Login  |  Register  |  Contact
Wednesday, March 12, 2014

Incite 3/12/2014: Digging Out

By Mike Rothman

The ritual is largely the same. I do my morning stuff (usually consisting of some meditation and some exercise), I grab a quick bite, and then I consult my list of things that need to get done. It is long, and seems to be getting longer. The more I work, the more I have to do. It’s a good problem to have, but it’s still a problem.

And going to RSA two weeks ago exacerbated it. I had a lot of great conversations with lots of folks who want to license our research, have us speak at their events, and have us advise them on all sorts of things. It’s awesome, but it’s still a problem.

Just keep digging

Of course you probably think we should expand and add a bunch of folks to keep up with demand. We have thought about that. And decided against it. It takes a unique skill set to do what we do, the way we do it. The folks who understand research tend to be locked up by big research non-competes. The folks who understand how to develop business tend not to understand research. And the very few who can do both generally aren’t a cultural fit for us. Such is life…

But that’s not even the biggest obstacle. It’s that after 4+ years of working together (Rich and Adrian a bit more), we enjoy a drama-free environment. The very few times we had some measure of disagreement or conflict, it was resolved with a quick email or phone call, in a few minutes. Adding people adds drama. And I’m sure none of us wants more drama.

So we put our heads down and go to work. We build the pipeline, push the work over the finish line, and try to keep pace. We accept that sometimes we need to decide not to take a project or see how flexible the client is on delivery or scheduling. As with everything, you make choices and live with them.

And while it may sound like I’m whining about how great our business is, I’m not. I am grateful to have to make trade-offs. That I have a choice of which projects I work on, for which clients. Not that I can’t find work or deal with slow demand. The three of us all realize how fortunate we are to be in this position: lots of demand and very low overhead. That is not a problem. We want to keep it that way. Which is basically my way of saying, where is that shovel again? Time to get back to digging.


Photo credit: “Digging out auto” originally uploaded by Boston Public Library

Securosis Firestarter

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

2014 RSA Conference Guide

In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat.

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, where you can get all our content in its unabridged glory. And you can get all our research papers too.

Advanced Endpoint and Server Protection

Newly Published Papers

Incite 4 U

  1. Incentives drive organizational behavior: I am not sure why Gunnar tweeted a link to something he posted back in October, but it gave me an opportunity to revisit a totally awesome post. In Security Engineering and Incentives he goes through the key aspects of security engineering, and incentives are one of the four cornerstones (along with security policy, security mechanism, and assurance). Probably the most important of the cornerstones, because without proper incentives no one does anything. If you have ever been in sales you know the compensation plan drives behavior. It is that way in every functional part of the business. In the not-so-real world you have folks who do what they are supposed to because they do. And in the real world, those behaviors are driven by incentives, not risk (as GP points out). So when you wonder why the Ops team ignores the security policy and developers couldn’t give less of a crap about your security rules, look at what they are incented to do. Odds are be secure isn’t really on that list. – MR

  2. Persona non grata: The Mozilla Wiki does not really capture the essence of what’s going on with Mozilla’s Persona project, but the gist is that their effort to offer third party identity federation has failed. There is some debate about whether technical or financial derailed the project and prevented it from reaching “critical mass”, but I think the statement “We looked at Facebook Connect as our main competitor, but we can’t offer the same incentives (access to user data)” pretty much nails it. If you wonder why Yahoo is ditching Facebook and Google federation services in lieu of their own offering, understand that identity is the next generation’s “owning the user”, and a key means for data providers (advertising networks) to differentiate their value to advertisers. The goal of federated identity was to offer easier and better identity management across web applications, doing away with user names and passwords. But identity providers have seen the greatest benefit, through enrichment of the data they collect. – AL

  3. Ranum and Turner on whitelisting: Searchsecurity posted a great discussion between Marcus Ranum and Aaron Turner on whitelisting. I have been a huge fan of the technology for years as well, and have been doing a bunch of research on what is now called application control. I will link to our completed AppControl white paper later this week. Aaron provides a bunch of real-world perspective on the challenges, which echo the way I described the Double-Edged Sword. Marcus keeps coming back to the reality that iOS and now OS X can be governed by whitelisting, which is basically the App Store model. So is it just fear that is still preventing folks from embracing this security model? Maybe, but I don’t know that fight is still worth fighting. For those use cases where AppControl is a no-brainer, just do that. For those where you have to think about it or face an onerous application management situation, look at something like advanced heuristics which can do a decent job of protecting a subset of the most targeted applications, as I described in the Prevention post in our Advanced Endpoint and Server Protection series. – MR

  4. You don’t need to see his identification: I like being able to look at the code changes on Github and similar sites – you get to see fixes for serious security bugs like the TLS security bug reported last week. If I read this correctly it was a simple uninitialized return variable. But what bothers me is how this could have gone undetected – the first thing you do when testing SSL/TLS is send bad or odd certificates to see if the user still connects. And uninitialized return variables should pop up in static analysis as well. Much in the same way the goto bug in OS X makes a security paranoid’s hair stand on end, it is hard to imagine how this bug – bypassing one of the three crucial checks – was not caught during normal testing or manual code scans. It also reminds me to put logging code into exception handlers, because executing a routine called ‘fail’ should not be confused with successful operation. – AL

  5. Turning the tables on the adversary: Dave Meltzer has a good line of discussion on TripWire’s blog about increasing the cost to attackers of compromising your devices. His point is that you should make it fiscally irresponsible to exploit you. Great idea, but how? One suggestion is to decentralize your most valuable assets. That makes sense but also increases your cost to manage that data. So you need to trade off increasing the cost to adversaries against screwing up your own financial models. Another suggestion is to force the adversary to burn a very valuable (expensive) 0-day attack. That requires making sure you can defend yourself against widely available tools like Metasploit and the zillion attack kits available on the gray market. It comes back to Corman’s magical HDMoore’s Law. If you can’t defend against Metasploit, you have very little chance to cost an adversary much of anything. So get working on that, okay? – MR

–Mike Rothman

Tuesday, March 11, 2014

Firestarter: RSA Postmortem

By Rich

We are all rested and recovered from RSA (yeah, right) and it’s time to review the week and what we think. Did we mention security is back, baby?! That’s right – it is clear budgets are now free, and the stink of desperation is fading.

Here’s the video:

And the audio-only version is up – we should be available for subscription in iTunes next week.

Thanks, and see you next week…


Monday, March 10, 2014

Advanced Endpoint and Server Protection: Quick Wins

By Mike Rothman

We have covered the main aspects of the threat management cycle, in terms of the endpoint and server contexts, in our last few posts. Now let’s apply these concepts to a scenario to see how it plays out. In this scenario you work for a high-tech company which provides classified technology to a number of governments, and has a lot of valuable intellectual property. You know you are targeted by state-sponsored adversaries for the classified information and intellectual property on your networks. So you have plenty of senior management support and significant resources to invest in dealing with advanced threats.

You bought into reimagined threat management, and have deployed a combination of controls on your endpoints and servers. These include advanced heuristics on valuable endpoints, application control on servers with access to key intellectual property stores, and broad deployment of device activity monitoring technology – all because you know it is a matter of when rather than if you will be compromised. You supplement endpoint and server protections with network-based malware detection and full packet capture.

So resources are not an issue and you have controls in place to deal with advanced adversaries. Of course that and $4 will get you a coffee, so you need to build these controls into a strong process to ensure you can react faster and better to the attacks you know are coming. But not every organization can make such extensive investments, so you may not have the full complement of controls at your disposal.

The Attack: Take 1

This attack starts as many do, with an adversary sending a phishing email with a malicious MS Office attachment to an employee in the finance department. The employee’s device has an agent that uses advanced heuristics, which identifies the malicious behavior when the file attempts to turn off the traditional AV product and install what looks like a dropper on the device. The agent runs at the kernel level so it manages to block the attack and administrators alerted, and no harm is done… this time.

These are the kinds of quick wins you are looking for, and even with proper security awareness training, employees are still very likely to be duped by advanced attackers. So additional layers of defense, beyond the traditional endpoint protection suite, are critical.

The Attack: Take 2

The advanced adversary is not going to give up after their blocked initial foray. This time they target the administrative assistant of the CEO. They pull out a big gun, and use a true 0-day to exploit an unknown flaw in the operating system to compromise the device. They deliver the exploit via another phishing email and get the admin to click on the link to a dedicated server never used for anything else. A drive-by download exploits the OS using the 0-day, and from there they escalate privileges on the admin’s device, steal credentials (including the CEO’s logins) and begin reconnaissance within the organization to find the data they were tasked to steal.

As the adversary is moving laterally throughout the organization they compromise additional devices and get closer to their goal, a CAD system with schematics and reports on classified technology. As mentioned above, your organization deployed network-based malware detection to look for callbacks, and since a number of devices have used similar patterns of DNS searches (which seem to be driven by a domain-generating algorithm), alarms go off regarding a possible compromise.

While you are undertaking the initial validation and triage of this potential attack, the adversaries have found the CAD system and are attempting to penetrate the server and steal the data. But the server has application controls, and will not run any unauthorized executables. So the attack is blocked and the security team is alerted to a bunch of unauthorized activity on that server. This is another quick win – attackers found their target but can’t get the data they want directly.

Between the endpoint compromise calling back to the botnet, and attempts on the server, you have definitive proof of an adversary in your midst. At this point the incident response process kicks in.

Respond and Contain

As we described in our incident response fundamentals series, you start the response process after confirming the attack by escalating the incident based on what’s at risk and the likelihood of data loss. Then you size up the incident by determining the scope of the attack, the attacker’s tactics, and who the attacker is, to get a feel for intent. With that information you can decide what kind of response you need to undertake, and its urgency.

Your next step is to contain the attack and make sure you have the potential damage under control. This can take a variety of forms, but normally it involves quarantining the affected device (endpoint or server) and starting the forensics investigation. But in this scenario – working with senior management, general counsel, and external forensic investigators – the decision has been made to leave the compromised devices on the network. You might do this for a couple reasons:

  1. You don’t want to tip off the adversary that you know they are there. If they know they have been detected they may burrow in deeper, hiding in nooks and crannies and making it much harder to really get rid of them.
  2. Given an advanced attacker is targeting your environment, you can gather a bunch of intelligence about their tactics and techniques by watching them in action. Obviously you start by making sure the affected devices can’t get to sensitive information, but this gives you an opportunity to get to know the adversary.

A key part of this watching and waiting approach is continuing to collect detailed telemetry from the devices, and starting to capture full network traffic to and from affected devices. This provides a full picture of exactly what the adversary is doing (if anything) on the devices.


The good news is that the investigation team has access to extensive telemetry from device activity monitoring and network packet capture. Analyzing the first compromised device (the administrator’s system) shows the kind of malware used, and then the organization can more definitively identify the adversary by working with a threat intelligence service. Knowing the adversary gives your team a good idea of what is targeted and that specific adversary’s typical tactics. This will be critical post-recovery. If you are counting quick wins you can put another point on the board – comprehensive data makes it much easier for investigators to identify root cause and ultimately plan remediation and clean-up.

Given the adversary’s sophistication, the incident response team does a similar analysis on all the other devices performing callbacks to the botnet, to understand the attack timeline. Knowing what was attacked when helps you track proliferation and understand where controls failed. This is also critical during the post-mortem analysis.

This analysis shows similar malware to the initial attack on the CEO’s admin. Not wanting to take any chances, the team searches the entire organization for similar indicators – scrutinizing device activity monitoring data, SIEM and event logs, and the configuration management system. You will also want to consult network-based malware detection devices and the threat intelligence service to make sure you are looking at any additional touch points to track the attackers. This analysis helps the team find another 4 compromised devices currently dormant to maintain presence in the organization, even after initial discovery. This is another quick win – if you hadn’t identified the additional devices, you would have failed to fully eject the adversary.

At this point the investigation team puts together its plan to remediate the environment. They decide to take a big bang approach and reimage all the affected devices. They don’t want to take a chance that the adversary found alternative paths into your network to maintain presence. So within a 15-minute period, while all the infected devices are pulled off the network and reimaged, the network team also blocks IPs associated with the adversary and increases their monitoring for command and control patterns.


At this point, the security team tends to hand off information to Operations to execute the cleanup. The most valuable thing you can provide is highly detailed plans and techniques to ensure the adversary is fully removed from your environment. Some operations teams may be a bit resistant to being handed a detailed remediation plan, but if you have done a good job of building bridges with your peers within the organization they will understand that you know more about the adversary than they do, and your plans reflect that deep knowledge.


Once the operations team has executed the big bang remediation and fully removed the attackers, your work is still not done. You need to learn from the situation, tuning your processes and controls to respond more effectively next time. Thanks to quick response and implementation of effective controls, you didn’t lose data. That’s huge, but the adversary will be back, so you need to be ready.

So you undertake a non-judgmental post-mortem to evaluate the investigation, and to determine what went wrong. This evaluation includes active controls and the monitoring environment. What can you do differently now that you know the adversary? Do you need to change your threat management processes or control sets? Now is the time to make those decisions.

Also be sure to look at your response process. What could be done better? What additional tools or automated triggers should come into play? Be brutally honest with your team about what needs to change, and then put a plan in place to implement necessary process changes, new processes, and additional controls.


When dealing with advanced attacks it is critical to appreciate the value of time. So having the data is critical. Once the data is lost you cannot get it back, and you cannot use it to investigate any attacks. Time is money to every organization – the sooner you can identify root cause, investigate the attack, contain the damage, eradicate the adversary from your environment, and then implement controls to keep them out – the better.

You can achieve this goal by implementing a broader threat management process and making a commitment – not just to new and shiny preventative technologies, but also to bolstering your ability to detect and investigate attacks. Yet you still need to deal with the reality of compliance mandates for traditional endpoint protection technologies – even though they won’t help against advanced attackers. You have to balance your need to maintain existing controls against deploying new technologies much better suited to today’s adversaries.

–Mike Rothman

Sunday, March 09, 2014

New Paper: Leveraging Threat Intelligence in Security Monitoring

By Mike Rothman

As we continue our research into the practical uses of threat intelligence (TI), we have documented how TI should change existing security monitoring (SM) processes. In our Leveraging Threat Intelligence in Security Monitoring paper, we go into depth on how to update your security monitoring process to integrate malware analysis and threat intelligence. Updating our process maps demonstrates that we don’t consider TI a flash in the pan – it is a key aspect of detecting advanced adversaries as we move forward.

Here is our updated process map for TI+SM.:

TISM Process Map

As much as you probably dislike thinking about other organizations being compromised, this provides a learning opportunity. An excerpt from the paper explains in more detail:

There are many different types of threat intelligence feeds and many ways to apply the technology – both to increase the effectiveness of alerting and to implement preemptive workarounds based on likely attacks observed on other networks. That’s why we say threat intelligence enables you to benefit from the misfortune of others. By understanding attack patterns and other nuggets of information gleaned from attacks on other organizations, you can be better prepared when they come for you.

And they will be coming for you – let’s be clear about that. So check out the paper and figure out how your processes need to evolve, both to keep pace with your adversaries, and to take advantage of all the resources now available to keep your defenses current.

We would like to thank Norse Corporation for licensing this paper. Without support from our clients, you wouldn’t be able to use our research without paying for it.

You can check out the permanent landing page for the paper, or download it directly (PDF).

–Mike Rothman

Friday, March 07, 2014

Advanced Endpoint and Server Protection: Detection/Investigation

By Mike Rothman

