Esphion

A better alternative to full-drive encryption?

One of the few blogs I am reading regularly is the one by Bruce Schneier. In a recent entry, he mentions a new hard-drive, which provides full encryption of all contents. However, I think that encrypted container files have several advantages over fully-encrypted drives, like the one he is mentioning.

As a laptop user, I am certainly very much interested in securing the data on my drive. However, I have always viewed full drive encryption somewhat skeptically. I much prefer to use a software solution, which created an encrypted container-file, but which can be mounted like a file-system. Essentially, these programs install as drivers, which ask for a password and then make the file-system inside of that container file available to you, just like any other new drive. Under Windows, for example, a new drive with its own drive letter would appear. Everything stored in that drive is automatically encrypted. All of this happens completely transparently to the applications on your computer. Once you unmount the encrypted 'drive' again, the drive letter disappears and all you have left is that container-file, which is of course encrypted.

Some examples of these programs are DriveCrypt, or Jetico's BestCrypt. Personally, I use BestCrypt. I really like it, because my laptop is dual-boot: Linux and Windows. BestCrypt allows me access to the encrypted data from both sides, which is nice.

There are two key advantages, which I see with the encrypted container files:

1. Backing up your important data is amazingly easy. In fact, for me a complete backup of all my e-mail, addresses, calendar and documents is done in a single drag-and-drop operation, without the need for any additional backup-management software. How? Just drop that single container file onto the office file-server, and it is all done. Since the file is entirely encrypted, it does not even matter if anyone else has access to it.
2. I can give my laptop to tech-support, without having to give them the password to the encrypted partition. If your entire drive is encrypted then nothing will work, unless that password is provided. Even your own tech-support or system administrator will not be able to fix your machine or work on it, unless you stay with them to type in the password after every reboot, or if you tell them the password. And even more: The admin may come across some of the confidential information you have on your drive, while helping you. Since the drive is unlocked in its entirety, this is quite possible. However, with the encrypted partition / container-file, you just unmount that partition and all the confidential data disappears. The admin can work on your laptop all they want, they still won't see the data. Not even by accident.

For those reasons, I personally prefer the software solution with encrypted container files. I understand that there are possibly some things to consider, like the location of temporary files, for example. But with some care, those issues can be addressed.

Juergen

Where is the right place to deploy anomaly detection?

A network-based anomaly detection (NBAD) system can detect network events, which are beyond the capabilities of traditional network security systems, such as IPSs and firewalls. Some areas of specific strength for NBAD systems are distributed denial of service (DDoS) attacks, worm outbreaks, or other such anomalies manifesting themselves in the network traffic. When we talk to our customers, we recommend placement of our NBAD solution, Esphion netDeFlect(r), based on what concerns them most.

For example, if a web-hoster wants to protect their network from incoming DDoS attacks, it is important to place the NBAD system outside of their firewalls. Why? Because a firewall may filter some of the DDoS traffic. A stateful firewall will not allow any packets to pass through, which do not belong to an already established connection. An exception may be made for those packets that start a new connection, such as TCP-Syn packets to port 80, in case of a web-hoster. Since many DDoS attacks use randomized source addresses, and may use packets other than TCP-Syn on port 80 (just to continue with the simple example), the packets used in the flood may actually be blocked. It is easy to see that this is not a sufficient defense, since the access links are already filled up, or the firewall may be overloaded. For the web-hoster, it is important to detect the attack quickly, and to get detailed filter recommendations, which can then be passed on to the upstream equipment for more efficient filtering.

If the NBAD solution would have been deployed behind the firewall, it would not have seen the anomalous traffic at all in this example. Therefore, if you want to detect incoming DDoS attacks, the anomaly detection solution should be placed outside of the firewalls, where we can be sure that we get complete insight into all the traffic.

The story is entirely different for someone concerned about the detection of worm outbreaks in their network.

As I discussed in previous postings, a worm may appear in the network at any time and at any place. The biggest threat is what has been known as the dissolving perimeter. With the dissolving perimeter, we cannot rely solely on perimeter defenses, such as firewalls and IPSs. The ubiquity of mobile devices, or extranet connections that need to be provided to business partners, or the presence of wireless access points - all of this causes more and more poorly defined demarcation lines between 'trusted' and 'untrusted' parts of the network space.

In my posting about network self-vaccination, I tried to point out that we need an adaptive security system, which can detect if something happens within the network and that allows the network to adapt and defend itself. Therefore, if the detection of worm outbreaks is important then the NBAD solution should be deployed deep within the network. That is where a worm will start to scan or spread, and that is where it needs to be detected. The same firewall that might block incoming DDoS traffic might also block outgoing scans of the worm. Therefore, an NBAD solution that is placed outside of that firewall will only have limited success in detecting an internal worm outbreak.

