The Answer is 42 of Course

If we want our networks to be sufficiently difficult to penetrate, we’ve got to ask the right questions.

THOMAS WADLOW, INDEPENDENT CONSULTANT

Why is security so hard? As a security consultant, I’m glad that people feel that way, because that perception pays my mortgage. But is it really so difficult to build systems that are impenetrable to the bad guys?

OK, I just threw you a ringer. Two, in fact. The first is that lovely word impenetrable. A nice absolute word that makes it seem like you are completely safe and secure (two more words that give similar impressions). If we are talking about the security of your network, or any system for that matter, and you tell me that you need it to be impenetrable, safe, secure, or any similar absolute concept, it suggests that there’s money to be made. By me.

I don’t want to sound too cynical, and I certainly don’t want to make it seem like a scam. I provide good value to my customers, as do many other security consultants and professionals. I know that I have saved my customers money, and made them safer. But “safer “isn’t “safe,” and until customers and developers understand the difference, security is going to remain a difficult and expensive proposition for them.

The difficulty is in the human hunger for absolutes. Many technology issues are based around absolute concepts. The airplane flies or it doesn’t. The network router works or it doesn’t. The equation produces the correct answer or it doesn’t.

Issues where people are involved rarely have this clarity. That is the first fundamental realization necessary to really understand security as a technologist or as a manager. Security is a people problem, not just a technology problem.

When we design a network router, we are basically solving problems of logic and physics. We can define tests for your device, and those tests can be repeated exactly so that we can debug the device. If we have enough tests, and our device passes them, our router works.

Security devices such as firewalls often physically resemble network routers (and indeed may be part of the same device), but good tests are a lot more difficult to develop. Why? Because now our tests have to take people into account. To reflect the real world accurately, they won’t all be repeatable, and the people we are trying to defend against may not play by our rules.

If we want our network to be acceptably difficult to penetrate, we’ve got to ask the right questions. For many people, even technically sophisticated ones, thinking about the basics of network security boils down to a question of what kind of firewall to buy. But let’s step back a bit farther and try to look at this problem from first principles. Absolutes won’t work, so the first question we must ask is: How can we design a network that is safe enough?

Thinking about the phrase “safe enough” should quickly make us wonder, “Safe enough from whom?” In other words: Who are the people attacking our network?

Well, that was the second ringer in the first paragraph of this article. Remember the bad guys? The phrase conjures up an image of movie-type criminals hunched over computer screens, or maybe 14-year-old social misfits in the family basement. But in truth, they could be anybody. They might even be people we know. And there’s a pretty good chance they are people we hired, and probably trust. A truism in the security industry is: if money is involved in a security issue, look for an insider.

In my work as a security consultant, I’ve had the opportunity to look at many different network security systems, both successful and unsuccessful. I’ve seen how a variety of organizations protect their computing infrastructures and proprietary information. I’ve spoken to many of my peers, who have had similar perspectives. Throughout all this, one recurring theme is clear: for the majority of successful intrusions, either the barriers are very low or the motivation level is very high.

This is not to say that there aren’t complex and dangerous penetrations, or that attackers aren’t using so-called “zero-day exploits” (making use of newly discovered vulnerabilities early before defenders can patch against them). It is not to say that well-defended networks are not penetrated. It is still true, to paraphrase Thomas Jefferson, that the price of network security is eternal vigilance. But in an awful lot of cases, either the network designers made it easy enough, or the attackers wanted it really badly.

Skill, Motivation, Opportunity

Given all of the above, we might make this assertion: any computer system can be penetrated if the attackers have sufficient skill, motivation, and opportunity. From there, a strategy for protecting our network falls quite naturally into two major goals:

Requiring a very high level of skill and motivation for an attacker and presenting as little opportunity as possible for the attack to succeed.
Deciding where and how much effort to expend in the process.

Now those are goals that a technologist can embrace and expand upon. Furthermore, those goals can direct our security efforts from the micro to the macro level.

Let’s analyze our first goal a bit more, starting with some help from a dictionary: skill is defined as “proficiency, facility, or dexterity that is acquired or developed through training or experience”; motivation is “the psychological feature that arouses an organism to action toward a desired goal”; and opportunity is “a favorable or advantageous circumstance or combination of circumstances.”

Skill. How do attackers become more skillful at penetrating a network? One way is through practice. With off-the-shelf software, attackers can set up test networks of their own and learn about them until a weakness is found that they can exploit. This requires a fairly high level of skill and motivation, because it can take a lot of patience to find a good exploit. By packaging that exploit in software and distributing it, however, many more attackers can take advantage of the flaw without having to be smart enough to find it.