Our last AESP post covered a number of approaches to preventing attacks on endpoints and servers. Of course prevention remains the shiny object most practitioners hope to achieve. If they can stop the attack before the device is compromised there need be no clean-up. We continue to remind everyone that hope is not a strategy, and counting on blocking every attack before it reaches your devices always ends badly.

As we detailed in the introduction, you need to plan for compromise because it will happen. Adversaries have gotten much better, attack surface has increased dramatically, and you aren’t going to prevent every attack. So pwnage will happen, and what you do next is critical, both to protecting the critical information in your environment and to your success as a security professional.

So let’s reiterate one of our core security philosophies: Once the device is compromised, you need to shorten the window between compromise and when you know the device has been owned. Simple to say but very hard to do. The way to get there is to change your focus from prevention to a more inclusive process, including detection and investigation…


Our introduction described detection:

You cannot prevent every attack, so you need a way to detect attacks after they get through your defenses. There are a number of different options for detection – most based on watching for patterns that indicate a compromised device. The key is to shorten the time between when the device is compromised and when you discover it has been compromised.

To be fair, there is a gray area between detection and prevention, at least from an endpoint and server standpoint. With the exception of application control, the prevention techniques described in the last post depend on actually detecting the bad activity first. If you are looking at controls using advanced heuristics, you detect the malicious behavior first – then you block it. In an isolation context you run executables in the walled garden, but you don’t really do anything until you detect bad activity – then you kill the virtual machine or process under attack.

But there is more to detection than just figuring out what to block. Detection in the broader sense needs to include finding attacks you missed during execution because:

  1. You didn’t know it was malware at the time, which happens frequently – especially given how quickly attackers innovate. Advanced attackers have stockpiles of unknown exploits (0-days) they use as needed. So your prevention technology could be working as designed, but still not recognize the attack. There is no shame in that.
  2. Alternatively, the prevention technology may have missed the attack. This is common as well because advanced adversaries specialize in evading known preventative controls.

So how can you detect after compromise? Monitor other data sources for indicators that a device has been compromised. This series is focused on protecting endpoints and servers, but looking at devices is insufficient. You also need to monitor the network for a full perspective on what’s really happening, using a couple techniques:

  1. Network-based malware detection: One of the most reliable ways to identify compromised devices is to watch for communications with known botnets. You can look for specific traffic patterns, or for communications to known botnet IP addresses. We covered these concepts in both the NBMD 2.0 and TI+SM series.
  2. Egress/Content Filtering: You can also look for content that should not be leaving the confines of your network. This may involve a broad DLP deployment – or possibly looking for sensitive content on your web filters, email security gateways, and next generation firewalls.

Keep in mind that every endpoint and server device has a network stack of some sort. Thus a subset of this monitoring can be performed within the device, by looking at traffic that enters and leaves the stack.

As mentioned above, threat intelligence (TI) is making detection much more effective, facilitated by information sharing between vendors and organizations. With TI you can become aware of new attacks, emerging botnets, websites serving malware, and a variety of other things you haven’t seen yet and therefore don’t know are bad. Basically you leverage TI to look for attacks even after they enter your network and possibly compromise your devices. We call this retrospective searching. This works by either a) using file trajectory – tracking all file activity on all devices, looking for malware files/droppers as they appear and move through your network; or b) looking for attack indicators on devices with detailed activity searching on endpoints – assuming you collect sufficient endpoint data.

Even though it may seem like it, you aren’t really getting ahead of the threat. Instead you are looking for likely attacks – the reuse of tactics and malware against different organizations gives you a good chance to see malware which has hit others before long.

Once you identify a suspicious device you need to verify whether the device is really compromised. This verification involves scrutinizing what the endpoint has done recently for indicators of compromise or other such activity that would confirm a successful attack. We’ll describe how to capture that information later in this post.


Once you validate the endpoint has been compromised, you go into incident response/containment mode. We described the investigation process in the introduction as:

Once you detect an attack you need to verify the compromise and understand what it actually did. This typically involves a formal investigation, including a structured process to gather forensic data from devices, triage to determine the root cause of the attack, and searching to determine how broadly the attack has spread within your environment.

As we described in React Faster and Better, there are a number of steps in a formal investigation. We won’t rehash them here, but to investigate a compromised endpoint and/or server you need to capture a bunch of forensic information from the device, including:

  1. Memory contents
  2. Process lists
  3. Disk images (to capture the state of the file system)
  4. Registry values
  5. Executables (to support malware analysis and reverse engineering)
  6. Network activity logs

As part of the investigation you also need to understand the attack timeline. This enables you to identify the first compromised device (Patient Zero), as well as all affected devices, so you can effectively contain the damage when you reach the remediation phase. This timeline shows you how the malware got into your network in the first place, and how it proliferated to infect other devices.

This highlights one of the biggest problems in handling modern malware – getting rid of it completely. Even if you wipe an infected device to bare metal and reimage, unless you successfully identifying all other infected devices in your environment, and clean them all successfully, the malware will cause additional trouble. So as part of investigations you need to isolate all devices affected by the attack and clean them once and for all.

You can’t just rely on behavioral indicators (the device behaving badly) to identify additional affected devices, because the malware may be lying dormant and awaiting instructions from the bot master. You need to analyze detailed telemetry from endpoints and servers to determine whether these indicators are present – which brings us to the proverbial glue that enables both detection and investigation of attacks on endpoints and servers.

Capture Two Birds (with One Agent)

As we explained in our 2014 Endpoint Security Buyer’s Guide, to really investigate a device, you need to capture what’s happening on the endpoints and servers at a very granular level. This includes file activity, registry changes, privilege escalation, executed programs, network activity, and a variety of other activities happening on endpoints. We call this function Device Activity Monitoring, and it is also called ETDR (Enterprise Threat Detection and Response).

The key functions in device activity monitoring start with data capture. To get the data needed for a comprehensive investigation you need to capture data continuously. Of course that might not be practical on all devices, in which case you will use a trigger to start full collection. For example if a user clicks a link in an email that takes the browser to a suspicious site, you would start pulling detailed data from the endpoint, because a compromise is likely imminent.

Another capture decision is where to store the data. There is a battle brewing between products that capture this device telemetry data and store it on customer premises, and those which store data in the cloud. There are pros and cons to both approaches. On one side you will hear a lot about the security implications of moving such sensitive data to the cloud – and those are legitimate concerns. On the other hand, the need for large-scale analysis of aggregated and anonymized data, to identify emerging patterns across organizations, favors a cloud-based model. Mr. Market will determine the right approach soon enough, but where to store your telemetry data is definitely a deployment decision you need to make when selecting an approach.

Next, the activity monitoring technology should have adequate hooks for threat intelligence (TI) integration. The vendor’s research team can and should populate agents with emerging attack indicators, IP and file reputation, etc., to provide a basis for detecting advanced attacks. But one research feed is not enough so you will want a product flexible enough to ingest other feeds – likely through industry standard TI formats such as STIX, TAXII, OpenIOC, OTX, et al.

Finally, endpoints and servers generate a huge amount of data, so it’s also necessary for the product to perform big data style analysis on the telemetry dataset, to identify patterns and develop relationships between data sources. Having the data is the first step. Supplementing it with external information to help prioritize focus areas is second. Being able to analyze the data to provide useful information to security practitioners and incident responders is the third leg of the device activity monitoring triangle.

What now?

If you missed on prevention, you need to detect bad behavior by infected endpoints and servers, and then verify and investigate the attack. But that doesn’t entirely solve the problem – you still have active malware on the devices. Now it’s time to remediate.

Remediation tends to fall within the purview of Operations, but security teams can get a quick win by providing very detailed data and recommendations for remediation to Ops, to help focus their efforts and aid them in fully cleaning up the attack. We will discuss that Quick Win as we wrap up this series, in our next and final post.

–Mike Rothman

Thursday, March 06, 2014

Friday Summary: March 7, 2014

By Adrian Lane

