- Welcome to the Cyber5, where security experts and leaders answer five burning questions on one hot topic and actual intelligence enterprise. Topics include adversary research and attribution, digital executive protection, supply chain risks, brand reputation and protection, disinformation and cyber threat intelligence. I'm your host Landon Winklevoss co-founder of Nisos, a Managed Intelligence Company™. In this episode, I talked with cyber threat management director, Colby Clark, who is also the author of a recent book, titled "The Cyber Security Incident Management Master's Guide" Scott Colby brings over 20 years of consulting experience and has worked with over a thousand different organizations, either for incident response or solutions architecture. We baseline incident response playbooks around the customer environment, threat landscape, regulatory environment, and security controls. We further discuss how instant response playbooks have evolved over the last five years, we also discuss how instant response playbooks have scaled in the cloud and discuss telemetry that is important and critical to ensure instant response teams can say with confidence that an incident is accurate, complete, and truthful in order to avoid breaches. Finally, we discuss the criticality of threat intelligence and incident response process. And what boards really care about during an incident, stay with us. Colby, welcome to the show, sir, would you mind sharing a little about your background for our listeners please? [Colby]- Landon thanks for having me Yeah. I've been involved in cybersecurity and incident management since about 1999, contiguously as well as getting pulled into lots of other related topics like solutions architecture, cybersecurity architecture, things of that nature.

- No its gonna be a fascinating conversation. It's not every day. We have security practitioners that come from the solutions consulting side, as well as the customer side. So certainly your expertise is going to be awesome here. So I guess kind of starting out today, we're going to be talking about general incident response playbooks, and really how they've changed over the last 10 years, because I think that we all probably agree what has happened over the past 10 years in terms of what is needed to actually indicate what is complete, truthful, and accurate and how you ultimately have that baseline. And then ultimately how you respond has certainly changed. Just kind of going on that theme. If you don't mind, you've written quite a bit of literature on this very topic based on your experiences over the last 10, 15 years, you know, provide a baseline overview of the critical aspects of cyber security incident management framework, and then how those playbooks change over the last ten years.

- Yeah, sure I guess to start off with it, probably easiest talk about where it's come from So I've been in consulting for a long time and 10 years ago when we ran across playbooks and customer environments, you know, when they existed, they really weren't that mature or specific to cybersecurity concerns. Most of the playbooks are basically departmental structures, assignment of responsibilities and contact lists, things of that nature, but they didn't inform people on what to do for the various types of threats or the related incident types that were affecting them. What was most common for playbooks was that they're based more on natural disasters, BCDR situations, regulatory compliance concerns like HIPAA or PCI may have driven them to a certain extent. And if they did have anything related to cybersecurity, it was more like one big cyber security buckets, which they treated kind of like BCDR as like, like I said more about recovery, you know, in consulting when we did see them, you know, they were very generic kind of based off a NIS templates and they didn't really fit very well. It was mainly driven by an auditor, said they needed to have this. And so they just downloaded something. We branded it and then put it in play nowadays there's a much larger emphasis on developing threat based playbooks that are more specific and actionable to individual environments and to be effective, they really need to be customized to uniquely address the nuances of each environment and threat type, you know, to a certain extent, you know, regulatory requirements and cyber insurance needs some help drive this by asking for such in many environments, they still make the mistake though of only creating playbooks that are requested by the auditors. Such as you know, they'll have a playbook for ransomware is such a hot topic, but they won't necessarily have a playbook for the underlying malware or crimeware suites that is affecting their environment. That's deploying the ransomware. And ransomware is basically that the payload in the back of a pickup truck that just happens to be what they deployed, but companies need to really have a broader look at what's affects them. And instead of, of response playbooks respective to those. And so what I've put together with the incident management framework, there's 13 distinct domains that are specifically defined and used for either assessments or for planning in the environment. So you can use it the other way. And the various domains they're structured in such a way as to enable a better understanding of the customer environments and the internal and external variables. I'm not going to go through all the different domains unless you want to talk about each one, but there's, it gets they're broken up in such a way that you can have a distinct discussion about them and really fully get your arms around the environments either for assessing the needs or planning for such. And I think the most important thing to remember is that incident management is a continuous process that repeats forever and the regulatory landscape it tends to increase in scope and create overlapping incongruities, 'cause there's conflicting requirements. Of course, the business is always trying to change and to meet the various needs and to adapt to the regulatory requirements, which are sometimes highly vague, actually usually highly vague and, often inconsistent. You also have developers there forever making bad code that creates areas of opportunities for attackers. And that includes inside of security tools, which are supposed to keep us safe. So when you look at the whole threat space, it's constantly evolving and there always seems to be at least a step or two ahead of the security solutions providers. And so the solution space is constantly striving to adapt, to hopefully address the various security needs. But the attackers are much better funded than the defenders who are always, you know, playing catch up. So this combination of factors, it creates a situation where there's always gaps that need to be addressed in innovative ways and which can't be addressed by solutions out of the box. So because of this combination of factors, it just results in a constant churn of the need for identification and response lessons learned you know, changes in detection, techniques, countermeasures solutions, and then followed by training and monitoring sane. Lastly, you know, a good goal is to be dealing with new problems rather than playing whack-a-mole with the same problems. Again, if you're playing whack-a-mole you're, you know you're doing it wrong.

