Category Archives: Network Security Monitoring

Investigation Case Management with TheHive

I’ve struggled for a long time to find a case management system that I thought fit well within the constructs of how analysts actually perform investigations. Most case management systems are actually just help desk ticketing systems that have been retrofitting to fit a security use case. This is what I see most often when SOCs are using tools like Remedy, RTIR, or OTRS. Last November, a group of researchers from CERT Banque de France (CERT BDF) released a new case management system called TheHive. The authors of the project describe TheHive as an “open source and free security incident response platform designed to make life easier for SOCs, CSIRTs, CERTs, and any information security practitioners dealing with incidents that need to be investigated and acted upon swiftly.” I would simply describe TheHive as a purpose built case management system to facilitate the investigation of security incidents. I’ve enjoyed using the TheHive so much that I actually integrated it into my Investigation Theory course where I teach people how to approach investigations and hunt down bad guys. In this post, I want to discuss a few features of the TheHive and why I enjoy it so much.

Architecture and Installation

TheHive is written in Scala and uses ElasticSearch to store and access data on the back end. The front end uses AngularJS and Bootstrap. A number of REST API endpoints are also provided to allow for integrations and bulk actions.

 

You’ll see Cortex mentioned in the diagram shown above. Cortex allows users to submit observables and indicators of compromise to popular open source intelligence tools via a series of Python-based analyzers. Ultimately, it is a separate tool with it’s own codebase, but  TheHive and Cortex go together like peas and carrots, so you’ll see them mentioned a lot in TheHive documentation. The installation command I’ll provide below will actually install both of them as a single integrated container.

There is a traditional Ubuntu 16.04 installation option described here which is probably most appropriate for production systems:  https://github.com/CERT-BDF/TheHive/wiki/Installation-guide.

If you just want to try TheHive or run it locally, you can get it running via containers with Docker. The installation process here couldn’t be simpler:

  1. Build an Ubuntu 16.04 system and ensure it’s up to date on system and software patches.
  2. Install Docker
    Info: https://docs.docker.com/engine/getstarted/step_one/#step-2-install-docker
    Command: curl -fsSL https://get.docker.com/ | sh
  3. Download and run TheHive w/ Cortex ():
    Info: https://github.com/CERT-BDF/TheHive/wiki/Docker-guide—TheHive-Cortex
    Command: docker run –publish 8080:9000 –publish 8081:9001 certbdf/thehive-cortex
  4. Connect to the web interface using a browser: http://IPofServer:8080
  5. Follow the on screen prompts to create an administrative user account

Case Management

The core construct of TheHive is the investigation case. I like this because the case is also the core construct of most security investigations, whether you’re reviewing alerts, reverse engineering malware, or working a declared incident. The case construct doesn’t provide a lot of bells and whistles, but that’s okay because I don’t think it has to. A lot of ticketing systems that are built to serve too many masters quickly become too generic to be useful. That isn’t the case here.

I particularly appreciate that you can add tags to cases for quick searching and filtering. You can also track TLP levels, which can help govern and facilitate the sharing of data. This is a nice feature that really shows how TheHive was custom built for investigation tracking. All the data you put into a case is easily searchable from the search bar at the top of the screen. This makes it really easy to determine if activity you’re currently observing was present in any earlier case.

Task Tracking

Once you’ve created a case, you can create, assign, and track tasks. A task can really be anything, but I recommend using them to track the actions taken to answer investigative questions. For example, if you’re investigating an exploit kit infection, a common question might be, “What was the system doing prior to when the alert was generated?”. To answer this, you’ll need to review evidence from whatever data source you have that will hold the answer. So, a task could be “Review HTTP Proxy data to determine what the host was doing in the 10 minutes leading up to the alert.”

In addition to answer seeking, tasks are also useful to track containment, eradication, and remediation events. You can create a task for disabling user accounts, quarantining a system, deploying an image to a system, or providing user security awareness counseling.

