BSidesATL 2015: Operationalizing Threat Intelligence by Willard Dawson

This room is frightening. I I I will probably get nervous and stammer a bit, but hopefully you'll take that in in stride. So, um let's just get started. I actually gave this presentation uh some of it at an ISSA conference this last fall and there were all of three people in the room and that was unfortunate that it was because there was a lot of other exciting presentations going on. So there's one benefit from having a single track and that is you don't really have any options. your captive audience other than you know if the beer shows up and you all leave I'll know it's uh frighteningly boring but uh yeah so I I actually started off my career in

chemical engineering and that didn't work out so then I went back to music and eventually became a computer scientist so it's been a long crazy road um a number of roles that I've had there but uh my present role is the thread intelligence manager at a Fortune 100 insurance company who I will not name by name because they have not cleared this talk. So um my management has but we have uh as you might imagine in a large organization of that nature and we'll get into that more as presentation proceeds a lot of legacy controls especially around what you can and cannot say and what you can and cannot share and what you cannot publish. And

so there's a a very uh selective set of things that I can say with official official sanctions. So to give me more uh leverage and more freedom of speech will just not involve them directly. So most of my experiences that I'm talking about actually do come out of that work environment. So you may or may not find how many work for well how many work and probably I'm guessing probably for medium and smallsized businesses and maybe a handful of large corporations. So your your your experiences will vary quite widely. Of course there is speaking of varying widely a lot of dissension about what is actually threat intelligence. So this definition actually comes from Gartner and seems to be a popular one at

least in some of the marketing press that you find. Um it's not not a bad one to work with, but basically we're looking for evidence of compromise or indicators of compromise or things that might tell us that bad things are going on and we want to see that in an informed way with context that allows us to apply it to our own business environments. And not only that, we would like to at some point be able to leverage that information to give us a predictive capability. So there's a lot of expectations that are coming associated with threat intelligence and what we do with that. That's probably difficult to read. Why do we really want it? Touched upon

some of that now, but we really want early warnings so that we can have an adaptive response and we can make more effective incident response. But not just incident response. In many organizations what we find we're we're actually reactive. We're not really setting up response but just day-to-day reaction from a lot of things that are going on. Even with groups that are mature in other aspects of their security infrastructure or their SEC enterprise security architectures, incident response in my experience has been a relatively weak area. Um but that again based on my actual experiences. Um, different companies I've worked for have had really mature incident response capabilities, others not so mature. It really is kind of all over the map. Uh,

this idea of adaptive response is, I think, important because what we really want to eventually get to is not just incident response, but a continual adaptive response. So, there really isn't an eb and flow between actual fires that are occurring, but just day-to-day handling of what is normal business. I think part of the mantra that we've we've heard recently and we see it more in the news there more companies that are being breached on a day-to-day basis establishing an expectation at the board level that we will be hacked. Hacking is an inevitable occurrence and you should simply be prepared to respond to that in a timely fashion. That's a a paradigm shift especially at board level in and executive level

management in companies because until recent times the the strategy has been let's avoid being hacked altogether and if you did get hacked then that's your it's time for the pink slip of the seesaw right it's time to get him marching out the door and bring in another regime who basically goes through the same exercise in another six to 12 months and and I think as as large breaches occur on a more frequent basis fewer fewer CISOs are going to lose their job as a result just a personal opinion and that's probably a good thing because you really need continuity at that level. So driving better, more effective incident response. It's tied very closely to incident

response. I almost have to start this talk with venting. And so this is my venting slide. What have what have I had, you know, years years of going to Blackout and Defcon and my justifications for going were maintain situational threat awareness. What's going on? What what are what are the bad guys doing that we need to defend against? Whereas a pentester, what what are the key areas that I need to be focused on to keep my skills sharp? So, uh problem is executives and management didn't always get on board with that argument, right? Oh, you you're going to Vegas to party. what are you going to learn out there, you know, uh or you're you're just hanging out with a bunch of

guys that just like to drink all the time. Well, yeah, there's a lot of proof to that, but um but there there really is a lot of value to be gained from these these community- based sharing exercises. And I think finally finally we're seeing staff and or and at least in my personal experience, I'm seeing executive management that's getting on board with that and it comes in no small part to uh regime change. So the old guys are retiring and leaving and we're bringing in new people who have the right threat or defensive level posture mindsets. So those antagonistic CISOs are are starting to go away. Um the negative views of hacker history still lingers, but I think we're working

through that. We have some more psycho analysis sessions. Maybe we can admit that, you know, we have issues and start a 12step program and leave our hacker sort of history behind at least for a bit and put on a clean white shirt when we go to work instead of a black one. Oh, wait. Um that that that the paradigm shift now beyond just mindset is getting budget and that has been at least in in my current situation getting money to stand up a program is a problem and uh part of that is you you really have to show the the financial justification. What are you going to deliver as a threat intelligence program that the business will find useful?

