Research

It’s really funny and gratifying to see your kids growing up. Over the weekend XX1 took her first solo plane trip. I checked her in as an unaccompanied minor, and she miraculously got TSA Pre-check. Of course that didn’t mean I did with my gate pass. So the TSA folks did their darndest to maintain the security theater, and swabbed my hands and feet. We had some time so I figured we’d hang out in the airline club. Not so much. I have access to the SkyClub via my AmEx Platinum card, but evidently I have to be flying. So we got turned away at the door. Really? Total fail, Delta. And your club receptionist was mean. But I had XX1 with me, so I mumbled some choice words under my breath and just let her mention that person wasn’t nice. Then the gate agent called for her, and after a quick goodbye… Okay, not so quick – no goodbye is quick with XX1 – she headed down the jetway and was gone. Of course I got dispatches every 10 minutes or so via text. So I knew when her bag was in the overhead bin, when she got a refreshment, how much she was enjoying Tower Heist on the iPad, when the plane was loaded, and finally when she had to shut down her phone. She made it to her destination in one piece, and met Grandma at the gate. Another milestone achieved.   Then on Saturday morning I had the pleasure of taking the boy to breakfast. His sports activities (tennis and LAX) weren’t until afternoon so we had some boy time. As we were chatting I asked him about his friends. He then launched into a monologue about how all his friends tell Yo Mama! jokes now. He even had some pretty funny ones ready to go. He asked me if I had heard of those kinds of jokes. I just had to chuckle. You know those kids today – they invented everything. Though how they get their material is radically different. It seems they get the jokes on YouTube and then tell them to each other the next day at school. I had to actually read joke books to get my material and my delivery wasn’t very good. It seems to be in good fun, for now. I remember getting into fights with kids over those kinds of jokes, mostly because they weren’t really intended to be joking. And it’s a bit strange to think the Boss is the Mama in question, and at some point he may need to defend her honor. Although the Boy is pretty mild-mannered and very popular, so it’s hard to envision someone telling a joke to get a rise out of him. All the same, the kids are growing up. And unaccompanied plane rides and Yo Mama! jokes are all part of the experience. –Mike Photo credit: “Yo Mama’s Sign” originally uploaded by Casey Bisson 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. March 11 – RSA Postmortem Feb 21 – Happy Hour – RSA 2014 Feb 17 – Payment Madness Feb 10 – Mass Media Abuse Feb 03 – Inevitable Doom Jan 27 – Government Influence Jan 20 – Target and Antivirus Jan 13 – Crisis Communications 2014 RSA Conference Guide In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, with our content in all its unabridged glory. And you can get all our research papers too. Advanced Endpoint and Server Protection Quick Wins Detection/Investigation Prevention Assessment Introduction Newly Published Papers Reducing Attack Surface with Application Control Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing What CISOs Need to Know about Cloud Computing Incite 4 U Pwn to Pwn: Our friend Mike Mimoso has a great summary of the annual Pwn2Own contest at CanSecWest. This is the one where prizes are paid out to researchers who can crack browsers and other high-value targets (all picked ahead of time, with particular requirements). The exploits are bought up and later passed on to the affected vendors. As usual, all the products were cracked, but the effort required seems higher and higher every year. This level of exploitation is beyond your usual script kiddie tactics, and it’s nice to see the OS and browser vendors make practical security advances year after year. On the downside, BIOS and firmware hacking are going beyond scary. I really feel bad I haven’t made it to CanSecWest (usually due to work conflicts so close to RSA), but I think I need to make it a priority next year. It’s a great event, and a powerful contributor to the security community. – RM PCI is relevant. Really. It’s just those careless retailers: I’m in the air right now so I can’t check the TripWire folks’ interview with the PCI Standards Council’s Bob Russo at RSA, but some of the quotes I have seen are awesome. “People are studying for the test. Passing the compliance assessment and then leaving things open. They’re being careless,” said Bob Russo. Man, that is awesome. The standards are great – the retailers are just careless. Really? To be clear, Target was careless, but nowhere in the PCI standards do I see anything about locking down third-party access to non-protected information. Or having a network-based malware detection device to detect malware before it exfiltrates data. How about this one? “Russo said it

We originally recorded this episode on St. Patty’s Day and thought it would be nice to send off Windows XP with a nice Irish wake, but Google had a hiccup and our video was stuck in Never Never Land for an extra day. To be honest, we thought we lost it, so no complaints. But yes, the end is nigh, all your coffee shops are going to be hacked now that XP is unsupported, yadda yadda yadda… Share:

