Category Archives: Analysis

Know Your Bias – Anchoring

In the first part of this series I told a personal story to illustrated the components and effects of bias in a non-technical setting. In each post following I’ll examine a specific type of bias, how it manifests in a non-technical example, and provide real-world examples where I’ve seen this bias negatively affect a security practitioner. In this post, I’ll discuss anchoring.

Anchoring occurs when a person tends to rely too heavily on a single piece of information when making decisions, most often based on information received early in the decision-making process.

Anchoring Outside of Security

Think about the average price of a Ford car. Is it higher or lower than 80,000? This number is clearly too high, so you’d say lower. Now let’s flip this a bit. I want you to think about the average price of a Ford car again. Is it higher or lower than 10,000? Once again, the obvious answer is that it’s higher.

These questions may seem obvious and innocent, but here’s the thing. Let’s say that I ask one group of people the first question, and a separate group of people the second question. After that, I ask both groups to name what they think the average price of a Ford car is. The result is that the first group presented with the 80,000 number would pick a price much higher than the second group presented with the 10,000 number. This has been tested in multiple studies with several variants of this scenario [1].

In this scenario, people are subconsciously fixating on the number they are presented and it is subtly influencing their short term mindset. You might be able to think of a few cases in sales where this is used to influence consumers. Sticking with our car theme, if you’ve been on a car lot you know that every car has a price that is typically higher than what you pay. By pricing cars higher initially, consumers anchor to that price. Therefore, when you negotiate a couple thousand dollars off, it feels like you’re getting a great deal! In truth, you’re paying what the dealership expected, you just perceive the deal because of the anchoring effect.

They key takeaway from these examples is that anchoring to a specific piece of information is not inherently bad. However, making judgements in relation to an anchored data point where too much weight is applied can negatively effect your realistic perception of a scenario. In the first example, this led you to believe the average price of a car is higher or lower than it really is. In the second example, this led you to believe you were getting a better deal than you truly were.

 

Anchoring in Security

Anchoring happens based on the premise that mindsets are quick to form but resistant to change. We quickly process data to make an initial assessment, but our ability to hone that assessment is generally weighed in relation to the initial assessment. Can you think of various points in a security practitioner’s day where there is an opportunity for an initial perception into a problem scenario? This is where we can find opportunities for anchoring to have occurred.

List of Alerts

Let’s consider a scenario where you have a large number of alerts in a queue that you have to work through. This is a common scenario for many analysts, and if you work in a SOC that isn’t open 24×7 then you probably walk in each morning to something similar. Consider this list of the top 5 alerts in a SOC over a twelve hour period:

  • 41 ET CURRENT_EVENTS Neutrino Exploit Kit Redirector To Landing Page
  • 14  ET CURRENT_EVENTS Evil Redirector Leading to EK Apr 27 2016
  • 9 ET TROJAN Generic gate[.].php GET with minimal headers
  • 2 ET TROJAN Generic -POST To gate.php w/Extended ASCII Characters (Likely Zeus Derivative)
  • 2 ET INFO SUSPICIOUS Zeus Java request to UNI.ME Domain

Which alert should be examined first? I polled this question and found that a significant number of inexperienced analysts chose the one at the top of the list. When asked why, most said because of the frequency alone. By making this choice, the analyst assumes that each of these alerts are weighted equally. By occurring more times, the rule at the top of the list represents a greater risk. Is this a good judgement?

In reality, the assumption that each rule should be weighted the same is unfounded. There are a couple of ways to evaluate this list.

Using a threat-centric approach, not only does each rule represent a unique threat that should be considered uniquely, some of these alerts gain more context in the presence of others. For example, the two unique Zeus signatures alerting together could pose some greater significance. In this case, the Neutrino alert might represent a greater significance if it was paired with an alert representing the download of an exploit or communication with another Neutrino EK related page. Merely hitting a redirect to a landing page doesn’t indicate a successful infection, and is a fairly common event.

You could also evaluate this list with a risk-centric approach, but more information is required. Primarily, you would be concerned with the affected hosts for each alert. If you know where your sensitive devices are on the network, you would evaluate the alerts based on which ones are more likely to impact business operations.

This example illustrates the how casual decisions can come with implied assumptions. Those assumptions can be unintentional, but they can still lead you down the wrong path. In this case, the analyst might spend a lot of time pursuing alerts that aren’t very sensitive while delaying the investigation of something that represents a greater risk to the business. This happens because it is easy to look at a statistic like this and anchor to a singular facet of the stat without fully considering the implied assumptions. Statistics are useful for summarizing data, but they can hide important context that will keep you from making uninformed decisions that are the result of an anchoring bias.

 

Visualizations without Appropriate Context

As another example, understand that numbers and visual representations of them have a strong ability to influence an investigation.  Consider a chart like the one in the figure below.

This is a treemap visualization used to show the relative volume of communication based on network ports for a single system. The larger the block, the more communication occurred to that port. Looking at this chart, what is the role of the system whose network communication is represented here? Many analysts I polled decided it was a web server because of the large amount of port 443 and 80 traffic. These ports are commonly used by web servers to receive requests.

This is where we enter the danger zone. An analyst isn’t making a mistake by looking at this and considering that the represented host might be a web server. The mistake occurs when the analyst fully accepts this system as a web server and proceeds in an investigation under that assumption. Given this information alone, do you know for sure this is a web server? Absolutely not.

First, I never specified whether this treemap exclusively represents inbound traffic, and it’s every bit as likely that it represents outbound communication that could just be normal web browsing. Beyond that, this chart only represents a finite time period and might not truly represent reality. Lastly, just because a system is receiving web requests doesn’t necessarily mean its primary role is that of a web server. It might simply have a web interface for managing some other service that is its primary role.

The only way to truly ascertain whether this system is a web server is to probe it to see if there is a listening service on a web server port or to retrieve a list of processes to see if a web server application is running.

There is nothing wrong with using charts like this to help characterize hosts in an investigation.  This treemap isn’t an inherently bad visualization and it can be quite useful in the right context. However, it can lead to investigations that are influenced by unnecessarily anchored data points. Once again, we have an input that leads to an assumption.  This is where it’s important to verify assumptions when possible, and at minimum identify your assumptions in your reporting. If the investigation you are working on does end up utilizing a finding based on this chart and the assumption that it represents a web server, call that out specifically so that it can be weighed appropriately.

 

Diminishing Anchoring Bias

The stories above illustrate common places anchoring can enter the equation during your investigations. Throughout the next week, try to look for places in your daily routine where you form an initial perception and there is an opportunity for anchoring bias to creep in. I think you’ll be surprised at how many you come across.

Here are a few ways you can recognize when anchoring bias might be affecting you or your peers and strategies for diminishing its effects:

Consider what data represents, and not just it’s face value. Most data in security investigations represents something else that it is abstracted from. An IP address is abstracted from a physical host, a username is abstracted from a physical user, a file hash is abstracted from an actual file, and so on.

Limit the value of summary data. A summary is meant to be just that, the critical information you need to quickly triage data to determine its priority or make a quick (but accurate) judgement of the underlying events disposition. If you carry forward input from summary data into a deeper investigation, make sure you fully identify and verify your assumptions.

Don’t let your first impression be your only impression. Rarely is the initial insertion point into an investigation the most important evidence you’ll collect. Allow the strength of conclusions to be based on your evidence collected throughout, not just what you gathered at the onset. This is a hard thing to overcome, as your mind wants to anchor to your first impression, but you have to try and overcome that and try to examine cases holistically.

An alert is not an answer, it’s merely a question. Your job is to prove or disprove the alert, and until you’ve done one of those things the alert is not representative of a certainty. Start looking at alerts as the impetus for asking questions that will drive your investigation.

If you’re interested in learning more about how to help diminish the effects of bias in an investigation, take a look at my Investigation Theory course where I’ve dedicated an entire module to it. This class is only taught periodically, and registration is limited.

[1] Strack, F., & Mussweiler, T. (1997). Explaining the enigmatic anchoring effect: Mechanisms of selective accessibility. Journal of personality and social psychology73(3), 437.

 

 

Know your Bias – Foundations

In this blog series I’m going to dissect cognitive biases and how they relate to information security. Bias is prevalent in any form of investigation, whether you’re threat hunting, reversing malware, responding to an incident, attributing network attacks, or reviewing an IDS alert. In each post, I’ll describe a specific type of bias and how it manifests in various information security specialties. But first, this post will explain some fundamentals about what bias is and why it can negatively influence investigations.

 

What is Bias?

Investigating security threats is a process that occurs within the confines of your mind and centers around bridging the gap between your limited perception and the reality of what has actually occurred. To investigate something is to embrace that perception and reality aren’t the same thing, but you would like for them to be. The mental process that occurs while trying to bridge that perception-reality gap is complex and depends almost entirely on your mindset.

A mindset is how you see and approach the world and is shaped by your genetics and your collective world experience. Everyone you’ve ever met, everything you’ve ever done, and every sense you’ve perceived molds your mindset. At a high level, a mindset is neither a good or bad thing, but it can lead to positive or negative results. This is where bias comes in.

Bias is a predisposition towards a certain way of thinking, and it can be the difference in a successful or failed investigation. In some ways, bias is good when it allows us to learn from our previous mistakes and create mental shortcuts to solving problems. In other ways its bad, and can lead us to waste time pursuing bad leads or jump to conclusions without adequate evidence. Let’s consider a non-technical example first.

 

The (very) Personal Effects of Bias

On a night like any other, I laid my head down on my pillow at about 11 PM. However, I was unexpectedly awoken around 2 AM with wrenching stomach pain unlike anything I’d ever felt before. I tossed and turned for an hour or so without relief, and finally woke my wife up. A medical professional herself, she realized this might not be a typical stomach ache and suggested we head to the emergency room.

About an hour later I was in the ER being seen by the doctor on shift that night. Based on the location of the pain, he indicated the issue was likely gal bladder related, and that I probably had one or more gall stones causing my discomfort. I was administered some pain medication and setup with an appointment with a primary care physician the next day for further evaluation.

The primary care physician also believed that a gal bladder was the likely cause of the previous night’s discomfort, so she scheduled me for an ultrasound the same day. I walked over to the ultrasound lab where they spent about twenty minutes trying to get good images of the area. Shortly thereafter, the ultrasound technician came in and looked at the image and shared his thoughts. He had identified my gal bladder and concluded that it was full of gal stones, which had caused my stomach pain. My next stop was a referral to a surgeon, where my appointment took no more than ten minutes as he quickly recommended I switch to a low fat diet for a few weeks until he could perform surgery to remove the malfunctioning organ.

Fast forward a couple of weeks later and I’m waking up from an early morning cholecystectomy operation. The doctor is there as soon as I wake up, which strikes me as odd even in my groggy state.

“Hey Chris, everything went fine, but…”

Let me take this opportunity to tell you that you never want to hear “but…” seconds after waking up from surgery.

“But, we couldn’t remove your gal bladder. It turns you don’t have one. It’s a really rare thing and less than .1% of the population is born without one, but you’re one of them.”

At first I didn’t believe him. As a matter of fact, I was convinced that my wife had put him up to it and they were messing with me while I wasn’t completely with it. It wasn’t until I got home that same day and woke up again several hours later that I grasped what had happened. I really wasn’t born with a gal bladder, and the surgery had been completely unnecessary.

 

Figure 1: This is a picture of where my gal bladder should be

 

Dissecting the Situation

Let’s dissect what happened here.

  1. ER Doctor: Believed I was having gal bladder issues based on previous patients presenting with similar symptoms. Could not confirm this in the ER, so referred me to a primary care physician.
  2. Primary Care Doctor: Also believed the gal bladder issue was likely, but couldn’t confirm this in her office, so she referred me to a radiologist.
  3. Radiologist: Reviewed my scans to attempt to confirm the diagnosis of the previous two doctors. Found what appeared to be confirming evidence and concluded my gal bladder was malfunctioning.
  4. Surgeon: Agreed with the conclusion of the radiologist (without looking at the source data himself) and proceeded to recommend surgery, which I went through.

So where and why did things go wrong?

For the most part, the first two doctors were doing everything within their power to diagnose me. The appropriate steps of a differential diagnosis instruct physicians to identify the most likely affliction and perform the test that can rule that out. In this case, that’s the ultrasound that was performed by the radiologist, which is where things started to go awry.

The first two doctors presented a case for a specific diagnosis, and the radiologist was predisposed towards confirming this bias before even looking at the scans. It’s a classic case of finding something weird when you go looking for it, because everything looks a little weird when you want to find something. In truth, the radiologist wasn’t confident in his finding, but he let the weight of the other two doctor’s opinions bear down on him such that he was actually seeking to confirm their diagnosis more than trying to independently come to an accurate conclusion. This is an example of confirmation bias, which his perhaps the most common type of bias encountered. It also represents characteristics of belief bias and anchoring.

The issue here was compounded when I met the surgeon. Rather than critically assessing the collective findings of all the professionals that were involved to this point, he assumed a positive diagnosis and merely glanced at the ultrasound results in passing. All of the same biases are repeated here again.

In my case bias led to an incorrect conclusion, but understand that even if my gal bladder had been the issue and the surgery went as expected, the bias was still there. In many (and sometimes most) cases, bias might exist and you will still reach the correct conclusion. That doesn’t mean that the same bias won’t cause you to stumble later on.

 

Consequences of Bias

In my story, you see that bias resulted in some fairly serious consequences. Surgery is a serious matter, and I could have suffered some type of complication while on the table, or a post op infection that could have resulted in extreme sickness or death.

In any field, bias influences conclusions and those conclusions have consequences when they result in action being taken. In my case, it was a few missed days of work and a somewhat painful recovery. In security investigations, bad decisions can result in wasted time pursuing leads or missing something important. The latter could have drastic effects if you work for a government, military, ICS environment, or any other industry where lives depend on system integrity and uptime. Even if normal commercial environments, bad decisions resulting from the influence of bias can lead to millions of lost dollars.

Let’s examine one other effect of this scenario. I’m a lot less likely to trust the conclusions of doctors now, and I’m a lot less likely to agree to surgery without a plethora of supporting evidence indicating the need for it. These things in themselves are a form of bias. This is because bias breeds additional bias. We saw this with the relationship between the radiologist and the surgeon as well.

The effects of bias are highly situational. It’s best not to think of bias as something that dramatically changes your entire outlook on a situation. Think of bias like a pair of tinted glass that subtly influences how you perceive certain scenarios. When the right bias meets the right set of circumstances, things can go bad quickly.

 

Countering Bias

Bias is insanely hard to detect because of how it develops in either an individual or group setting.

In an individual setting, bias is inherent to your own decision making. Since humans inherently stink at detecting their own bias, it is unlikely you will become aware of it unless your analysis is reviewed by someone else who points it out. Even then, bias usually exists in small amounts and is unlikely to be noticed unless it meets a certain threshold that is noticeable by the reviewer.

In a group setting, things get complicated because bias enters from multiple people in small amounts. This creates a snowball effect in which group bias exists outside the context of any specific individual. Therefore, if hand offs occur in a linear manner such that each person only interacts one degree downstream or upstream, it is only possible to detect overwhelming bias at the upstream levels. Unfortunately, in real life these upstream levels are usually where the people are less capable of detecting the bias because they have lesser subject matter expertise in the field. In security, think managers and executives trying to catch this bias instead of analysts.

Let me be clear – you can’t fully eliminate bias in an investigation or in most other walks of your life. The way humans are programmed and the way our mindsets work prohibit that, and honestly, you wouldn’t want to eliminate all bias because it can be useful at times too. However, you can minimize the effects of negative bias in a couple of ways.

Evidence-Based Conclusions

A conclusion without supporting evidence is simply a hypothesis or a belief. In both medicine and information security, belief isn’t good enough without data to support it. This is challenging in many environments because visibility isn’t always in all the places we need it, and retention might not be long enough to gather the information you need when an event occurred far enough in the past. Use these instances to drive your collection strategy and justify appropriate budget for making sound conclusions.

In my case, two doctors made hypotheses without evidence. Another doctor gathered weak evidence and made a bad decisions, and another doctor confirmed that bad decision because the evidence was presented as a certainty when it actually wasn’t. A review of the support facts would have led the surgeon to catch the error before deciding to operate.

Peer Review

By definition, you aren’t aggressively aware of your own bias. Your mindset works the way it works and that is “normal” to you, so your ability to spot biased decisions when you make them is limited. After all, nobody comes to a conclusion they know to be incorrect. As Sheldon from the Big Bang Theory would say, “If I was wrong, don’t you think I’d know it?”

This is where peers come in. The surgeon might have caught the radiologist’s error if he had thoroughly reviewed the ultrasound results. Furthermore, if there was a peer review system in place in the radiology department, another person might have caught the error before it even got that far. Other people are going to be better at identifying your biases than you are, so that is an opportunity to embrace your peers and pull them in to review your conclusions.

Knowledge of Bias

What little hope you have of identifying your own biases doesn’t manifest during the decision-making process, but instead during the review of your final products and conclusions. When you write reports or make recommendations, be sure to identify the assumptions you’ve made. Then, you can review your conclusions as weighed against supporting evidence and assumptions to look for places bias might creep in. This requires a knowledge of common types of bias and how they manifest, which is precisely the purpose of this series of blog posts.

Most physicians are trained to understand and recognize certain types of bias, but that simply failed in my case until after the major mistakes had been made.

 

Conclusion

The investigation process provides an opportunity for bias to affect conclusions, decisions, and outcomes.  In this post I described a non-technical example of how bias can creep in while attempting to bridge the gap from perception to reality. In the rest of this series I’ll focus on specific types of bias and provide technical and non-technical examples of the bias in action, along with strategies for recognizing the bias in yourself and others.

As it turns out my stomach aches eventually stopped on their own. I never spoke to the radiologist again, but I did speak to the surgeon at length and he readily admitted his mistake and felt horrible for it. Some people might be furious at this outcome, but in truth, I empathized with his plight. Complex investigations, be it medical or technical, present opportunity for bias and we all fall victim to it from time to time. We’re all only human.

 

 

If you’re interested in learning more about how to help diminish the effects of bias in an investigation, take a look at my Investigation Theory course where I’ve dedicated an entire module to it. This class is only taught periodically, and registration is limited.

The Effects of Opening Move Selection on Investigation Speed

What follows is a shortened version of a longer paper that will be released at a later time. You can also learn more about this research by watching my recent Security Onion Conference 2016 video where I discuss these results and other similar experiments.

Background

The core construct of computer network defense is the investigation. It’s here where human analysts receive anomalous signals and pursue evidence that might prove the existence of an information system breach. While little formalized methodology related to the investigation process exists, research in this area is beginning to emerge.

Existing research in human thought and knowledge acquisition is applicable to information security and computer network defense. Daniel Kahneman provided modern research in support of a dual-process theory of thinking that defines two separate processes governing human thought. The first process, called intuitive or system 1 thinking, is automatic and usually kicks in without directly acknowledging it. You don’t have to think about brushing your teeth or starting your car, you just do it. The second process, called reflective or system 2 thinking, is deliberate and requires attentive focus. You have to think about math problems and your next move when playing checkers. Both of these systems are in play during the investigation process.

In an investigation, analysts use intuitive thought when pursuing data related to an alert. This is most often the case when the analyst makes their opening move. The analyst’s opening move is the first data query they execute after receiving an alert. By virtue of being the first move, the analyst doesn’t apply a lot of explicit reflective thought on the issue and they simply jump to the place they believe will provide the quickest and most definitive answer. It’s assumed that in these cases, the analyst’s first move is probably the data source they perceive as being the most valuable.

The goal of the present research is to determine which common data source analysts were more likely to use as their opening move, and to assess the impact of that first move on the speed of the investigation.

Methods

The foundation of this research was a purpose built investigation simulator. The investigation simulator was built to recreate the investigation environment in a tool agnostic manner, such that individual scenarios could be loaded for a sample population and the variables could be tightly controlled.

A pool of security analysts was selected based on their employment history. Every analysts selected was currently or recently in a role were they were responsible for investigating security alerts to determine if a security compromise had occurred. Demographic information was collected, and analysts were placed into three skills groups based on their qualifications and level of experience: novice, intermediate, or expert.

 

Group A – Exploit Kit Infection

The primary experiment group was asked to connect to the investigation simulator remotely and work through the investigation scenario provided to arrive at a conclusion whether an infection or compromise had successful occurred.

The scenario presented the user with a Suricata IDS alert indicating that an internal host visited an exploit kit landing page.

 

openingmove-figure1

Figure 1: The Suricata IDS alert that initiated the simulation

The following data sources were provided for investigation purposes:

Data Source Query Format Output Style
Full packet capture (PCAP) Search by IP or port TCPDump
Network flow/session data Search by IP or port SiLK IPFIX
Host file system Search by filename File path location
Windows Logs Option: User authentication/process create logs Windows event log text
Windows Registry Option: Autoruns/System restore/application executions (MUI cache) Registry keys and values
Antivirus Logs Search by IP Generic AV log text
Memory Option: Running process list/Shim cache Volatility
Open Source Intelligence Option: IP or domain reputation/file hash reputation/Google search Text output similar to popular intelligence providers