Tasks, like cases, have the concept of assignment. Therefore, each task can be individually assigned to an analyst for the work to be performed. By default, a task doesn’t have an owner until someone clicks into it, or “takes” it from the Waiting tasks queue in the top menu bar. This effectively creates a task queue that analysts can watch to help facilitate their work load. The queue can be filtered by any number of criteria like a specific tag, a case number, a task name, or a keyword. Tasks that are assigned specifically to you will appear in the My tasks queue in the top menu bar.

Case Templates

As a SOC evolves, it becomes critical to define playbooks that help analysts consistently approach investigations that share common attributes. For example, most the steps you take to initially investigate a series of failed passwords attempts or a phishing e-mail will generally be the same. If you can define those steps, you’ll have a great head start for training new analysts and ensuring most investigations start off on a level footing. TheHive provides a unique case template system that allows you to define common investigations and pre-populate case metadata and tasks.

In the example above, I’ve defined a template for investigations related to exploit kit activity. Now, any time I create a new case I can select this template and all the information you see there will be pre-populated into the case details. The real power here is in the ability to automatically create a series of tasks that should be completed when spawning the case. This essentially lays out the investigative playbook for you. With that, you get the added benefit of automatically populating the Waiting tasks queue so that other analysts can jump into the investigation or start completing containment and eradication tasks. This is, hands down, my favorite feature of the tool.

Collaboration

A key feature of any case management system should be collaboration, and TheHive hits the mark here. Each analyst using TheHive gets their own account which is used to log any actions they take within the tool. Users can own cases and/or tasks. One thing I particularly like is that once you create a case, virtually any action taken with it is recorded to create an audit trail. This audit trail is displayed to the right side of the individual case screens in a Twitter-style feed as seen in several of the images I’ve already shared.

Observables and Analyzers

TheHive allows you to create separate entries for interesting observables within the context of a case. An observable is any interesting data artifact, and TheHive comes with a number of common observable types built in. This includes things like IP addresses, domain names, HTTP URIs, etc. Of course, you can also define your own types which makes this capability quite flexible.

There are multiple benefits to tracking observables. The obvious one is that you can search for them during later investigations to bring in additional context. You can also export them for later import into a blacklist, whitelist, or detection mechanisms. Finally, you can use the built in Cortex integration to automatically submit the observables to any number of OSINT research sites. This is a very simple process, and primarily just requires that you input API keys for each service you’ll be using. Some of the existing integrations include Passive Total, Virus Total, and Domain Tools.

API and Integrations

Because the TheHive was built on a series of open API’s, it’s incredibly flexible in terms of integrating with other tools. The authors have produced really nice API documentation here: https://github.com/CERT-BDF/TheHive/wiki/API%20documentation. You’ll see that the documentation provides multiple examples of request formatting, along with several use cases. This includes the ability to query, create, and manipulate cases, tasks, and observables. This has immediate tangible benefits.

Consider a scenario where you’re running a signature based IDS. Any time a specific set of rules associated with exploit kit activity generates an alert, you could use the API to create a new case using a template like the one I showed earlier that is specifically designed for investigation of exploit kit related activity. Using this approach you haven’t just done a simple automation, you’ve created a workflow based on the playbooks you’ve developed. When you or another analyst go to review new alerts, anything related to exploit kits will already have a series of tasks created and waiting for you to accomplish. This is a time saver for experienced analysts, and a teaching tool for younger analysts who might not know what move to make next.

In addition to the APIs, TheHive can integrate with MISP and you can also write custom analyzers for use with Cortex. Once again, there are a lot of options here.

Conclusion

