Q&A: Bruce Jenkins, Fortify Software

Jenkins: I pay credit monitoring services so I'm aware if something happens with my bank accounts

The recent report of hackers breaching a top secret US F-35 jet fighter programme has highlighted the fact that even organisations perceived to have some of the best security infrastructure money can buy can fall to determined cyber attacks.

One method of protecting companies' critical business applications is through targeted application security. Application security uses procedural methods to secure applications throughout the software lifecycle – design, coding, deployment, and maintenance. For software development firms, this means the use of policies and tools to certify software, as far as possible minimising the security attack envelope to resist both internal and external attacks.

One person well qualified to speak about these attacks is Bruce Jenkins, a former Major in the US Air Force (USAF), and now a managing consultant for application security firm Fortify Software. Computing caught up with him at the Infosecurity 2009 show at Earls Court.

You were part of the team given the task of investigating a breach in the USAF's personnel system – what happened?
Bruce Jenkins: The personnel system was using personally identifiable information for access, which with hindsight was really silly. But then, just as other organisations currently do, the USAF was relying on its perimeter defences to prevent application security attacks.

So here someone had designed a system allowing me to go in, enter my social security number, date of birth, and other personal information and do a password reset, and that's precisely what someone did. They got access to the personnel database and downloaded 33,000 personnel records – mine included. In fact, to this day I pay credit monitoring services a monthly fee so I'm aware if something happens with my bank accounts.

How do you think they cracked the database?
It's purely speculation on my part, but I can speculate because I know what the code looked like. I think once they got access into the system, they used an SQL injection to gain access to the database, and got away with a relatively large number of records in a short amount of time. The data the hackers were taking out was not encrypted, someone at system administrator level noticed unusual activity and shut it down, but 33,000 records had already been lifted.

What was the result of that security breach?
There were a couple of recommendations following the breach. One was to evaluate products on the market that would solve this problem, and I led a pilot programme in 2006 to evaluate static analysis tools. That lasted 11 months. At the end of 2006, the USAF changed its Mission Statement which was modified to include cyber security.

Second, because there was no central authority in the USAF to do this, in 2007 I and others created the framework and resource requirements for what is now the Application Software Assurance Center of Excellence (ASACoE). ASACoE's role is to raise awareness, educate and provide products and tools for software developers. They are taught how to use them and create metrics to feed back into the process to give better application security.

From a policy standpoint, the Crisis Action Team investigation resulted in the Air Force doing something quite amazing. Normally policy changes such as this would take 18 months, but in this case the policy regarding identification and authentication was changed within 90 days.

Is there a difference between military application security and corporate application security?
Frankly, I don't think there should be any difference. There's no difference between this and, say, a financial firm's application security. System downtime is the same. Take the Computing web site – if the web site goes down, people can't access the latest articles, which potentially affects your image, your advertising, your revenue. The mindset is the same – if I have a problem that affects my service, then resources – whether military or financial – need to be protected as quickly as possible.

What is the problem with traditional perimeter security infrastructure in relation to application security?
Don't assume that because you have robust perimeter defences or security that this will help you in any way when it comes to application security. Organisations will invest heavily in firewalls, intrusion detection systems, intrusion prevention systems and end point security such as anti-virus software, and think that will solve their problem. The real issue here is that you're extending the software beyond their perimeter defences, so don't assume that those pieces of equipment are going to help you.

What are the most common roadblocks in an application security programme?
Don't assume that everybody will jump on board with the programme. Many high-level company executives are unconvinced yet – despite the daily security breaches – that there is a real issue with application security. So you'll have to build an awareness programme into your organisation, so those affected understand what you're trying to do from an application security standpoint, and will buy in to your project.

You must also get sponsorship at the appropriate level. Let's say you’re a project leader and you've been given the task of implementing the software security programme. You've been given the resources, people and money, which is all well and good, but if I don't give you the authority or the scope within the company to apply the leverage necessary to implement this, you won't get anywhere. You'll meet resistance from other individuals in the business unit – they'll say, "Hey Dave – this is great what you're doing, but I don't work for you and I have a project to roll out, and what you're going to do will affect me." They're pretty much saying, "get out of my face here, and go and do something else."