Login  |  Register  |  Contact
Wednesday, March 25, 2015

Network-based Threat Detection: Overcoming the Limitations of Prevention

By Mike Rothman

Organizations continue to invest heavily to block advanced attacks, on both endpoints and networks. Despite all this investment devices continue to be compromised in increasing numbers, and high-profile breaches continue unabated. Something isn’t adding up. It comes down to psychology – security practitioners want to believe that the latest shiny geegaw for preventing compromise will finally work and stop the pain.

Of course we are still waiting for effective prevention, right? So we have been advocating a shift in security spending, away from ineffective prevention and towards detection and investigation of active adversaries within your networks and systems. We know many organizations have spent a bunch of money on detection – particularly intrusion detection, its big brother intrusion prevention, and SIEM.

But these techniques haven’t really worked effectively either, so it’s time to approach the issue with fresh eyes. Our Network-based Threat Detection series will do just that. By taking a new look at detection, not from the standpoint of what we have done and implemented (IDS and SIEM), but what we need to do to isolate and identify adversary activity, we will be able to look at the kinds of technologies needed right now to deal with modern attacks. The times have changed, the attackers have advanced, and our detection techniques for finding adversaries need to change as well.

As always, we wouldn’t be able to publish our research for the awesome price of zero without clients supporting what we do. So we’d like to thank Damballa and Vectra Networks for potentially licensing this content at the end of this series. We will develop the content using our Totally Transparent Research methodology, with everything done in the open and objectively.

Threat Management Reimagined

Let’s revisit how we think about threat management now. As we first documented in Advanced Endpoint and Server Protection, threats have changed so you need to change the way you handle them. We believe threat management needs to evolve as follows:

  1. Assessment: You cannot protect what you don’t know about – that hasn’t changed and isn’t about to. So the first step is to gain visibility into all devices, data sources, and applications that present risk to your environment. Additionally you need to understand the security posture of anything you have to protect.
  2. Prevention: Next try to stop attacks from succeeding. This is where most of the effort in security has been for the past decade, with mixed (okay, lousy) results. A number of new tactics and techniques are modestly increasing effectiveness, but the simple fact is that you cannot prevent every attack. It is now a question of reducing attack surface as much as practical. If you can stop the simplistic attacks you can focus on advanced ones.
  3. 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.
  4. Investigation: 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 a search to determine how widely the attack spread within your environment.
  5. Remediation: Once you understand what happened you can put a plan in place to recover the compromised device. This might involve cleaning the machine, or more likely re-imaging it and starting over again. This step can leverage ongoing hygiene activities (such as patch and configuration management) because you can and should use tools you already have to reimage compromised devices.

This reimagined threat management process incorporates people, processes, and technology – integrated across endpoints, servers, networks, and mobile devices. If you think about it, there is a 5x4 matrix of all the combinations to manage threats across the entire lifecycle for all device types. Whew! That would be a lot of work (and a really long paper). The good news for this series is that we will focus specifically on network-based detection.

Why Not Prevention?

From reading thus far, you may think we’ve capitulated and just given up on trying to prevent attacks. Not true! We still believe that having restrictive application-centric firewall policies and looking for malware on the ingress pipes is a good thing. Our point is that you can’t assume that your prevention tactics are sufficient. They aren’t.

Adversaries have made tremendous progress in being able to evade intrusion prevention and malware detonation devices (sandboxes). And remember that your devices aren’t always protected by the network perimeter or your other defenses at all times. Employees take the devices outside of the network and click on things. So your devices may come back onto the corporate network infected.

That doesn’t mean these devices don’t catch stuff, but they don’t catch everything. Thus, if you are having trouble understanding the importance of detection; think about it as Plan B. Every good strategist has Plan B (and Plan C, D, and E) and focusing effort on detection gives you a fallback position when your prevention doesn’t get it done.

So in a nutshell, it’s not either prevention or detection. It’s both.

Why Not Existing Monitoring?

You probably already spent a bunch of time and money implementing intrusion detection/prevention and SIEM to monitor those network segments. So why isn’t that good enough? It comes down to a fundamental aspect of IDS and SIEM: you need to know what you are looking for. Basically, you define a set of conditions (rules/policies) to look for typical patterns of attacks in your network traffic or event logs. If an attacker uses a common attack that has already been profiled, and you have added the rule to your detection system, and your device can handle the volumes (because you probably have 10,000 other rules defined in that device) you will be able to find that attack.

But what if the attacker is evading your devices by hiding traffic in a standard protocol and communicating by proxying through a legitimate network? What if they are using a pattern you haven’t seen before? Yep, you’ll miss the attack.

Again, it’s not like you don’t have to monitor your systems and networks anymore. Compliance mandates that you still need your IPS and your SIEM. It’s still critical to collect data and analyze it to find attacks you know about. And to be fair, many IDS/IPS and SIEM platforms are adding more sophisticated analysis to their standard correlation capabilities to improve detection. But these approaches still require a lot of tuning and experimentation to get right, and nobody has time to do everything. Nobody has time to waste on a noisy security monitor.

The Answer Is…

Unfortunately we haven’t found sustainable cold fusion, or a magic bullet that identifies every attack from every adversary every time (cold fusion actually seems a bit more likely). Would be nice though, right? But a couple capabilities have come together to enable better and more accurate detection on the network:

  1. Math: Actually math has been around for a while (yes, that’s sarcasm). But improved ability to find patterns among a variety of data sources has made a big difference in the effectiveness of detection. Vendors call this “Big Data Analytics” and “Machine Learning”. Shiny buzzwords aside, these capabilities improve your ability to find anomalous traffic earlier in the attack chain.
  2. Context: Anomaly detection has been around almost as long as math, but it offered limited value because it threw off a lot of false positives. An anomaly could just as easily be legitimate and malicious, but you had no way to tell the difference without a pretty deep investigation. So being able to evaluate other types of data such as identity and content/payload, and to prioritize anomalies based on which are more likely to be an attack, helps you eliminate now-obvious false positives.

So network-based detection has evolved to the point where you can identify devices that look like they have been compromised. To be clear, this is still suboptimal, because damage has already been done. Our inner security purist still wants to block every attack. But a breach doesn’t happen until exfiltration occurs, and if you are able to respond faster and better you can contain the damage. That’s what better detection is all about.

