Login  |  Register  |  Contact


Tuesday, February 18, 2014

RSA Conference Guide 2014 Deep Dive: Data Security

By Rich

It is possible that 2014 will be the death of data security. Not only because we analysts can’t go long without proclaiming a vibrant market dead, but also thanks to cloud and mobile devices. You see, data security is far from dead, but is is increasingly difficult to talk about outside the context of cloud, mobile, or… er… Snowden. Oh yeah, and the NSA – we cannot forget them.

Organizations have always been worried about protecting their data, kind of like the way everyone worries about flossing. You get motivated for a few days after the most recent root canal, but you somehow forget to buy new floss after you use up the free sample from the dentist. But if you get 80 cavities per year, and all your friends get cavities and walk complaining of severe pain, it might be time for a change.

Buy us or the NSA will sniff all your Snowden

We covered this under key themes, but the biggest data security push on the marketing side is going after one headlines from two different angles:

  • Protect your stuff from the NSA.
  • Protect your stuff from the guy who leaked all that stuff about the NSA.

Before you get wrapped up in this spin cycle, ask yourself whether your threat model really includes defending yourself from a nation-state with an infinite budget, or if you want to consider the kind of internal lockdown that the NSA and other intelligence agencies skew towards. Some of you seriously need to consider these scenarios, but those folks are definitely rare.

If you care about these things, start with defenses against advanced malware, encrypt everything on the network, and look heavily at File Activity Monitoring, Database Activity Monitoring, and other server-side tools to audit data usage. Endpoint tools can help but will miss huge swaths of attacks.

Really, most of what you will see on this topic at the show is hype. Especially DRM (with the exception of some of the mobile stuff) and “encrypt all your files” because, you know, your employees have access to them already.

Mobile isn’t all bad

