Login  |  Register  |  Contact


Wednesday, February 03, 2016

Incite 2/3/2016: Courage

By Mike Rothman

A few weeks ago I spoke about dealing with the inevitable changes of life and setting sail on the SS Uncertainty to whatever is next. It’s very easy to talk about changes and moving forward, but it’s actually pretty hard to do. When moving through a transformation, you not only have to accept the great unknown of the future, but you also need to grapple with what society expects you to do. We’ve all been programmed since a very early age to adhere to cultural norms or suffer the consequences. Those consequences may be minor, like having your friends and family think you’re an idiot. Or decisions could result in very major consequences, like being ostracized from your community, or even death in some areas of the world.

In my culture in the US, it’s expected that a majority of people should meander through their lives; with their 2.2 kids, their dog, and their white picket fence, which is great for some folks. But when you don’t fit into that very easy and simple box, moving forward along a less conventional path requires significant courage.


I recently went skiing for the first time in about 20 years. Being a ski n00b, I invested in two half-day lessons – it would have been inconvenient to ski right off the mountain. The first instructor was an interesting guy in his 60’s, a US Air Force helicopter pilot who retired and has been teaching skiing for the past 25 years. His seemingly conventional path worked for him – he seemed very happy, especially with the artificial knee that allowed him to ski a bit more aggressively. But my instructor on the second day was very interesting. We got a chance to chat quite a bit on the lifts, and I learned that a few years ago he was studying to be a physician’s assistant. He started as an orderly in a hospital and climbed the ranks until it made sense for him to go to school and get a more formal education. So he took his tests and applied and got into a few programs.

Then he didn’t go. Something didn’t feel right. It wasn’t the amount of work – he’d been working since he was little. It wasn’t really fear – he knew he could do the job. It was that he didn’t have passion for a medical career. He was passionate about skiing. He’d been teaching since he was 16, and that’s what he loved to do. So he sold a bunch of his stuff, minimized his lifestyle, and has been teaching skiing for the past 7 years. He said initially his Mom was pretty hard on him about the decision. But as she (and the rest of his family) realized how happy and fulfilled he is, they became OK with his unconventional path.

Now that is courage. But he said something to me as we were about to unload from the lift for the last run of the day. “Mike, this isn’t work for me. I happened to get paid, but I just love teaching and skiing, so it doesn’t feel like a job.” It was inspiring because we all have days when we know we aren’t doing what we’re passionate about. If there are too many of those days, it’s time to make changes.

Changes require courage, especially if the path you want to follow doesn’t fit into the typical playbook. But it’s your life, not theirs. So climb aboard the SS Uncertainty (with me) and embark on a wild and strange adventure. We get a short amount of time on this Earth – make the most of it. I know I’m trying to do just that.

Editors note: despite Mike’s post on courage, he declined my invitation to go ski Devil’s Crotch when we are out in Colorado. Just saying. -rich


Photo credit: “Courage” from bfick

It’s that time of year again! The 8th annual Disaster Recovery Breakfast will once again happen at the RSA Conference. Thursday morning, March 3 from 8 – 11 at Jillians. Check out the invite or just email us at rsvp (at) securosis.com to make sure we have an accurate count.

The fine folks at the RSA Conference posted the talk Jennifer Minella and I did on mindfulness at the 2014 conference. You can check it out on YouTube. Take an hour. Your emails, alerts, and Twitter timeline will be there when you get back.

Securosis Firestarter

Have you checked out our video podcast? Rich, Adrian, and Mike get into a Google Hangout and… hang out. We talk a bit about security as well. We try to keep these to 15 minutes or less, and usually fail.

Heavy Research

We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too.

Securing Hadoop

SIEM Kung Fu

Building a Threat Intelligence Program

Recently Published Papers

* The Future of Security

Incite 4 U

  1. Evolution visually: Wade Baker posted a really awesome piece tracking the number of sessions and titles at the RSA Conference over the past 25 years. The growth in sessions is astounding (25% CAGR), up to almost 500 in 2015. Even more interesting is how the titles have changed. It’s the RSA Conference, so it’s not surprising that crypto would be prominent the first 10 years. Over the last 5? Cloud and cyber. Not surprising, but still very interesting facts. RSAC is no longer just a trade show. It’s a whole thing, and I’m looking forward to seeing the next iteration in a few weeks. And come swing by the DRB Thursday morning and say hello. I’m pretty sure the title of the Disaster Recovery Breakfast won’t change. – MR

  2. Embrace and Extend: The SSL/TLS cert market is a multi-billion dollar market – with slow and steady growth in the sale of certificates for websites and devices over the last decade. For the most part, certificate services are undifferentiated. Mid-to-large enterprises often manage thousands of them, which expire on a regular basis, making subscription revenue a compelling story for the handful of firms that provide them. But last week’s announcement that Amazon AWS will provide free certificates must have sent shivers through the market, including the security providers who manage certs or monitor for expired certificates. AWS will include this in their basic service, as long as you run your site in AWS. I expect Microsoft Azure and Google’s cloud to follow suit in order to maintain feature/pricing parity. Certs may not be the best business to be in, longer-term. – AL

  3. Investing in the future: I don’t normally link to vendor blogs, but this post by Chuck Robbins, Cisco’s CEO, is pretty interesting. He echoes a bunch of things we’ve been talking about, including how the security industry is people-constrained, and we need to address that. He also mentions a bunch of security issues, s maybe security is highly visible in security. Even better, Chuck announced a $10MM scholarship program to “educate, train and reskill the job force to be the security professionals needed to fill this vast talent shortage”. This is great to see. We need to continue to invest in humans, and maybe this will kick start some other companies to invest similarly. – MR

  4. Geek Monkey: David Mortman pointed me to a recent post about Automated Failure testing on Netflix’s Tech blog. A particularly difficult to find bug gave the team pause in how they tested protocols. Embracing both the “find failure faster” mentality, and the core Simian Army ideal of reliability testing through injecting chaos, they are looking at intelligent ways to inject small faults within the code execution path. Leveraging a very interesting set of concepts from a tool called Molly (PDF), they inject different results into non-deterministic code paths. That sounds exceedingly geeky, I know, but in simpler terms they are essentially fuzz testing inside code, using intelligently selected values to see how protocols respond under stress. Expect a lot more of this approach in years to come, as we push more code security testing earlier in the process. – AL

–Mike Rothman

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.