This post discussed a few of my favorite features of TheHive and how they can be used in practice. There are quite a few other features like reporting and metrics that I didn’t discuss here, so make sure to check those out on your own. A lot of tools that are used in SOCs were born in them. However, this is not an easy thing to do. Every SOC I’ve been in is different, and most of the times the tools that might come out of them won’t be nearly flexible enough to fit into the workflow that exists in another organization. The developers of TheHive have hit the delicate balance of creating a tool that is focused enough to deliver on immediate use cases, while still being broadly focused and flexible enough to be adapted to differing use cases. As stated earlier, it’s for that reason I use TheHive in my Investigation Theory course and why I’ll be recommending it for individuals who want to learn how to be analysts and for organizations that are seeking a simple case management solution that can get the job done.

You can learn more about TheHive at the project’s homepage here: https://thehive-project.org/. If you’d like to learn more about the investigation process and facilitating it with TheHive, be sure to check out the Investigation Theory course.

 

* Some of the images in this post were created from my home lab, but a few were borrowed from TheHive official documentation linked throughout the article.

 

 

 

Three Useful SOC Dashboards

I worked in security operation centers for a long time, and I really grew to hate dashboards. Most of them were specially designed pages by vendors meant to impress folks who don’t know any better when they stroll through the SOC and glance at the wall of low-end plasmas. They didn’t really help me catch bad guys any better, and worse yet, my bosses made my ensure they were always functional. Fast forward a few years, and I end up working for a vendor who builds security products. Much to my dismay, while planning for features we end up having to build these same dashboards because, despite my best efforts to persuade otherwise, CISO’s consistently ask for eye candy, even while admitting that it doesn’t have anything to do with the goal of the product. Some of them even tell us, straight up, that they won’t purchase our product if it doesn’t have eye catching visuals.

I provide that backstory to provide some insight into my long, tortuous relationship with useless dashboards. I talk about this enough at work that I feel like I’ve almost created a support group for people who have stress triggers associated with dashboards. If you’ve ever attended a conference talk from my good friend Martin Holste, you may know he hates dashboards even more than me. Alas, I’m not here just to rant. I actually believe that dashboards can be useful if they focus less on looking like video games and they help analysts do their job better. So, in this post I’m going to talk about three dashboard metrics you can collect right now that are actually useful. They won’t look pretty, but they will be effective.

Data Availability

The foundation of any investigation is rooted in asking questions, making hypotheses, and seeking answers that either disprove or prove your educated guesses. Your questioning and answer seeking with both be driven, in part, based on the data you have available. If you have PCAP data then you know you can seek answers about the context within network communication, and if you have Sysmon configured on your Windows infrastructure, you know you can look for file hashes in process execution logs.

While the existence of a data source is half the battle, the other half is retention. Some sources might have a specific time window. You might store PCAP for 3 day and flow data for 90 days, for example. Other data sources will probably use a rolling window, like most logs on Windows endpoints that are given a disk quota and roll over when that quota is met. In both cases, the ability to quickly ascertain the availability of data you have to work with is critical for an analyst. In short, if the data isn’t there, you don’t want to waste time trying to look for it. I contend that any time spent gathering data is wasted time, because the analyst should spend most of their time in the question and answer process or drawing conclusions based on data they’ve already retrieved.

A data availability section on a live dashboard helps optimize this part of the analyst workflow by providing a list of every data source and the earliest available data.

dashboard-dataavailability

In the example above I’ve created a series of tiles representing five different data types common to a lot of SOCs. Each tile boldly displays the name of the data source, and the earliest available date and time of data for it. In this example, I’ve also chosen to color code certain tiles. Data sources with a fixed retention period are green, sources with a rolling retention period based on a disk quota are yellow and red. I’ve chosen to highlight endpoint logs in red because those are not centralized and are more susceptible to a security event causing the logs to roll faster. The idea here is to relay some form of urgency into the analyst if they need to gather data from a particular source. While PCAP, flow, and firewall logs are likely to be there a few hours later, things can happen that will purge domain auth and Windows endpoint logs.

Ideally, this dashboard component is updated quickly and in an automated fashion. At minimum, someone updating this manually once a day will still save a lot of time for the individual analyst or collective group.

Open Case Status