We talked about BYOD last year, and it is still clearly a big trend this year. But a funny thing is happening – Apple now provides rather extensive (but definitely not perfect) data security. Fortunately Android is still a complete disaster. The key is to understand that iOS is more secure, even though you have less direct control. Android you can control more visibly, but its data security is years behind iOS, and Android device fragmentation makes it even worse. (For more on iOS, check out our a deep dive on iOS 7 data security. I suppose some of you Canadians are still on BlackBerry, and those are pretty solid.

For data security on mobile, split your thinking into MDM as the hook, and something else as the answer. MDM allows you to get what you need on the device. What exactly that is depends on your needs, but for now container apps are popular – especially cross-platform ones. Focus on container systems as close to the native device experience as possible, and match your employee workflows. If you make it hard on employees, or force them into apps that look like they were programmed in Atari BASIC (yep, I used it) and they will quickly find a way around you. And keep a close eye on iOS 7 – we expect Apple to close its last couple holes soon, and then you will be able to use nearly any app in the App Store securely.

Cloud cloud cloud cloud cloud… and a Coke!

Yes, we talk about cloud a lot. And yes, data security concerns are one of the biggest obstacles to cloud deployments. On the upside, there are a lot of legitimate options now.

For Infrastructure as a Service look at volume encryption. For Platform as a Service, either encrypt before you send it to the cloud (again, you will see products on the show floor for this) or go with a provider who supports management of your own keys (only a couple of those, for now). For Software as a Service you can encrypt some of what you send these services, but you really need to keep it granular and ask hard questions about how they work. If they ask you to sign an NDA first, our usual warnings apply.

We have looked hard at some of these tools, and used correctly they can really help wipe out compliance issues. Because we all know compliance is the reason you need to encrypt in cloud.

Big data, big budget

Expect to see much more discussion of big data security. Big data is a very useful tool when the technology fits, but the base platforms include almost no security. Look for encryption tools that work in distributed nodes, good access management and auditing tools for the application/analysis layer, and data masking. We have seen some tools that look like they can help but they aren’t necessarily cheap, and we are on the early edge of deployment. In other words it looks good on paper but we don’t yet have enough data points to know how effective it is.


Tuesday, January 14, 2014

Firestarter: Crisis Communications

By Rich

Okay, we have content in this thing. We promise. But we can’t stop staring at our new title video sequence. I mean, just look at it!

This week Rich, Mike, and Adrian discuss Target, Snapchat, RSA, and why no one can get crisis communications correct.

Sorry we hit technical difficulties with the live Q&A Friday, but we think we have the kinks worked out (I’d blame Mike if I were inclined to point fingers). Our plan is to record Friday again – keep an eye on our Google+ page for the details.


Friday, February 24, 2012

The Securosis Guide to RSA 2012

By Rich

Here it is, folks. Weeks of work, and there’s a lot of great information in there even if you aren’t attending the RSA Conference.

We cover all the major areas of security and what you can expect to see this year. It’s really more than a guide to the conference – it also contains many of our guesses on what the next year in security holds.

We hope you like it, and please let us know if you find it useful.


And as a little teaser, here are our food and beverage recommendations:

Dining and Beverage Guide

This year we had a request for some of our favorite places to grab a bite or a drink. After all these years, we hate to admit how much time we have spent grubbing for food around the Moscone center – and this isn’t the only event we attend there. So here is a combination of our own recommendations and tips from friends on Twitter.

Best breakfast that’s a little out of the way: Mo’z Cafe

Best convenient breakfast everyone knows about, but which might be slow: Mel’s Cafe

Best coffee/breakfast/lunch place for quick meetings: The Grove

Best place to have a drunk marketing/PR person buy you a free drink: Lobby bar at W hotel

Close food courts with decent food for lunch: Westfield Center & Metreon

Best Drinks: Burbon and Branch

Easy places to find a party you might not get into: Thirsty Bear, Ruby Skye, & all the hotels immediately around Moscone

Best place to get a good beer even if there’s party upstairs: Thirsty Bear

Fake Mexican place to avoid unless you’re desperate: Chevy’s Fresh Mex

Best Indian: Amber

Best spicy noodle place: Henry’s Hunan

Mike’s personal recommendation: Mitchell Brothers


Thursday, June 02, 2011

A Different Take on the Defense Contractor/RSA Breach Miasma

By Rich

I have been debating writing anything on the spate of publicly reported defense contractor breaches. It’s always risky to talk about breaches when you don’t have any direct knowledge about what’s going on. And, to be honest, unless your job is reporting the news it smells a bit like chasing a hearse.

But I have been reading the stories, and even talking to some reporters (to give them background info – not pretending I have direct knowledge). The more I read, and the more I research, the more I think the generally accepted take on the story is a little off.

The storyline appears to be that RSA was breached, seed tokens for SecurID likely lost, and those were successfully used to attack three major defense contractors. Also, the generic term “hackers” is used instead of directly naming any particular attacker.

I read the situation somewhat differently:

  • I do believe RSA was breached and seeds lost, which could allow that attacker to compromise SecurID if they also know the customer, serial number of the token, PIN, username, and time sync of the server. Hard, but not impossible. This is based on the information RSA has released to their customers (the public pieces – again, I don’t have access to NDA info).
  • In the initial release RSA stated this was an APT attack. Some people believe that simply means the attacker was sophisticated, but the stricter definition refers to one particular country. I believe Art Coviello was using the strict definition of APT, as that’s the definition used by the defense and intelligence industries which constitute a large part of RSA’s customer base.
  • By all reports, SecurIDs were involved in the defense contractor attacks, but Lockheed in particular stated the attack wasn’t successful and no information was lost. If we tie this back to RSA’s advice to customers (update PINs, monitor SecurID logs for specific activity, and watch for phishing) it is entirely reasonable to surmise that Lockheed detected the attack and stopped it before it got far, or even anywhere at all. Several pieces need to come together to compromise SecurID, even if you have the customer seeds.
  • The reports of remote access being cut off seem accurate, and are consistent with detecting an attack and shutting down that vector. I’d do the same thing – if I saw a concerted attack against my remote access by a sophisticated attacker I would immediately shut it down until I could eliminate that as a possible entry point.
  • Only the party which breached RSA could initiate these attacks. Countries aren’t in the habits of sharing that kind of intel with random hackers, criminals, or even allies.
  • These breach disclosures have a political component, especially in combination with Google revealing that they stopped additional attacks emanating from China. These cyberattacks are a complex geopolitical issue we have discussed before. The US administration just released an international strategy for cybersecurity. I don’t think these breaches would have been public 3 years ago, and we can’t ignore the political side when reading the reports. Billions – many billions – are in play.

In summary: I do believe SecurID is involved, I don’t think the attacks were successful, and it’s only prudent to yank remote access and swap out tokens. Politics are also heavily in play and the US government is deeply involved, which affects everything we are hearing, from everybody.

If you are an RSA customer you need to ask yourself whether you are a target for international espionage. All SecurID customers should change out PINs, inform employees to never give out information about their tokens, and start looking hard at logs. If you think you’re on the target list, look harder. And call your RSA rep.

But the macro point to me is whether we just crossed a line. As I wrote a couple months ago, I believe security is a self-correcting system. We are never too secure because that’s more friction than people will accept. But we are never too insecure (for long at least) because society stops functioning. If we look at these incidents in the context of the recent Mac Defender hype, financial attacks, and Anonymous/Lulz events, it’s time to ask whether the pain is exceeding our thresholds.

I don’t know the answer, and I don’t think any of us can fully predict either the timing or what happens next. But I can promise you that it doesn’t translate directly into increased security budgets and freedom for us security folks to do whatever we want. Life is never so simple.


Thursday, March 24, 2011

Crisis Communications

By Rich

I realize that I have a tendency to overplay my emergency services background, but it does provide me with some perspective not common among infosec professionals. One example is crisis communications. While I haven’t gone through all the Public Information Officer (PIO) training, basic crisis communications is part of several incident management classes I have completed. I have also been involved in enough major meatspace and IT-related incidents to understand how the process goes.

In light of everything from HBGary, to TEPCO, to RSA, to Comodo, it’s worth taking a moment to outline how these things work.

And I don’t mean how they should go, but how they really play out. Mostly this is because those making the decisions at the executive level a) have absolutely no background in crisis communications, b) think they know better than their own internal experts, and c) for some strange reason tend to think they’re different and special and not bound by history or human nature.

You know – typical CEOs.