Hey everyone, I mentioned it on Twitter but also wanted to post it here. Tomorrow I will be giving a webinar on What Security Pros Need to Know About Cloud, based on the white paper I recently released. CloudPassage is sponsoring the webinar, but, as always, the content is our objective view. You can register online, and we hope to see you there… Share:

Forrester’s Rick Holland makes a great point in the epic Target Breach: Vendors, You’re Not Wrestlers, And This Isn’t The WWE post. Epic mostly because he figured out how to work the WWE and a picture of The Rock into a security blog post. Rick’s irritation with competitors trying to get a leg up on FireEye based on their presence in Target’s network is right on the money. Vendors who live in glass houses shouldn’t throw stones. It didn’t take long; I’ve already started hearing FireEye competitors speaking out against their competitor’s role in the Target breach. As I mentioned above, this wasn’t a technology failure: FireEye detected the malware. This was a people/process/oversight failure.   We all live in glass houses and karma is a bitch. But more to the point, if you think I take as fact anything written about a security attack in the mainstream business press, you’re nuts. If Krebs writes something I believe it because he knows what he’s doing. Not that no other reporters have enough technical credibility to get it right, there are. But without the full and complete picture of an attack, trying to assign blame is silly. Clearly in Target’s case there were many opportunities to detect the malware and perhaps stop the breach. They didn’t, and they are suffering now. Their glass house is shattered. But this could happen to any organization at any time. And to think otherwise is idiotic. So think twice before thinking that would never happen to you. Never is a long time. Photo credit: “Going into the Glass House” originally uploaded by Melody Joy Kramer Share:

Back in 2013, volumetric denial of service (DoS) attacks targeting networks were all the rage. Alleged hacktivists effectively used the tactic first against Fortune-class banks, largely knocking down major banking brands for days at a time. But these big companies adapted quickly and got proficient at defending themselves, so attackers then bifurcated their attacks. On one hand they went after softer targets like public entities (the UN, et al) and smaller financial institutions. They also used new tactics to take on content delivery networks like CloudFlare with multi-hundred-gigabyte attacks, just because they could. In our Defending Against Denial of Service Attacks research we described network-based DoS attacks: Network-based attacks overwhelm the network equipment and/or totally consume network capacity by throwing everything including the kitchen sink at a site – this interferes with legitimate traffic reaching the site. This volumetric type of attack is what most folks consider Denial of Service, and it realistically requires blasting away from many devices, so current attacks are called Distributed Denial of Service (DDoS). If your adversary has enough firepower it is very hard to defend against these attacks, and you will quickly be reminded that though bandwidth may be plentiful, it certainly isn’t free. Application-based attacks are different – they target weaknesses in web application components to consume all the resources of a web, application, or database server to effectively disable it. These attacks can target either vulnerabilities or ‘features’ of an application stack to overwhelm servers and prevent legitimate traffic from accessing web pages or completing transactions. The motivation for these attacks hasn’t changed much. Attackers tend to be either organized crime factions stealing money via ransom attacks, or hacktivists trying to make a point. We do see a bit of competitor malfeasance and Distributed DoS (DDoS) to hide exfiltration activities, but those don’t seem to be primary use cases any more. Regardless of motivation, attackers now have faster networks, bigger botnets, and increasingly effective tactics to magnify the impact of DDoS attacks, forcing most organizations to devote attention to implementing plans to mitigate these attack. After digging deeper into the application side of denial of service in Defending Against Application Denial of Service Attacks, we now turn our attention to the network side of the house. We are pleased to start this new series, entitled Defending Against Network Distributed Denial of Service Attacks. As with all our public research, we will build the series using our Totally Transparent Research model. Before we get going we would like to thank A10 Networks, as they have agreed to potentially license this research at the end of the project. It’s Getting Easier If anything, it is getting easier to launch large-scale network-based DDoS attacks. There are a few main reasons: Bot availability: It’s not like fewer devices are being compromised. Fairly sophisticated malware kits are available to make it even easier to compromise devices. As a result there seem to be millions of (predominately consumer) devices compromised daily, adding to the armies which can be brought to bear in DoS attacks. Faster consumer Internet: With a bandwidth renaissance happening around the world, network speeds into homes and small offices continue to climb. This enables consumer bots to blast targets with growing bandwidth, and this trend will continue as networks get faster. Cloud servers: It is uncommon to see 50mbps sustained coming from a consumer device. But that is quite possible at the server level. Combine this with the fact that cloud servers (and management consoles) are Internet-facing, and attackers can now use compromised cloud servers to blast DDoS targets as well. This kind of activity is harder to detect because these servers should be pumping out more traffic. Magnification: Finally, attackers are getting better at magnifying the impact of their attacks, manipulating protocols like DNS and ICMP which can provide order-of-magnitude magnification of traffic hitting the target site. This makes far better use of attacker resources, allowing them to use each bot sporadically and with more lightly (in terms of bandwidth) to better hide from detection. Limitations of Current Defenses Before we dive into specifics of how these attacks work we need to remind everyone why existing network and security devices aren’t particularly well-suited to DDoS attacks. It’s not due to core throughput – we see service provider network firewalls processing upwards of 500gbps of traffic, and they are getting faster rapidly. But the devices aren’t architected to deal with floods of legitimate traffic from thousands of devices. Even with NGFW capabilities providing visibility into web and other application traffic; dealing with millions of active connection requests can exhaust link, session, and application handling capacity on security devices, regardless of their maximum possible throughput. IPS devices are in the same boat, except that their job is harder because they are actively looking for attacks and profiling activity to find malicious patterns. So they are far more compute-intensive, and have an even harder time keeping pace with DDoS bandwidth. In fact many attackers target firewalls and IPS devices with DDoS attacks, knowing the devices typically fail closed, rendering the target network inoperable. You should certainly look to service providers to help deal with attacks, first by over-provisioning your networks. This is a common tactic for networking folks: throw more bandwidth at the problem. Unfortunately you probably can’t compete with a botmaster leveraging the aggregate bandwidth of all their compromised hosts. And it gets expensive to provision enough unused bandwidth to deal with a DDoS spike in traffic. You can also look at CDNs (Content Delivery Networks) and/or DoS scrubbing service. Unfortunately CDN offerings may not offer full coverage of your entire network and are increasingly DDoS targets themselves. Scrubbing centers can be expensive, and still involve downtime as you shift traffic routes to the scrubbing center. Finally, any scrubbing approach is inherently reactive – you are likely to already be down by the time you learn you have a problem. Further complicating things is the fundamental challenge of simply detecting the onset of a DDoS attack. How can you tell the difference between a temporary spike in traffic and a full-on blitzkrieg on your