Our next post will dig into the typical indications of a compromised device. Attackers always leave traces, so by looking for certain things on your network you can find them.

—Mike Rothman

Incite 3/25/2015: Playing it safe

By Mike Rothman

A few weeks back at BSidesATL, I sent out a Tweet that kind of summed up my view of things. It was prompted by an email from a fitness company with the subject line “Embrace Discomfort.” Of course they were talking about the pain of whatever fitness regimen you follow. Not me. To me, comfort is uncomfortable.

Comfort is uncomfortable

I guess I have always been this way. Taking risks isn’t risky from where I sit. In fact playing it safe feels dangerous. Of course I don’t take stupid risks and put myself in harm’s way. At least I don’t any more – now I have a family who depends on me. But people ask me how I have the courage to start new businesses and try things. I don’t know – I just do. I couldn’t really play it safe it I tried.

Not that playing it safe is bad. To the contrary, it’s a yin-yang thing. Society needs risk-takers and non-risk-takers. However you see yourself, make sure you understand and accept it, or it will not end well.

For instance some folks dream of being a swashbuckling entrepreneur, jumping into the great unknown with an idea and a credit card to float some expenses. If you are risk-averse that path will be brutal and disappointing. Even if the venture is successful it won’t feel that way because the roller coaster of building a business will be agonizing for someone who craves stability.

Risk Takers

Similarly if you put an entrepreneur into a big stable company, they will get into trouble. A lot of trouble. Been there, done that. That’s why it is rare to see true entrepreneurs stay with the huge companies that acquire them, after the retention bonuses are paid and the stock is vested. It’s just soul-crushing for swashbucklers to work in place with subsidized cafeterias and large HR departments.

I joked that it was time to leave META Group back in the mid-90s, when we got big enough that there were people specifically tasked with making my job harder. They called it process and financial controls. I called it bureaucracy and stupid paperwork. It didn’t work for me so I started my own company. With neither a subsidized cafeteria nor an HR department. Just the way I like it.

–Mike

Photo credit: “2012_05_050006 Road to Risk Takers Select Committees” originally uploaded by Gwydion M. Williams


Have you registered for Disaster Recovery Breakfast VII yet? What are you waiting for. Check out the invite and then RSVP to rsvp (at) securosis.com, so we know how much food to get…


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


Securosis Firestarter

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


Heavy Research

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

Endpoint Defense Essential Practices

Applied Threat Intelligence

Network Security Gateway Evolution

Newly Published Papers


Incite 4 U

  1. We’re hacking your stuff too, eh! All my Canadian friends are exceedingly nice. I’m sure many of you know our contributors from up North, Dave Lewis and James Arlen, and there aren’t any nicer people. They are cranky security people like the rest of us, but they somehow never seem cranky. It’s a Canadian thing. So when you hear about the Canadians doing what pretty much every other government is doing and hacking the crap out of all sorts of things, you say, “Eh? The Canadians? Really?” Even better, the Canadians are collaborating with the NSA to use social engineering and targeted attacks to “garner foreign intelligence or inflict network damage.” The spinmeisters were spinning hard about the documents being old, blah blah blah. Maybe they need a little Rob Ford action in the cyber department to give us the real low-down. But you know what? I’m sure they were very polite guests and left everything exactly as they found it. – MR

  2. He had me at Manifesto: I love a good manifesto. Nothing gets the blood moving like a call to arms, to rally the troops to do something. My friend Marc Solomon of Cisco advocates for CISOs to write their own manifestoes to get the entire organization thinking about security. I’m not sure how you make security “a growth engine for the business”, but a lot of his other aspirations are good. Things like security must be usable, transparent, and informative. Yup. And security must be viewed as a “people problem,” which really means that if you didn’t have all these pesky employees you would have far fewer security problems. Really it’s a sales document. You (as CISO) are selling the security mindset to your organization, and that is a manifesto worth writing. – MR

  3. E-DDoS coming to a cloud near you: One of the newer attack vectors I highlighted in our denial of service research a couple years ago was an economic denial of service. An adversary can hammer a cloud-based system, driving costs up to the victim’s credit limit. No more credit, no more cloud services. I guess that’s the cloud analogue to “No shoes, no shirt, no dice.” [Dude)…] It seems someone in China doesn’t like that some website allows connectivity to censored websites, so they are blasting them with traffic, costing $30,000/day in cloud server costs. These folks evidently have a lot of credit with Amazon and haven’t been forced to shut down. Yet. Aside from the political reality an attack like this represents, it is a clear example of another more diabolical type of attack. A DDoS that knocks your stuff down may impact sales, but not costs. This kind of attack hits you below the belt: right in the wallet. – MR

—Mike Rothman

Friday, March 20, 2015

Endpoint Defense Essential Practices

By Mike Rothman

The area of security has the most increased focus recently is protecting the endpoint. Once you stop snickering, it makes some sense. For years (or decades, depending on how cynical you want to be) endpoint security was the beneficiary of the compliance driver. Whether the technologies actually protected anything was beside the point. Assessors would show up, and you needed to have AV. Then advanced attackers happened and the industry started innovating, starting with network security, leaving the endpoint largely unprotected.

But that’s no longer a defensible strategy. Endpoints are more likely untethered than not, so these devices are no longer within the corporate perimeter. You could route all traffic through your corporate network, but that defeats the purpose of the cloud and the Internet. We have seen a renaissance of sorts with lots of interesting technologies designed to protect endpoints. We covered many of these developments in our Advanced Endpoint and Server Protection paper.

But the fact remains: many organizations are not even prepared to deal with unsophisticated attackers. You know, that dude in the basement banging on your stuff with Metasploit. Those organizations don’t really need advanced security – their needs are more fundamental. They need to understand what really needs to get done – not the hot topic at industry conferences. They cannot do everything to fully protect endpoints, so they need to start with the essentials.

So this post is all about these Essential Practices of Endpoint Defense. Thanks to our friends at Viewfinity, we will turn this post into a short paper.

Securing Endpoints Is Hard