Most SOCs use some form of case tracking or management system. While there aren’t a lot of really great options that are designed with the SOC in mind, there are things people find a way to make work like RTIR, Remedy, Archer, JIRA, and more. If integrated properly, the case management system can be a powerful tool for facilitating workflow when you assign users to cases and track states properly. This can be a tremendous tool for helping analysts organized, either through self organization or peer accountability.

 

dashboard-casestatus

In this example, I’ve gone with a simple table displaying the open cases. They are sorted and color coded by alive time, which is the time since the case was opened. As you might expect, things that have been pending for quite some time are given the more severe color as they require action. This could, of course, be built around an SLAs or internal guidelines you use for required response and closure times.

The important thing here is that this dashboard component shows the information the analysts needs to know. This provides the ability to determine what is open (case number), who they can talk to about it (owner), how serious it is (status), what it’s waiting on (pending), and how long have we known about the issue (alive).

Unsolved Mysteries

On any given day an analyst will run into things that appear to be suspicious, but for which there is no evidence to confirm that suspicion. These unsolved mysteries are usually tied to a weird external IP address or domain name, or perhaps an internal user or system. In a single analyst SOC this is easily manageable because if that analyst runs across the suspicious thing again it is likely to draw attention. That is a tougher proposition in the larger SOC however, because there is a chance that a completely different analyst is the one who runs across the suspicious entity the second time. In truth, you could have half a dozen analysts who encounter the same suspicious thing in different contexts without any of them knowing about the other persons finding. Each encounter could hold a clue that will unravel the mystery of what’s going on, but without the right way to facilitate that knowledge transfers something could be missed.

As a dashboard component,  using watch lists to spread awareness of suspicious entities is an effective strategy. To use it, analysts must  have a mechanism for adding things to a watch list, which is displayed on a screen for reference. Any time an analyst runs across something that looks suspicious but they can’t quite pin down, they first check the screen and if it’s not on there, they add it. Everything that shows up on this list is auto cycled off of it every 24-48 hours unless someone else puts it back on there.

dashboard-weirdthings

In this component, I’ve once again chosen a simple table. This provides the thing that is weird (item), who to talk to about it (observer), when it was observed in the data (date), and where you can go to find out the context of the scenario in which it was found (case) if there is any.

Conclusion

A Dashboard doesn’t have to use a fancy chart type or have lasers to be useful. In this post I described three types of information that are useful in a SOC when displayed on a shared dashboard. The goal is to use group dashboards to help analysts save time or be more efficient in their investigations. If you have the capacity to display this information, you’ll be well on your way to doing both of those things.

 

Do you have a really useful dashboard idea that you think is relevant in most SOCs? Let me know and I might blog about it down the road in a follow up.

Interested in learning more about the investigation process and how these dashboards fit in? Sign up for my mailing list to get first shot at my upcoming course focused entirely on the human aspect of security investigations.

Video: Building an NSM Lab

Building a security lab is something I get asked about really often. So often, in fact, that I decided to put some of my notes together and record a short training video on the topic. This video is only a small part of a much larger series I’m developing, so if you’re interested in learning more about that when it’s available, sign up for my mailing list.

In this one hour video I discuss the importance of an NSM lab and go through a systematic approach to building your own. I go through the following topics:

  • Analyzing your needs to define your inputs and desired outputs
  • Modeling your lab by building a list of technologies
  • The pros and cons of physical, virtual, and cloud based labs
  • Choosing the right platform for your lab
  • Designing your lab network
  • Sourcing the right hardware for your lab
  • Taking a step by step approach to designing and building the lab

Once you’re done with this video, you should have a system you can follow to build a lab that will help you test and build detection, analyze malware, and create simulations. I also provide a lot of insight to my own personal lab I use for my writing and my day job. I’ve also included some additional resources:

  • Lab planning worksheet
  • An exact parts list from my lab
  • Two example lab network diagrams
  • The network diagram for my personal lab

You can access the additional resources mentioned in the video by signing up here.

