Main

October 4, 2011

The Perimeter is Dead, Long Live the Cloud Firewall.

Today, we are announcing Symantec O3 early access program, a new approach to securing enterprise clouds. But what is Symantec O3 really about? No doubt, cloud is an inexorableIT trend. However, CIOs and CISOs often cite security as a major concern. That is not to say that the new cloud platforms are fundamentally more insecure than the computing platforms that preceded them. Quite the opposite, cloud-oriented architectures have the potential to provide stronger security than most IT organizations can achieve today.


Nevertheless, SaaS applications and cloud infrastructures challenge in their own way IT's fundamental function of defining and enforcing consistent security policies across devices, users, and information. The new cloud platforms directly conflict with the need for enterprises to establish consistent risk profiles and compliance postures. The shift to the cloud is eroding our traditional controls. Network-based security is no longer as effective since the network is no longer ours The network and its controls now belong to Salesforce, Amazon or Google.


The shift to the cloud raises a fundamental question regarding the role of tomorrow's IT. If IT can outsource desktops, applications and infrastructures operations, can IT also outsource the governance of corporate digital policies? The answer is simple. IT should no have to embrace the cloud at the cost of renouncing its "raison d'être"! We ought to be able to embrace the clouds without relinquishing the control of our own security policies.


This need to layer IT driven security independently of cloud providers drives the emergence of a new security control point. The new control point must act as a "cloud firewall." Unlike it sibling, the cloud firewall inspects outbound traffic. It is not network-centric but web-centric since Web protocols are the clouds lingua franca. The security gateway leverages identity and access control to initiate itself between all user devices (fixed or mobile) and clouds infrastructures (private or public). It creates a new layer of IT security and governance. By virtue of being inline with cloud traffic, the cloud firewall is context aware (identity, device type, location, time, etc). It is also be content-aware, providing information security through the deep inspection of HTTP streams and the application of DLP, encryption and tokenization technologies. Indeed, the cloud firewall has complete visibility. It feeds cloud access and information events into log management systems that can now correlate security information across internal and external systems across managed and unmanaged devices.


At a time where pundits are claiming the deperimeterization of the network, it is time to reinvent a new form of perimeter for the cloud. Delivering on such vision will take no less than the leading security company. The cloud firewall is the cornerstone of tomorrow's IT security. So, long live Symantec O3, the catalyst for a new form of perimeter security, a perimeter for the cloud.

April 20, 2011

Trusted Identities in Cyberspace

Last week, the White House announced its official National Strategy for Trusted Identities in Cyberspace (NSTIC). NSTIC is the largest-ever effort by the federal government and private sector partners (including Symantec) to develop a secure, standards-based and interoperable online identity system. The goal: Improve the security and privacy of online interactions and more effectively fight cybercrime. Today's announcement marks the culmination of two years of effort by VeriSign (first as an independent company and later as part of Symantec) to help bring this important initiative to life.


At the heart of NSTIC is the concept of an Identity Ecosystem based on trusted identity frameworks. Trusted identity frameworks are the lynchpin to trusted interactions online, for everything from e-commerce to electronic health records to online voting. These frameworks will require all participating service providers to ensure the credentials they offer adhere to the same standards for identification, authentication, security and privacy. This wouldn't be a "national online identity" setup, but rather interoperability among many market offerings.


The initiative recognizes that public-private partnerships are essential for success. Symantec and other private sector companies have already created the technology for strengthening and sharing high assurance identities. Government leadership will promote, facilitate and coordinate industry to further NSTIC goals.
The government can also help overcome the three big impediments this kind of initiative faces:


1. Privacy concerns: The government can define and deploy standardized trust frameworks that help ensure citizens privacy (e.g. by working through the private sector, leveraging organizations such as the Online Identity Exchange).

2. Liability concerns: Data breaches involving personally identifiable information (PII) can easily run into the tens or hundreds of millions of dollars, depending on the number and kind of records affected. Once trust frameworks are in place, Congress can pass legislation to cap liability for organizations certified under those frameworks.

3. Business concerns: The federal government can create business incentive for trusted identity providers to join the eco-system by becoming the initial customer. That would basically prime the pump for a trusted identity service business model.


NSTIC's goals for FY11 include:


• Convene the private sector by hosting workshops on governance, privacy and technology
• Establish a governance model, standards and models for addressing liability
• Develop criteria, assess potential programs and prepare for formal funded pilot launches in FY12


These plans are ambitious, certainly, but are necessary given the escalating data breach and cybercrime threats people face every day. NSTIC will provide the means to dramatically improve online authentication and the security, privacy and business benefits it provides.

September 6, 2010

Identity Proofing - the Next Mobile Business Opportunity?


It is clear that high assurance identity on the internet is going to require identity proofing. With more than 1 Billion Web users, and 3 Billion mobile users increasingly connected to the Internet, scalability is going to be essential. If high assurance identities become the norm, digital identify verification services that do not require in-person proofing could therefore turn into a significant market opportunity


Most folks in the industry would tell you that credit bureaux, and financial institutions ought to be primary beneficiaries as the new business emerges. However, the convergence of Internet, mobile and telecommunication driven by iPhone and Android could attract new market players. Mobile network operators (MNOs) have a wealth of identifiable data about us. They are also uniquely positioned to bring to market multi-channel solution. In fact, an MNO-operated ID proofing service could easily support voice and web, for brick and mortar as well as online service providers.


Them comes the unfair advantage: the mobile handset. Obviously, the biggest challenge of "person not present" identity proofing lies in the processor ability to match the person on the other side of the communication channel to the identity data. A personal mobile device provides a unique link between my digital and physical me (there is a long history that links my mobile device to my identity). For the web, it supports an out of band channel that considerably adds to the security of the verification process. From a privacy and control standpoint, the mobile phone enables a user-centric approach where the user can approve the transfer of her personal information (a sort of out of band OAUTH dance). Last but not least, location (somewhere I am) may prove of strategic importance, since an embedded GPS can correlate the proofing event to a verifiable personal location (e.g. my home). Location verification for proofing could happen "just in time" or as a post-process step. In any case, it would greatly strengthen the overall process.


There is little doubt that the combination of wireless data and handset constitute a unique recipe for enabling high-assurance identity proofing systems. The OIX will soon get to the bottom of this theory since it has recently announced the formation of a working group for telecom data. Early next month, OIX members will explore the development of a trust framework that would support the secure exchange of identity data between MNOs and relying parties while ensuring the privacy and trust of consumers. This could well be a significant step towards high-scale, high-assurance identity systems. So, good luck to new working group; we will be watching closely.

June 2, 2010

Cloud Identity, Trust and the Liability Elephant.

I have been involved with a couple similar initiatives around certification for identity and thought it would be interesting to explain the logic behind these efforts. The first initiative is led by the Open Identity Exchange and is based on the Open Identity stack. The second is more enterprise cloud focused; it is driven by the Cloud Security Alliance (CSA). The CSA is developing a more SAML-oriented technology blueprint within OASIS. The technology protocols are different but the risk controls are similar. Therefore, I am hopeful that both trust frameworks will converge (I will certainly try to help them converge).


But let us re-hash the motivation of the industry that sponsors these efforts. A trust framework is necessary to enable policy makers across vertical markets (healthcare, enterprise SAAS, mobile payment, digital content) to set the security and privacy bar for identity providers, identity brokers and relying parties. For sure, across all vertical markets, the sharing of identity requires a baseline of best practices for security, and privacy as it facilitates customer adoption of cloud identity services by providing a foundation for trust.


However, there is another motivation to develop certification programs for identity services. The true 'raison d'être' for identity trust certification is that it will allow private consortia or legislators to govern liability in a multi-party transaction. In particular, one can shift the liability away from accredited identity providers on the basis that they have demonstrated the proper privacy and security controls through certification. In other words, trust certification can be used to kill the liability elephant that has been haunting the federated identity rooms for so many years.


By capping liability risk through certification, an identity trust framework would make it commercially easier for large Internet consumer, commercial banks and online payment systems to participate as identity providers in high assurance transactions such as health care, eGov services and all new breeds of cloud services. In essence, this not too different from the VISA model, where a consortium of financial institutions establishes the network blueprint, for online payment, defines the necessary security controls and is hen able to shift the liability (in this case, away from the card issuing banks (IDPs) to the merchants (RPs), who are generally responsible for charge back expenses).


