Risk Mitigation

If you've been following the last few days of posts, I've been thinking about security from a more general level. I've been wondering how we can mitigate risks in a digital world where the following features are appearing in nearly every digital device.

Think about digital devices in your possession and see if you agree with this characterization of their development. Digital devices are increasingly:

• Autonomous: This means they act on their own, often without user confirmation. They are self-updating (downloading patches, firmware) and self-configuring (think zeroconf in IPv6). Users could potentially alter this behavior, but probably not without breaking functionality.


• Powerful: A cell phone is becoming as robust as a laptop. Almost any platform will be able to offer a shell to those who can solicit it . There is no way to prevent this development -- and would we really want to?


• Ubiquitous: Embedded devices are everywhere. You cannot buy a car without one. I expect my next big home appliance to have network connectivity. Users can't do much about some of these developments.


• Connected: Everything will be assigned an IPv4 (or soon) an IPv6 address. Distance is seldom a problem. Every digital maniac is a few hops away.


• Complex: I am scared by the thought of running Windows Mobile on my next phone. Can I avoid it? Probably not. How many lines of code are running on that mini-PC -- I mean "phone" -- I'll be using?

In my opinion, this digital world is increasingly resembling the analog one. In fact, those five attributes could describe people as easily as complex machines!

The key factor in this new world will not be static vulnerabilities, but dynamic threats. The number of opportunities for threats to play havoc will vastly dwarf the chances for defenders to address vulnerabilities.

Think about how we deal with security in a typical city. I call it the "local police model."

• Police can never prevent all crimes, although they can try.


• Police more often respond to crimes. They proceed to track and jail criminals.


• By prosecuting criminals, the justice system removes threats.


• No one spends time or money putting bars on windows or replacing door locks in the average suburban neighborhood.


• Crime still happens, but society survives as long as the level of crime is acceptable.

Why did a police model rise? Back in the cave man days, we lived in tribes. If you didn't belong to my tribe, I could beat you back with my club. As societies evolved, communication and ties between tribes prevented this simple model from working. More sophisticated threats with ingenious attacks (e.g., white collar crime) took advantage of these social ties.

Guess what -- this is where we are now in the digital world. Once upon a time you might have been able to restrict access based on trusted IPs. Then you had to shut down ports that couldn't be shared. Now we do business with everyone, and I can't be sure that the Microsoft SMB/CIFS that I'm exchanging with a business partner is normal or malicious when I use a standard access control device.

A threat-centric approach to security has served the analog world well enough. I think that is the only way to move forward as the digital world becomes as complex as the analog.

One more thought: The number of assets continues to rise. The number of vulnerabilities in those assets continues to rise. The number of threats continues to rise. The ability of security experts to apply countermeasures can not keep pace with this world. Is it time for autonomous agents to work on behalf of "the good guys?" I am beginning to agree with Dave Aitel's idea of nematodes that act on behalf of human agents.

It is becoming increasingly difficult for humans to even understand the digital environment. The only real way to know exploitation is not possible is for exploitation to be tried and then found to fail. Nematode agents may roam the network constantly testing intrusion scenarios and reporting their progress. Perhaps next-generation detection devices will monitor nematode activity. When they see another agent that is not a registered nematode exploit a target, that will be the sign that an intrusion has occurred.

Read More

Analog Security is Threat-Centric

If you were to pass the dark alley in the image at left, I doubt you would want to enter it. You could imagine all sorts of nasty encounters that might deprive you of property, limb, or life. Yet, few people can imagine the sorts of danger they encounter when using a public PC terminal, or connecting to a wireless access point, or visiting a malicious Web site with a vulnerable browser.

This is the problem with envisaging risk that I discussed earlier this week. Furthermore, security in the analog world is much threat-centric. If I'm walking near or in a dark alley, and I see a shady character, I sense risk. I don't walk down the street checking myself for vulnerabilities, ignoring the threats watching me. ("Exposed neck? Could get hurt there. Bare hands? Might get burnt by acid." Etc...)

