Research

There are two ways to respond to criticism of your security product, especially when encryption is involved. Respond cautiously, openly, and positively as demonstrated last week by AgileBits, the folks behind 1Password. Do what CipherCloud did. The TL;DR is that some people over on StackExchange were trying to figure out how CipherCloud works (specifically its homomorphic encryption, which CipherCloud states isn’t actually part of the product). Some public materials were posted, and then the CipherCloud legal team smacked StackExchange with a DMCA takedown notice over screenshots of the product as people tried to figure out how it works. They also issued a takedown request based on “false and misleading statements”, which does little more than fully engage the Streisand effect. CipherCloud has since issued a kinda-sorta apology and an update that, judging from the few comments doesn’t satisfy anyone. They apologize for the takedown requests and blame their legal department, but barely address the actual issue. First of all from what I have seen they have a good product which does what they claim it does. I have been briefed and know some large organizations evaluating or using it. The problem here isn’t the product – it’s their approach. When someone posts potentially unfavorable information about you on the Internet, trying to squash it always backfires. Also, if the posts are mostly trying to cut through your marketing material to see how the product works, that means people are interested in your product and you should treat them with respect. CipherCloud’s response to the DMCA takedown criticism is to state that the conclusions coming out of StackExchange were wrong and based on an older video demo. That’s totally fine, but they fail to actually fill the information gap with accurate information. There is a little about what they don’t do, the usual platitudes about FIPS-140, and that’s about it. They say they will provide this information to customers, prospects, and partners, but want to keep their IP otherwise out of the public eye: I understand and appreciate the interest in the market to better understand our technology, and I am happy to discuss additional details around our encryption implementation with our customers, prospects and partners. If you are interested in learning more, please contact CipherCloud directly via our website at info@ciphercloud.com This isn’t how to respond. I know their competitors, and trust me, they all have a good idea of how CipherCloud works. The ones who care set up straw buyers/prospects to get their hands on demos, however unethical that is. I don’t think they need to reveal everything, but this was a great opportunity to get some additional attention, explain why they feel they are better than the competition, and generate some goodwill among those interested in the product. Instead they look like they are hiding something. 1Password nailed it with their reasoned response to a security concern, and the industry is well trained to be skeptical of security vendors – especially in encryption – who aren’t transparent about their technology. Also, when you make a mistake like letting loose the legal dogs, you need to sound truly apologetic, not defensive. Anyway, big companies can get away from this, but now CipherCloud has to deal with negative coverage as the second result on their Google search. I am not a marketing exec, but that coverage is not good, and they will have to live with it for a while. Share:

I tend to avoid “security jazz” blog posts – esoteric arguments contrasting what we should be doing in security against what we do today. These rants don’t really help IT professionals get their jobs done so I skip them. But this is going to be such a post because I need to talk about big data security approaches. Many of you will to stop reading at this point. But for you data architects, CISOs, and security product development teams learning about how to plan for big data security (particularly those of you who have been asking me lately) and wanting to understand the arcane research that influences my recommendations, read on. I got started on this topic by considering what big data security will look like in coming years. I was reacting to the apparently random recommendations in the general security press. I eventually decided that this is simply unknown. I can’t fairly slam the press for their apparently moronic recommendations, because I cannot be sure they will not be correct in the future. Stock picking monkeys have made fools of professional traders, and it is likely to happen again with big data security predictions. As big data continues its metamorphosis – in data storage, data and node management, system orchestration, and query methods – the ways we secure these clusters will change. A series of industry research papers (PDF), blog posts, and academic research projects on big data convince me that we are still very early in big data’s evolution. In each case we see some evolutionary changes (such as the Berkeley AMPLab’s Spark product), as well as some total rethinks of how to do analysis with big data (such as Google’s Pregel). I am raising this topic on here because I think merits an open discussion. I am being asked frequently how to approach big data security, and given that big data currently looks like Hadoop and Cassandra, there are specific actionable steps that make sense for these types of clusters. But for someone architecting security products, this model might well be obsolete by the time the product goes live. Based upon research findings from last year things like masking, encryption, tokenization, identity management, and API security all make sense in Hadoop. When I speak with vendors who are looking to design big-data-specific security products, I need to caveat all recommendations with “as far as we know today”. I certainly cannot say that in 5 years anyone will still be using Hadoop. I guess Hadoop will still be a big player, but who knows? It could be Dremel, a SQL-like system, in which case we will be able apply many techniques we have already evolved for relational stores. If fashion dictates a Pregel-like ant swarm of worker threads, not so much. Here is where I come to the predictions and recommendations. I would like to recommend that you embed as much security into the application layer as you can. That’s the best place to control access and control who can see what. The application is the gateway to the data, where you can abstract away many underlying data management layer complexities to focus on user rights and business logic enforcement. Application-layer controls also scale security with the application. These are reasons I think (Updated) Intel Mashery, Axway Vordel, and CA Layer7 are important. But we cannot yet tell where big data is going – we don’t know what applications, orchestration, queries, data storage, or even architectures will look like going forward – so it is impossible to know whether any security model we design will be absurd in a few years. The safe approach, based upon the uncertainty of big data environments, would be to protect at the data layer. That means using encryption, masking, and tokenization technologies that don’t expose sensitive data to big data environments. Making that work currently requires big data security clusters fronting big data analytics clusters – not terribly efficient, and you need another cluster (perhaps twice as many, depending on scale). Then I realize that IT folks, trying to get their jobs done, will ignore all this overly abstract mumbo-jumbo and fall back on what they are comfortable with: the encapsulation/walled garden model of security. Put a firewall “in front” of the cluster, sealing it off (virtually) from the rest of IT. Hard firewall shell on the outside, chewy lack of security on the inside. At this point we appreciate the Jacquith/Hoff Security Hamster Sine Wave of Pain model as a useful tool. You can show how each of these choices is right … and wrong. We will play catch-up because we have no choice in the matter. Share:

