Jan 21, 2008

Security certifications... are we hacker safe?

While looking into the concept of XSS proxies I ran into a somewhat funny, ironic, and insightful article by Jeremiah Grossman on the Hacker Safe certification. As I will let you read his post on your own terms, I would like to express my concern about the ever-growing marketing of the "security tested" or "hacker safe" certification programs.

What is the purpose of such programs?
Let's start off by looking at the foundation upon which such programs are created. As malicious attacks become more and more sophisticated and in large numbers, regular users have voiced a concern about the security of the Internet products that they use on a day-to-day basis. To fill this gap, security vendors have released numerous programs that call for a quick and easy certification of various sites that is intended primarily to wave off users' concerns. These programs work by evaluating the security of a site based on a predefined checklist of security vulnerabilities. If the site is not vulnerable to the vulnerabilities specified in the checklist, then the site is awarded its certification.

What is wrong with this model?
Let's face it, most modern day software applications represent the processes employed in today's business world. As technology evolves, these processes also evolve. Although certifications are great for assessing the knowledge within a body, it fails short for ensuring the security within that body. The simplest example would be a scenario in which version 3.5 of a product tags on to the security certification of version 3.0 of that same product; all being done regardless of the version change. Because version 3.5 introduces new features that may be vulnerable to existing attacks, the end-user, deceived by the certification of version 3.0, may believe that the deployed product is completely secure while in reality it's not.

Although such practice can be caught in stand-alone desktop applications, a major version change in a web application is most likely to be buried inside the source code or the product's documentation.

In the general sense, certifying a product's security should focus on several key points:
  • Scope. Developers and web users are to know exactly what components of an application have undergone testing before the security certification was awarded. Providing such information can protect both the development team and the certification brand when an incident occurs.

  • Lifetime. As software evolves over time, it must be recertified. Certifying a changing product's security demands either strict control over how the product is developed or short-term certifications.

  • Documentation. A product's users should be provided access to a report that contains the above mentioned 2 points including the methodology used in the certification process. This is very important as the user will have the opportunity to verify both his/her trust relationship with the site and the integrity of the certification brand.

Otherwise the result might be as the one here.

No comments: