Apperently, the growth of the number of disclosed vulnerabilities are declining. As usuall, these kind of statistics follows with alot of speculations of what this means for security. A common idea is that fewer disclosed vulnerabilities must mean we are more secure, right?

While at it, let me speculate some too. From a hackers perspective, the most valuable vulnerability is the one no-one else knows, right? Such a vulnerability, if in the “right” (from our perspective, wrong) piece of code, would let a hacker walk in through the front door of many targets. With money to gain from stealing company secrets, identity information and credit card details, it’s relatively obvious that vulnerabilities themselves have more value today than earlier. The decline in disclosed vulnerabilities could just as easily be a result of an increased care, focus and determination within the underground. For use in targeted, more sophisticated attacks. There is no easy way for us to know exactly, and that is why drawing conclusions of the state of security from statistics of vulnerabilities is far to simplistic.

This kind of mindset reminds me of a speech I heard from the CSO of a large financial company here in Sweden: “We measure our security on the number of security incidents we have a year”. I instantly thought, “That says nothing. How hard are you looking?”.

I was directed to a great document on some theory of detection and prevention - or as the author likes to compare it with: solving mysteries and puzzles.

Puzzles can be solved; they have answers. But a mystery offers no such comfort. It poses a question that has no definitive answer because the answer is contingent; it depends on a future interaction of many factors, known and unknown

This is interesting:

Solving puzzles is useful for detection. But framing mysteries is necessary for prevention.

A great example of the issues of prevention of unknown vulnerabilities:

To analysts in the Pentagon, for instance, terrorists present the ultimate asymmetric threat. But the nature of the threat is a mystery, not a puzzle. Terrorists shape themselves to our vulnerabilities, to the seams in our defenses; the threat they pose depends on us. The 9/11 hijackers, for instance, did not come to their plan of attack because they were aviation buffs. They came to it because they had identified gaps in our aviation defenses.

Why we need to look for indications of suspicious activity, at different places, and correlate these:

By contrast, mysteries often grow out of too much information. Until the 9/11 hijackers actually boarded their airplanes, their plan was a mystery, the clues to which were buried in too much “noise�—too many threat scenarios. So warnings from FBI agents in Minneapolis and Phoenix went unexplored. The hijackers were able to hide in plain sight. After the attacks, they became a puzzle: it was easy to pick up their trail.

Finally on how medicine, which is very similar to reactive security efforts, correlates indications before they give treatment:

Doctors base an initial assessment of a patient’s health on propensity, as revealed by his or her medical history, and on diagnosis, determined through an examination. If the doctor’s initial assessment is of a high probability of disease, he or she orders more tests, which in turn refine that probability. For chronic concerns, such as high blood pressure leading to heart disease, the initial assessment leads to a decision about whether and how to treat, followed by subsequent tests to see if the original probability of problems can be revised downward.

There is no coincidance that a certain IPS-vendor claims their IPS to be a “DigitalVaccine”. Only, they apply their cure only by looking at a single packet. That perhaps why they sometimes get it wrong - all IPS products in some sense do. And in some cases, as with medicine and cure of a human with a decease, gettings things wrong isn’t acceptable - it could render in a even worse condition, death or block of absolutely bussiness critical traffic. But there are products that functions more like doctors.

Encrypted and encoded traffic has always been one of the troubles for IDS/IPS systems to handle. A vulnerability was disclosed last week, related to the encoding issue, affecting many systems that does some sort of content inspection of the HTTP-protocol. From the advisory:

Full-width and half-width encoding is a technique for encoding Unicode characters. Various HTTP content scanning systems fail to properly scan full-width/half-width Unicode encoded HTTP traffic. By sending specially-crafted HTTP traffic to a vulnerable content scanning system, an attacker may be able to bypass that content scanning system

Systems affected by the vulnerability includes most commercial and “free” IDS/IPS systems, including Snort, Bro, TippingPoint and ISS - and disables their detection/protection for attacks mounted in HTTP-sessions.

Interop (as in: “just another vendor conference”) is currently running at the other side of the pond. This is a conference were its common for vendors to release their new silver-bullet products - and IDS/IPS vendors is not an exception. The strange thing with many of the vendors of IDS/IPS-products, is that they seem to focus on relatively irrelevant features - not on these kind of issues that could increase their ability to detect and actually prevent intrusions. They seem to think that the biggest issue with their technology, or the greatest improvement, is to increase the speed at which the devices can inspect and block traffic. ISS is battling Tippingpoint, who can currently operate their IPS at 5 gbit speeds, with a system that can now run at 15 gbit (which in reality means more like 6 gbit). Still, no body with the intention of buying and IDS/IPS for getting increased security should let speed be deciding factor. These people might just as well look at a an firewall with some sort of novel deep inspection.