Investigations and Prospective Data Collection

confused-winnerOne of the problems we face while trying to detect and respond to adversaries is in the sheer amount of data we have to collect and parse. Twenty years ago it wasn’t as difficult to place multiple sensors in a network, collect packet and log data, and store that data for quite some time. In modern networks, that is becoming less and less feasible. Many others have written about this at length, but I want to highlight two main points.

Attackers play the long game. The average time from breach to discovery is over two hundred days. Despite media jargon about “millions of attacks a day” or attacks happening “at the speed of light”, the true nature of breaches is that they are not speedy endeavors from the attackers side. Gaining a foothold in a network, moving laterally within that network, and strategically locating and retrieving target data can take weeks or months. Structured attackers don’t win when they gain access to a network. They win once they accomplish their objective, which typically comes much later.

Long term storage isn’t economical. While some organizations are able to store PCAP or verbose log data in terms of months, that is typically reserved for incredibly well funded organizations or the gov/mil, and is becoming less common. Even on smaller networks, most can only store this data in terms of hours, or at most a few days. I typically only see long term storage for aggregate data (like flow data) or statistical data. The amount of data we generate has dramatically outgrown our capability to store and parse through that data, and this issue it only going to worsen for security purposes.

Medicine and Prospective Collection

The problem of having far too much data to collect and analyze is not unique to our domain. As I often do, let’s look towards the medical field. While the mechanics are a lot different, medical practitioners rely on a lot of the same cognitive skills to investigate afflictions to the human condition that we do to investigate afflictions to our networks. These are things like fluid ability, working memory, and source monitoring accuracy all work in the same ways to help practitioners get from a disparate set of symptoms to an underlying diagnosis, and hopefully, remediation.

Consider a doctor treating a patient experiencing undesirable symptoms. Most of the time a doctor can’t look back at the evolution of a persons health over time. They can’t take a CAT scan on a brain as it was six months ago. They can’t do an ultrasound on a pancreas as it was two weeks ago. For the most part, they have to take what they have in front of them now or what tests can tell them from very recent history.

If what is available in the short term isn’t enough to make a diagnosis, the physician can determine criteria for what data they want to observe and collect next. They can’t perform constant CAT scans, ultrasounds, or blood tests that look for everything. So, they apply their skills and define the data points they need to make decisions regarding the symptoms and the underlying condition they believe they are dealing with. This might include something like a blood test every day looking at white blood cell counts, continual EKG readings looking for cardiac anomalies, or twice daily neurological response tests. Medical tests are expensive and the amount of data can easily be overwhelming for the diagnostic process. Thus, selectively collecting data needed to support a hypothesis is employed. Physicians call this a clinical test-based approach, but I like to conceptualize it as prospective data collection. While retrospective data looks at things that have previously been collected up until a point in time, prospective data collections rely on specific criteria for what data should be collected moving forward from a fixed point in time, for a set duration. Physicians use a clinical strategy with a predominate lean towards effective use of prospective data collection because they can’t feasibly collect enough retrospective data to meet their needs. Sound familiar?

Investigating Security Incidents Clinically

As security investigators, we typically use a model based solely on past observations and retrospective data analysis. The prospective collection model is rarely leveraged, which is surprising since our field shares many similarities with medicine. We all have the same data problems, and we can all use the same clinical approach.

The symptoms our patients report are alerts. We can’t go back and look at snapshots of a devices health over the retrospective long-term because we can’t feasibly store that data. We can look back in the near term and find certain data points based on those observations, but that is severely time limited. We can also generate a potential diagnosis and observe more symptoms to find and treat the underlying cause of what is happening on our networks.

Let’s look at a scenario using this approach.

Step 1

An alert is generated for a host (System A). The symptom is that multiple failed login attempts where made on the devices administrator account from another internal system (System B). 

Step 2