It seems like the digital security model is like an unarmed combatant in a war zone. Survivability is determined solely by vulnerability exposure, the attractiveness of one's assets to a threat, and any countermeasures that might disrupt threats.

In the analog world, one can employ a variety of tactics to improve survivability. Avoiding risky areas is the easiest, but let's assume one has to enter dangerous locations. A potential victim could arm himself, either using a weapon or martial arts. He could travel in groups, hire a bodyguard, or enlist the police's aid.

The term "hack-back" crops up in the digital scenario. This is really not a useful approach, because hacking the system attacking you does absolutely nothing to address the real threat -- the criminal at the keyboard.

In the analog world, consider the consequences for "hacking back." If you shoot an assailant, you'll have to explain yourself to the police or potentially a court of law. You probably can't shoot someone for simply being on your property, but you can if they threaten or try to harm you.

On a related note, we need some means to estimate threat level in a systematic, repeatable manner. When I say "threat" I mean threat, not vulnerability. Something like a system of distributed honeypots with distinct configurations might be helpful. Time-to-exploit for a given patch set might be tracked. I know the Honeynet Project periodically issues reports on how long it takes to 0wn a box, but it might be neat to see this in a regular, formal manner.

Read More

Why Prevention Can Never Completely Replace Detection

So-called intrusion prevention systems (IPS) are all the rage. Since the 2003 Gartner report declaring intrusion detection systems (IDS) dead, the IPS has been seen as the "natural evolution" of IDS technology. If you can detect an attack, goes a popular line of reasoning, why can't (or shouldn't) you stop it? Here are a few thoughts on this issue.

People who make this argument assume that prevention is an activity with zero cost or down side. The reality is that the prevention action might just as easily stop legitimate traffic. Someone has to decide what level of interruption is acceptible. For many enterprises -- especially those where interruption equals lost revenue -- IPS is a non-starter. (Shoot, I've dealt with companies that tolerated known intrusions for years because they didn't want to "impact" the network!)

If you're not allowed to interrupt traffic, what is the remaining course of action? The answer is inspection, followed by manual analysis and response. If a human decides the problem is severe enough to warrant interruption, then a preventative measure is deployed.

In some places, prevention is too difficult or costly. I would like to know how one could use a network-based control mechanism to stop a host A on switch X from exploiting host B on switch X. Unless the switch itself enforces security controls, there is no way to prevent this activity. However, a sensor on switch X's SPAN port could detect and report this malicious activity.

Note that I think we will see this sort of access control move into switches. It's another question whether anyone will activate these features.

I think traffic inspection is best used at boundaries between trusted systems. Enforcement systems make sense at boundaries between trusted and untrusted systems. Note that if you don't trust individual hosts inside your organization (for whatever reason), you should enforce control on a per-host basis within the access switch.

Read More

Thoughts on Patching

As I continue through my list of security notes, I thought I would share a few ideas here. I recorded these while seeing Ron Gula discuss vulnerability management at RMISC.

Many people recommend automated patching, at least for desktops. In the enterprise, some people believe patches should be tested prior to rollout. This sounds like automated patching must be disabled. I'm wondering if anyoen has implemented delayed automated patching. In other words, automatic updates are enabled, but with a two or three day delay.

Those two or three days give the enterprise security group time to test the patch. If everything is ok, they let the automated patch proceed. If the patch breaks something critical, they instruct the desktops to not install the patch until further orders. I think this approach strikes a good balance since I would prefer to have automated patch installation be the default tactic, not manual installation.

Determining which systems are vulnerable results in imagining a continuum of assessment tactics.

• At the most unobtrusive level we have a "paper review" of an inventory of systems and their reported patch levels.


• Next comes passive assessment of traffic to and from clients and servers.


• Traditional vulnerability scanning, without logging in to the target, is the next least obtrusive way to assess hosts.


• Logging in to a host with credentials is another option.


• Installing an agent on the host is a medium-impact approach.


