Here is an extract of the of interview I did with Stephen Northcutt in June 11th 2007 (see full version here):
1) On the video of you at Blackhat 2006[4] you were saying that vendors wanted to avoid standards since it takes away some of the differentiation of their products. Now that you are working for a vendor, what do you feel and what is the most promising standards effort in the industry for software security?
Well, I still strongly believe that we need industry wide standards, and I think that the most promising efforts are currently happening at OWASP, WASC[5] and CVE[6]. Ultimately, all vendors must stop reinventing the wheel and use common ways to describe vulnerabilities, exploits, remediation techniques, etc…
What clients (and users) want are solutions for their problems that are cost effective, open, reliable and (very important) secure. The world that most software companies (and several open source projects) live in - which is based on complex, interconnected and opaque blocks - will not last for much longer.
The problem is that the customers are still okay with the low quality software products (both commercial and Open Source) that they use on critical systems, and the fact that the attacker’s business model has not evolved where they make money exploiting those environments. We are still in a phase where software vendors really get away with murder and ironically, from a security point of view, Microsoft is becoming one of the least offenders.
2) What can you share about the web app security market segment, growing, shrinking, becoming more sophisticated? How would you describe the typical customer for the Ounce Labs product mix?
I usually view the web application security market in five big blocks:
- black-box testers (SPI Dynamics, Cenzic)
- white-box testers (Ounce Labs, Fortify)
- grey-box testers (security consulting companies like IOActive or Foundstone)
- Web Application Firewalls (Breach, Imperva)
- Security Products (SSL accelerators, Anti-Virus, IPS, IDS, etc.)
I think some of those markets are growing and some are shrinking. Not coincidentally, the one that I believe is just about to explode is the source code scanning tools (the white-box testers) since the potential to add real value to the end consumer is enormous, and the new generation of these tools will make such a positive difference that they will become a vital tool for developers and security consultants.
Regarding the typical Ounce Labs customers, they usually fall into two categories. There are the ones who just want to run the tool in their code base to see how bad it is and give the results to the developers (or security consultants), and then there are the security consultants (or security focused developers) who use the tool to become more productive and to be able to efficiently cover the entire code base of the application being tested.
We usually call the first group the "Big Red Button crowd" (since they just want to press one button or a single mouse click) and the second group, the "App Security Consultant/Developer crowd".
There is a strong need for both approaches, but we must be aware that there are big limitations on how much the discovery process can be automated. So, my focus is on the second group where I am working to create an environment where they (the knowledgeable security professional) can be hyper effective and accurate. I like the analogy of a plane’s cockpit, where a huge amount of data and complexity are filtered into graphically displayed, easy to understand information (well, easy to understand for the pilot *smile*, and, in our case, for the security consultant/developer.)
3) This is a question I like to ask everyone in this space, one of the unique things about web applications is that one programming error can be referenced in hundreds of instances often all of them Internet reachable. What do you think the number one error is; the mistake a programmer can make to guarantee a spot in the hall of shame?
I have to say that I really have a problem with blaming the developers. I do a lot of security training for developers and, in most cases, those guys are much more intelligent and knowledgeable than me. The problem is that our current development models reward features, performance, reliability and speed to market with security being one of those "Oh yeah, and it has to be secure." *smile*
So, I think the one single mistake the programmer can make is to agree to program in a non-sandboxed and non type-safe environment where one mistake can be fatal. The reason why such critical-impact errors occur is that our current application environments are not designed to protect that application’s assets. For example, in the web world: an SQL Injection on the Login Page, or a bank details page which asks the user which account he wants to see and doesn’t check if the user is authorized to see that account, or an airline system which uses a price for a ticket purchase submitted from a user-supplied html form, or XSRF vulnerable pages, and the list goes on.
One of the areas which I have been trying to get some of the big players in the market to change their paradigm (for example Microsoft) is in the use of Sandboxing technologies. We need to create run-time execution environments (for example, the environment where the web application server side code is executed) that limit what the code can do to those assets (for example, why should every single line of code in an application be able to manipulate the database, access all data, change the user identify, attack the internal network, etc.)
This also takes us to a problem of complexity where developers (and even system architects) are not able to list the attack surface of their application (i.e., all inputs and types of data that can be submitted). Add to that mix the use of Frameworks (from .NET to Ruby on Rails) that contain their own types of vulnerabilities, and you have a powerful cocktail where one mistake can lead to catastrophic consequences.
The good news is that the attackers are not exploiting these vulnerabilities (where are the kids writing benign worms when you need them? *smile* )
4) Dinis, the security market continues to change, new threats evolve, what are the hottest trends right now in attacking web applications and what can we do to prevent them?
I think XSS (Cross-Site Scripting) exploits (and its variations) have really exploded in the last 9 months. This was mainly caused by the wide use of AJAX, the emergence of meshes / "2.0" type of applications and the exploitation of JavaScript’s capabilities. We also had a couple cases of backdoors inserted (and discovered) on popular applications (see the WordPress case) which is something that we will see more and more in the future
To solve these problems we need to take security much more seriously, in both Open and Closed source worlds, where companies and organizations that develop software used to manage or store important assets use security-aware SDL (Software Development Lifecycle), run security audits regularly, and allow clients (i.e. the users of those applications) to select products based on their security (or lack of).
The key will be to enable the clients, who are paying for that software or using those web applications, to select with their wallet or eyeballs.
5) If security was your primary driver, would you prefer a framework like .Net or an AJAX driven Web 2.0 approach like MySpace? What if coding efficiency, getting it done both quickly and pretty much correctly, was the primary driver?
Well, I think you will find very few cases where getting it done both quickly and pretty much correctly is NOT the primary driver. I think the key is not in which framework or technology you use, but rather in the answers to the following questions:
- How much do the key players (from developers, to architects, to clients) understand the security implications of what they are doing?
- Is creating a secure application a key requirement?
- Is there a dedicated security team?
- How much clout (and budget) does that security team have?
- Can the application's features be changed based on their security implications?
- What are the REAL consequences of a security incident? (i.e., will it be a marketing / damage control exercise, or will that company actually lose customers and revenue?)
- Can the clients make their purchase decisions based on how good (or bad) the product’s security is? (i.e., are the clients aware of the efforts and cost required to write a secure application?)
- Finally, the main one: Does it make more commercial sense to: a) create a "secure" product; or, b) create a product that has a lot of "security features" but is quite insecure? Note that, in most cases, the answer is (b).
The answers to those questions will have more impact on the security of the website/application than the framework or operating system chosen. That said, I am a big fan of Frameworks since they can create development environments where the developers are making the right decisions by default (of course, if those Frameworks don’t implement and enforce Sandboxes, then the developers are able to bypass those "secure techniques" and manipulate the assets directly.)
6) What haven’t I asked, this is your chance to grab the bully pulpit, a platform from which to persuasively advocate an agenda, and drive home your number one point that you are trying to make as a thought leader in the industry?
The main point that I would like to make (which will be no surprise to anyone who has the patience to hear me talking about it *smile*) is my wish that we would all take sandboxing (most specifically, Partially Trust on ASP.NET) much more seriously. At this moment, our main security model is one based on the nonexistence of malicious code and vulnerabilities in the applications and libraries used on our servers and desktops.
I prefer the world where there WILL be vulnerabilities and malicious code in our servers and desktops that cannot be exploited (or are, at least, will be easy to identify when activated) due to the sandbox used to execute it.
Unfortunately, the big players who can move markets (Microsoft and Sun, in this case) don’t view that as a priority and their paying clients are not being attacked enough to demand serious solutions from them.
I have been defending this idea for 3 years now, and I still believe that this approach will solve a lot of the current security problems (note that my sandbox concept is focused on the assets and takes into account both server side and client side execution environments.)