show what the expenses are going to be and you've got some clear expenses that are going to start coming out of of once you start looking at the architecture of how you implement threat intelligence. So their costs are going to be associated with people with implementing processes that have to integrate with existing business workflows and there's there's costs there but there's basically baseline project costs because you have to have these internal projects to integrate your existing business into what you plan to do as a threat intelligence group or person within a within your companies. So these these are hidden costs that you may not have thought about but they really are there and you have to still make the

justification in terms of people time to executives that as you you try to implement these programs. Um yeah, not having a dedicated team is a real problem. And for me, uh being that guy who came in wearing a lot of hats, being the the the token hacker that was brought into the larger security group and and being for a while the the sole enterprise architect for the company for uh security architecture when I was then given the role of being the threat intelligence manager, I didn't really get to put those roles aside, right? So I basically had to well keep shifting the hat all the time. And that really is a problem when when you're still you're tasked with actually

doing threat intelligence uh collection and analysis and doing reporting but also writing program documents around that and oh wait you still are on all these other review boards there really just there's no time. So the the thing that you really probably have to accept is you know that that 40 or 60 hour work week now just became an 80 or 90 hour work week. Yeah. Really at least. Yeah. Exactly. Well, for some people maybe. So, I'm I'm reaching an age where it's it's challenging. It really is. So, what work life balance? It's uh yeah, forget about it. At least in my case, it's uh I think we eventually want to get there because that I think is important that we

maintain that because we'll start having burnout. If you're not already burning out, you will be burning out the more you try to do of this nature. Just my experience, I am worn out. Uh I I've kept some slides in here that I I had from previous talks and we'll just kind of breeze through those. But really there's integrations that you need to do into your existing enterprise security architectures and and if you haven't done those architectures, it's important that you take a step back and say, am I really ready to implement a threat intelligence program? Because I think a threat intelligence program is really more of an advanced topic. So, if you haven't done the basics, it's

probably time to to step back and evaluate where you are in your security program. Say, have what what's what's left to do and and when when is the right time to start thinking about plugging things in. So, you can always find useful reference architectures. In my case, we're we're basing ours on uh ISO 27,000. It's a common risk management framework and most companies at least in private sector are are using something like that. if not that exactly. Um we we at the moment are totally revamping our policy sets and I think that's a useful exercise as well because when revisions come out to ISO 27 for example the most recent one is 20 2013 you should take a hard look at your

policy set and make sure that it's actually aligned with what the current revision is has to say about your control set should examine all your controls and make sure that those are well implemented. Um I the one thing I like to keep uh up in front of us is this ISMS model plan do check act cycle and and that really does apply directly to not just ISMS and your risk management framework but it's also a key part of the discussion when we talk about threat intelligence and how you actually implement that. So just generally speaking, remember the UDA loop without saying where UDA came from, but breaking that down, you want to establish your your your your plans and

and make sure that those are well formulated. You have an implementation plan for operations, kind of what we're here to talk about for threat intelligence, monitor and review that. So you have a governance layer to ensure that you're meeting your key objectives, that you have key man uh key performance indicators defined. And that I think is also important that you want achievable results that you communicate to your management team and they are in in line on on board with that. You want that going up front. You don't want to just run your your your shop as an ad hoc shop where you'll continuously be in an ad hoc mode. And then of course act maintain and improve and and optimize

your workflows. And there's some legacy stuff here. This is a comprehensive slide I found of the ISMs implementation certification process. Not what we're here to talk about. Our process flow is not quite that complicated, but it breaks down in a similar fashion. And you really probably do want to spend time documenting your process flow as part of program documentation. That will get you a lot of traction with executive management, at least in large organizations. It's actually a key part of what I find myself doing as a threat intelligence manager. I spend more time documenting process flows than I do doing threat threat intelligence. So, it's kind of sad that way. all this the corporate management overhead. Again,

the the process loop um just another way of formulating that. It's interesting to me that this that this presentation actually integrated uh threads. By the way, this this set of content is not my own. And if you want the actual links to to these slides, be happy to give you the deck, but also the references for where all the content is taken from. So, um I think it's important to to work uh off the shoulders of others and elevate oursel, which is another way of saying it's it's plagued your eyes like heck and you know, steal your content, but give credit to those who who actually did the work because I think we we don't

want the same thing done to us when we actually get around to designing new and creative content, right? So, I think it's important to give attribution. So, I do have all the all the attri all the all the citations if you if and when you want those. Um this this is interesting to me. this idea of developing a maturity scorecard. This is actually also correlated with the NIS cyber security framework, the idea of developing a a profile and showing what your target profile is. So, not every company should be at the same maturity level either in your ISMS program, but also in your threat intelligence program. You're obviously going to start out at a less mature pro program level