Why is this still a discussion? Endpoints have been around for decades, and organizations have spent tens of billions of {name your favorite currency} to protect these devices. But every minute more devices are compromised, breaches result, and your Board of Directors wants an explanation of why this keeps happening. Two issues underlie the difficulties of endpoint protection. First, let’s be candid. It’s a software issue – software has defects, which attackers exploit. Second, employees routinely fall for simplistic social engineering attacks, resulting in a software install or clicked link – the beginning of a successful attack.

And you are a target, regardless of the size of your organization. You have something someone else wants to steal, and they will try. Complicating the situation, adversaries continue to automate their reconnaissance and attack efforts. You are not protected by resource constraints – the entire Internet can be scanned for common vulnerabilities daily.

The status quo doesn’t work for our side. We need to take a step back, and look at protecting endpoints with fresh eyes. This provides an opportunity to determine what’s really essential.

Defending Endpoints

As we have alluded, there are two aspects to defending endpoints: hygiene and threat management. They are co-dependent – you cannot just address either on and expect your endpoints to be protected.

Endpoint Defense Yin Yang

  • Endpoint Hygiene: The operational aspects of reducing device attack surface are an integral aspect of endpoint security strategy. You need to ensure you have sufficient capabilities to manage patches and enforce security configuration policies. Additionally, you should ensure employees have the least privilege necessary on each device to prevent privilege escalation, and lock down device ports.

  • Endpoint Threat Management: Advanced attackers are only as advanced as they need to be: they take the path of least resistance. But the converse is also true. When these adversaries need advanced techniques, they use them. Traditional malware defenses such as antivirus don’t stand much chance against a zero-day attack. An effective threat management process incorporates people, processes, and technology.

Now let’s dig into both aspects of endpoint defense to identify these essential practices.

Endpoint Hygiene

Consistent and effective hygiene practices are elusive, both personally (look at your dentist’s fancy car) and within security. It is not a lack of desire – everyone wants to ensure their devices are difficult to compromise. It has been a challenge of operational excellence. To be clear, effective hygiene practices don’t completely protect endpoints, but they certainly make them much harder targets.

The essential practices we lump into the hygiene bucket include:

  • Patch Management
  • Configuration Management
  • Device Control
  • Least Privilege

Patch Management

Patch managers install fixes from software vendors to address vulnerabilities. The most well-known patching process is Microsoft’s monthly Patch Tuesday, when the company issues a variety of software fixes to address defects in its products – many of which could result in system exploitation. Other vendors have adopted similar approaches, with a periodic patch cycle and out-of-cycle patches for more serious issues. Once a patch is issued your organization needs to assess it, figure out which devices need to be patched, and install it within the window specified by policy – typically a few days. A patch management product scans devices, installs patches, and reports on the success or failure of the process. Our Patch Management Quant research provides a detailed view of the patching process, so refer to it for more information.

Configuration Management

Configuration management enables an organization to define an authorized set of configurations for devices. These configurations can control pretty much everything that happens on the device, including: applications installed, device settings, running services, and on-device security controls. Another aspect of configuration management is the ability to assess configurations and identify changes, which is valuable because unauthorized configuration changes may indicate malware execution or an exploitable operational error. Additionally, configuration management can help ease the provisioning burden of setting up and reimaging devices after infection.

Device Control

End users love the flexibility USB ports provide for ‘productivity’. Unfortunately USB doesn’t just enable employees to share music with buddies – it also lets them download your entire customer database onto their phones. It all became much easier once the industry standardized on USB a decade ago. The ability to easily share data has facilitated employee collaboration, while also greatly increasing the risks of data leakage and malware proliferation. Device control technology enables you to enforce policy – both who can use USB ports and how – and capture whatever is copied to and from USB devices. As an active control, monitoring and control over device usage addresses a major risk.

Least Privilege

Employees don’t mean to mess up their devices, for the most part. But allowing them to install software, use new devices like printers, and change endpoint configurations can lead to device exploitation. So eliminating device owners’ ability to manage devices can dramatically reduce attack surface. That said, a lot of endpoint changes are legitimate, so a key aspect of implementing least privilege is ensuring there is a clear process to allow employees to do their jobs. For instance, trusted employees might be able to get a 24-hour grace period for a change, while less sophisticated employees may need to run through an approval process to install new software.

Endpoint Threat Management

We define threat management within the context of dealing with an attack, as a subset of a larger security program – typically the most visible capability. So it’s time to explain the components of threat management.

Assessment

You cannot protect what you don’t know about – that hasn’t changed and is not about to. So the first step is to gain visibility into all devices, data sources, and applications that present risk to your environment. Additionally you need to understand the security posture of anything you have to protect.

You need to know what you have, how vulnerable it is, and how exposed it is. With this information you can prioritize your exposure and design a set of security controls to protect your assets.

  • Mission Assessment: As we described in our CISO’s Guide to Advanced Attackers, you need to understand what attackers will try to access in your environment, and why. We call this Mission Assessment, and it involves figuring out what’s important in your environment.

  • Discovery: This process finds the endpoints and servers on your network and makes sure everything is accounted for. It includes an ongoing discovery process to shorten the window between something popping up on your network, you discovering it, and figuring out whether it has been compromised.

  • Determine Security Posture: Once you know what’s out there you need to figure out how vulnerable it is. That typically requires some kind of vulnerability scan on the devices you discovered. There are many aspects to vulnerability scanning – at the endpoint, server, and application layers. Check out our Vulnerability Management Evolution research to understand how a vulnerability management platform can help prioritize operational security.

It may not be as sexy as a shiny malware sandbox or advanced detection technology, but these assessment tasks are necessary before you can even start thinking about building a set of controls to prevent attacks. Assessment needs to happen on an ongoing basis because your technology environment is dynamic, and the attacks you see are subject to change as well – sometimes daily.

Prevention