Attacks keep happening. Breaches keep happening. Senior management keeps wondering what the security team is doing. The lack of demonstrable progress [in stopping malware] comes down to two intertwined causes. First, devices are built using software that has defects attackers can exploit. Nothing is perfect, especially not software, so every line of code presents an attack surface. Second, employees can be fooled into taking action (such as installing software or clicking a link) that enables attacks to succeed. Application Control technology can have a significant impact on the security posture of protected devices, but has long been much maligned. There was no doubt of its value in stopping attacks, especially those using sophisticated malware. Being able to block the execution of unauthorized executables takes many common attacks out of play. But there is a user experience cost for that protection.   In Reducing Attack Surface with Application Control, we look at the double-edged sword of application control, detail a number of use cases where it fits well, and define selection criteria to consider for the technology. Keep in mind that no one control or tactic fits every scenario. Not for every company, nor for every device within a company. If you are looking for a panacea you are in the wrong business. If you are looking for a technology that can lock down devices in appropriate circumstances, check out this paper. Conclusion: Application control can be useful – particularly for stopping advanced attackers and securing unsupported operating systems. There are trade-offs as with any security control, but with proper planning and selection of which use cases to address, application control resists device compromise and protects enterprise data. We would like to thank AppSense for licensing the paper and supporting our research. We make this point frequently, but without security companies understanding and getting behind our Totally Transparent Research model you wouldn’t be able to enjoy our research. Get the paper via our permanent landing page or download the paper directly (PDF). Share:

Rich here, As technology professionals we always place bets with our careers. There is no way to really know, for certain, which sets of skills will be most in demand down the road. Yet, as with financial investments, we only have so many resources (time and brain cells) to allocate at any given time. Invest too much too early and your nifty new skills won’t be in demand. Too late and you miss the best opportunities, and are stuck playing catch-up if that’s even possible. Sometimes we make deliberate decisions, and sometimes we just sort of luck out. This week I am excited to announce my involvement as an Advisory Board member of DevOps.com. It’s something I basically fell into when I mentioned to Alan Shimmel, who founded it, that I was spending a ton of research time on DevOps and security. I never really intended to revert to my roots and start writing code and managing systems again – never mind realizing I was hooked into what may be one of the most important operational framework changes to hit IT in a long time. For me it was a series of chained intellectual and professional challenges that self-organized into a logical progression. I would love to say I planned it, but really I mostly tripped into it. It all started when Jim Reavis of the Cloud Security Alliance asked if I would be interested in building a training class for the CCSK exam. I said sure, but only if we could build some hands-on labs so security pros would learn how the cloud really works, and weren’t merely looking at architectural diagrams. I had launched some things in Amazon before, but I had never needed to create packaged, reproducible environments (the labs). Never mind ones that could hide complexity from students while still allowing them to create complete application stacks almost completely automatically. At the time I was solving problems to make labs and teach a few cloud security essentials. In the process, I was learning the foundation of techniques that underlie many DevOps processes. Total. Blind. Luck. This was before DevOps was a hot term – I just worked from problem to problem to meet my own needs. Then I refined the labs. Then I decided to create some proof of concept demonstrations of Software Defined Security techniques. Solving, in the process, some core DevOps problems that weren’t well documented anywhere. I wasn’t the first to hit the problem or come up with a solution, but no one else seemed to write it down, so I had to work my way through it from scratch. Then I started hearing more about DevOps. And as I dug in, I realized I was solving many of the same problems with many of the same tools. This is why I think DevOps is so important. I didn’t set out to “learn DevOps” – I set out to solve a set of practical implementation problems I was experiencing in the cloud, and in the process found myself smack in the middle of the DevOps ‘movement’ (whatever that is). Anyone who wants to operate in that environment needs the same basic skills, and any organizations deploying applications into the cloud will find themselves using the same techniques, to one degree or another. It is early days still, but I am not doubling down on cloud and DevOps because I think they are overhyped analyst fads. Spend some time in the trenches and you will realize there really isn’t any other way to get the job done, once you start down a certain road. On to the Summary: Webcasts, Podcasts, Outside Writing, and Conferences Rich quoted in Macworld UK on Apple security. To be honest, I think this is from an old blog post, but I’ll take it. Dave Lewis on Apple TV password disclosure. Favorite Securosis Posts Adrian Lane: Firestarter: RSA Postmortem. Mike Rothman: New Paper: Leveraging TI in Security Monitoring. Yeah, it’s my work. But there is a lot of noise about threat intelligence out there now, and much less about how to actually use it effectively. This paper looks at TI in terms of security monitoring. Rich: New Paper: Leveraging TI in Security Monitoring. Threat Intelligence was all over RSA, and Mike has been working on this research for far longer than those marketing departments. He really nails it, bringing TI from buzzwords to actionable advice. Nice. Other Securosis Posts Incite 3/12/2014: Digging Out. Advanced Endpoint and Server Protection: Quick Wins. Advanced Endpoint and Server Protection: Detection/Investigation. Favorite Outside Posts Mike Rothman: The cost of doing business at the RSA Conference. Big money. Big money. No whammies. Check out these numbers and maybe you will understand why some companies opt for a suite at the W to do meetings. Adrian Lane: To Wash It All Away. And epic rant that includes such gems as “For the uninitiated, Cascading Style Sheets are a cryptic language developed by the Freemasons to obscure the visual nature of reality and encourage people to depict things using ASCII art.” and “Here’s a life tip: when you’re confused about what something is, DON’T EXECUTE IT TO DISCOVER MORE CLUES!” Rich: Does devops leave security out in the cold? I will be writing more on this in coming days, but I think it’s safe to say this article misses the target. I guarantee you security can effectively integrate with DevOps, but not using some of the techniques mentioned in this article. Security has to fully integrate into the process. Gunnar Peterson: Ultimate Cheat Sheet for Dealing with Haters. Research Reports and Presentations Leveraging Threat Intelligence in Security Monitoring. The Future of Security: The Trends and Technologies Transforming Security. Security Analytics with Big Data. Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7. Eliminate Surprises with Security Assurance and Testing. What CISOs Need to Know about Cloud Computing. Defending Against Application Denial of Service Attacks. Executive Guide to Pragmatic Network Security Management. Security Awareness Training Evolution. Top News and Posts Target Didn’t Follow Up After Hackers Tripped Its Security System. We still

