McKinsey’s view of Government 2.0
Posted by Shahid N. Shah in Government 2.0 on July 27th, 2009
McKinsey & Company, the venerable management consultant firm, has a nice publication called McKinsey Quarterly. Along with Harvard Business Review and MIT Technology Review, McKinsey Quarterly is one of my favorite publications.
Recently the McKinsey Public Sector folks published their E-Government 2.0 article (warning: login required, free article). Here’s the summary:
Despite spending enormous amounts on Web-based initiatives, government agencies often fail to meet users’ needs online. By employing new governance models, investing in Web capabilities, and embracing user participation, agencies can raise the effectiveness of their online presence.
Some key paragraphs include:
During the Internet boom of the late 1990s, government entities raced to develop Web sites, and high levels of e-government spending became the norm. Spending on e-government-related initiatives has continued to grow—indeed, in 2009, the US government is expected to spend more than $71 billion on IT, of which an estimated 10 percent will be related to e-government.1
While the total price tag for e-government services has risen dramatically, these outlays have not yet delivered on the promise of e-government. Public enthusiasm for government Web sites has waned. Americans’ satisfaction with e-government, which rose steadily early in the decade, has started to decline.2 In 2004, Time featured three federal government sites in its list of the “50 coolest Web sites,” while more recent lists contain at most one mention.
Illustrating this trend, one US government agency site was recognized as an innovator in online information and transactions and became a model for other agencies to follow, as it enjoyed user adoption rates that justified its e-government expenditures. However, more recent initiatives have failed to catch on with users, who regard the Web site as having become harder to use and new services as too confusing and complex. Nor is this phenomenon confined to the United States. One government agency invested millions developing a service that enabled citizens to manage their accounts with the government online, only to achieve a disappointing adoption rate of less than 5 percent.
What’s more, data suggest that investments have not yielded major improvements in the operational efficiency of government. A random sample of six US government agencies suggests that administrative costs have increased by 7 to 12 percent per year over the past decade. Nor has public perception of government efficiency improved. According to the Pew Research Center, the percentage of US citizens who agree that “When something is run by the government, it is usually inefficient and wasteful” has increased in recent years, from 53 percent in 2002 to 62 percent in 2007.3
They go on to talk about how the government websites can improve through new governance models and improving web capabilities. It’s a good article to check out.
New open source project management tool for large-scale enterprise systems
Posted by Shahid N. Shah in Methodologies & Frameworks, Project Management on July 21st, 2009
I just ran across the new Endeavour Software Project Management solution; it seems to be a pretty feature-packed web-based open source package to manage the creation of large-scale enterprise systems. Unlike most large project management solutions that assume waterfall approaches, Endeavour’s designers understand that most modern applications are developed in an iterative and incremental development process and it supports agile processes by providing administration for software process artifacts, reports and collaboration among many different stakeholders.
It’s still quite rough around the edges but I think it’s a great start.
Federated Vulnerability Management
Posted by Shahid N. Shah in Vulnerability Management on July 15th, 2009
The Guerilla CISO blog recently posted a very interesting proposal on Federated Vulnerability Management. I think it’s a fantastic idea that should be seriously considered. If we use modern linked open data through some secure network channels I think we could make this happen without writing much code and getting all the agency data we need through RESTful mashup technologies. We wouldn’t need any centralized servers and could really do it in a decentralized but fully federated and integrated way.
For architects, the relevant paragraph from the posting was the following:
Security architecture models (FEA anyone?) that show federated patch and vulnerability management deployments as part of their standard configuration. OK with the firewall pictures and zones of trust, I understand what you’re saying, now give me patch and vulnerability management flows across all the zones so I can do the other 85% of my job.
A Radical New Approach to (MUTUAL) Authentication
Posted by Eashwar Ganapathy in Uncategorized on May 19th, 2009
[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]
Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy
Abstract In this article, we present a fundamentally new identity framework – RELATIVE IDENTITY - which addresses and eliminates many of the core problems faced by the current identity technologies. We postulate that authentication necessarily has to be mutual and that the only valid way to perform mutual authentication is to make fundamental changes to the identity representation framework.
This can be accomplished by –
- Changing from end-point entity labeling (like in the case of login/password, biometric, digital certificates, 2-Way SSL and a combination of these) – to labeling the relationship between the end-point entities (which inherently covers the two end-points in its definition)
- Making the authentication protocol truly mutual – and thereby eliminating the susceptibility to man-in-the-middle attacks and phishing
Identity and identification are central to any interaction, both in real and virtual (digital) systems. Especially where the interaction entails access to or manipulation of protected resource(s).
We firmly believe that any identity framework has to address the problem of establishing a mutually-authenticated secure connection BEFORE initiating any data transaction using that connection.
Introduction Identity and Authentication form the central building block of any information security solution/framework. Establishing identity using an authentication protocol is the starting point for any secure transaction. In order to be able to establish identity (be it man or machine), the entity must be characterized by a unique set of symbols (as per the adopted identity representation framework). During the process of actually identifying / authenticating the entity, the same characteristics of the entity are observed and matched against those that were captured earlier and associated with the entity.
The act of establishing identity is identification. Identity Systems must possess the capability represent, provide, maintain and establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual identities it is used to represent. In this article we cover the following points:
- Definition of RELative IDentity – the representation
- Fundamental properties of identity (representation)
- Proof that all authentication must necessarily be mutual ( that 1-way authentication basically flawed)
- Fundamental properties of authentication / identification (the process of)
- How is Relative Identity different from other identity schemes
The basic flaws and limitations in current identity technologies for websites prevalent in the World Wide Web SSL/Digital Certificates (when used for AUTHENTICATION) become apparent in the context of the axiomatic frame of reference defined in the following sections.
Definition of Relative Identity The relative identity of an entity is
- Distributed among the relationship of this entity with other entities. Each such valid relationship –
- constitutes a unit “Relative Identity” – an important and inseparable constituent of the identities of each of the entities sharing a valid relationship
- contributes in the definition of the relative identity of each entity
- exists only in the context of two (or more) entities who share a relationship
- Is the union/collection of all such “Relative Identities”
- Is dynamic since new relationships may be established, while old relationships may be discarded, over time
- Is associated with a set of labels/attributes/characteristics – immutable and mutable
- immutable - such as biometrics, which cannot be changed at will
- mutable - such as SSN which are awarded for a life time, log in passwords, bank account numbers which are changed quite often
In practical implementations of identity based transactions, one is concerned only with the specific (relevant) relative identity and associated attributes, and hence the rest of the identity representation is not susceptible to identity theft.
As is evident from the above definition, the concept of identity in the prevalent conventional identity systems that deal with only labels/attributes/characteristics – “What you have”, “What you know” and “What you are”, totally ignore the most relevant concept of “Who you know” – which is how humans establish trusted relationships.
Fundamental Properties of Relative Identity
The unit relative-identity data -
- must be unique (no two relative-identities should have the same identity data)
- must be tamper-proof (difficult to reconstruct and reproduce)
- must be secret - wholly / partially (should not be communicated in full form during authentication; should be known only to the related entities)
- must be used simultaneously and uniquely, to identity all entities involved in the authentication transaction
Most of the prevalent conventional identity systems satisfy properties 1, 2 and 3 above. For example -
- Login/Password would satisfy 1, 2 (partially) and 3 (partially)
- Digital Certificates would satisfy 1, 2 and 3 (partially)
What is Mutual Authentication/Identification? Why does one need it?
As yourself the following questions -
- what is the meaning of authentication if it is not mutual?
- why would I allow someone to authenticate me, if I can’t authenticate him/her?
- would I produce my passport to identify myself to someone who does not (even seemingly) possess the requisite authority?
- Even so, don’t I run the risk of being duped into producing my passport to a person who only looks authentically like he/she has the requisite authority?
The basic flaw in identification over the internet is that an end-user assumes that the website challenging him/her for his/her credentials is indeed the authentic site – so long as interaction with the user-agent application (the web-browser) while accessing the website, is identical to previous such interactions. That is to say – so long as the website looks the same, behaves the same, and does not trigger a negative message from installed security products (due to more recent efforts in the anti-phishing features of these products).
All things considered, are you sure you can trust such a website that asks for your login credentials?
Conclusion: Authentication, to be of any practical use, MUST BE MUTUAL
Fundamental properties of authentication / identification
The process for identification / authentication
- must be tightly integrated with a given/underlying identity representation
- must necessarily have a priori access to the identity data that is to be identified / authenticated
- must necessarily authenticate all identifying/authenticating parties (entities) – preferably simultaneously
These are simple (minimal) properties that any identity/authentication system must possess. Some of them are straightforward while some may not be seem obvious.
Let us now visit some of the prevalent identification/authentication processes in light of the above properties -
- Login/Password – satisfies 1 and 2 above
- Digital Certifications/SSL – does not satisfy 2 and 3, and hence, should NOT be used for authentication
- Hardware/Software Tokens (and OTPs) – satisfy 1 and 2 but do not satisfy 3
Please note that even the use of multi-factors satisfy only properties 1 and 2 and not the property 3
Let us look at the third property above for authentication protocols that essentially says that - the process MUST be mutual and simultaneous. The term mutual has earlier been defined in the context of client-server architecture as “client must authenticate the server and the server must authenticate the client”. Such a definition classifies any “1-way” authentication method executed twice as a valid 2-WAY or mutual authentication process. The fundamental flaws in existing mutual and 1-Way authentication systems are precisely due to the violation of properties (2) and (3) above.
Mutual authentication cannot and should not be implemented using two 1-WAY authentication schemes – e.g. 2-Way SSL, or a combination of login/password and shared secrets/site-key. Any such scheme will be vulnerable to the same attacks that the 1-WAY equivalent is vulnerable to. For example, 2-WAY SSL is susceptible to MITM (man-in-the-middle) in exactly the same way that 1-WAY SSL is - for the same reasons.
How is Relative Identity different from other identity schemes?
Conventionally, identity is associated with the end-point entities (client or server) and authentication involved authenticating the end-points. Authenticating this information for both end-points in sequence is NOT secure mutual authentication – it is a concatenation of 2 instances of 1-WAY authentication.
The REL-ID (relative identity) approach to authentication is to identify and authenticate the ‘link/relationship’ between the end-point entities – not the individual end-points. That is to say – IDENTITY must necessarily be associated with the ‘link’ representing the relationship between the end-points. This is the only representation, and authentication thereof, that can legitimately be termed as MUTUAL – as the end-points are an integral part of the definition of any such representation.
Authenticating such a ‘link’ would necessarily be mutual – would ensure that all end-points are authenticated simultaneously, and makes the identity of every end-point relative to the other end-point(s) axiomatically.
Conventional Identity System
Relative-Identity System
We believe that, in order to (a) represent the above information correctly at the end-points and (b) arrive at the correct protocols for identification/authentication, one must develop the necessary mathematical frameworks and algorithms. However, before starting to derive them, one must accept and acknowledge the fundamental paradigm shift in the desired properties of such representations and algorithms.
The set of identity representations and identification/authentication algorithms constituting the REL-ID© Security Suite is one such implementation of the identity paradigm described here. Assuming that authentication must necessarily be mutual and simultaneous to be of any value, authentication schemes such as tokens, digital-certificates/SSL, login/password… cannot be compared with REL-ID – since they offer only 1-WAY authentication, at best. Furthermore, methods/products that claim to provide mutual authentication, but in reality implement two 1-WAY authentications (like SITE-KEY – flash-persistent object; Shared Secrets…), will remain vulnerable to man-in-the-middle attacks due to the inherent vulnerability in the conventional end-point identity representation scheme.
There are no known contemporary technologies/products that are built using mutual authentication protocols, which have the properties mentioned in this article, and which are available commercially.
2-WAY SSL == TWICE PHISHED
Posted by Eashwar Ganapathy in Uncategorized on May 18th, 2009
[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]
Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy
Basics of Identity and Authentication - In order to be able to identify / authenticate any entity (be it man or machine), the entity must be characterized by a unique set of symbols, as per the adopted representation scheme. During the process of actually identifying / authenticating the entity, these characteristics are observed and matched against those that were captured earlier and associated with the entity.
The act of establishing identity is identification. An Identity System must be able to represent, provide, maintain and establish identity. The identity representation framework must ensure that it is extremely difficult to compromise the individual identities it deals with. Identity and identification are central to any interaction, both in real and virtual (digital) systems, typically where the interaction entails access to or manipulation of protected resource(s).
For example, we are identified by our name, social security number, passport number, national ID card, fingerprint, voice print, DNA print etc. The context of identification determines the parameters used to determine the identity. While establishing our identity, one or more of these characteristics are elicited / captured from us, and matched against previously captured and stored characteristics.
Let’s take a look at prevalent IDENTITY TECHNOLOGIES
- Login-Password The login-password is captured and stored A PRIORI with the server and then compared with the login-password that is presented before subsequent interactions with the login-password-secured system.
- Biometrics (fingerprint/voice/DNA/iris-scan) The biometric is captured and stored A PRIORI and then compared with the biometric data that is presented before subsequent interactions with the biometric-secured system.
- Photo-ID Cards After verifying that the Photo-ID Card is authentic using a system with a card-reader, the PHOTO on the ID-CARD is matched with the individuals face as well as the system-retrieved photo expected to be on the card.
Note that AUTHENTICATION NEEDS A PRIORI INFORMATION.
PKI, Digital Certificates, SSL and Authentication - PUBLIC KEY CRYPTOGRAPHY, aka Asymmetric Cryptography, is a form of cryptography in which the key used to encrypt a message differes from the key used to decrypt it; the user has a pair of keys - a public key and private key. The private key is kept secret, while the public key may be widely distributed. The keys are related mathematically, but the private key cannot be computationally derived from the public key in ‘reasonable’ time, and vice versa. Messages encrypted with the public key can only be decrypted with the corresponding private key and vice versa. Further, in conjunction with a signing algorithm and a signature-verification algorithm the key pair can be used to send verifiably signed messages
The two main branches of public key cryptography are -
- Public Key Encryption - A message encrypted with a recipient’s public key cannot be decrypted by anyone but the recipient (using his/her corresponding private key). This ensures confidentiality of messages thus encrypted. An analogy for public-key encryption is that of a locked mail slot. The mail slot is exposed and accessible to the public - its location (the postal address) is, in essence, the public key. Anyone who knows the location can go to the door and drop a message through the slot. However, only the person who possesses the key can open the mailbox and read the messages.
- Digital Signatures - A signing algorithm, given a message and the private key, produces the signature. And a signature verification algorithm, given a message, its signature and the correct public key, can verify that the message has not been modified with since signing (generation of the signature). This ensures non-repudiation of the message thus sent. An analogy for digital signatures is the sealing of an envelope with a personal wax seal. The recipient checks that the seal is intact and corresponds to that of the sender, before opening the message.
A central problem in public-key cryptography is proving that a public key, which is publicly available, is authentic, and has not been tampered with, or replaced, by a malicious 3rd party. This problem is solved by using a Public Key Infrastructure (PKI), in which one or more 3rd parties, called Certificate Authorities (CA), certify ownership of key pairs. Another approach, used by PGP, is the ‘web of trust‘ method to ensure authenticity of key pairs.
In PKI, a public key certificate (or digital certificate) is an electronic document which incorporates a digital signature to bind together a public key with an identity - information such as the name of a person or organization, their address… The certificate can be used to verify that a public key belongs to an entity. In practice this verification entails verifying that the digital signatures in the certificate were indeed generated using the correct private keys. In a typical PKI scheme, the signature is generated by a Certifying Authority (CA). In a web of trust scheme, the signature is either from the owner (a self-signed certificate) or another user (’endorsements’). In either case, the signatures on a certificate are attestations by the certificate signer that the information in the certificate and the public key belong together.
Why do websites face PHISHING attacks even after adopting DIGITAL CERTIFICATES and SSL technology? What exactly is wrong with DIGITAL CERTIFICATES?
In the 1990’s the DIGITAL CERTIFICATE technology was introduced by VERISIGN bundled with NETSCAPE. The idea was to issue certificates to entities requesting one from VERISIGN. This technology was based on the PKI scheme (made popular by RSA in the 1980’s). The term Certificate Authority was born and VERISIGN became the first such CA. Eventually other entities could become CAs by purchasing special certificates from VERISIGN or other CA’s and a CA chain came in to existence. The browser technology then invented by NETSCAPE incorporated the certificate technology and along with the SSL protocol became the de facto standard for SECURE INTERNET TRANSACTIONS. Since then this technology, that has been assumed to secure the internet transactions, went on to become a regulatory requirement for most institutions world-over.
Quite frequently, due to evolution, and at times mass acceptance of a technology, the industry seems to overlook some basic but extremely FUNDAMENTAL aspects of technology. Such ignorance (though unintentional) leads to serious security flaws – flaws that are exploited by fraudsters.
DIGITAL CERTIFICATES ARE VERIFIED NOT IDENTIFIED (or AUTHENTICATED) SINCE THERE IS NO DIRECT A PRIORI KNOWLEDGE ABOUT THE CERTIFICATE WITH THE VERIFYING PARTY / PROGRAM.
The Secure Sockets Layer (SSL) and the Transport Layer Security (TLS) protocols use DIGITAL CERTIFICATES to establish a secure connection between a SERVER and a CLIENT. They are MEMORY-LESS protocols – they were designed to be so in order to make existing and newly developed web applications integrate with them seamlessly - for seamless interoperability. Both protocols are based on CERTIFICATE VERIFICATION. This proves to be a fundamental, subtle and yet non-trivial loophole when used for AUTHENTICATION – there is NO A PRIORI knowledge about the CLIENT or SERVER side certificates available at the verifying side of the connection, during the protocol exchange. A priori knowledge is a fundamental requirement for any AUTHENTICATION PROTOCOL, be it 1-WAY or 2-WAY.
Although the SERVER has a DIGITAL CERTIFICATE which is used to establish a secure SSL connection with the CLIENT – the CLIENT does not have any A PRIORI knowledge of this CERTIFICATE (public key). The SSL protocol only VERIFIES that the CERTIFICATE IS VALID and was issued by the valid CA (as per the contents of the certificate). The equivalent in real life would be to accept an ID card as valid simply because the card has not been tampered with – although the person carrying the card may not be the same person you are trying to authenticate.
Due to this flaw – any application can claim to be the “right or authentic” SERVER to a CLIENT as long as it has a VALID certificate - the same argument can be extended if one is using a CLIENT CERTIFICATE as well (in case of 2-WAY SSL). If 1-WAY SSL protocol is a VERIFICATION protocol – how can 2-WAY SSL protocol claim to eliminate the fundamental issues of AUTHENTICATION – since a 2-WAY SSL PROTOCOL is equivalent to 2 instances of the same 1-WAY SSL VERIFICATION PROTOCOL implemented on both CLIENT and SERVER side.
Have we missed something when it comes to using certificate technology as an identity system for IDENTIFYING WEBSITES?
As per the SSL Protocol, the client confirms that the CERTIFICATE produced by the server is VALID – that the contents of the certificate have not been tampered with, and that the domain name in the certificate indeed is the same as the domain name to which you are currently connected. That is to say, a CERTIFICATE can only be VERIFIED to the extent of the claims made on it – that it belongs to the ENTITY that has presented the CERTIFICATE. However, the client cannot confirm whether it is the SAME ENTITY that the USER is trying to connect to.
A fraudster gets a CERTIFICATE issued to himself/herself, with a domain name that sounds or looks similar, and presents the CERTIFICATE to the user – the SSL/HTTPS layer will NOT be able to tell you whether the USER is indeed connected to the website he/she wants to connect to. This loophole is not addressed and cannot be addressed in the way the DIGITAL CERTIFICATE TECHNOLOGY and SSL are implemented in the internet today.
Is it possible to correct the present system of DIGITAL CERTIFICATES?
No. Since it would mean a sea change in the entire process of creating, issuing, distributing and identifying the certificates.
If one has implemented the DIGITIAL CERTIFICATE Technology, does that mean their IDENTITY cannot be compromised?
Well, one can make their own educated judgment based on the arguments presented in this article.
According to us, ONCE the IDENTITY has been confirmed, the CERTIFICATE technology could be used to exchange encryption keys, and secure the transaction – IT SHOULD NOT BE USED TO ESTABLISH or AUTHENTICATE THE IDENTITY.
Why not?
The reason why DIGITAL CERTIFICATE TECHNOLOGY is what it is today is because of the fundamental nature of ‘online applications’. Digital Certificates themselves are tools to ensure that a given datum communicated from one end to the other is not tampered with and is ‘signed’ using the private secret corresponding to the publicly available ‘certificate’. The use of digital certificate technology between an all-purpose web-browser and any specific security-critical application can at best be described as a marriage of convenience – essentially because online applications came first!
Conclusions
- The fundamental tenet of ‘securing’ any application is to uniquely, unambiguously and reliably identify the user of the application before authorizing and executing any action on the identified user’s behalf.
- Furthermore, any centralized and fully automated ‘trust-building mechanism’ for capturing, storing and verifying the trust between ‘essentially anonymous entities’ across wide spectra of businesses and geographies will come with inherent weaknesses – they will be as secure as the weakest link in the security chain built around it.
Website Identity - the root cause for Internet Fraud
Posted by Eashwar Ganapathy in Uncategorized on May 14th, 2009
[This thought paper is from Rel-ID Technologies Inc. - a Uniken venture]
Authors Sanjay Deshpande, Dr. Pat Shankar, Eashwar Ganapathy
Abstract On the internet there are 2 types of websites - ones that take sensitive information from you and ones that don’t. Online banking applications, shopping applications, stock-trading applications are examples of the former; while CNN, Google etc are examples of the latter. This article deals with the very real insecurities of working with applications of the former variety.
How do you know that you are at an authentic website? What if you are not?
Authenticating a website implicitly assumes you already know what to look for in the website, in order to establish the websites identity - which in turn implicitly assumes you know what constitutes the identity of a website. Let us define WEBSITE IDENTITY to be a set of identifiers that can be authenticated to prove the identity of the website. Currently, there are only 3 identifiers that constitute WEBSITE IDENTITY - (1) URL, (2) CONTENT, and (3) SSL/TLS CERTIFICATE. Furthermore, let us note that - any kind of authentication of any identity mandatorily requires a priori knowledge of the identity information.
In this article we shall delve deeper into the above constituents of WEBSITE IDENTITY, and conclusively prove that they are fundamentally incomplete, leaving you - the internet-user, at the mercy of fraudsters who use this knowledge to their benefits, by sending fraudulent emails with links to similar looking websites.
The Website URL - when one sets up a website the first thing one does is to register the domain name (www.mywebsite.com) - that is the primary identifier for the website. More often than not, this is the ONLY identifier - for first-time visitors.
Let us say the website’s domain name is communicated to you by the owner of the website directly/indirectly through trusted channels. In this case, since the identity information for the website has been communicated from a trusted source, the problem of authenticating the website reduces to authenticating the identifier - ensuring that the website you are visiting is authentic.
What if the website’s domain name is communicated to you through channels that you cannot necessarily trust - the first question that arises is how would you know for sure that this identifier indeed belongs to the correct website.
For example, let us assume you are a customer of Bank of America. How would you know for sure that www.bankofamerica.com is the correct website if it has not been communicated to you by the bank? What if someone told you or you searched on the internet and got the website name to be www.boa.com instead, what would you do?
Do you know how to confirm the ownership of a given URL/Domain Name before using it? Further, even if the OWNER (let’s say the bank in this case) told you what to check (assuming there was a way to get this information) - if you have not received the information from a TRUSTED source, how do you verify that the information is correct?
NOTE that the DOMAIN REGISTRATION entities (companies that issue the domain name) do not verify the information provided by the individual who is registering the domain (website address).
NOTE that there is no central TRUSTED repository where you can find the WEBSITE NAME for a given OWNER. There are services like www.who.is – that give you information about who has registered the DOMAIN. However, since the domain registration entities do not authenticate or validate the owner of the website name – which means any one can register any name and own it – what use is this information anyway!
Website Content - Let us move on to the next identifier of the website – the content. Most users confirm the authenticity of the website based on just the visual cues and verifying the visual cues every time they visit the website.
The very nature of HTTP and HTML (the protocol and language used to retrieve and render website content, respectively) allows one to stream information/content from multiple sources. Which means, even if the visual cues are the same, how do you confirm the validity of the content - what if someone has tampered the content and/or it is being served from somewhere else? Further, if you are visiting the website for the first time – and the owner has NEVER communicated what the website should look like in the first place, how would you authenticate the website’s content?
The website content – the HTML document - is available for any one to view, copy and save. It is a trivial task to scrape content off an authentic website (using a browser or wget or website copiers such as HTTrack etc), register a similar (but not identical) website, and put up the same content there - a COUNTERFEIT WEBSITE.
Let us say there are 2 URLs A and B that are displaying contents Ca and Cb - each implying that the website belongs to the same company X. If the company X has not communicated the correct URL(s) to its users - how would you confirm that the URL you are browsing (A/B) indeed belongs to the company X? If you conclude incorrectly, you could end up providing valuable information to a counterfeit / fraudulent website!
Digital Certificates - By far the most popular method of registering, certifying and verifying identity on internet.
The anti-trust laws in this part of the business world are laughable - to become a valid certification authority one just has to be affiliated to the company called VERISIGN directly or indirectly - isn’t this a fundamental violation of the anti-trust laws? VERISIGN (www.verisign.com) is neither a government nor an international body.
If you navigate to www.patentoffice.nic.in, the official website of India’s Patent Office and visit their e-filing section, most browsers say this could be a fraudulent website - because the certificate is not issued by VERISIGN or any of its affiliated certification authorities (it is issued by a company called NCODE SOLUTIONS - one of the valid root certificate authorities in India). Not just that, the address-bar turns RED.
Who decided that one has to trust VERISIGN? And why does that mean one has to trust all certification authorities certified by VERISIGN? Most consumers do not even know VERISIGN - MicroSoft, maybe, but not VERISIGN. In their defence - given the fundamental flaw with the Certification Authority scheme - there really was no solution but to pick up a bunch of ‘root CAs’ and declare them as the TRUSTED AUTHORITY.
An end-user has no A PRIORI knowledge of the certificate issued to an entity. The transaction (or act) of getting a certificate is a private transaction between the entity (for eg. a bank) and the CA (Certification Authority). This information is never distributed to the end-user and he/she in turn is in no way equipped to verify this information. How can a 3rd party (the CA) vouch for the authenticity of an entity to the end-user? Does it make sense for a child to ask a visitor (a stranger) to vouch for the authenticity of his/her mother? But that is what it is. Why is there a necessity for a 3rd party like VERISIGN (or its derivative CAs) to verify the identity between 2 parties who already share a primary relationship (like bank-customer or enterprise-employee …)?
The original premise of the SSL protocol (that uses these certificates) was to establish an encrypted communication channel between two UNTRUSTED parties. What completely defies logic is - what good would an encrypted channel be between two UNTRUSTED parties?!
Banks and other e-commerce websites boldly declare that they are secure - they have SSL/TLS enabled websites. What good is it when the user does not know what to verify? He/She does not have a-priori knowledge of the information that should be present in the website’s certificate - such as the signed content, the public-key in use etc.
The CA infrastructure and the current SSL protocol violate the basic principles of IDENTITY and AUTHENTICATION - that IDENTITY must be established first and then verified between 2 (now) trusted parties - using information shared during IDENTITY ESTABLISHMENT.
The above discussion conclusively proves that the three primary identifiers – WEBSITE URL, CONTENT and (optionally) PKI-based CERTIFICATES are incomplete as website identifiers. They leave the user at the mercy of fraudsters who use this knowledge to their benefit - sending fraudulent emails with links of similar looking counterfeit websites, luring the ignorant users to divulge sensitive information to the wrong websites.
Security Guidance for Critical Areas of Focus in Cloud Computing
Posted by Shahid N. Shah in Cloud Computing, Information Assurance on May 7th, 2009
The Cloud Security Alliance was recently formed to “promote the use of best practices for providing security assurance within Cloud Computing, and provide education on the uses of Cloud Computing to help secure all other forms of computing.” Their first publication is out and is worth reviewing.
Managing FISMA compliance with OpenFISMA tool
Posted by Shahid N. Shah in Government 2.0, Information Assurance, Tools on May 4th, 2009
As architects working on federal projects we spend a ton of time on security practices and FISMA compliance. Implementing FISMA guidelines involves lots of manual tracking of dozens of steps and checks across various groups. I was pleased to run across OpenFISMA recently because it helps automate some of the manual steps in FISMA compliance by using a LAMP-based application to manage the process. OpenFISMA also guides requirements-gathering activities, such as verifying compliance with requirements, security assessments and vulnerability remediation. Here’s the description of the tool from their website:
The OpenFISMA project is an open source application designed to reduce the complexity and automate the regulatory requirements of the Federal Information Security Management Act (FISMA) and the National Institute of Standards and Technology (NIST) Risk Management Framework (RMF).
OpenFISMA contains many of the NIST SP 800-53 security controls required for a FIPS-199 "high" impact information system. This helps you get your OpenFISMA instance authorized to operate quickly. The built-in controls include system use notification, rules of behavior, electronic privacy policy (p3p), and many, many more.
OpenFISMA also contains a catalog of all NIST SP 800-53 Rev. 2 controls built-in. Findings in OpenFISMA can be matched against these security controls to provide supplemental information for remediation and planning. The catalog includes descriptions of the controls, scoping, and supplemental guidance.
Google Embarks on Public Data Search
Posted by Shahid N. Shah in Government 2.0 on May 2nd, 2009
Google says it’s going to make public government data searchable and is going to allow the general population to visualize the data. Starting with population and unemployment data, it says more is on the way. This is similar to the vision that Vivek Kundra has with his concept of data.gov — it will be interesting to see which one the public uses more and which data set Google puts higher in search results.
PKI (HSPD-12) for controlling access to your web applications
Posted by Shahid N. Shah in Tools on May 1st, 2009
If you’re looking for a quick and easy way to allow web applications to use your PIV cards and allow more thin-client solutions be HSPD-12 compliant, check out the Public Key Infrastructure Framework (PKIF) and WebCullis projects.
What’s slick about WebCullis is that it’s an IIS- and Apache-compatible web module that makes most of the process transparent. Here’s what the developers say about the projects, verbatim from their website:
PKIF provides a variety of capabilities useful in enabling applications, including:
- Certification path building and discovery compatible with the DoD PKI and the Federal bridged environments.
- RFC 5280-compliant path validation.
- Supports RFC 3852 (Cryptographic Message Syntax).
- Supports RFC 3161 (Timestamp protocol).
- New Supports RFC 5055 (SCVP) and RFC 4998 (ERS) along with RFC 5276 (SCVP/ERS wantBacks)
- wxWidgets-based cross-platform GUI controls.
- Enabling applications is simple.
- Multiple certificate sources are supported, including LDAP-accessible directories, web servers, CAPI certificate stores, NSS certificate stores and other application-specified sources.
- Can retrieve revocation information from local stores, application-specified sources (such as an LDAP directory) and follow CRL distribution points.
- Can use OCSP responders specified in AIA extensions.
- One or more trusted OCSP responder(s) may be configured for path validation.
- Configurable to make the most of your infrastructure.
- Configurations can be created centrally and pushed out using your existing management tools.
- Much more. See the online developer’s reference for details.
Webcullis provides a simple, secure and flexible solution for integrating your PKI and your web aplications. Webcullis Feature:
- Certification path building and discovery compatible with the DoD PKI and the Federal bridged environments.
- RFC 3280-compliant path validation
- Cached validations to reduce server load for multiple requests
- Simple configuration syntax
- Access restrictions may be based on: Name constraints, Key Size, Extended Key Usage, Policy Constraints or Quality of revocation information
- Allows the use of one or more LDAP directories for path building
- One or more trusted OCSP responders may be configured for path validation
- Webcullis trust roots are separate from the system trust roots, enabling server-side work-arounds for client-side bugs.
- Access to resources may be controlled without configuring cumbersome mappings between certificates and system accounts on IIS.
-
Who's Blogging Here
The founder of this blog is Shahid N. Shah, CEO of Netspective. Please help continue our conversations by commenting on any posts. If you'd like join and start blogging, just create an account and begin sharing your thoughts immediately.
Recent Comments