- Diving into that a little bit. I mean if you take these to things like the customer and buyer threat landscape, the regulatory environment, security controls, all those things to kind of go into, you know, an IR measure framework in your opinion, what is the hardest aspect to get, right. And how long does this take for mature securities? I guess a little bit of context on that question. You know, what you said is that the solutions are never really catching up. And, you know, as you know, we're in a world where funding, you know, solutions, really we're talking about products, a lot of times, only address one little issue and your gonna have to staple all these different types of products into these environments. None of it really talks to one another. And so realistically what's happening is, you know, a lot of consolidation in the market where you have legit platforms, like customers are going to be one specific vendor. It's going to be their entire suite, or they're going to be another type of vendor it's going to be their entire suite. Is that the hardest aspect of management response?

- Well, I think that most companies lack the understanding of their environment. They typically don't get serious about incident response until they have grown to be a, a medium to large business. And at that point, they, they don't quite understand how their business operations and their systems work. And so there's the, the first tenant, I guess, of zero trust architecture is, is, you know, know thy network, you know? Understand what exactly you have. What's normal, what you, what it is you're trying to protect and defend what is normal in your environment. And then based upon the threat landscape that would be affecting your environment. The companies need to have playbooks for responding to all their respective threat types and their teams need to be well-practiced in responding to these threats in their environments and using their tools. And so this takes many iterative cycles and a combination of responding to real threats, as well as war gaming and tabletop exercises in order to identify weaknesses and to improve aspects of all of people process and technology. And then in doing so, the teams can identify and kind of mitigate those dark corners in their environments. And something we keep in mind is that companies typically just focus on technology. Like they like to open a can and say, Hey, this, this, this here's a fix it in the can, but they skipped the people and process components of it. And you really need all three for a complete solution because this, if the, you know, the, the technology isn't tuned and set up for the environmental, the people do not how to use it, or it doesn't have coverage and visibility. It's not going to be that effective.

- Well you mentioned a couple of key points there, know thy network and attackers are more funded than defenders. So understanding those two aspects, you know, what are some effective strategies where visibility can be maintained that makes the defender's job easier?