Of course, certification does not happen in a vacuum. Certification is about risk management. It needs to define privacy and security controls appropriate to the transaction and information risk levels. This means that identity certification will have to discriminate among different levels of assurance (most likely, the four NIST levels of authentication) in order to adapt across multiple verticals. Howard Schmidt seems to agree with the need for identity trust frameworks and even points to a concrete market: "The president is 'concerned and very committed' to making sure that as healthcare goes electronic that 'we also have the right controls for security and privacy,' Schmidt said at a May 11 conference on privacy and security sponsored by the Health and Human Service Department. "The plan to develop a strategy will focus on ways to improve identity management. As part of that effort, the administration will roll out a 'trust framework' incorporating authentication technologies, standards, services and policies that government, industry and consumers could adopt. The key issue is that we have to instill trust in the system. If we don't trust the system, we won't use it and if we don't use it, we lose its [potential] benefits".


For all of us in the digital identity world, it is certainly encouraging to see that the federal administration is recognizing the importance of identity management and its acute need for trust policy. It is certainly not an easy issue, but it is now getting the visibility that it deserves. There is also plenty of good will in the industry to collaborate and make a trust framework for eHealth a reality. The elephant may not have quite left the building, but at least we can now all see it, and it is a good thing.

April 5, 2010

Open Identity: the end of childhood, the age of assurance

This week is the week of the OpenID summit in Mountain View, California. We are all hoping that 2010 will be another pivotal year for open identity. There seems to be a combination of market forces that are making federated identity more attractive. In fact, we are hearing new compelling use cases for federation. A first example is cloud access and identity management. As enterprises shift their IT infrastructure and information to the cloud (as in IAAS, PAAS and SAAS applications), CIOs need to federate corporate identities with cloud service providers. For cloud resources, the corporate directory becomes the identity providers and the cloud services are the relying parties (and if you don't have a directory or don't want to use it for federation, Google is in the pole position to be your OP). Another interesting vertical ripe for federation is healthcare. Now that the Obama bill for healthcare has passed, one should expect a revival of health information networks (remember the RHIOs). Finally, payment, the mother of al federation, online payment, is seeing a lot of innovation too. From mobile to social games, to high assurance open identity networks led by modern payment systems such as PayPal, Amazon or Facebook could sway consumers, curb fraud and shift merchant liability where Verified by Visa has fumbled to-date.


So, what do the trusted cloud initiative, Obama's new health care bill, and next generation online payment have in common? They all require federation and stronger forms of authentication to enable trust and protect against fraud. These transactions are complex and risky. They are complex because they involve multiple independent, sometime competing organizations. Federation is needed. These transactions are also too risky because the current Internet authentication system based on name and password is too weak. High assurance identity is needed. As government and vertical industries worldwide come to the realization that their cyber security and business agenda require them to enable high assurance online transactions, federation and strong authentication will converge into new compelling trust infrastructures deployed across vertical markets.


The need for high assurance federation may provide a much needed boon for open identity technologies such as OpenID and OAuth. The point is that the adoption of a new identity management model on the Internet by consumers may require much more than single sign on, attributes exchange and authorization. As Dick Hardt put it many times, these traditional identity features are only vitamins. Most people won't go for vitamins alone. Consumers want enablement. Facebook figured that one a long time ago but tying friends discovery and activity streams to Facebook Connect. So, what is Open Identity's mojo then? I dare to suggest that the opportunity for open identity is new transaction enablement. If open identity networks can enable complex and risky transactions that are not possible online today, massive adoption will follow and altering the digital identity experience becomes palatable.


Of course, it is a security guy talking but let us consider the business model too. The business of security and trust is well understood. Credit bureaus, security companies and VISA/Mastercard have clear and compelling transactional business models. Transactional revenue model are also more compelling than advertising. The profit margins for standing in the middle of transactions as neutral third-party and enable high assurance are fairly high. Compare the addressable market to the currently minuscule market size of open identity as it stands today. Whether you look at it from a product, deployment or economic standpoint, I continue to believe that the future of open identity on the Internet rapidly is intimately linked to high assurance identity.


March 3, 2010

Open Identity Exchange: enabling all the VISAs of identity

The Open Identity Exchange was launched this morning at the RSA conference in San Francisco. It is a significant step for federated identity as it will enable US government web sites such as the NIH to embrace open identity standards and roll out open identity services to US citizens. For example, the National Institute of Health can now move out of pilot phase and support accredited OpenID providers.