The ritual is largely the same. I do my morning stuff (usually consisting of some meditation and some exercise), I grab a quick bite, and then I consult my list of things that need to get done. It is long, and seems to be getting longer. The more I work, the more I have to do. It’s a good problem to have, but it’s still a problem. And going to RSA two weeks ago exacerbated it. I had a lot of great conversations with lots of folks who want to license our research, have us speak at their events, and have us advise them on all sorts of things. It’s awesome, but it’s still a problem.   Of course you probably think we should expand and add a bunch of folks to keep up with demand. We have thought about that. And decided against it. It takes a unique skill set to do what we do, the way we do it. The folks who understand research tend to be locked up by big research non-competes. The folks who understand how to develop business tend not to understand research. And the very few who can do both generally aren’t a cultural fit for us. Such is life… But that’s not even the biggest obstacle. It’s that after 4+ years of working together (Rich and Adrian a bit more), we enjoy a drama-free environment. The very few times we had some measure of disagreement or conflict, it was resolved with a quick email or phone call, in a few minutes. Adding people adds drama. And I’m sure none of us wants more drama. So we put our heads down and go to work. We build the pipeline, push the work over the finish line, and try to keep pace. We accept that sometimes we need to decide not to take a project or see how flexible the client is on delivery or scheduling. As with everything, you make choices and live with them. And while it may sound like I’m whining about how great our business is, I’m not. I am grateful to have to make trade-offs. That I have a choice of which projects I work on, for which clients. Not that I can’t find work or deal with slow demand. The three of us all realize how fortunate we are to be in this position: lots of demand and very low overhead. That is not a problem. We want to keep it that way. Which is basically my way of saying, where is that shovel again? Time to get back to digging. –Mike Photo credit: “Digging out auto” originally uploaded by Boston Public Library Securosis Firestarter Have you checked out our new video podcast? Rich, Adrian, and Mike get into a Google Hangout and well hang out. We talk a bit about security as well. We try to keep these to less than 15 minutes and usually fail. March 11 – RSA Postmortem Feb 21 – Happy Hour – RSA 2014 Feb 17 – Payment Madness Feb 10 – Mass Media Abuse Feb 03 – Inevitable Doom Jan 27 – Government Influence Jan 20 – Target and Antivirus Jan 13 – Crisis Communications 2014 RSA Conference Guide In case any of you missed it, we published our fifth RSA Conference Guide. Yes, we do mention the conference a bit, but it’s really our ideas about how security will shake out in 2014. You can get the full guide with all the memes you can eat. Heavy Research We are back at work on a variety of blog series, so here is a list of the research currently underway. Remember you can get our Heavy Feed via RSS, where you can get all our content in its unabridged glory. And you can get all our research papers too. Advanced Endpoint and Server Protection Quick Wins Detection/Investigation Prevention Assessment Introduction Newly Published Papers Leveraging Threat Intelligence in Security Monitoring The Future of Security Security Management 2.5: Replacing Your SIEM Yet? Defending Data on iOS 7 Eliminating Surprises with Security Assurance and Testing What CISOs Need to Know about Cloud Computing Incite 4 U Incentives drive organizational behavior: I am not sure why Gunnar tweeted a link to something he posted back in October, but it gave me an opportunity to revisit a totally awesome post. In Security Engineering and Incentives he goes through the key aspects of security engineering, and incentives are one of the four cornerstones (along with security policy, security mechanism, and assurance). Probably the most important of the cornerstones, because without proper incentives no one does anything. If you have ever been in sales you know the compensation plan drives behavior. It is that way in every functional part of the business. In the not-so-real world you have folks who do what they are supposed to because they do. And in the real world, those behaviors are driven by incentives, not risk (as GP points out). So when you wonder why the Ops team ignores the security policy and developers couldn’t give less of a crap about your security rules, look at what they are incented to do. Odds are be secure isn’t really on that list. – MR Persona non grata: The Mozilla Wiki does not really capture the essence of what’s going on with Mozilla’s Persona project, but the gist is that their effort to offer third party identity federation has failed. There is some debate about whether technical or financial derailed the project and prevented it from reaching “critical mass”, but I think the statement “We looked at Facebook Connect as our main competitor, but we can’t offer the same incentives (access to user data)” pretty much nails it. If you wonder why Yahoo is ditching Facebook and Google federation services in lieu of their own offering, understand that identity is the next generation’s “owning the user”, and a key means for data providers (advertising networks) to differentiate their value to advertisers. The goal of federated identity was to offer easier and better identity management across web applications, doing away with user names and passwords. But identity providers have seen the greatest benefit, through enrichment of the data