To sum it all up: NBAD is a great way to detect some of today's most pressing network and security impacting events. However, choosing the right place to deploy them is important: For DDoS attacks, deploy outside of the firewalls. For worm outbreaks, deploy deep inside of your network.

Juergen Brendel
CTO
Esphion Ltd.

Writing down passwords?

Recently there has been a renewed discussion about password security. The latest surge of interest was caused by a comment from Microsoft's Jesper Johansson, who recommended that people actually write down their various passwords. I think there might be a better way, though.

We all require a large number of passwords on a daily basis, and for obvious reasons are not supposed to use the same password for everything. Therefore, we need to remember a large number of strong passwords.

Writing passwords on a piece of paper has long been frowned upon, and many corporate security policies explicitly prohibit this practice. But according to Mr. Johansson, it is better to have complex and strong passwords than simple and weak ones. Since complex and secure passwords normally are difficult to remember, people need to write them down. If we prohibit them from writing them down then people will not use them, and revert back to the simple ones. And simple passwords are vulnerable to dictionary attacks. In his latest blog entry, even Bruce Schneier chimes in with support for this idea. He recommends we keep this list of passwords in our wallet.

This makes the wallet a single point of failure, of course. Personally, I think the situation can be improved, without using paper.

I use unique passwords for all sites and accounts, and yet, I never need to write them down, and I don't even need to remember them. All I remember is a hash function. When I need to log in somewhere, I take the name of the site I am logging in, apply my hash function and get a unique identifier, which I use as a password.

Here is an example to illustrate this:

Let's say you are a PayPal user, and want to log into your account.  The name of the site is 'paypal.com'. Let's take an extremely simple hash function as an example:

Take the site-name, extract the first, last and middle letter, count the number of letters in the name, capitalize the last letter if the number is even, and append that to a special filler string "rD7eI".

'paypal.com' consists of 10 characters, with the middle (in integer arithmetic) being 5. So, the three letters are 'p', 'a', and 'm'. The overall number of characters is even, and thus we capitalize the last letter: 'M'. What we get then for 'paypal.com' is this password: rD7eIpaM

Now this is pretty random looking.

What did I have to remember to arrive at this password? My hash function, which may contain one or more of those random looking filler strings. But that is all.

The secret is the hash function, and it is the only secret that needs to be remembered. To make this a secure system, though, the hash function should be a bit more complex. Otherwise, if one of your many passwords is compromised, an attacker may be able to reverse engineer your hash function. Realistically, this is only a risk if the attacker manages to compromise several of your passwords, though.

With a little bit of thought, it should be possible for most of us to come up with a personal hash function, which produces very random looking results.

Juergen Brendel
CTO
Esphion Ltd.

Network self-vaccination: Applying the biological model of the adaptive immune system to networks

Much of today's network security architecture relies on signature-based solutions, such as IPSs (Intrusion Prevention Systems), IDSs (Intrusion Detection Systems) and firewalls. If you have read my previous blog-entries, you know my opinion about the signature-based approach. To sum it up: These signatures come from certain network security operations centers, run by the various vendors. The people working there do a great job, but it still takes them a couple of hours to crank out a new signature for a new threat. To top it off, your signature-based device will typically be updated only at certain intervals, which means even more time elapses. So, if a true zero-day anomaly comes around, something that nobody has seen before, or has just started a few hours ago, you will most likely find yourself unprotected.

In addition, this approach completely ignores the threat that arises from anomalies, which are specific to your network. For example, if you are flooded by a DDoS attack, and some attacker chooses a certain kind of packet to flood you with, what do you think the chances are that there is a signature for exactly that kind of packet in someones signature database? Pretty close to zero.

The question then is: How can a network react to new anomalies and threats, once it gets exposed to them? Is it possible for the network to defend itself, without having to wait for some signatures to be sent down by someone else's network security operations center?

Well, yes it is possible, at least for some of the most pressing security concerns, such as worms and DDoS attacks. I call this network self-vaccination. Let's look at an example from nature, in order to explain this. I'm not a biologist or a doctor, so what I'm about to write here may not always use the 100% correct terminology, but I think you will understand what I mean.

Our skin is an important barrier, which protects our body from infection. Without the skin, various microbes could easily enter our body and cause havoc. Even though the skin is a good barrier, a bacteria, parasite or virus may still find a way into our body.

Fortunately, our skin is not the only line of defense that we have: Our immune system can deal with intruders and issues even if they have managed to get into our body. Interestingly enough, it is for the most part capable of handling even brand new (zero day, if you will) diseases. We might get sick, but for the most part, we eventually recover. How is that possible?