These people don’t understand that the goal of crisis communications is to control the conversation through honesty and openness, while minimizing damage first to the public, then second to your organization. Reversing those priorities almost always results in far worse impact to your organization – eventually, of course, the public eventually figures out you put them second and will make you pay for it later.

Here’s how incidents play out:

  1. Something bad happens. The folks in charge first ask, “who knows” to figure out whether they can keep it secret.
  2. They realize it’s going to leak, or already has, so they try to contain the information as much as possible. Maybe they do want to protect the public or their customers, but they still think they should keep at least some of it secret.
  3. They issue some sort of vague notification that includes phrases like, “we take the privacy/safety/security of our customers very seriously”, and “to keep our customers safe we will not be releasing further details until…”, and so on. Depending on the nature of the incident, by this point either things are under control and there is more information would not increase risk to the public, or the attack was extremely sophisticated.
  4. The press beats the crap out of them for not releasing complete information.
  5. Competitors beat the crap out of them because they can, even though they are often in worse shape and really just lucky it didn’t happen to them.
  6. Customers wait and see. They want to know more to make a risk decision and are too busy dealing with day to day stuff to worry about anything except the most serious of incidents. They start asking questions.
  7. Pundits create more FUD so they can get on TV or in the press. They don’t know more than anyone else, but they focus on worst-case scenarios so it’s easier to get headlines.
  8. The next day (or within a few hours, depending on the severity) customers start asking their account reps questions.
  9. The folks in charge realize they are getting the crap beaten out of them. They issue the second round of information, which is nearly as vague as the first, in the absurd belief that it will shut people up. This is usually when the problem gets worse.
  10. Now everyone beats the crap out of the company. They’ve lost control of the news cycle, and are rapidly losing trust thanks to being so tight-lipped.
  11. The company trickles out a drivel of essentially worthless information under the mistaken belief that they are protecting themselves or their customers, forgetting that there are smart people out there. This is usually where they use the phrase (in the security world) “we don’t want to publish a roadmap for hackers/insider threats” or (in the rest of the world), “we don’t want to create a panic”.
  12. Independent folks start investigating on their own and releasing information that may or may not be accurate, but everyone gloms onto it because there is no longer any trust in the “official” source.
  13. The folks in charge triple down and decide not to say anything else, and to quietly remediate. This never works – all their customers tell their friends and news sources what’s going on.
  14. Next year’s conference presentations or news summaries all dissect how badly the company screwed up.

The problem is that too much of ‘communications’ becomes a forlorn attempt to control information. If you don’t share enough information you lose control, because the rest of the world a) needs to know what’s going on and b) will fill in the gaps as best they can. And the “trusted” independent sources are press and pundits who thrive on hyperbole and worst-case scenarios.

Here’s what you should really do:

  1. Go public as early as possible with the most accurate information possible. On rare occasion there are pieces that should be kept private, but treat this like packing for a long trip – make a list, cut it in half, then cut it in half again, and that’s what you might hold onto.
  2. Don’t assume your customers, the public, or potential attackers are idiots who can’t figure things out. We all know what’s going on with RSA – they don’t gain anything by staying quiet. The rare exception is when things are so spectacularly fucked that even the collective creativity of the public can’t imagine how bad things are… then you might want them to speculate on a worst case scenario that actually isn’t.
  3. Control the cycle be being the trusted authority. Don’t deny, and be honest when you are holding details back. Don’t dribble out information and hope it will end there – the more you can release earlier, the better, since you then cut speculation off at the knees.
  4. Update constantly. Even if you are repeating yourself. Again, don’t leave a blank canvas for others to fill in.
  5. Understand that everything leaks. Again, better for you to provide the information than an anonymous insider.
  6. Always always put your customers and the public first. If not, they’ll know – either during the incident or later.
  7. Don’t lie or blame others, and don’t try to pretend you didn’t make mistakes. Don’t be like Comodo, try to blame Iran, and lump yourself into the same breach as RSA.

I don’t care if it’s the Tylenol scare, a security breach, or a nuclear meltdown – your job is to aggressively communicate so you don’t lose control of the cycle. Give people the information they need to make appropriate risk decisions, and it’s okay to keep certain details private… but only if they really protect someone other than yourself (e.g., sometimes you can’t say anything for legal reasons, but be honest when you can’t). Acting like a patronizing parent never seems to work out as well as you hope.

RSA could have controlled the cycle… especially since they were disclosing on their own terms, rather than responding to external discovery. But while they probably thought they were being responsible and releasing the right amount of information, they released just enough to kick the spin into overdrive; create doubt among their customers and the public; and allow pundits, press, and competitors to take control of the cycle… even though none of them has all the information.

There are exceptions to these rules. But not for you.


Monday, March 21, 2011

RSA Releases (Almost) More Information

By Rich

As this is posting, RSA is releasing a new SecureCare note and FAQ for their clients (Login required). This provides more specific prioritized information on what mitigations they recommend SecurID clients take.

To be honest they really should just come clean at this point. With the level of detail in the support documents it’s fairly obvious what’s going on. These notes are equivalent to saying, “we can’t tell you it’s an elephant, but we can confirm that it is large, grey, and capable of crushing your skull if you lay down in front of it. Oh yeah, and it has a trunk and hates mice.”