The examining analyst performs an initial triage and comes up with a list of potential diagnoses. He attempts to validate or invalidate each diagnosis by examining the retrospective data that is on hand, but is unable to find any concrete evidence that a compromise has occurred. The analyst determines that System B was never able to successfully login to System A, and finds no other indication of malicious activity in the logs. More analysis is warranted, but no other data exists yet. In other scenarios, the investigation might stop here barring any other alerting. 

Step 3

The analyst adds his notes to the investigation and prunes his list of diagnoses to a few plausible candidates. Using these hypothesis diagnoses as a guide, the analyst generates a list of prospective collection criteria. These might include:

  • System A: All successful logins, newly created user accounts, flow data to/from System B.
  • System B: File downloads, attempted logins to other internal machines, websites visited, flow data to/from System A.

This is all immensely useful data in the context of the investigation, but it doesn’t break the bank in terms of storage or processing costs if the organization needs to store the data for a while in relation to this small scope. The analyst tasks these collections to the appropriate sensors or log collection devices. 

Step 4

The prospective collections record the identified data points and deliver them exclusively to the investigation container they are assigned to. The analyst collects these data points for several days, and perhaps refines them or adds new collections as data is analyzed.

Step 5

The analyst revisits and reviews the details of the investigation and the returned data, and either defines additional or refined collections, or makes a decision regarding a final diagnosis. This could be one of the following:

  • System B appears to be compromised and lateral movement to System A was being attempted.
  • No other signs of malicious activity were detected, and it was likely an anomaly resulting from a user who lost their password. 

In a purely retrospective model the later steps of this investigation might be skipped, and may lead the analyst to miss the ground truth of what is actually occurring. In this case, the analyst plays the long game and is rewarded for it.

Additional Benefits of Prospective Collection

In addition to the benefits of making better use of storage resources, a model that leverages prospective collection has a few other immediate benefits to the investigative process. These include:

Realistic-Time Detection. As I’ve written previously, when the average time from breach to detection is greater than two hundred days, attempting to discover attackers on your network the second they gain access is overly ambitious. For that matter, it doesn’t acknowledge the fact that attackers may already be inside your network. Detection can often its hardest at the time of initial compromise because attackers are typically more stealthy at this point, and because less data exists to indicate they are present on the network. This difficulty can decrease over time as attackers get sloppier and generate more data that can indicate their presence. Catching an attacker +10 days from initial compromise isn’t as sexy as “real time detection”, but it is a lot more realistic. The goal here is to stop them from completing their mission. Prospective collection supports the notion of realistic-time detection.

Cognitive Front-Loading. Research shows us that people are able to solve problems a lot more efficiently when they are aware of concepts surrounding metacognition (thinking about thinking) and are capable of applying that knowledge. This boils down to have an investigative philosophy and a strategy for generating hypotheses and having multiple approaches towards working towards a final conclusion. Using a prospective collection approach forces analysts to form hypotheses early on in the process, promoting the development of metacognition and investigation strategy.

Repeatability and Identified Assumptions. One of the biggest challenges we face is that investigative knowledge is often tacit and great investigators can’t tell others why they are so good at what they do. Defining prospective collection criteria provides insight towards what great investigators are thinking, and that can be codified and shared with less experienced analysts to increase their abilities. This also allows for more clear identification of assumptions so those can be challenged using structured analytic techniques common in both medicine and intelligence analysis. I wrote about this some here, and spoke about it last year here.

Conclusion

The purpose of this post isn’t to go out and tell everyone that they should stop storing data and refocus their entire SOC towards a model of prospective collection. Certainly, more research is needed there. As always, I believe there is value in examining the successes and failures of other fields that require the same level of critical thinking that security investigations also require. In this case, I think we have a lot to learn from how medical practitioners manage to get from symptoms to diagnosis while experiencing data collection problems similar to what we deal with. I’m looking forward to more research in this area.

The Value of Watching Game Tape