Another way is what, in military circles, would be called intelligence. Learn the design of the target network. Learn the ways in which it is guarded and monitored. Learn about the people who run it. Knowledge is power, and if you want to open something tough, use power tools.

So we can analyze the skill part of our assertion by asking questions such as these: How can we maximize the amount of skill needed to penetrate our network? How can we minimize the amount of skill needed to operate the defenses of our network? How can we prevent attackers from gaining knowledge of our network? Given that some exposure of our network information to the Internet is inevitable, how can we make that knowledge less useful to an attacker? How can we know that we are under attack?

By answering these questions, we can begin to see how we can use technological means to make our networks hard to penetrate. What makes a defense hard to penetrate? Answers to that might include: good design; good implementation of that design; proper configuration; a continuing supply of up-to-date patches; and multiple, redundant layers. Now we are getting to something that looks like technical specs.

You can try to ask for those qualities from the manufacturers of equipment you are considering for purchase, but you should also ask them some other important questions: How can you prove to me that your device has good design, good implementation, etc.? How often is your design and implementation audited by independent third parties? How often do you issue security patches? Do you issue patches on problem detection or on problem resolution? When was your device last compromised, how was it done, how did you find out about it, and how long did it take you to issue a patch?

Motivation. What motivates someone to attack our network? Well, for a start, the same things that motivate pretty much anybody to do anything—such as anger, greed, love, hate, revenge, and, of course, everyone’s favorite: money. Add to that more intellectual reasons such as curiosity and the thrill of a challenge, and we won’t have any problem finding reasons why people attack us.

Motivation is a two-way street, of course. Attackers are driven by their own desires, but they can also be encouraged or discouraged by how they are treated by the network. Tease them with tantalizing clues and they will treat it as a game to be won. Answer each challenge with disappointment and confusion, and perhaps they will seek fun elsewhere.

Some questions that explore the issue of motivation are: What circumstances or resources cause people to want to attack us? Do our actions in defending the network increase or decrease a person’s motivation to continue an attack? What would motivate people not to attack our network?

There is a famous quote from Sun Tzu, the Chinese general of several millennia past: “The general who is truly a master of war can wage the entire war in the mind of the enemy and win without bloodshed.” One way to do this is to create a situation in which potential attackers are unaware of your network. If it never occurs to them to attack you, and nothing disturbs their blissful ignorance of you, then they never will bother you.

This practice, called security by obscurity, actually does work—as long as you remain obscured. And therein lies the problem. Because as those of us who have Googled ourselves know, it can be very difficult to remain invisible in today’s world. Invisibility certainly doesn’t hurt, but it is not sufficient. You must plan for the day that it fails.

I once saw a stand-up comic whose act consisted, in part, of convincing audience members to loan him something personal, like a wallet or purse, on some innocuous pretense, only to rifle through the contents in public to get laughs at the expense of that person. He managed to get a woman’s purse and started pulling things out, but when the first thing he found turned out to be a .38 caliber police handgun, he very wisely and quickly replaced it, closed the purse, handed it back to the woman, and moved on to the next part of the act.

Creating barriers that convince potential intruders that it is really unwise to continue is an excellent way of deterring some attackers. Telling them they will be monitored is nice, but demonstrating in some way that they really are being monitored is even better. You can take this too far, of course. Counterattacking an intruder, while tempting, is almost always a really bad idea. Why? Well, besides legal and ethical reasons, there is a good chance that it will actually increase their motivation to attack you. It becomes personal!

Imagine how your defenses appear to an attacker. In fact, you should try them out yourself and learn first-hand. Do they seem like a video game, urging players to try for ever-higher scores? Or do they make you seem cold, implacable, and serious, with no sense of humor and a big team of detectives and lawyers just waiting for someone foolish to step in the trap?

Which of those images would make you want to try again? Which would make you want to move away quietly, never to return?

Opportunity. We want to minimize the opportunities that an attacker has to attempt a penetration. What does an opportunity look like? It could be as simple as a program accidentally left running on an Internet-exposed network port. Or it could be a whiteboard visible through a window, or a white paper that is a bit too honest about the network design. It could even be something as indirect as an executive who lets his or her children play games on a company-issued laptop. It could be the temporary but forgotten wireless hub set up for a now-defunct project. It could be some well-known commercial software with a not-so-well-known flaw. It could be a poorly chosen encryption algorithm or a mailroom worker who slips a backup tape in his or her pocket before leaving for the day.