So let’s update what we know, what we don’t, what you should do, and the open questions from our first post:

What we know

Based on the updated information… not much we didn’t before.

But I believe RSA understands the strict definition of APT and isn’t using the term to indicate a random, sophisticated attack. So we can infer who the actor is – China – but RSA isn’t saying and we don’t have confirmation.

In terms of what was lost, the answer is, “an elephant” even if they don’t want to say so. This means either customer token records or something similar, and I can’t think of what else it could be. Here’s a quote from them that makes it almost obvious:

To compromise any RSA SecurID deployment, the attacker needs to possess multiple pieces of information about the token, the customer, the individual users and their PINs. Some of this information is never held by RSA and is controlled only by the customer. In order to mount a successful attack, someone would need to have possession of all this information.

If it were a compromise of the authentication server software itself, that statement wouldn’t be accurate. Also, one of their top recommendations is to use long, complex PINs. They wouldn’t say that if the server was compromised, which means it pretty much has to be related to customer token records.

This also leads us to understand the nature of a potential attack. The attacker would need to know the username, password/PIN, and probably the individual assigned token. Plus they need some time and luck. While extremely serious for high-value targets, this does limit potential exposure. This also explains their recommendations on social engineering, hardening the authentication server, setting PIN lockouts, and checking logs for ongoing bad token/authentication requests.

I think his name is Babar.

What we don’t know

We don’t have any confirmation of anything at this point, which is frankly silly unless we are missing some major piece of the puzzle.

Until then it’s reasonable to assume a single sophisticated attacker (with a very tasty national cuisine), and compromise of token seeds/records. This reduces the target pool and means most people should be in good shape with the practices we previously recommended (updated below).

One big unknown is when this happened. That’s important, especially for high-value targets, as it could mean they have been under attack for a while, and opponents might have harvested some credentials via social engineering or other means already.

We also don’t know why RSA isn’t simply telling us what they lost. With all these recommendations it’s clear that the attacker still needs to be sophisticated to pull off more attacks with the SecurID data, and needs to have that data, which means customer risk is unlikely to increase if they reveal more.

This isn’t like a 0-day vulnerability, where merely knowing it’s out there is a path to exploitation. More information now will only reduce customer risk.

What you need to do

Here are our updated recommendations:

Remember that SecurID is the second factor in a two-factor system… you aren’t stripped naked (unless you’re going through airport security). Assuming it’s completely useless now, here is what you can do:

  1. Don’t panic. Although we don’t know a lot more, we have a strong sense of the attacker and the vulnerability. Most of you aren’t at risk if you follow RSA’s recommendations. Many of you aren’t on the target list at all.
  2. Talk to your RSA representative and pressure them for increased disclosure.
  3. Read the RSA SecureCare documentation. Among other things, it provides the specific things to look for in your logs.
  4. Let your users with SecurIDs know something is up and not to reveal any information about their tokens.
  5. Assume SecureID is no longer effective. Review passwords/PINs tied to SecurID accounts and make sure they are strong (if possible). If you change settings to use long PINs, you need to get an update script from RSA (depending on your product version) so the update pushes out properly.
  6. If you are a high-value target, force a password change for any accounts with privileges that could be seriously damaging (e.g., admins).
  7. Consider disabling accounts that don’t use a password or PIN.
  8. Set authentication attempt lockouts (3 tries to lock an account, or similar).

The biggest changes are a little more detail on what to look for, which supports our previous assumptions. That and my belief their use of the term APT is accurate.

Open questions

I will add in my own answers where we have them:

  1. While we don’t need all the details, we do need to know something about the attacker to evaluate our risk. Can you (RSA) reveal more details? Not answered, but reading between the lines this looks like true APT.
  2. How is SecurID affected and will you be making mitigations public? Partially answered. More specific mitigations are now published, but we still don’t have full information.
  3. Are all customers affected or only certain product versions and/or configurations? Answered – see the SecureCare documentation, but it seems to be all current versions.
  4. What is the potential vector of attack? Unknown, so we are still assuming it’s lost token records/seeds, which means the attacker needs to gather other information to successfully make an improper authentication request.
  5. Will you, after any investigation is complete, release details so the rest of us can learn from your victimization? Answered. An RSA contact told me they have every intention on getting as detailed as possible once this is all over.

And one remaining question:

  1. Will RSA need to reissue tokens, and if so what is the timing and process?

Hopefully this all helps. For most of you there isn’t a whole lot to do at this point, but some of you most definitely need to make changes and keep your eyes open.


Friday, March 18, 2011

How Enterprises Can Respond to the RSA/SecurID Breach

By Rich

We have gotten a bunch of questions about what people should do, so I thought I would expand more on the advice in our last post, linked below.

Since we don’t know for sure who compromised RSA, nor exactly what was taken, nor how it could be used, we can’t make an informed risk decision. If you are in a high-security/highly-targeted industry you probably need to make changes right away. If not, some basic precautions are your best bet.