coachcalBeing a native Kentuckian, it’s no secret that I bleed blue. As I write this, my Kentucky Wildcats are towards the end of what I hope will continue to be a historic season. All of the prestige that comes with being a tournament favorite also brings copious amounts of media coverage. A recent article by the Wall Street Journal caught my eye. I’ve always known that Head Coach John Calipari isn’t a big fan of exposing his players to game tape, but I’ve never known exactly why until now. The WSJ article addresses this exact topic. The article is worth a read, but this section sums up a lot of Coach Cal’s philosophy:

Kentucky touches on its opponents in the days before a game with a series of walk-throughs in which the Wildcats’ scout team apes the upcoming opponent’s strategy. By the time Kentucky’s players watch film, they have already seen the opponent’s sets on the court, often several times. Even then, though, they aren’t looking for specific plays.

“You see the idea of their offense,” Kentucky guard Aaron Harrison said. “We don’t need to watch every single play. We need to know the options off each set they have. After that we just have to defend.”

The article goes on to mention that assistant coaches responsible for video typically only allow a maximum of eight minute of video review. This is astonishing, because it goes against the grain of what most teams do. The majority of teams in college basketball place extreme focus on film review, often devoting multiple hours a day to it and even sending players home with iPad’s to review game tape away from team facilities. Coach Cal instead makes the players focus heavily on their own strengths and weaknesses, helping them understand that with their talent level, they can beat most anyone if they play as the best version of themselves. In this approach, Kentucky’s losses often have just as much to do with the team beating themselves as it does with them being beaten by their opponent.

Of course, limiting exposure to game tape isn’t a completely new concept. Another coach that practiced this, albeit in an era where obtaining video of teams performances was much harder, was legendary UCLA coach John Wooden. Coach Wooden won an unmatched 10 national championships during his tenure and is widely accepted by many to be the greatest college basketball coach of all time.

Given the audience of my blog, you can probably guess that this post isn’t purely about basketball. This got me thinking about how the Wooden/Calipari approach to limiting game tape applies to using “game tape” in information security. In our case, game tape is more commonly known as threat intelligence. In most cases, this is explicit knowledge about an adversary based derived by researching previous compromises and malware samples. While I can’t possibly argue that threat intelligence should be abandoned, it does make me wonder about the emphasis placed on it in certain environments. In the right situation, might it actually be preferable to decrease focus on threat intelligence and instead focus inward to ones own network to perform effective detection? Perhaps it’s possible that threat intelligence can sometimes be used as a crutch that substitutes for understanding your network as well as you should. That’s a bit radical, but it’s food for thought.

Coach Cal and Wooden both had the benefit of having very good players as their disposal. In the same manner, I think selectively limiting reliance on threat intelligence requires an “A team” of players in your SOC. Having the capability to monitor your network assets and relationships on a very granular basis requires talent and resources, and that simply isn’t something most organizations can do. As information security takes a more mainstream role in our society, this may change as new research and tooling is built to support this line of thought. It might also be positively impacted as the general skill gap between established and amateur defenders narrows.

This approach also requires forward thinking viewpoint on the fundamental nature of breaches. It requires that you accept that prevention eventually fails, and that you don’t consider breaches to exist in a binary state of being. An attacker who breaches your network will have a set mission or series of goals, and the degree to which they succeed and the impact to your business or data determines the nature of the breach. There isn’t simply a breach, there are degrees of breaches. Just like a basketball team can’t expect to keep the opposing team from scoring any points at all, the network defender can’t expect their network to remain forever unbreached. At the end of the day, it’s all about making sure you have more points than your opponent/adversary.

All in all, this might be a bit of a stretch. That said, it does have me thinking quite a bit about the reliance on threat intelligence in defending networks, and what can be done to better understand my own network so that I can focus my defense, detection, and response around where critical data exists and where potential weaknesses exist. Ultimately, having great threat intelligence is not a panacea and there are a lot of ways to think about defending networks that exist independently from detailed knowledge of attacker tools, tactics, and procedures.