All the discussion so far in our CISO’s Guide to Advanced Attackers has been of preparation for the main event. The bell rings when an alert fires and it’s time for your incident response process to kick in. But as we have seen through our adversary analysis and intelligence gathering, “advanced attackers” present some unique challenges. In particular, they significant resources and time, which makes them difficult to deter – even if you successfully block one attack or stop a specific exfiltration, there will be more. A lot more. As usual we depend on process as the key to dealing with advanced attackers. But this class of adversaries requires you to put a premium on analyzing malware to isolate the root cause of the attack, looking for indicators to identify additional compromised devices, and then trying to piece together the bigger picture of the attack. React Faster and Better, CISO Style Let’s turn back the clock and review some of the Incident Response Fundamentals we introduced a few years ago. The process remains largely the same, but you are likely to need some of the data sources covered in React Faster and Better and some of the analysis techniques presented in the Malware Analysis Quant process maps to deal with advanced attackers’ tactics. If you weren’t worried enough about this, remember that your perceived success as CISO is directly correlated to your ability to respond effectively to incidents and keep your organization out of headlines. You don’t need a SIEM to do that correlation, by the way. During the Attack Once the alert sounds it is time to figure out whether the attack is legitimate, what it looks like, and the proper escalation path (if necessary). Here are the general steps in that effort: Gather information: For an investigator to make heads or tails of anything, your first tier needs to collect some information. Things like who triggered the alert and what systems and devices were involved. Were you notified by a third party (not a good sign)? Could you find an alert (perhaps one that was ignored) around the time period of the attack? You are trying to get a feel for whether this is an operational failure or something designed to evade your defenses. Escalate: Next you decide how far up the chain of command this needs to go. If there are critical systems involved (those on your list of things where compromise would be bad), then your spidey senses need to start tingling and you need the big guns involved. The escalation scenarios must be defined and agreed on ahead of time so your first tier responders know what to do and when. Size up: Once your second tier (or even third tier) responders are involved, the key is determining the scope of the situation. Was this a total compromise? Does extensive lateral movement indicate potential exfiltration? You need to know what you might be dealing with, and to assemble a list of the stuff you really need in order to investigate the incident. Initial Containment: Depending on your initial assessment of the situation you may need to quarantine devices, step up monitoring, or remove the device’s access to sensitive data. As with escalation, the initial set of containment actions should be documented in a playbook, with documented approval from all stakeholders, to ensure containment steps are not held up by bureaucracy. At this point you should have initial defenses in place and a feel for whether you are dealing with folks who know what they’re doing. If the attack doesn’t seem sophisticated or coordinated you can probably just wipe the machine and move on, hopefully using it as a teaching moment so the user doesn’t do something stupid again. Is it a risk to just wipe and move on? You bet! You lose any ability to seriously analyze the attack, but part of the CISO’s job is to allocate resources to the stuff that matters. Being able to tell the difference between an advanced attacker, an operational failure, and a stupid user error becomes a key determinant of success in the job, along with resource allocation. If there is a chance that you are dealing with an advanced attacker (or something else is pushing you to do a broader investigation), you will start working through a more detailed forensics process. That means quarantining the affected devices, taking forensic images, and working to determine the root cause of the attack. That requires you to dig into the malware and determine how the devices were compromised, then assess the extent of the damage. Digging for the Root (Cause) Malware analysis is a discipline all its own. We have documented the entire process in Malware Analysis Quant, but CISO types rarely fire up BackTrack or ship file up to malware sandboxes, so here is what you need to make sure the right stuff is happening to identify the root cause of a compromise. Build Testbed: It is rarely a good idea to analyze malware on production devices connected to production networks. So your first step is to build a testbed to analyze what you found. This is mostly a one-time effort but you will always be adding to the testbed, with the evolution of your attack surface. There are services that can do this as well, without the hardware investment. Static Analysis: The first actual analysis step is static analysis of the malware file to identify things like packers, compile dates, and functions used by the program. Dynamic Analysis: There are three aspects of what we call Dynamic Analysis: device analysis, network analysis, and proliferation analysis. To dig a layer deeper, first observe the impact of the malware on the specific device, dynamically analyzing the program to figure out what it actually does. Here you seek insight into memory usage, configuration, persistence, new executables, and anything else interesting associated with execution of the malware. This is managed by running the malware in a sandbox. Once you understand what the malware does to a device you can begin to figure out its communications paths. This includes command and control traffic, DNS tactics, exfiltration

