Misconception No. 2: Believing the Hype of Technology and Tools

By Ed Adams

(Back to article)

This is not to be meant to be a bash on security tools. My consulting company partners with security tool vendors and we believe they are valuable components to a mature security posture. But here are a few things to remember:

Tools don’t make people smarter. Nor do they improve the process through which solutions are built and deployed. Tools simply make people more efficient in jobs they are trained to do.

View the Entire Series

The Five Most Common Misconceptions of Enterprise Security

Misconception No.1: Over-Relying on Network Defenses

Misconception No. 2: Believing the Hype of Technology and Tools

Misconception No.3: Too Many People Assumptions

Misconception No.4: Assuming Secure Software is Costly

Misconception No.5: The “Recency” Trap

If you want to comment on these or any other articles you see on CIO Update, we'd like to hear from you in our IT Management Forum. Thanks for reading.

- Allen Bernard, Managing Editor.

FREE IT Management Newsletters

Tools don’t teach a surgeon how to operate or a road worker how to jack-hammer a hole. I didn’t become a better mechanical design engineer because I learned how to use AutoCAD, it just made me more efficient in the job I was already trained to do.

This is especially true of application security tools. The market here is still nascent and users need more education before tools can be truly useful. Network security tools are similar but luckily the market, purpose, and limitations of the tools here are better understood and much more mature.

When using a scanner (source code or Web) remember that they are just that, scanners. They will create false positives and they may very well miss a lot of serious vulnerabilities that do exist. Scanners are also impossibly flawed at catching business logic vulnerabilities, often the most damaging of all.

These are vulnerabilities that exploit acceptable behavior to steal or circumvent checks in your system. Take the example of a negative-integer attack on an ecommerce site. If the site uses client-side validation (all too many sites do, mainly for performance reasons), it’s easy to poison a cookie and turn the price of an item from positive to negative.

And because our business systems are so compartmentalized, most of these attacks go un-noticed. The account group just gets a notice that says debit this person’s account -$74.99, while the shipping department just gets a message that instructs them to ship the item to the user. There is often no correlation between the business functions and tools can’t help.


Tools need to be worked into your risk management and audit management cycles. This is something consulting companies can help you do if you do not know how. There is a large translation problem right now in a lot of organizations where a risk management team may define a problem and must translate that to actionable activities for the software development and network operations teams.

You need to take a three-pronged approach and integrate tools with your processes and your training so you can help your staff understand what’s expected of them and use the right tools to help them accomplish the job at hand while adhering to both corporate and industry processes and regulations.

Many organizations simply insert a tool into the software development or deployment process and require an application “pass” some arbitrary, predetermined score. This is dangerous in both context and user interpretation.

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.