EXPOSE The ancient Greeks spun myths to explain the unexplanable. Modern enterprises use commonly held myths as
a foundation for security.
In Greek mythology, the closest thing to a "God of Security" wasn't a god at all, but the giant monster Argus, who was considered the perfect security guard because of his ability to keep at least one of his hundreds of eyes open while sleeping.
Argus was a fearsome warrior to contend with, but he wasn't invincible. He ended up the wrong side of Zeus, who sent his son Hermes to kill Argus.
As the story goes, Hermes lulled the giant into a deep, eye-closing slumber. Then, when Argus was no longer "watching," Hermes cut his head off.
Argus is an interesting, if imprecise, symbol for today's infosecurity professional.
We, too, pride ourselves on our ability to keep constant vigilance over our systems, networks and data. Unfortunately, we're often undermined by the cunning of our adversaries and their ability to exploit our vulnerabilities.
The parallels between ancient mythology and modern enterprise security don't end there. As in ancient times, myths are the foundation of much of security's belief system; they're a way to infuse meaning and purpose in a world that lacks scientific explanation. Where the ancients lacked empirical data to explain the world around them--such as the movement of the stars or the change of the seasons--security pros lack data on the effectiveness of their activities. What constitutes "good" security? How effective is my IDS? How much money should I spend on vulnerability management? How do you quantify security productivity?
Lacking the tools and knowledge to gather, analyze and apply objective data to our policies and initiatives, we, like the ancients, uncritically accept common truisms about the "way to do security," rarely questioning their validity or applicability.
For security to mature as a business discipline, security professionals must shed the common myths that justify our beliefs and give meaning to our activities, and develop a framework of critical thinking that tests the generalities of the best way to secure the enterprise.
Here are six common security myths and how you can avoid being lulled into a false sense of security by them.
Myth #1: You can patch yourself to safety
The theory behind patch management is simple: Patch vulnerabilities before the bad guys can exploit them. Unfortunately, it's also impractical and idealistic for most environments.
"There's a great Pennsylvania Dutch proverb that says, 'The hurrieder I go, the behinder I get,'" says Oracle CSO Mary Ann Davidson. "Nobody can keep up with security patches. It's just too overwhelming."
Most would agree that patching is a critical step in the identify-assess-remediate-defend lifecycle of vulnerability management. What's more, recent research shows that enterprises are getting better at patching. According to vulnerability management firm Qualys, over the past year, organizations have reduced the "half-life" of critical vulnerabilities (the exposure window for worms and automated attacks) on externally facing systems from 30 to 21 days. This appears to be great progress--until you realize that the interval between a vulnerability's discovery and the appearance of an exploit is now 10 days or less.
The problem is that too many IT and security managers view patching as a binary function--a system is either patched/secure or unpatched/vulnerable, which puts unrealistic pressure on patch management systems (be they manual or automated) to efficiently and systematically prioritize and deploy fixes.
"Patching is blatantly bad news," says Ron Moritz, senior VP and chief security strategist at Computer Associates. "We tend to think it's a panacea, and it's not."
For one thing, effective patching relies on accurate asset management, which most organizations lack. Automated patch management systems can help, but most lack the intelligence to correlate vulnerabilities, threats and patch deployment status.
Perhaps most importantly, the patch philosophy flies in the face of harsh business realities, in which uptime and productivity are valued far more than exposure management. Put another way, your CEO may proclaim, "Security is the foundation of our business," but, when push comes to shove, nobody is taking the accounts receivable database offline during earnings reporting season--SQL vulnerability or not.
A better approach views patching as part of the risk management continuum. Moritz argues for a "situational command center" approach in which risk scenarios are constantly simulated and modeled. That way, when patching takes a backseat to the need for uptime, you've already got a workaround in place--for instance, temporary system isolation at the router level.
Myth #2: Antivirus doesn't work
Viruses, worms, spyware, Trojans, mobile code and all other varieties of malware are hammering businesses at alarming rates and levels of intensity. Multivector, multipayload worms obliterate disk drives, saturate network shares and covertly install rootkits on servers, costing businesses billions of dollars annually.
The stark reality is that conventional signature-based antivirus technology is largely powerless against these new forms of attack. In fact, many new worms and their variants are carefully tweaked to evade AV scanners. This has lead many to believe that signature-based AV is impotent and unnecessary.
"AV reduces risk in companies by a hundredfold or more," says Peter Tippett, CTO of managed security firm CyberTrust. In fact, he suggests that using AV has an "amplifying" effect on risk reduction. "If you do a little bit--place AV on desktops and gateways and filter for 10 or so prominent file attachments--you get a lot of benefit."
The problem with conventional AV, Tippett says, is that too many companies overly rely on it. "They try to take that thing that reduces risk by a hundredfold and make it tenfold better instead of investing in other cheap and easy security processes," such as zone segmentation, bastion hosts, default deny on border routers and disabling active scripting in Internet Explorer. Like AV, each of these techniques is effective only up to a point. But used in concert, they reduce the risk of malware infection by orders of magnitude.
And then there's the human element, which no technology can perfectly secure. "Many worms and viruses target people, and we'll never be able to secure them," says Bruce Schneier, CTO at Counterpane Internet Security.
Schneier says that blaming AV scanners is a little like killing the messenger. "The security of our operating systems and applications sucks, [and] lousy software makes for a very permissive environment for worms and viruses."
Myth #3: Security policies must be comprehensive
Most security pros dread implementing and writing security policies because they assume these policies have to be exhaustive documents that address every aspect of IT and business procedures. A poll conducted at a recent Information Security Decisions conference found that many enterprise security pros have bought into the "more is better" approach. More than one-third have rolled out security policies longer than 20 pages, and nearly one-fifth have policies longer than 50 pages.
Documents of this length may be complete, but they're hardly accessible, and probably ignored.
Security managers fail to realize that the more work that goes into a policy document, the longer it takes to roll out and the greater the chance that parts of it will be obsolete as soon as it's pressed into action.
Whether you have a 50-page policy or no policy at all--as is the case with 14 percent of those polled--G. Mark Hardy, president of security consultancy National Security Corp., advises that enterprises create a one- or two-page high-level policy statement that includes the company's mission and objectives, as well as the guiding principles for and restrictions on the use of organizational property, resources and content. The succinctness of a "big picture" summary document will increase employee acceptance and boost compliance with the policies that matter most.
Myth #4: Security is a feature
Lots of managers view security as another feature of the infrastructure--something you install, configure and administer, like a remote management application. But, security is neither a feature nor a product.
"Security is a nonfeature requirement," says Counterpane's Schneier. Features in applications, for instance, are designed to allow input A to produce output B. Security is the mechanism that enables that activity to happen safely.
Security is better positioned as a subset of reliability, says Dan Geer, VP and chief scientist of insider security monitoring software vendor Verdasys. "Security is a means, not an end; reliability is an end, not a means," says Geer. The goal of reliability is to ensure the confidentiality, integrity and availability of data and data resources. If data is reliable, it's secure, but security alone doesn't make it reliable.
Myth #5: IDS is dead
Like conventional AV, signature-based intrusion detection systems have come under fire for not living up to their promise. This sentiment reached its apex in 2003 when Gartner Group proclaimed, "IDS is dead." And, if Gartner said it, well, of course, it must be true--right?
IDS isn't dead. In a recent survey, Information Security research partner TheInfoPro found that 80 percent of Fortune 1000 enterprises now deploy some form of intrusion detection. And, rather than killing it off, many vendors and enterprises have transformed their IDSes into integral components of attack correlation, perimeter intelligence and forensics.
Network firewalls from vendors such as Check Point Software Technologies, Juniper Networks, Cisco Systems and Secure Computing now have IDS-like functionality for commonly exploited application protocols such as HTTP, FTP, SMTP and XML/SOAP. These devices supplement filtering on IP address, port and network protocols by examining the construction of selected application payloads and pattern-matching against a signature database--just like an IDS.
IDSes are also proving to be effective reconstruction data stores. While they're less effective in real-time threat prevention, IDSes give you a specific data trail on what and when attack packets passed on the network.
"Forensics has become IDSes' greatest value," says CyberTrust's Tippett.
Myth #6: The security guy is accountable for security
It's an age-old maxim that "security is successful when nothing bad happens." So, naturally, when some-thing bad happens, everyone asks, "What happened?"
If security is institutionalized throughout an organization, the security guy should be able to respond, "You tell me." At the end of the day, the security guy isn't accountable for security; he's accountable for making everyone else accountable for security.
"Security is really about gap analysis," says Robert Garigue, CISO of the Bank of Montreal. "The people who are accountable to close those gaps are not the security people; they're the operational people. Firewalls and IDSes should be managed by the network people. Patch management should be done by the server and desktop staff." Instead of doing all those things, Garigue says, "Security should be looking at where the next big risks are coming from."
Garigue puts accountability for security square in the laps of the line-of-business owners. The security/business unit relationship, he says, should resemble that of a dentist/patient. "The patient has the accountability to brush his teeth every day. The dentist has the accountability to do a checkup once a year and fix cavities when required."
CA's Moritz agrees. "Security is moving beyond the infrastructure and users," he says. "Today, we build business processes around people and work. Tomorrow, we will automate business processes and hire people to work around standard processes.
"As this change takes place, the ideas behind what defines security and security products will change dramatically--and so too the expertise required to be a security wonk. The expertise will be in the attribute-based classification of data, business processes and management goals. The security guy will be the head conductor, not someone relegated to the back corner of the orchestra."