- Well yeah, yeah. I think you hit the nail on the head with visibility. It's absolutely critical. It's really hard to make a valid arguments of not being breached if you have no telemetry to back it up. And I think that was a ruse that, that people would do in the past, like companies would use the statements. Well, there's no evidence of compromise, but, you know, they had no evidence at all. So it, and it used to fly, but it never was a very good argument, but not anymore. Now regulators and state AG's and consumer protection groups credit card brands, and all these folks who are very interested in your business after you've had a breach. Now they'll hire response teams to investigate and to determine if companies have, have adequate security controls. And if they don't, then they're going to incur, you know, fines and penalties and restrictions, and a lot of undesirable intervention. And I know this because the teams that I was responsible for, as well as myself, we were often hired by all of these different groups. If you didn't have a conflict of interest on, because I did run a PFI team. And so we would come in after the fact a lot and work on behalf of these different, well, for PFI, it was for the credit card brands, but we'd do the same work for AGS and DOJs and various other groups. And then regarding the placement of visibility, it's, it's naturally moving toward the end point to be effective. Network tools are increasingly blind due to network encryption pervasiveness, such as we also self-imposed limitations and cryptography improvements such as like TLS 1.3, which really complicates network monitoring. But the end point is really the only place where everything is still visible, always mostly visible, moreover, since the inside is the new outside, you know, so to say you know, due to like endpoint browser volms, and email threads and things like that, systems are so distributed also across the workforce, particularly now with so many people working from home network controls are just becoming increasingly irrelevant and really moving towards the end points to be effective. But you know, you'll never have an agent on every end point so there's still network controls that are required. And maybe some prime examples would include like contractor and legacy or perhaps regulated systems like FDA regulated systems where you can't do anything to 'em you can't even patch 'em them without, you know, vendor testing approval. So there's still a place for network controls, but they need some pose, better security through architecture and dynamic segmentation, web isolation, things like that to make them visible, or at least restrict them and put them in such a place that you can be successful. And companies also need to stop self-limiting their network traffic that they decrypt, you know, to ensure they have this visibility. Oftentimes companies will say, well, you know, we're not going to decrypt like medical, financial or personal web mail because we don't want to intrude on people's privacy, but those are some of the biggest attack vectors. And if you need are your next gen protections for malicious sites, that's, you know, you might as well not even have them.

- The question that you already answered I guess is, is all internal telemetry created equal. And you're just saying, it's actually not.The end points is obviously much more critical than the network. Very interesting that you say, you know, that, that the fact that it's a, cop-out when people say, well, what if we can't see it? You know? And of course, can you see this a lot of times when you're dealing with counsel, as if we can't see it, then we have no reason to believe it's breached and we don't have any reason to disclose. And those are, those arguments are mostly being phased out. Give an example of where, of where that endpoint telemetry helps, quote you know, save the day and that visibility was needed and really where the network traffic was irrelevant.

- Yeah there, I would say around 2014 there started to be halfway decent EDR type solutions. And some of them would integrate with the network side of the house where you had a combination of, of end points and, and network detection. And we started doing a breach discoveries about that point. And we would go into customer environments where they had a suspicion that things might be malicious. So or that, that there, there may be something going on that they didn't know, or they maybe they do about some activity, but they didn't know the full story because it was, it was just too hard to get their arms around. And so we started using like EDR type technologies to figure out really quickly what malicious application is sending, what data, where, and we can, we can answer those questions. And, and honestly, during breach discovery type activity, I think probably 70 or 80% of the detections that we were able to positively identify would come from EDR tools. You would have another, maybe 10 to 15% come from network. And another smaller percent is coming from, from log analysis. When you put it all together, in one view, it makes it very easy to answer and, or figure out what's going on and said to figure out what's the impact, what's the risk to the organization.

- So I guess then the next phase of this, you know, it was really kind of the overall migration that many organizations are moving to cloud. Many say that a moved cloud is critical for conducting initial triage and response at scale. Would you agree there?

- Oh, for sure. Yeah. With EDR and NDR What they are now branding together as XDR, it's really the only way to perform rapid detection and response as an example, or by contrast anyways, on-prem forensic approaches are no longer viable and they really ceased to be effective about 10 years ago. And if, if you have an on-prem EDR or NDR solution, it's, it's going to be just as lame because you won't be able to see what's happening with all your distributed workforce. And there's, there's always some sales guy traveling somewhere. That's going to wind up getting affected or compromised in his laptop, and then bring it back to, to the environment or phone at home, through a VPN. So, you know cloud-based response tools, they're just, they're incredibly liberating to response teams, which might not even have to go on site if they have the right cloud-based visibility and response tools. Now, when you're also asking about cloud environments like prod and non-prod environments where they're extending to the cloud, or just, just the investigative tools?

- I was really mostly talking about the, the environments themselves

- Ah, the environments themselves. So with like prod and non-prod systems, I think they, they worked against us from the security response perspective and they really pose a significant problem for security and I.R, because they don't typically have on par visibility or response capabilities to their physical counterparts. Especially if you consider things like containers, which is just an application with some libraries and oftentimes cloud systems, or they might be dual homed. And then they may have internal and external interfaces, which can create a back door situation into the environment that you, you might not even be aware of. Long story short. I think they create an increased attack surface and they have fewer controls and, and investigative capabilities. What it's investigating cloud now is a lot like investigating end points, 15 years ago.