I don’t code much. In fact over the last 10 years or so I have been actively discouraged from coding, with at least one employer threatening to fire me if I was discovered. I have helped firms architect new products, I have done code reviews, I have done some threat modeling, and even a few small Java utilities to weave together a couple other apps. But there has been very, very little development in the last decade. Now I have a small project I want to do so I jumped in with both feet, and it feels like I was dumped into the deep end of the pool. I forgot how much bigger a problem space application development is, compared to simple coding.

In the last couple of days I have learned the basics of Ruby, Node.js, Chef, and even Cucumber. I have figured out how to bounce between environments with RVM. I brushed up on some Python and Java. And honestly, it’s not very difficult. Learning languages and tools are trivial matters. A few hours with a good book or web site, some dev tools, and you’re running. But when you are going to create something more than a utility, everything changes. The real difficulty is all the different layers of questions about the big picture: architecture, deployment, UI, and development methodologies. How do you want to orchestrate activities and functions? How do you want to architect the system? How do you allow for customization? Do I want to do a quick prototype with the intention of rewriting once I have the basic proof of concept, or do I want to stub out the system and then use a test-driven approach? State management? Security? Portability? The list goes on.

I had forgotten a lot of these tasks, and those brain cells have not been exercised in a long time. I forgot how much prep work you need to do before you write a line of code. I forgot how easy it is to get sucked into the programming vortex, and totally lose track of time. I forgot the stacks of coffee-stained notes and hundreds of browser tabs with all the references I am reviewing. I forgot the need to keep libraries of error handling, input validation, and various other methods so I don’t need to recode them over and over. I forgot how much I eat when developing – when my brain is working at capacity I consume twice as much food. And twice as much caffeine. I forgot the awkwardness of an “Aha!” moment when you figure out how to do something, a millisecond before your wife realizes you haven’t heard a word she said for the last ten minutes. It’s all that. And it’s good.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

Blog Comment of the Week

This week’s best comment goes to Marco Tietz, in response to Research Revisited: FireStarter: Agile Development and Security, and you’ll have to watch the video to get it.

@Adrian: good video on Agile vs Security. But why did you have the Flying Spaghetti Monster in there and didn’t even give it credit! :) rAmen

–Adrian Lane

Wednesday, March 05, 2014

Incite 3/5/2014: Reentry

By Mike Rothman

After I got off the plane Friday night, picked my bag up off the carousel, took the train up to the northern Atlanta suburbs, got picked up by the Boss, said hello to the kids, and then finally took a breath – my first thought was that RSA isn’t real. But it is quite real, just not sustainable. That makes reentry into my day to day existence a challenge for a few days.

Bring me homeIt’s not that I was upset to be home. It’s not that I didn’t want to see my family and learn about what they have been up to. My 5 minute calls two or three times a day, while running between meetings, didn’t give me much information. So I wanted to hear all about things. But first I needed some quiet. I needed to decompress – if I rose to the surface too quickly I would have gotten the bends.

For me the RSA Conference is a nonstop whirlwind of activity. From breakfast to the wee hours closing down the bar at the W or the Thirsty Bear, I am going at all times. I’m socializing. I’m doing business. I’m connecting with old friends and making new ones. What I’m not doing is thinking. Or recharging. Or anything besides looking at my calendar to figure out the next place I need to be. For an introvert, it’s hard. The RSA Conference is not the place to be introverted – not if you work for yourself and need to keep it that way.

I mean where else is it normal that dinner is a protein bar and shot of 5-hour energy, topped off with countless pints of Guinness? Last week that was not the exception, it was the norm. I was thankful we were able to afford a much better spread at the Security Blogger’s Meetup (due to the generosity of our sponsors), so I had a decent meal at least one night.

As I mentioned last week, I am not about to complain about the craziness, and I’m thankful the Boss understands my need to wind down on reentry. I make it a point to not travel the week after RSA, both to recharge, get my quiet time, and reconnect with the family.

The conference was great. Security is booming and I am not about to take that for granted. There are many new companies, a ton of investment coming into the sector, really cool innovative stuff hitting the market, and a general awareness that the status quo is no good. Folks are confused and that’s good for our business. The leading edge of practitioners are rethinking security and have been very receptive to research we have been doing to flesh out what that means in a clear, pragmatic fashion.

This is a great time to be in security. I don’t know how long it will last, but the macro trends seem to be moving in our direction. So I’ll file another RSA Conference into the memory banks and be grateful for the close friends I got to see, the fantastic clients who want to keep working with us, and the new companies I look forward to working with over the next year (even if you don’t know you’ll be working with us yet).

Even better, next year’s RSA Conference has been moved back to April 2015. So that gives me another two months for my liver to recover and my brain cells to regenerate.


PS: This year we once again owe huge thanks to MSLGROUP and Kulesa Faul, who made our annual Disaster Recovery Breakfast possible. We had over 300 people there and it was really great. Until we got the bill, that is…

Photo credit: “Reentry” originally uploaded by Evan Leeson

Securosis Firestarter

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

2014 RSA Conference Guide

In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat.

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, where you can get all our content in its unabridged glory. And you can get all our research papers too.

Leveraging Threat Intelligence In Security Monitoring

Advanced Endpoint and Server Protection

Newly Published Papers

Incite 4 U

  1. TI is whatever you want it to mean: Interesting experiment from FireEye/Mandiant’s David Bianco, who went around the RSA show floor and asked vendors what threat intelligence (TI) meant to vendors who used the term prominently in their booths. Most folks just use the buzzword, and mean some of the less sophisticated data sources. I definitely understand David’s perspective, but he is applying the wrong filter. It’s like of like having a Ph.D. candidate go into a third grade classroom and wonder why the students don’t understand differential equations. Security is a big problem, and the kinds of things David is comfortable with at the top of his Pyramid of Pain would be lost on 98% of the world. If even 40% of the broad market would use IP blacklists more effectively, that would have a huge impact on security posture. The TTPs he discusses are so far beyond the capabilities of most companies that he is talking a different language. But that’s okay. As the TI market matures we will see better and more sophisticated use of information to improve defenses. Until then TI will largely be a marketing bandwagon everyone needs to jump on. – MR

  2. Pandering from within: Rod Trent’s statement that use of cloud computing means corporate data that resides outside of control of IT puts the entire business at risk is an irresponsible assertion and a disservice to IT professionals. You don’t lose control of data by moving it to the cloud. How you deploy security in the cloud differs from what you need to do within your own data centers, and which capabilities are offered varies from vendor to vendor, but cloud services are no more or less inherently secure than your own hardware. As Chris Hoff said in his RSA presentation this year, “Security is more a function of your operational model than cloud vs. on-prem deployments; if your on-prem security sucks today, it’s likely your cloud security deployment will also suck.” Go figure. Cloud services imply engagement with a third party, so you will by definition need some level of trust in the provider, but you get to choose a provider and service delivery model you are comfortable with. Sweeping generalizations like “I’m not sold on the statement that the Cloud is ‘secure enough to use’” are simply ignorant assertions to prop up the author’s thinly veiled security appliance agenda. – AL

  3. People? Process? Bah! Bejtlich gets pretty fired up as he pulls apart Dave Aitel’s post on the pros and cons of certain defensive technologies. Richard’s point is that “Network defense is more than tools and tactics. It’s more often about people and processes.” Amen to that, but we do need to use the tools out there because no human (or team of humans) can scale to the extent of the problem any more. So you need to be very clear about the capabilities – and more importantly limitations – of the tools you will use to defend yourself. Richard’s real point is the need for a programmatic approach to security. Even people and processes must be brought to bear in the same manner as tools and technologies: as part of an integrated security program. – MR

  4. When bad security is not an option: This week we saw about 12.3% of the BTC on Poloniex was stolen, which is shortly after Mt. Gox was shuttered indefinitely. It’s early days for Bitcoin, and this instability has little to do with the viability of Bitcoin as a currency – more sloppy execution by exchanges and services, and failure to protect their systems. These are new companies with shiny new applications, and they will continue to lose bitcoins until they shake out bugs and learn lessons that banks and traditional financial houses have learned over centuries. In the case of Poloniex, it was an attack on application business logic. Hopefully most of these exchanges will take note and hire professionals to come in for threat modeling and penetration testing, to find flaws before attackers. It’s not like they don’t have genuine financial incentive to be secure. If not money will continue to disappear. – AL

  5. Where the humans at? I have never been a fan of highly probabilistic models of risk or vulnerability. They typically involve assumptions on top of assumptions, and that usually leads to faulty decision making. My quant friends argue constantly that I’m being obtuse, and analysis in the right context can assist in decision making. They are probably right. Russell Thomas has been putting forth models for a while to help provide this context. Lately he has gotten into a little discussion (and yes, I’m being kind) about the role of probability in making security decisions. The reality is that at some point someone has to make a decisions about what to do. You want to feel good about that decision. That could involve prayer, it could involve a hard-core model, or it could involve experience – or more likely all of the above. If you can believe the math, I have no issue with models. Given the amount of data we are all dealing with, you need some way to reduce it and make sense of it, and that will involve probabilities in some way, shape, or form. But security is not high-velocity trading. The models have limitations, and I am not about to trade a 20-year security analyst for a risk model any time soon. And I don’t think Russell is either. – MR

