Authentication Beyond the "Norm"

A week of vacation always gives one time to do some extra reading - catching up on things and looking at a broader base of things. This past week I had that opportunity and a theme came through in some of the articles I stumbled upon ... Authentication is generally thought of as a person authenticating to an application or two applications authenticating to allow processing of data. However there are other things that we need to keep in mind when we think of authentication.

Some of the major issues that are now being encountered are centering around source of base technology. Malicious code embedded in devices manufactured in other countries is one example. To date we have seen this method leveraged in devices used within the power grid and this has also been seen within components in laptops. This type of extended attack is much deeper and worrisome for many as it can go undetected for many years before being launched. Within the software application environment we of course have code signing that is intended to mitigate the similar style of attack which has been seen through code delivery. Code signing itself cannot stop the attacks that are further embedded in the base technology and to some extent does not mitigate all software based code attacks. There is a need in both environments to design a more complete end to end protection of systems.

Part of the issue in design of such systems comes to ensuring compliance in an environment where base technology is being delivered from many sources and in many cases to a consumer that is first concerned with immediate technological gratification - how many of us click through user agreements before installing software? Certainly there is an attempt at resolution here with the Trusted Computing Group's platform approach but broad acceptance of this across the many technology platforms has not happened.

So how do consumers and users protect themselves? That may be the muti-billion dollar question. Certainly there are simple things to mitigate risk for a consumer:

- Where possible buy a platform with a TPM (Trusted Platform Module)
- Only execute signed code
- Ensure proper validation options are turned on (CRL/Revocation Status checking for example)

The broader answer is something like TC. Is it signed object code? But how do you validate that code? Who authorizes the signature? Certainly there are many more questions and solutions but it is a problem that is growing and it will take a cooperative solution between hardware technology manufacturers, software distribution companies and software developers at a minimum. Education for the consumer is also important and something that has to be considered.

Maybe initiatives like NSTIC will get the conversation going - that would at least be a start.

What is Security?

I read an interesting article this morning on mobile banking. Now do not get me wrong - I am looking forward to mobile banking but the article raised another question in my mind - what exactly is security?

There are lots of people around the world using mobile payments today. With the advent of Google Wallet, Serve, VISA Wallet, ISIS and others combined with the rollout of NFC enabled phones this will only grow. Of course as this begins to grow these companies will focus their attention on making sure that their systems cannot be breached. The last thing they need is someone to pay for something they did not buy or to have the bitCoins situation of suspected account breaches occur. The use of strong authentication and fraud detection improves the security posture and the retailers themselves are bound to protecting data to maintain their agreements with payment systems such as VISA and MasterCard, so one would say the system should be as secure as the payment systems in use today.

But is it truly a secure system? The WSJ article discusses one of the big concerns that came out of the NSTIC privacy conference - reuse of data. What information is the payment system I am using or the retailer I am dealing with collecting? How are they using this? If a retailer collects my cell phone number as part of the authentication process can they keep that data tied to what I bought and the next time I walk near their store text me a coupon? That of course is the most minor case here.

This is yet another demonstration of the need for privacy controls at the device and within the relying party. At the device it should come as a form of an information or attribute release option, defaulted for some transaction types and interactive for others. At the relying party, in this case retailer, some form of opt-in mechanism for data handling. Maybe I want the coupons - but give me the option.

So is a system secure if the user does not have control of their privacy or is it good enough to say that the system will not have a serious breach? It is a interesting question.

As can be seen there are still lots of areas of specifications that need to happen. Are these areas for policy definition within something like PCI or are the areas here something that need to be included in legislative discussions? Lots to be done and how it happens, I believe, will determine how successful these systems are.

- Posted using BlogPress from my iPad

Planning is important

This week is my last week of doing baseline running in getting prepped for the Marine Corps Marathon. Next week the real training plan kicks in. As I was doing a few miles the end of last week I had a long discussion with myself on the similarities between marathon training and security planning - and the glaring similarity is that you need a plan and you need to stick to it.

Everyone sees a marathon as 26.2 miles. Yes that is accurate but it is not the whole story. It does not talk about the weeks of planning and the months of 30 or 40 mile weeks that you are running. Those 26.2 miles do not talk about the tempo runs, the interval runs, nor the long distance runs. It does not talk about the handling of injuries, the planning for hydration and nutrition when running 16, 20 or 26.2 miles. Those are all details that get lost in the vision of a marathon.

Security planning is no different. There is no silver bullet in security planning. It is a long hard slog. Planning simply makes most events more controllable. Yes there will always be challenges, a breach due to a new zero-day attack or a true ATP, but the plan should also include how you handle these much like the marathon plan includes how you handle a strained muscle or a bad cold. Security planning needs to involve all relevant parties - business owners, CxOs, developers, hr, and where possible relying parties and end users. At least for relying parties and end users their needs and concerns need to be assessed and addressed. Security planning also is broad as well as deep. It is not enough to protect the boundaries, as we have all seen from recent attacks like those at the National Labs, but it must also consider subversive attacks. The plan must also involve things like: how I know who is entering my network; what happens when their means of authentication has to be challenged and how that happens; how do I detect attacks - on the periphery and inside the network; how do I control what hits a desktop - balancing between business function and protection; ad of course this list could go on for days worth of reading.

