AppSec Blog: Author - Jim Bird

Late last year SANS conducted a survey on application security practices in enterprises. One of the questions asked in the survey was how often organizations are doing security testing. The responses were:

• No security testing policy for critical apps: 13.5%


• Only when applications are updated, patched or changed: 21.3%


• Annually: 14.3%


• Every 3 months: 18.0%


• Once a month: 9.5%


• Ongoing: 23.3%

The only way to test this frequently, and the effective way to scale security testing in large enterprises with thousands of applications and hundreds of web sites, is by relying heavily on

My brain's on fire about devops, having just got back from Devopsdays. Devops is starting to have the same kind of impact on application and system operations as Agile has had on software development. Although only a small number of people at a few companies are really doing devops, it is getting a lot of attention, because they are getting impressive results. Devops is the most exciting thing to happen in operations for a long time.

What's interesting from an appsec perspective, is that devops is trying to solve some of the same problems as appsec. Both communities are trying to get developers and operations working together to make systems safer and more reliable and more resilient. To get developers to take operations problems and requirements (including security and reliability and resilience and operations transparency) seriously, and to share responsibility for making systems work in production.

But

When a development team first starts to take application security seriously, they'll end up with a list (probably a long list) of security bugs. It's useful to look at security bugs in different ways.

<h2>Design Flaws vs. Implementation Bugs</h2>

The first is to ask where each bug comes from — is it an architectural or design flaw, or a coding or implementation bug? As Gary McGraw explains in Software Security: Building Security In, architectural or design flaws are more fundamental and more expensive to change or fix, and they take training and help to understand. Coding or implementation bugs are easier to find through scanning and reviews — these kinds of bugs are smaller and easier to fix, but there tend to be a lot of them. Thinking of security bugs this way helps you to understand where you need to focus your controls and time in your SDLC, where

Penetration testing is one of the bulwarks of an application security program: get an expert tester to simulate an attack on your system, and see if they can hack their way in. But how effective is application penetration testing, and what should you expect from it?

Gary McGraw in Software Security: Building Security In says that

Passing a software penetration test provides very little assurance that an application is immune to attack

It's easy to test whether a feature works or not, but it is very difficult to show whether or not a system is secure enough under malicious attack. How many tests do you do before you give up and decide "secure enough"?

I attended the RSA conference last week in San Francisco for the first time, and enjoyed the city. Excellent restaurants like Slanted Door, Canteen, Barbacco and especially Commonwealth, the Wharf, Chinatown, the almost perfect weather.

I was surprised at the scale of the conference, the impressive number of IT security professionals who came from everywhere, and the even more impressive number of technology vendors represented. The exhibition floor was overwhelming: huge booths with their own bars and free drinks, lovely booth bunnies in racing suits and blue wigs, race cars, a robot, a real sumo wrestler, lots of games and contests, even a "beat the freak" - a chance to put on gloves and beat on a salesman. Most of the technology was targeted to the enterprise of course, SIEM systems and enterprise ID management systems, and highly scalable next generation and next next generation firewalls, and lots of endpoint security solutions. And vulnerability scanning technology of