–Mike Rothman

Friday, February 28, 2014

Research Revisited: FireStarter: Agile Development and Security

By Adrian Lane

I have had many conversations over the last few months with firms about to take their first plunge into Agile development methodologies. Each time they ask how to map secure software development processes into an Agile framework. So I picked this Firestarter for today’s retrospective on Agile Development and Security (see the original post with comments).

I am a big fan of the Agile project development methodology, especially Agile with Scrum. I love the granularity and focus it requires. I love that at any given point in time you are working on the most important feature or function. I love the derivative value of communication and subtle peer pressure that Scrum meetings produce. I love that if mistakes are made, you do not go far in the wrong direction – resulting in higher productivity and few total disasters. I think Agile is the biggest advancement in code development in the last decade because it addresses issues of complexity, scalability, focus, and bureaucratic overhead.

But it comes with one huge caveat: Agile hurts secure code development. There, I said it. Someone had to. The Agile process, and even the scrum leadership model, hamstrings development in terms of building secure products. Security is not a freakin’ task card. Logic flaws are not well-documented and discreet tasks to be assigned. Project managers (and unfortunately most ScrumMasters) learned security by skimming a “For Dummies” book at Barnes & Noble while waiting for lattes, but they are the folks making the choices as to what security should make it into iterations. Just like general IT security, we end up wrapping the Agile process in a security blanket or bolting on security after the code is complete, because the process itself is not suited to secure development.

I know several of you will be saying “Prove it! Show us a study or research evidence that supports your theory.” I can’t. I don’t have meaningful statistical data to back up my claim. But that does not mean it isn’t true, and there is ample anecdotal evidence to support what I am saying. For example:

  • The average Sprint duration of two weeks is simply too short for meaningful security testing. Fuzzing & black box testing are infeasible in the context of nightly builds or pre-release sanity checks.
  • Trust assumptions, between code modules or system functions where multiple modules process requests, cannot be fully exercised and tested within the Agile timeline. White box testing can be effective, but security assessments simply don’t fit into neat 4-8 hour windows.
  • In the same way Agile products deviate from design and architecture specifications, they deviate from systemic analysis of trust and code dependencies. It is a classic forest for the trees problem: efficiency and focus gained by skipping over big picture details necessarily come at the expense of understanding how the system and data are used as a whole.
  • Agile is great for dividing and conquering what you know, but not so great for dealing with the abstract. Secure code development is not like fixing bugs where you have a stack trace to follow. Secure code development is more about coding principles that lead to better security. In the same way Agile cannot help enforce code ‘style’, it doesn’t help with secure coding guidelines. (Secure) style verification is an advantage of peer programming and inherent to code review, but not intrinsic to Agile.
  • The person on the Scrum team with the least knowledge of security, the Product Manager, prioritizes what gets done. Project managers generally do not track security testing, and they are not incented to get security right. They are incented to get the software over the finish line. If they track bugs on the product backlog, they probably have a task card buried somewhere but do not understand the threats. Security personnel are chickens in the project, and do not gate code acceptance the way they traditionally were able in waterfall testing; they may also have limited exposure to developers.
  • The fact that major software development organizations are modifying or wrapping Agile with other frameworks to compensate provide security is evidence of the difficulties in applying security practices directly.

The forms of testing that fit Agile development are more likely to get done. If they don’t fit they are typically skipped (especially at crunch time), or they need to be scheduled outside the development cycle. It’s not just that the granular focus on tasks makes it harder to verify security at the code and system levels. It’s not just that features are the focus, or that the wrong person is making security decisions. It’s not just that the quick turnaround in code production precludes effective forms of testing for security. It’s not just that it’s hard to bucket security into discreet tasks. It is all that and more.

We are not about to see a study comparing Waterfall with Agile for security benefits. Putting together similar development teams to create similar products under two development methodologies to prove this point is infeasible. I have run Agile and Waterfall projects of similar natures in parallel, and while Agile had overwhelming advantages in a number of areas, security was not one of them. If you are moving to Agile, great – but you will need to evolve your Agile process to accommodate security.

What do you think? How have you successfully integrated secure coding practices with Agile?

–Adrian Lane

Thursday, February 27, 2014

Research Revisited: POPE analysis on the new Securosis

By Mike Rothman

Since we’re getting all nostalgic and stuff, I figured I’d dust off the rationale I posted the day we announced that I was joining Securosis. That was over 4 years ago and it has been a great ride. Rich and Adrian haven’t seen fit to fire me for cause yet, and I think we’ve done some great work.

Of course the plans you make typically aren’t worth the paper they’re written on. We have struggled to launch that mid-market research offering. And we certainly couldn’t have expected the growth we have seen with our published research (using our unique Totally Transparent Research process) or our retainer business. So on balance it’s still all good.

By the way, I still don’t care about an exit, as I mentioned in the piece below. I am having way too much fun doing what I love. How many folks really get to say that? So we will continue to take it one day at a time, and one research project at a time. We will try new stuff because we’re tinkerers. We will get some things wrong, and then we’ll adapt. And we’ll drink some beer. Mostly because we can…

The Pope Visits Security Incite + Securosis

(Originally published on the Security Incite blog – Jan 4, 2010.)

When I joined eIQ, I did a “POPE” analysis on the opportunity, to provide a detailed perspective on why I made the move. The structure of that analysis was pretty well received, so as I make another huge move, I may as well dust off the POPE and use that metaphor to explain why I’m merging Security Incite with Securosis.


Analyzing every “job” starts with the people. I liked the freedom of working solo, but ultimately I knew that model was inherently limiting. So thinking about the kind of folks I’d want to work with, a couple of attributes bubbled to the top. First, they need to be smart. Smart enough to know when I’m full of crap. They also need to be credible. Meaning I respect their positions and their ability to defend them, so when they tell me I’m full of crap – I’m likely to believe them. Any productive research environment must be built on mutual respect.

Most importantly, they need to stay on an even keel. Being a pretty excitable type (really!), when around other excitable types the worst part of my personality surfaces. Yet, when I’m around guys that go with the flow, I’m able to regulate my emotions more effectively. As I’ve been working long and hard on personal development, I didn’t want to set myself back by working with the wrong folks.

For those of you that know Rich and Adrian, you know they are smart and credible. They build things and they break them. They’ve both forgotten more about security than most folks have ever known. Both have been around the block, screwed up a bunch of stuff and lived to tell the story.

And best of all, they are great guys. Guys you can sit around and drink beer with. Guys you looking forward to rolling your sleeves up with and getting some stuff done. Exactly the kind of guys I wanted to work with.


