Six Grim(m) Security Fairy Tales - Page 2

By Ed Adams | Posted May 15, 2007
Page 2 of 2   |  Back to Page 1
Print ArticleEmail Article
  • Share on Facebook
  • Share on Twitter
  • Share on LinkedIn
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

Comment and Contribute
(Maximum characters: 1200). You have
characters left.
Get the Latest Scoop with Enterprise Networking Planet Newsletter