Table 1: Data source provided for Group A

Subjects were instructed that they should work towards a final disposition of true positive (an infection occurred), or false positive (no infection occurred). Whenever they had enough information to reach a conclusion, they were to indicate their final disposition in the tool, at which point the simulation exited.

The simulator logged every query the analysts made during this experiment, along with a timestamp and the start and end time. This produced a timeline of the analysts enter investigation, which was used to evaluate the research questions.

 

Group B – PCAP Data Replaced with Bro Data

Based on results achieved with group A, a second non-overlapping sample group of analysts were selected to participate in another experiment. Since group indicated a preference for higher context PCAP data, the second scenario removed the PCAP data option and replaced it with Bro data, another high context data source that is more structured and organized. The complete list of data sources provided for this group were:

Data Source Query Format Output Style
Bro Search by IP Bro
Network flow/session data Search by IP or port SiLK IPFIX
Host file system Search by filename File path location
Windows Logs Option: User authentication/process create logs Windows event log text
Windows Registry Option: Autoruns/System restore/application executions (MUI cache) Registry keys and values
Antivirus Logs Search by IP Generic AV log text
Memory Option: Running process list/Shim cache Volatility
Open Source Intelligence Option: IP or domain reputation/file hash reputation/Google search Text output similar to popular intelligence providers

Table 2: Data source provided for Group B

All experiment procedures and investigation logging measures remained in place, consistent with group A.

Group C – Survey Group

A third semi-overlapping group was selected at random to collect self-reported statistics to assess what opening move analysts self reported they would be more likely to make given a generic investigation scenario.

Using a combination of manually polling analysts and collecting responses from Twitter polling, analysts were asked the following question:

In a normal investigation scenario, what data source would you look at first?

The multiple-choice options presented were:

  1. PCAP
  2. Flow
  3. Open Source Intelligence
  4. Other

Results

The first item evaluated was the distribution of opening moves. Simply put, what data source did analysts look at first?

In Group A, an 72% of analysts chose PCAP as their first move, 16% chose flow data, and the remaining 12% chose OSINT. The observed numbers differ significantly from the numbers analysts reported during information polling. In the Group C polling, 49% of analysts reported PCAP would be their first move, 28% chose flow data, and 23% chose OSINT.

openingmove-chart1

Chart 1: Opening move selection observed for Group A

The mean time to disposition (MTTD) metric was calculated for each first move group by determining the difference between start and end investigation time for each analysts and averaging the results of all analysts within the group together. Analyst’s who chose PCAP had a MTTD of 16 minutes, those who chose flow had a MTTD of 10 minutes, and those who chose OSINT had a MTTD of 9 minutes.

openingmove-chart2

Chart 2: Time to disposition for Group A

 

In Group B where PCAP data was replaced with Bro data, 46% of analysts chose Bro data as their first move, 29% chose OSINT, and 25% chose flow.

openingmove-chart3

Chart 3: Comparison of group A and B opening moves

Analysts who chose Bro had a MTTD of 10 minutes, while those who chose flow and OSINT and MTTDs of 10 minutes and 11 minutes, respectively.

openingmove-chart4

Chart 4: Comparison of group A and B average time to close

Discussion

While not entirely conclusive, the data gained from this research does provide several suggestions. First, given an overwhelming 72% of people chose to begin their investigation with PCAP data, it’s clear that analysts prefer a higher context data source when its available, even if other lower context data sources available. In these simulations there were multiple ways to come to the correct conclusion, and PCAP data did not have to be examined at all to reach it.

The data also suggests that an opening move to a high context but relatively unorganized data source can negatively affect the speed an analyst reaches an appropriate conclusion. The MTTD for analysts whose opening move was PCAP in Group A was significantly higher than those who started with lower context data sources flow and OSINT. This is likely because PCAP data contains extraneous data that isn’t beneficial to the investigator, and it takes much longer to visually parse and interpret. Examining the results of the group B experiment further supports this finding. PCAP was replaced with Bro log data, which generally contains most of the same useful information that PCAP provides, but organizes it in a much more intuitive way that makes it easier to sift through. Analysts who chose Bro data for their opening move had a MTTD that was much lower than PCAP and comparable to flow and OSINT data sources.

The comparison between observed and reported opening moves highlights another finding that analysts often don’t understand their own tendencies during an investigation. There was a significant difference between the number of people who reported they would choose to investigate an anomaly with PCAP, and those who actually did. Opening move selection is somewhat situational however, so the present study did not introduce enough unique simulations to truly validate the statistics supporting that finding.

Possible limitations for this study mostly center on a limited number of trials, as only one simulation (albeit modified for one group) was used. More trials would serve to strengthen the findings. In addition, there is some selection bias towards analysts who are more specialized in network forensics than host forensics. This likely accounts for no first moves being to host-based data. Additionally, in the simulations conducted here access to all data sources took an equal amount of time. In a real world scenario, some data sources take longer to access. However, since PCAP and other higher context data sources are usually larger in size on disk, the added time to retrieve this data would only strengthen these findings that PCAP data negatively affects investigation speed.

Conclusion

Overall, this research provides insight into the value of better organized higher context data sources. While PCAP data contains an immense level of context, it is also unorganized, hard to filter and sift through compared to other data types, and has extraneous data not useful for furthering the investigation. To improve investigation efficiency, it may be better to make opening moves that start with lower context data sources so that a smaller net can be cast when it comes time to query higher context sources. Furthermore, when more organized higher context data sources are available, they should be used.

While the present research isn’t fully conclusive due to its sample size and a limited number of simulation trials, it does provide unique insight into the investigation process. The methods and strategy used here should be applicable for additional research to further confirm the things this data suggests.

 

Interested in learning more about the investigation process, choosing the right data sources to look at, and becoming a better analyst? Sign up here to be the first to hear about my new analyst training course being released later this year. Mailing list subscribers will get the first opportunity to sign up for the exclusive web-based course, and space is limited. Proceeds from this course will go to benefit charity.

The Role of Curiosity in Security Investigations

curiousgeorgeI’ve written a lot about the metacognitive gap in digital forensics and incident response. As an industry, we aren’t very effective at identifying the skills that make our expert practitioners so good at what they do, and we are even worse at teaching them. While there are a myriad of skills that make someone good at finding evil and eradicating adversaries, what’s the most important? What is the “X Factor” that makes an investigator great?

That’s a highly subjective question and everyone has an opinion on it biased towards his or her own experience. Regardless, I recently posed this question to some of my coworkers and Twitter followers. The most common answer I received was centered on curiosity.

Based on these results, I conducted a semi-formal survey where I asked 12 experienced analysts to rate the importance of possessing a highly curious mind while attempting to solve an investigation.

In the first survey item, I asked respondents to address the statement “A curious mind is important for an investigator to arrive at a state of resolution in an investigation with accurate and thorough results.”

All 12 investigators responded Strongly Agree using a 5-point Likert scale.

In a second question, I asked respondents to address the statement “A curious mind is important for an investigator to arrive at a state of resolution in an investigation in a timely manner.”

Using the same rating sale, 10 investigators responded Strongly Agree and 2 responded Agree.