Well, the answer lies in the way the immune system works. There is a really great introduction here, but to summarize it: We have an innate immune system and an adaptive immune system. The innate system is made up of genetically pre-programmed defenses, such as the skin (a physical barrier), but also the phagocytic cells, which can devour foreign elements, such as microbes and a couple of other things. The innate immune system therefore is something we have more or less from birth. A pre-programmed set of defenses.

More interesting in our context here is the adaptive immune system, though. What does it do? To quote from the above mentioned Wikipedia article:

[It] ensures that most mammals that survive an initial infection by a pathogen are generally immune to further illness caused by that same pathogen.

Key elements of the adaptive immune system are the leukocytes (white blood cells),  antibodies, T-cells and so on. Using a lot of fascinating bio-chemistry, the adaptive immune system can in effect learn the specific fingerprint of a new microbe or virus. That is, after the foreign body has entered the bloodstream, and an immune response has started (in effect, an infection has already occurred), it can then learn how to defend itself better the next time. So, the adaptive immune system does not prevent an infection the first time around, but it can do a good job the second time it sees the same problem.

This is, of course, exactly the principle behind vaccination: Expose the organism to the disease in a way that the organism can survive, and the acquired immune response will be able to defend the organism from then on. The organism is immunized.

So, how does all of this relate to networks?

Well, modern threats to network security can come from any direction. As we have all heard before, the network perimeter is dissolving, which means that any defense at that perimeter is only effective to a certain extent. Compare the firewall or IPS on the Internet access links to the defense offered by the skin. These devices also rely on prior knowledge about how to react to specific conditions or signatures, and thus could be compared (to some degree) with the innate immune system.

However, mobile devices or browser-based exploits allow malware to appear right in the middle of the network at any point and at any time. What do we have in place to defend against that? Since a mobile device may have been infected already before it is even connected to our network, it is difficult to guarantee that there is never going to be an outbreak of some kind in a network. Nevertheless, most organizations completely ignore this threat to their network infrastructure. And as we have seen, even the perimeter defense is powerless when confronted with zero-day anomalies, such as site-specific DDoS attacks.

What most organizations have today is only the equivalent of the skin, a portion of the innate immune system. But these days, this is not enough anymore. What we need is an adaptive immune system for networks. It needs to fulfill three basic requirements:

• Automatically able to detect an anomaly that appears within the network.
• Autonomously able to get a handle on the anomaly (a fingerprint) so that it is possible to characterize and identify it when we see it.
• Use these fingerprints to defend against the anomaly, using the already existing infrastructure of the network.

We can see a lot of similarity to the adaptive immune system from biology in that description. The most important point obviously is the detection of the anomaly. For this, the observation sensors of this adaptive network immune system are not only on the perimeter (where they can detect DDoS attacks, for example), but also right in the middle of the network, where they can observe the internal traffic. The ability to detect an attack within the network (organism) is important, which is why the biological adaptive immune system does not sit on the skin, but is present everywhere in our body.

The second point then describes the adaptability of the system: It sees a new anomaly, and can automatically learn the fingerprint for it, even though it may never have seen it before. Sophisticated algorithms can do this for network traffic, and we have implemented them in our solutions.

The last point is interesting: Use the existing network infrastructure for defense. Why is that? Well, the existing network infrastructure (routers, switches, firewalls, IPSs) often has the ability to filter traffic, or at least to isolate an infected host. Thus, without having to invest in expensive inline devices, which just add latency and points of failure, this adaptive immune system simply provides fingerprints / signatures which can be applied to the existing infrastructure elements. This effectively stops the anomaly right at the source. Even if a worm-infected laptop is connected into the company network, it is instantly detected and isolated or the offending traffic is simply filtered out. Since this is important, our system can produce actionable filter instructions for a variety of different network devices.

The network therefore has observed an anomaly, and has learned automatically to recognize it and to shut it out, without relying on pre-existing signatures. As we know, time is of the essence (see my previous blog entry) and so, in our solution all of this happens within just a few seconds, even for deliberately slow-scanning worms.

Just like our body, the network in effect used an adaptive immune system for defense. A network with such a security system in place, is capable of self-vaccination.  And that is what it takes these days.

Juergen Brendel
CTO
www.esphion.com

Network traffic surgery - Or: How to remove bad traffic with fine-grained signatures

One of the problems that many organizations have when being faced with network anomalies, such as DDoS attacks and worm outbreaks, is the fact that it is hard to remove the traffic from their network, while keeping the business running.

It is quite astonishing to me how many vendors of security solutions are touting their products with claims about anomaly detection and filtering capabilities. At the same time, though, their wares are woefully ill equipped to actually provide the kind of insight into the anomaly traffic that is required to really allow for the surgical removal of that traffic. For the most part, any filters those solutions can implement or suggest represent a broad ax when really a fine scalpel is called for.