The point here is that it is the plan that is important - and that plan needs to be constantly assessed based on new needs, new data points, new attacks - and execution of the plan has to be the responsibility of one part of the organization with the assistance, cooperation and input from the others. Just like my marathon training plan, which does not succeed without a lot of help, input and support from my wife and kids, an organization security plan will not succeed without help and support from your organization and when needed some outside experts to give that independent view of how you are doing.

Report from NSTIC Privacy at MIT

I have attended the initial two NSTIC conferences and I think I can safely say that things are ..... interesting. My first comment is that it is quite obvious that there is still a lot of work to be done. I firmly believe that in the governance and privacy areas there is one big thing that needs to be done and that is to take what has been accomplished in other areas and map those to see where there is intersection and then see if that is something that will be useful for NSTIC. I say this because there are lots of good things going on in a number of areas but right now I think trying to take each one of those and to map to NSTIC or to see which piece is useful may be overwhelming. I hope that as responses to the NOI come in that a process like this will help to ease the burden.

The conference itself was thought provoking. Some ideas that struck me were ideas of data ownership and pseudonymity versus anonymity. There were many others but these two struck me in particular.

On the data ownership side there was much discussion on data ownership. Certainly it is easier to define ownership of some elements of data including things like credit card numbers, social security numbers, birthdate, address, weight, height etc .... but what of other types of identifying data? When I buy something online at apple.com is the fact that I bought something make that my data element or does it belong to Apple? Certainly Apple needs to know who to charge and what and where to ship but outside of that, once the transaction is complete, do they need to keep that data if I do not want them to? Should they be allowed to tell Verizon that I just bought a 3G iPad 2 with a Verizon chip in it? These "data breadcrumbs" are left by all kinds of transactions and the question of ownership is interesting.

But of course it is not just ownership - once I have ownership how do I protect that data from improper use or for that matter any use that I do not want? This is an interesting challenge in terms of privacy and in the process does it step on things like tracking (web tracking being looked at legislatively today)? Does it also step on business model? Experian, Transunion and others keep data on me that they use to provide market targets to other service and product providers. What happens to these entities and the downstream providers, who use the information, if we change how those breadcrumbs get picked up?

The other interesting data point was the pseudonymity versus anonymity thoughts. For those of us that believe we can be anonymous on the Internet I present an excerpt from an LA Times blog on the possible exposing of LulzSec. "The A-Team said LulzSec's members were a product of the hacking culture found on the Website 4chan, which is rooted in anonymity, making some feel invincible. .... "The Internet by definition is not anonymous," the group said. "Computers have to have attribution. If you trace something back far enough you can find its origins.""

So do we accept that we will at best be pseudonymous? Does that lead to multiple identities or multiple personae within a single identity? In either case it becomes critical that we prevent linkage between these unless that linkage is driven by the identity owner. This idea is one I will be thinking about some more - it is definitely interesting.

There were many more great ideas shared and I would encourage anyone with interest to visit the NIST NSTIC site to follow the updates.

- Posted using BlogPress from my iPad

Re-application of Technology

As I was thinking about the upcoming NSTIC Privacy Conference my mind wandered to some of the technical challenges that exist. Some of these are things that we have been discussing for some time and are directly related to privacy. One of the core ideas is that in our online lives we have different degrees of relationships with other entities. Some of these relationships require a high degree of assurance as to who I am, for example, accessing my health records online, others do not require a high degree of assurance (commenting on blogs is one of them). That being said the question becomes how do I maintain a single identity but use it differently in different places?

There are a couple of technical solutions that are out there today that are being discussed:

• Backend Attribute Exchange (BAE) leverages SAML 2.0 and a cooperative architecture to build a system whereby a relying party can request further information about an authenticated entity using a set of standard protocols. This system works very well in an environment like one of first responders where the community is well defined and the sources of attribute information are well recognized. I also think it can be extended to a more general use but a broader infrastructure for identifying Attribute Providers needs to be architected and a mechanism for predefined release needs to be implemented within these. I do believe all the pieces are there and I know some of this work is ongoing so we may not be that far away.
• uProve is driven largely by Micrsosoft but there are a number of open working groups including one on Claims Agents that are looking to open source variants of elements of the system. Teh basic tenet of uProve, from a architecture perspective, is not that different than BAE. Grant it the underlying technology is very different but the architecture of a relying party, communicating with an end entity for authentication and then using a third party to validate claims is not that different than what BAE is achieving. 