Finally, I asked respondents to address the statement “A curious mind is a primary factor in determining whether an investigator will be successful in resolving/remediating an investigation.”.

Using the same rating sale, all 12 analysts responded Strongly Agree.

Clearly, expert practitioners believe that a curious mind is important in terms of accuracy, thoroughness, and speed at which an investigation is conducted. While curiosity isn’t the only thing makes an investigator successful in their craft, it certainly warrants attention as a key player. In this post I will talk about curiosity as a trait, how it manifests in the investigative process, how it’s measured, and whether it’s a teachable skill.

What is Curiosity?

There are many definitions of curiosity scattered across psychology research text, but the one I think most accurately depicts the construct from an applied perspective comes from Litman and Spielberger (2003). They state that curiosity can be broadly defined as a desire to acquire new information, knowledge, and sensory experience that motivates exploratory behavior.

Lowenstein (1994) also provides relevant insight by defining curiosity as “the desire to know.” In this sense, he describes that a desire to know more can arise when a person encounters stimuli that are inconsistent with an idea he or she holds. When this is experienced, the person may feel some kind of deprivation that can only be alleviated by resolving this inconsistency and closing the knowledge gap that has been identified. This jives well with the thoughts of other great psychology thinkers like Kant and Freud.

Curiosity takes form early in life when infants start exploring the world around them to test the limitations of their own body. Many developmental psychologists agree that this curiosity and simple but constant experimentation is the foundation of early learning and normal development. As we grow older, our curiosity continues to spark experimentation.

While curiosity has been considered a research-worthy construct from a theoretical perspective, there has been little effort put into pinning down the neural substrates that underlie it. This is unfortunate, but something to look forward to as neurology and brain imaging techniques continue to rapidly advance.

As it relates to computer security investigations, curiosity manifests practically in a number of ways that most of us can easily recognize. A few of those include the following:

 

Dead End Scenarios

The most dreaded scenario in an investigation occurs when an investigator reaches a point where there are still unanswered questions, but there are no leads left to pursue answers. This is common, especially when things like data retention and availability often limit us. In these scenarios a required data source might not be available, a lead from other evidence could run dry, or the data might not point to an obvious next step.

A limited amount of curiosity can be correlated with an increased number of dead end experiences encountered by an investigator. Without adequate motivation to explore additional avenues for answering questions, the investigation might miss logical paths to the answers they are seeking. They may also fail to adequately ask the appropriate questions.

 

Hypothesis Generation

The investigative process provides many opportunities for open-ended questions, such as “What is responsible for the network traffic?” or “Why would this internal host talk to that external host?” The process of reasoning through these questions is usually characterized initially by divergent thinking to generate ideas to be explored in route to a possible solution. This manifests as an internal dialog when conducted by a single analyst, but can be expressed verbally when a group is involved.

When presented with an open-ended question, curiosity is responsible for motivating the internal evaluation of hypothetical situations. Without curiosity, an individual won’t conduct mind-wandering exercises and may only consider a small number of potential hypotheses when there is potential for many other valid ones. In this scenario an investigator might not be pursuing the correct answers because they haven’t considered all of the potential questions that should be asked.

Note: It’s probably worth noting here that creativity plays a role in this process too, and is linked to curiosity depending on which model you subscribe to. That, however, is a little beyond the scope of what I want to talk about here.

 

Data Manipulation

Looking at the same data in different ways can yield interesting results. This can include using sed, grep, and awk to pull specific columns out of a data stream for comparison, using uniq and sort to aggregate field values, or reducing PCAP data into flows for comparison of multiple data streams.

While having the skills to manipulate data is a separate discussion, having the desire to find out if the manipulation of existing data into a new format will yield useful results is a product of curiosity. Investigators who lack curiosity to find out if such an exercise would be fruitful end up in more dead end scenarios and may take longer routes towards resolving investigations.

 

Pivoting to Tangential Evidence

The goal of collecting and reviewing evidence is to yield answers relevant to the question(s) an investigator has asked. However, it’s common for the review of evidence to introduce tangential questions or spawn completely new investigations. Within an investigation, you might review network connections between a friendly internal host and a potentially hostile external host only to find that other friendly devices have communicated with the hostile device and warrant examination. In another example, while examining web server logs for exploitation of a specific vulnerability, you might find unrelated evidence of successful SQL injection that warrants a completely separate investigation.

Curiosity is a key determinant in whether an investigator chooses to pivot to these tangential data points and pursue their investigation. Without the motivation that curiosity provides, an investigator may neglect to provide more than a cursory glance to these data points, or fail to note them down for later review. This can result in missed intrusions or improper scoping.

Relating Curiosity and Experience

Our cognitive processes don’t operate in a vacuum. Any decision we make is influenced by a symphony of different traits and emotions working in concert together. Some work in perfect harmony while others operate as opposing forces, and curiosity is not exempt. When we talk about curiosities role in an investigation, we also have to talk about experience.

Earlier, I mentioned that curiosity is pivotal to human development, and that our experimentation at an early age is motivated by curiosity to learn more about ourselves and the world around us. This isn’t a characteristic that goes away with time; we just become more aware of it. As we get older, we gain more experience and become more selective of what experiments we conduct. This manifests in many forms of our lives and in every day decisions. For example, a person who has never slept in on a Tuesday might hit the snooze button a few times because curiosity motivates them to explore the benefits and/or consequences of that action.

Experience serves as both a motivating and regulating force for curiosity. In an investigation, I believe this is best illustrated by assessing curiosity and experience as they relate to each other. Consider the following scenarios where we assess the level of curiosity (C) and experience (E) possessed by an individual investigator.

High C / Low E:

With a lot of curiosity but little experience, an investigator is jumpy. This person’s curiosity drives them to dig into everything that seems new, and without experience to regulate it, this persons ends up chasing a lot of ghosts. They will encounter dead end scenarios frequently because they will choose to pursue inconsequential leads within the evidence they are reviewing. They will rarely admit to encountering a dead-end scenario because their lack of experience doesn’t permit them to realize they’ve encountered one. This person will generate many ideas when hypothesis generation is required, but many of those ideas will be unrealistic because of a lack of experience to weed out the less useful ones. They will seek alternate views of data constantly, but will spend a considerable amount of time pursuing alternate views that don’t necessarily help them. Instead of learning to use tools that get them close to the views they want, they’ll spend time attempting to do more manual work to get the data precisely how they desire even if going that extra 20% doesn’t provide a discernable benefit to their investigation. Even though this person will spend a lot of time failing, they will fail fast and gain experience quickly.

Low C / High E

An investigator possessing a lot of experience but little curiosity could be described as apathetic. This doesn’t necessarily mean they aren’t effective at all, but it does make them less likely to investigate tangential leads that might be indicative of a larger compromise scope or a secondary compromise. In many cases, a person in this state may have started with a high degree of curiosity, but it may have waned over time as their experience increased. This can result in the investigator using their experience as a crutch to make up for their lack of curiosity. They won’t encounter too many dead end scenarios because of this, but may be more prone to them in new and unfamiliar situations. This person will manipulate data, but will rely on preexisting tools and scripts to do so when possible. They will carefully evaluate the time/reward benefit of their actions and will trust their gut instinct more than anything else. This person’s success in resolving investigations will be defined by the nature of their experience, because they will be significantly less successful in scenarios that don’t relate to that experience. These individuals won’t be as highly motivated in terms of out-of-the-box thinking and may be limited in hypothesis generation.