Next you try to stop attacks from succeeding. This is where most of the effort in security has been for the past decade, with mixed (okay – lousy) results. A number of new tactics and techniques are modestly increasing effectiveness, but the plain fact is that you cannot prevent every attack. It is now a question of reducing your attack surface as much as practical.

  • Traditional Signatures: Signature-based controls are all about maintaining a huge blacklist of known malicious files to prevent from executing.

  • Advanced Heuristics: You cannot depend on matching what a file looks like, so you need to pay close attention to what it does, and profile typical patterns of successful attacks. This is the concept behind the advanced heuristics used to detect malware.

  • Application Control/Whitelisting: Application control implies a default deny posture on devices. You define a set of authorized executables that can run on a device, and block everything else. With a strong policy in place, application control provides true device lockdown – no executables (either malicious or legitimate) can execute without explicit authorization. Check out our Application Control research for a lot more detail on this approach.

  • Isolation: In addition to better profiling malware and searching for indicators of compromise, another prevention technique with growing popularity is isolating executables from the rest of the device by running them in a sandbox. The idea is to spin up a walled garden for a limited set of applications, to shield the rest of the device from anything bad happening within those applications.

Now it’s time for the hard truth. You cannot block all attacks. Adversaries have gotten much better, attack surface has increased dramatically, and you are not going to prevent every attack. Pwnage happens, so what you do next is critical – both to protecting critical information in your environment, and to your success as a security professional.

Detection

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.

In the broader sense, detection 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) which they use as needed. So your prevention technology could be working as designed, but still not recognize an attack. There is no shame in that.
  2. The prevention technology missed the attack – This is common 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. Very few organizations have the dubious distinction of being first to see a new ‘advanced’ attack, so you should be able to look for emerging attack indicators, IP and file reputation, etc. as a basis for detecting attacks. This kind of “threat intelligence” enables you to benefit from the misfortune of others, by looking for attacks you haven’t seen yet.

Once you identify a potentially compromised device, you need to verify your suspicion. Verification involves scrutinizing what the endpoint has done recently for indicators of compromise, or other activity that confirms a successful attack.

Investigation

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, and a search to determine how widely the attack spread within your environment.

  • Data Capture: To really investigate a device you need to capture what’s happening on 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 activity on the device.

  • Analytics: Endpoints and servers generate a huge amount of data, so a product needs to perform Big Data style analysis on telemetry data to identify patterns and develop relationships across 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 data to provide useful information to security practitioners and incident responders is the third leg of the device activity monitoring triangle.

Remediation

Once you understand what happened you can put a plan in place to recover. This might involve cleaning the machine, or more likely reimaging it and starting over again. This step can leverage ongoing hygiene activities (such as patch and configuration management), because you can and should use tools you already have to reimage compromised devices.

It also requires tight integration with the Operations team – most organizations separate out threat management functions from endpoint operations functions. This means integrating systems and ensuring that the handoffs between the security and Ops teams are well-structured and efficient.

Bringing It All Together

The key to making both sides of endpoint defense work well is a common data model. You should be able to integrate and analyze data about endpoints, without moving between systems or only looking at only half the story (either threat management or hygiene). For example if you detect a known malware file on an endpoint you know has been patched to protect it from that compromise, you can move on to other more pressing concerns.

On the other side of the coin, if a different device has known malware installed and recently escalated privileges (as recorded by policy), you know that’s a serious problem; you can immediately quarantine the device by shutting down the network connectivity, then locking down what software it can execute by enforcing a whitelisting policy. Without hygiene and threat management consolidating data into a common view you cannot attain that level of integrated defense.

You do not need to use one solution for everything, but you must be able to integrate data to build a consistent end-to- end view. This might involve sending data to a separate aggregation platform like a SIEM or security analytics product, or ensuring that both your hygiene and threat management vendors can export data to your integration point.

Summary

Perfectly defending against endpoint attacks is a pipe dream, so organizations need to shift away from ineffective legacy protection technologies and procedures. Endpoint security has two major components: hygiene and threat management. Neither is sufficient itself – you need to implement and test both to adequately defend endpoints. It is tempting to focus on state-of-the-art defenses to protect against advanced attacks, but without a strong foundation to reduce attack surface and ensure endpoint hygiene, your devices will be compromised.

This is another situation where you need to walk before you can run. Get the essential pieces of the foundation in place, and then layer more advanced prevention and detection technologies onto your foundation. That isn’t what most organizations want to hear, but it’s necessary. If you can’t get the basic functions right you have no chance against an adversary who knows what they are doing.

—Mike Rothman

New! Cracking the Confusion: Encryption & Tokenization for Data Centers, Servers, & Applications

By Rich

Woo Hoo! It’s New Paper Friday!

Cracking_the_Confusion-_Datacenter_Encryption.v.1.final.pdf

Over the past month or so you have seen Adrian and myself put together our latest work on encryption. This one is a top-level overview designed to help people decide which approach should work best for datacenter projects (including servers, storage, applications, cloud infrastructure, and databases). Now we have pieced it together into a full paper.

We’d like to thank Vormetric for licensing this content. As always we wrote it using our Totally Transparent Research process, and the content is independent and objective. Download the full paper.

Here’s an excerpt from the opening:

Today we see encryption growing at an accelerating rate in data centers, for a confluence of reasons. A trite way to summarize them is “compliance, cloud, and covert affairs”. Organizations need to keep auditors off their backs; keep control over data in the cloud; and stop the flood of data breaches, state-sponsored espionage, and government snooping (even by their own governments).

Thanks to increasing demand we have a growing range of options, as vendors and even free and Open Source tools address this opportunity. We have never had more choice, but with choice comes complexity – and outside your friendly local sales representative, guidance can be hard to come by.

For example, given a single application collecting an account number from each customer, you could encrypt it in any of several different places: the application, the database, or storage – or use tokenization instead. The data is encrypted (or substituted), but each place you might encrypt raises different concerns. What threats are you protecting against? What is the performance overhead? How are keys managed? Does it all meet compliance requirements?

This paper cuts through the confusion to help you pick the best encryption options for your projects. In case you couldn’t guess from the title, our focus is on encrypting in the data center: applications, servers, databases, and storage. Heck, we will even cover cloud computing (IaaS: Infrastructure as a Service), although we covered it in depth in another paper. We will also cover tokenization and discuss its relationship with encryption.

We would like to thank Vormetric for licensing this paper, which enables us to release it for free. As always, the content is completely independent and was created in a series of blog posts (and posted on GitHub) for public comment.

