Research

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: Something bad happens. The folks in charge first ask, “who knows” to figure out whether they can keep it secret. 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. 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. The press beats the crap out of them for not releasing complete information. 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. 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. 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. The next day (or within a few hours, depending on the severity) customers start asking their account reps questions. 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. 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. 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”. 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. 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. 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: 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. 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. 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. Update constantly. Even if you are repeating yourself. Again, don’t leave a blank canvas for others to fill in. Understand that everything leaks. Again, better for you to provide the information than an anonymous insider. Always always put your customers and the public first. If not, they’ll know

Beyond the base FAM features, there are two additional functions to consider, depending on your requirements. We expect these to eventually join the base feature set, but for now they aren’t consistent across the available products. Activity Blocking (Firewall) As with many areas of security, once you start getting alerts and reports of incidents ranging from minor accidents to major breaches, you might find yourself wishing you could actually block the incident instead of merely seeing an alert. That’s where activity blocking comes into place – some vendors call this a ‘firewall’ function. Using the same kinds of policies developed for activity analysis and alerts, you can choose to block based on various criteria. Blocking may take one of several different forms: Inline blocking, if the FAM server or appliance is between the user and the file. The tool normally runs in bridge mode, so it can selectively drop requests. Agent-based blocking, when the FAM is not inline – instead an agent terminates the connection. Permission-based blocking, where file permissions are changed to prevent the user’s access in real time. This might be used, for example, to block activity on systems lacking a local agent or inline protection. Those three techniques are on the market today. The following methods are used in similar products and may show up in future updates to existing tools: TCP RESET is a technique of “killing” a network session by injecting a “bad” packet. We’ve seen this in some DLP products, and while it has many faults, it does allow real-time blocking without an inline device, and does not require a local agent or the ability to perform permission changes. Management system integration for document management systems. Some provide APIs for blocking, and others provide plugin mechanisms which can provide this functionality. All blocking tools support both alert and block policies. You could, for example, send an alert when a user copies a certain number of files out of a sensitive directory in a time period, followed by blocking at a higher threshold. DLP Integration Data Loss Prevention plays a related role in data security by helping identify, monitor, and protect based on deep content analysis. There are cases where it makes sense to combine DLP and FAM, even though they both provide benefits on their own. The most obvious option for integration is to use DLP to locate sensitive information and pass it to FAM; the FAM system can then confirm permissions are appropriate and dynamically create FAM policies based on the sensitivity of the content. A core function of DLP is its ability to identify files in repositories which match content-based polices – we call this content discovery, and it is not available in FAM products. Here’s how it might work: FAM is installed with policies that don’t require knowledge of the content. DLP scans FAM-protected repositories to identify sensitive information, such as Social Security Numbers inside files. DLP passes the scan results to FAM, which now has a list of files containing SSNs. FAM checks permissions for the received files, compares them against its policies for files containing Social Security Numbers, and applies corrective actions to comply with policy (e.g., removing permissions for users not authorized to access SSNs). FAM applies an SSN alerting policy to the repository or directory/file. This is all done via direct integration or within a single product (at least one DLP tool includes basic FAM). Even if you don’t have integration today, you can handle this manually by establishing content-driven policies within your FAM tool, and manually applying them based on reports from your DLP product. Share:

I am probably in the minority, but when I buy something I think of it as mine. I paid for it so I own it. I buy a lot of stuff I am not totally happy with, but that’s the problem with being a tinkerer. Usually I think I can improve on what I purchased, or customize my purchase to my liking. This could be as simple as adding sugar to my coffee, or having a pair of pants altered, or changing the carburetor on that rusty Camaro in my backyard. More recently it’s changing game save files or backing out ‘fixes’ that break software. It’s not the way the manufacturer designed it or implemented it, but it’s the way I want it. One man’s bug is another man’s feature. But as the stuff I bought is mine – I paid for it, after all – I am free to fix or screw things up as I see fit. Somewhere along the line, the concept of ownership was altered. We buy stuff then treat it as if it’s not ours. I am not entirely sure when this concept went mainstream, but I am willing to bet it started with software vendors – you know, the ones who write those End User License Agreements that nobody reads because that would be a waste of time and delay installing the software they just bought. I guess this is why I am so bothered by stories like Sony suing some kid – George Holtz – for altering a PlayStation 3. Technically they are not pissed off at him for altering the function of his PlayStation – they are pissed that he taught others how to modify their consoles so they can run whatever software they want. The unstated assumption is that anyone who would do such a thing is a scoundrel and criminals, out to pirate software and destroy hard-working companies (And all their employees! Personally!). These PlayStations were purchased – personal property if you will – and their owners should be able to do as they see fit with their possessions. Don’t like Sony’s OS and want to run Linux? Those customers bought the PS3s (and Sony promised support, then reneged) so they should be able to run what they want without interference. It’s not that George is trying to resell the PlayStation code, or copy the PlayStation and sell a derived work. He’s not reselling Halo or an Avatar Blu-ray; he’s altering his own stuff to suit his needs, and then sharing. This is not an issue of content or intellectual property, but of personal property. Sony should be able to void his warranty, but coming after him legally is totally off-the-charts insane IMO. Now I know Sony has better lobbyists than either George or myself, so it’s much more likely that laws – such as the Digital Millennium Copyright Act (DCMA) – reflect their interests rather than ours. I just can’t abide by the notion that someone sells me a product and then demands I use it only as they see fit. Especially when they want to prohibit my enjoyment because there is a possibility someone could run pirated software. If you take my money, I am going to add hard drives or memory of software as I like. If companies like Sony don’t like that, they should not sell the products. Cases like this call the legitimacy of the DCMA into question. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich in Macworld on private browsing. Protect your privacy: online shopping. Mike’s first Macworld article. Rich quoted in the New York Times on RSA. A great response to Rich’s Table Stakes article. John Strand does a good job of presenting his own spin. Index link to Mike & Rich’s Macworld series on privacy. Adrian’s Dark Reading article on McAfee acquisition. Rich quoted on RSA breach. Adrian’s Dark Reading post on DB Security in the cloud. Favorite Securosis Posts Rich: Agile and Hammers – They Don’t Fix Stupid. I still don’t fully get how people glom on to something arbitrary and turn it into a religion. Mike Rothman: Agile and Hammers: They Don’t Fix Stupid. Rare that Adrian wields his snark hammer. Makes a number of great points about people – not process – FAIL. Gunnar Peterson: The CIO Role and Security. Adrian Lane: Crisis Communications. Other Securosis Posts FAM: Additional Features. McAfee Acquires Sentrigo. Incite 3/23/2011: SEO Unicorns. RSA Releases (Almost) More Information. FAM: Core Features and Administration, Part 1. Death, Taxes, and M&A. How Enterprises Can Respond to the RSA/SecurID Breach. Network Security in the Age of Any Computing: Index of Posts. Favorite Outside Posts Rich: Why Stuxnet Isn’t APT. Mike Cloppert is one of the few people out there talking about APT who actually knows what he’s talking about. Maybe some of those vendor marketing departments should read his stuff. Mike Rothman: The MF Manifesto for Programming, MF. Back to basics, MFs. And that is one MFing charming pig. Adrian Lane: A brief introduction to web “certificates”. While I wanted to pick the MF Manifesto as it made me laugh out loud, Robert Graham’s post on cryptography and succinct explanation of the Comodo hack was too good to pass up. Project Quant Posts NSO Quant: Index of Posts. NSO Quant: Health Metrics–Device Health. NSO Quant: Manage Metrics–Monitor Issues/Tune IDS/IPS. NSO Quant: Manage Metrics–Deploy and Audit/Validate. Research Reports and Presentations The Securosis 2010 Data Security Survey. Monitoring up the Stack: Adding Value to SIEM. Network Security Operations Quant Metrics Model. Network Security Operations Quant Report. Understanding and Selecting a DLP Solution. White Paper: Understanding and Selecting an Enterprise Firewall. Understanding and Selecting a Tokenization Solution. Security + Agile = FAIL Presentation. Top News and Posts Dozens of exploits released for popular SCADA programs. Twitter, Javascript Defeat NYT’s $40m Paywall. Apple patches unused Pwn2Own bug, 55 others in Mac OS. Spam Down 40 Pecent in Rustock’s Absence. The Challenge of Starting an Application Security Program. Hackers make off with TripAdvisor’s membership list. Talk of Facebook Traffic Being Detoured. Firefox 4 Content Security Policy feature. Firefox