Six Grim(m) Security Fairy Tales
Information security mistakes are costly, damaging, and all too prevalent. Given the repercussions of poor security strategies (see recent incidents from organizations like TJX, AOL and the VA), one is inclined to believe change agents are in place.
However, organizations continue to drive their security efforts based on fallacies and myths, and make seemingly avoidable mistakes when it comes to information security. I'll present six common myths, in no particular order:
• Network Defenses will Protect your Kingdom
• Technology/Tools are the Panacea
• Only "Bad" People are Bad
• Security ROI is the Beacon
• Secure Software is Costly
• The Security Breach du Jour is the Most Pressing
1) Network Defenses Protect Your Kingdom
The problem isn't our networks (which are pretty well protected, by the way). It's the crappy software we write and put on the network.
There is no discipline or rigor to software engineering like there is in other engineering disciplines. I'm a mechanical engineer by trade with certifications that verify my expertise in this craft. There is no correlation in the software world and we, as organizations that build and buy software, aren't demanding a change.
Network defenses, like firewalls and intrusion prevention systems, have a place in a multi-layered information security solution, but they can't protect us from the majority of vulnerabilities – those in the application layer.
2) Technology/Tools are the Panacea
I love tools. I worked for a software testing tools vendor for more than five years. But I also recognize that tools alone don't make people smarter, nor do they improve the process through which solutions are built. They simply make people and processes more efficient in jobs they are trained to do.
Tools don't teach a surgeon how to operate. 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. That's the problem. There is no training in the application development discipline and no rigor in holding teams accountable to maintaining secure infrastructures. Tools have their place in a complete information security workflow but they require people who know how to operate them to be effective.
3) Only "Bad" People are Bad
Causal hackers aren't the real threat. Hackers actually help trip landmines that are waiting to be exploited.
The real threats are organized hackers (think terrorist cells or enemy states) who could cripple our infrastructure, utilities and communication systems. Real threats are insiders who already have access and know where the crown jewels are. Companies focus on hackers but that is the wrong assumption. And they always forget that it's their poorly-written software that allows the hackers to exploit them in the first place. Fix the problem (bad software) and you mitigate the threats.
4) Security ROI is the Beacon
A recent Gartner survey noted that 25% of organizations are looking for a specific return on investment from information security investments. An additional 27% view it as a cost or risk avoidance investment, leaving only 48% of organizations that view security investments as a cost of doing business.
Until organizations let go of the desire to measure security ROI, they will never be satisfied with any investment therein. Your applications and data are liabilities, not assets. They are information security risks and liabilities that need to be mitigated, not exploited for ROI.
If companies thought about their applications as threats or liabilities instead of assets they'd treat them a lot differently, from conception through development and deployment. Think of security investment like an investment in term life insurance – you are mitigating risks associated with a liability, your mortality. We don't die every year, but does that mean term life insurance is a bad investment?5) Secure Software is Costly
Though it may add time to the up-front software development cycle, integrating security into each phase of the software development lifecycle (SDLC) saves tons of time and money in later phases.
Application security holes take a long time to troubleshoot, re-code and patch. Microsoft has some good case studies on this utilizing its Secure Development Lifecycle (SDL) internally on applications like SQL Server 2005. I realize they are biased in promoting that but the numbers don't lie – SQL Server 2005 (which was built using SDL) has substantially fewer security bugs than either Oracle or MySQL. Check the CVE database for verification.
6) The Security Breach Du-Jour is the Most Pressing
This is a psychological problem more than anything. People react to the most recent scare.
For example, lost laptops from ING and Ernst & Young lead to organizations mandating hard drive encryption on all machines that leave the premises. A series of news articles on netbots result in heavy investments in IPS (intrusion prevention systems). This is a trend that is well-documented and a shame.
Organizations feel more at risk simply because they are aware of an incident that occurred at some other organization. The result is over-investment and investment in the wrong places because organizations try to mitigate a risk that they now perceive as real. The fact is that there are many more risks that are much more real and probably more damaging, but the recency trap has sprung. It happens not just in IT.
In 1967 Sweden changed from driving on the left side of the road to driving on the right. What happened? In the 12 months following, auto fatalities dropped by 35%. Not because the right side of the road is safer, but because there was a change and people felt more at risk. Twelve months later, auto fatalities were exactly where they were pre-1967. People forgot they were at risk and adjusted behavior. Classic.
Questions to Ask Yourself
If you made it to this point without a major panic attack, that's good. There's no doubt that security has been one of the biggest pains faced by the IT industry in the last few years. And it will continue on this painful path if you bury your head in the sand thinking it will go away. Ask yourself:
1) How much value will adding x security control bring to my organization? And how much risk will that control help me mitigate?
2) How do I know I'm improving on security? What do we measure and are we using the right metric?
3) Do I need to make a security investment in this area (the answer isn't always yes)? And what are the activities that provide the largest security protection here?
4) When I buy or build "y" product, what is the security risk in deploying it and how does that risk vary from product to product?
5) How will tools help my team? And do I need to provide them training to complement the tools?
6) What activities should the IT or development team be doing to ensure secure data and applications? Are we thinking of security at each phase of the software development and management lifecycle?
7) Is my business really at risk in this area or do I just perceive that we are because of recent events?
Article courtesy of eSecurity Planet