and and you're going to work towards being more mature, but you really want to plan that so that you can say, well, at at six months from now, I want to be doing these activities and I want to have the staff to support that and here's the investment cost I want have to do in technology to support that because that's also going to be part of your your budget cycle discussions which I'm still involved with here. Here I've c captured a handful of presentations of material on intelligence cycle. But the the important thing to to think about here, you can't read any of that, can you? We're going to start with requirements analysis. We're going to go

through a planning and directions. We're going to do especially collections. So this is about collecting indicators of compromise, but also specific threat intel about actors. And we're going to go through a process and exploitation phase of our analysis. This is where we're going to assess the potential impact and relevance to our own infrastructure of threats and vulnerabilities. So I think it's important to mention that there is an easy uh often it's it's a frequent uh uh thing that I've seen occur and it's I'm just as guilty of it in my own organization is to conflate the terms threat and vulnerability. When it comes to the types of reports that I'm generating internally for my management team, as

often as not, I'm really writing a vulnerability report with some specific information added to that about potential threat actors because it's it's not necessarily the case that we know or are able to attribute observed attempts to hack into our infrastructure to the actual actors. So, for example, who all really believes that China is behind Sony, right? Well, we've seen attribution like that, but do you really believe it? Not. We don't always even have that level of attribution where we get something from the government that says, "Is this that threat actor or that threat actor?" We hire a man, the answer is always China, right? So, it depends on who you're talking to and who's giving you that

type of attribution advice, who the threat actor is or may be. We're not really always able to get even that level of detail. Depending on who you're working with, you may or may not get detailed attribution information. Yes. But do you at least uh take a look at kind of categorizing the threat? Yes, absolutely. We'll get into threat risk assessment in just a bit, but that that's an important aspect as well. So, as part of the cycle, we're collecting specific threat information, but we're also going to cycle through how how we mature that that information and how we do risk assessment. Um and then once we've done an analysis step that there's obviously delivery or dissemination but

the the key the key product for thread intel workg groupoup in the corporate environment in my experience is reports that's that is the deliverable. So a big part of the the job is just pushing out reports just like pin testing you you don't get paid until you deliver the report right assuming you're working for pin testing and not just doing it as a hobby. U the planning and direction stage is always optimization phase and we always want to come back. There's um a variety of presentations that you can see um views through prisms or lenses of of this cycle. This this this particular set of slides from this point forward there's a handful here that are taken

from this documents. This one is from um SP800-30 and 39. So they've taken the same approach and then shown that you you need to do the same cycle but across multiple tiers of your organization. So basically it's it's what we were saying as we started the talk. You're going to do the the ISMS loop the same at the framework level. You want to do a risk assessment at at an enterprise level. You want to do risk assessment at application level. Basically we're following the same workflow throughout. There is a tendency to view threat intelligence and try to say that applies only to my technical assets. But there's also the need to do threat intelligence analysis around what are

the threats to personnel what are the threats to physical facility what are the threats and to is key executives are those threats locally based we do a different analysis on on if we're looking at international travel for example but I think the scope of what your team does depends on the size of your of your organization the size the specific requirements of your management team and and in my case our focus at the moment is IT a technical asset threat. So, wow, how many times can you see the same workflow again from SP800-30 more udaloop? Really, you will never get out of the loop. You're stuck in a ridiculous cycle that never ends. This is the job you've asked for.

It's like a swirling cesspool of you never can stop processing threat. What's the exit strategy? Well, hopefully hopefully you're you're managing threat. I really like this slide. This this is from Lanco Lanc I think uh sponsors here today. Um this whole idea of context aware and security from continuous response. Wow, I really like that. I think that's our our objective. So um this this is something from Waypack Labs who uh are a vendor of threat intelligence information. I did I mention No, I didn't but the company I work for is a financial sector um vertical. So we um are a member of FSISAC and one of the which is I think the premier thread information sharing organization or

amongst ISACs at least um and as such we get a lot of exposure to thread intelligence coming from organizations. We also get subscribed information from way and a number of other companies that are contributors. This did not come from that subscription. This is public facing material. So I believe um fair use applies. Um but uh the the whole point here is is to increase your your process maturity. Um and and and the typical capability maturity model categories are are defined here. You're doing a you're performing you're managing it's defined measured and optimized. So the different activities you want to be performing as you're doing threat intelligence. you can start to lay those out and that gives you kind

of an action plan for moving your your program forward. Um so in my case uh this is a case study that I put together around fictitious company uh where you're basically starting up a program. We started by by actually describing what the team does and making that information available as part of the program document that uh was provided to management team. any similarities to any real life company are completely accidental. Uh but there there may be some here. I think the most important thing to begin uh with as you're developing a threat intelligence program is to make sure that you have executive mandate for the group and the team and the effort. Uh without that everything is a

grassroots effort and is really going to be difficult to make headway uh as as you try to implement process. The process is difficult enough as it is to get established in larger organizations where there is a legacy of this is the way to do things. We're not changing it just because you think it's a great idea. Uh we're we're over we're we're we run a lean shop. We have as few technical people as possible. So the new things you're asking us to do are going to be assigned the lowest level of priority because these people are already working on uh what what are deemed to be business critical roles and responsibilities. So your your thing if

if it's not deemed business critical and given that criticality by your top level executive is just going to be something that that gets put on the shelf and never gets implemented. And even if you do have executive approval that may still also be a risk area. So, uh, that's that's certainly important. Defining your scope in terms of what types of threats are you going to be focused on initially. You don't want to set a large a larger scope than you can hope to achieve. Working just with your technical assets or or your your critical applications is probably a good way to start. You should avoid conflating threat and risk and and vulner and and vulnerability, but you should at the

same time make sure that those terms are clearly understood by everyone in your company that may be getting your presentations and understanding what you're delivering. So getting definitions out of the way is relatively important in your program and worth worth talking about here. So I think I think everybody is probably aware of the difference between threat and vulnerability. you have any questions about that? Yeah. So, we're basically looking to the potential source for actions against whatever vulnerable devices or or applications that we might have. And being able to identify those sources means that we are able to possibly see patterns of of attacks that come from there. We might be able to take remediating actions as simple as

blocking their source IPs, but it may be more complicated by identifying uh the the telltale signs of their attacks. So that if they move to different source networks, we'll at least be able to see the type of attack that's occurring, recognize that sooner. Uh we be able to may be able to write more effective uh signatures for our IDs or firewall platforms or whatever other technologies that we have in place. So those those are the goals and of course risk risk is a completely different animal but risk um is the generic score that we mostly want to communicate to the business. Risk is how the business manages financially the costs of running the business. So if we can assign a risk

level and have a cost associated with that. Now we're speaking in terms the business will understand and that is an important uh thing to keep in mind. You should not talk about vulnerabilities or attacks when you go in front of the board. You want to tell them what's the cost of running my threat shop. What what what value have I added to the company by reducing risk overall and what was the financial impact of the company? And if we can talk in those terms to the business that we've really succeeded at in our jobs. If you can't, then you're you're you're at risk. You're at risk for not keeping your job or not getting the funding that you want

to run the thread shop. So there is there is a technical risk process. It's also the same risk process for business level risk. But u again it's really not at the the right level to be able to read that. But this is uh this is actually taken from wall SB800-30. It's another NI the same NIS document we saw before. You you'll find it also in risk management discussions that are framed around ISO 27,000. It's the same the same process but identify threat sources, identify vulnerabilities, determine likelihood of occurrence, determine the magnitude of impact and and from that uh come out with a a risk score. This this is basically the day-to-day work of threat and team that goes into the reports that

we generate. this this report actually uh where's my thanks securosis um but I think that it shows the integrations between um incident response and threat intelligence quite nicely so above and beyond just delivering reports to management we want to actually have a close association with our incident response team and actually implementing mitigations so that that to me is the more operational aspect of threat threat intelligence having an established CERT or or CERT within your company is an ideal state to go into. You you may you may have a company where you don't have such a thing established and you need to define some roles and responsibilities there. Um and keeping a store um as as a

a central repository of thread intellformation is useful because that it it gives you the opportunities at at a future point by automation and we'll talk about that just a little bit and we've talked about this already but you basically want to add answer the the six questions of who where why what's going on and we have beaten this to death. Um you should be able to speak in terms of threat assessment levels when you're speaking to management. color coding is actually somewhat useful, but you need to have a quantitative method of of arriving at that so that you consistently apply the same methodology of of assessing risk. So even if you're doing qualitative risk assessment, at some point you should

think about assigning some number level to the different things that you're evaluating. But you can get at that by generally speaking what what what are the what's the exposure and what's the severity of of that and the potential being the severity and exposure then allow you to compute an impact value. So what would be the the the damage to my Windows environment if none of those systems are exposed to the internet and I'm getting attacks that are only coming from the internet. My my the impact on my enterprise would be low because I have no exposure. So it's it it is important to maintain some situational awareness about how you're running your firewalls and how what your overall

posture is in terms exactly where the attacks are coming from. It's also important to consider your internal just looking at it from a network perspective to consider your internal attacks uh and not to consider your internal network as being a protected uh citadel because as as you may know probably this audience knows oftenimes malware attacks give a a foothold on your internal network to an external attacker who then has as much visibility into your internal network as you did with or without your firewall. So um that's that's common knowledge I think but for management reports colors are meaningful especially at the board level. So if you can translate your threat assessment into a color-coded threat assessment level this is really