• Exploiting the host is the final way to definitively see if a host is vulnerable.

On a related note, Ron mentioned that the costs of demonstrating compliance far exceed those of maintaining compliance. This is sad. Ron also noted he believes auditors should work for the CFO and not the CIO. I agree.

Read More

Return on Security Investment

Just today I mentioned that there is no such thing as return on security investment (ROSI). I was saying this two years ago. As I was reviewing my notes, I remembered one true case of ROSI: the film Road House. If you've never seen it, you're in for a treat. It's amazing that this masterpiece is only separated by four years from Swayze's other classic, Red Dawn. (Best quote from Red Dawn: A member of an elite paramilitary organization: "Eagle Scouts.")

In Road House, Swayze plays a "cooler" -- a bouncer who cleans up unruly bars. He's hired to remove the riff raff from the "Double Deuce," a bar so rough the band is protected by a chicken wire fence! I personally would have hired Jackie Chan, but that's a story for another day. Swayze's character indeed fights his way through a variety of local toughs, in the process allowing classier and richer patrons to frequent the Double Deuce. The owner clearly sees a ROSI; the money he pays Swayze is certainly less than the amount he now receives from a more upscale establishment.

Is there a lesson to be drawn for the digital security world? Notice the focus on threats. The Double Deuce owner didn't hire Swayze to build higher walls or cover windows with iron bars. Instead of addressing vulnerabilities, he sought threat removal. This is not a process the average company can implement; usually law enforcement and intelligence agencies have this power.

I have heard the term "friendly force presence" being used within certain military circles. This seems to refer to keeping assessment teams on the lookout for indications of the adversary on our networks. This certainly works in the physical world, but it may be difficult to translate into the virtual one.

One example: when I visited Ottawa recently, I stopped at a McDonald's to get a quick meal. The place was teeming with teenagers, most of whom were just lounging around. I considered leaving because the place was so full. I saw a manager appear a few minutes after I arrived, and with him came a uniformed police officer. The officer had a word with one or two of the larger teens and suddenly the restaurant started to empty. Within five minutes hardly anyone was left, and no one under the age of 18. It was amazing.

Read More

Two Good IEEE Security and Privacy Articles

One of my favorite aspects of attending USENIX conferences is receiving free copies of magazines like IEEE Security and Privacy. The March/April 2005 issue (ok, I'm way behind when I use the freebie method) features two articles that might be interesting to security folks. First, if you want a good summary of trusted computing, read Protecting Client Privacy with Trusted Computing at the Server (.pdf). To get insights on the differences between computer science and computer engineering, try Turing is from Mars, Shannon in from Venus (.pdf). Since Dartmouth faculty wrote both articles, they're published free through dartmouth.edu.

Read More

GAO Hammers Common Criteria

I've written about Common Critera before. If you also think CC is a waste of money, read GAO: Common Criteria Is Not Common Enough by Michael Arnone. It summarizes and comments upon a report by the Government Accounting Office titled INFORMATION ASSURANCE: National Partnership Offers Benefits, but Faces Considerable Challenges. Mr. Arnone writes:

GAO also criticized the National Information Assurance Partnership (NIAP) for not providing metrics or evidence that the Common Criteria actually improves product security. In addition, the Common Criteria process takes so long to complete that agencies often find that the products they need are not on the list of certified offerings or that only older versions have been accredited, GAO’s report states...

Pescatore said GAO’s call for increased education and awareness of NIAP’s function is overblown. Large vendors already know the process well and can afford millions of dollars for tailor-made product evaluations, he said.

Any education efforts should target smaller vendors — with $10 million to $50 million a year in annual revenue — that don’t know about the NIAP process, don’t know how expensive it is and have trouble affording it, Pescatore said. NIAP must do more than educate, he added. It must provide subsidies or reduce prices so smaller vendors can participate, he said.

It sounds like Common Criteria is becoming nothing but a hurdle to keep smaller companies from providing products to government agencies.

Read More