There is a third one that comes to mind and it relates to the idea of re-application of technology. ePassport systems are based upon either Basic Access Control (BAC) or Extended Access Control (EAC) mechanisms for access to information on the ePassport. At Entrust, where I work, we have implemented both types of solutions in multiple countries and have been involved in the standards work around ePassports for a number of years. As the BAE and uProve technologies have come to surface I began to think about how EAC has the same basics in terms of architecture. The EAC architecture is more closed today due to the application but with the ongoing definition of EAC 2.0 there is a lot more similarities in terms of architecture. Can EAC 2.0 be even further extended such that its protocols extend beyond the chip-reader communication set to reuse the ideas there to allow for extension into chip-relying party in general? Does this provide the end entity with greater control in terms of information release and do so in a self contained environment? Today information release through uProve and BAE have release notification at the attribute service but could EAC bring that to teh credential holder in a self contained way.

I am planning to explore this a bot more over the next two days at the NSTIC conference in Cambridge so look for a follow-up.

Why PIV-I?

I wanted to followup on the discussion of PIV-I that I started a couple of weeks back. That discussion centered around what is PIV-I. As is the case the "what" has to be paired with a "why". Over the last couple of weeks I have also brought up a couple of other issues that tie in here that can be summarized with "authentication architectures".

The last few months have seen a significant proliferation of attacks against authentication systems: RSA SecurID, a defense contractor having their Active Directory administration services breached; and the Comodo attack against an administrative function. These attacks, and more, were intended to achieve one thing and that is to be able to get deeper into systems than a normal attack would and to potentially extend the attack reach outside of the initial target.

So how does this play to PIV-I?

PIV-I does  a number of things: it defines a standard issuance process; it defines a standard token; and it defines a standard token interface. The PIV-I specification allows organizations to readily see that another organizations have implemented an authentication mechanism that is measurable. Once you know that the mechanism is measurable then you can decide how it meets your requirements so you can decide if you can trust these credentials, and for what purpose. A good example of this is within the US Government agencies looking to PIV-I as a way to be able to easily work with external parties, contractors, suppliers, partners and other governments like State and Local. An example of this happening is that DOD has created a list of commercial SSPs that issue PIV and PIV-I credentials that can be trusted within DOD. So there is a business reason to use PIV-I, a strong mechanism to allow for digital interoperability at a high degree of assurance.

There is also a business reason for PIV-I based on the above mentioned attacks. A PIV-I token is a FIPS validated credential with strong protection mechanisms. Too many wrong passwords and the token is no longer usable. Private keys cannot leave the card. It is a PIN protected device; and has a biometric capability for additional assurance requirements. On top of these the credential is issued through a process that is well defined, requires in person proofing, and is separate from the relying party application. This last piece is the important element as it provides a safety barrier in the case of attack against the authentication system, as discussed in the last post. Another good read on the subject can be found here.

So PIV-I is an authentication mechanism that provides a well defined process for issuance, a strong credential  for identity (physically and logically) and mitigates some of the risk factors that were in place with the attacks against authentication systems that have happened over the last many months.

Next will be a discussion on using PIV-I in a solutions architecture.

APT and Layered Authentication

I was recently speaking with someone about their infrastructure and an issue they were addressing. Their infrastructure is based around Active Directory. It is a standard implementation that uses AD to identify end entities, grant privilege and to push policy. The issue is that they are faced with an Advanced Persistent Threat against this existing AD implementation. The question becomes how does one move from this existing infrastructure to a new one while ensuring that they can safely port the existing end entity population (machines and persons) and to ensure that they implement a strategy that mitigates the risk of the ongoing and future APTs.

It seemed to me that the initial strategy has to be one around the segregation of the authentication infrastructure. In a traditional layered security approach we speak of separation of duty, roles and in some cases networks but infrequently do I see people look at the authentication infrastructure as a separate element - it normally is imbedded into some other element - usually preceded by comments like "well Microsoft gives me a CA imbedded in AD". no knock against Microsoft but we need to be careful of architectural implementations.

The authentication infrastructure is a key component of usability but also of defense. Knowing who is accessing a resource is critical and in the case of an APT even more so as the traditional ways to protect a resource may already be compromised. There was a very good example of this within the last year when a major technology/defense firm had their AD compromised. In the process of that compromise the attacker was able to act as a administrator for the certificate authority that was part of the AD implementation and was able to issue credentials that allowed broader access and possibly to a wider audience.

It is becoming critical in light of these persistent attacks that additional precautions be taken. Layering the authentication infrastructure is one element of this that allows for migration of the core elements with less impact on end entity credentials. Similarly if the authentication infrastructure becomes compromised, such as the RSA breach, then you can also take a layered approach to credential replacement. Although this is more challenging if you do not know how deep the attack became after the credential breach but this is another reason to stress the importance of the authentication infrastructure. One step beyond that would be to look at layers of credentials within your infrastructure that would allow levels of access to resources based upon risk and type of credential presented .... but that is another topic.


- Posted using BlogPress from my iPad