So, what is the Open Identity Exchange (OIX)? The OIX aims at enabling specialized trust frameworks or certification programs within a vertical community (e.g. US government, health care, financial services). Certification requirements for shared identity can be diverse and complex depending on the level of assurance required. Simply said, when it comes to trust, one size does not fit all.


You can think of a trust framework as the policy sibling of technical standards for identity. Identity policies must be set to deal with privacy, security, and liability. Once policies have been defined, certification can emerge as the foundation for trust between all parties exchanging information. However, the type of policy needed greatly depends on the sensitivity of this information, the security risks, and many other factors, including geo-political sensitivities. Indeed, the level of trust assurance required to protect access to the energy grid, electronic health care records or social web pages is clearly not the same.


The open approach that the OIX take is attractive. The OIX does not try to set the policy rules. Instead, it creates a common framework, a shared approach that will enable different communities to create their own certification rules. It is not an easy problem. But because cyber security and key governmental initiatives depend on high assurance identity management, OIX is an important first step to get there.

November 3, 2009

Trust assurance in open identity networks


One of key challenges in federated authentication network is the establishment of trust between an identity provider (IDP or OP) and relying party websites (RP). In the real world, contractual agreements provide a simple out-of-band mechanism to effectively bind two parties into a trust relationship. When it comes to federated identity networks, peer to peer contracts between many identity providers and a myriad of relying party websites do not provide for a scalable process. Therefore, open federated networks need a trust assurance framework to bootstrap trust between the three parties (the user, the OP and the RP).


The basic idea is that if an OP can be certified to comply with a set of industry best practices, the RP should be able to enter into open identity exchange where both the websites and the consumers are reasonably protected. Of course, a pragmatic trust assurance framework should be flexible enough to support different levels of assurance based on the transaction risk and value. For low assurance Web federation where large brands such as email providers and major social networks dominate as OPs, certification may seem overkill, unless of course, the federation is built on open principles stating that any OP meeting the standard should be able to participate. For high assurance identity, such as payment networks, financial networks or eHealth record exchanges, certification is primordial. In fact, in such environments, both the OP(s) and the RPs need to be certified.


The NIST guideline for electronic authentication is often referenced in the community as a good model for any identity trust framework. The NIST guideline defines four levels of insurance for e-authentication. Each level is deemed appropriate
Depending on transactional risks. Tiered levels of identity assurance are essential to any pragmatic trust framework. Set the bar too high and deployment becomes impractical. Set the bar too low, and the bad guys will have a ball. Justifiably, the NIST guideline provides a solid starting point. Nevertheless, one needs to observe that the framework may be too narrowly focused on user credentialing and credentials strength to provide a complete answer. Open Identity systems cannot ignore the reality of today's Web vulnerabilities, threats and exploits that feed identity theft around the globes such as man in the browser exploits, session hijacking or Web vulnerability driven exploits like mass SQL injections. A trust standard also needs to go beyond security and address the major consumer concerns and political challenges of privacy. When it comes to trusting identities, security, privacy and anonymity are intricately intertwined. Trust in a federated identity Web mandates a holistic approach that looks not only at user authentication but also takes into account the current state of desktop exploits, Web site compromises and most importantly establishes clear and enforceable privacy protection guidelines.


Trusting the OP/RP Websites: web security & business authentication


For low and medium assurance identity transactions, it seems to be that both the OP and RP website security would need to be asserted. There I think, one can learn from Internet security standard such as PCI. Even though the standard is far from being perfect (a euphemism, perhaps), it provides a shared base of security requirements for all websites to engage into ecommerce and securely handle credit card information. If one believes that consumers will require for their personal identity the same level of security as for their credit card, the parallel can be useful. The OP website should then be scanned for network security vulnerabilities; Ports should be closed. Network services should not run outdated or un-patched software; the OP should not be vulnerable to common Web exploits such SQL injections, cross-site scripting (XSS), or Cross-Site Forgery requests (CSRF). For web application vulnerabilities, the OWASP standard that identifies the top 10 Web vulnerabilities provides a useful reference. In addition to security assessment, a set of security best practices should be required. For example, the OpenID profile retained by the federal pilot already specifies that SSL should be part of the deployment profile. Verifying the authenticity and legitimacy of the organization behind the OP is as important as verifying the security of its website. There, a proven model that the industry could re-use is the EV business authentication standard. EV certification already defines a strong process for vetting organizations and it is already widely used across the industry.