- So how do you do that? If you're a development shop, and again, this can be a Fortune 500 company. This can be a startup in the, a round, right? Who's just developing an application, if you're constantly spinning up containers, you know, and again, if not configured appropriately, the successful authentication of one container could, give access to the backend environment. It could give access to proprietary source code. There changes can be made to that source code. That source code gets pushed to push to production. And we have big problems if, of course, if that can be altered, right? So walk through some strategies, if you don't mind on how, you know, you can really from an instant response perspective, because again, like let's go back to that central thesis of, I need to be what is truthful, what is accurate, what is complete. I need to have visibility on this and, you know, as well as I do developers spin up containers within hours and take them down, right? What are strategies that you have that ultimately have those containers? What's the redundancy, you know, criticalities of where those types of containers, and you can have insert, you know visibility from an incident response perspective.

- Well there, and say, add to that. There they're automatically provisioned and de-provisioned. It's not even a manual process. Most of the time, it's just about availability. So they just, the system spins them up. So with those, you have to be very, very disciplined of having the right container image, making sure you have something that's fully patched and hardened, and that, you know, you don't have, let's say a quarterly or annual audit cycle where you go through an update or update your containers. It's something that they really have to stay on top of, you know, particularly if they're, they're, they're based on highly vulnerable and exploited types of technologies. So I think that you need to have at least a monthly cycle of making sure you're running something that is that's, you know, fully updated from that container image, as well as, you know, even something more rapidly than, than a month, if there's new threats that come out and beyond that, because containers are automatically provisioned and de-provisioned, there needs to be some kind of an image that's kept. So you have something to go back and to investigate. And so that, that just means that there's a lot of discipline and a lot more expense in cloud to do that. And as well as, as well as logging, oftentimes it will actually not, oftentimes, by default in cloud environments, nothing is logged and you have to, you have to pay extra money and you have to also pay extra licensing fees for security tools, to be able to have things like, like waf and SIM and all these types of things. And a lot of that at least with SIM you can funnel it back to your on-prem SIM. Your still paying for the additional logging features, and it's not something that comes by default. So I would suggest having the right logging turned on and there's, there's a lot of different technologies. And there's examples of what's recommended for that. And this has some examples, but I would recommend having the right logging turned on having the right network security controls, having decryption in the right place and using endpoint security technologies where possible, obviously not with containers.

- Where's threat intelligence fit in this overall picture, just by the example that we're just talking, right? So you have all these containers being stood up and stood back down. If you're going to take down a container based on, you know, a bad guy scanning a container. I mean, that's not good for business, right. But if you can think of potentially, okay, well maybe I wanna pick up activity, of somebody auth attempts, you know, authentication attempts, maybe I'll want to pick up activity. Somebody throwing a, an old exploit at one of these, is there threat intelligence that could add value to overall, you know, not only the IR management framework process, but also to this kind of, you know, move to the cloud as well.

- Yeah, for sure. I think that even all of the modern tools. They, they, just to an extent relied on threat intel feeds to inform them because, you know, chances are, you're not the first one to be compromised, right? Somebody else has seen some variant of this first and the bad guy models they just sort of rinse and repeat through different sectors across different, across the same technologies. Like for instance, when you start seeing,you know card breaches, as an example, maybe they'll, they'll rip through all the vendors that have Aloha networks and then they'll move on to something else. And so you can usually get a, a pretty good understanding of what's coming if you have decent threat Intel, and it's preferably if it's automated and it's feeding your tools and you need, you need multiple sources, but it's threat Intel should hopefully be very helpful, both in preventing breaches, as well as identifying if your customers have been breached and they don't know it, and threat Intel will help to flush that out. It's, it's an invaluable part of, of both proactive and reactive processes and, and from a zero trust and a modern IR perspective, it really should be assumed that a breach already has, or is certainly will happen. So, you know, threat hunting and, you know, breach discovery and, and always kind of threat intel based critical workflows and, and finding breaches. They can really shorten the, the response life cycle and keep the bad guys out of your network and, you know, reduce that the whole time.

- Would you agree that it's not about being breached, but it's how an organization responds?

