Reading between the lines

Most people never need to mess-around with cipher suites, but if you do, it can be quite confusing to figure out their cryptic names. For example, what’s the difference between TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 and TLS_RSA_WITH_AES_256_GCM_SHA384 or what is the difference between the 1^st, 2^nd and 3^rd “256” in TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA256_P256?

If you ever wondered what this all means, I got the answers!

The Cipher Suite name is comprised of the following pieces (some suites have less pieces):

1)      The protocol

2)      The Key Exchange

3)      The Digital Signature

4)      The Encryption (Cipher)

5)      The encryption key length

6)      The encryption mode

7)      The Hashing algorithm

8)      The Elliptic Curve size

Let’s review what they mean, and what possible values you could find.

Protocol

The protocol is the most important value, and it can have two possible values – SSL and TLS. SSL is a family of older protocols starting from SSL 1 and going up to SSL 3. While most computer still support it, even the latest one (3) has significant vulnerabilities, so it’s rarely used anymore and many server explicitly de-prioritize or disable it. The TLS family of protocols has 3 members – 1.0, 1.1 and 1.2 and like anything else, most people (and the servers they configure) prefer the latest member. At this time, 1.2 is the latest, and version 1.3 has had its draft published a few months ago. We can expect to start seeing it in public use within a year or two. Cipher suites don’t actually list the version of the protocol and just state TLS or SSL, with the version number being suggested by the client to the server separately.

Key Exchange

The key exchange algorithm controls how the client gives the server the symmetric key that will be used for the session. The common key exchange families are RSA and DH (Diffie-Helman). DH has several variations like ECDH (Elliptic-Curve DH), DHE (DH Ephemeral) and ECDHE (both Elliptic-curve and Ephemeral). Windows Servers usually prefer Diffie-Helman’s exchanges, and the typical priority list for cipher suits will list them almost exclusively.

Digital Signature

The Digital Signature makes sure that the data exchanged between client and server is protected from forgery or alteration. The common algorithms are RSA, ECDSA and DSS. Several cipher suites use RSA for both Key Exchange AND Digital Signature, and so their name would list RSA only once. For example:

TLS_RSA_WITH_AES_128_CBC_SHA

Encryption (Cipher) and key length

The Encryption algorithm is about how the data actually gets scrambled, and is always paired with a key length between 128 and 256 bit. AES is pretty much ubiquitous these days, though RC4 was in use for many years and still shows up not-and-then. You can sometimes see 3DES (a.k.a. “Triple-DES”), and when using non-windows platforms, occasionally others. A key length of 256 bit might seem low when comparing it to the 1024 bits (or more) used in generating digital certificates, but in reality, symmetric encryption is stronger and thus a 1024 bit key for a certificate (asymmetric encryption) is equivalent to a 80 bit key for symmetric encryption. That means that a 128 bit key is pretty darn good, and a 256 bit key is terrific…we are many decades away from anyone (even the NSA or quantum computers) having the ability to brute-force his way through a 256 bit symmetric key. Since 256 is still much stronger than 128, the default cipher priority order on any computer favors 256 over lower lengths.

Encryption mode

The encryption mode is actually an extension, so it’s optional and not all suites specify one. For example, RC4 doesn’t offer advanced encryption modes and therefore none are listed. AES does, and so the default list of suites includes CBC and GCM as the primary modes, and using GCM offers better security as it implements several technologies to protect message integrity (so does CBC, but GCM is better)

Hashing algorithm

Hashing benefits security by preventing tampering with the encrypted data. Changing the data invalidates the data’s hash, thus alerting the recipient that the data has been tampered with. SHA (Secure Hash Algorithm) is a family of cryptographic hash functions published by the National Institute of Standards and Technology (NIST) as a U.S. Federal Information Processing Standard (FIPS). The number following SHA is the Output size in bits. The bigger the hash, the harder it is to brute-force, hence it’s more secure and preferred.

Elliptic Curve size

Some Key Exchange algorithms use Elliptic Curves, which are easier to calculate. This can provide higher security as the same CPU power can generate better encryption in less time. When Elliptic Curves are used, the suite specifies the curves and adds “P” to differentiate from the encryption algorithm’s key length. When looking at the cipher suites, those without Elliptics won’t list the curves

Ready to see this in real life? Have a look at the following list of suites built-into Windows 2012 R2 and see if you identify the properties of the suites and how they differ:

Back to my roots

I haven't posted to this blog for quite a while, as a few years ago I moved out of the security business to the program manager for IIS and for Azure Websites (Microsoft's cloud based web and app hosting service). Last week, I went back to my roots in the Security world, and I'm now part of the Identity and Access Management team in Microsoft's IT group, where I'll be dealing with Microsoft's global PKI.

As part of this, I'll be posting some interesting stuff about this topic and other security-related articles here again.

Also, this blog is now accessible via http://www.isitsafe.us , so the URL is a bit easier to remember!

Welcome back, Me!

Erez

How many firewalls are enough?

Pretty much every company in the world places at least one firewall at the edge of its network, to protect its internal resources. There were dark times, where a simple router is all we had, and we exposed all of our computers to the internet without any protection, but now that the hardware and software have gone down in price, this brings a new discussion to the table…how many firewalls are enough?

On one hand, you can take some old computer that’s too slow for use with modern desktop operating systems, stick some Linux based firewall on it and you got yourself a firewall at a cost that’s close to zero. Many people think that a thicker armor can stop more missiles, and would take advantage of the cheap options to build a network with multiple layers of firewalls. Is more really better?....not always!

The thing about quantity is that it rarely really trumps quality. Even in the simplest example of a tank having multiple layers of armor on it this is not the case. Sure, a tank with 15 layers of steel would be harder to penetrate than one with 14 layers, but the multiple layers also make the tank heavy. The added weight makes the tank slower to move and maneuver, limits the distance it can travel and the land it can drive onto.

In the case of network security, adding more layers can make it harder for an attacker to crack it, but the complex configuration makes it more likely for something to get overlooked or misconfigured. For example, if you put 6 different firewalls in the mix, you’re probably not an expert on each and every one of them. Perhaps one of them has a built in remote-access option that you forgot to protect or disable? Perhaps one has a lesser-known vulnerability that you were not aware of and forgot to plug? Perhaps updating the various firewalls will be hard because of the limitations on internet connections?

A common term in my world is “security by obscurity”, referring to using technology to mask some component in hopes that if it’s hidden well enough, it’s less likely to be attacked. The same concept applies, however, to bugs and issues. The more complicated the environment, the harder it is for us to see any issues it may be harboring.

Unfortunately, there’s no simple answer to the age old question of how much is enough, and how much is too much. Depending on your own exposure, which includes the profile of the data you need to have coming in and out, and your public profile that makes your organization a prime target or a lesser one, the answer is individual. If you’re a small company that’s just publishing a simple website, it’s very likely that a single firewall is all you need. If you’re a multimillion dollar corporation, which has tons of public services, then it’s probably a good idea to have more.

If you were expecting a simple numerical answer, then I’m afraid I’m going to disappoint you. I’m here to remind you of the considerations pro and con for each option. Your own mileage may vary, but one thing is simple to note…if your configuration is so complicated that even you can’t explain easily where a packet is going and where it has been lost, then it’s probably too complicated to be reliable.

Recipe for disaster

Disaster recovery is one of the most important aspects of a security officer’s work. It even has its own domain in the ISC2 CBK (Business Continuity and Disaster Recovery Planning). With recent disasters like the 8.9 magnitude earthquake in Japan, other aspects of disaster recovery come to mind.

The information security officer has plenty of tools for disaster recovery at his disposal. Backups, hot/cold sites, off-site storage are some of them. With sufficient budget and training, a company can live-through a disaster and resume work very rapidly, and this was demonstrated well during the Sep-11 events in NY City.