Remember that SecurID is the second factor in a two-factor system… you aren’t stripped naked (unless you’re going through airport security). Assuming it’s completely useless now, here is what you can do:

  1. Don’t panic. We know almost nothing at this point, and thus all we can do is speculate. Until we know the attacker, what was lost, how SecurID was compromised (assuming it was), and the potential attack vector we can’t make an informed risk assessment.
  2. Talk to your RSA representative and pressure them for this information.
  3. Assume SecureID is no longer effective. Review passwords tied to SecurID accounts and make sure they are strong (if possible).
  4. If you are a high-value target, force a password change for any accounts with privileges that could be overly harmful (e.g., admins).
  5. Consider disabling accounts that don’t use a password or PIN.
  6. Set password attempt lockouts (3 tries to lock an account, or similar).

I hope we’re wrong, but that’s the safe bet until we hear more. And remember, it isn’t like Skynet is out there compromising every SecurID-‘protected’ account in the world.


Thursday, March 17, 2011

**Updated** RSA Breached: SecurID Affected

By Rich

You will see this all over the headlines during the next days, weeks, and maybe even months. RSA, the security division of EMC, announced they were breached and suffered data loss.

Before the hype gets out of hand, here’s what we know, what we don’t, what you need to do, and some questions we hope are answered:

What we know

According to the announcement, RSA was breached in an APT attack (we don’t know if they mean China, but that’s well within the realm of possibility) and material related to the SecureID product was stolen.

The exact risk to customers isn’t clear, but there does appear to be some risk that the assurance of your two factor authentication has been reduced.

RSA states they are communicating directly with customers with hardening advice. We suspect those details are likely to leak or become public, considering how many people use SecurID. I can also pretty much guarantee the US government is involved at this point.

Our investigation has led us to believe that the attack is in the category of an Advanced Persistent Threat (APT). Our investigation also revealed that the attack resulted in certain information being extracted from RSA’s systems. Some of that information is specifically related to RSA’s SecurID two-factor authentication products. While at this time we are confident that the information extracted does not enable a successful direct attack on any of our RSA SecurID customers, this information could potentially be used to reduce the effectiveness of a current two-factor authentication implementation as part of a broader attack. We are very actively communicating this situation to RSA customers and providing immediate steps for them to take to strengthen their SecurID implementations.

What we don’t know

We don’t know the nature of the attack. They specifically referenced APT, which means it’s probably related to custom malware, which could have been infiltrated in a few different ways – a web application attack (SQL injection), email/web phishing, or physical access (e.g., an infected USB device – deliberate or accidental). Everyone will have their favorite pet theory, but right now none of us know cr** about what really happened. Speculation is one of our favorite pastimes, but largely meaningless other than as entertainment, until details are released (or leak).

We don’t know how SecurID is affected. This is a big deal, and the odds are just about 100% that this will leak… probably soon. For customers this is the most important question.

What you need to do

If you aren’t a SecurID customer… enjoy the speculation.

If you are, make sure you contact your RSA representative and find out if you are at risk, and what you need to do to mitigate that risk. How high a priority this is depends on how big a target you are – the Big Bad APT isn’t interested in all of you.

The letter’s wording might mean the attackers have a means to generate certain valid token values (probably only in certain cases). They would also need to compromise the password associated with that user. I’m speculating here, which is always risky, but that’s what I think we can focus on until we hear otherwise. So reviewing the passwords tied to your SecurID users might be reasonable.

Open questions

  1. While we don’t need all the details, we do need to know something about the attacker to evaluate our risk. Can you (RSA) reveal more details?
  2. How is SecurID affected and will you be making mitigations public?
  3. Are all customers affected or only certain product versions and/or configurations?
  4. What is the potential vector of attack?
  5. Will you, after any investigation is complete, release details so the rest of us can learn from your victimization?

Finally – if you have a token from a bank or other provider, make sure you give them a few days and then ask them for an update.

If we get more information we’ll update this post. And sorry to you RSA folks… this isn’t fun, and I’m not looking forward to the day it’s our turn to disclose.

Update 19:20 PT: RSA let us know they filed an 8-K. The SecureCare document is linked here and the recommendations are a laundry list of security practices… nothing specific to SecurID. This is under active investigation and the government is involved, so they are limited in what they can say at this time. Based on the advice provided, I won’t be surprised if the breach turns out to be email/phishing/malware related.


Wednesday, January 26, 2011

Register for Our Cloud Security Training Class at RSA

By Rich

As we previously mentioned, we will teach the very first CSA Cloud Computing Security Knowledge (Enhanced) class the Sunday before RSA. We finally have some more details and the registration link.

The class costs $400 and include a voucher worth $295 to take the Cloud Computing Security Knowledge (CCSK) exam. We are working with the CSA and this is our test class to check out the material before it is sent to other training organizations. Basically, you get a full day of training with most of the Securosis team for $105.

Not bad, unless you don’t like us.

The class will be in Moscone and includes a mix of lecture and practical exercises.

You can register online and we hope to see you there!

(Yes, that means it’s a long week. I’ll buy anyone in the class their first beer to make up for it).


Monday, March 08, 2010

RSA Tomfoolery: APT is the Fastest Way to Identify Fools and Liars

By Rich

It is better to stay silent and let people think you are an idiot than to open your mouth and remove all doubt.

–Abraham Lincoln

