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