—Rich

Summary: Crunch Time

By Rich

I’ve had one conversation about 8 times this week:

“Ready for RSA?”

“Not even close.”

“Yeah, figured it would be better since they pushed it out an extra month, but not so much.”

For those who don’t know, the RSA conference is the biggest event in our industry. Usually it’s in February or March, but this year it’s in April. A full extra month to prep presentations, or marketing material for vendors (my end-user friends who aren’t presenting don’t worry about any of this). Plus there are all the community things, like the Security Blogger’s Meetup, our Disaster Recovery Breakfast, and so on.

Seems like we all just pushed everything back a month, and if anything are even further behind than usual. Or maybe that’s just me, a pathological procrastinator.

So I don’t have time for the usual Summary this week. Especially because we have a ton of projects going on concurrently, and I’m about to start bouncing around the country again for client projects. The travel itself isn’t exciting but the projects themselves are. Most of my trips are to help end-user orgs build out their cloud security strategy and tactics. It’s a big change from Gartner, when I never got to roll up my sleeves and dig in deep. The fascinating bit is the kinds of organizations who are moving to cloud (mostly AWS, because that’s where I’m deepest technically). Instead of being startups these are established companies, some quite large, and a few heavily regulated. I knew we’d get here someday, but I didn’t expect cloud adoption to hit these segments so soon.

Mike and Adrian are just as busy as I am, which is why the blog is so slow, but some new projects are about to hit. We’ve also been working on our annual RSA Guide, which you will start seeing pieces of soon. This year our Contributing Analysts wrote a lot of the content.

But hey, we’ve been around 8+ years and still put up multiple blog posts a week, even when things are ugly. So we have that going for us.

Which is nice.

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 Tom, in response to My $500 Cloud Security Screwup–UPDATED.

Great writeup – being able to admit you made a mistake is very hard for some, but we all do, bravo for being up front about it.

AWS (Amazon, in general) has always been really super super reasonable about charges with me – I too have had them reverse a charge (in my case, for Amazon prime that I didn’t really use) that was totally on my own shoulders, without me asking – good on them, it makes me feel very, very comfortable with trusting them to do the right thing. I like to think a big part of it was you posting about this and owning the issue – this is an awesome example of how to handle this sort of situation with integrity and competence.

I suggest the VERY first thing you do with a new AWS account is turn on MFA, make an IAM account, and put the master credentials on a thumb drive in a desk drawer (locked, ideally). Then, use that IAM account to make less-privileged ones, and use those in practice. It is a pain, to be sure, but it is important to lay a good foundation. (I actually have gone further and worked out federated access for our team at work, and ALL credentials that could reasonably be exposed have a very short lifespan – accidentally checked-in creds in code are to our internal auth server, unusable to the real world. It was a pain, but it lets me sleep better.)

You inspire me; I should clean up the federation server and put it out there for others to use.

—Rich

Wednesday, March 18, 2015

Incite 3/18/2015: Pause

By Mike Rothman

It’s been over a month since I wrote an Incite. It’ is the longest period of downtime since I joined Securosis. I could talk about my workload, which is bonkers right now. But over the years I’ve written the Incite regardless of workload. I could talk about excessive travel, but I haven’t been traveling nearly as much as last year. I could come up with lots of excuses, but as I tell my kids all the time, “I’m not in the excuses business.”

Here’s the reality: I needed a break. I have plenty to write about, but I found reasons not to write. There is a ton of stuff going on in security, so there were many interesting snippets I let fly right on by. But I didn’t write it, and I didn’t really question it. What I needed was what my Tao teacher calls a pause.

Hit the pause button

You could need a pause for lots of reasons. Sometimes you have been running too hard for too long. Sometimes you need to change things up a bit because the status quo makes you unhappy. Sometimes you need some space to recalibrate and figure out what you want to do and where you want to go. Of course, this could be for very little things, like writing the Incite every week. Or very big things. But without taking a pause, you don’t have the space to make objective decisions.

You are reading this, so obviously I am writing the Incite. So during my pause, it became clear that the Incite is an important part of what I do. But it’s bigger than that. It’s an important part of who I am. I have shared the good and the not so good through the years. I have met people who tell me they have experienced what I write about, and it’s helpful for them to commiserate – even if it’s virtual. Some tell me they learn through my Incites, and there is nothing more flattering. But it’s not why I write the Incite.

I write the Incite for me. I always have. It’s a journal of sorts representing my life, my views, and my situation at any given time. Every so often I go back a couple years and read my old stuff. It reminds me of what things were like back then. It’s useful because I don’t spend much time looking backwards. It’s interesting to see how different I am now. Some people journal in private. I do that too. But I have found my public journal is important to me.

The pause is over. I’m pushing Play. In the coming months there will be really cool stuff to share and some stuff that will be hard to communicate. But that’s life. You take the good and the bad without judgement. You move forward. At least I do. So stay tuned. The next few months are going to be very interesting, for so many reasons.

–Mike

Photo credit: “Pause? 272/265” originally uploaded by Dennis Skley


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


Securosis Firestarter

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


Heavy Research

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

Cracking the Confusion

Applied Threat Intelligence

Network Security Gateway Evolution

Newly Published Papers


Incite 4 U