We are all rested and recovered from RSA (yeah, right) and it’s time to review the week and what we think. Did we mention security is back, baby?! That’s right – it is clear budgets are now free, and the stink of desperation is fading. Here’s the video: And the audio-only version is up – we should be available for subscription in iTunes next week. Thanks, and see you next week… Share:

We have covered the main aspects of the threat management cycle, in terms of the endpoint and server contexts, in our last few posts. Now let’s apply these concepts to a scenario to see how it plays out. In this scenario you work for a high-tech company which provides classified technology to a number of governments, and has a lot of valuable intellectual property. You know you are targeted by state-sponsored adversaries for the classified information and intellectual property on your networks. So you have plenty of senior management support and significant resources to invest in dealing with advanced threats. You bought into reimagined threat management, and have deployed a combination of controls on your endpoints and servers. These include advanced heuristics on valuable endpoints, application control on servers with access to key intellectual property stores, and broad deployment of device activity monitoring technology – all because you know it is a matter of when rather than if you will be compromised. You supplement endpoint and server protections with network-based malware detection and full packet capture. So resources are not an issue and you have controls in place to deal with advanced adversaries. Of course that and $4 will get you a coffee, so you need to build these controls into a strong process to ensure you can react faster and better to the attacks you know are coming. But not every organization can make such extensive investments, so you may not have the full complement of controls at your disposal. The Attack: Take 1 This attack starts as many do, with an adversary sending a phishing email with a malicious MS Office attachment to an employee in the finance department. The employee’s device has an agent that uses advanced heuristics, which identifies the malicious behavior when the file attempts to turn off the traditional AV product and install what looks like a dropper on the device. The agent runs at the kernel level so it manages to block the attack and administrators alerted, and no harm is done… this time. These are the kinds of quick wins you are looking for, and even with proper security awareness training, employees are still very likely to be duped by advanced attackers. So additional layers of defense, beyond the traditional endpoint protection suite, are critical. The Attack: Take 2 The advanced adversary is not going to give up after their blocked initial foray. This time they target the administrative assistant of the CEO. They pull out a big gun, and use a true 0-day to exploit an unknown flaw in the operating system to compromise the device. They deliver the exploit via another phishing email and get the admin to click on the link to a dedicated server never used for anything else. A drive-by download exploits the OS using the 0-day, and from there they escalate privileges on the admin’s device, steal credentials (including the CEO’s logins) and begin reconnaissance within the organization to find the data they were tasked to steal. As the adversary is moving laterally throughout the organization they compromise additional devices and get closer to their goal, a CAD system with schematics and reports on classified technology. As mentioned above, your organization deployed network-based malware detection to look for callbacks, and since a number of devices have used similar patterns of DNS searches (which seem to be driven by a domain-generating algorithm), alarms go off regarding a possible compromise. While you are undertaking the initial validation and triage of this potential attack, the adversaries have found the CAD system and are attempting to penetrate the server and steal the data. But the server has application controls, and will not run any unauthorized executables. So the attack is blocked and the security team is alerted to a bunch of unauthorized activity on that server. This is another quick win – attackers found their target but can’t get the data they want directly. Between the endpoint compromise calling back to the botnet, and attempts on the server, you have definitive proof of an adversary in your midst. At this point the incident response process kicks in. Respond and Contain As we described in our incident response fundamentals series, you start the response process after confirming the attack by escalating the incident based on what’s at risk and the likelihood of data loss. Then you size up the incident by determining the scope of the attack, the attacker’s tactics, and who the attacker is, to get a feel for intent. With that information you can decide what kind of response you need to undertake, and its urgency. Your next step is to contain the attack and make sure you have the potential damage under control. This can take a variety of forms, but normally it involves quarantining the affected device (endpoint or server) and starting the forensics investigation. But in this scenario – working with senior management, general counsel, and external forensic investigators – the decision has been made to leave the compromised devices on the network. You might do this for a couple reasons: You don’t want to tip off the adversary that you know they are there. If they know they have been detected they may burrow in deeper, hiding in nooks and crannies and making it much harder to really get rid of them. Given an advanced attacker is targeting your environment, you can gather a bunch of intelligence about their tactics and techniques by watching them in action. Obviously you start by making sure the affected devices can’t get to sensitive information, but this gives you an opportunity to get to know the adversary. A key part of this watching and waiting approach is continuing to collect detailed telemetry from the devices, and starting to capture full network traffic to and from affected devices. This provides a full picture of exactly what the adversary is doing (if anything) on the devices. Investigate The good news is that the investigation team has access to extensive telemetry from device activity monitoring and network packet capture. Analyzing the first compromised