The other aspect of this is that while the operations and security teams are busy with trying to reestablish the company’s operations and IT, most companies forget that the disaster site, although dysfunctional, typically still has all of the company’s assets. In the case of the world trade center towers, everything was buried in tons of dust and rubble, but other disasters may leave sensitive equipment or data exposed. A building that has been overrun by water may be unusable, and the computers in it may be completely destroyed, but their hard drives may be intact. Backup tapes or optical media is also likely to withstand such an event, esp. if it is inside a fireproof vault. This could be a golden opportunity for infiltrators to come in and grab something.
Naturally, it may be hard or dangerous to try this sort of stunt, but the kind of financial gain someone can make has been known to drive certain people to take risks. You and I probably won’t, but it takes only one crazy bastard to compromise a lot of secure information.

In addition to the above, even companies that have nothing to do with the disaster, and haven’t been harmed at all (or very little) are at risk, as with any large scale disaster, the entire country can plunge into chaos. In Japan, many companies have not been harmed, but have been completely deserted, as the employees left to attend to their families and loved ones. This is perfectly understandable, but the result is low-hanging fruit for any cracker. The police are typically concerned with street-level looting going on, but we in information security need to think about data looting too.

Naturally, the physical security domain in the CBK deals with protecting the workplace from physical harm, though it usually deals mostly with day-to-day threats, like burglary, fire and flood. When something as large as an earthquake or missile bombing comes into play, many of these measures will collapse. With proper planning, at least some of these may be mitigated. For example, your sensitive servers are properly locked away in a server room, but that room may not be secure enough to withstand someone ramming it with a truck. Using secure cabinets instead of the simple glass-door ones may provide an additional level of security. Using hard-disk encryption on servers and storage arrays, even though slow, can protect your data in case all hell breaks loose. You can’t physically secure all desktops, but using thin-clients (or terminal services) for some or all employees can provide for additional protection.

In addition to these, you should encourage your employees to refrain from storing sensitive data in the offices. This means avoiding printing of sensitive info, and making sure printouts are shredded in-house. Sensitive documents like employee or customer lists should be stored in a secure room or vault. Backup tapes and other media should be stored in a vault. When using such a vault, remember it still needs to be secure, so don’t leave it unlocked or the key too easy to find (many companies open the vault in the morning, and leave it open throughout the workday…ah…..).

And lastly, when creating your disaster plan master policy, make sure to assign guards to the destroyed facility. You may find, in reality, that all your guards disappeared, but if you prepare well enough, even a single guard will be more effective than none…

book Smarts!

I usually use this blog to talk about general security related issues, but on this special occasion, I’d like to tell you all about a new book of mine that just came out.

Even though I’ve been a writer for almost 15 years, this is my first published book, and it’s also good news for many users of UAG, IAG or eGap users, as this is the 1st public book about these products.

For those who never heard of these products, UAG is the latest member of a line of secure remote-access products. It was originally developed by Whale Communications from Israel, which was purchased by Microsoft in 2006. In 2007, the previous version named IAG (Intelligent Application Gateway) was released, and a few months ago, UAG (Unified Access Gateway) was released as part of the Forefront family of security products.

The book itself is not really finished – I still have a few more chapters to write, but the publisher has released the first three chapters as something they call RAW (short for Read As we Write). It’s like a Beta version – readers can get it right now, way before the book is officially out, and also make comments or suggestions to it. This is a great honor for me, of course, as the publisher only releases into RAW books that are very well written, and can stand their ground without significant edits.

Even though the book is about UAG, a lot of it also applies to IAG, and even eGap. It’s written specifically for the UAG beginner, and starts with basic concepts and design. It then goes through advanced configurations and troubleshooting, as well as Direct Access. It does not, however, cover advanced scenarios like ADFS or customizations.

Interested? I hope so…go ahead and look at:
https://www.packtpub.com/microsoft-forefront-uag-2010-administrators-handbook/book

Automan

An old boss of mine used to say that his best employees are the laziest, because they create automation to do their job, and automation reduces human error. Since human error is one of the leading causes of security breaches, this also means that using automation appropriately could not only serve to free up time, but also reduce your exposure and boost your security.