High C / High E

Because this person has a high level of curiosity they will be more motivated to investigate tangential leads. Because they also possess a high level of experience, they will be more efficient in choosing which leads they follow because they will have a wealth of knowledge to reflect upon. When encountering a dead-end scenario, this person should be able to move past it quickly, or if they claim they’ve hit a true dead end, it’s more likely to be an accurate representation of the truth. This person will excel in hypothesis generation and will provide valuable input to lesser experienced investigators relating to how their time could be best spent. They will seek to perform data manipulation when possible, but will be adept at realizing when to use already available tools and when to create their own. They will realize when they’ve found a data manipulation solution that is good enough, and won’t let perfect be the enemy of good enough. This presents an ideal scenario where the investigator is highly capable of resolving an investigation and doing so in a timely manner. These individuals are ideal candidates for being senior leaders, because they can often effectively guide less experienced investigators regarding what leads are worth pursuing and what the right questions to ask are. This person is always learning and growing, and may have several side projects designed to make your organization better.

Low C / Low E

This presents an undesirable scenario. Not only does this person not have the experience to know what they are looking at, they don’t have enough curiosity to motivate them to perform the necessary research and experimentation needed to learn more. This will handicap their professional growth and have them getting outpaced by their peers with a similar amount of experience.

 

If you are an investigator or have spent time around a lot of them then the descriptions you read in each of these scenarios might remind you of someone you know, or even yourself at different points in your career. It’s important to also consider progression, because the level of curiosity and experience of a person changes throughout their career. In these scenarios, a person always starts with no experience but their level of curiosity may affect how quickly that experience is gained.

 

High Curiosity – Sustained

c1

In this ideal scenario, an investigator learns very quickly, and the rate at which they learn also grows. As they realize there is more to learn, they begin to consume more information in more efficient ways.

 

High Curiosity – Waning

c2

While many start very curious, some experience a waning level of curiosity as their experience grows. When this happens, these investigators will rely more on their experience and their rate of learning will slow.

 

Low Curiosity – Sustained

c3

An investigator with a sustained level of low curiosity will continually learn, but at a very slow rate through their career. Peers with a similar number of years experience will outpace them quickly.

 

Low Curiosity – Growing

c4

If an investigator is able to develop an increased level of curiosity over time, their rate of learning will increase. This can result in dramatic mid to late career growth.

 

Each of these scenarios represents a bit of an extreme case. In truth, the progression of an investigators career is affected by many other factors, and curiosity can often take a back seat to other prevailing forces. Most of us who have served in an investigative capacity also know that curiosity often comes in peaks and valleys as new ideas or technologies are discovered. For instance, new tools like Bro have sparked renewed interest for many in the field of network forensics, while the maturity of memory analysis tools like Volatility have sparked curiosity for many in host-based forensics. A new job or changes in someone’s personal life can also positively or negatively affect curiosity.

Recognizing and Assessing Curiosity

We’ve established that curiosity is a desirable trait, and we’ve reviewed examples of what an investigator possessing varying degrees of curiosity and experience might look like. It’s only logical to consider whether curiosity is a testable characteristic. Several researchers have tackled this problem, and as a result there are different tests that can be used to measure varying degrees of this construct.

Available tests include, but are not limited to, the State-Trait Personality Inventory (Spielberger et al, 1980), the Academic Curiosity Scale (Vidler & Rawan, 1974), and the Melbourne Curiosity Inventory (Naylor, 1981). All of these tests are simple self-reported pencil and paper inventories designed to ask somewhat abstract questions in order to assess different facets of curiosity. Some use likert scales to evaluate whether statements describe them, where as others use agreement/disagreement choices in response to whether specific activities sound interesting. These tests all use different models for curiosity, spanning three, four, and five-factor models. They also all require someone with an understanding of administering personality tests to deliver and interpret the results.

A paper published by Reio, et al (2016) completed a factor analysis study of eleven different test designed to measure facets of curiosity. Their findings confirmed research done other psychologists that supports a three-factor model for curiosity delineated by cognitive, physical thrill seeking, and social thrill seeking components. Of course, the former of those is most interesting in our pursuits.

Psychometrics and personality testing is a very unique field of research. While many tests exist that can measure curiosity to some degree, their delivery, administration, and interpretation isn’t entirely feasible by those outside of the field. Simply choosing which test to administer requires a detailed understanding of test reliability and validity beyond what would be expected in a normal SOC. Of course, there is room for more investigation and research here that might yield simplified versions of these personality inventories that are approachable by technical leaders. This is yet another gap that can be bridged where psychology and information security intersect.

Teaching and Promoting Curiosity

Many believe that there is an aspect of curiosity that is a product of nature, and one that is a product of nurture. That is to say some people are born innately with a higher level of curiosity than others. The nature/nurture debate is one of the most prolific arguments in human history, and it goes well beyond the scope of my this article. However, I think we can stipulate that all humans are born with an innate ability to be curious.

If we know curiosity is important, that humans are born with a capacity for it, and we have models that can assess it, the practical question is whether we can teach it. As the field of cognitive psychology has grown, academics have sought to increase the practical application of research in this manner, incorporating the last hundred years of research on reasoning, memory, learning, and other relevant topics.

Nichols (1963) provides useful insight about scenarios that can inhibit and foster curiosity. He identifies three themes.

 

Theme 1: Temperance

A state of temperance is a state of moderation or restraint. While we usually think that it’s in our best interest to absorb all the information we can in an investigation, this can actually serve to limit curiosity. In short, a hungry man is much more curious than a well-fed one.

I think Nichols says it best, “Intemperance in a work situation is largely a condition we bring upon ourselves by limiting our mental exercise to a narrow span of interest. This is most commonly manifested in an over-attention paid to the details of what we are doing. Once our mind becomes satiated by an abundance of minor facts, we cannot, merely by definition, provide it with new and fresh ideas that will allow us to expand our intellectual perception. Our capacity to do so is restricted by our inability to cram more into a mind that is already overburdened by minutiae. Instead, if we recognize that our responsibility is to focus on the vital few points rather than the trivial many, we will have released ourselves so that we may—as the juggler does—examine these areas from several vantage points and mentally manipulate them in a way that will be both more productive and give greater self-satisfaction (Nichols, 1963, p.4). “

 

Theme 2: Success and Failure

When know this from basic principles of conditioning that humans will use avoidance techniques to prevent experiencing a stimulus that is perceived as negative. Because of this, an investigator who repeatedly attempts to perform the same activity and fails will be dissuaded from pursuing that activity. As we’ve established curiosity as a motivation to fill knowledge gaps, it’s clear to see the correlation between repeated failure and decreased curiosity.

For example, an investigator who has little scripting ability might decide that they would like to write a script to output the contents packet capture file and print all of the DNS queries and responses. If they attempt this multiple times and fail, they will eventually just move on to other methods of inquiry. At this point they are much less likely to pursue this same task again, and worse, are much less likely to attempt to solve similar problems using scripting techniques.

 