beneficial to to you to be able to speak to management in terms that they understand. So you need to have a consistent way of applying vulnerability analysis and identifying potential threat actors and communicating that up up the hill. And I think um maybe you know what you the basics of what you're looking at but we want to know who the audience for our our our threat discussion is what the severity and urgency is. One of the biggest questions that comes to me all the time is okay so what about this freak attack? What about this freak vulnerability? What is my what is my my uh priority on patching? Should should I should I interrupt all of my workflows and do an

emergency patch process? Well, now now we're just strictly talking vulnerability because there haven't been any identified attackers since weakness. We haven't been any observed attacks really. Some proof of concept stuff that maybe developed, but in in in the wild, not a lot of active attacks against it. Completely different. The heartbeat of course the moment that went public, they started seeing scanning for it which turned into will attacks against it. So that there was obviously a much greater urgency when you see things that are live in the wild than there is when you don't see any type of attack. But that's the my internal audience for reports that I'm delivering are the technical team as much as the management team. The

technical teams who are doing actual patching across a distributed enterprise environment u want to know what's what's the criticality how how how quickly should I patch everything? Do I need to stop my normal patch process and do this as an emergency patch? In my environment, we have a very strong change control uh group and paradigm and and we don't really do anything without executive approval if if for for emergency changes. So if you have a large organization, getting changes done with with multiple presidential level approvals is a non-trivial task and and you really need to justify that accordingly. Um there's some just a little bit about profiling attack threat actors that I that I've kept here. This is from um a

presentation um um I I forget the company who actually did it but it's through a media chair but that's this is also something that we we want to do on a regular basis. But I think this it was worth mentioning some content that just came out this week shared by infregard from from OSAC. OSAC is um something that's done by the US Department of State uh Bureau of Diplomatic Security and new a new report that they released just this week had to do with identifying cyber threat per country. So they have a methodology that's that's really well described that lines up well with what we're talking about and how you're doing threat uh uh uh threat assessments. Um

but basically you can see the computation of risk is exactly what I I showed on one of the previous slides. It's it's a three tuple based on threat threat, vulnerability and impact. So I think this is this is a really common language you find especially you know NIST is using it in every basically everyone. So this is also from the OSAC document describing basically you want to measure capability intent vulnerability impact and and there's some some materials that that they provide that you can use if you want to do that on nation state basis. what what are what are the risks that I my company might see if I'm doing business in this country or that country

was was their point of view. I think it's also useful to take the same methodology and apply to what are the threat actors in those nation states that may be targeting me uh that and and I thought that that um some of the things that they that they mentioned here um especially towards the bottom of this were interesting that they they felt that risk varies per organization that threat remains constant per country. I I'm not sure I totally agree with that but uh capability remains constant per country. Intent remains constant per country. I think it's a really broad view about that. I think in very large countries that's that's that's maybe not so true. I don't know

that I would agree that intent remains constant across the United States for example. There are a lot of threat actors in the United States of all sorts of different motivations that so it's interesting to me that that this the Department of State takes such a broad view of things. as a nation state as individual groups that may be. Yeah, I I agree. I I I think you're right and and it comes from that type of analysis, but their presentation was more towards what type of cyber risk do you incur by actually being there in that state. So, for example, if I want have executives that want to travel to or do business in with with computing technology and say

they won't go to China, then I should measure the impact of that against my environment. Or if I'm doing business in China, what what's the impact as opposed to so I don't think it was really meant towards threat actors that are targeting me coming from those states, but really more about the the threat of doing business in that state and and maybe maybe that lens changes that view a bit, but maybe not. I mean maybe maybe maybe look you can look at it regardless of whether you know the tax is coming to me from the from the state as a state actor versus the cost of doing business there. I don't know that it changes. I

think it's it's worth maybe doing the the threat analysis from with both lenses and seeing how what what are the net results. Um which I haven't done. So unfortunately for me my company has a very focused domestic business. So that's kind of not really the point. The point to me that was the methodology in doing the risk assessment was the same and the tools that they have provided through their their report which is also the the URL is listed here. Oh by the way um it is the department of state uh it's osac.gov I have the URLs for it but you actually had to have a member of your organization establish a presence with the department of state in order to gain

access to that or you can gain access to the report through FBI infra was the channel I received. So, um, they apparently are not just divying that out to anybody and everybody. Um, but there there is I guess once it's out, it's out. They'll have a hard time keeping it hidden. Um, but if if you try to go directly to the download URL, you you probably won't be able to get it that way unless you take those registration steps, which are a little bit more tightly controlled than just regular any old place. Um I I you can't read it but it's a list of basically a bibliography that you can have from me if you want

the slide deck and some similar references some of the materials that I've mentioned here before now and some more there. Um I don't think we need to talk about vulnerability management per se but you know penetration testing is always fun talk pin testing killchain killchain where does that yeah on on vulnerability management I found it very counterproductive to share