Securosis will be rolling out a set of information products targeted at accelerating the success of mid-market security and IT professionals. Let’s just say the security guy/gal in a mid-market company may be the worst job in IT. They have many of the same problems as larger enterprises, but no resources or budget. Yeah, this presents a huge opportunity.

We also plan to give a lot back to the community. Securosis publishes all its primary research for free on the blog. We’ll continue to do that. So we have an opportunity to make a difference in the industry as well.

To be clear, the objective isn’t to displace Gartner or Forrester. We aren’t going to build a huge sales force. We will focus on adding value and helping to make our clients better at their jobs. If we can do that, everything else works itself out.


To date, no one has really successfully introduced a syndicated research product targeted to the mid-market, certainly not in security. That fact would scare some folks, but for me it’s a huge challenge. I know hundreds of thousands of companies struggle on a daily basis and need our help. So I’m excited to start figuring out how to get the products to them.

In terms of research capabilities, all you have to do is check out the Securosis Research Library to see the unbelievable productivity of Rich and Adrian. The library holds a tremendous amount of content and it’s top notch. As with every business trying something new, we’ll run into our share of difficulties – but generating useful content won’t be one of them.


Honestly, I don’t care about an exit. I’ve proven I can provide a very nice lifestyle for my family as an independent. That’s liberating, especially in this kind of economic environment. That doesn’t mean I question the size of the opportunity. Clearly we have a great opportunity to knock the cover off the ball and build a substantial company. But I’m not worried about that. I want to have fun, work with great guys and help our clients do their jobs better. If we do this correctly, there are no lack of research and media companies that will come knocking.

Final thoughts

On the first working day of a new decade, I’m putting the experiences (and road rash) gained over last 10 years to use. Whether starting a business, screwing up all sorts of things, embracing my skills as an analyst or understanding the importance of balance in my life, this is the next logical step for me.

Looking back, the past 10 years have been very humbling. It started with me losing a fortune during the Internet bubble. selling the company I founded for the cash on our balance sheet because we couldn’t find enough customers. Trying to start two other companies – to no avail. Then getting fired (or laid off) three times. Quite a decade, eh?

Yet, I persevere. I lived through that and had lots of successes as well. Each of those experiences helped me get to this place and become ready to do this. And I’m ready. So hold on, it’s going to be a great ride.

–Mike Rothman

Research Revisited: Off Topic: A Little Perspective

By Rich

As I was crawling through the old archives for some posts, I found my very first reference to Mike here at Securosis. I timed this Revisited post to fire off when Mike’s post on joining Securosis goes live, and the title now seems to have more meaning.

Off Topic: A Little Perspective

This has nothing to do with security other than the fact Mike Rothman is a security analyst.

Sometimes it’s worth sitting back and evaluating why you’re in the race in the first place. It’s all too easy to get caught up in the insanity of day-to-day demands or the incredibly deceptive priorities of the corporate and government rat races.

A few months ago I took a step back and decided to reduce travel, stay healthy, and start this blog. I wanted a more personal outlet for writing on topics and in a style that’s inappropriate at my day job (in other words, more fun). My challenge is running this site in a way that doesn’t create a conflict of interest with my employer, and thus I don’t publish anything here that I should be publishing there.

Mike just went off and started his own company to support his real priorities.

You should really read this.


Wednesday, February 26, 2014

Research Revisited: Apple, Security, and Trust

By Rich


After publishing this, I realized I should have taken more time editing, especially after Apple released their iOS Security paper this week. My intention was to refer to situations where, often due to attacks, vulnerabilities, or other events, Apple is pushed into responding. They can still struggle to balance the lines between what they want to say, and what outsiders want to hear. They have very much improved communications with researchers, the media, and the level of security information they publish in the open. It is the crisis situations that knock things off kilter at times.

I am sometimes called an Apple apologist for frequently defending their security choices, but it wasn’t always that way. I first started writing about Apple security because those were the products I used, and I was worried Apple didn’t take security seriously. I was very personally invested in their choices, and there were a lot of reasons when I first posted this back in 2006 to think we were headed for disaster.

In retrospect, my post was both on and off target. I thought at the time that Apple needed to focus more on communications. But Apple, as always, chose their own path. They have improved communications significantly, but not nearly as much as someone like Microsoft. But at the same time they tripled down on security. iOS is now one of the most secure platforms out there (yes, even despite the patch last week). OS X is also far more secure than it was, and Apple continues to invest in new security options for users.

I was right and I was wrong. Apple recognized, due to the massive popularity of iOS, that building customer trust was essential to maintaining a market lead. They acted on that with dramatic improvements in security. iOS has yet to suffer any major wide-scale exploitation. OS X added features like FileVault 2 (encryption for the masses) and GateKeeper (wrecking malware markets). Apple most definitely sees security as essential to trust. But they still struggle with communications. Not that I expect them to ever not act like Apple, but they are still feeling their way around the lines to find a level they are comfortable with culturally, which still avoids negative spin cycles like I talk about below.

This post originally appeared on October 18, 2006

Apple, Security, and Trust

Before I delve into this topic I’d like to remind readers that I’m a Mac user and Apple fan. We are a 2 person, 2 Mac, 3 iPod, 2 Airport Express household, with another Mac in the plans this spring. By the same token I don’t think Microsoft is evil and consider some of their products to be quite good. That said I prefer OS X and have no plans to switch to Vista, although I’ll probably run it in a virtual machine on my Mac.

What I’m about to say is in the nature of protecting, not attacking, one of my favorite vendors. Apple faces a choice. Down one path is the erosion of trust, lost opportunities, and customers facing increased risk. On the other path is increased trust, greater opportunities, and happy, safe, customers. I have a lot vested in Apple, and I’d like to keep it that way.

As most of you probably know by now, Apple shipped a limited number of video iPods loaded with a Windows virus that could infect an attached PC. The virus is well known and all antivirus software should stop it, but the reality is this is an extremely serious security failure on the part of Apple. The numbers are small and damages limited, but there was obviously some serious breakdown in their security controls and QA process.

As with many recent Apple security stories this one was about to quietly fade into the night were it not for Apple PR. In Apple’s statement they said, “As you might imagine, we are upset at Windows for not being more hardy against such viruses, and even more upset with ourselves for not catching it.”. As covered by George Ou and Amrit Williams, this statement is embarrassing, childish, and irresponsible. It’s the technical equivalent of blaming a crime victim for their own victimization. I’m not defending the security problems of XP, which are a serious epidemic unto themselves, but this particular mistake was Apple’s fault, and easily preventable.

While Mike Rothman agrees with Ou and Williams, he correctly notes that this is just Apple staying on message. That message, incorporated into all major advertising and marketing, is that Macs are more secure and if you’d just switch to a Mac you wouldn’t have to worry about spyware and viruses.

It’s a good message, today, because it’s true. I bought my mom a Mac and talked my sister into switching her small business to Macs primarily because of security. I’m overprotective and no longer feel my friends and family can survive on the Internet on XP. Vista is a whole different animal, fundamentally more secure than its predecessors, but it’s not available yet so I couldn’t consider that option. Thus it was iMac and Mac mini city.

But when Apple sticks to this message in the face of a contradictory reality they expose themselves, and their customers, to greater risks. Reality is starting to change and Apple isn’t, and therein lies my concern.

All relationships are founded on trust and need. (Amrit has another good post on this topic in business relationships). One of the keystones of trust is security. I like to break trust into three components:

  • Intent: How do you intend to treat participants in a relationship?
  • Capability: Can you behave in compliance with your intent?
  • Communication: Can you effectively communicate both your intent and capability?

Since there’s no perfect security we always need to make security tradeoffs. Intent decides how far you need to go with security, while capability defines if you’re really that secure, and communication is how you get customers to believe both your intent and capability.