- Not really. I think sometimes it maybe takes a breach to motivate companies to avoid another one because they have this, this belief that, well, we're not adventurous. We're just a, you know, insert your benign label there, but companies, they can avoid a lot of hassle and, and save a lot of money by proactively spending the money upfront on the much needed security and response capabilities that they would have spent on the, the incident response process. Like why not spend it ahead of time and avoid the problem and avoid all the regulatory fines you're going to spend the money either way. And probably more, if you get breached, you know, breaches are expensive, you know, in both the direct and the indirect costs, particularly if you're talking about legal or regulatory actions, FTC consent orders, and, you know, nightmares like that. I mean, it's true that the response process is important, but no matter how good it is, it's never going to make up for losing highly sensitive information that could permanently damage your business.

- So on that aspect as well, when you're briefing a board, who's not technical, which I'm sure you have a lot of experience doing, what are the critical metrics beyond just overall events that you've responded to? I mean, I I've sat in board meetings where that's usually the canned five minutes, you know, discussion of just, you know, we respond to this many events, there's nothing further to report. I think that that's, you know, very antiquated. What are the critical metrics that you found successful that boards really start sinking their teeth into and asking the right questions?

- Well, there's a lot of metrics and I, I try to tell stories more than, than metrics that I find they're, they're better. So they obviously start off with metrics. So you talk about the difference, the number of incidents that you have at time and responding, and as well as, you know, all the different types of anomalies. But I think what's more important to focus on is, is that, you know, with, within the audience, you have to find a way to tell a story and their language and show why something is of value to them. And you can really bore people quick with metrics. You know, you need to have trend lines and slides and visualizations and all that, but some boards of directors, they're more technical than others. And, and they're all really very interested in the way that their investments and security strategy is solving problems and what else is needed to keep them out of the headlines and to stay ahead of the curve. So I prefer to talk about how they can proactively solve problems and mitigate the risk as it resonates with the widest audience. And you can talk about how these trends in the industry are affecting, you know, others in, in your sector and or in the customer sector, and basically, you know, put together a plan and show how we're staying ahead of that, because that's really what people want now. They don't want to be reactive. They're, they're ready to be proactive. And this involves really a combination of threat intelligence, identifying how the threats affect companies specifically, and very high level plans and timelines for addressing them and using the appropriate controls.

- You mentioned that part right there that I think is critical of how the threat benefits the company, because you and I both know that, you know, there's almost three aspects to threat intelligence, if you would, you get software that mostly is like a lot of threat intelligence platforms that just this good analytics, and then you have content, which of course comes from a lot of the feeds, which is like you just said, it's okay, here's what this actor is doing against the e-commerce industry. Here's what this actor has done against these numerous businesses. And of course this is then repackaged to ultimately give to a lot of different customers, but it's not exactly very tailored to what the, or what it means to the actual business. How have you found success and actually tailoring those types of activities to the actual business where, you know, a board of directors is going to care?

- It starts with having good asset management, quite honestly, it goes back to know thy network with zero trust infrastructure. And if you don't understand your network, you can't, if you can't say, well, we have an number of these types of devices, and this is a critical threat that's affecting, you know, all of the different companies in our sector who have this type of technology. You just can't make a cohesive argument. So you really need to understand your network and to be able to take whatever is referred to as a top down approach with proactive incident management and saying this critical zero day that's out there affecting this type of technology. We have this in an number of locations across however many business sectors and be able to definitively identify the impact of different types of threats across the environments. And then you can talk about here's what we're doing to, to prevent exploit of this, and basically avoid impact while enabling the business to stay operational. You want to be able to tell the whole story about, you know, how you're solving the problem and not creating another one.

- So context is king, as they say,

- Absolutely

- Colby, your a master of your craft. We appreciate your time. Thank you for everything that you do with the industry and all the literature and all the best practice that you put out there to give the large companies a chance to give medium and small business and MSSP's a chance. Appreciate your time, sir.

- For the latest subject matter expertise around managed intelligence, please visit us at www.nisos.com. There we feature all the latest content from Nisos experts on solutions ranging from supply chain risk, adversary research and attribution, digital executive protection, merger and acquisition diligence, brand protection, and disinformation, as well as cyber threat intelligence, a special thank you to all Nisos teammates who engage with our clients to conduct some of the world's most challenging security problems on the digital plane and conduct high stakes security investigations without the value of the team provides day in, day out this podcast would not be possible. Thank you for listening.