Although we expected APT to be the threat du jour at RSA, I have to admit even I was astounded at the outlandish displays of idiocy and outright deception among pundits and the vendor community.

Now, let’s give credit where credit is due – only a minority of vendors hopped on the APT bandwagon. This post isn’t meant to be a diatribe against the entire product community, only those few who couldn’t help themselves in the race to the bottom.

I’m not claiming to be an expert in APT, but at least I’ve worked with organizations struggling with the problem (starting a few years ago when I began to get data security calls related to the problems of China-related data loss). The vast majority of the real experts I’ve met on the topic (those with direct experience) can’t really talk about it in public, but as I’ve mentioned before I’d sure as heck read Richard Beijtlich if you have any interest in the topic. I also make a huge personal effort to validate what little I say with those experts.

Most of the APT references I saw at RSA were ridiculously bad. Vendors spouting off on how their product would have blocked this or that malware version made public after the fact. Thus I assume any of them talking about APT were either deceptive, uninformed, or stupid.

All this was summarized in my head by one marketing person who mentioned they were planning on talking about “preventing” APT (it wasn’t in their materials yet) because they could block a certain kind of outbound traffic. I explained that APT isn’t merely the “Aurora” attack and is sort of the concerted espionage efforts of an entire country, and they responded, “oh – well our CEO heard about it and thought it was the next big thing, so we should start marketing on it.”

And that, my friends, is all you need to know about (certain) vendors and APT.


Wednesday, September 30, 2009

Tokenization Will Become the Dominant Payment Transaction Architecture

By Rich

I realize I might be dating myself a bit, but to this day I still miss the short-lived video arcade culture of the 1980’s. Aside from the excitement of playing on “big hardware” that far exceeded my Atari 2600 or C64 back home (still less powerful than the watch on my wrist today), I enjoyed the culture of lining up my quarters or piling around someone hitting some ridiculous level of Tempest.

One thing I didn’t really like was the whole “token” thing. Rather than playing with quarters, some arcades (pioneered by the likes of that other Big Mouse) issued tokens that would only work on their machines. On the upside you would occasionally get 5 tokens for a dollar, but overall it was frustrating as a kid. Years later I realized that tokens were a parental security control – worthless for anything other than playing games in that exact location, they keep the little ones from buying gobs of candy 2 heartbeats after a pile of quarters hits their hands.

With the increasing focus on payment transaction security due to the quantum-entangled forces of breaches and PCI, we are seeing a revitalization of tokenization as a security control. I believe it will become the dominant credit card transaction processing architecture until we finally dump our current plain-text, PAN-based system.

I first encountered the idea a few years ago while talking with a top-tier retailer about database encryption. Rather than trying to encrypt all credit card data in all their databases, they were exploring the possibility of concentrating the numbers in one master database, and then replacing the card numbers with “tokens” in all the other systems. The master database would be highly hardened and encrypted, and keep track of which token matched which credit card. Other systems would send the tokens to the master system for processing, which would then interface with the external transaction processing systems.

By swapping out all the card numbers, they could focus most of their security efforts on one controlled system that’s easier to control. Sure, someone might be able to hack the application logic of some server and kick off an illicit payment, but they’d have to crack the hardened master server to get card numbers for any widespread fraud.

We’ve written about it a little bit in other posts, and I have often recommended it directly to users, but I probably screwed up by not pushing the concept on a wider basis. Tokenization solves far more problems than trying to encrypt in place, and while complex it is still generally easier to implement than alternatives. Well-designed tokens fit the structure of credit card numbers, which may require fewer application changes in distributed systems. The assessment scope for PCI is reduced, since card numbers are only in one location, which can reduce associated costs. From a security standpoint, it allows you to focus more effort on one hardened location. Tokenization also reduces data spillage, since there are far fewer locations which use card numbers, and fewer business units that need them for legitimate functions, such as processing refunds (one of the main reasons to store card numbers in retail environments).

Today alone we were briefed on two different commercial tokenization offerings – one from RSA and First Data Corp, the other from Voltage. The RSA/FDC product is a partnership where RSA provides the encryption/tokenization tech FDC uses in their processing service, while Voltage offers tokenization as an option to their Format Preserving Encryption technology. (Voltage is also partnering with Heartland Payment Systems on the processing side, but that deal uses their encryption offering rather than tokenization).

There are some extremely interesting things you can do with tokenization. For example, with the RSA/FDC offering, the card number is encrypted on collection at the point of sale terminal with the public key of the tokenization service, then sent to the tokenization server which returns a token that still “resembles” a card number (it passes the LUHN check and might even include the same last 4 digits – the rest is random). The real card number is stored in a highly secured database up at the processor (FDC). The token is the stored value on the merchant site, and since it’s paired with the real number on the processor side, can still be used for refunds and such. This particular implementation always requires the original card for new purchases, but only the token for anything else.

Thus the real card number is never stored in the clear (or even encrypted) on the merchant side. There’s really nothing to steal, which eliminates any possibility of a card number breach (according to the Data Breach Triangle). The processor (FDC) is still at risk, so they will need to use a different set of technologies to lock down and encrypt the plain text numbers. The numbers still look like real card numbers, reducing any retrofitting requirements for existing applications and databases, but they’re useless for most forms of fraud. This implementation won’t work for recurring payments and such, which they’ll handle differently.