These are the questions we must ask to evaluate opportunity: Do we know all the ways in and out of our network? How can we be sure that we really know them all? How do we know that our network is built the way we think it is built? Have we closed off all unnecessary paths into our network? How do we know that we’ve succeeded in closing them? How do we know that they stay closed? What do we do if conditions change? If a new vulnerability is discovered in previously trustworthy software? If that software is deployed on 1,000 servers?

I remember reporting the results of a detailed security audit to a customer. I began by saying: “Your firewall here in the home office is not bad, but your firewall in Switzerland is terrible!” The president looked at the IT guys. The IT guys looked at each other, and finally somebody said, “What firewall in Switzerland?” It turned out that the company had merged with another company a year before and linked their networks. Nobody had ever noticed that there was a wide-open Internet connection that had never been locked down.

Measuring your network is not enough. You have to keep measuring it, as often as possible, to make sure that nothing has changed. Tools such as Nessus are freely available to do this, but remarkably few people use them to good advantage. Custom tools, if you can afford to create them, are even better, because public tools are available to your attackers as well, but private tools are known only to you and your team.

Which brings us to the most difficult topic of all: insiders. It’s painful to consider, but the people with the most skill, motivation, and opportunity to attack your network are often working for you, and unhappy about some aspect of their jobs or their lives. Some useful questions are: Who do you trust, and with how much? Have those people trusted others with access that we don’t know about? How would we detect if someone abused that trust? How can we limit damage from a misuse of that trust? Do we have any current or ex-employees who can cause problems for our security? Who on our own staff knows enough about our network to be dangerous?

Dealing with the potential for insider attacks in a way that does not alienate those same insiders is tricky, but it can be done. One way is to limit the people with critical access to the smallest number possible, then be bluntly honest with those people and enlist them to help. One way is to have them watch each other. It sounds draconian, but it’s used in a number of sensitive situations. For example, the military employs a two-man rule, or a no-lone-zone approach, in which certain functions must be performed by two authorized people, side by side.

Probably the best way to deal with this problem is to keep the people who can cause a security problem for you happy and engaged and aware of the potential for trouble—and the consequences of a breach. Use their creativity and good will to improve your security.

Tying It All Together

Our second major goal, deciding how much effort to expend on any given security measure, suggests that no technical project lives in a vacuum. The political and financial ramifications of any technical decision often weigh heavily on what is actually built. So for any particular security measure, a network designer must consider questions such as these: How much are we willing to pay for this security measure? Will our user base accept the security measures we think are necessary? Do they believe these measures are necessary? Will the improvement in security justify the cost? How will we know that our security measures are really working?

One of the odd aspects of security work is that it can be very difficult to cost-justify if it is successful. If your car was not stolen last week and you had a steering wheel lock, is the lack of theft because of the lock, or because nobody was trying to steal it? It’s tough to know unless we have some way of measuring how many times an attack was attempted or contemplated. Measuring the system and knowing if it is working, and if we are really under attack, helps us get some sense that we are getting what we paid for.

Consider the following questions:

What metrics tell us that attacks have been attempted?

What characterizes an attack?

What differentiates real attacks from accidents or unintentional attacks?
What is the false-positive rate of our detection mechanisms?
Who or what is responsible for reading the logs?
How does the detection of an attack feed into our security response strategy?
How can we characterize attack types and rates over time? How can we measure trends in those characterizations to know if our defenses are working?
How can we detect new types of attacks that will arise in the future? How can we add known attacks to our repertoire of detectable ones? What about future zero-day attacks, whose profiles we don’t know now?

Asking these questions can be a painful process, but the time to ask them is up front, so that we can think about their answers and make our plans accordingly.

Given all these complex questions, we might be tempted to go look for outside help to help sort through the issues. Some questions we should ask about security consultants: Are they playing the FUD (fear, uncertainty, and doubt) card? Do they offer guarantees or certainty? (If so, double-check their credentials.) Are we getting a real analysis of our network, or just the (possibly reformatted) output of off-the-shelf scanning tools? Do they offer to fix the problems they are diagnosing? If so, how do we know that they have told us all the problems they have found? Maybe they just listed the ones they can fix...

Why is security hard? Well, to paraphrase Albert Einstein, the questions generally remain the same, but the answers change all the time.

THOMAS A. WADLOW is a network and computer security consultant and author of The Process of Network Security

Originally published in Queue vol. 3, no. 5—
Comment on this article in the ACM Digital Library