(Note: Don’t blame Rich or Adrian for the older Incite… They got me stuff on time – it just took me a month to post it. You know, that pause I talked about above.)

  1. There are no perfect candidates… There is no such thing as perfect security, so why would there be perfect security candidates? Our friend Andy Ellis, CISO of Akamai, offers a refreshing perspective on recruiting security professionals. Andy focuses on passion over immediate competence. If a person loves what they do they can learn the rest. I think that’s great, especially given the competition for those with the right certifications and keywords on their CVs. Andy also chooses to pay staffers fairly instead of pushing them to find other jobs as their skills increase. Again, very smart given the competition for security staff. The #1 issue we hear from CISO types, over and over, is the lack of staff / recruiting challenge. So you need to find folks in places others aren’t looking, and invest in them – knowing a few will leave for greener pastures at some point. That’s all part of the game. – MR

  2. No love: Another encryption vendor got rolled up recently, with Voltage security acquired by HP. But before you lose your train of thought, with jokes about how HP is where tech companies go to die – yeah, we heard a lot of that in the last 24 hours – note this is occurring with encryption firms of all sizes. In case you missed it, Porticor was acquired by Intuit the week before the HP/Voltage deal. And before that, Safenet to Gemalto, Entrust to Datacard, and Gazzang went to Cloudera. You would think selling data encryption in the age of data breaches would be like giving ice cream to kids on a hot day, but the truth is selling is hard because implementing it is hard. Customers view encryption as a commodity, with one AES variant the same as every other, and complain bitterly about cost and key management headaches. Encryption platforms have matured steadily over the last 10 years, and continually evolved to include format preserving encryption, tokenization, transparent encryption, dynamic masking, key storage, and management, all while integrating with storage systems, apps, applications, cloud services and ‘big data’. The trend is clearly to bake data encryption in, but innovation and growing demand for data security mean this market is far from settled. – AL

  3. Bring Your Own Key: I’m a big fan of the cloud, and of encryption, which is why I’m excited to see Box announce their new Enterprise Key Management product. First a little full disclosure: I have known about this for a while and I done some work with Box (which was not a secret). That said, it isn’t like I get paid more if anyone buys the service from them. I’ve been on record for a few years as not a fan of proxy-based encryption for cloud computing. Shoving an appliance (or service) between your users and the cloud platform so you can encrypt a few fields seems like a kludge prone to breaking application functionality. But almost no providers allow customers to manage their own encryption in a way that can protect against misuse by the provider (or snoops, criminal or government). Box’s EKM enables customers to control their own encryption keys, but all the actual work happens within Box. This reduces the likelihood the application will break. It isn’t necessarily completely subpoena proof, but there is no way for anyone besides you to see your data unless you release the key. Amazon is one of the only other cloud providers supporting customer managed keys, and I really hope this trend grows. But as Mike says, “Hope is not a strategy”, so vote with your dollars if you want more customer-controlled cloud key management. – RM

  4. Vulnerability management, still kicking…: I have voiced my disappointment with the fact that modern product reviews are consistently cursory, and rarely useful for procurement decisions. That doesn’t stop folks like SC Mag from continuing to review products, like their recent Vulnerability Management review. Yes, vulnerability management is still a thing – even if Gartner doesn’t think so anymore. That being said, the major players in the market are changing direction, and they all seem to be going in different directions. One is climbing the stack, another focused on identity, a third morphing into a services driven shop, and yet another preoccupied with executive level dashboards. And yes, they all still scan your stuff and generate long reports of stuff you’ll never get to. Same old, same old. Although as you are looking to renew your product and/or service, it makes sense to actually learn about the longer term strategy of your chosen vendor to ensure it still aligns with what you need. If not, make a change since it’s not like all of the vendors can’t scan your stuff. – MR

  5. Smart cards, disrupted: It’s happening again; the threat of EMV cards. The Smart Card Alliance position is the liability shift for not using EMV will push adoption within mass merchants, while Visa representatives claim 525 million cards will be in the ‘ecosystem’ by the end of 2015. Bull$#!*. For the sake of round numbers say there are about 300 million US citizens – minus those under 18 – which would require each US adult to get two Chip and PIN cards over the next 10 months. Even if the US government issues an ID for every citizen, that milestone is not going to happen. Nor will merchants move fast enough with new terminals to support the cards. I understand the smart card industry’s angst – EMV needs to move or be get over in the US. Apple Pay basically virtualized Chip and PIN for payments, simultaneously showing consumers a model for health and ID cards pushed into mobile devices with less cost and pain. It’s not a new idea by any stretch, but Apple upended a bunch of firms who were positioning for the future. As Apple does from time to time. – AL

  6. Eye of Sauron: Big breaches happen, and no matter what anyone tells you they aren’t going way… ever. The goal of your security program is to minimize the potential damage because it can’t be eliminated. Even with all the high-profile breaches, there’s a lack of motivation for companies, even in regulated industries, to protect their data. Everyone ignored the HIPAA security requirements for years and years, until HITECH put baby teeth in place. But heck, with entirely too many friends still in healthcare, even that threat isn’t enough to be a true catalyst for action. So I’m always interested in events that change the economics of security. Like one of the biggest insurance markets taking a close look at insurer cybersecurity. Nothing may happen here – it isn’t like Elliot Spitzer is back in charge, kicking ass and (er… spanking… no… not going to say it) taking names (no mention of black books either…), but it only takes a couple state regulators in the right markets to move the needle and drive change. – RM

—Mike Rothman

Monday, March 16, 2015

Firestarter: Cyber Cash Cow

By Rich

Last week we saw a security company hit the $2.4B valuation level. Yes, that’s a ‘B’, as in billion. This week we dig into the changing role of money and investment in our industry, and what it might mean. We like to pretend keeping our heads down and focusing on defense and tech is all that matters, but practically speaking we need to keep half an eye on the market around us. It not only affects the tools at our disposal, but influences the entire course of our profession.

Watch or listen:


—Rich

Tuesday, March 10, 2015

Take Control of Security for Mac Users

By Rich

I spend a lot of time on Apple security, more for personal reasons than anything else. They are the tools I use every day, and where I send most of my friends and family to manage their digital lives, so my investment runs deeper than anything financial. I have been the Security Editor over at TidBITS since about the time I founded Securosis, but I am not the only security expert over there. Joe Kissell has himself written books on the topic, and plenty of articles (mostly at TidBITS and Macworld).

Joe is currently writing a Take Control book on Mac security. The Take Control series of books are my favorite hands-on instructional guides, and I have used a fair few myself (Take Control is distinct from TidBITS, but closely related and run by the same team).

The first two chapters are available free online at TidBITS. The rest of the chapters become available to TidBITS members as Joe writes them. These books run much deeper than the white papers and articles we post on Securosis. The book a soup-to-nuts hands-on guide for nearly everything you need to know to secure your own Mac.

Joe and I have talked about combining efforts for a Securosis/Take Control cross-branded version of the content if we can line up a licensee/sponsorship. If you are interested drop me a line.