The Swedish part of IDG today has a story about a Swedish company, Direct, who offers insurance for IT-related accidents. The insurance claims to cover damages caused by for instance intrusions and compromises, as well as accidents. I guess most larger companies have insurances that cover similar damages, but this insurance is according to the insurance company targeted at small and medium size bussinesses.

The insurance company exemplifies the use of the insurance by saying that extorsion-based attacks can now simply be paid off - Wow, that’s a good way to solve incidents. What about pressing charges? Most insurances need a police report too, so how will that work?

I like the idea though. But these kind of insurances are still ahead of its time. First, I’d like to see a law, similar to those in California, that requires companies by law to report security breaches. Today, incidents largely go unnoticed from the public, which means that the demand for this kind of insurance will be low - despite of what the insurance company in question says.

One of the things that is crucial of an IDS/IPS is the ability to get more information about an attack than just the alerts. An alert won’t, by itself, serve well as evidence in the court. It won’t tell you what really happened either. At the point when a truly critical alert is fired, you will wan’t to look at the detals. Who did it? What did he do? Can we prove it?

The IDS/IPS from Juniper Networks, a.k.a. IDP, has Tcpdump available on the sensors, but also a self-developed script that does log rotating of Tcpdump captures in a nice way. This makes the IDP an ideal platform for dumping real time network traffic in “ring buffer mode”. Which essentially mean that we can, in an automated fashion, store packet captures for a specified time back in history.

The script, called dumpLoop, uses Tcpdump for packet capture and can be configured in numerous ways, depending on how long back in time you’d want captures for etc. Here what executing dumpLoop looks like, configured to capture on interface eth2, saving 5 files, each being a hundred megabytes.

[root@defaulthost admin]# dumpLoop -i eth2 -k 5 -s 100000000
Starting loop.
Checking capture filesize...
File nofile.cap does not exist.
...size check complete.
Rotating tcpdump...
New filename:200705111455_eth2.cap
Starting new... (tcpdump -n -i eth2 -s 0 -w 200705111455_eth2.cap )...
tcpdump: WARNING: eth2: no IPv4 address assigned
tcpdump: listening on eth2
Reset PID...
New PID is 7706.
...rotation complete.
...check complete.
Checking log count...
Keeping 200705111455_eth2.cap
...end log count check.
Break to exit.
Checking capture filesize...

This configuration allows us to have 500 megs of traffic captures, which is basically a few hours on a moderately busy link. The files are stored in the current working directory and is named in a good way that describes when the capture started and on what interface. A log file of the process shown above is also written to disk as seen below

[root@defaulthost admin]# ls -lh
total 1.3M
-rw------- 1 root root 1.3M May 11 14:56 200705111455_eth2.cap
-rw------- 1 root root 392 May 11 14:56 dumpLoop_200705111455.log

Replaying the contents of the capture is as easy as letting tcpdump read the file, using the f-flag.

[root@defaulthost admin]# tcpdump -r 200705111455_eth2.cap
14:55:39.286474 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: . 14981:16441(1460) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.286479 802.1Q vlan#4093 P0 X.X.X.63.1514 > X.X.X.9.rtsp: . ack 16441 win 65535 (DF)
14:55:39.286486 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: . 16441:17901(1460) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.286491 802.1Q vlan#100 P0 X.X.X.9.rtsp > X.X.X.63.1514: P 17901:18028(127) ack 1 win 64785 (DF) [tos 0x70]
14:55:39.288620 802.1Q vlan#4093 P0 X.X.X.63.1514 > X.X.X.9.rtsp: . ack 18028 win 65535 (DF)
14:55:39.389889 802.1Q vlan#4093 P0 X.X.X.57.2412 > X.X.X.58.1863: . ack 320 win 64508 (DF)

If other tools suits the analysis better, such as Wireshark, Tshark or Argus, the captured files could of course be copied to another system.

A few weeks ago Bruce Schneier asked himself wheather the security industry is really necessary. If systems were naturally secure, security products and services wouldn’t be needed, right?

Problem is, not all security problems and vulnerabilities come from implementation or design errors. So, what constitutes a secure product? Is it zero vulnerabilities? Defense against bruteforcing the authentication? Ability to disallow actions that might cause harm to another system? It’s certainly problematic to define, even harder to implement.

For the sake of discussion, lets picture a product that is “secure by default”. Does that mean it will always be? We can’t be sure. I believe it’s just a matter of how hard we look, and without the security industry all we can be certain about is that we won’t look that hard. Sure, there would be no publically known vulnerabilities - but does that mean there aren’t any?

You still there? :)

I sure am. And while having been away from writing on the blog for almost a year now, I’m looking forward to using this blog in the future as I did in the past. The past year has been busy with finishing school, starting working etc.

Nothing much has changed with regards to Security. Software is still like swiss cheese. Still, companies generally aren’t that concerned with security - It wont happen to us right? Why would anyone target a Swedish company? That never happens… Luckily, this is what keeps me busy all day - and probably will for some time.

Expect me to be a bit more active here in the future than I have been in the past.