Theme 3: Culture

Whenever someone is surrounded by a group of others without any sense of curiosity, it’s likely that their level of curiosity will slow or cease growing at all. Fortunately, the opposite of the previous case is also true, as Nichols noted, “Just as association with a group methodically killing curiosity soon serves to stifle that precious commodity within us, becoming part of a group concerned with intellectual growth stimulates our personal curiosity and growth. This does not mean that each of us must throw over our present job, don a white lab coat, and head for the research and development department. It does mean that we should be discriminating in our choice of attitudinal surroundings both on and off the job. Specifically, it requires that we surround ourselves with doers, with competition that will give us incentive to exercise the creative abilities that grow out of intellectual curiosity. We all have the opportunity to find and benefit from an environment that stimulates our curiosity if we only seek it (Nichols, 1963, p.4).”

 

I’ve written extensively about creating a culture of learning, but there is something to be said for creating a culture of curiosity as a part of that. In a more recent study (Koranda & Sheehan, 2014), a group of researchers concerned with organizational psychology in the advertising field built upon that practical implications of Nichols’ work and designed a course with the goal of promoting curiosity in advertising professionals. This, of course, is another field highly dependent on curiosity for success. While this study stopped short of using one of the aforementioned inventories to measure curiosity before and after the course, the researchers did use less formal surveys to ascertain a distinguishable difference in curiosity for those who had participated in the course.

Based on all these things we can identify impactful techniques that can be employed in the education of computer security investigators encompassing formal education, shorter-term focused training, and on-the-job training. I’ve broken those into three areas:

Environment

  • When possible, encourage group interaction and thinking as much as possible. It exposes investigators to others with unique experience and ways of thinking.
  • Provide an environment that is rich in learning opportunities. It isn’t enough to expect an investigator to wade through false positive alerts all day and hope they maintain their curiosity. You have to foster it when scenario-based learning that is easily accessible.

Tone

  • Encourage challenging the status quo and solving old problems in new ways. This relates directly to data manipulation, writing custom code, and trying new tools.
  • Stimulate a hunger for knowledge by creating scenarios that allow investigators to fail fast and without negative repercussions. When an investigator is met with success, make sure they know it. Remember that experience is the thing we get when we don’t get what we wanted.
  • Pair lesser experienced investigators with mentors. This reduces the change of repetitive failure and increases positive feedback.

Content

  • Tie learning as much as possible to real world scenarios that can be solved in multiple ways. If every scenario is solved in the same way or only provides one option, it limits the benefits of being curious, which will stifle it.
  • Create scenarios that are intriguing or mysterious. Just like reading a book, if there isn’t some desire to find out what happens next then the investigator won’t invest time it and won’t be motivated towards curiosity. The best example I can think of here is the great work being done by Counter Hack with Cyber City and the SANS Holiday Hacking Challenges.
  • Present exercises that aren’t completely beyond comprehension. This means that scenario difficulty should be appropriately established and paired correctly with the individual skill sets of investigators participating in them.

 

Of course, each of these thoughts presents a unique opportunity for more research, both of a practical and scientific manner. You can’t tell someone to “be more curious” and expect them to just do it any more than you can tell someone “be smarter” and expect that to happen. Curiosity is regulated by a complex array of traits and emotions that aren’t fully understood. Above all else, conditioning applies. If someone is encouraged to be curious and provided with opportunities for it, they will probably trend in that direction. If a person is discouraged or punished for being curious or isn’t provided opportunities to exhibit that characteristic, they will probably shy away from it.

Conclusion

Is curiosity the “X factor” that makes someone good at investigating security incidents? It certainly isn’t the only one, but most would agree that it’s in that conversation and it’s importance can’t be understated.

In this article I discussed the construct of curiosity, why it’s important, how it manifests, and what can be done to measure and promote it. Of course, beyond the literature review and application to our field, many of the things presented here are merely launching points for more research. I look forward to furthering this research myself, and hearing from those who have their own thoughts.

 

References:

Koranda, D., & Sheehan, K. B. (2014). Teaching Curiosity: An Essential Advertising Skill?. Journal Of Advertising Education18(1), 14-23

Litman, J. A., & Spielberger, C. D. (2003). Measuring epistemic curiosity and its diversive and specific components. Journal of personality assessment,80(1), 75-86.