—Rich

Monday, March 09, 2015

Be Careful What You Wish For, It’s the SEVENTH Annual Disaster Recovery Breakfast

By Mike Rothman

2015 DRB, the be careful what you wish for edition

There seems to something missing for us Securosis folks now that it’s the beginning of March. After some reflection we realized it’s that dull ache in our livers from surviving yet another RSA Conference. The show organizers had to move the conference to April this year, to ensure a full takeover of San Francisco. Regardless of when the conference is, there is one thing you can definitely count on: the DRB!

That’s right – once again Securosis and friends are hosting our RSA Conference Disaster Recovery Breakfast. This is the seventh year for this event, and we are considering delivering a bloody head to Jillian’s in homage to Se7en. Maybe that wouldn’t be the best idea – it might ruin our appetites. Though given how big the DRB has become, we probably should consider tactics to cut back – we pay for insane amounts of bacon.

Kidding aside, we are grateful that so many of our friends, clients, and colleagues enjoy a couple hours away from the glitzy show floor and club scene that is now the RSAC. By Thursday, if you’re anything like us, you will be a disaster and need to kick back, have some conversations at a normal decibel level, and grab a nice breakfast. Did we mention there will be bacon?

With the continued support of MSLGROUP and Kulesa Faul, as well as our new partner LEWIS PR, we are happy to provide an oasis in a morass of hyperbole, booth babes, and tchotchke hunters.

As always, the breakfast will be Thursday morning from 8-11 at Jillian’s in the Metreon. It’s an open door – come and leave as you want. We will have food, beverages, and assorted recovery items (non-prescription only) to ease your day. Yes, the bar will be open – Mike gets very grumpy if a mimosa is not waiting for him on arrival (and every 10 minutes thereafter).

Remember what the DR Breakfast is all about. No marketing, no spin, just a quiet place to relax and have muddled conversations with folks you know, or maybe even go out on a limb and meet someone new. After three nights of RSA Conference shenanigans, we are confident you will enjoy the DRB as much as we do.

See you there.

To help us estimate numbers, please RSVP to rsvp (at) securosis (dot) com.

—Mike Rothman

SecDevOps Learning Lab at RSA

By Rich

We were invited to run a two-hour learning lab on a topic of our choice this year at the RSA Conference. I suspect it will surprise… no one… that we chose Pragmatic SecDevOps as our topic.

This is a cool opportunity – it gives us a double-length session to mix in presentation, hands-on labs, demonstrations, and group activities. I realize some people roll their eyes when they see these buzzwords, but everything we will present is being used in the real world, often at leading-edge organizations. DevOps really is a thing, it really does affect security, and you really can use it to your advantage in super interesting ways.

Here is the official description.

Pragmatic SecDevOps

Date & Time: Wednesday, April 22, 2015, 10:20am-12:20pm

Abstract: As cloud and DevOps disrupt traditional approaches to security, new capabilities emerge to automate and enhance security operations. In this hands-on session attendees will learn pragmatic techniques for leveraging cloud computing and DevOps for improving security. Through a combination of demonstrations and exercises we will work through a string of real-world security automations.

We are still finalizing what will make the cut but here are some components we are considering including:

  • An updated (and concise) Pragmatic SecDevOps presentation to start the conversation.
  • A lab to automate embedding host security agents in cloud deployments (e.g., Chef/Puppet) and then use them to enforce security policies.
  • A lab to monitor your cloud security management plane.
  • A group exercise to adapt and embed security architectures to leverage new cloud capabilities. This one is interesting because we will be showing off some leading-edge architectures we are starting to see for DevOps and cloud deployments, which not many security people have been exposed to.
  • A security automation group exercise/hands-on lab where we will give you a library of Ruby methods to mix and match for different security functions.

That is a ton of content, and we may not get to all of it. I will streamline some of the labs that I normally have people work through manually in training, but we need to push through more quickly.

You need to pre-register to attend, and we will run a webcast in the beginning of April so people can prepare and be ready to participate in the hands-on sections. One nice thing about the Learning Labs is that they happen during the main conference – not the day before or at the end of the week.

Please feel free to drop us ideas, preferences, or comments below. We already have a lot of the content, but how we piece it together is still very much open to suggestion.

—Rich

Friday, March 06, 2015

Friday Summary: More Cowbell

By Rich

Rich here.

Not to get too personal, but I had a dream about being back on ski patrol last night.

Of all the rescue things I did, ski patrol was one of the most satisfying. That probably sounds weird, because it means I was more satisfied picking up people who could afford $80 lift tickets than saving people in the inner city. But each activity brings a different kind of satisfaction, and when it comes to ski patrol, it was all about the independence.

I worked patrol part time at Copper Mountain for 5 years. We were pseudo-volunteers who would do everything full-timers did, except drive snowmobiles and throw bombs. Although some of us did get certified to drive (to ferry athletes and photographers at special events) and we could go out on avalanche control – just not light the boom-boom things.

Patrol is a physically demanding job. You don’t turn laps all day; if you aren’t on a work mission (fixing trail markers, setting safety gear, etc.), you hang out in one of the patrol buildings until you hear the dispatcher ring the cowbell. Yes, more cowbell. Someone would then snag the 1050 (injured person), get details, grab a rig (toboggan), and go find the patient.

It’s all solo after that. You ski (or in my case snowboard) to the patient, assess them, treat them, load them, and then take them to the base to either release or send to the clinic. Help is always available via radio if you need it, such as having a second person grab the tow line on the rig in really nasty conditions (usually a cross-slope traverse on ice), or if you hit CPR levels of badness, but otherwise it is a solo deal.

I loved working the back bowls. They were physically much tougher, but the environment was amazing. The main patrol building was called Motel 6, at around 12,000 feet. Just getting to it usually involved a hike. It wasn’t very large, but held a table, couch, and small kitchenette area. If you worked there, you wore an avalanche beacon and carried a shovel. Directly across the bowl from 6 was The Dumpster: two lift shack halves welded together with some crash pads on the floor and walls to sit on. Getting to The Dumpster took about 45 minutes and involved hiking the entire ridge around, topping out over 12,500’. The year I lived in Phoenix and flew back to work weekends… that hurt.