Trusting the user: beyond identity verification and credentials


As mentioned, NIST will provide the foundation for user trust assurance (both for runtime and initial authentication of end users). Equally important, however, is to consider that Internet threats have significantly evolved since the NIST framework was initially published. In particular, we need to recognize that one of the main threat vector for identity theft is now malware. An identity trust framework can no longer ignore the potential of a man-in-the browser attacks (Trojans, key-loggers, worms, etc). Knowing whether the end user has any end-point protection (and maybe encouraging websites to introduce out-of-band messages into high assurance identity transactions when such protection is lacking) could be of consideration.


Trusting the transaction: from activity to security streams


Believing that the OP can provide strong identity assurance by simply checking credentials and abandoning the user at the RP front door is a dangerous over-simplification. Because modern exploits often let the user authenticate to commit fraud further down the session, it is important to enable OPs to leverage the knowledge of the end-user and her transaction patterns to identify high-risk conditions. Since we cannot assume the existence of adequate desktop protection (Internet security that exclusively relies on the presence of a client on the user desktop is no more than an academic exercise), high assurance federation models need to enable the use of fraud engines techniques across RPs (most logically, run at the OP although it could be a separate). The ability to create an effective user risk profile across transactions is what has made the credit card networks work. High assurance identity networks are going to need an equivalent (think VISA of identity). An interesting idea could to leverage the concept of activity stream as a real-time fraud detection primitive. A security stream back to the OP (under complete user consent and strict privacy protection) would allow RPs to feed transactional information back to the OP, allowing it to build a complete risk profile of the user across her Internet activities (fraud detection is often based on clustering techniques that measure abnormal deviation from normal behavior). Even without a risk-engine running at the OP, a security activity stream could have tremendous security value if used as a simple identity alert system to notify the user of all ongoing transactions. In high risk cases, the activity stream could trigger an out-of-band consent for the transaction (think of Visa calling you to confirm and authorize a suspicious transaction); it is interesting to think that the social concept of activity stream that is today missing from OpenID (not from Facebook Connect) could actually be used to drive better identity theft protection. With such transactional feedback loop, a security minded OP would be able return a transaction score and possibly a liability guarantee based on the user risk and behavioral profile built over time. Incidentally, interesting new OP business models could emerge (VISA-like: "I will take a cut of the transaction", Credit-Bureau-like: "I will charge you for the score", Insurance-like: "I will take the liability risk").


Ensuring trust across these three dimensions (the organization, the website and the user) is non-trivial. Yet, it is critical to enable consumers worldwide to engage into shared identity interactions with peace of mind across the Internet. Very much like PCI vendors emerged from the existence of a commercial PCI standard, one would hope that Identity trust assurance services could emerge as well since security companies need economic drivers to build great services. One of the key challenges of the standard will be to strike a balance between where to set the security bar to permit a high level of automation for accreditation. Such balance is always hard to strike, but it is also what makes the challenge worthwhile.

September 22, 2009

OpenID goes to the White House

Two weeks ago, I had the privilege to join the OpenID foundation and Information Card boards for a meeting with CIO, Vivek Kundra and his staff at the Whitehouse. The goal was to discuss the forthcoming OpenID pilot and better understand the government commitment to enabling distributed identity on the Web. Undeniably, this was a very interesting and spirited discussion.

WH.JPG

A key take home for me was the recognition of identity as the lynchpin to new citizen-centric services, governmental IT cost reduction, and stronger cyber security. For key Obama initiatives such as citizen participation or electronic health records, identity management was described as foundational. Equally impressive was the sense of a holistic and consensual approach towards the broad deployment of trusted digital services across federal, state and local Web sites.


In particular, there is a clear view that the deployment of low level assurance identities is only a critical first step, not an end in itself. With the initial OpenID pilot, the administration is seeking to teach Internet users how to conveniently and confidently re-use their identities across multiple sites. Federation is a new behavior and as such, it requires training. Federal and State web sites will provide an important training ground of relying parties. The government endorsement of OpenID is likely to prove significant. After all, if OpenID is good and secure enough for the government, it should be good and secure enough for most Web sites. Beside, once consumers are comfortable using distributed identities, it becomes possible to alter the login experience by introducing stronger security and identity assurance. This is the ultimate end game since high assurance identity services are pre-conditions to new strategic initiatives.