Lowenstein, G. (1994). `The Psychology of Curiosity: A Review and Reinterpretation.

Naylor, F. D. (1981). A state-trait curiosity inventory. Australian Psychologist,16(2), 172-183.

Nichols, R. G. (1963). Curiosity – The Key to Concentration. Management Of Personnel Quarterly2(1), 23-26.

Reio, T. J., Petrosko, J. M., Wiswell, A. K., & Thongsukmag, J. (2006). The Measurement and Conceptualization of Curiosity. The Journal Of Genetic Psychology: Research And Theory On Human Development167(2), 117-135. doi:10.3200/GNTP.167.2.117-135

Vidler, D. C., & Rawan, H. R. (1974). Construct validation of a scale of academic curiosity. Psychological Reports35(1), 263-266.

Inattentional Blindness in Security Investigations

*Disclaimer: Psychology Related Blog Post*

bellJoshua woke up on a frigid Friday morning in Washington, DC and put on a black baseball cap. He walked to the L’Enfant metro station terminal and found a nice visible spot right near the door where he could expect a high level of foot traffic. Once positioned, he opened his violin case, seeded it with a handful of change and a couple of dollar bills, and then began playing for about 45 minutes.

During this time thousands of people walked by and very few paid attention to Joshua. He received several passing glances while a small handful stopped and listened for a moment. Just a coupe lingered for more than a minute or two. When he finished playing, Joshua had earned about twenty-three dollars beyond the money he put into the case himself. As luck would have it, twenty of those dollars came from one individual who recognized Joshua.

Joshua Bell is not just an ordinary violin player. He is a true virtuoso who has been described as one of the best modern violinist in the world, and he has a collection of performances and awards to back it up. Joshua walked into that metro terminal, pulled out a three hundred year old Stradivarius violin, and played some of the most beautiful music that most of us will hear in our lifetime. That leaves the glaring questions: why did nobody notice?

Inattentional Blindness

Inattentional blindness (IB) is an inability to recognize something in plain sight, and it is responsible for the scenario we just described. You may have heard this term before if you’ve had the opportunity to subject yourself to this common selective attention test: https://www.youtube.com/watch?v=vJG698U2Mvo.

As humans, the ability to focus our attention on something is a critical skill. You focus when you’re driving to work in the morning, when you are performing certain aspects of your job, and when you are shopping for groceries. If we didn’t have the ability to focus our attention, we would have a severely limited ability to perceive the world around us.

The tricky thing is that we have limited attention spans. We can generally only focus on a few at a time, and the more things we try to focus on, the less overall focus can be applied to any one thing. Because of this, it is easy to miss things that are right in front of us when we aren’t focused on finding them. In addition, we also tend to perceive what we expect to perceive. These factors combine to produce situations that allow us to miss things right in front of our eyes. This is why individuals in the metro station walked right by Joshua’s performance. They were focused on getting to work, and did not expect a world-class performer to be playing in the middle of the station on a Friday morning.

Manifestations in Security

As security investigators, we must deal with inattentional blindness all the time. Consider the output shown in Figure 1. This screenshot shows several TCP packets. At first glance, these might appear normal. However, an anomaly exists here. You might not see it because it exists in a place that you might not expect it to be, but it’s there.

IB-1

Figure 1: HTTP Headers

In a profession where we look at data all day it is quite easy to develop expectations of normalcy. As you perform enough investigations you start to form habits based on what you expect to see. In the case of investigating the TCP packets above, you might expect to find unexpected external IP addresses, odd ports, or weird sequences of packets indicating some type of scan. As you observe and experience these occurrences and form habits related to how you discover them, you are telling your mind to build cognitive shortcuts so that you can analyze data faster. This means that your attention is focused on examining these fields and sequences, and other areas of these packets lose part of your attention. While cognitive shortcuts like these are helpful they can also promote IB.

In the example above, if you look closely at other parts of the packets, you will notice that the third packet, a TCP SYN packet initiating the communication between 192.168.1.12 and 203.0.113.12 actually has a data length value of 5. This is peculiar because it isn’t customary to see data present in a TCP SYN packet whose purpose is simply to establish stateful communication via the three-way handshake process. In this case, the friendly host in question was infected with malware and was using these extra 5 bytes of data in the TCP SYN to check in to a remote host and provide its status. This isn’t a very common technique, but the data is right in front of our face. You might have noticed the extra data in the context of this article because the nature of the article made you expect something weird to be there, but in practice, many analysts fail to notice this data point.

Let’s look at one more example. In Figure 2 we see a screen populated with alerts from multiple sources fed into the Sguil console. In this case, we have a screen full of anomalies waiting to be investigated. There is surely evil to be found while digging into these alerts, but one alert in particular provides a unique anomaly that we can derive immediately. Do you see it?

IB-2

Figure 2: Alerts in Sguil

Our investigative habits tell us that the thing we really need to focus on when triaging alerts is the name of the signature that fired. After all, it tells us what is going on and can relay some sense of priority to our triage process. However, take a look at Alert 2.84. If you observe the internal (RFC1918) addresses reflected in all of the other alerts, they all relate to devices in the 192.168.1.0/24 range. Alert 2.84 was generated for a device in the 192.168.0.0/24 range. This is a small discrepancy, but if this is not on a list of approved network ranges then there is a potential for a non-approved device on the network. Of course, this could just be a case of someone plugging a cheap wireless access point into the network, but it could also be a hijacked virtual host running a new VM spun up by an attacker, or a Raspberry Pi someone plugged into a hidden wall jack to use as an entry point on to your network. Regardless of the signature name here, this alert is now something that warrants more immediate attention. This is another item that might not be spotted so easily, even by the experienced analyst.

Everyone is susceptible to IB, and it is something we battle ever day. How can we try to avoid missing things that are right in front of our eyes?

Diminishing the Effects

The unfortunate truth is that it isn’t possible to eliminate IB because it is a product of attention. As long as we have the ability to focus our attention in one area, then we will become blind to things outside of that area. With that said, there are things we can do to diminish some of these affects and improve our ability to investigate security incidents and ensure we don’t miss as much.

Expertise

The easiest way to diminish some of the affects of IB is through expertise in the subject matter. In our leading example we mentioned that there were a few people who stopped to listen to Joshua play his violin in the station. It is useful to know that at least two of those people were professional musicians themselves. Hearing the music as they walked through the station triggered the right mechanisms in their brain to allow them to notice what was occurring, compelling them to stop. This was because they are experts in the field of music and probably maintain a state of awareness related to the sound of expert violin playing. Amongst the hustle and bustle of the metro station, their brain allowed them not to miss the thing that people without that expertise had missed.

In security investigations it’s clear to see IB at work in less experienced analysts. Without a higher level of expertise these junior analysts have not learned how to focus their attention in the right areas so that they don’t miss important things. If you hand a junior analyst a packet capture and ask them where they would look to find evil, chances are their list of places to look would be much shorter than a senior analyst, or it would have a number of extraneous items that aren’t worth being included. They simply haven’t tuned their ability to focus attention in the right places.

More senior analysts have developed the skill to be able to selectively apply their attention, but they rarely have the ability to codify it or explain it to another person. The more experienced analysts get at identifying and teaching this information, the better chance of younger analysts getting necessary expertise faster.

Directed Focus

While analysts spend most of their time looking at data, that data is often examined through the lens of tools like SIEMs, packet sniffers, and command line data manipulation utilities. As a young industry, many of these tools are very minimal and don’t provide a lot of visual cues related to where attention should be focused. This is beneficial in some ways because it leaves the interpretation fully open to the analyst, but without having opinionated software this sort of thing promotes IB. As an example, consider the output of tcpdump below. Tcpdump is one of the tools I use the most, but it provides no visual queues for the analysts.

IB-3

Figure 3: Tcpdump provides little in the way of visual cues to direct the focus of attention

We can compare Tcpdump to a tool like Wireshark, which has all sorts of visual cues that give you an idea of things you need to look at first. This is done primarily via color coding, highlighting, and segmenting different types of data. Note that the packet capture shown in Figure 3 is the same one shown in Figure 4. Which is easier to visually process?

IB-4

Figure 4: Wireshark provides a variety of visual cues to direct attention.

It is for this reason that tools developed by expert analysts are desirable. This expertise can be incorporated into the tool, and the tool can be opinionated such that it directs users towards areas where attentional focus can be beneficial. Taking this one step farther, tools that really excel in this area allow analyst users to place their own visual cues. In Wireshark for example, analysts can add packet comments, custom packet coloring rules, and mark packets that are of interest. These things can direct attention to the right places and serve as an educational tool. Developing tools in this manner is no easy task, but as our collective experience in this industry evolves this has to become a focus.

Peer Review

One last mechanism for diminishing the affects of IB that warrants mention is the use of peer review. I’ve written about the need for peer review and tools that can facilitate it multiple times. IB is ultimately a limitation that is a product of an analyst training, experience, biases, and mindset. Because of this, every analyst is subject to his or her own unique blind spots. Sometimes we can correlate these across multiple analyst who have worked in the same place for a period of time or were trained by the same person, but in general everyone is their own special snowflake. Because of this, simply putting another set of eyes on the same set of data can result in findings that vary from person to person. This level of scrutiny isn’t always feasible for every investigation, but certainly for incident response and investigations beyond the triage process, putting another analyst in the loop is probably one of the most effective ways to diminish potential misses as a result if IB.

Conclusion

Inattentional blindness is one of many cognitive enemies of the analyst. As long as the human analyst is at the center of the investigative process (and I hope they always are), the biggest obstacle most will have to overcome is their own self imposed biases and limitations. While we can never truly overcome these limitations without stripping away everything that makes us human, an awareness of them has been scientifically proven to increase performance in similar fields. Combining this increased level of metacognitive awareness with an arsenal of techniques we can do to minimize the effect of cognitive limitations will go a long way towards making us all better investigators and helping us catch more bad guys.