Operationalising threat intelligence is back on topic for the mnemonic security podcast!
Making a return to the podcast is Joe Slowik from MITRE Corporation, where he is the CTI Lead for MITRE ATT&CK and also Principal Engineer for Critical Infrastructure Threat Intelligence. Also joining is Jeff Schiemann, an industry veteran and CISO at one of the world's first crypto banks.
The conversation ventures across how security teams are currently using threat intelligence, the importance of frameworks and standardisation, and the role AI and automation may play for defenders and adversaries. The trio also share their thoughts on a future where threat intelligence decisions can be automated in real-time, and what might take to get us there.
Operationalising threat intelligence is back on topic for the mnemonic security podcast!
Making a return to the podcast is Joe Slowik from MITRE Corporation, where he is the CTI Lead for MITRE ATT&CK and also Principal Engineer for Critical Infrastructure Threat Intelligence. Also joining is Jeff Schiemann, an industry veteran and CISO at one of the world's first crypto banks.
The conversation ventures across how security teams are currently using threat intelligence, the importance of frameworks and standardisation, and the role AI and automation may play for defenders and adversaries. The trio also share their thoughts on a future where threat intelligence decisions can be automated in real-time, and what might take to get us there.
From our headquarters in Oslo, norway, and on behalf of our host, robbie Perelta. Welcome to the Mnemonic Security Podcast.
Speaker 2:In a parallel utopian universe, marketing isn't allowed to name threat actors. There's only one naming convention for tracking and attribution of them, and all the TI people drive on the same side of the road using the MITRE ATT&CK framework. Incidents happen, breach reports are shared, followed by detection and response code that just auto-magically propagates to production. So in this universe the security people are tan as they're just chilling on the beach. So my security friends aren't exactly tan, but some of them actually aren't. So far away from the scenario described previously, and although I've kind of lost my own definition of threat intelligence lately, to me knowing what's going on around the world, understanding the TTPs and implementing detection and response logic seems like a legitimate and sensible use of time for someone working with TI, and today's guests have some experience in doing just that. Oh, and sorry for my sound on this one, I kind of forgot to press the red button on my recorder thingy.
Speaker 3:Jeff Seaman and Joe.
Speaker 1:Slowik, welcome to the podcast. Always happy to be here.
Speaker 3:Thank you Great to be here, Joe. You've been on the podcast before, but this time you are in a new organization. What are you up to these days?
Speaker 1:So I'm over at the MITRE Corporation these days and I'm doing some critical infrastructure threat research and analysis, but I'm also leading up the cyber threat intelligence portion of the MITRE ATT&CK project, which I'm sure many of your listeners are pretty familiar with, because it's a pretty widely used framework across information security.
Speaker 3:Awesome Welcome home. I love that you're in MITRE Makes total sense. Is it MITRE, or how do you say it in the States?
Speaker 1:by the way Mitre.
Speaker 3:Mitre. Okay, cool, in Norway they're called Mitre. That's a little off. Mitre and Jeff, you came. We met at the FS ISAC event in. Where was that? Amsterdam, Amsterdam.
Speaker 3:I forgot where it was Amsterdam yeah, and you came up to the stand with a really cool project and a lot of difficult questions that I had no idea what to do with, so I had to have you on the podcast. That's my defense mechanism. Good to be here and thanks for the invitation. Why don't you give us a little introduction to yourself and, at the same time, segue into the project that you came up to the stand with?
Speaker 4:Sure. So I'm Chief Information Security Officer for a digital bank. We deal exclusively in digital assets, so crypto I'm in a bank is the name, and we're located here and regulated in Switzerland soon to be in Europe as well. So the project we needed to come up with was one on adversary enumeration. We were looking for basically the enumerated plans of adversary actors, threat actors who were going to be and have been attacking us. We think we're pretty much asymmetrical attack surface for them. So we think we're seeing more attacks than normal, since we're in crypto and we're seeing most of the state actors that are seeking crypto to attack platforms like ours.
Speaker 4:So with that, we went to market with a fairly simple approach. We wanted to know how many digital forensics and incident response a provider was doing, turning that into cyber threat intelligence and then turning cyber threat intelligence into SOC operations and detection as code, response as code. And our key goal for doing this adversary enumeration was to get to the detection as code and response as code product so we could better our SOC operations inside of our company. So with that was the second year we'd gone out to market looking for this and again, the key part of this program is to really get through to detection as code, response as code, so that when we're dealing with automated cyber threat intelligence or a platform that, when attackers come in, we can isolate them immediately.
Speaker 4:Something we did along the framework of the MITRE ATT&CK framework is we assume confidential access, so credential access. We also assume defensive agent. So you know, we're purposely holding and fighting with one hand behind our back when we're doing some of these tests. So that's really the project we went to market for and what we're doing now and making sure that when I say enumeration, it needs to be able to discuss a little bit more than emulation. It's not a breach attack path analysis or breach attack simulation, you know. It's not telling you if you're still vulnerable to WannaCry from years ago, you know, or if you're vulnerable from MeToo campaigns. What we're really doing is we're looking at the TTPs the tactics, techniques and procedures of the latest campaigns and evolving that into detection and responses code in our securely orchestrated automated response platform.
Speaker 3:So just to rewind a little bit, you're a crypto bank, so say a little bit about the actors that are up against you like not your typical ransomware actors, or are they?
Speaker 4:We see the Me Too campaigns. Actually, by the time we see the Me Too campaigns, we've usually identified them already in primary campaigns. So there's anywhere between eight to 12 weeks sometimes a little longer, a little shorter for the MeToo campaigns, when primary campaigns get sold on. But basically, our nation state actors that we're seeing are APT38, lazarus Group and all of their affiliates and anybody else interested in crypto. They know where we live. We can't change the address of our bank, obviously, and we deal exclusively in Bitcoin and Ethereum and different protocols thereof. So, yeah, it's something we look at every day and when we see them, we call them Choson. The name for North Koreans is not North Korean.
Speaker 3:The.
Speaker 4:Americans are not called the United States of Americans, they're called Choson. We see them enough and more often than we want, but that's why we think we're an asymmetric attack service. We're seeing them more often.
Speaker 3:And you also are doing this all in one platform which is interesting to me.
Speaker 4:We're doing it completely in one platform. Why is that? By the way, basically, inside of one platform, inside of one cloud, we've basically limited a lot of our security vulnerabilities. If you have multiple data islands and multiple data clouds, you actually start to magnify your risk, obviously confidentiality and security risk. Of course you improve your availability, right. Maybe you also decrease your integrity because some of that data can be attacked. But we chose a single cloud provision, a single MDR, a single SOAR platform, all unified in one of the big three cloud providers. That gives us much less attack surface to be addressable and much more flexibility and the ability to see across the estate, whether it's in servers, endpoints, containers basically everything that we have.
Speaker 3:Awesome. What do you think of this? So far, Joe? I have more questions for you, Jeff, before I go over there. Does this sound like an interesting approach to you, Joe? Is this something that you see on your side of the world very often?
Speaker 1:Right, it is a very interesting approach. I have to confess, I don't know much about the operational side of the cryptocurrency space. It's not something that I've been involved in but I do know from a attack, cyber, threat, intelligence perspective that cryptocurrency as an objective for adversaries is certainly wide ranging, from adversaries that are more end user focused in doing things like implanting cryptocurrency miters on victim machines or a variety of objects, but then, as Jeff was saying, you get into your state-sponsored, state-directed adversaries like a I hate using the term Lazarus because Lazarus is such a murky term, but you know essentially. You know, looking at what's been published by both threat intelligence industry, commercial entities, as well as news coming out of US government and other government entities, the North Korean directed actors have really leaned hard into cryptocurrency theft and abuse as a way of funding the regime, which is pretty wild when you think about it, that there is a tendency for some to just sort of shrug off like, oh, cryptocurrency, it's fake money, like who cares, Until you realize that there is an entire regime that is basing a non-trivial part of its ability to fund itself on being able to steal, siphon or otherwise execute transactions with these platforms.
Speaker 1:And you know it's a real concern and it's also something that, from the attack perspective, as a CTI object, one of the things that I have on my to-do list is to try to unpack some of these adversaries, especially the entities that have been related to North Korean interests or North Korean state operations, because there's been a sort of historical sloppiness in sort of accreting various sorts of things together so that you have this ball called Lazarus or even APT38.
Speaker 1:I mean no offense to the folks at Google Cloud or whatever, but it's very difficult to try to unpack different degrees of this when using a behavior-based clustering approach, like one fueled through MITRE, ATT&CK, behavioral objects or technique tagging or whatever, that you see lots of overlapping entities inside. But from an operations security operations approach, what Jeff is describing, I think, is not just a very appropriate way of dealing with these sorts of issues but also a very emulation-worthy approach for a lot of organizations in trying to really increase automation, increase that speed of identification, action and response related to intrusions, irrespective of your industry. So what I'm hearing as far as what's being put in play, irrespective of you know what vertical we're talking about here really represents a sort of best of breed in my mind, for you know how do you do these sorts of things.
Speaker 3:Jeff, how many banks are there in your space? How many comparable institutions are there in the world? I've only heard of like three. I know you're friends.
Speaker 4:Yeah, exactly, there are about a dozen of us in the space, in the regulated Swiss space that are different types of institutions, so we're called custody provider, custody provider in also Worm Mollets Trading Solution, and we're also in private and do-wealth individuals and smaller banking, international bank institutions, so there's a niche for everybody. It's a $3 trillion market business sort of, in the crypto world. So current crypto value is around $3 trillion and there's a good portion of that now being held by institutions like ours that are regulated and seeking more regulation. So gone are the days of sort of the fly-by-wire unregulated institutions. There's still a few out there, but most of the money now has boiled up into the institution regulated institutions.
Speaker 3:Crypto made it to the big stage.
Speaker 4:Yes, it has.
Speaker 3:No, it's there, Welcome. So basically what you're trying to do, your goal basically, is if something happens out there in the wild, you want to basically know that it's there, understand it and be able to write defensive code. And you call that just heading at the speed of the threat. Is that correct?
Speaker 4:Exactly. And so speed of threat versus speed of vulnerability. Last year we had 28,000 CVEs vulnerabilities and that's really something for IT. I mean, try 28,000 things to patch, repair, replace, get rid of, take out of the infrastructure, do something to mitigate, right. But I'm looking at the speed of threat. So there are about 11 million TTPs tactics, tactics and procedures a month, from 100 to 150 threat actors running between 300 and 500 campaigns. So what I'm really looking for is that type of speed of protection in the network so that when we first see something like the Klopp ransomware gang that rolled out the Moveit breach last summer we just happened to have completed our first round of adversary enumeration We'd run about 80% of that campaign. We hadn't run the specific breach against MoveIt, but we knew our detection kill change would catch that software as soon as it landed. It never landed on our shores, thankfully, but we do know that we would have caught it by because we were running the type of campaign that it was based upon.
Speaker 4:And threat enumeration, threat informed defense and adversary enumeration really flips the script. It goes from having to be right every day and the attacker only has to be right once to being only right once. As a defender, the attacker has to execute 70, 80, 100 steps in their campaign perfectly. They have to execute every step and not get caught, because if we catch them in one step they're scrapped right. The whole campaign will collapse. We can stop them on one PC, we can isolate it on one server, on one device. So that's really the important parts about threat-informed defense. It's really changing the mode of operating Isolate first, triage second, looking for ways to stop the attacker in your environment, and that's really the most positive benefits that you can have when it comes to security operations.
Speaker 3:I mean isolate first, tree out second. That's awesome, I guess sort of unique in your approach. How has this journey been like, the whole setup thing? How did you get here? How long did it take you, for example?
Speaker 4:Yeah, interesting.
Speaker 4:I've been CISO for the company for three years this summer and I would say on the initial time coming into the company it was something I wanted to do.
Speaker 4:I had also looked at the Cyber Threat Alliance, the CTA. That started back in 2013, 2015, when I was working for a large telecommunications provider, trying to get that provider to contribute cyber threat intelligence, or what I call cyber threat information, into the pipeline. So after leaving that organization, I came into crypto and I always had this idea in my mind that if I came into crypto and I always had this idea in my mind that if I came into a position of a CISO again, that I would move that organization into fully security automated response. So not just a security orchestration tool that puts some humans between cyber threat intelligence and then rolls out a few limited, orchestrated playbooks but really, you know, in just millions of pieces of cyber threat intelligence at the speed of threat, like I said, to 11 million different pieces a month, and then make automated decisions based on real-time threat intelligence and we sort of take the risk that one of our CTI providers might blacklist all the Microsoft IP addresses one day, right, but it'll be fixed five minutes later, if not five seconds right.
Speaker 4:Google blacklisted and corrupted their own DNS pool for their own access to their own buildings right, but they fixed it and they won't ever do that again. So you know we do take some risks that things will fail closed in our world, but in the crypto world, we'd rather have them failed closed. We're protecting confidentiality of private keys. We're just not protecting integrity of private ledgers. Our ledgers are all held public in the public blockchain, so for us it's an all or nothing risk when it comes to the private keys of our assets. If they're lost once, they're lost forever. And when the blockchain and Bitcoin's case updates, every 11 minutes or so, on the 12th minute, people will know where you sent the money, who received it, and probably by minute 15, 16, 17, you'll be getting a call from a regulator. Why did the money transact from your institution to an OFAC banned wallet? So these are real risk cases for us and this is why we take it very serious.
Speaker 3:So, joe, you're my CTI guy. Yes, why haven't I heard this sort of request coming from more customers before? It sounds like a really novel proper approach to CTI and how it's integrating with defense operations. What do you think?
Speaker 1:Well, I think this is a common request and a common ideal. It's just one that's been very difficult to move towards because, if you look at cyber threat intelligence and its evolution where it started, kind of where it is right now, we talk about the transition of disciplines from being an art form to a science. So CTI still largely resides in this sort of artistic, bespoke whatever pick a fluffy adjective or whatever to assign to this realm, where you have different analysts approaching the same sort of subject matter, the same intrusion, the same data set and providing their own interpretation of it, which makes trying to arrive at consistent, machine readable, machine actionable outcomes very difficult. So that's where something like you know the so what behind MITRE ATT&CK, going back to its genesis almost 10 years ago now, is that ATT&CK provides the plumbing or the mechanism through which to begin discussing and highlighting the context around individual technical observables or events, to give you a sense of what is actually in play here what does something do, what is its purpose and the adversary's overall life cycle. So the way that I frame this typically is like attack is not like the laws of gravity, in which case everyone's going to obey them because, like you, can't get around it, but it's more like what side of the road do we all do we drive on? So it doesn't matter which side everyone drives on the road, just as long as everyone in the same area does the same thing.
Speaker 1:Orientation to individual technical observables or even narratives around adversary activity in a way that enables what Jeff is trying to do, so that it's not just analyst A's fluffy language around some activity compared to analyst B's fluffier language around the same activity, but being able to compare those directly to one another based upon the reference to a common language set that ATT&CK provides. So that when Jeff ingests this from the multiple different threat intelligence providers, there's a commonality behind what it is that they're referring to. That makes this machine acceptable, machine readable and, if you can combine that with other frameworks, so there's MITRE defend, for example, mitre embed if you're talking about IOT and similar devices, that can start pushing that from not just the CTI labeling standpoint which, when you say it that way, it sounds like well, it's a labeling schema. How? Why is that important? Well, it's very important because, lacking that, you have to have a human in the loop doing hands-on interpretation of results in order to drive things over to a concrete action.
Speaker 1:If we've agreed upon a common labeling schema and are adopting it and implementing it consistently, then the sort of detectionist code, responses code and so forth that Jeff is implementing with his organization now become possibilities that we can engage in, which is a very powerful position for organizations to place themselves in as we see adversaries increasing the sort of velocity of their operations as well as the volume of their operations against high-profile targets of interest such as financial organizations, not to say not to even get into things like government, military and classic intelligence targets and so forth.
Speaker 1:So, in looking at this from the CTI perspective, really what allows for and Jeff certainly correct me if I'm misinterpreting what you said earlier but the key enabling factor in getting into a position where it's not just a artistic process of CTI analysts conducting some bespoke analysis that then gets moved to a security operations center analyst or incident responder or similar who then takes a similar interpretive action on that common set of data, but standardizing a lot of that flow so that initial CTI can be tagged and classified in such a way that allows it to be fed into an engine that can take pre-programmed or predetermined actions on that data set, based upon hopefully accurate labeling to speed up that response and mitigation process to really place adversaries at a disadvantage process.
Speaker 1:To really place adversaries at a disadvantage, which gets us to a key point that I think CTI needs to adopt in something that is near and dear to my heart, in operationalizing cyber threat intelligence. So it's not just here's a 10-page book report on whatever we're calling the Lazarus Group these days, but rather here is a concrete set of actions that you can take within your environment in order to take activities that map to what has been observed in Lazarus activity to identify, detect and defeat this adversary should it manifest in your own environment.
Speaker 4:Yeah, beautifully well said, Joe. And so, absolutely, in our adversary narration approach, we look at our bad actors, whether it's Scattered, Spider or Lazarus, all the different ones we're looking at. We're just looking at their TTPs, right, we're looking at exactly that behavior. And I would say something to all the CISOs and technical people who are in charge of vendor relations and buying any services that if you're buying a product today that doesn't use the MITRE mapping, just stop it. Stop funding projects and products that are using, you know, bespoke classifications, because what we need is this data normalization. We need the standard schema in order to make things faster on our response. And this goes all the way back to Styx taxi servers, from the Cyber Threat Alliance to version two that most people are rolling out now.
Speaker 4:And if we can get that digital forensics, incident response artifacts found through lots of high volume DFIR and get that turned into really good cyber threat intelligence that doesn't need lots of hairy artistic explaining, right, you know, when Bach wrote the note B-flat, Beethoven understood it as a B-flat, right, they weren't writing some ancient code, you know, and everybody understood what that B-flat meant.
Speaker 4:And then we need to turn it into SOC Ops very fast and that really leads this sort of triangle DFIR at the top, CTI at the bottom left and SOC operations at the bottom right which is detection as code, response as code. And we're starting to see a lot of the benefit of AI happening at the digital forensics incident response, also happening internal to cyber threat intelligence but also happening internal to SOC. We think the real acceleration will be when one AI tool can look at a digital forensics incident response and turn it immediately into obvious CTI and turn that CTI immediately into detection as code, response as code. Our current triangle, we think, is running somewhere between seven and 10 days. I foresee a future not long away, maybe five, six years, where we're seven to 10 hours from DFIR artifacts being turned into CTI, being turned into let's call it the easiest detection as code, response as code, SOC operations.
Speaker 3:Wow. So if I understood that correctly, so right now you from saying something somewhere in the world within 7 to 10 days, that'll go from you saying it to you and Jesse and your systems to be able to respond to it and isolate whenever it occurs, right?
Speaker 4:That's basically what we think is happening now. When we tend to see things on our financial services information sharing analysis center, we tend to see about a two-week lead in IOCs and or TTPs, indicators of compromise and or tactics and procedures, and I think we're going to live in a world soon maybe five years is even too long where that's going to be three to seven hours, not three to 10, seven to 10 days. But the real key thing there is every individual area is focusing on AI. What I'd like to see as a provider look at DFIR, cti and SOC Ops as one whole piece of AI, not just digital forensics, artificial intelligence, not just SOC operations like a co-pilot tool, not just CTI or in sort of helping the analysts analyze better. Remember, my world is all about isolation first and triage second. I want a real active tool that goes out and isolates things and critically looks at analysis and gives us reasons then to release it if it's not a bad actor.
Speaker 4:Speaking with one of the major vendors today, they understood my problem that their tool was too expensive, and I flipped the point on their head and I said no, no, your tool doesn't allow me to use it, just for the most critical cases, I would pay you 10 times more for your tool, but I need to tag it just to the artifacts of my organization that are critically important to me, and then I want your AI to deal with those in a responsible way. And this is a major cloud service provider who's just rolled out their AI in the last couple of months and it's just not tameable and it's generating huge costs and it's firing on every informational alert that you have. And what I need is I need to just to fire on the pieces that are critical to my infrastructure and provide us better value there.
Speaker 3:And when you say AI in this DFIR triangle of yours, it's not just an LLM right, Because I understand an LLM can read, ingest information, but you also need some system to actually do things. Exactly what kind of AI is that? I don't even know what that would be.
Speaker 4:Yeah, we've had several discussions so far with people about collecting different types of AI models. We want to buy it. We're not trying to build the world here, but what we see is people with digital forensics, incident response. They're collecting all the artifacts and their LLMs and AI in that world are basically separating indicators of compromise from TTPs and they're starting to see some speed in that world of separating those artifacts and then sending them over to CTI people to be categorized whether it's in tool categorization or whether it's through automated categorization to be ruled out and then tested. And then we're seeing also inside of the SOC operations, just that type of response. But so far we haven't seen all three areas connected by a single tool. We're only seeing the acceleration and digital forensics and response becoming quicker. We're seeing the cyber threat intelligence classification becoming quicker and we're seeing SOC operations becoming quicker, but so far the highway between those two really hasn't got any quicker.
Speaker 1:Do you have any comment to this, joe, before I move on to some more questions for you, so I'm not even going to pretend that I'm an expert on artificial intelligence, and there are a number of people at MITRE who know far more about both what it is we're doing in that field and where it's going.
Speaker 1:The only thing I can comment on, at least from a purely CTI as well as security operations perspective, is that it certainly is the future.
Speaker 1:Operations perspective is that it certainly is the future, but even as part of that, I think one of the things that we're witnessing when it comes to throwing artificial intelligence at complex problems like cyber threat intelligence, security event disposition and similar, is that we're dealing with very complex, very nuanced sort of data sets and, as a result, the same thing that we talked about earlier in terms of appropriate use of standardized language and classification for these items is going to be necessary in migrating between initial event categorization how individual event observables get stored in your threat intelligence platform whether it's a MISP, an OpenCTI, a SIDAPS or one of many commercial vendors and then how that gets integrated into your security orchestration, automation and response or your SOAR platform to then take action.
Speaker 1:That that entire pipeline, even if we're having machine-generated analysis and response feeding that is going to be very brittle if we're still living in an area of very inconsistent ways of analyzing, identifying and flagging data and data analysis throughout that pipeline. So, as much as people might want to look five years from now, that well, ai will save us, it'll solve these problems for us. That we still need to eat our cyber vegetables, so to speak, because, to use a scientific phrase that I'm very fond of, I hope your listeners don't mind this, but stuff in, stuff out, so to speak, really does hold true Junk in, junk out.
Speaker 4:Yeah, exactly, and I completely agree with you, joe, that standardization in our detectionist code and responses code was KQL. It has always been KQL, so people will know what Thor we're using. Based on that, two years ago when we started, we couldn't get anybody to agree contractually to write our detection responses. This year that was a make or break of the contract and we got two providers willing to do that for us. So, yeah, we're starting to see more standardization. But again I put this square at the feet of every CISO out there Buy what you want, don't buy what the market has. If you have money, go get the market to build what you want and build it on standards, because money leads and, as they say, other stuff walks.
Speaker 1:Yeah, that's very true. It does place a lot of organizations in a difficult position though, because certainly, if you're a well-capitalized, well-resourced organization, you can start demanding things of vendors or just have the resources available in-house to build your own at that point, but there is that long tail of other organizations. Whether we're talking about hospitals I don't know if anyone's seen the news today, but there's a major event going on in the United Kingdom right now where a critical services provider was hit by ransomware that's impacted service delivery for multiple hospitals in the London area right now. Var various examples such as this. Where do these organizations have the heft to demand this?
Speaker 1:And, if not, how do we sort of square the circle between yes, you know Jeff's organization is doing a lot of the right things and has the heft and the wherewithal to do so, but how do we start translating what Jeff and similar entities are doing down to the less privileged or the less enabled?
Speaker 1:And I think that's one thing that's been encouraging to see within this space is that MITRE ATT&CK has definitely been a boon for much of the industry in terms of just drawing a line in the sand, and it's like here's a framework for standardizing your language and how to refer to security events. That's great. But then as you start adding other frameworks that have emerged over time, like Sigma as a detection language, for example, that has really driven a lot of standardization around how to write detections for host-based systems and so forth and if we keep pushing the envelope and if we have the sort of high profile, very important customers like Jeff's organization and similar demanding these sorts of applications, that I think it will help drive the market to a point where other organizations will see that well, we don't have a choice and this will trickle down. I hate this phrase trickle down because that brings up certain other implications, but in this case it might actually be true of demanding that vendors what's that?
Speaker 4:Let's say boil up, boil up, there you go.
Speaker 4:We boil up from where the funds are and, having been a provider for 20 years, there was nothing more motivating when a customer came into the office with a check and said build it. And even though the first couple of things might have been rough, or the first couple of things we built might have only addressed one or two problems, that's where really the ingenuity comes from, and I challenge every CISO out there you know, save your Friday afternoons. You know four hours and go, listen to. You know every week four or five different pitches and find out. You know what people can build, what people want to be doing, and then come with good requirements, like we did.
Speaker 4:Adversary enumeration Didn't come from ourselves. Some people at Y2K Networks, rick Howard and some other people, had been talking about it part of the CyberSmart Alliance for years and how to do adversary enumeration. We don't have a whole CTI team. We bought all these pieces right. We're a small team. We went to market, we bought it for less than seven figures, and so it's something that you could throw a whole team of 20 people at, or you could buy it from the market and build a bespoke arrangement for it.
Speaker 4:So one thing I'd also say is I mentioned this earlier, the market segregates itself fairly easy.
Speaker 4:So if you go into the market as a CISO and you've defined what the terms are like cloud computing or native cloud computing then when you talk to a vendor, don't let them to sort of thrust you in their version of it, right?
Speaker 4:So everybody says, oh, we're native cloud and I'm like well, my definition of native cloud is in my cloud, in my compute and in my storage, which means if you're not in my cloud I don't want to talk to you as a vendor. You might have the most perfect solution, but if you're not in my cloud using my compute, my storage, which I already pay for, I'm not interested. So have good definitions like adversary enumeration rather than emulation. It's not ready to light campaign as one of these actors. It's running the latest TTP campaign in your infrastructure and then hold vendors to that and that will sort out out of the 600 or 700 different security vendors that there are selling all the different products from data, applications, networks, users, identity. You know that sorts people out very quickly when they have to deliver to the definition of the customer okay.
Speaker 3:So, jeff, you mentioned earlier your triangle, right, the seven to ten days right now, and you want to get that down to seven to ten or three to seven, one of those hours right, yeah and obviously in to do that you have to use AI, lms, the whole automation thing, whatever you're going to call it then.
Speaker 3:And I'm just thinking, if you do that and the bad guys have to do it or else, then we won and then the game is over, right? Um, to be great, but I guess that's not going to happen. Um, and I guess it's a very cheesy question, but uh, and you guys are both now attack-related. Besides them using chat-to-petites and writing good phishing mail, have we actually seen this anywhere?
Speaker 1:AI attacks- so there have been reports of artificial intelligence of the LLM flavor being used to drive things like target research and target development. Microsoft has noted, openai has noted that adversaries have been abusing these frameworks for research, development and other purposes. So we're seeing adversaries begin to at least play around with what's available right now to speed up and enhance operations in terms of developing not just phishing or social engineering payloads phishing or social engineering payloads but also to try to speed run things like what does a certain organization look like or can I do some sort of vulnerability analysis at scale, leveraging an openly available model or similar? Having said that, you know you'll see stories mentioned about the possibilities of artificial intelligence being used for AI-developed malware and things like that. Well, we've had polymorphic malware and things of that sort for a while now and doing things like vulnerability fuzzing is also not a new item. But I will be interested in seeing, because I haven't. You know, from a MITRE ATT&CK perspective, we certainly are being very much, you know, nose to the ground, ear to the ground in public reporting to make sure that the framework is up to date in capturing the best of breed of what's going on in adversary space and I am not yet aware, at least, of any public reporting where adversaries have leveraged artificial intelligence capabilities for things further along the adversary life cycle to date.
Speaker 1:Will that change? Almost certainly Can I predict when. No, that'd be a losing bet. Most likely it will happen at some point. I think there's too much development, too much interest and too many resources being shoved into artificial intelligence research. That it's an inevitability, but when that becomes a reality, I think, is an open question right now.
Speaker 4:I'd say the same thing. We're in the same position. You're at a ground waiting for the first vibrations. We know it's going to happen. We can't hold our breath to the moment that it happens.
Speaker 4:We have to prepare ourselves for it, and what we're really thinking about is this circle around the triangle, and this is where we go from unscalable attacks, pegasus, eternal Blue, ntc, vulcan, something that's out there in a government capability or a state actor capability, but it's not scalable right now. Right, it's used, but it's used very limited. Whether it be Stuxnet's virus, anything of that, it's used in a very focused way, and what we're concerned most about is something moving from the unscalable to scalable, because as soon as it becomes scalable, it's then used and usually found in the digital forensics, incident response and in the history sort of of where we are in cybersecurity. That blood-brain barrier, that border around scalability and scalable and non-scalable items, has traditionally been very hard to overcome.
Speaker 4:If AI breaks that barrier down, or AI accelerates that barrier, that may be the flood that we see turn back in favor of the attackers. I would say, though, today, if you're practicing good defensive threat, informed defense, and you're doing adversary enumeration and deploying kill chains, and you've now living in this mantra where we've now the attacker has to be right every time and the defender only has to catch them once inside of the kill chain. You know, right now I would say the defender has the key advantage using those tactics. Um, if they're not using those tactics, then of course the defender's still on the back foot. But my real concern is when I think we all think it will sooner or later break that barrier, or that barrier then starts to accelerate from unscalable technology to scalable attacks.
Speaker 1:So I will add one thing because you mentioned, jeff, something very near and dear to my heart. You slipped in an NTC Vulcan reference in there and Robbie's familiar with my work in analyzing that set and presented at DEF CON and Brew Con. Was that just last year?
Speaker 3:That was last year.
Speaker 1:Yeah, wow, time flies. But I think what you're talking about in terms of frameworks is definitely something that's worth emphasizing here, because some of this work already exists, whether we're talking about the ScanV project with NTC Vulcan that's linked to Sandworm operations associated with Russian state-sponsored operations, or research into the Volt Typhoon-related botnets and then other PRC-associated botnets that Mike Ragge at Google Cloud recently published research on. Mike Ragge at Google Cloud recently published research on well written, I think he's presented at a couple of events or whatever on this at the stage that we've seen a lot of very concerning adversaries even a Lazarus, like we were talking about from a cryptocurrency targeting perspective but very concerning adversaries that have targeted critical national infrastructure and similar, that have leveraged frameworks for doing things like building infrastructure to stage and even initiate initial access and then follow on command and control. And the interesting bit about this, and something that I had mentioned in my DEF CON presentation last year, is taking something like a ScanV, which already adds significant degrees of automation in terms of target selection, target exploitation and target management, and then, if you're able to adapt a artificial intelligence capability on that, it doesn't shift the narrative so much, but it does speed it up if that makes sense. So that's similar to what you're talking about from a defender perspective of shifting seven to 10 days to seven to 10 hours.
Speaker 1:Now we're talking about doing that from an adversary's perspective where, oh, my intermediate infrastructure for attack and for command and control purposes has been burned by the FBI or UK NCSC or whatever. What do I do? Operational relay boxes or orbs within a matter of hours, based upon capabilities that I have at hand, and then resume operations as though nothing ever happened, placing the defenders on the wrong foot. So I think that's a very important thing to emphasize, and a point of worry is increasing the velocity of things that are already out there, like Vulcan leaks, the Pierre Sievel typhoon botnets and other items, and what implications that may have in terms of the whack-a-mole of going after malicious infrastructure for defenders, especially defenders that aren't as well-resourced or are disadvantaged against these adversaries, like utilities in Guam or similar sorts of entities that find themselves in the crosshairs of these organizations based upon public reporting.
Speaker 4:Yeah, I think you're exactly right. And you know, when people finally see adversaries that have their own content distribution networks for their C2 command and control infrastructure, it's not just turning one server off, right, I mean, they are resilient, as you say, call them, in this orb infrastructure, and when you know you see a pass off between one c2 server to another, uh, and basically they're ensuring their own resilience and attack. Yeah, we have to take them more seriously, and so that'd be my advice to everybody is this this stuff is already out there in deployment.
Speaker 3:Yeah, well, we see this, or like uh, when this happens, this like uh I won't call it doomsday scenario, because it's going to happen here soon Like, what's that going to look like?
Speaker 1:Well, I think it's a race condition to a point, because you development, including projects that are being worked on within MITRE to try to improve defender resiliency, the speed of defense and ways of enabling the sort of you know the piping, so to speak, to allow for improved, enhanced and speedier decision-making for defensive frameworks, even looking at things like the MITRE Embed, mitre Defend-related projects to take things like the ATT&CK framework and start applying that in machine-readable and machine-scalable ways to defensive decision-making. So it's not just about waiting for the bad thing to happen. There's a lot of co-evolution going on here between adversaries and defenders. The open question is you know who gets there first? And I would say the main question in my mind is how do we ensure you know? Mitre is a non-profit organization and the tooling that we make available, like ATT&CK and so forth, is freely available to everyone, which is great. We've been lucky in that other tools that have been developed in this space, like the Sigma framework for detection engineering, have also been made available freely as a standard by the developers behind them.
Speaker 1:My worry is that as we look at things like the way that capabilities will expand to things like criminal actors, whether a scattered spider or a lockbit operator or similar, that we're ensuring that it's not just the most well-resourced organizations that benefit from this, but that we have a way of extending this defense to others, so that epidemics like the ransomware you know, just horror stories that are out there or business email compromise and similar, that we're also fighting the good fight against these entities as well and enabling organizations that find themselves victimized can benefit from these advances as well.
Speaker 1:Because if we don't, you know, if it's just the haves and not the have-nots that are benefiting from these advances, we're putting ourselves very much at a level of societal risk, in my opinion. So that's the main worry point. Like, I think, defenders, the large organizations of the world or whatever, the well resourced organizations aren't going to be fine. Be fine, there's going to be some struggles or whatever, but overall they'll be able to co-evolve with adversaries to defend themselves. But if we don't ensure that some of these capabilities and benefits are also available in some fashion to hospitals, school districts and local water utilities and so forth, then we have to ask ourselves okay, are we really putting ourselves in a position where we'll be able to disadvantage adversaries everywhere? That's necessary, because then we wind up with some real, significant negative externalities within the security space, then I'd agree completely.
Speaker 4:There's a book called Cyber Persistence Theory. It's right over there. It's a fantastic book, great, you have it on the shelf. Mine's just fantastic book, great you have it on the shelf Mine's just behind me.
Speaker 4:One of the people here from Zurich contributed to that and also University of Cincinnati two different organizations I've been proud to be a student of at different times and basically it's just saying about the same thing we need to stay persistently engaged in this area of cyberspace, of cyberspace. It's not going to be the whopper and the war, cyber war right, it's a consistent engagement. It's like the cavalry knowing where the army is. Only bad things happen when the cavalry loses control of where the infantry is and then you get something like Gettysburg or Waterloo. You get a disaster, right.
Speaker 4:And it's about staying engaged with those threat actors to monitor them, because the threat actors live in a competitive ecosystem. Today, when we're seeing, you know, campaign burning a zero day, they're burning a zero day off of curated monetary attack list because they're worried that the other competitor in that same ecosystem may find the zero day and burn it before them. So you know, these are competitive threat actors. They're not burning a whole campaign of zero days, right, they're burning monetizing time to market speed, to return, basically in their own ecosystem against their own competitors. So think of it as what I call the evil Formula One race. Right, they're out there racing their evil Formula One cars, but they're only racing the zero days against each other, and so if we benefit from that as defenders, that's the way to take away a better feeling about doing adversary.
Speaker 4:Enumeration is 90%. 80% of those campaigns are stock off the shelf. Things we can defend against the zero day almost never, right, we're almost never going to match that one zero day. But if I can block 80% of the rest of that campaign, so what if they found a zero day on data exfiltration? They're never going to get there to execute it.
Speaker 3:So it sounds like if I'm going to sum up defense is still winning. We still have a chance. There's hope out there and I have a little bit right, we're not losing.
Speaker 1:How about that? We're not losing we are working the problem as best as we can.
Speaker 3:And the second thing is that there's two people that I really, really respect that just admitted that AI is real and it's there and it's being used on both sides. All right, gentlemen, thank you so much for your time. It's been a pleasure. Jeff, keep up the great work, and you too, joe and Mitre, thank you so much for your time, any closing thoughts.
Speaker 4:I think we covered everything. Joe, thank you for your input, always awesome, as always.
Speaker 1:Pleasure Jeff.
Speaker 3:Thank you, robbie, great Thank you. Thank you, gents. All right, gentlemen. Thanks guys, have a good day. Ciao, ciao, thank you Bye. Thanks for watching.