Let's consider an example: An e-commerce web-site is under a TCP-Syn attack on port 80.  So, what traffic should be removed now? The traffic to the web-site (identified by IP address and/or port)? The service provider may think so, since this would keep their network operational. However, the owner of the attacked site clearly has different priorities.

Should all TCP-Syn packets to that site's IP address and port be filtered out? This would not be ideal either, since any new, legitimate connection to the site would be prevented.

Now, we have to keep in mind that many of the solutions out there in the market, who claim to protect against zero-day anomalies by means of behavioral anomaly detection, only provide such impractically broad filters. Let us examine why this is the case.

Most of the solutions are based on the processing of flow records, such as Cisco's Netflow, for example. There is no doubt that flows are useful for many things. However, one thing they are terribly inadequate for is as a source of information to provide truly fine-grained filter suggestions and signatures for network anomalies.

A flow, we need to remember, is a summary record about a connection (actually only about one direction of a connection) between two hosts. So, it contains information as to when the connection started, when it stopped, which IP addresses where involved, which protocol and port, as well as byte and packet counts. Once the connection is closed, or timed out, the flow-generating device, typically routers, will pack the flow into a packet, along with a couple of other flows, and send it to a registered flow consumer. The flow consumer typically is a server, which receives the flow records and performs some processing on them.

Many network behavioral anomaly detection (NBAD) solutions are based on flows. We can see, though, that the NBAD server is quite far removed from the actual anomalous traffic. It only receives an abstraction, or summary, of what really happened on the wire. It has no insight into the actual traffic. It has no means to collect packet samples. Thus, all it can base it's 'filter' suggestions on is the information contained in the flow records.

Well, and that information only allows for IP addresses, ports and protocols. Sometimes some flag information can be gleaned from the record as well, but as we have seen, that does not help much.

So, assume then that e-commerce site www.mybigbusiness.com has invested in such a flow-based NBAD solution. Now they are under the TCP-Syn attack we have mentioned earlier. They look to their shiny, new security product for help, and what do they see?  They see a recommendation like this:

        You are under TCP-Syn attack.
        Filter all TCP-Syn packets to www.mybigbusiness.com on port 80.

If they were to follow that recommendation, My-Big-Business would be out of business in a hurry.

Clearly, something better is needed.

I contend that flow-based analysis of network anomalies only gets you a part of the solution. Much more insight into the actual traffic is needed. That's why we here at Esphion are big advocates of packet-based NBAD.

In a packet-based approach, you don't rely on third-party summary information, such as flow records, but look at the actual culprit, the actual offending packets, directly and immediately. A packet-based NBAD solution therefore will sit right there where it matters: In the network, listening to the traffic on a spanning port or even via a network tap.

So, what can we see if we do that? We can see any characteristics, which further identifies and differentiates the offending packets from the legitimate packets. Essentially it goes like this:

1. We know that there is an anomaly (we have specialized neural networks that can detect those very nicely).
2. We know how many bad packets we currently see per second.
3. We take a sample of the actual traffic (in the case of the Syn flood, we would take a sample of all TCP Syn packets to www.mybigbusiness.com).
4. We then run those special algorithms over that sample, in order to find a fine-grained signature, which takes into account all the information that is contained in the packets.

I don't need to go into all the details here, but it suffices to say that with that approach, we get signatures which contain much more detail than just the IP addresses, ports and protocols. We may see something like:

        You are under TCP-Syn attack.
        Filter all TCP packets with the following characteristics:
            - TCP-destination port: 80
            - TCP-flags: SYN
            - Destination address: www.mybigbusiness.com
            - Window size: 16000
            - Sequence number: 12345678

We can see here that items such as the window-size and the sequence-number have been identified. In this particular case, the attack tool generated packets which had those things in common. Using modern IPSs and even some firewalls, filtering on such fine-grained information is possible.

This information then allows for the truly surgical removal of offending traffic. If filters based on those recommendations were implemented, the vast majority of legitimate traffic would be able to pass through completely uninhibited.

It should be noted that the usefulness of this is not only limited to DDoS attacks. Worms are particularly interesting as well. For example, the SQL/Slammer worm, which propagated on UDP port 1434. A business who needs this service for operation will not just be able to block all traffic on that port. Our packet-based NBAD solution, however, did not only identify the port and protocol, but also the packet length as a very distinct characteristic of that traffic. Filtering on packet length is possible even with many routers, so this information can be put to practical use immediately by many organizations.

The key is, though, that a flow-based solution will never be able to provide this level of detail and accuracy, only a packet-based NBAD solution can do this.

Juergen Brendel
CTO
www.esphion.com