Recent actions by Apple are breaking their foundations of trust. As a business this is a critical issue; Apple relies heavily on trust to grow their market. Trust that their products work well, are simple to use, include superior capabilities, and are more secure. Apple’s message is that Macs are secure, simple, elegant, and reliable. Safe and secure is a powerful message, one that I suspect (based on personal experience) drives many switchers. When I told my cab driver today that Macs have no spyware or active viruses he was stunned.

Should Apple lose either their intent to provide superior security, their capability to achieve security, or their ability to communicate either of those, they face reasonable risk of losing customers, or at least growth opportunities. Security, today, is one of Apple’s cornerstones. Anything that erodes it increases their business risks.

At the same time, should communication disconnect from either intent or capability, Apple places then places both their trust relationship, and their customers, at risk. Take my favorite snake-oil salesmen at Diebold- by having no intent to secure their products and no security capabilities in their products, and communicating that the products are secure, they create huge potential for security failures. Less educated customers buy products thinking they’re secure, but the products are so flawed it places these customers (the voting public) at extreme risk. Software vendors have done this in the past – claiming products are secure and covering up failures in the hopes the customers and prospects won’t notice.

Recent events indicate that Apple may stay on an impossible message (perfect security) and face failures in capability despite the best intent. The entire Black Hat debacle showed Apple pushing the message so hard that the debate lived far longer than needed, exposing more of the public to a potential security failure than would have otherwise noticed, drawing the attention of researchers who may now want to prove Apple isn’t invincible, and losing the trust of some of us in the industry disappointed by PR’s management of the incident.

The iPod virus infections shows a lack of capability (security QA in shipping products) and poor communications (failure to take full responsibility). It’s a very small problem, but their arrogant approach to spinning the story lead me to question how they might respond to more serious issues. We have, over the course of a couple months, two incidents where Apple decided to play the PR game rather than taking responsibility and communicating openly. I realize those of you that still believe the wifi hack was BS probably believe Apple dealt with the situation reasonably, but for reasons I can’t disclose I still think PR overrode good security practices.

The latest security updates indicate that OS X, while still materially more secure than XP, has its own fair share of flaws. We’ve seen zero day vulnerabilities in Safari, multiple holes in QuickTime, wireless vulnerabilities, and even a flaw that could allow a specially crafted image sent in email to exploit and own your Mac. The first time Microsoft patched an image vulnerability like that I spammed all my friends and family to update their computers pronto. Macs are pretty secure, but not invulnerable, and fortunately we’ve managed to avoid any significant mass exploits. I’d really like that trend to continue.

Let’s look back on the three components of trust. Right now I believe Apple still intends to keep us secure; of that I have little doubt. The next release of the operating system should be very telling – should they adopt some more advanced OS security features, like memory randomization (a very cool feature of Vista) it will indicate they continue to push towards a secure OS. So far they’ve done pretty well. Next is communication, which is a mixed bag. On one hand, the message is clear and unambiguous – Macs are secure. On the other hand is their arrogance, as best illustrated in the response to the iPod virus and the wifi vulnerability. Those are early indications that the message could exceed reality, eventually (probably) leading to an erosion of trust.

The linchpin is capability. As I already stated – OS X is materially more secure than Windows XP, but is far from perfect. We’ll eventually see a mass exploit (I hope I’m wrong). Recent vulnerability disclosures by Apple themselves indicate that the kinds of serious flaws that lead to worms and viruses can exist in OS X. We also shouldn’t underestimate the impact of goodwill towards Apple on exploit development – researchers and attackers tend to focus on hot issues (just look at the recent spate of Microsoft Office exploits). If you piss off the bad guys, or just the generally good social malcontents, eventually they’ll come after you. Anyone still think Oracle is unbreakable?

Thus Apple stands at a crossroads. Should they choose the marketing line they’d better be able to back it up. If you base your reputation on security, and that security is eroded, trust is equally eroded. If they communicate more openly and honestly about security, communications will reinforce intent and capability and even imperfect security will be accepted by the market. If they intend to deceive the market (the one option I don’t think they’ll take) it will place customers at risk and eventually destroy trust.

I’ve trusted Apple. I’d like that trust to continue. But incidents like the wifi flaw and the iPod virus are starting to weaken that relationship. Not because Apple made mistakes and vulnerabilities and flaws made it into products, but because Apple mangled the communications and lead me to believe image was more important than substance and accountability.

When capability, intent, and communications are aligned, trust is reinforced. If any of those degrade or deviate from reality, trust disappears, customers are in danger, and Apple’s business is at risk.

It’s early. Opportunities are still open. The roads are clear. If Apple is open and honest, and harbors good, intentions they’ll succeed. I really REALLY don’t want to see them go the way of other vendors who put PR in charge of security.


Research Revisited: Hammers vs. Homomorphic Encryption

By Adrian Lane

We are running a retrospective during RSA because we cannot blog at the show. We each picked a couple posts we like and still think relevant enough to share. I picked a 2011 post on Hammers and Homomorphic Encryption, because a couple times a year I hear about a new startup which is going to revolutionize security with a new take on homomorphic encryption. Over and over. And perhaps some day we will get there, but for now we have proven technologies that work to the same end. (Original post with comments)

Researchers at Microsoft are presenting a prototype of encrypted data which can be used without decrypting. Called homomorphic encryption, the idea is to keep data in a protected state (encrypted) yet still useful. It may sound like Star Trek technobabble, but this is a real working prototype. The set of operations you can perform on encrypted data is limited to a few things like addition and multiplication, but most analytics systems are limited as well. If this works, it would offer a new way to approach data security for publicly available systems.

The research team is looking for a way to reduce encryption operations, as they are computationally expensive – their encryption and decryption demand a lot of processing cycles. Performing calculations and updates on large data sets becomes very expensive, as you must decrypt the data set, find the data you are interested in, make your changes, and then re-encrypt altered items. The ultimate performance impact varies with the storage system and method of encryption, but overhead and latency might typically range from 2x-10x compared to unencrypted operations. It would be a major advancement if they could dispense away with the encryption and decryption operations, while still enabling reporting on secured data sets.

The promise of homomorphic encryption is predictable alteration without decryption. The possibility of being able to modify data without sacrificing security is compelling. Running basic operations on encrypted data might remove the threat of exposing data in the event of a system breach or user carelessness. And given that every company even thinking about cloud adoption is looking at data encryption and key management deployment options, there is plenty of interest in this type of encryption.

But like a lot of theoretical lab work, practicality has an ugly way of pouring water on our security dreams. There are three very real problems for homomorphic encryption and computation systems:

  1. Data integrity: Homomorphic encryption does not protect data from alteration. If I can add, multiply, or change a data entry without access to the owner’s key: that becomes an avenue for an attacker to corrupt the database. Alteration of pricing tables, user attributes, stock prices, or other information stored in a database is just as damaging as leaking information. An attacker might not know what the original data values were, but that’s not enough to provide security.
  2. Data confidentiality: Homomorphic encryption can leak information. If I can add two values together and come up with a consistent value, it’s possible to reverse engineer the values. The beauty of encryption is that when you make a very minor change to the ciphertext – the data you are encrypting – you get radically different output. With CBC variants of encryption, the same plaintext has different encrypted values. The question with homomorphic encryption is whether it can be used while still maintaining confidentiality – it might well leak data to determined attackers.
  3. Performance: Performance is poor and will likely remain no better than classical encryption. As homomorphic performance improves, so do more common forms of encryption. This is important when considering the cloud as a motivator for this technology, as acknowledged by the researchers. Many firms are looking to “The Cloud” not just for elastic pay-as-you-go services, but also as a cost-effective tool for handling very large databases. As databases grow, the performance impact grows in a super-linear way – layering on a security tool with poor performance is a non-starter.

