Security Advancements at the Monastery

“Do not believe in anything simply because you have heard it. Do not believe in anything simply because it is spoken and rumored by many. Do not believe in anything simply because it is found written in your religious books. Do not believe in anything merely on the authority of your teachers and elders. Do not believe in traditions because they have been handed down for many generations. But after observation and analysis, when you find that anything agrees with reason and is conducive to the good and benefit of one and all, then accept it and live up to it.” — Siddhartha Gautama

The security profession is facing some major problems. The world we live in requires us to be effective and efficient at interpreting, addressing and communicating data quickly. Risks is ever increasing as government and private sector become more dependent upon computers and network systems. Before we start considering solutions, Eliezer Yudkowsky in “Hold Off On Proposing Solutions,” cautions “if you make your decision very early on, it will, in fact, be based on very little thought, no matter how many amazing arguments you come up with afterward.”

Helping us understand some of the underlining problems, Sergey Bratus examines the different approaches between the hacker and developer worlds in his article, “Hacker Curriculum: How Hackers Learn Networking.” Sergey points that the out typical developer is likely to encounter:

• pressure to follow standard solutions—that is, the “path of least resistance” to “just making it work.” As long as “it works,” detailed understanding is often optional. As a result, developers might not realize the security implications of deviating (intentionally or not) from the standard templates or recognize their inherent weaknesses.
• training that discourages exploring the underlying API because the extra time investment rarely pays.
• a severely limited view of the API, with few implementation details. (Such limitations are often intentional or even part of the vendor’s business model.)
• encouragement to ignore or avoid infrequent border cases because investing effort in handling unusual conditions is a “waste of time.” As a result, developers might not understand the effects of nonstandard input on the system.
• explicit directions to ignore specific problems that are other developers’ domain. (In private communication, I was told that a major vendor advised customers that their product’s security was the customers’ responsibility. The vendor expected the customers to “just put it behind a firewall.”)
• a lack of tools for examining the system’s state, let alone changing it outside the API.

In contrast, hackers exhibit the following traits:

• Hackers tend to treat special and border cases of standards as essential and therefore invest significant time in reading the appropriate documentation (which isn’t a good survival skill for most industrial or curricular tasks).
• Hackers insist on understanding and exploring the underlying API’s implementation to confirm the documentation claims.
• Hackers second-guess, as a matter of course, the implementor’s logic (one reason for preferring a developer-addressed Request for Comments [RFC] to other forms of documentation).
• Hackers reflect on and explore the effects of deviating from standard tutorials.
• Hackers insist on having tools for examining the system’s full state across interface layers and for modifying these states, bypassing the standard development API. If hackers lack such tools, developing them is a top priority.

These points help explain why the hacker’s approach has continued to prove effective. The traditional approach to security is not working. Richard Bejtlich has a humorous description of the security most organizations are practicing. He refers to it as “Soccer Goal Security.”

To quote Richard,

I see the goalie as representing most preventative security countermeasures. Player 9 is the threat. The soccer ball is an exploit. They are attacking an enterprise, represented by the soccer net. The goalie is addressing the threat he expects, namely someone trying to score from the side of the net he is defending. In many cases the goalie is fighting the last war; perhaps the last time he was scored upon came from the side he now defends?

The threat is smart and unpredictable, attacking a different part of the net.The net itself (the enterprise) is huge. Not only is the front of the net open, the net itself is riddled with holes. A particularly clever attacker might see his objective as getting the ball in the net using any means necessary. That might include cutting the ball into smaller pieces and sending the fragments through holes in the net. Another attacker might dig his way under the goal and send the ball up through a tunnel. Yet another attacker might wait for the goalie to get tired, or drop his guard, or lose his vision at night. A really vicious threat would attack the goalie himself.

What might be a solution? Gartner vice-president John Pescatore at the London IT Security Summit on September 17th stated that organizations should aim to spend less of their IT budgets on security. Pescatore went on to say, “I really don’t think most of us need more and people.” Pescatore went on to explain that if organizations moved to a model he called ‘Security 3.0’, IT security would anticipate threats, rather than fight them after they hit. SA Mathieson has written more on Pescatore’s message in the article, “Spend less on IT security, says Gartner.” Pescatore described Security 3.0 as involving an approach to risk management that applies security resources appropriately to meet business objectives. Instead of bolting security on as an afterthought, Security 3.0 integrates compliance, risk assessment and business continuity into every process and application. Pescatore presented two very interesting slides, “Threats Continue to Be Dynamic” and “Lack of Product is Not the Problem.” While there might be many products addressing security problems, are they addressing the right problems? New products and new technology are creating new holes to exploit.

Pescatore makes many very valid points. Of course, back in 2003 Pescatore stated, “We think IDS is dead. It’s failed to provide enterprise value.” Just a demonstration that no one has all the answers. Well, not all the correct answers. Hopefully, managers will not just walk away with the message that they should “spend less on security” and “employ fewer people.” In many organizations management is spending plenty of money. Unfortunately it is on the wrong tools. Directing resources to other functions could result in more effective security. In other words, organizations must stop practicing Soccer Goal Security.