Over the past year or so I’ve become a firm believer that tokenization is the future of transaction processing – at least until the card companies get their stuff together and design a stronger system. Encryption is only a stop-gap in most organizations, and once you hit the point where you have to start making application changes anyway, go with tokenization.

Even payment processors should be able to expand use of tokenization, relying on encryption to cover the (few) tokenization databases which still need the PAN.

Messing with your transaction systems, especially legacy databases and applications, is never easy. But once you have to crack them open, it’s hard to find a downside to tokenization.


Friday, May 01, 2009

Friday Summary: May 1, 2009

By Rich

Sometimes the most energizing thing you can do is absolutely nothing.

Last week at RSA was absolutely insane, in a good way. It’s kind of like being a kid and going to summer camp. You get to see all the friends who live in other towns, you all go nuts for a week with minimal supervision, and then everyone staggers home all excited. Between the Recovery Breakfast, 4 official RSA panels, a Jericho panel, my 160+ slide Friday morning session with Chris Hoff, and the nonstop speed-dating during the day, and parties at night, I should really be in much worse shape. But I found this year’s RSA to be incredibly motivating on multiple levels.

First, I think this is absolutely one of the best times to be in information security. Yes, major crap is hitting the fan all over the place, including massive national security, financial, and infrastructure breaches, but security is also hitting the front pages and reaching into the common consciousness. This is exactly the kind of environment true security professionals thrive on – with challenges and opportunities on all sides. As someone who loves the practice and theory of security, I find these challenges to be absolutely energizing and I wouldn’t want to be doing anything else. Well, except for maybe being an astronaut.

Next, RSA was extremely motivating from a corporate standpoint. I won’t say much, but it validated what we’re trying to do, and how we are positioning ourselves.

Finally, it was a very motivating week on a personal level. I used to have friends at work, and acquaintances in the industry. But these days I find some of my closest friends are scattered throughout the world in different jobs. I realized I spend more time interacting with many of you than I do with my local ‘meatspace’ friends outside of the industry. I especially appreciated the group that took me out for my birthday on Monday night – it really eased the pain of spending yet another family event away from my wife and (new) daughter.

After RSA I took 4 days off, and the combination of intensity followed by relaxation was a major recharge, but didn’t leave me much content for this week’s summary. Except stay away from, like, every Adobe product on the planet since they are all full of 0days.

One reminder – if you’d like to get our content via email instead of RSS, please head over and sign up for the Daily Digest (it goes out every night). We’re also thinking of creating a Friday Summary-only version, so let us know if that would be of interest.

And now for the week in review:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Favorite Outside Posts

Top News and Posts

Blog Comment of the Week

This week’s best comment was from Ant in response to Rich’s post on Security Industry Disambiguation Movement.

Well I mint not have chosen those terms, but I personally* fully endorse the sentiment!

A different problem arises where a perfectly serviceable term is pressed into use in several different but not wholly dissimilar markets, leading to ambiguity and confusion – e.g., identity management, policy management. So… it’s not strictly anti-disambiguation, but it some vendors are guilty of disingenuously using a term which doesn’t apply to them in their market.

– Ant

* i.e., this is not (necessarily) the official view of my employer.


Wednesday, April 15, 2009

The Network Security Podcast, Episode 146

By Rich

Things are so crazy this week, getting ready for RSA, that I nearly forgot we record this little podcast thing every week. Sure, I’ve only been doing it every week for over a year, but you’d think I’d learn to remember.

This week we start by reviewing all the happenings at RSA, before talking about the cable cuts in the Bay Area and the Twitter worm. Martin and I will be doing our best to push out shorter daily shows (usually interviews) every day at RSA, and these tend to be some of our more popular episodes.

The Network Security Podcast, Episode 146.


Tuesday, March 17, 2009

Securosis at RSA

By Rich

Ah yes, as spring approaches, so does Sundance for Ugly People (as a friend likes to call the RSA Security Conference).

We will, of course, be there. But unlike other years we have a little surprise brewing.

Schedule-wise I’m giving one track session, and participating in 3 panels:

  • Tuesday at 1:30 PM: Discover, Protect, and Securely Share Sensitive Corporate Data (panel on DLP/DRM/etc.).
  • Tuesday at 4:10 PM: “Groundhog Day” – History Repeats Itself (with Rothman, McKeay, Mortman and Ron Woerner- my favorite panel).
  • Thursday at 9:20 AM (those bastards, 9am?): Which Security Tools Take Priority in a Challenging Economic Climate? (panel with Shimel, Rothman, and… okay, sorry to leave someone off). Should be a hoot.
  • Friday at 10:10 AM: Disruptive Innovation and the Future of Security (With The Hoff. Flat out, this session is going to rock, and it’s worth changing your flight to stay for).

We’re still figuring out our schedule for non-official speaking slots. Priority goes to the paying clients (since we are totally… “professionals”… and need to pay for our post RSA rehab trip). We have a few slots open, but also some things on the table and are hoping to lock it down by next week (breakfast/lunch/mid-day stuff only, evenings are all tied up already).