One of my most memorable calls was my first solo mission out of 6. Some guy injured his leg down near the bottom. Getting to him with the rig was easy, but getting out more complex. It involved multiple “Doo pulls”. Our snowmobiles were all Ski-Doos, and for a Doo pull, the driver would throw you a tow rope. You cannot safely tie it onto the rig, so you get in between the horns (handlebars) and wrap the end of the rope around one grip in such a way that it will only stay while you keep a firm hold on it. Then you handle steering. Fall, and you will probably get run over before momentum (or your head) stops the rig, after the rope drops off.

So I got towed out of the bowl, boarded the patient to my next pickup point, towed up to a better spot to reach the mountain base, and then followed the runs all the way down. It took well over an hour, on a hill I could ride top to bottom in under 10 minutes.

I don’t completely understand why this was so much more satisfying than working the ambulance or even a complex, multi-day mountain rescue. Perhaps because there are few cases in emergency services where you can honestly say you were responsible for saving someone. It is almost always a team effort, and real saves are rare. But on patrol I remember the time we were sweeping the hill at the end of the day and I found a girl who had just crashed on one of the big jumps. She wasn’t only unconscious, but she wasn’t breathing. I repositioned her head, opened her airway, and she was fine with a mild concussion.

My call. My patient. My strength and skills tested, with an expectation that I wouldn’t need help beyond the occasional tow if gravity wasn’t there to help. Teamwork is deeply satisfying, but it is also nice to know you can handle things yourself.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

—Rich

Monday, March 02, 2015

Firestarter: Cyber vs. Terror (yeah, we went there)

By Rich

Last week the US Director of National Intelligence said cyberattacks are a greater risk than terrorism. This week we debate what that means, and whether terminology is getting so muddled that it becomes meaningless. Plus we rip into Rich’s post claiming security people need to stop thinking of themselves as warriors, and start thinking like spies.

Watch or listen:


—Rich

Friday, February 27, 2015

Summary: You’re a Spy, not a Warrior

By Rich

Rich here.

These days it is hard to swing a cyberstick without hearing a cybergasp of cyberstration at the inevitable cyberbuse of the word “cyber”.

To be clear, I think ‘cybersecurity’ is not only an acceptable term, but a particularly suitable one. It is easy to understand and covers aspects of IT security the term “IT security” doesn’t quite describe as well. There are entire verticals which think of IT security as “the stuff in the office” and use other terms for all the other technology that powers their operations.

But snapping cyber onto the front of another word can be misleading. Take, for example, cyberwar and cyberwarrior.

We are, very clearly, engaged in an ongoing long-term conflict with a myriad of threat actors. And I think there is something that qualifies as cyberwar, and even cyberwarriors. Believe it or not, some people with that skill set work in-theater, under arms, and at risk.

But when you dig in this is more a spy’s game than a warrior’s battlefield. Defensive security professionals are engaged more in counterintelligence and espionage than violent conflict, especially because we can rarely definitively attribute attacks or strike back.

Personally, as Han Solo once said, “Bring ‘em on, I’d prefer a straight fight to all this sneaking around”, but it isn’t actually up to me. So I find I need to think as much in terms of counterintelligence as straight-up defense. That’s why I love some of the concepts in active defense, such as intrusion deception – because we can design traps and misdirection for attackers, giving ourselves a better chance to detect and contain them.

Admit it – you love spy movies. And while you probably won’t get the girl in the end (that’s a joke for whoever saw Kingsman), and you aren’t saving the world, you also probably don’t have to worry about someone sticking bamboo under your fingernails.

Until audit season.

I have some family in town and ran out of time to do a proper summary, so I shortened things this week.

Favorite Securosis Posts

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

—Rich

Wednesday, February 25, 2015

Cracking the Confusion: Encryption Decision Tree

By Rich, Adrian Lane

This is the final post in this series. If you want to track it through the entire editing process, you can follow along and contribute on GitHub. You can read the first post, and find the other posts under “related posts” in full article view.

Choosing the Best Option

There is no way to fully cover all the myriad factors in picking a specific encryption option in a (relatively) short paper like this, so we compiled a visual decision tree to at least get you into the right bucket.

Here are a few notes on the decision tree.

  • This isn’t exhaustive but should get you looking at the right set of technologies.
  • In all cases you will want secure external key management.
  • In general, for discreet data you want to encrypt as high in the stack as possible. When you don’t need as much separation of duties, encrypting lower may be easier and more cost effective.
  • For both database and cloud encryption, in a few cases we recommend you encrypt in the application instead.
  • When we list multiple options the order of preference is top to bottom.
  • As you use this tree keep the Three Laws in mind, since they help guide the security value of your decision.

Encryption Decision Tree

Once you understand how encryption systems work, the different layers where you can encrypt, and how they combine to improve security (or not), it’s usually relatively easy to pick the right approach.

The hard part is to then architect and implement the encryption technology and integrate it into your data center, application, or cloud service. That’s where our other encryption research can be valuable, and the following reports should help:

Rich, Adrian Lane

Ticker Symbol: Hack - *Updated*

By Gunnar

There is a ticker symbol HACK that tracks a group of publicly traded “Cyber Security” firms. Given how hot everything ‘Cyber’ is, HACK may do just fine – who knows? But perhaps one for breached companies (BRCH?) would be better. For you security geeks out there who love to talk about the cost of breaches, let’s take a look at the stock prices of several big-named firms which have been breached:

Sony 11/24/14 28.3%
S&P 500 11/24/14 2.2%
 
Home Depot 9/9/14 31.3%
S&P 500 9/9/14 6.4%
 
Target 12/19/13 23.8%
S&P 500 12/19/13 16.9%
 
Heartland 1/20/09 250.1%
S&P 500 1/20/09 162.7%
 
Apple 9/2/14 28%
S&P 500 9/2/14 6%

This is a small sample of companies, but their stock values have each substantially outperformed the S&P 500 (which has been on a tear in the last year or so) from the time of their breaches through now. “How long until activist investors like Icahn pound the table demanding more dividends, stock buy backs and would it kill you to have a breach?” Food for thought.

—Gunnar