If an application passes, there may be a false sense of security the application is secure. If the application fails, the development team may have more incentive to code specifically to pass the test rather than meeting critical business or security requirements. Tools and people are both fallible. Thus, well documented and reviewed security policies and procedures are paramount.
In Context
There are a lot of great tools available but you need to make sure you give your team the context in which to use them as well as the training they need to get value from them. If you give that jack hammer to a six year-old boy he’s not going to know what to do with it or how to use it and two things are going to happen: He’s either not going to use it at all because he’s afraid of it (making it a very expensive paper weight), or he will use it and cause serious damage to him or someone else in the process.
This is how a lot of companies use security tools today. They just buy the development or audit team a scanner and tell them “just use it” without the guidelines or training on how to. What the organization needs to do is roll out sound processes integrating security into every step of the development and deployment process.
Intrusion detection (IDS) and prevention systems (IPS) are classic examples of tools that give a false sense of security. They typically look for abnormal or suspicious data or behavior and then block that user or activity. Sounds great on the surface, but you need to understand exactly what they are looking at.
Often, it’s no more than sniffing network traffic and watching for “out of bounds” behavior. I can’t tell you how many clients I’ve had that are frustrated because their IPS keeps preventing users from making off-hour database queries or even a simple thing like flushing the browser’s cache; a rapid succession of deleting large numbers of files is often an activity that will get detected and blocked by an IPS or heuristic antivirus system.
As I’ve said, I love tools. I worked for a software testing tools vendor for over five years. But I also recognize that tools alone don’t make people smarter, or necessarily solve the problem you expect them to. That’s the short-term problem to focus on — train and educate your teams in the application development discipline and hold your network teams accountable to maintaining secure infrastructures.
Most of all, make sure your policies and procedures are up-to-date and include all use cases and abuse cases you need them to in order to protect your crucial assets. The best attempt I’ve seen to date is the PCI standard (payment card industry) which is a specific and prescriptive set of requirements for secure information flow.
This is not comprehensive, but it is getting there. For example, next year, it will require the presence of either a Web application security firewall or proof that your application has been security code reviewed. These are not replacements for each other, mind you, but it’s a good start in the right direction; a proactive attempt to secure data at both ends.
Security tools are not the panacea people want them to be. Just like network defenses, they have their place in a complete information security workflow, and they require people who know how to use them to be effective.
In the coming weeks look for more expanded articles from Ed Adams covering each of these themes: Over-relying on Network Defenses, Believing the Hype of Technology/Tools, Too Many People Assumptions, Assuming Secure Software is Costly, and Falling into the “Recency” Trap.
Ed Adams is CEO of Security Innovation, an independent provider of application security services that include security testing and training.