Consider health care reforms for example. To counter balance the $900B expense that the new Obama plan calls for, electronic health records must come to reality. However, eHealth requires access control across a large and complex ecosystem. Users must be able to register, login and access private data across physicians, hospital, pharmacies, labs, insurance, and employers Web sites. Privacy and security concerns are high on the list. Without high assurance, clear liability models and robust shared identity services, eHealth is a non-starter.


The crawl, walk run approach to identity services that our federal government is taking may prove insightful. By restricting initial interaction to pseudonymous and low assurance level identities, federal web sites instantly provides the industry with a simple test bed to iron out the trust and privacy frameworks necessary to the deployment of large federated identity networks. User experience, privacy policy and security approach that can work for millions of consumers will have to be standardized. The liability elephant that has been haunting the identity discussion rooms will have to be tamed. No doubt that the OpenID foundation, the Information Card foundation and many other have their work cut out for the next few months.


So, keep an eye on the pilot. If all the planets keep aligning, and federated identity can prove to significantly increase user registration, an important chapter in the book of distributed identity systems may be just about to open in front of us.

September 8, 2009

Open identities for open civic action? Yes, we can!

Today, Federal CIO Vivek Kundra is announcing the first pilot for its Open identity initiative. The pilot will support both OpenID and Information Card technologies. Initially, it will be conducted by the Center for Information Technology (CIT), National Institutes of Health (NIH), U.S. Department of Health and Human Services (HHS) and other agencies. Over time, over 500 governmental web sites may become Open ID relying parties, potentially, creating one of the largest federated identity network.


Bien sur, VeriSign and the PIP will participate to the pilot as Open ID authentication services. This means that your VeriSign PIP ID will be accepted across participating federal Web sites. Saying that we are proud of being a part of this important announcement would be an understatement. The open identity initiative is a crucial step in President Obama's mandate for open citizen participation on key society issues such as health care, ecology and energy.


The goal is as bold as it is audacious. By embracing open and distributed identity systems, the US government is taking a resolute step towards turning the Web into an organizing engine for participative civic action. Identity is foundational. Making it easy for users to register and participate in government Web sites is smart. Removing obstacle to participation by allowing citizens to manage their digital identity through independent service providers of their choice is inspired. Yes, the tone is definitely right. Civic participation should be based on principles as open as is the Internet that enables it.


User centric identities for a citizen centric Internet? It certainly feels very right to me.

Read our Press Release.

August 20, 2009

I will have your cookie and eat it too


In the coming years, many websites will contemplate adding strong authentication to accounts login. So far, early adopters for strong authentication have mostly been financial institutions. Since 2005, banks and brokerage firms have had had little choice than following the FFIEC guidance. This 2005 regulated mandated a move to stronger credentials than just name and passwords. Today, SAAS providers and large consumer Web sites are increasingly suffering brand exposure and public scrutiny following high visibility attacks (here and there). With increasing reliance on the cloud to host mission critical applications and sensitive data for enterprises and consumers, I would expect many large online services to begin offering stronger login options to their user base.


Interestingly, the FFIEC deployment of multi-factor solutions such as chase.com or bankofamerica.com give us some insight into the type of technology that are likely to be adopted by non financial service providers. Multi factor authentication essentially relies on a cookie as the second factor (the cookie is "what you have"). Coupled with a backend anomaly engine, the client side cookie is used as a "persistent" device identifier. Cookies as device IDs are alluring because they work across all browsers; they do not require any new client install on the user desktop; cookies are transparent to the end user, and most importantly, they do not cost anything. Since cookies could become prevalent as a "second factor" for web login, it is important to be aware of the security limitations and risk that they represent.


The first issue with cookies is their lack of persistence. Statistics show that users very often reset their cookie. This leads to the challenge of "cookie re-issuance" or cookie reset. This problem is roughly equivalent to password reset which, as many recognize, is the Achilles' heel of login. The alternative is not pretty. Either you make the reset process stringent and secure and it becomes a hassle to the end-user; or you make the process relatively easy, and it leads to very simple attacks. In short, the lack of persistence of cookie as device ID will trigger many cookie re-issuance events. Since high frequency life-cycle events cannot be made too complex without frustrating customers, the high frequency of cookie reset will inexorably lead to simple procedures. In turn, these simple procedures will inevitably open the door to a broad range of attacks.


