Rsa

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.

–Rich

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.

–Rich

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

• Martin and Rich on the weekly Network Security Podcast.
• I did a series of three videos and an executive overview on DLP for Websense. It was kind of cool to go to a regular studio and have it professionally edited. The videos (all about 2 minutes long) and Executive Guide are designed to introduce technical or non-technical executives to DLP. It's all objective stuff, and cut-down versions of our more extensive materials.
• I show up in the Sydney Morning Herald, based on some TidBITS/Mac writing.
• Speaking of TidBITS, I wrote up some thoughts on how to read Mac security articles.
• I was quoted in a TechTarget article on cloud computing, based on my involvement in the Jericho panel.

Favorite Securosis Posts

• Rich: The latest Project Quant post -- we really need your feedback on the patch management cycle!
• Adrian: Rich's post on the Security Industry Anti-Disambiguation Movement. Having watched this first-hand at a couple of startups, I know how well the mere mention of a competing technology by one of the major competitors could halt your POC process in an instant.

Favorite Outside Posts

• Adrian: Favorite external was Greg Young's comment on Becoming the Threat ... An excellent analysis of something we see in society, and certainly something that is a problem here in Phoenix. Oddly, this is something I do NOT see with most corporate IT. Why is that?
• Rich: Chris Eng's Decoding the Verizon DBIR 2009 Cover. Very cool.

Top News and Posts

• Joint Strike fighter plans nicked. Will someone in charge WAKE THE FUCK UP!
• Good: Microsoft removes 'AutoRun' option for Memory sticks.
• Bad: Pushing 8 out through auto-update? What if I don't want it?
• Targetted worms and banking scams.
• Adobe is having a seriously bad run. More 0days.
• Interesting take on WAF+VA.
• The Black Hat call for papers is extended.

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.

–Rich

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.

–Rich

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.

–Rich

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.

–Rich

Data Discovery & Classification

By Adrian Lane

I was reading the RSA report on the Torpig/Sinowal trojan while stuck at the airport for several hours last Thursday. During my many hours of free time I overheard some IT executive discussing the difficulties of implementing data discovery and classification with his peers. I did not catch the name of the company, and probably would not pass it along even if I had, but the tired and whiny rant about their associated failures was not unique. Perhaps I was a bit testy about having to sit in an airport lobby for eight hours, but all I could think was "What is wrong with you? If hackers can navigate your data center, why can't you?"

That's where the RSA report just gelled my thoughts on the subject. If a small group, quite literally a handful of hackers, can use Torpig & BlaBla to steal hundreds of thousands of credit card numbers, steal accounts and passwords, install malicious software at multiple company sites ... all without being provided credentials, access rights or a specific map of your IT infrastructure ... why can't your company classify its own data and intellectual property assets? You would think that a company, given a modest amount of resources, could discover, classify and categorize its own data. I mean, if you paid someone full time to do it, don't you think you could get the job done?

Some of the irritating points that they raised ...

"Data in motion made it difficult to track": So what- the hacker tools are kept running and they never stopped scanning. Nor did they give up on the first try; rather they periodically modified their code to adapt for location and type of data, and they were persistent. You should be too.

"Difficulty to classify the data" and "Can't find stuff you know is there": So what- hire better programmers. Pressure vendors for better tools. Can't afford expensive software? There is open source code out there to start with; hackers can do it, so can you. There is at least a dozen programatic ways to analyze data, through content or even context, and probably even more ways to traverse/crawl/inspect systems. If the application your company uses it can find it, so can you.

"Size of the project is difficult to manage": So what- divide and conquer. Take a specific set of data you are worried about and start there. Compliance group breathing down your neck to meet XYZ regulation? Pick one category (customer accounts, credit card data, source code, whatever. Tune your tools and policies (you did not really think you were going to get perfection out of the box did you?), address the problem and move on. If you are starting with an ISACA or Cobit framework and trying to map a comprehensive strategy, stop making the problem more complex than it is. Hackers went for low hanging fruit; you should too.

"The results are not accurate": So what- your not going to be 100% right all the time. The hackers aren't either. Either accept 95-99% accuracy, or try something different. Or maybe your policy is out of line with reality and needs to be reconsidered.

"Expensive" and "Takes too much in the way of resources": No chance! If hackers can run malware for 18 months at TJX and related stores UNDETECTED, then the methods used are not resource hogs, nor did they invest that much money in the tools.

Some times, you just got to stop whinin' and git 'er done!

–Adrian Lane

Wireless Security Survey

By Adrian Lane

'Rich forwarded me the RSA Wireless Security Survey for 2008 that was just released this morning. The cities that they scanned were Paris, London & New York.

Public hotspots — designed to allow anyone with a wireless device to access the Internet on a pay-as-you-go or pre-paid basis — continue to grow in prevalence across all three cities, and in each case the growth of available hotspots accelerated significantly in 2008 compared with development in the preceding year. Paris saw the largest jump, with numbers increasing by over 300% and comfortably outstripping the comparative growth in New York City (44%) and London (34%). However, New York City remains the leader in regards to its concentration of hotspots. At 15%, New York City is well clear of London where just 5% of wireless access points were found to be hotspots. In Paris, hotspots represented 6% of all the access points we located.

It is interesting to compare the year over year changes, and to see what kind of encryption is being employed. It's certainly worth a review, and a little vendor hype is to be expected, but there are two things that worry me about survey's like this. First, the public perception that if the connection is encrypted that all is safe. Unless there is a shred secret or some other type of protection, most of these systems are vulnerable to man-in-the-middle attacks. Second is that the rogue hotspots are difficult to detect, which is the de-facto method for wireless man-in-the-middle.

If your an IT manager, you have very little way to assess risk from this report, so just assume wireless hotspots are compromised and that you need to deploy a system to thwart these attacks on externally accessible corporate WiFi. And as an end users, if you think you are safe just because you have established an encrypted connection at Starbucks, think again. The guy in the tiny corner apartment overlooking the store makes his living by sniffing personal information and passwords.

–Adrian Lane

Webcast On Tuesday: Encryption And Key Management

By Rich

This Tuesday I'll be giving a webcast for RSA on encryption and key management. It's heavy on the data center side; focusing on SAN/NAS/Tape, Databases, and Applications. Not much discussion of mobile or email, but a bit of file and folder (server based).

Here's the official description, and you can register here:

Encryption Considerations for the Enterprise

Business Trends, Impact, and Solutions

Government regulations and internal policies drive your need to secure information wherever it lives and travels. Get the facts on Encryption and Key Management technologies during this seminar series and Q&A featuring Rich Mogull, founder of Securosis.com, who will discuss:

• Why encrypt data? Where to encrypt data? What are the pros and cons of different solutions?
• What role should enterprise key management play as part of an overall encryption strategy?
• What is the value of centralizing encryption key management?

–Rich