Random Acts of Architecture

Wisdom for the IT professional, focusing on chaos that is IT systems and architecture.

Tag Archives: OWASP

Information Security vs Software Developers: Bridging the Gap

4 Comments Posted by on April 8, 2014

Builder versus Defender

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.

Information Security , , , , , , , , , ,

A Ticket to Security via Obscurity

2 Comments Posted by on November 14, 2012

A group of Australian university students recently “cracked” the “encryption” used by public transport tickets in New South Wales (NSW), Australia. The public transport ticket format’s security relied on people not knowing the format of data on the ticket’s magnetic stripe and not having access to equipment to create tickets. In other words, it relied on “security through obscurity“.

Security through obscurity is not a new concept. In 1883, Auguste Kerckhoff theorised that the only truly secure parts about a system (computerized or otherwise) were the hidden or secret parts. This became known as Kerckhoff’s principle.  Over half a century later, Claude Shannon rephrased it as assume “the enemy knows the system”, called Shannon’s Maxim. These are as true now in computer security, particularly cryptography and encryption,  as they were then.

Ultimately, poor computer security for the public transport ticket system is not the programmers’ or engineers’ fault. The customer and management decided the security provided was sufficient. It is similar to the Year 2000 issue. The programmers knew that two digit years were not going to work after the century changed but why should the manager responsible spend resources to fix it when he or she is unlikely to be around in the year 2000 to take credit for the work?

When people initially approach computer security, they start at cryptography and software security. If we build more secure encryption systems; if we  fix every buffer overflow and every injection attack; if every object has the appropriate authentication, access control, auditing and so on, the “bad guys” will be helpless.

A lot of progress has been made in improving computer security. Organizations like OWASP and SAFECode provide software security guidance for software developers. Many vendors provide frameworks, such as Microsoft’s Security Development Lifecycle, and software patching is a regular occurrence. The US government has FIPS 140-2, a standard for hardware or software that performs cryptography, and Common Criteria is an attempt by multiple governments to provide a framework for software security assurance. A plethora of software security tools are also available with interesting and technical sounding names like “static analysis tools” and “fuzzers”.

That said, computer security practitioners eventually realise it is a matter of economics instead – as Allan Schiffman said in 2004, “amateurs study cryptography; professionals study economics.” It is not that we do not know how to build secure systems. However, if the customer cannot differentiate the security (or quality) of two otherwise seemingly identical products, the cheaper (and likely less secure) product will win. Similarly, most software is sold “as is”, meaning the customer assumes all the risk. See Bruce Schneier’s “Schneier on Security” or “Freakonomics” by Steven D. Livett and Stephen J. Dubner for more discussion.

Others take a different direction and focus on the sociology and behavioural patterns behind security.  Although most people recognise computer security is important, the first reaction of most when confronted with a security warning is to ignore or bypass it. After all, social engineering attacks are behind many of the headline grabbing computer security incidents over the last few years, such as Operation Aurora and Stuxnet. See Bruce Schneier’s “Liars and Outliers” for more discussion.

That said, there is little impetus to improve computer security without people willing to push the boundaries of systems and reveal flaws. Kudos and credit to the students for not only discovering  the public transport ticket format and “encryption” mechanism (if true encryption was actually ever used) but revealing it in a responsible (or “white hat”) manner, such as by allowing the targeted state to reveal itself. Remember that just because the ticket format has been discovered by the students does not mean others have not already done so and used it for less than honest purposes.

Interestingly, the NSW public transport ticket system is approximately 20 years old, introduced when computers were less powerful and less accessible and the required security standards were much lower. I wonder how many systems being built today are going to be considered secure in 20 years time, when computers are going to be presumably exponentially more powerful and more ubiquitous and the security standard much higher.

Information Security , , , , , , , , , , , , , , , , , , , ,

%d bloggers like this: