Login  |  Register  |  Contact
Sunday, January 25, 2015

Applied Threat Intelligence: Defining TI

By Mike Rothman

As we looked back on our research output for the past 2 years it became clear that threat intelligence (TI) has been a topic of interest. We have written no less than 6 papers on this topic, and feel like we have only scratched the surface of how TI can impact your security program.

So why the wide-ranging interest in TI? Because security practitioners have basically been failing to keep pace with adversaries for the past decade. It’s a sad story, but it is reality. Adversaries can (and do) launch new attacks using new techniques, and the broken negative security model of looking for attacks you have seen before consistently misses them. If your organization hasn’t seen the new attacks and updated your controls and monitors to look for the new patterns, you are out of luck.

What if you could see attacks without actually being attacked? What if you could benefit from the experience of higher-profile targets, learn what adversaries are trying against them, and then look for those patterns in your own environment? That would improve your odds of detecting and preventing attacks. It doesn’t put defenders on an even footing with attackers, but it certainly helps.

So what’s the catch? It’s easy to buy data but hard to make proper use of it. Knowing what attacks may be coming at you doesn’t help if your security operations functions cannot detect the patterns, block the attacks, or use the data to investigate possible compromise. Without those capabilities it’s just more useless data, and you already have plenty of that. As we discussed in detail in both Leveraging Threat Intelligence in Security Monitoring and Leveraging Threat Intelligence in Incident Response/Management, TI can only help if your security program evolves to take advantage of intelligence data.

As we wrote in the TI+SM paper:

One of the most compelling uses for threat intelligence is helping to detect attacks earlier. By looking for attack patterns identified via threat intelligence in your security monitoring and analytics processes, you can shorten the window between compromise and detection.

But TI is not just useful for security monitoring and analytics. You can leverage it in almost every aspect of your security program. Our new Applied Threat Intelligence series will briefly revisit how processes need to change (as discussed in those papers) and then focus on how to use threat intelligence to improve your ability to detect, prevent, and investigate attacks. Evolving your processes is great. Impacting your security posture is better. A lot better.

Defining Threat Intelligence

We cannot write about TI without acknowledging that, with a broad enough definition, pretty much any security data qualifies as threat intelligence. New technologies like anti-virus and intrusion detection (yes, that’s sarcasm, folks) have been driven by security research data since they emerged 10-15 years ago. Those DAT files you (still) send all over your network? Yup, that’s TI. The IPS rules and vulnerability scanner updates your products download? That’s all TI too.

Over the past couple years we have seen a number of new kinds of TI sources emerge, including IP reputation, Indicators of Compromise, command and control patterns, etc. There is a lot of data out there, that’s for sure. And that’s great because without this raw material you have nothing but what you see in your own environment.

So let’s throw some stuff against the wall to see what sticks. Here is a starter definition of threat intelligence:

Threat Intelligence is security data that provides the ability to prepare to detect, prevent, or investigate emerging attacks before your organization is attacked.

That definition is intentionally quite broad because we don’t want to exclude interesting security data. Notice the definition doesn’t restrict TI to external data either, although in most cases TI is externally sourced. Organizations with very advanced security programs can do proactive research on potential adversaries and develop proprietary intelligence to identify likely attack vectors and techniques, but most organizations rely on third-party data sources to make internal tools and processes more effective. That’s what leveraging threat intelligence is all about.

Adversary Analysis

So who is most likely to attack? That’s a good start for your threat intelligence process, because the attacks you will see vary greatly based on the attacker’s mission, and their assessment of the easiest and most effective way to compromise your environment.

  • Evaluate the mission: You need to start by learning what’s important in your environment, so you can identify interesting targets. They usually break down into a few discrete categories – including intellectual property, protected customer data, and business operations information.
  • Profile the adversary: To defend yourself you need to know not only what adversaries are likely to look for, but what kinds of tactics various types of attackers typically use. So figure out which categories of attacker you are likely to face. Types include unsophisticated (using widely available tools), organized crime, competitors, and state-sponsored. Each class has a different range of capabilities.
  • Identify likely attack scenarios: Based on the adversary’s probable mission and typical tactics, put your attacker hat on to figure out which path you would most likely take to achieve it. At this point the attack has already taken place (or is still in progress) and you are trying to assess and contain the damage. Hopefully investigating your proposed paths will prove or disprove your hypothesis.

Keep in mind that you don’t need to be exactly right about the scenario. You need to make assumptions about what the attacker has done, and you cannot predict their actions perfectly. The objective is to get a head start on response, narrowing down investigation by focusing on specific devices and attacks. Nor do you need a 200-page dossier on each adversary – instead focus on information needed to understand the attacker and what they are likely to do.

Collecting Data

Next start to gather data which will help you identify/detect the activity of these potential adversaries in your environment. You can get effective threat intelligence from a number of different sources. We divide security monitoring feeds into five high-level categories:

  • Compromised devices: This feed provides external notification that a device is suspiciously communicating with known bad sites or participating in botnet-like activities. Services are emerging to mine large volumes of Internet traffic to identify such devices.
  • Malware indicators: Malware analysis continues to mature rapidly, getting better and better at understanding exactly what malicious code does to devices. This enables you to define both technical and behavioral indicators to search for within your environment, as Malware Analysis Quant described in gory detail.
  • IP reputation: The most common reputation data is based on IP addresses and provides a dynamic list of known bad and/or suspicious addresses. IP reputation has evolved since its introduction, now featuring scores to assess the relative maliciousness of each address. Reputation services may also factor in additional context such as Tor nodes & anonymous proxies, geo-location, and device ID, to further refine reputation.
  • Command and Control networks: One specialized type of reputation assessment which is often packaged as a separate feed is intelligence on Command and Control (C&C) networks. These feeds track global C&C traffic to pinpoint malware originators, botnet controllers, and other IP addresses and sites you should watch for as you monitor your environment.
  • Phishing messages: Current advanced attacks tend to start with a simple email. Given the ubiquity of email and the ease of adding links to messages, attackers typically find email the path of least resistance to a foothold in your environment. Isolating and analyzing phishing email can yield valuable information about attackers and their tactics.

What Has Changed

As you can see, we have had many of these data sources for years. So why are we talking about TI as a separate function? Because the increasing sophistication of attackers has driven change, which means you need to leverage more and better data to keep pace.

We started seeing more advanced security organizations staffing up their own threat intelligence groups a couple years ago. They are tasked with understanding the organization’s attack surface, and figuring out what’s at risk and most likely to be attacked. These folks basically provide context for which of the countless threats out there actually need to be dealt with; and what needs to be done to prevent, detect, and/or investigate potential attacks. These organizations need data and have been willing to pay for it, which created a new market for security data.

Another large change in the threat intelligence landscape has been the emergence of standards, specifically STIX and TAXXI, which enabled quicker and better integration of TI into security processes. STIX provides a common data format for the interchange of intelligence and TAXXI the mechanism & protocols to send it between originators and consumers of the data. Without these standards organizations needed to do custom integrations with all their active controls and security monitors, which was ponderous and didn’t scale.

So in this case standards have been a very good thing for security.

Addressing the Challenges

You just hit the EZ Button, gather some threat intelligence, and find the attackers in a hot minute, leaving plenty of time for golf. That sounds awesome, right? Okay, maybe it doesn’t work quite like that. Threat intelligence is an emerging capability within security programs. So we (as an industry) need to overcome a few challenges to operationalize this approach:

  • Aggregate the data: Where do you collect the intelligence? You already have systems that can and should automatically integrate intelligence, and use it within rules or an analytics engine. The more automation the better so resources can focus preventing attacks or figuring out what happened.
  • Analyze the data: How do you know what’s important within the massive quantity of data at your disposal? You need to tune your intelligence feeds and refine rules in your controls and monitors over time. As you leverage intelligence in your security program, you get a feel for what works and what isn’t so useful.
  • Actionable data: This takes TI to the next level, with tools automatically updating controls and searching your environment based on threat intelligence feeds. Potentially blocking attacks and/or identify attack indicators before the attacker exfiltrates your data. Existing tools such as firewalls, endpoint security, and SIEM can and should leverage threat intelligence. You will also want your forensics tools to play along, with the ability to leverage external intelligence.
  • False positives/false flags: Unfortunately threat intelligence is still more art than science. See if your provider can prioritize or rank alerts. Then you can use the most urgent intelligence earlier and more extensively. Another aspect of threat intelligence to beware is disinformation. Many adversaries shift tactics, borrowing from other adversaries to confuse you. That is another reason not to simply profile an adversary, but to cross-reference with other information to make sure that adversary makes sense in your context.

Now you have a decent idea what we mean by threat intelligence, so in the rest of this series we will focus on how TI can be used effectively in common use cases. These include security monitoring/alerting, incident response/management, and active security controls (both network and endpoint). So stay tuned – we will put this series on the fast track and post most of the research in short order.

—Mike Rothman

Friday, January 23, 2015

Summary: Grind on

By Rich

Rich here.

Last weekend I ran a local half-marathon. It wasn’t my first, but I managed to cut 11 minutes off my time and set PRs (Personal Record for you couch potatoes) for both the half and a 10K. I didn’t really expect either result, especially since I was out of running for nearly a month due to a random foot injury (although I kept biking).

My times have been improving so much lately that I no longer have a good sense of my race paces. Especially b cause I have only run one 10K in the past 3 years that didn’t involve pushing about 100 lbs of kids in a jog stroller.

This isn’t bragging – I’m still pretty slow compared to ‘real’ runners. I haven’t even run a marathon yet. These improvements are all personal – not to compare myself to others.

I have a weird relationship with running (and swimming/biking). I am most definitely not a natural endurance athlete. I even have the 23andMe genetic testing results to prove it! I’ve been a sprinter my entire life. For you football fans, I could pop off a 4.5 40 in high school (but weighed 135, limiting my career). In lifting, martial arts, and other sports I always had a killer power to weight ratio but lacked endurance for the later rounds.

While I have never been a good distance runner running has always been a part of my life. Mostly to improve my conditioning for other sports, or because it was required for NROTC or other jobs. I have always had running shoes in the closet, have always gone through a pair a year, and have been in the occasional race pretty much forever. I even would keep the occasional running log or subscription to Runners World, but I always considered a marathon beyond my capabilities, and lived with mediocre times and improvements. (I swear I read Runners World for the articles, not the pictures of sports models in tight clothes).

Heck, I have even had a couple triathlon coaches over the years, and made honest attempts to improve. And I’ve raced. Every year, multiple tris, rides, and runs a year.

But then work, life, or travel would interfere. I’d stick to a plan for a bit, get a little better, and even got up to completing a half-marathon without being totally embarrassed. Eventually, always, something would break the habit.

That’s the difference now. I am not getting faster because I’m getting younger. I’m getting faster because I stick to the plan, or change the plan, and just grind it out no matter what. Injured, tired, distracted, whatever… I still work out.

This is the longest continuous (running) training block I have ever managed to sustain. It’s constant, incremental improvement. Sure, I train smart. I mix in the right workouts. Take the right rest days and adjust to move around injuries. But I. Keep. Moving. Forward. And break every PR I’ve ever set, and am now faster than I was in my 20’s for any distance over a mile.

Maybe it’s age. Maybe, despite the Legos and superhero figures on my desk I am achieving s modicum of maturity. Because I use the same philosophy in my work. Learning to program again? Make sure I code nearly every day, even if I’m wiped or don’t have the time. Writing a big paper that isn’t exciting? Write every day; grind it out. Keeping up my security knowledge? Research something new every day; even the boring stuff.

Now my life isn’t full of pain and things I hate. Quite the contrary – I may be happier than I’ve ever been. But part of that is learning to relish the grind. To know that the work pays off, even those times it isn’t as fun. Be it running, writing, or security, it always pays off. And, for some of those big races, it means pushing through real pain knowing the endorphins at the end are totally worth it.

That, and the post-race beers. Hell, even Michelob Ultra isn’t too bad after 13 miles. Runner’s high and all.

Now I need to go run a race with Mike. He’s absolutely insane for taking up running at his age (dude is ancient). Maybe we can go do the Beer Mile together. That’s the one even Lance bailed on after one lap.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

  • Mike: Firestarter: Full Toddler – The disclosure battles heat up (again) and we wonder when someone is going to change Google’s diaper…

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts


Wednesday, January 21, 2015

Incite 1/21/2015: Making the Habit

By Mike Rothman

Over halfway through January (already!), how are those New Year’s resolutions going? Did you want to lose some weight? Maybe exercise a bit more? Maybe drink less, or is that just me? Or have some more fun? Whatever you wanted to do, how is that going?

If you are like most the resolutions won’t make it out of January. It’s not for lack of desire, as folks that make resolutions really want to achieve the outcomes. In many cases the effort is there initially. You get up and run or hit the gym. You decline dessert. You sit with the calendar and plan some cool activities.

Good habits are hard to break too...

Then life. That’s right, things are busy and getting busier. You have more to do and less to do it with. The family demands time (as they should) and the deadlines keep piling up. Travel kicks back in and the cycle starts over again. So you sleep through the alarm a few days. Then every day. The chocolate lava cake looks so good, so you have one. You’ll get back on the wagon tomorrow, right?

And then it’s December and you start the cycle over. That doesn’t work very well. So how can you change it? What is the secret to making a habit? There is no secret. Not for me, anyway. It’s about routine. Pure and simple. I need to get into a routine and then the habits just happen.

For instance I started running last summer. So 3 days a week I got up early and ran. No pomp. No circumstance. Just get up and run. Now I get up and freeze my ass off some mornings, but I still run. It’s a habit. Same process was used when I started my meditation practice a few years back. I chose not to make the time during the day because I got mired in work stuff. So I got up early. Like really early. I’m up at 5am to get my meditation done, then I get the kids ready for school, then I run or do yoga. I have gotten a lot done by 8am.

That’s what I do. It has become a routine. And a routine enables you to form a habit. Am I perfect? Of course not, and I don’t fret when I decide to sleep in. Or when I don’t meditate. Or if I’m a bit sore and skip my run. I don’t judge myself. I let it go.

What I don’t do is skip two days. Just as it was very hard to form my habits of both physical and mental practice, it is all too easy to form new less productive habits. Like not running or not meditating. That’s why I don’t miss two days in a row. If I don’t break the routine I don’t break the habit.

And these are habits I don’t want to break.


Photo credit: “Good, Bad Habits” originally uploaded by Celestine Chua

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.

Network Security Gateway Evolution

Monitoring the Hybrid Cloud: Evolving to the CloudSOC

Security and Privacy on the Encrypted Network

Newly Published Papers

