Neohapsis Labs

How do you protect sensitive data and networks?  The approach you take tends to depend a lot on “size.”  For most organizations, their “size” is simply measured by sales and revenue.  For organizations processing credit cards, the “size” can be defined by the number of credit card transactions they process.  No matter what measuring stick one uses, the larger the “size” of a corporation, the more information and assets it has to protect.

The size of an entity makes decisions around what to protect become more complicated.  Most small organizations know the assets and information they need to protect, but often simply aren’t aware of  – or simply disregard – regulations specifying minimum security controls that must be in place (e.g. PCI requirements).  Large corporations tend to have the opposite problem.  They most often are well aware of the regulations that apply to them, but don’t have a clue how to strategically plan around complying with such regulations or requirements.

In a large and/or complex environment, the information and assets of an entity become exponentially more difficult to protect.  New regulations and/or requirements stipulate compliance to specific security requirements.  For large organizations and corporations that “grew up” without these stipulations, bringing themselves into compliance can be a very daunting task.  One good example is identity management.  Compliance to section 404 of Sarbanes-Oxley in the context of user provisioning, authentication, and access control can be extremely difficult for large organizations.  Legacy systems, lack of a standardized password policy, customized provisioning systems, and inefficient (yet heavily utilized) manual processes are only a few of the major challenges that an enterprise may face.

Another good example is PCI compliance.  Large organizations are charged with implementation of very specific controls to protect credit card data.  For a large enterprise that evolved without these requirements, this can be a major challenge.   Even determining where all the credit card data resides is often a herculean task, let alone architecting and implementing controls to bring the corporation into compliance.

Smaller companies face different sets of challenges.  In the case of PCI requirements, many smaller corporations are often out of PCI compliance and don’t even know it until they get a threatening letter in the mail from one of the major credit payment brands.  Once they get such a letter, it turns into a scramble to  a) figure out what PCI compliance actually is b) figure out how to comply and c) implement the controls to ensure compliance.  The smaller corporation may have an easier time determining PCI in-scope systems and environments, but often faces issues that a large corporation enterprises aren’t as concerned with.  These issues almost always involve budget and resource constraints.

Bottom line, the challenges an entity faces when attempting to protect their data and networks depends a lot on size – regardless of how it’s measured.  Larger corporations have more resources to direct at securing their data, but may have a much more difficult time implementing solutions.  Smaller organizations are much more agile, but often simply don’t have the knowledge or resources to get the job done.



The PCI Security Council on April 15, released clarification on DSS requirement 6.6.

Requirement 6.6 states that all web facing applications are protected against known attacks by having a code review or installing an application-layer firewall (WAP) in front of the web application.

I am of the opinion that the clarification document for requirement 6.6 still does not address the issue adequately, and leaves mis-interpretations about code review and WAP.

Let’s start off with observation #1.

From the Information Supplement: Requirement 6.6 Code Reviews and Application Firewalls Clarified document:

“Manual reviews/assessments may be performed by a qualified internal resource or aqualified third party. In all cases, the individual(s) must have the proper skills andexperience to understand the source code and/or web application, know how to evaluate each for vulnerabilities, and understand the findings. Similarly, individuals using automated tools must have the skills and knowledge to properly configure the tool andtest environment, use the tool, and evaluate the results. If internal resources are being used, they should be organizationally separate from the management of the application being tested. For example, the team writing the software should not perform the final review or assessment and verify the code is secure.”

What qualifies a qualified internal resource? Does the QSA qualify this internal resource?

There currently is no standard certification in our industry for code review, and in my experience, very few organizations have any staff that could perform adequate code review if the focus is on identifying security relevant issues.

Scenario 1: Development team uses someone from the IT/QA group to run a web application vulnerability scanner against their web application.

Does this meet Requirement 6.6?
Absolutely not.

Web application vulnerability scanners do not find all vulnerabilities, in addition, they throw out a lot of false positives.. Here at Neohapsis we have seen that and so have others, Rolling review: Web Application Scanners.

“Ultimately, you can’t automate your way to secure software–any combination of analysis tools is only as effective as the security knowledge of the user. As Michael Howard, co-author of Writing Secure Code (Microsoft Press, 2002) and one of the lead architects of Microsoft’s current security posture, put it in his blog: “Not-so-knowledgeable-developer + great tools = marginally more secure code.”

We recommend taking advantage of documented processes, including Microsoft’s SDL (Security Development Lifecycle), The Open Web Application Security Project’s CLASP (Comprehensive Lightweight Application Security Process) and general techniques available at the National Cyber Security Division’s “Build Security In” portal (“Automated Code Scanners.” Network Computing Magazine, April 16, 2006).

Web application vulnerability scanners should be used as a tool in conjunction with a full code review.

Observation #2: Option #2 in Requirement 6.6.

I find this to be the band-aid approach to passing 6.6. Web application firewalls, WAF, should be used as an additional layer of security, not a band-aid and avoiding code reviews. Would we consider an IDS or a firewall to be the resolution to running unnecessary services on a system, or a solution to avoid us from hardening or configuring systems to best practice of vendor recommended guidelines? Similarly, WAF’s are another step in the principle of Defense-in-Depth (DiD), but are in no means a solution to securing an application.

There needs to be a balance found with Requirement 6.6 to include source code review, using a web application vulnerability scanner as a tool, and a WAP for it to be taken seriously. There are ways to do this. If an organization implements a solid SDL process, you only need to do sample source code review during the development phase, since a lot of the initial threats were identified during the threat analysis phase. Also, you have secure coding practices and modules that already address a lot of issues such as poor input validation etc. If one is looking to spend less time on finding security issues after a production / environment has to be deployed, one has to look at security right from the start. This holds true when you are building out a security network or DMZ, and also holds true when it comes to the design and development of an application.

The bottom line is that the clarification does not really help out overall.

PCI or not, a proper SDLC implementation and process, developers going through secure code training, and having a proper set of tools will lead to a more secure application.