Like many of you, we plan to fully participate in all the evening activities. If you’ve been to RSA before, you also know that comes at a price to be extracted the following morning. To ease your pain, on Wednesday we are sponsoring the Securosis Recovery Breakfast. For a few hours we’ll have an open buffet with all the required recovery tools (aspirin, Tums, activated charcoal administered by an expired paramedic). No presentations, subdued lighting, and loud noises prohibited.

We’ll be posting more details on it next week, and highly encourage you to RSVP so we can make sure we have enough food. The location will be extremely convenient, and we should have it locked down in the next couple of days.

And that’s it! We look forward to seeing everyone there, and if you want to meet, please hit us up as soon as possible so we can coordinate schedules.


Thursday, December 04, 2008

Analysis Of The Microsoft/RSA Data Loss Prevention Partnership

By Rich

By the time I post this you won’t be able to find a tech news site that isn’t covering this one. I know, since my name was on the list of analysts the press could contact and I spent a few hours talking to everyone covering the story yesterday. Rather than just reciting the press release, I’d like to add some analysis, put things into context, and speculate wildly. For the record, this is a big deal in the long term, and will likely benefit all of the major DLP vendors, even though there’s nothing earth shattering in the short term.

As you read this, Microsoft and RSA are announcing a partnership for Data Loss Prevention. Here are the nitty gritty details, not all of which will be apparent from the press release:

  • This month, the RSA DLP product (Tablus for you old folks) will be able to assign Microsoft RMS (what Microsoft calls DRM) rights to stored data based on content discovery. The way this works is that the RMS administrator will define a data protection template (what rights are assigned to what users). The RSA DLP administrator then creates a content detection policy, which can then apply the RMS rights automatically based on the content of files. The RSA DLP solution will then scan file repositories (including endpoints) and apply the RMS rights/controls to protect the content.
  • Microsoft has licensed the RSA DLP technology to embed into various Microsoft products. They aren’t offering much detail at this time, nor any timelines, but we do know a few specifics. Microsoft will slowly begin adding the RSA DLP content analysis engine to various products. The non-NDA slides hint at everything from SQL Server, Exchange, and Sharepoint, to Windows and Office. Microsoft will also include basic DLP management into their other management tools.
  • Policies will work across both Microsoft and RSA in the future as the products evolve. Microsoft will be limiting itself to their environment, with RSA as the upgrade path for fuller DLP coverage.

And that’s it for now. RSA DLP 6.5 will link into RMS, with Microsoft licensing the technology for future use in their products. Now for the analysis:

  • This is an extremely significant development in the long term future of DLP. Actually, it’s a nail in the coffin of the term “DLP” and moves us clearly and directly to what we call “CMP”- Content Monitoring and Protection. It moves us closer and closer to the DLP engine being available everywhere (and somewhat commoditized), and the real value in being in the central policy management, analysis, workflow, and incident management system. DLP/CMP vendors don’t go away- but their focus changes as the agent technology is built more broadly into the IT infrastructure (this definitely won’t be limited to just Microsoft).
  • It’s not very exciting in the short term. RSA isn’t the first to plug DLP into RMS (Workshare does it, but they aren’t nearly as big in the DLP market). RSA is only enabling this for content discovery (data at rest) and rights won’t be applied immediately as files are created/saved. It’s really the next stages of this that are interesting.
  • This is good for all the major DLP vendors, although a bit better for RSA. It’s big validation for the DLP/CMP market, and since Microsoft is licensing the technology to embed, it’s reasonable to assume that down the road it may be accessible to other DLP vendors (be aware- that’s major speculation on my part).
  • This partnership also highlights the tight relationship between DLP/CMP and identity management. Most of the DLP vendors plug into Microsoft Active Directory to determine users/groups/roles for the application of content protection policies. One of the biggest obstacles to a successful DLP deployment can be a poor directory infrastructure. If you don’t know what users have what roles, it’s awfully hard to create content-based policies that are enforced based on users and roles.
  • We don’t know how much cash is involved, but financially this is likely good for RSA (the licensing part). I don’t expect it to overly impact sales in the short term, and the other major DLP vendors shouldn’t be too worried for now. DLP deals will still be competitive based on the capabilities of current products, more than what’s coming in an indeterminate future.

Now just imagine a world where you run a query on a SQL database, and any sensitive results are appropriately protected as you place them into an Excel spreadsheet. You then drop that spreadsheet into a Powerpoint presentation and email it to the sales team. It’s still quietly protected, and when one sales guy tries to email it to his Gmail account, it’s blocked. When he transfers it to a USB device, it’s encrypted using a company key so he can’t put it on his home computer. If he accidentally sends it to someone in the call center, they can’t read it. In the final PDF, he can’t cut out the table and put it in another document. That’s where we are headed- DLP/CMP is enmeshed into the background, protecting content through it’s lifecycle based on central policies and content and context awareness.

In summary, it’s great in the long term, good but not exciting in the short term, and beneficial to the entire DLP market, with a slight edge for RSA. There are a ton of open questions and issues, and we’ll be watching and analyzing this one for a while.

As always, feel free to email me if you have any questions.