Here's the story. Every Oyster card has a radio-frequency identification chip that communicates with readers mounted on the ticket barrier. That chip, the "Mifare Classic" chip, is used in hundreds of other transport systems as well — Boston, Los Angeles, Brisbane, Oslo, Amsterdam, Taipei, Shanghai, Rio de Janeiro — and as an access pass in thousands of companies, schools, hospitals, and government buildings around Britain and the rest of the world.

The security of Mifare Classic is terrible. This is not an exaggeration; it's kindergarten cryptography. Anyone with any security experience would be embarrassed to put his name to the design. NXP attempted to deal with this embarrassment by keeping the design secret.

The group that broke Mifare Classic is from Radboud University Nijmegen in the Netherlands. They demonstrated the attack by riding the Underground for free, and by breaking into a building. Their two papers (one is already online) will be published at two conferences this autumn.

The second paper is the one that NXP sued over. They called disclosure of the attack "irresponsible," warned that it will cause "immense damages," and claimed that it "will jeopardize the security of assets protected with systems incorporating the Mifare IC." The Dutch court would have none of it: "Damage to NXP is not the result of the publication of the article but of the production and sale of a chip that appears to have shortcomings."

Exactly right. More generally, the notion that secrecy supports security is inherently flawed. Whenever you see an organization claiming that design secrecy is necessary for security — in ID cards, in voting machines, in airport security — it invariably means that its security is lousy and it has no choice but to hide it. Any competent cryptographer would have designed Mifare's security with an open and public design.

Secrecy is fragile. Mifare's security was based on the belief that no one would discover how it worked; that's why NXP had to muzzle the Dutch researchers. But that's just wrong. Reverse-engineering isn't hard. Other researchers had already exposed Mifare's lousy security. A Chinese company even sells a compatible chip. Is there any doubt that the bad guys already know about this, or will soon enough?

Publication of this attack might be expensive for NXP and its customers, but it's good for security overall. Companies will only design security as good as their customers know to ask for. NXP's security was so bad because customers didn't know how to evaluate security: either they don't know what questions to ask, or didn't know enough to distrust the marketing answers they were given. This court ruling encourages companies to build security properly rather than relying on shoddy design and secrecy, and discourages them from promising security based on their ability to threaten researchers.

It's unclear how this break will affect Transport for London. Cloning takes only a few seconds, and the thief only has to brush up against someone carrying a legitimate Oyster card. But it requires an RFID reader and a small piece of software which, while feasible for a techie, are too complicated for the average fare dodger. The police are likely to quickly arrest anyone who tries to sell cloned cards on any scale. TfL promises to turn off any cloned cards within 24 hours, but that will hurt the innocent victim who had his card cloned more than the thief.

The vulnerability is far more serious to the companies that use Mifare Classic as an access pass. It would be very interesting to know how NXP presented the system's security to them.

And while these attacks only pertain to the Mifare Classic chip, it makes me suspicious of the entire product line. NXP sells a more secure chip and has another on the way, but given the number of basic cryptography mistakes NXP made with Mifare Classic, one has to wonder whether the "more secure" versions will be sufficiently so.

This essay originally appeared in the Guardian.

Part of the problem is that good security people need to know the following skills:

• IT technology: since the data more often than not is in a computer, you need to understand them
• People technology: policies and procedures for managing people
• Business sense:  understanding that you’re supporting business goals
• And for Government:  politics

Back when I was PFC Rybolov, my battalion commander told me something along the lines of “The intelligence world is a hard job, you have to be able to out-infantry the infantry, out-mechanic the mechanics, out-radio the radio guys, and you need to know a language.”  Security is pretty much the same thing–you have to out-techie the techies, out-business the MBAs, and out-jerkify the auditors.  =)

Sound complicated?  Yes, it is, and it’s hard to find people who can do all this.  IT is an employment niche, IT security is a niche to a niche.  And there isn’t enough people who have the experience to do it.

So how do we mitigate the staffing shortage?  Here is what we are doing today in the Government:

• CyberCorps scholarship program for undergrads and graduate students with a minimum government service obligation.
• Using other career fields in “crossover roles”–yes, accountants can be used for some light security tasks.  Some things that we think of as security are really Quality Assurance and Change Control jobs that we have a vested interest in making work.
• Using contractors in some roles such as ISSO, ISSM, etc.
• Automation as much as possible.  Technical is easier, the policy and procedures side takes longer.  What you’ll find out eventually is that good IT management is good security management.
• Hanging on methodologies to “automate” the process side of security.

Now this is cool and all, but it’s hard to sustain and really hard to justify as a long-term solution.  In order to support the Government, we need to create more people.  Cybercorps is a start, but the need is so much larger than the supply that we have to consider better ways to create Government security dweebs.

Do we need Security Awareness and Training?  Yes we do, but much more than what is being provided (think system administrator training and procurement specialist training, not end-user training), and as an internal recruiting pipeline.  Still, I don’t think that we can recruit enough people to “the dark side” and that we need to look outside the Beltway for people.  Problem is that DC is such an insular community and we don’t speak the same language as the rest of the world.

Bookmark to:

Recently I spent one week at a customer in a hotel where the staff obviously was hosting nightly parties down at my end of the hall- from about 2:00am - 5:30am each (yes- every) night I was there. The hotel I’m in tonight has no elevator. Yeah. @#$! That’s what I said. Twice in the past 10 days or so, I’ve been in really nice resort-hotels, so I’ve had the whole spectrum this month and last.

For me, sometimes it’s the little things… I really like it when hotels have conditioner, instead of just shampoo. I like space- so a nice work area is important to me. Of course a big soft bed and plenty-o-pillows is a key ingredient. A whirlpool or jetted tub (in the room) is icing on the cake. Exercise rooms are good, although half the time I’m too tired when traveling or have work to do (I know- excuses, excuses ;). Convenience is also a biggie- I had a run in Las Vegas where *every* room I had felt like it was a 10-minute walk just to the elevators. When I’m on-site for a customer, I also love the hotels with the do-it-yourself breakfast- I can go when I want and grab something before heading out for the day. I love the little lighted makeup mirrors… and of course a full-length for checking out the wardrobe. Plugs! I love lots of plugs. I like hotels that secure the outer doors early and require a key for access to various parts of the building.

Sometimes it’s the bigger things… Hotels with outside-facing doors make me paranoid, and obviously those in neighborhoods where your rims may disappear is not good either. I hate hotels that MAKE me valet park my car. It’s my car, my keys, I park it and I keep the keys- that’s my rule. (My Dad taught me a little trick of telling the valet boys that it’s a company car and against corporate policy for valet- it works!)

Traveling techies sometimes have unique needs or requests, and many of the ‘good list’ is universal for all traveler types.

So, those are some items from my little list… What about you- what do YOU look for in a good hotel?

# # #

Their competition, tantalizingly called a “digital combat exercise,” was supposed to give onlookers a rare opportunity to watch a computer hacking job in progress, complete with play-by-play.

It didn’t work out that way, though, thanks to — what else? — some sort of technical glitch that obstructed efforts to monitor what the competitors were doing. So for the few non-techie spectators who showed up, the business of hacking was still as opaque and mysterious at the end of the 1 1/2-hour exercise as it was in the beginning.

A technical glitch? They always happen at the worst possible time, don’t they? Read on.

The commentary was to come from Peter Stephenson, a member of the program’s faculty, who sat at his own terminal and displayed on a big screen something he called a “sniffer trace,” a multi-colored table with columns of numbers and letters — the first in what was to be a series of tableaus that held the promise of monitoring all the traffic on the network next door.

The minutes passed, and not much happened. The sniffer trace stayed the same, and from time to time, when Stephenson tried to check on what individual teams were up to, the screen went blank. Could it be that the hackers weren’t getting anywhere?

Someone decided to check on them in the old-fashioned way — paying a visit in person. The report came back that they were, in fact, getting somewhere — finding holes and vulnerabilities of various kinds.

You’d think that somebody on the faculty, or one of the grad students, or even somebody in the audience would have realized the problem. The story implies that they never did figure out what those pesky hackers were up to.

Sometimes I’m the queen of analogies (likely a trait I inherited from my Dad). Quite often my analogies are pretty silly, but they almost always get the point across.

So I was trying to work out an analogy to explain how we can use logs, events and searching and why these are advantageous. I was in the shower and it hit me! And… here it is.  FYI- If you’re a techie, just stop reading now… (I warned you).

The analogy. Imagine a house… actually, imagine your house. Let’s say that your house is like a network. The house and all the major appliance and structures of the house are like infrastructure devices- switches and servers, for example. Of course, the people living in your house are users. In addition you have ‘gateways’ from your house to the outside world, in the form of doors, windows, vents, etc. These house gateways are like our WAN devices- firewalls, IDS/IPS and other gateway appliances.

Let’s say you live in the house with your spouse and family. You’re going to be the wife for now, so imagine you, your husband, three kids and a dog (only because that amuses me). Each of your house users have a key to get in.

Your major appliances- the TVs, refrigerator, oven, the family computers and alarm system are all creating logs when anything happens and they’re all giving their logs to the toaster. (The toaster is greatly under appreciated so I’m giving him a big role here- yes- your toaster is the Syslog server). The doors, windows and other ‘portals’ to the outside are also creating events and logging each time they’re opened, closed, locked or broken and, they too, are sending their info to the toaster.

Here’s where life in your house gets interesting. Let’s figure out what’s normal… it’s probably normal for your husband to come home, do some work on the computer while you cook, and then everyone watch TV. The kids are doing their homework, playing on the computer and probably rummaging around the fridge for an after-school snack. You see your syslogging toaster shows you…  

• the src= Refrigerator was opened multiple times in a short period of time between 3:43pm and 4:16pm by multiple users
• the src= Kids Computer was logged off the Internet at 4:30 by user: Kid2
• the src= Front Door was opened at 5:20pm by user: Husband
• the src= Oven was turned on Bake at 350 at 5:32pm by user: You
• the src= LivingRoom TV was turned on at 5:56pm by user: Husband
• the src= LivingRoom TV channel was modified multiple times in a short period of time between 5:56pm and 6:02pm (your husband was probably looking for the ball game)

These are all things you expect to see. So, what’s not normal? Some things your toaster may tell you that would be out of the ordinary…

• the src= Refrigerator was opened at 02:40am by user: Kid1
  What does this mean? Someone’s late-night snacking, no big deal.
• the src= Kids Computer was logged onto the Internet at 02:45am by user: Kid1
  Uh-oh, Kid1 is gallivanting on the Internet in the middle of the night un-chaperoned. Might need to check that out.
• the src= Front Door was attempted to be opened unsuccessfully 14 times in a short period of time beginning at 10:15am by user: UNKNOWN. The toaster logged the key code attempts tried by user UNKNOWN.
  Kids were at school, you were at work- someone’s trying to break in.
• the src= Front Door was opened the next day at 1:20pm by user: ROOT
  You were still not home- someone just broke into your house.

Maybe we want to be alerted when these things are happening, or have happened. With some log search and correlation tools, in conjunction with your toaster syslog, we can get immediate alerts when something unexpected is happening. We could tell the log search to keep talking to the toaster and immediately send us a text message if the toaster sees the front door or any windows being accessed between 09:00am and 3:00pm on any weekday, by any user. If the toaster saw something happening, we would know immediately and could take appropriate actions- maybe call the police to notify them of a break-in.

Now, back to the network. Now that you have an idea of how we can use logs and events in the house to identify what’s going on and spot abnormal activity, we can port that over to our network. Go back and again think of the house and its appliances as resources on the network. We can see when someone- inside or outside- is trying to or has successfully accessed something and we can alert, take action, or keep logs and reports for future use and accounting.

Replaying events. If you’re using a super-nifty tool, you may be able to replay specific events back in a visual format- almost like a video into the network. Let’s take our Kid1’s midnight snacking. If we replayed all the events that contained user= Kid1 from time 10:00pm (bedtime) to 07:00am (gettin’ up time) we could see Kid1 go from the bedroom down to the kitchen, opening the fridge, watching TV for a bit before going back to the room and surfing the Internet for an hour. We could actually ‘watch’ these events happening with a re-constructed timeline. A great example (and my favourite toy) to do this is Splunk’s Replay application.

That’s the basic gist of it all. There are some other detailed ‘things’ we can do with these technologies, and I may elaborate on those another time. We all have A.D.D. and this one is long enough already!

# # #

- Take a risk based approach - Focus on business needs - Talk the language of the business - Don’t make wild statement about cost savings and ROI - Work to reduce costs - Put risk assessments into context - Present a decent set of meaningful security metrics