A few hours after this post goes live, the Verizon Enterprise risk team will release their 2013 Data Breach Investigations Report. This is a watershed year for the report, as they are now up to 19 contributing organizations including law enforcement agencies, multiple emergency response teams (CERTs), and even potential competitors. The report covers 47,000 incidents, among which there were 621 confirmed data disclosures. This is the best data set since the start of the report, so it provides the best insight into what is going on out there. We were fortunate enough to get a preview of the report and permission to post this a few hours before the report is released. In the next 24-72 hours you will see a ton of articles; as analysts we aren’t here to make a story or nab a headline, but to help you get your job done. We offer a very brief overview of the interesting things we saw in the report, but our main focus for this post is to save you a little time in using the results to improve security in your own organization. The best part this year is that the data reflects a more balanced demographic than in the past, and the Verizon risk team did a great job of breaking things out so you can focus on the pieces that matter to you. The report does an excellent job of showing how different demographics face different security risks, from different attackers, using different attack techniques. Instead of a bunch of numbers jumbled together, you can focus on the incidents most likely to affect your organization based on your size and industry. You probably know that from the beginning, but now you have numbers to back you up. But first: If you are an information security professional, you must read this report. Don’t make decisions based on news articles, this post, or any other secondary analysis. It’s a quick read, and well worth your time, even if you only skim it. Got it? There is a ton of good analysis in the report, and no outside summaries will cover the important things you need for making your own risk decisions. Not even ours. We could easily write a longer analysis of the DBIR than the DBIR itself. Key context Before we get any deeper, Verizon made two laudable decisions when compiling the report that might cause some hand wringing among those who don’t understand why: They almost completely removed references to lost record counts such as the number of credit card numbers lost. The report is much more diverse this year, and record counts (which are never particularly useful in breach analysis) were just being misused and misunderstood. Only 15% of confirmed incidents had anything close to a measurable lost records count, so it made no sense to mention counts. The report focuses on the 621 confirmed data loss incidents, not the 47,000 total incidents. Another great decision – most organizations have different definitions of ‘incident’, which made data normalization a nightmare. This is the Data Breach Investigations Report, not an analysis of every infected desktop on your network. These two great decisions make the report much more focused and useful for making risk decisions. A third piece of context is usually lost in much of the press coverage: When the DBIR says something like “password misuse was involved in an incident”, it means it was one of multiple factors in the incident – not necessarily the root cause. Later in the report they tie in the first of the chain of attacks used, but you can’t read, “76% of network intrusions exploited weak or stolen credentials” as “76% of incidents were the result of weak or stolen credentials”. Attacks use chains of techniques, and these are only one factor. Context really is king because your goal is to break the attack chain at the most efficient and cost effective point. The last piece of context is an understanding of what happens when 19 organizations participate. Some use VERIS (the open incident recording methodology published by Verizon) and others use their own frameworks. The Verizon risk team converts between methodologies as needed, and usually excludes data if there isn’t enough to cover the core needed to merge the data sets. This means they sometimes have more or less detail on incidents, and they are clear about this in the report. There is no way to completely avoid survey bias in a sample set like this – incidents must be detected to be reported, and a third party response team or law enforcement must be engaged for Verizon to get the data. This is why, for example, lost and stolen devices are practically nonexistent in this report. You don’t call Verizon or Deloitte for a forensics investigation when a salesperson loses a laptop. Then again, we know of approximately zero cases where a lost device resulted in fraud. They definitely incur costs due to loss reporting and customer notification, but we can’t find any ties to fraud. There is one choice we disagree with, and one area we hope they will drop, but they probably have to keep: The DBIR includes many incidents of ATM skimming and other physical attacks that don’t involve network intrusion. These are less useful to the infosec audience, and we believe the banking community already has these numbers from other places. Tampering with ATMs in order to install skimmers is the vast majority of the ‘Physical’ threat action, which represents 35% of the breaches in the DBIR. Year-over-year trends are nearly worthless now, due to the variety of contributors. It is a very different sample set from last year, the year before, or previous years. Perhaps if they filtered out only Verizon incidents, they could offer more useful trends. But people love these trend charts, despite the big changes in the sample set. ATM skimming attacks are still data breaches, but the security controls to mitigate them are managed outside information security in most financial institutions. For the most part this doesn’t negatively affect the data too much, but