Granted, developing automation can be a pain. It sometimes takes days of development and testing, but the benefits are fantastic. For example, one of the most common security pain points out there are user accounts. Every time an employee joins the company, you have to create an account, create a random password, fill in all the account details, assign the user to various groups, and finally, convey the appropriate information to the user securely. If an employee leaves, it’s even worse, because you have to close out the account with very precise timing, to make sure the ex-employee doesn’t get locked out prematurely, but also not be able to connect from home after leaving his position. The worst are role-changes, which require you to carefully clean-up the account of unnecessary permissions, to make sure the employee can’t abuse the rights he had in the past.

When you need to do this on a routine basis, within a few days, you would be able to perform such tasks almost blindly. Like driving a car, this is what we refer to as “over-learned activity”. After a while, we tend to feel confident enough to chew a sandwich while doing it, talk on the phone or installing a server (talking about the network here…not installing a server while driving a car), and that’s where the little mistakes creep in. We might send the password to the wrong person; add the user to a group that has too many permissions, or worse. I’ve met an engineer who once, absentmindedly, misspelled the first name of a person named Bart as…well…you can guess. That guy got some chewing, but he might as well have exposed his network to attackers if his absentmindedness led somewhere else.

If you’re lucky, perhaps your company is rich enough to afford identity management software, but the costs of such suites and their adoption is immense. If so, why not write up your own automation? A VBScript, ASP page, PERL script or sometimes even a Batch file can save you tons of tedious work. If you’re thinking to yourself “heck…I ain’t no programmer!” you might be selling yourself short. Some tasks are so simple to achieve in VBScript and Batch that you can achieve this almost instantly. For example, a script to generate a random password in VBScript is so simple. Here’s a clever and tight one by Martijn Haverhoek http://www.haverhoek.nl/index.php?/archives/36-Random-password-generator-vbscript.html . Here’s another one, written in JavaScript: http://blazonry.com/javascript/password.php . With time and patience, a script can be written to automate almost the entire process of creating and deleting user accounts, as well as other administration tasks.

Even when using automation, mistakes can still happen, but by shortening the processes, it makes them less tedious and encourage performing them with more attention and focus. Another advantage is that it may allow you to delegate some tasks to your subordinates (knowing that there is less things for them to mess-up) or to your colleagues when you go on leave. Even if you are a decision maker and will never get into programming, you can still benefit your organization by hiring or contracting someone to develop some automation for you. Start simply by thinking which processes are performed routinely, and which are the most annoying or tedious. From then on…the sky’s the limit!

Chain of events

When thinking about security, one of the things that are hardest to grasp is the way things are linked together, and of course, the ingenuity of criminals. One small thing can lead to disasterous results in ways a normal person could not even imagine.

For example, a well known story is about a family that went to a public event, and parked their car in the parking lot, like everybody else. The car was a piece of junk, so there was no reason to steal it, and therefore, the owners didn’t install any protection. When thieves broke into it, they weren’t even interested in the car itself, but instead, they stole the GPS that was in it. No…they didn’t want the $50 they could hawk it for, but instead, they just put it in their own vehicle, and pressed “go home”. Thirty minutes later, they were in the driveway of the car’s owner, and entered the house using the remote they also found in the car. I guess there’s no need to detail the resulting mess.

There are several preventative measures to prevent this kind of thing (the simplest would be to set the HOME location on the GPS at a point that’s actually a mile or two from home, or not at all), but the point is that everything can be used for bad deeds, even if it is worthless in itself. Knowing where you work, for example, will allow a clever social engineering hacker to squeeze some info from your co-workers. For example, when you are going on vacation (which would be a good time to hit your house) or what days you stay late at the office.

What can you do about this? Unfortunately, not enough. The criminal mind thinks differently than us, normal people, and even amongst the crooks, there are the more devious kind. A good practice is simply to pretend to be a bad guy for a day. Sit in your car outside your home or office, and try to come up with a way to break in. Sit at your computer, and think how YOU can bust into your boss’s computer, and then try to figure out how you would block him from doing the same to you. Some of us just can’t do it – too old to think outside the box, but you might also try having your kids suggest thoughts.