vulnerability that kind of operational outside of the security like as soon as I go I'm having to explain like three or four times to anyone else where the point is I don't want anyone else I'm going to translate that data well before it gets to any even like you know yeah that's a very good point the the point the statement was that you should not just deliver vulnerability information outside of the team that's dealing with and remediating vulnerabilities and because you'll spend more time explaining that than you do actually getting work and and I I agree with that. So in in my case, we we we talk about risk management and and lowering the enterprise risk. We want to provide a

composite enterprise risk score to the to everybody else. So so that basically we don't really open the kimono all the way. We just give a a dashboard view of what's enterprise risk today and we would translate for example patch level to an established risk level. Um so if for example we've got a flatline of of vulnerability on our server environment because we haven't been able to patch those servers then just the fact that it's not trending downward but it's flat and not going up is good enough for management to see you know have we made have we improved our overall risk posture but I definitely agree you don't want to be talking about number of

vulnerabilities or criticality of vulnerabilities that were patched last month that just has has no traction so to follow up on that is do you do um mapping vulnerabil through let's say the exploit kits that are available. So here's the black hole using all these various exploits. Do you map that to your vulnerabilities and say I have this vulnerability but it's a lot more important because it's part of a active right um trying to think if I had the particular sliding question and it's not really before after here um but but yes yes yes we do um I think we we actually kind of breeze past it so in the risk in that risk framework um we we want to understand the threats

and exploits and then also the vulnerabilities but that's going to give us a measure of adverse impact. So, back to back to this um this where did I put it? I probably missed I did miss it. There's we we talked about it briefly, but I didn't dwell on it, but there is um sorry for this guys. That's right. The short answer is the short answer the short answer is yes. But yeah, okay. I did spend some time here but but measuring uh exposure rating and severity also there's an impact score from from exposure which which I well I mean I said that already exposure um but depending on exposure and then the severity of the

vulnerability basically is what we're talking about here gives you a risk score that if if it's down here then then then you're you're basically going to map that up into like red or orange when you present that outside of your And so that's that's the whole point is that we do want to map vulnerability and exposure to a residual risk value and we want the residual risk to be lowered. And so showing over time lowering the residual risk is one of the the key performance indicators we can provide to say here's the value of having our threat program. Historically you were flatlined. We implemented the threat program. We drove the risk downward, the residual risk downward. So that in a in

a dashboard view is exactly what you you want the meter to start going whichever side you have as green trending towards green. So that's an important aspect. You know there's there's basically two major kinds of reports that my team delivers today which I do not have examples of here because it's a little bit too much a work work product but um we have uh we have daily weekly and detailed threat reports that specifically address vulnerabilities and threats per se and are mostly given to um technical teams as a key as a key tool for them to drive prioritization of mitigation efforts. And then the other report that we give is a dashboard view that goes up the hill which speaks

towards threat trends and and what are the what are the primary topics that that we're seeing as top trending trending threats and without having the actual content here we we tend to do that today uh across the enterprise vertical. Uh so we talk about trending threats across our vertical and one thing that we still have yet to implement in my team is trending threats for our internal uh point of view with the internal zone. So I can say that in the vertical today the top threats that you see on an almost almost never changing basis are malware fishing DDoS. All right. So in the in in financial sector there is a day-to-day non-stop battle dealing

dire kahos you know it just whatever flavor of the moment of malware that is being pushed out and being upgraded. So, so Dire is like the new Zoobot if you don't know what that's about. And and the the challenge is while in my corporate environment, I may have a lot of really solid foundational controls around endpoint security, I've also got a user base that's not in the corporate sector that uh you know, you may you may have some parallels to that if you come from education or other other verticals where you've got people that you have desktop controls on and then you've got that set of people over there. It's just the wild wild west and executives the

executives students executives right so we've got you know you've got uh uh okay so bring your own right bring your own um bring your own disaster you've got you've got your you know your Mac users where you may have a really strong program around Windows protections but you haven't got the foundational controls around Mac support well the fortunate thing is there's not a lot of malware attacking Macs yet but but it's coming I Android devices are are like really vulnerable at the moment to freak, but you can't get that pushed out because the vendors, your your your phone companies are not pushing out support for those devices. So, you're going to have lingering vulnerabilities that

exist and lingering lingering threat landscape that you can do nothing about because it's outside of your control. The only controls you're going to have are what are my mitigating steps now? I make sure that they're never allowed on my corporate network. And if you did allow them like six months ago, then you made a big mistake. and for which you know recovery may be impossible. So you may really want to seriously think about network segmentation if you haven't already. So the whole kill chain thing uh for us when we're doing incident response uh or we're doing mitigation reports and we want to describe basically what controls we have at each step in the kill chain. Um so in my