The second class of problem with cookies is that they can easily be stolen using remote attacks such as cross-site scripting (XSS). XSS is a vulnerability that lets the attacker overcome the same origin policy enforced by all modern browsers. The policy circumvents scripts loaded from one domain to access content from another domain. XSS vulnerabilities effectively allow an attacker to execute scripts in the context of the vulnerable domain, hence overcoming the same origin safeguard in the browser. All the attacker needs to do is to exploit this vulnerability by crafting a request parameter value along the lines of . Since this gives the attacker unlimited access to any cookies of the website, DOM content, etc., this is considered one of the most serious vulnerabilities out there. The key about this type of cookie attack is that it can be launched remotely. In other words, an attacker can get to a user cookie without the user machine being compromised by malware. Add malware on the user machine, and cookies as a device ID become a recipe for disaster. In that case, cookies and machines fingerprints can be harvested and sent to the bad guys without the user ever noticing anything.


The increasing reliance on a silent device ID that does not impact the user experience is a logical approach to strengthening authentication on the Web. It is only the absence of alternative to cookies that is leading web engineers to leveraging them for authentication. Cookies were not invented for such purpose. As my sweet-tooth daughter would eloquently put it: the world need better cookies. Eventually, we do need stronger, more persistent devices ID that can be deployed across fixed and mobile devices, competing operating systems and browser platforms. These strong device IDs can be shared secrets, asymmetric key pairs or device certificates. The technology clearly exists but we lack a common deployment framework for device IDs (open client, common user experience, shared ID security stack, hardware protection too) .That is typically where the industry does it best work. Everyone needs it. Everyone will benefit from it. No one can do it alone.


The common need for open standard, open stack and open policies to deal with strong, persistent and privacy-conscious device IDs will inevitably lead to a joint effort. As cookies start crumbling across websites, security experts will get together and the urgency for collaboration will come to bear. In the meantime, when access security really matters, I will keep using my one time password token. If only, I could remember where I left it.


March 8, 2009

The Next Trust Infrastructure: Securing Mashups

There is no doubt that mashups will be an important construct of the next Internet. The ability to "compose" distributed Web services into one single aggregate service or view is a significant enabler. The lightweightness of HTML and JavaScript speak to the simplicity of a successful programming model. Add to this the emergence of open standards like OAuth, and the need to distribute functionality across screen boundaries (PC, mobile and IP TV), and the picture becomes very clear; mashups and widgets are likely lead the componentization of the Web and become an important distribution mechanism.


For mashups to become ubiquitous, a trust infrastructure is needed. To establish trust between a widget aggregator (a consumer portal, the enterprise portal or your homepage or TV screen), and a widget provider, protocols like OAuth essentially rely on the exchange of shared secrets. This works well when there are only a few big portals serving as aggregators. However, because they require pair-wise trust relationships, the approach does not scale to a truly distributed environment. In particular, the model breaks very quickly in the enterprise as the number of network end-points (enterprise portals and SAAS) explodes.
Alice.jpg
Ravi Ganesan and his new company SafeMashup may have found the answer to this thorny problem. Ravis' answer is brilliantly simple: reuse the existing and proven trust infrastructure of the Web. Indeed, SafeMashup enables existing CAs to issue credentials to mashers and mashees. These credentials are identical to the one they issue to Web sites today. Because Web 2.0 protocols such as OAuth require a shared secret, Ravi uses the SSL handshake and the issued SSL certificate as a secure method to establish a shared secret between the masher and the mashee. This approach allows him to layer SSL and certificates on top of the Web 2.0 protocols without requiring any change to these protocols. Brilliant!


There is no doubt that broad deployment of mashups requires an open, standard-based scalable trust infrastructure. Reusing the existing PKI infrastructures and its rugged SSL cousin strikes me as a very good idea! After all, when the wheel works, why reinvent the wheel. So, "bonne chance" to Ravi and SafeMashup. Indeed, there is something truly exciting brewing in San Antonio, Texas.


ABOUT SSL CERTIFICATES

Search

Disclaimer: Opinions expressed here and in any corresponding comments are the personal opinions of the original authors, not of VeriSign.

VeriSign Legal Notices

Read our Privacy Policy