Random Acts of Architecture

One of the biggest challenges in information security is application security. For example, Microsoft’s Security Intelligence Report estimates that 80% of software security vulnerabilities are in applications and not operating systems or browsers.

Software security has improved significantly over the years. For example, groups like OWASP promote awareness and provide concrete solutions for common issues. Software developer security certifications like the CSSLP have emerged. SANS have an increasing breadth and depth of software security courses.

Nevertheless, libraries and best practice rarely protect a whole application. There may be application-specific vulnerabilities (like poorly implemented business logic or access control) or something libraries and frameworks commonly omit (like denial of service prevention). The issues might be even bigger, like not considering software security at all.

Information security professionals often fill this gap. After all, securing the organization’s IT assets is their role. Information security professionals have a security-first or defender mindset. They are usually the first line of defense against threats and the more they know about the applications they protect, the easier that defense becomes.

However, developers are creators and builders and that different mindset can cause friction. This was apparent at a recent static analysis tool training event. We were given the OWASP WebGoat app (a sample Java web site with dozens of security vulnerabilities), a static analysis tool to find vulnerabilities and instructions to start fixing them.

Two different approaches emerged to solve the first vulnerability found: an HTML injection. The first group searched the web for HTML injection fixes. They read recommendations from OWASP and other well-regarded sources. Most found a Java HTML escaping library, used it in the application then modified the static analysis rules to accept the escaping library as safe.

The second group reviewed the code to see how the application created HTML elsewhere. A few lines above the first instance of HTML injection was a call to an escaping function already in the code. The static analysis tool did not flag this as vulnerable. This group then reused that function throughout the code to remove the vulnerabilities.

Which group’s solution is better? The first approach is more technically correct – escaping strings is actually quite complex. For example, although not required by WebGoat, the escaping method included in the application did not handle HTML attributes correctly.

However, the second approach was much quicker to implement. Search, replace, verify and move on. While not as good a solution as the first group, most of the second group had fixed several vulnerabilities before the first group had fixed one. While not technically as correct as the first, is the second group’s approach good enough?

Perceptive readers would have guessed the first group were the information security professionals and the second were software developers. Information security people want to reduce the frequency and severity of security issues. Software developers quickly understand large bodies of code, find solutions and move on. The training exercise highlighted the defender versus builder mindsets.

The two mindsets are slowly reconciling. For example, OWASP, traditionally very defender oriented, has released its proactive top 10, using terminology familiar to software developers, not just information security professionals. The IT architecture community is also starting to tackle software security issues. For example, security is one of the four groups of International Association of Software Architects‘ quality attributes.

However, many information security professionals look at software like WebGoat as a typical application, full of easily rectified security issues caused by ignorance. Most developers I have worked with write relatively secure code but security is only a small part of writing applications.

Developers need frameworks and libraries where common security vulnerabilities are not possible. For example, escaping libraries are great but if you are constructing HTML or SQL by string concatenation and risking injection attacks, you are doing it wrong in the first place! Use parameterized queries for SQL and data binding for HTML, common in both server- and client-side frameworks.

Meanwhile, addressing security at the requirements and design phases – where real security issues lie – comes in at numbers 9 and 10 in the proactive top 10. As software developers will tell you, the earlier issues are identified and fixed, the cheaper the fixes are. Unfortunately, software security is still too focused on point issues at the end of the development cycle.

In fairness to the OWASP proactive top 10, there are still many developers unfamiliar with secure coding practices. Parameterizing SQL queries (number 1), encoding data (number 2) and input validation (point 3) are relatively cheap and easy to implement. All three will give a big pay off, too.

Addressing security design and requirements is also hard. The people involved usually lack the experience and ability to articulate them. Meanwhile, information security professionals rarely have the skills or access to contribute to early phases of software development. This means software developers must also bare responsibility for software security.

Hopefully we can rise above the distractions of point issues and work together on the bigger issues soon enough. In a world where the hackers (breakers) get the glory, we need to remember that both builders and defenders are the ones keeping the software that we rely on working.