reports I'm I'm addressing killchain by by showing what mitigating steps are possible at different levels. so that that that we can start to drive the discussion towards let's do incident response as early as possible. Let's identify threat and and and actual attacks as early as possible. It helps to focus the discussion. Um, and so, yeah, it may it may sound like a buzz word that's overused, but if you can find a way to to deal with those aspects of the kill chain as you're talking about mitigating uh uh responses or you're talking about incident, you're talking about enterprise uh controls and and and start to to to structure your controls in such a way that they address

specific parts of the kill chain. You'll find it more effective to communicate, especially with the management team about driving cost down.

and more uh right so actually I think I already mentioned patch management and it's really all about prioritization of of what you're doing there oh boy sick of that right so mapping this this is actually a a set of of points that were taken from uh NIST content it's not 800-30 30 it's it's a different one but they're they're strictly talking about information life cycle but I think I I was like it's like cyber right threat is the new cyber is it the drinking game now you hear the word threat let's take a drink so put threat in front of any sentence this this framework is one that we're actually actively using in my enterprise it's u it's actually the from

CMU the software engineering institute So that's a something called the collections management framework and and it's broken down into three major uh maturity model phases which you cannot read that but I have the source URL for you if you want it. That's a PDF. I've flattened that and broken that down into um basically program model that we'll be we'll be using internally to more uh correctly identify stages of of where where we are in implementing the the framework as we proceed over the next three six 12 months and we'll be able to talk to management or you know we are at our desired state of an advanced threat intel program and and leveraging the collections framework

And so by identifying these these milestones that map back to the framework, it allows us then to identify maturity model states and push push forward. In order to do those activities, I am going to need additional staff and technology and I'm going to need cooperation from other parts of the business that have so far been slow to develop and that will come at a cost which we can start to identify because we'll be able to say who the roles and responsibil are in those groups that need to interface with us and the type of work that they need to be doing to support us. So this is a major component of my program is wrapping around this

framework. I've also developed that into a maturity model by by just laying out the activities that are high level activities that are that are being done in the framework and showing a march towards an advanced or optimized state. So this is all my content my content but based on standing on CMI CMU's shoulders. They also have some detailed um breakdowns of what you can be doing actually prior to do your threat analysis. So their content is is very I think useful in terms of defining actual procedures for your workforce to to help them understand what should you be doing as part of your threat analysis activities. It's also useful to go back and use that as a review uh methodology

when you're looking at did you meet your key performance objectives over the past year. Here's how well you did at this task or that task. So I think it it also helps us to map threat analysts roles and responsibilities but also to more clearly define them and give that information to HR. So when looking to hire a threat analyst, it's not always easy to understand what the role and responsibility is going to be because as we said at the start of the talk, even threat intelligence is poorly defined. So what is a threat analyst role in in my company as opposed to uh the defense sector is going to be a completely different animal. Uh not hopefully not

too completely different, but it will will vary greatly. So establishing a dialogue with HR so they understand what the role of responsibility really is and they know how to vet the various resumes they might get. I don't know if you've ever done hiring before for a large company but you get a lot of resumes that you simply think are trash. People make up stuff or they'll send you resumes thinking well my background would make a great foundational background for the job that you have but I have no experience whatsoever in what you're looking to hire. So you you have to kind of sort through that and figure out you know you know what I I really

like him and I think he's actually right or you know what that's a great idea and everything but I don't have the time to to train somebody in this role. I need them now. So it's it's a real challenge to to look at resumes and try to find someone that you think could really benefit the team but at the same time not disqualify someone because they simply don't have a thread intel background. Finding someone with a with a threat intel background limits you pretty much to the intelligence community, people coming out of DoD, the uh folks who who who is threat intel may have been around counterterrorism or insider threat with behavioral analysis. We all watch like you know those those

TV programs where we think people are doing that but uh whether that applies in the private sector directly is is can be a challenge. So that's real world experience with building a threat intel program. Oh my gosh. Um you want to prioritize risk. We've been saying that over and over and over again, but this framework here breaks it down into steps that are also mapped to the various levels of those those three maturity levels. So clearly you can't read that but uh I I find this this helpful in terms of identifying clear markers for where we are and where we want to be as we improve our program. You also can't read that but that's my actual workflow that I

established. Um we are basically developing swim lines around those swim lanes around those actual phases of of threat intel. So we have planning phase or requirements analysis phase, a collection phase, an analyze phase, a dissemination phase. I've mapped different uh tasks in each of those phases that that we can measure. Right? So the input and output to those phases. We'll we'll have key performance measurements against them. And so we'll be able to provide some some indication to our management team of what kind of job are we doing operationally. So having operational performance metrics I think are important when you establish a program because if you don't have them you don't have good visibility into what

how how well are you running your program. So you always have to think about the output being the number one deliverable but also a day-to-day conversation with your managers. How good a job am I doing? I I want to receive good good reports at the end of the year because it usually has a direct impact on bonus. And so I think it's important that you structure your program with measurable points in the program to allow you to deliver those type of indicators. This ties somewhat back to the framework, in fact, closely back to that framework. So I'm able then to show as I'm improving maturity of the program, what where the investments in the program have started to pay off. If

