My thoughts on common misconceptions about enterprise IT security focus on five core issues, the top three of which are the biggest offenders.
1. Over-Relying on Network Defenses
The problem isn’t our networks (which are pretty well protected), it’s the software. There is no discipline or rigor to software engineering like there is in other engineering disciplines. I’m a mechanical engineer by trade so this is a very serious problem to me and one that I’m intimately familiar with. But examples in other industries are just as stark by comparison, e.g., doctors have residencies; civil engineers have to be certified and train under another certified engineer (they’re called EIT, engineer-in-training, and can’t lead any projects).
2. Believing the Hype of Technology/Tools
I love tools. I worked for a vendor that sold software testing tools for more than five years. But I also recognize that tools don’t make people better. They simply make people more efficient in jobs they are trained to do. Tools don’t teach a surgeon how to operate. I wasn’t a better engineer because I learned AutoCAD, it just made me more efficient in the job I was trained to do. That’s the problem — no training in the discipline; not tools. They aren’t the panacea people want them to be.
3. Too Many “People” Assumptions
Causal hackers aren’t the real threat. Hackers actually help trip land mines 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 designed software that allows the hackers to exploit them in the first place. Fix the problem — software — and you mitigate the threats
4. Using ROI as a Leading Indicator/Metric
Organizations look at software and security as an investment. They are liabilities that need to be mitigated, not exploited for ROI. If companies thought about their applications as threats instead of assets they’d treat them a lot differently from conception through development and deployment.
5. Falling into the “Recency ” Trap
I love this one. It’s a psychological problem more than anything. People react to the most recent scare. An epidemic of lost laptops led to net data encryption, while netbots led to investment in intrusion prevention systems. This is a trend that is well-documented and it’s a shame. It happens not just in IT of course. 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 percent. 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. It’s a classic example.
6. Assuming Secure Software is Costly
Though it may add time to the up-front software development cycle (SDLC), defining requirements properly and designing systems well by integrating security into each phase of the SDLC saves tons of time and money in later phases; especially testing and deployment, when security holes take a long time to troubleshoot, re-code, and patch.
Microsoft has some good case studies on this utilizing its SDL (secure development lifecycle) internally on SQL Server. I realize they have a bias interest in promoting it, but the numbers don’t lie — SQL Server 2005 (which was built using SDL) had substantially fewer security bugs than either Oracle or MySQL.
– By Ed Adams Culled from an Internet.com Security eBook. © 2010, Internet.com, a division o f QuinStreet, Inc