Incite 4 U

  1. Doing attribution right… Marcus kills it in this post on why attribution is hard. You need to have enough evidence, come up with a feasible motive, corroborate the data with other external data, and build a timeline to understand the attack. But the post gets interesting when Marcus discusses how identifying an attacker based upon TTPs might not work very well. Attackers can fairly easily copy another group’s TTPs to blame them. I think attribution (at least an attempt) can be productive, especially as part of adversary analysis. But understand it is likely unreliable; if you make life and death decisions on this data, I don’t expect it to end well. – MR

  2. The crypto wars rise again: Many of you have seen this coming, but in case you haven’t we are hitting the first bump on a rocky road that could dead end in a massive canyon of pain. Encryption has become a cornerstone of information security, used for everything from secure payments to secure communications. The problem is that the same tools used to keep bad guys out also keep the government out. Well, that’s only a problem because politicians seem to gain most of their technical knowledge from watching CSI: Cyber. In the past couple weeks both Prime Minister Cameron in the UK and President Obama have made public statements that law enforcement should have access to encrypted content. The problem is that there is no technically feasible way to provide ‘authorized’ access without leave encryption technology open to compromise. And since citizens in less… open… countries use the same tech this could surrender any pretense of free speech in those areas as well. The next few years will be messy, and could very well have consequences even for average security Joes. There isn’t much we can do, but we sure need to pay attention, especially those of you on the vendor side. I know, not the funnest Incite of the week, but… sigh. – RM

  3. Nobody cares: If my credit card number is stolen I don’t bear the costs of the fraud and I am usually issued a new card within days to replace the old one. Lord knows I need to keep making card purchases, and nothing will stand in the way of commerce! So other than having to update the dozen web sites that require autopay why would I care about my card being stolen? The only answer I can discern is neurosis. Though apparently I am not alone – Brian Krebs’ How Was Your Credit Card Stolen? discusses the most common ways these numbers are harvested. My Boy Scout sense of fair play has prompted me in the past to put in the work to understand the fraud chain – twice – only to face subsequent frustration when neither local law enforcement nor the card brands cared. So, holiday shoppers, checking your credit statements is about all you can do to help. – AL

  4. More CISO perspective: I have been hammering on CISO-level topics for the past few weeks because folks still want to climb the ladder to get the big title (and paycheck). That’s fine, so I’ll keep linking to tips from folks in the field about how to sit in the top security seat. And then I’ll pimp the PragmaticCSO. Gary Hayslip provides some decent perspective on his 5-step process for the CISO job. It starts with “walk about” and then goes through inventory/assessment, planning, and communication. Seems pretty pragmatic to me. I like the specific goal of walking around for a certain amount of time every day. That’s how you keep the pulse of the troops. The requirements of the CISO job are pretty straightforward. Executing on them successfully? That’s a totally different ballgame. – MR

  5. Soft core payments: Google is reportedly looking to buy Softcard, presumably in an effort to kickstart their stalled mobile payment efforts. Google found that “If you build it they will come” only applies to bad Hollywood scripts – anyone can write a mobile ‘digital wallet’ app, but without cooperation from the rest of the ecosystem you won’t get far. The banks, payment processors, and (just as important) mobile carriers all have a stake in mobile payments, and will get their pound of flesh. For years the carriers have been unwilling to allow others to use the embedded “secure element” on phones for payments unless they got a transaction fee, which meant either pay the carrier tax or go home. Details are slim but Softcard is a carrier-owned business so apparently Google would get a carrier-approved interface to devices and the business relationships needed to make their payment app relevant again. – AL

  6. Bait bike: I’m a cyclist. Bicycle theft is a pretty big business, especially in cities and college towns. In the past few years some police departments have started planting GPS-enabled bait bikes in areas to catch the bad guys. They have done the same thing with cars, but it’s probably easier to plant a bike. That’s why I’m amused by the hackers for hire site. Need someone to break into your ex’s Facebook account? Steal that customer list? Just come on down to Billy Bob’s Trusted Hackers! Send us what’s left of your Bitcoin and we’ll hook you up with the most professional script kiddie in our network! Look, this probably isn’t a bait site, but now that it’s in the New York Times, what are the odds the FBI or Interpol isn’t already scanning the database, tracking clients, and prepping cases? We all know how this story is going to end: with jail time. – MR

—Mike Rothman

Monday, January 19, 2015

New Paper: Security Best Practices for Amazon Web Services

By Rich

I could probably write a book on AWS security at this point, except I don’t have the time, and most of you don’t have time to read it. So I wrote a concise paper on the key essentials to get you started – including the top four things to do in the first five minutes with a new AWS account.

Here is an excerpt:

Amazon Web Services is one of the most secure public cloud platforms available, with deep datacenter security and many user-accessible security features. Building your own secure services on AWS requires properly using what AWS offers, and adding additional controls to fill the gaps.

Never forget that you are still responsible for everything you deploy on top of AWS, and for properly configuring AWS security features. AWS is fundamentally different from a virtual datacenter (private cloud), and understanding these differences is key for effective cloud security. This paper covers the foundational best practices to get you started and help focus your efforts, but these are just the beginning of a comprehensive cloud security strategy.