Not to be a total buzzkill, but I wanted to point out that there are practical alternatives that work today. For example, data masking obfuscates data but allows computational analytics. Masking can be done in such a way as to retain aggregate values while masking individual data elements. Masking – like encryption – can be poorly implemented, enabling the original data to be reverse engineered. But good masking implementations keep data secure, perform well, and facilitate reporting and analytics. Also consider the value of private clouds on public infrastructure. In one of the many possible deployment models, data is locked into a cloud as a black box, and only approved programatic elements ever touch the data – not users. You import data and run reports, but do not allow direct access the data. As long as you protect the management and programmatic interfaces, the data remains secure.

There is no reason to look for isolinear plasma converters or quantum flux capacitors when when a hammer and some duct tape will do.

–Adrian Lane

Tuesday, February 25, 2014

Research Revisited: Security Snakeoil

By Rich

Wow! Sometimes we find things in the archives that still really resonate. This is a short one but I’ll be damned if I don’t expect to see this exact phrase used on the show floor at RSA this week.

This was posted September 25, 2006. I guess some things never change…

How to Smell Security Snake Oil in One Sentence or Less

If someone ever tells you something like the following:

“We defend against all zero day attacks using a holistic solution that integrates the end-to-end synergies in security infrastructure with no false positives.”

Run away.


New Paper: The Future of Security The Trends and Technologies Transforming Security

By Rich

This paper originally started with a blog post called Inflection. Sure, many of our papers start as a series of posts, but this time the post came long before I thought of a paper. I started seeing a bunch of interrelated trends, and what appeared to be some likely unavoidable outcomes. Unlike most predictive pieces, I focused as much on inherent security trends as on disruptive forces. Less “new attacks” and more “new ways we are doing things”.

The research continued, but I never expected a chance to write it up as a paper.

Out of nowhere the folks at Box contacted me to see if I had an interest in writing up and licensing something on where security is headed. I pointed them toward Inflection, and it hit exactly what they were looking for. So I got a chance to pull together the additional research I have been thinking about since that post back in 2012, and compile everything into a paper. As an analyst it isn’t often I get a chance to focus on far-field research, so I am excited to get this one out the door.

This paper is also being co-released by the Cloud Security Alliance, who reviewed and approved its findings.

I hope you find it useful, and please keep in mind that everything I discuss is in practice someplace today, but I expect it to take ten or more years for these practices to become widespread and their full implications to kick in.

Executive Overview ToC


Research Revisited: RSA/NetWitness Deal Analysis

By Mike Rothman

As we continue our journey down memory lane I want to take a look at what I said about the RSA/NetWitness deal back in April 2011, when it was announced. In hindsight the NetWitness technology has become the underlying foundation of RSA’s security management and security analytics offerings, so I underplayed that a bit. EnVision is pretty much dead. And we haven’t really seen a compelling alternative on the full packet capture and analytics front. Although a bunch of bigger SIEM players started introducing that technology this year.

As with most everything, some prognostications were good and some not so good. And if I had a crystal ball that worked I would have invested in WhatsApp, rather than trying to figure out the future of security.

Fool us once… EMC/RSA Buys NetWitness

(Published on the Securosis blog April 4, 2011)

To no one’s surprise (after NetworkWorld spilled the beans two weeks ago), RSA/EMC formalized its acquisition of NetWitness. I guess they don’t want to get fooled again the next time an APT comes to visit. Kidding aside, we have long been big fans of full packet capture, and believe it’s a critical technology moving forward. On that basis alone, this deal looks good for RSA/EMC.

Deal Rationale

APT, of course. Isn’t that the rationale for everything nowadays? Yes, that’s a bit tongue in cheek (okay, a lot) but for a long time we have been saying that you can’t stop a determined attacker, so you need to focus on reacting faster and better. The reality remains that the faster you figure out what happened and remediate (as much as you can), the more effectively you contain the damage. NetWitness gear helps organizations do that. We should also tip our collective hats to Amit Yoran and the rest of the NetWitness team for a big economic win, though we don’t know for sure how big a win. NetWitness was early into this market and did pretty much all the heavy lifting to establish the need, stand up an enterprise class solution, and show the value within a real attack context.

They also showed that having a llama at a conference party can work for lead generation. We can’t minimize the effect that will have on trade shows moving forward.

So how does this help EMC/RSA? First of all, full packet capture solves a serious problem for obvious targets of determined attackers. Regardless of whether the attack was a targeted phish/Adobe 0-day or Stuxnet type, you need to be able to figure out what happened, and having the actual network traffic helps the forensics guys put the pieces together. Large enterprises and governments have figured this out and we expect them to buy more of this gear this year than last. Probably a lot more. So EMC/RSA is buying into a rapidly growing market early.

But that’s not all. There is a decent amount of synergy with the rest of RSA’s security management offerings. Though you may hear some SIEM vendors pounding their chests as a result of this deal, NetWitness is not SIEM. Full packet capture may do some of the same things (including alert on possible attacks), but it analysis is based on what’s in the network traffic – not logs and events. More to the point, the technologies are complimentary – most customers pump NetWitness alerts into a SIEM for deeper correlation with other data sources. Additionally some of NetWitness’ new visualization and malware analysis capabilities supplement the analysis you can do with SIEM. Not coincidentally, this is how RSA positioned the deal in the release, with NetWitness and EnVision data being sent over to Archer for GRC (whatever that means).

Speaking of EnVision, this deal may take some of the pressure off that debacle. Customers now have a new shiny object to look at, while maybe focusing a little less on moving off the RSA log aggregation platform. It’s no secret that RSA is working on the next generation of the technology, and being able to offer NetWitness to unhappy EnVision customers may stop the bleeding until the next version ships.

A side benefit is that the sheer amount of network traffic to store will drive some back-end storage sales as well. For now, NetWitness is a stand-alone platform. But it wouldn’t be too much of a stretch to see some storage/archival integration with EMC products. EMC wouldn’t buy technology like NetWitness just to drive more storage demand, but it won’t hurt.

Too Little, Too Late (to Stop the Breach)

Lots of folks drew the wrong conclusion, that RSA bought NetWitness because of their recent breach. But these deals doesn’t happen overnight, so this acquisition has been in the works for quite a while. But what could better justify buying a technology than helping to detect a major breach? I’m sure EMC is pretty happy to control that technology. The trolls and haters focus on the fact that the breach still happened, so the technology couldn’t work that well, right?

Actually, the biggest issue is that EMC didn’t have enough NetWitness throughout their environment. They might have caught the breach earlier if they had the technology more widely deployed. Then again, maybe not, because you never know how effective any control will be at any given time against any particular attack, but EMC/RSA can definitely make the case that they could have reacted faster if they had NetWitness everywhere. And now they likely will.

Competitive Impact

The full packet capture market is still very young. There are only a handful of direct competitors to NetWitness, all of whom should see their valuations skyrocket as a result of this deal. Folks like Solera Networks are likely grinning from ear to ear today. We also expect a number of folks in adjacent businesses (such as SIEM) to start dipping their toes into this water.

Speaking of SIEM, NetWitness did have partnerships with the major SIEM providers to send them data, and this deal is unlikely to change much in the short term. But we expect to see a lot more integration down the road between NetWitness, EnVision Next, and Archer, which could create a competitive wedge for RSA/EMC in large enterprises. So we expect the big SIEM players to either buy or build this capability over the next 18 months to keep pace. Not that they aren’t all over the APT marketing already.

Bottom Line

This is a good deal for RSA/EMC – acquiring NetWitness provides a strong, differentiated technology in what we believe will be an important emerging market. But with RSA’s mixed results in leveraging acquired technology, it’s not clear that they will remain the leader in two years. But if they provide some level of real integration in that timeframe, they will have a very compelling set of products for security/compliance management.

This is also a good deal for both NetWitness and RSA customers. The product is now too high-profile for RSA to muck with it and decrease its value, as happens with all too many acquisitions. There are some potentially interesting integration opportunities, and the product will hum along nicely for those who are happy with current capabilities and the usual improvements over time.

It isn’t often we get to say nice things about a security deal, but this one is a slam dunk.

–Mike Rothman