if I have a key performance indicator in one in one process box that lag even though we've invested there, then you probably want to do a root cause analysis to see why is that? Why haven't my investments paid off? Okay, nearing the end here, threat intel sharing is is a topic that that I I think is really key to having an effective threat intel team. So as I'm part of the FSI sack, I'm also part of the cyber intel community there and there is a lot of threat intel sharing that goes on in that community mostly on TTP about actual either malware attacks, DOS attacks or fishing attacks. Those those being the main ones that we see

dayto-day. uh that is a closed community that you can become a member of if your parent if your company is a financial sector company and pays to be a member of FSISAC which by the way is the financial services information sharing and analysis center. If no one knows what FSI isack means, there are other ISACs that are wrapped around um the basically the the critical infrastructure categories, the 16 critical infrastructure categories that were u defined as part of the critical infrastructure protection program and you can learn more about that through the FBI Infart program as as one source of information. There are closed information sharing groups that you can become a member of. Usually those you

have to be nominated by an existing member and and vetted into the organization or into the discuss into the group. Um those are really useful. I I happen to be a member of one or two. Um and u there is a lot in my experience a lot of overlap between those members and FSISAC members but also the advantage of being FSISAC because it's made up of of financial sector companies. there are limitations on the type of information that can be shared across those between those companies because of concerns about anti-competitive practices. So we don't want to be in violation of RICO. Uh and yes so um so there there there are limitations and you may have

seen through the the uh uh cyber security framework that was pushed out there. It's been ongoing discussions which came from NIST also but there have been on discuss ongoing discussions also President Obama just recently pushed an executive order out that he's hoping would clear the way which still has not done because there is not supporting legislation to enable uh sharing to be done. Most companies are reluctant to do more proactive sharing because of concerns about liability and being sued or or being brought to court for for potential RICO violations. So there there there are these these legal limitations that are preventing companies from sharing. In my own case, we have requests to share certain specific things that we have going

internally to our office of general counsel and we're still awaiting a finding or or response from our own lawyers as to whether we can share that more broadly even in these closed communities. So that's that's unfortunate. I see a lot of information coming from other companies, but I'm not able to share nearly as much as I would like to. Um I think uh capability evolution is is this is actually from a NIST document SP800-150. It's it's a document that's actually in draft. It's not published yet and it targets uh information sharing specifically. So if you have an interest in in joining an information sharing community, you can find some some um ideas about information sharing

best practices that are being developed by NIST and and being discussed at a at a more um global level. But basically the whole idea is you want to be sharing. Sharing gets you a lot of value in terms of being able to identify threats uh at at an earlier stage. Um and there are additional ways you can break that down. This is my own internal attempt to do that. Um, one one method that once you start sharing, what you'll find is you'll get you'll get more thread indicators than you can possibly manage as as a human. It's just like looking at your log data. You need a SIM to do your log correlation. You're not going to be able to do uh indicator

correlation as a human because you are going to get literally thousands and thousands and thousands of these things. Um, as a member of the FSAC, I've also been on the security automation working group and that basically has led to the development and eventually spin-off of of a new company called Sultra, which I'm only involved with as potential customer. So, I don't want to advertise them really per se, but they're most of their work product is available open source or at least openly available for download. So what that product is is a tool called edge which implements the uh protocols that were developed by MITER to do information in threat intel sharing or indicators complement sharing

uh through protocols called sticks and taxi. Um so once you implement edge then what you wind up are with with uh you want to have established feeds through other uh threat providers and you basically get indicators that okay so now you just got a big repo on the back end as a database that that is retaining threat indicator information. You still need a SIM or log management tool to attach to this thing and do your correlation because this is basically just a router for thread intel information. Once you have that in place though, I believe the the the capability that we still have yet to realize in my own enterprise, but it's kind of a face

faith-based thing. We want to move towards actually doing that and and doing more automation so that we I believe reach a more the the the penult the ultimate if not okay maybe it's the penultimate. It's not really the final stage of maturity because I don't think you ever get there. But for us, a target mature state is automation around our threat intel and how we integrate that with with finding uh context on our internal company through our internal logs.

Well, we we we haven't integrated uh we have not integrated edge yet with SIM, but but yeah, that's that's part of the challenge with with working with other groups that are lean and and don't have the cycles to spare. So, that's with other um not yet visibility or visibility. No, not not yet. It's it's we're receiving feeds, but we haven't integrated our own content there yet. So, it's that's that's the next step for us as we move ahead with that. So, the interest is staying on schedule. There's a great questions. If you want to meet up in the back with more questions after the talk, that's fantastic. Right now, what we need to do is swap out our speakers. Um

Xavier, where are you? There he is. Uh next will be Xavier Ash doing Excuse me.