The paper has a [permanent home]((https://securosis.com/research/publication/security-best-practices-for-amazon-web-services).

Or you can directly download the PDF.

I would especially like to thank AlienVault for licensing this paper. Remember companies that license our content don’t get to influence or steer it (outside of submitting comments like anyone else), but their support means we get to release it all for free.


Firestarter: Full Toddler

By Rich

Full Toddler

Yes, people, the disclosure debate is still alive and kicking. But now it is basically a pissing match between two of the largest tech companies. With Google setting rigid deadlines, and Microsoft stuck on their rigid schedule, who will win? Grab the popcorn as we talk about egos, internal inconsistencies, and why putting the user first is so damn hard.

Watch or listen below:


Friday, January 16, 2015

Summary: No Surprises

By Rich

Rich here,

First a quick note. I will be giving a webcast on managing SaaS security later this month. I am about to start writing more on the Cloud Security Gateway market and new techniques for dealing with SaaS.

I planned to write something irreverent in this week’s Summary (like my favorite films), but it has been an odd week in the security world. I expect the consequences to play out over the next decade. I should probably write this up as a dedicated post, but my thoughts are shifting around so much that I am not sure my ideas are ready to stand on their own.

Before I go into this, please keep in mind that the security ‘world’ is a collection of different groups. Tribes might be a better word. But across all subgroups we tend to be skeptical and critical. That is quite healthy, considering what we do, but can easily turn negative and self-defeating.

This is especially true when we engage with society at large. We are, on the whole, the pain-in-the-ass cousin who shows up at the holidays and delights in challenging and debating the rest of the family long past the point where anyone else cares. Yeah, we get it, you caught me in a logical fallacy because I like my new TV but bitched at you for not recycling your beer cans. You win. Now pass the stuffing and STFU.

Also factor in our inherent bias against anyone who does things others don’t understand. (Hat tip to Rob Graham for first introducing me to this concept). We have a long lineage that looks something like heretic > witch > egghead > nerd > geek > hacker. No, not everyone reading this is a hacker, but society at large cannot really differentiate between specific levels of technical wizardry. This is especially true for those of you who play with offensive security, no matter how positive your contributions.

Back to the main story, which is shorter than all this preamble. This week the White House proposed some updates to our computer security laws. Some good, some bad. The Twitter security echo chamber exploded a bit, with much hand-wringing over how this could lead to bad legal consequences – not only for anyone working legitimately in offensive security; it could also create all sorts of additional legal complexities with chilling effects.

There are actually a bunch of proposals circulating, which would affect not only cybersecurity but general Internet usage. From the UK wanting to ban encryption, to mandating DNSSEC, to the FBI wanting to ban effective encryption, to… well, everyone wanting to ban encryption, file sharing, and… stuff.

Many in the security world seem to feel we should have some say over these laws and policies. But we have mostly seen vendors lobby to have their products mandated (and then shrug when people using them get hacked), professional groups pushing to have their training or certifications mandated, and the occasional researcher treated like a dancing monkey for the cameras. And political leaders probably don’t see much distinction between any of these and the big Internet protests that their Hollywood funders all tell them are just criminals who want to watch movies free.

We have mostly done this to ourselves. We are fiercely independent, so it isn’t like we speak with a single voice. We can’t even decide what constitutes a “security professional”. Then we keep shooting ourselves in the foot by demanding evidence from law enforcement and intelligence agencies on things like the Sony hack. And, er, telling the FBI they are wrong rarely works out well.

I am not telling anyone not to do or say what they want. Just keep in mind how the world views you (as witches), and how much technology just scares people, no matter how much they love their iPhones. And if you want to affect politics you need to play politics. Twitter ain’t gonna cut it.

Seriously, no one likes that smarty-pants cousin (or in-law, in my case). And if any lobbyists are reading this, please fix the Kinderegg ban first, then get started on defending encryption.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

  • Mike Rothman: Your Risk Isn’t My Risk. It is always important to consider likelihood when looking at new attacks. Rich puts the latest in context.
  • Rich: Incite 1/14/2015: Facing the Fear. Because that was my only other choice. I mean, it’s still a good post, but it isn’t like I had an option.

Other Securosis Posts

And now you see why I had to pick Mike’s post.

Favorite Outside Posts

  • Adrian Lane: The importance of deleting old stuff. Honestly, it’s not as valuable as you think, and it is likely to cause harm in the long run.
  • Mike Rothman: The Stunning Scale of AWS. I remember Rich mentioning some of these stats after he got back from the AWS conference in 2013. It is shocking to see this documented, and to understand that when trying to really scale something… commercial products just won’t cut it. Really interesting.
  • Rich: Encryption is Not the Enemy. Dennis lays it out nicely, not that I expect the latest round of crypto wars to end any time soon.

Research Reports and Presentations

Top News and Posts


Wednesday, January 14, 2015

Incite 1/14/2015: Facing the Fear

By Mike Rothman

Some folks just naturally push outside their comfort zones as a matter of course. I am one of them. Others only do things that are comfortable, which is fine if it works for them. I believe that while you are basically born with a certain risk tolerance, you can be taught to get comfortable with pushing past your comfort zone.

For example, kids who are generally shy will remain more comfortable holding up the wall at a social event, but can learn to approach people and get into the mix. It’s tough at first but you figure it out. There is always resistance the first few times you push a child beyond what they are comfortable with, and force them to try something they don’t think they can do. But I believe it needs to happen. It comes back to my general philosophy that limitations exist only in our minds, and you can move past those limitations once you learn to face your fear.

Faces of Fear

The twins’ elementary school does a drama production every year. XX1 was involved when she was that age, and XX2 was one of the featured performers last year. We knew that she’d be right there auditioning for the big role, and she’d likely get one of them (as she did). But with the Boy we weren’t sure. He did the hip hop performance class at camp so he’ll perform, but that’s a bit different than standing up and performing in front of your friends and classmates. Though last year he did comment on how many of his friends were in the show, and he liked that.

We were pleased when he said he wanted to try out. The Boss helped him put together both a monologue and a song to sing for the audition. He knew all the words, but when it came time to practice he froze up. He didn’t want to do it. He wanted to quit. That was no bueno in my book. He needed to try. If he didn’t get a part, so be it. But he wasn’t going to back out because he was scared. He needed to push through that fear. It’s okay to not get the outcome you hope for, but not to quit.

So we pushed him. There were lots of tears. And we pushed some more. A bit of feet stomping at that point. So we pushed again. He finally agreed to practice for us and then to audition after we wore him out. Sure, that was a little heavy-handed, but I’m okay with it because we decided he needed to at least try.

The end result? Yes, he got a part. I’m not sure how much he likes the process of getting ready for the show. We’ll see once he gets up on stage and performs for everyone whether it’s something he will want to do again. But whether he does it again doesn’t matter. He can always say he tried, even when he didn’t want to. That he didn’t let fear stop him from doing something. And that’s the most important lesson of all.


Photo credit: “Faces of fear!” originally uploaded by John Seb Barber

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.

Security Best Practices for Amazon Web Services

Network Security Gateway Evolution

Monitoring the Hybrid Cloud: Evolving to the CloudSOC

Security and Privacy on the Encrypted Network

Newly Published Papers

Incite 4 U

  1. Full discraposure: Google discovers a bug in a Microsoft product. Google has a strict 90-day policy to disclose, no matter what. Microsoft says, “Hey, we have a fix ready to go on Patch Tuesday, can we get a few extra days?” but Google releases anyway. I’m sorry, but who does that help? Space Rogue summed it up best; he has a long history in the disclosure debate. In his words, “The entire process has gotten out of hand. The number one goal here should be getting stuff fixed because getting stuff fixed helps protect the user, it helps defeat the bad guys and it helps make the world a better place.” Another great quote is: “And so the disclosure debate continues unabated for over a hundred years. With two of the giants in our industry acting like spoiled children we as security professionals must take the reigns from our supposed leaders and set a better example.” Marry me, Space Rogue. Marry me. – RM

  2. The impact of Sony in 2015? FUD! Okay, I am being a little facetious by saying the Sony breach will enable the security industrial complex to launch a new wave of Fear, Uncertainty, and Doubt at organizations in 2015. But it already has folks using tried and true tactics in an attempt to create urgency for whatever widget they are selling today. Ben Rothke is a little more constructive in his analysis for CSO. He makes some good points about the reality that improving security requires ongoing investment and that shiny security products/services are not a complete answer. The one I like best is “a good CISO is important; great security architects are critical.” Amen to that. We believe that as security increasingly gets embedded within the cloud and continuous deployment environments, the security architect will emerge as one of the most valued members of the team. So study up on your architecture, kids! – MR

  3. Making the effort: Gunnar has another really good post, challenging folks to think differently about security. It’s very popular to accept defeat because the odds are stacked against defenders. To mail it in because you will be pwned anyway. And that much is true. You can make progress, but only if you make the effort to improve. Always quick with good analogies, GP refers to how smog was reduced in Los Angeles by 98% over the past 50 years, which most thought was impossible 60 years ago. And how the Scandinavian countries don’t have airplane delays because of snow. They just don’t because they made the effort to figure out how to optimize their processes. I guess another way to put it is a quote I use frequently: “I’m not in the excuses business.” And neither is your senior management, so as Gunnar says: “There is a lot to do, can’t get started any sooner than right now. No such thing as bad winter weather, only opportunities to improve bad snow removal equipment, dysfunctional teams and processes.” Truth. – MR

  4. Free, as in crapware: I seem to have a ‘crap’ theme for my submissions this week. A couple of writers over at HowToGeek decided to go to CNET’s Downloads.com [no link, for obvious reasons and obviousness] to see what happens if they download and install the top 10 apps listed. Hilarity ensues. Spyware, ads, browser hijackers, and more… all from a site that claims its downloads are safe. I frequently see links to these sorts of sites when I search for an application. Sometimes search engines show these contaminated links before the software developer’s site. This is especially common when I look for anything more obscure or no longer maintained. I never download from those sites and I’m on a Mac, but this highlights the ridiculous dangers facing normal Windows users (including your employees). Needless to say, this is why I’m a fan of app stores for PCs, even the open ones (where stuff can still sneak through). I suspect Microsoft will need to move in that direction for the same reasons Apple did, and kill the economic model of bundling and installing backdoors. As long as I always still have the option to go outside the store, I am down with it. – RM

  5. You want a seat, Mr./Ms. CISO? Good luck. I wanted to dig into the archives a bit to mention research that confirms what many of you already know. CISOs are not considered players at the big table. ThreatTrack commissioned a study last summer and came away with some disturbing numbers. 74% of respondents said CISOs should not be part of the organization’s leadership team. 54% don’t think CISOs should be responsible for security purchasing. 28% say the CISO’s decisions negatively impacted financial health. Holy crap! It’s time for a reality check. This is clearly a failure to communicate with folks in senior management. And it needs to be fixed ASAP. It is not like we are going to see fewer attacks or breaches, so if these folks don’t understand what you do and why, that needs to be job #1. Or polishing up your resume will be job #2. – MR

—Mike Rothman

Tuesday, January 13, 2015

Your Risk Isn’t My Risk (Apple Thunderbolt Edition)

By Rich

Last Friday I wrote an article on the Thunderstrike proof of concept attack against Macs. I won’t spend any more time analyzing it but I think it’s valuable as an example of risk assessment.

The short version is… it’s a creative attack that, if you have physical access to a Mac, could allow you to completely compromise it by merely connecting external hardware and triggering a reboot. The attack is against the firmware, and even removing the Mac’s hard drive leaves it infected.

The Thunderstrike proof-of-concept takes advantage of this trust to replace the contents of the Mac’s boot ROM with the attacker’s own code, effectively embedding it into the Mac’s hardware and making it impossible to remove using standard techniques. The attack works because Apple relies on software checks to confirm the firmware is valid, and Hudson developed techniques to circumvent those checks (and even replace the encryption key).

Apple is taking this seriously; it is already fixed on new hardware (Retina iMacs and new Mac Minis), and a further fix for older hardware is coming soon according to my sources (sooner than you probably think). But that is only a partial fix because an attacker can still downgrade the firmware and then execute the attack, although that doubles the time requirement.

In my article I made clear that very few people need to worry about this now:

While all Macs are technically vulnerable to the Thunderstrike attack, few TidBITS readers face any immediate risk. The attack is highly targeted – someone needs both physical access to your Mac and time to reboot it and reinstall the firmware. On top of that, it isn’t like everyone is walking around with maliciously modified Thunderbolt dongles.

So why write it up? Why talk about an attack that has to be designed for the specific hardware version you are using, requires physical control of your device, and can’t realistically spread on any wide basis?

Because I’m at risk, as are many readers here at Securosis.

For the TidBITS crowd I mostly wanted to assuage concerns and compensate for the usual spate of over-hyped stories. For Securosis? Some of you need to worry. I have direct reports of executives and security pros being compromised when their hardware leaves their control; typically when traveling internationally, usually to one of a few countries. (Make that mostly one country).

BTW, I don’t have any reports of these attacks on Macs, and I am very interested if you have a confirmed report, even if you can’t provide details.

Starting in about 2008 I started paying a lot more attention to physical control over my computers and mobile devices under certain circumstances (I am not counting hacker conferences – I have always kept hard control at those). The reports coming in from clients indicated that customs and hotel rooms were not safe places to lose physical control. I even stopped traveling to China with devices I was worried about, which did inhibit my ability to get work done while there.

Thunderstrike itself isn’t a big deal. It’s super interesting, but damn low on the risk list.


As a proof of concept it is incredibly educational, and some of you, especially readers of this site, need to pay attention to these kinds of attacks (for yourselves or your organizations). That’s why I like this story as a good example of understanding risk. For one publication, TidBITS, I wrote it up to debunk fear. For another, here, I am writing it up as a warning of real risk, if you fall into the right bucket. [Ed: The presentation is also remarkably readable – much easier to understand than I expected for something this complicated. –cp]


Sunday, January 11, 2015

Friday Summary: Favorite Films of 2014 (Redux)

By Rich

Rich here. Something went wonky so most of the Summary didn’t load properly on Friday. So I am reposting with the lost content…

The Securosis blog has been around since 2006, with pretty much constant posts over that entire time (multiple posts a week, with a few exceptions). That is a lot of words, a large percentage of which came through my keyboard.

We have always used the Summary (and when Mike joined, the Incite) to add some color to our security coverage, and give glimpses into our personal lives, or random thoughts that don’t really fit in a security-oriented blog post. I will expand on that in some posts this year, starting today with a post on my favorite films of 2014. Yep, you heard me, and you can skip to the Summary itself below if you just want the top links and news of the week.

Favorite Films of 2014

These aren’t necessarily the best movies of the year – not even close – but the ones I most enjoyed. My wife and I are huge film buffs, but since having (3 young) kids we dropped from seeing movies near weekly, to monthly if we are lucky. This changed our tastes because due to constant exhaustion we are more likely to pick something light and fun than arty and independent (we still watch those, usually over 2 nights, at home).

Top Films I Saw in a Theater

Guardians of the Galaxy: Flat out, the most fun I had in a theater all year. I saw it twice, then bought the Blu-Ray (3D with digital copy) for home. Some consider comic book films the death of ‘serious’ movies, but as we transition deeper into the digital age spectacles like this will sustain movie theaters and allow more serious films to still show in the smaller rooms at the back of the megaplex.

Captain America: The Winter Soldier: Almost my #1 pick because this one elevated the ‘classic’ comic-book genre film. Its comments on society were heavy-handed but the timing was perfect – especially if you know what’s coming in the Civil War storyline. But what really hooked me were the effects and character of Cap himself. His movements, style, and pure kinesis made even the Avengers action scenes look pedestrian.

Gravity: I love space. I went to Space Camp three times as a kid (and considering our limited household income, that was more than a big deal). The science may have been way off in parts, but the immersive 3D IMAX experience was incredible. And the tension? Oh, the tension! It makes me almost want to cry that I missed seeing Interstellar on an IMAX screen.

Favorite Film Most of You Skipped

Edge of Tomorrow: This did poorly in the theaters, and we only watched it on an iPad at 35,000 feet ourselves, but I immediately bought the book on my Kindle when we landed. If you have ever ground out a level in a video game this is the movie for you. If you want to see Tom Cruise die, a lot, this is the movie for you. If you want to see the best time-travel film since Looper… you know the rest. And definitely read the book.

The One We Loved Until Our iTunes Rental Expired

The Grand Budapest Hotel: I have the Blu-Ray from Netflix sitting here so we can watch the last 20 minutes. But unless they completely suck this was Wes Anderson at his best. Amazing style, characters with panache, and his usual visual splendor.

The One I Enjoyed, but Really Didn’t Get As Much As Anyone Else

Snowpiercer: I get it, Bong Joon-Ho is awesome and Tilda Swinton just nailed it, but I still don’t understand why this made so many Top 10 lists. It was good, but not that good.

My Favorites with the Kids

Our girls are finally old enough to sit through and enjoy a movie with, and this was an awesome year to bond in a theater (or with a rental).

The Lego Movie: I really really really wish we had seb this in the theater, instead of on video, but we all loved it. Our dining room table has been covered in Legos for months, and I don’t expect that to change anytime soon. The message hit the perfect tone of “be creative, but sometimes you still need to listen to your damn parents so you don’t die a tragic death!” Maybe I’m projecting, a little.

How to Train Your Dragon 2: Oh, wow. Even on a smaller 3D TV at home this is still amazing (we did see it in a theater first). It goes where few kids films have the balls for any more, putting you on an emotional roller coaster with plenty of spectacle. I really love this series, and will be sad when it ends with the next one.

Big Hero 6: Another one full of emotion, evoking classic Disney themes in a fully modern, comic-book tale. It could have gone horribly wrong and is far from perfect, but the kids loved it, we enjoyed it, and the visual design is truly special. I wouldn’t place this up there with The Incredibles, but it really shines is creating bonds between the audience and the main characters.

Favorite Comedy

Neighbors: I enjoyed 22 Jump Street, but Neighbors had a few scenes that floored me. Let’s be honest – I am at a stage of life where I can appreciate a hangover + full boobs joke more than when I was 20 or 30.

The One I Will Only See in Private

Boyhood: I have kids. I’m going to cry. Screw you if you think I’m doing that in a theater.

The Best Movie to See While Hopped up on Painkillers after… Guy Surgery

G.I. Joe: Retaliation: Not much else to say. I dare you to refute.

There are a lot of other films I enjoyed, especially Dawn of the Planet of the Apes, but these were my overall favorites. There were also a lot of films I missed, most of which I keep on a list for later rental. I’m also sure I’m forgetting some, but there you have it. I may cover television in a later post, which will be interesting because I timeshift everything I watch, and some shows haven’t even been on the air for a year or more.

On to the Summary:

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

Skipping this week since we are just back to the office, and don’t have enough posts to pick from.

Other Securosis Posts

Favorite Outside Posts

  • David Mortman: Tech Super Women.
  • Mort (again): It’s Usability All the Way Down
  • Mike Rothman: Hack Yourself First. Great post by Jeremiah Grossman about the need to test your stuff. Before the adversary (nation state or not) does it for you…
  • Mike Rothman: Scaling CloudFlare’s WAF. We joke about “Internet scale,” but some organizations actually need to think about scalability different. Interesting post here about how CloudFlare does some filtering of the inbound traffic on the websites they protect.
  • Adrian Lane: Sony Breach Linked to …. This is awesome. Don’t like the answer? Click refresh and get the one you want, complete with details to back up your assumption.
  • Rich: How Lego Became the Apple of Toys. I admit I have a bit of a Lego problem, but I love stories on creating quality.

Research Reports and Presentations

Top News and Posts


Wednesday, January 07, 2015

Incite 1/7/2014: Savoring the Moment

By Mike Rothman

Early December is a big deal in our house. It’s Nutcracker time, with both girls working all fall to get ready for their dance company’s annual production of the Xmas classic. They do 5 performances over a weekend, and neither girl wants it to end. We have to manage the letdown once that weekend is over. It has been really awesome to see all of the dancers grow up, via the Nutcracker. They start as little munchies playing party boys and girls in the first scene, and those who stick with it become Dew Drop or possibly even the Sugarplum Fairy.

The big part for XX1’s group this year was Party Clara. It’s on Pointe and it’s a big and featured role in Act 1. She has been dreaming about this part for the past 4 years, and when we heard she got it for one of the performances this year, we knew it was going to be a special Nutcracker. She also got a featured Rag Doll part for another performance and was on stage 4-5 times during the show.

XX2 wasn’t left out, and she got a number of featured parts as well. I used to dread that weekend but the girls didn’t really do much, so I could get away with going to one performance and being done with it. Now I attend 3 out of the 5 performances, and would go to all 5 if the girls had sufficient parts. I’m pretty sure the Boy wouldn’t be happy going to 5 performances, but he’ll get over it. I even skipped a home Falcons game to see the Sunday afternoon performance (I did!).

Savor the moment

One of the things I am working on is to pause during the big stuff and just enjoy it. You could call it smelling the flowers or something like that. For me it’s about savoring the moment. To see XX1 with a grin ear to ear performing as Party Clara was overwhelming for me. She was so poised, so in command, so happy. It was incredible. During those 3-4 minutes the world fell away. There was only my girl on stage. That’s it.

Some folks watch their kids perform through a camera viewfinder. Or a cellphone screen while taking video. Not me. I want to experience it directly through my own eyes. To immerse myself in the show. I want to imprint it in my memory. Yes, we’ll buy the DVD of the performance, but that’s for the folks who weren’t there. I don’t need it. I was fully in that moment, and I can go back any time I want. And I do.


Photo credit: “P1-VS-P2” originally uploaded by MoreInterpretations

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.

Security Best Practices for Amazon Web Services

Network Security Gateway Evolution

Monitoring the Hybrid Cloud: Evolving to the CloudSOC

Security and Privacy on the Encrypted Network

Newly Published Papers

Incite 4 U

  1. Security deadly sin: offensive envy: I dug up Richard Bejtlich’s awesome post from right before New Year, where he dismantles a list from Microsoft’s John Lambert and calls him out for minimizing the potential of defensive security. It is true that hacking stuff is sexy, and the chicks & dudes dig it. But still, the fact that many defenders work off checklists doesn’t mean all do. Because the defenders seem to come up on the losing end of some breach every day doesn’t mean their efforts are pointless. It means it’s a hard job, pure and simple. And glorifying the adversary only provides a defeatist attitude before you even start playing. Which I guess is the adversary’s plan… – MR

  2. No hands: I just love it when someone comes up with an entire class of security vulnerability – and if it might affect an Apple product guess what’s in the headlines? Like the general GSM wireless issue that was hyped as “iPhones Vulnerable” (every GSM phone was vulnerable). That hype sometimes does the issue a disservice, as highlighted in this piece at the Huffington Post on Jan Krissler recreating thumbprints from normal photographs at the Chaos Computer Club. It’s a fascinating and brilliant idea as we progress towards ubiquitous high-definition cameras throughout the world. Not merely for hacking phones, but for all the CSI-spinoff episodes it will inspire. Practically speaking, today I think the barriers to successfully executing this attack are high enough to keep this from becoming a major issue now, and anyone in a sensitive position should never rely on biometrics alone, but in 10 or years? Oh, and don’t forget to read the bit at the end about researchers pulling pass codes from over 100 feet away via screen reflections in someone’s eye via high def video. – RM

  3. Leadership: I think I was too young to understand what the term ‘leadership’ meant when I was promoted to CTO for the first time. Blindly stepping into a role I knew nothing about, I was blessed with a CEO who did not mince words: “If I catch you coding again, you’re fired!” That forced me to focus on the CTO job, which was leading the development team – communicating vision and providing direction on how we were going to deliver product. Over at Security Uncorked JJ wrote a thought-provoking piece on the mental challenges of changing – or even expanding – one’s role in Infosec. Releasing your grip on the hands-on work that got you where you are today is not easy. It’s not just learning leadership and management skills, but also giving up many things you enjoy in your current job. No college offers a “Security Leadership and Management 101” course, and as a new profession we don’t have that many resources to draw on. Bravo to JJ for sharing the angst of this transition. – AL

  4. In the real world, it depends… Wendy kills it again, pointing out that compliance is a pretty low bar, highly dependent on the competence of the assessor and with “the(ir) ability to measure objectively, not just answer questions.” A control can be implemented in such a way that it fails to protect anything. And the process may be in place, but if no one uses it, who cares? This isn’t really about maligning compliance (again), but the fact that prescriptive lists in mandates must be considered the lowest of low bars; once they are taken care of you can start really thinking about how to protect your stuff. So is compliance even helpful? Well, it depends… – MR

  5. Unintended consequences: If I were to redirect cellular tower traffic or interfere with cell transmissions, I would be prosecuted and go to jail for a very long time. If it’s illegal for me, shouldn’t law enforcement need a warrant to do it? The FBI says ‘No’: search warrants are not needed to use ‘stingrays’ in public places to perform mass surveillance of voice and data traffic on everyone in the area. Our government is spurring an interest in security I never thought would make the mainstream. Accusations like monitoring a CBS journalist – true or not – are so creepy that they will keep this story in the limelight for a while. Even at the giant Consumer Electronics Show in Vegas this week, vendors are competitively positioning consumer products with security features, and the keynote touched on the Sony hack. We are moving into a culture of digital security. Whodathunk that a few years ago? – AL

  6. Airway. Breathing. Cyberattack. As a geek and paramedic I became involved fairly early in healthcare IT. I still remember almost being fired for hacking into our manager’s computer because he accidentally locked us out of an important application that was only on his PC but required for our job, and he wouldn’t answer his landline or pager (yeah, I’m dating myself). Nothing fancy – I just found his password for the app in a plain text file via legit access we already had. Anyhow… Pre-Gartner I helped design an EMR app (and implement it in a clinic) for replacing dictation. I also have some more recent experience due to family connections in the industry. So it was no surprise to read Jack Daniel’s story of witnessing multiple hospital IT failures while visiting friends. Forget about security – this is an industry with massive structural issues in IT management. The situation is so much worse than you think, and despite all the security headlines fundamental reliability will consume healthcare dollars for a long time. Hop over to any healthcare forum (especially the physician ones) to see how bad things are, and be glad your providers would all prefer to go back to paper charting and orders in the first place. – RM

  7. The other EMET: I’m a football head, so when I hear the name “Emmitt” I always think of those times Emmitt Smith ran into the end zone to finish off the Giants as I was growing up. But I’m not talking about that Emmitt. I’m referring to EMET, Microsoft’s Enhanced Mitigation Experience Toolkit, which should be implemented on all your Windows devices. And it’s good that TrustedSec’s Dave Kennedy found some time (when he wasn’t hugging it out with the entire industry) to document how to install EMET. Is EMET perfect? Of course not. But it definitely makes it much harder to compromise Windows devices, so you should have it in your anti-malware toolkit. Yes, there are other cool technologies emerging to help on endpoints, but EMET is free, so why not use it? – MR

—Mike Rothman

Friday, December 19, 2014

Summary: That’s a Wrap!

By Rich

Rich here,

Holy crap, what a year!

I have been in the security business for a while now. I wouldn’t say I am necessarily jaded, but… yeah. Wow.

First, the news. This was the year of Target and Sony. Symantec finally breaking up. All sorts of wacky M&A. The year family members checked in for the first time in decades, after reading my quotes in articles with “celebrity nudes” in the headlines. Apple getting into payments. My guidance counselor totally left that out when we discussed infosec as a career option.

Not that infosec was a career option in the late 80’s, but I digress.

As I have often said, life doesn’t demarcate itself cleanly into 365 day cycles. There is no “year of X” because time is a continuum, and events have tendrils which extend long before and after any arbitrary block of time. That said, we will sure as hell remember 2014 as a year of breaches. Just like 2007/2008, for those who remember those ancient days. It was also a most excellent year for general security nonsense.

Then there was the business side. 2014 was an epic year for Securosis on every possible level. And thanks to the IRS and our fiscal year being the calendar year, we really do get to attribute it to 2014. We cranked out a bunch of papers (mostly Mike) and engaged in some insanely fun projects (mostly me). A year or so ago I wasn’t sure there was enough of a market for me to focus so much of my research on cloud and DevOps. Now I wonder if there’s enough of me to support all the work.

We were so busy we didn’t even get around to announcing a new research product: Securosis Project Accelerators. Focused workshops for end users and (for now) SaaS providers tied to specific project initiatives (like our Cloud Security for SaaS Providers package). On the upside, we sold a bunch of them anyway.

The main thing that suffered was this blog. We mostly kept up with our scheduled posts and open research, but did drop a lot of the random posts and commentary because we were all so busy. I wish I could say that’s going to change, but the truth is 2015 looks to be even busier.

Personally this has been my favorite work year yet, due to the amount of primary research I have been able to focus on (including getting back to programming), working more with end-user organizations on projects, and even getting to advise some brand-name cloud providers on technical aspects of their security.

I am not sure whether I mentioned it on the site, but my wife stopped working after RSA due to an acute onset of “too many children”. We decided it was no longer worthwhile for both of us to work full time. And changes in the healthcare system meant we were no longer so reliant on her employee benefits. That reduced a lot of home scheduling stress, but also meant I was short on excuses to stay off airplanes. I was definitely away from home a lot more than I liked, but when I am home, I get to be far more engaged than a lot of parents.

On the non-work front it was also an awesome year. We are done with babies (but not diapers), which means we are slowly clawing back some semblance of a life outside being parents. Our older two started in public school, which is like some kind of fantasy after years of paying a prison company to keep our children mostly alive and intact (daycare… shudder). We spent a month in Boulder, a week in Amsterdam, and a weekend in Legoland. I am running as fast as I was in my 20’s, over longer distances, and I am almost not embarrassed on the bike. (Remember, triathlon is latin for “sucks at three sports”).

So on the overall good/bad scale I would mark 2014 as “awesome”. Mostly because I don’t work for a retailer or a film studio.

And, without going into details, 2015 has some serious potential for epic.

As I like to do every year before we close down for the holidays, I would really like to thank all of you for supporting us. Seriously, we are 3 guys and a half-dozen friends with a blog, some papers, and a propensity to sit in front of webcams with our clothes on. Not that many people get to make a living like this, and we can only pull it off due to the tremendous support you have all given us for over 7 years.

I may not be religious but I sure am thankful.

On to the Summary (our last this year):

Webcasts, Podcasts, Outside Writing, and Conferences

Favorite Securosis Posts

  • Mike Rothman: Firestarter: Predicting the Past. I can only hope you had half as much fun watching as we had recording the year-end FS. That’s right vendors – think twice before making those predictions. Even if you’re our friends, we will still call you out!
  • Rich: Ditto. Natch.

Other Securosis Posts

Favorite Outside Posts

Research Reports and Presentations

Top News and Posts

And a major one for us DevOps types:

Blog Comment of the Week

This week’s best comment goes to Ilia, in response to Firestarter: Predicting the Past..

There is a grain of joke in every joke ;-) As freaky as it sounds, wifi connected light bulbs were hacked already – as a proof of concept so far, but the folks from Contextis explain how they could steal home WiFi credentials via light bulbs: http://contextis.co.uk/resources/blog/hacking-internet-connected-light-bulbs/

(Disclosure: yes, I work for the guys you’ve never heard of. And yes we’re working to fix that.)



Security and Privacy on the Encrypted Network: Selection Criteria and Deployment

By Mike Rothman

Our Use Cases post ran through setting policies for decryption, and specific use cases driving decryption of network traffic. We also brought up human resources and compliance considerations when building policies. But that doesn’t address the technical nuances of actually figuring out where to decrypt, or how to select and deploy the technology, so here we go. First let’s talk a bit about whether you need a standalone device.

Standalone or Integrated?

Many network and security devices can terminate and decrypt network sessions – including firewalls, IPS, load balancers, UTM, and web & email security gateways. Obviously using an existing device is simpler, often the path of least resistance for decryption and inspection. You don’t have to add other boxes or risk messing up your network addressing scheme, and you can enforce policies right at the point of decryption/inspection. A security device can decrypt traffic, inspect it, apply policy, and re-encrypt – all within a single product. For environments with minimal network volumes and simple policies, integrated devices work well.

But those who need to decrypt substantial network traffic tend to quickly crush the performance of existing security devices if they try to decrypt on existing devices. As we mentioned in our last post, onboard decryption may reduce performance of security devices by 33% to 80%. If you have plenty of performance headroom on your security devices that’s OK. If you don’t you need to look at another device to offload decryption load, in order to let your security devices do what they do best: inspect traffic, apply policies, and monitor or capture traffic.

If you deploy complicated policies, such as multiple policy triggers across the entire network stream rather than limiting yourself to port 443 (HTTPS), an integrated device’s relatively simple decryption policies may be insufficient. Additionally, if you need to send decrypted traffic to multiple places, such as a SIEM or network packet capture device, an integrated solution may not be a good fit.

We have nothing against the integrated option, but pragmatism and drives us toward the right tool for the job. If onboard decryption can meet your performance and policy requirements, do it. But if not you likely need a standalone decryption device.

Selection Criteria

Once you have decided to use a dedicated decryption device, what should you look for? Here are a few things to think about:

  • Performance: Much of the value of dedicated hardware is its ability scale up with traffic volume. Make sure any device or devices you buy can scale to your current and future volumes. Don’t paint yourself into a corner by buying equipment that will need to be replaced when traffic volume grows.
  • All Port Support: One of the easiest evasion techniques for attackers is to simply change the port number of their outbound traffic, sending encrypted traffic where it is not expected or monitored. Inspection devices cannot afford to trust port numbers – you need deep packet inspection looking at payloads to detect evasion.
  • Accuracy: Decryption strategy is highly policy dependent, so success requires accurate categorization of traffic. Related to looking at the full traffic stream, you need to ensure your devices accurately find encrypted traffic and categorize it effectively.
  • Policy actions: Once you have a policy hit, make sure your device supports a variety of different actions. You should be able to decrypt, not decrypt, drop the session, or reject the session (with a website failure code). You also want the ability to list sources or destinations as always decrypt (blacklist) or never decrypt (whitelist), by group or user.
  • Website category/reputation support: A big chunk of our use case post talked about setting policies; they may include websites, IP addresses, and applications. Given how quickly website reputation and categories change (minutes – if not seconds), it is important to have a dynamic source of current information to base policies on. That usually means some kind of cloud-based website categorization service for whitelisting, along with dynamic reputation scoring for websites and applications.
  • Multiple device support: Given the varied decryption use cases, these devices should be flexible in how they forward traffic, and to how many devices. For example you might want to send traffic to both an IPS for active control, and also a packet capture device for monitoring and forensics. It is also important for decryption devices to interoperates natively with security devices, so that (for instance) an IPS which detects decrypted attack traffic can drop that session without human intervention.
  • Security: This is a security device, so you will want to ensure that decryption/resigning keys and data on the device are protected. You also want the ability to reject/drop sessions if their security is insufficient. For example a weak encryption cipher could data at risk; it might be forbidden to transmit encrypted data which cannot be decrypted by the security device, to prevent unknown data from leaving your environment.
  • Transparency: It is also important to ensure decryption doesn’t impact application behavior or user interaction. End users should not need to concern themselves with security inspection. Further, the decryption device shouldn’t alter packet headers in any way, as that might impair other security devices’ inspection. Basically, nobody should know the device is there.
  • Deployment flexibility: Decryption needs to be inserted into the flow of traffic, so you want a device that supports multiple deployment models, discussed below. For devices with multiple ports, you should have flexibility in assigning them to specific devices. You should also be able to apply policies both actively and passively.


Decryption device deployment should be as non-disruptive as possible. You don’t want to mess around with IP addressing schemes, force every user to see a security warning every time they make an SSL connection, or have the device manipulate IP address headers and screw up your ability to monitor and analyze traffic. You want transparency, as mentioned above.

Also make sure you are seeing all relevant traffic. Don’t make assumptions about what is relevant and what isn’t. Attackers frequently hide encrypted traffic on odd traditional ports to evade decryption. So you should look at all traffic – not just the most obvious ports (HTTPS, SSH, SFTP, etc.) to make sure you don’t miss anything.

There are a few deployment options.

  • Passive Inline: In this configuration the decryption device is positioned as a bump in the wire – inline to ensure that all traffic can be inspected and decrypted according to the policy. Once traffic is decrypted the device can forward it to a variety of different security devices for inspection/monitoring, and can load balance between security devices if throughput is an issue. As a passive device, it won’t drop or block sessions itself, nor will it re-encrypt traffic – it just copies traffic to inspection devices, while forwarding the original (encrypted) traffic on to the network.
  • Active Inline: This configuration is similar to passive inline but can enforce policies. Based on policy the device decrypts traffic and forwards it to an inspection device. It queues the encrypted session until it receives a verdict back from the security device. If the session is fine it re-encrypts and sends the traffic on its way. If the session looks like an attack it is dropped.
  • Passive Tap: In this deployment the decryption device is connected to a network tap or span port on a switch to receive a copy of all the traffic. These passive devices aren’t in the flow of traffic, so they cannot enforce policy by dropping or blocking sessions. You will also need the private keys of receiving servers to decrypt because in this configuration you cannot get in the middle of the session to resign traffic. This model is only appropriate for inspecting traffic to internal servers, and so not commonly used.

In inline deployment models the device is basically a man-in-the-middle between your employees and their website destinations. The decryption device terminates user sessions, and establishes new sessions with destination websites. To avoid having the user see a security alert every time they initiate a secure session, users need to trust a certificate issued by the decryption device. That means either loading up a signed certificate into every user’s browser (typically through a workstation policy) or having decryption device certificates signed by a root which users (browsers) already trust, such as a public Certificate Authority (CA). This way the TCP session is not interrupted, and neither side has any idea that decryption is happening or that you are inspecting traffic.

These devices inspect and influence sensitive traffic, so availability is critical. Availability isn’t an issue in a passive tap deployment because tapas aren’t in the traffic flow. But in an inline configuration you need to decide what happens if the device fails. Choices include:

  • Fail to Network: If the device fails, the traffic is sent to the outbound network port but not to inspection devices. Sessions are not disrupted, but failure circumvents inspection and monitoring.
  • Fail to Device: In this scenario if the decryption device fails, traffic is still sent to inspection devices. Encrypted traffic cannot be decrypted, but unencrypted traffic can still be inspected and monitored/captured.
  • Fail Closed: This configuration takes the network offline by not forwarding traffic when the decryption device is down. This ensures you don’t miss an attack by taking the network out of commission entirely.

Most organizations choose Fail to Network – if decryption fails they do not want to stop all traffic. But that is something you will need to figure out with senior management, to ensure they understand the ramifications.

Now that you know how you should set policies to deal with encrypted traffic, where to decrypt it, and the criteria that should guide your selection of a dedicated device (if you go in that direction), you are ready to deal with the reality of encrypted networks. That was our objective for this short series. We will build a paper from this series before the end of the year, so keep an eye out.

—Mike Rothman

Wednesday, December 17, 2014

Security Best Practices for Amazon Web Services: Third Party Tools

By Rich

This is our third post on AWS security best practices, to be compiled into a short paper. See also our first post, on defending the management plane and our second post, on using built-in AWS tools.

Finish with Additional Security Tools

AWS provides an excellent security foundation but most deployments require a common set of additional tools:

  • Amazon’s monitoring tools (CloudTrail, CloudWatch, and Config) offer incomplete coverage, and no correlation or analysis. Integrate their feeds into existing log management, SIEM, monitoring, and alerting tools that natively support and correlate AWS logs and feeds, so they can fill gaps by tracking activity AWS currently misses.
  • Use a host configuration management tool designed to work in the cloud to automatically configure and update instances.
    • Embed agents into approved AMIs or bootstrap through installation scripts.
    • Insert baseline security policies so all instances meet security configuration requirements. This is also a good way to insert security agents.
  • Enhance host security in key areas using tools and packages designed to work in highly dynamic cloud deployments:
    • Agents should be lightweight, communicate with the AWS metadata service for important information, and configure themselves on installation.
    • Host Integrity Monitoring can detect unauthorized changes to instances.
    • Logging and alerting collect local audit activity and alerts on policy violations.
    • Host firewalls fill gaps left by security group limitations, such as rule set sizes.
    • Some tools can additionally secure administrator access to hosts without relying solely on ssh keys.
  • For web applications use a cloud-based Web Application Firewall.
  • Some services also provide DDoS protection. Although AWS can support high levels of traffic, DDoS protection stops traffic before it hits your instances… and your AWS bill.
  • Choose security assessments and scanning tools that tie into AWS APIs and comply with Amazon’s scanning requirements.
    • Look for tools that not only scan instances, but can assess the AWS environment.

Where to Go from Here

These fundamentals are just the surface of what is possible with cloud security. Explore advanced techniques like Software Defined Security, DevOps integration, and secure cloud architectures.


Tuesday, December 16, 2014

Firestarter: Predicting the Past

By Rich

In our last Firestarter for this year, Mike, Adrian, and I take on some of the latest security predictions for 2015. Needless to say, we aren’t impressed. We do, however, close out with some trends we are seeing which are likely to play out next year, and are MOST DEFINITELY NOT PREDICTIONS.

One warning: despite a lack of Guinness, we use some bad words, so let’s just brand this NSFW. Unless your workplace is like ours – then go for it.

Lastly, here are links to the predictions we called out (the only ones we found – feel free to mention more in the comments):

  • Websense. Which we didn’t read because you need to register to see them.
  • Trend Micro. Home of the legal disclaimer in case you get hacked after believing their predictions.
  • Kaspersky. A hard one to rip because we have friends there.
  • Netwrix. Yeah, we don’t know who they are either.
  • Vormetric. Another company we like, but we haz to play fair.
  • My 2011 security predictions. I keep renewing them every year, without change. Still mostly holding up – I estimate I hit 70-80% accuracy for 2014.

The audio-only version is up too.


Friday, December 12, 2014

Security Best Practices for Amazon Web Services: Built-In Features

By Rich

This is our second post on AWS security best practices, to be compiled into a short paper. The first post on defending the management plane is here.

Implement Built-in AWS Infrastructure Security Features

Once you lock down and establish monitoring for your Amazon Web Services management plane, it’s time to move on to protecting the virtual infrastructure. Start with these tools that Amazon provides:

Use Security Groups and VPCs for network defense

AWS uses a proprietary Software Defined Network with more security than physical networks. All new accounts on AWS use Virtual Private Clouds for underlying networking, giving you extensive control over network configurations, allowing you to run dozens or hundreds of separate virtual networks. Security Groups combine features of network and host firewalls. They apply to groups of instances like a network firewall, but protect instances from each other like a host firewall. These are the basis of AWS network security:

  • By default, instances in the same security group can’t talk to each other. This prevents attackers from spreading horizontally.
  • Separate application components across security groups, with only required ports open between them.
  • External administrative access (ssh or RDP) should be restricted to the IP addresses and subnets used by your administrators.
  • Minimize the number of public subnets, and use NAT gateways to connect private subnets to the Internet as needed, just like most enterprise networks.
  • Establish Access Control Lists to isolate subnets. They aren’t a substitute for security groups, but a complementary tool.
  • Require administrators to connect through a VPN or ssh “jump box” before connecting to instances. This can be an existing Privileged User Management tool.

Defend hosts and data

AWS is a mixture of Infrastructure as a Service (IaaS) and Platform as a Service (PaaS). Amazon bears most responsibility for keeping back-end components secure, but you are still responsible for properly configuring each service and your own instances. IAM is, again, your main tool for defense, but Amazon also offers features which can help you secure instances and protect data.

  • Establish an incident response process for compromised instances and other AWS services.
  • Use the AWS API or command line to collect all metadata, snapshot storage volumes, quarantine with IAM, and quarantine network connections.
  • Design applications to use Autoscaling Groups. Instead of patching running or compromised servers, you can terminate them and replace them with clean up-to-date copies without downtime.
  • AWS supports encryption for several data storage tools – including S3, EBS, and RedShift. You can manage the keys yourself with their Key Management Service (located in the IAM console).
  • Amazon can access keys in the Key Management Service. If you need extra security consider using CloudHSM instead, although service integration isn’t as simple.
  • If you use CloudHSM make sure you have at least two redundant instances so you don’t lose your keys. Amazon cannot view or recover them.