Author Archives: Chris Sanders

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.

 

 

 

Practical Packet Analysis 3rd Edition Released!

Ten years after releasing the first edition of Practical Packet Analysis, the third edition is finished and has been released! It’s hard to believe it’s been so long. So far, existing editions have sold tens of thousands of copies, been translated into multiple languages, and been used as a textbook in multiple college courses. I’m very humbled by the success the book has seen over the past decade.

Purchase Here from Amazon

Purchase Here from No Starch Press

If you’ve never read Practical Packet Analysis…

the key word I want to focus on is Practical. There are a lot of books about networking and protocols out there that get into the specific details at magnified level, but this isn’t that book. This book is written for people who need to do things like solve network issues, troubleshoot latency, or investigate security threats. Capturing packets is easy, but understanding them isn’t, and PPA is designed to give you the practical knowledge you need to get started down the right path. Practical Packet Analysis was the first book of its kind a decade ago, and the approach I’ve taken is unlike any other book you’ll find on the topic.

If you’ve read one of the previous editions…

I think you’ll like the new one too. Much of the introductory material is the same, but I’ve added quite a bit of new content:

  • Updated content for Wireshark 2.
  • A new chapter on packet analysis from the command line with tshark and tcpdump.
  • A bonus chapter on how to read packets in hex using packet diagrams.
  • New protocol coverage of IPv6 and SMTP.
  • All new scenarios related to network troubleshooting, internet of things devices, and security scenarios.

Charitable Contributions from Book Sales

A significant portion of the royalties from Practical Packet Analysis will be going to support a number of charities. This includes the Rural Technology Fund, the Against Malaria Foundation, and several others. Through your purchase of my books we’ve been able to put computer science resources into the hands of over 10,000 students just last year alone, purchase life saving mosquito nets for thousands of African families, and so much more. I’m thrilled to be able to use my work to serve others, and I hope you’ll share in that joy with me.

Acknowledgements

First of all, I want to sincerely thank everyone who has ever purchased any of the prior editions. I know you work hard for your money, so I’m glad my work was deemed worthy of your contribution and your time. As I always do, I want to share the acknowledgements and dedications you’ll find in the first few pages.

I’d like to express sincere gratitude for the people who’ve supported me and the development of this book.

Ellen, thank you for your unconditional love and for putting up with me pecking away at the keyboard in bed for countless nights while you were trying to sleep.

Mom, even in death the example of kindness you set continues to motivate me. Dad, I learned what hard work was from you and none of this happens without that.

Jason Smith, you’re like a brother to me, and I can’t thank you enough for being a constant sounding board.

Regarding my coworkers past and present, I’m very fortunate to have surrounded myself with people who’ve made me a smarter, better person. There’s no way I can name everyone, but I want to sincerely thank Dustin, Alek, Martin, Patrick, Chris, Mike, and Grady for supporting me every day and embracing what it means to be servant leaders.

Thanks to Tyler Reguly who served as the primary technical editor. I make stupid mistakes sometimes, and you make me look less stupid. Also, thanks to David Vaughan for providing an extra set of eyes, Jeff Carrell for helping edit the IPv6 content, Brad Duncan for providing a capture file used in the security chapter, and the team at QA Café for providing a Cloudshark license that I used to organize the packet captures for the book.

Of course, I also have to extend thanks to Gerald Combs and the Wireshark development team. It’s the dedication of Gerald and hundreds of other developers that makes Wireshark such a great analysis platform. If it weren’t for their efforts, information technology and network security would be significantly worse off.

Finally, thanks to Bill, Serena, Anna, Jan, Amanda, Alison, and the rest of the No Starch Press staff for their diligence in editing and producing all three editions of Practical Packet Analysis.

Dedication

This time around, rather that dedicating the book to an individual, I chose to include the first verse of one of my favorite songs, “Amazing Grace”. These words have profound meaning, and they just felt right positioned as the first words you’ll read in these pages.

“Amazing grace, how sweet the sound That saved a wretch like me.
I once was lost but now I’m found. Was blind but now I see.”

Reviews

Finally, if you do end up with a copy of Practical Packet Analysis, I’m always grateful for a review on the books Amazon page. A positive review is the most meaningful way to help an author whose work you enjoyed. If you’d rather share your review with me directly, don’t hesitate to e-mail me. I’m always happy to hear your feedback.

Increase Security Reporting with Contact Cards

After a really nice weekend, Zeke walked into his office and logged into his workstation. He made a habit of getting to the office around 7 AM on Mondays so that he could go through the pile of unanswered e-mails from the previous week and clear out all junk that accumulated over the weekend. As he was going through e-mails, he spotted one with the subject line “401k performance highlights” that was sent towards the end of the day on Friday. He had seen it then, but was in a rush to get out the door. He opened the e-mail and read that his 401k had performed better than expected over the previous quarter. A link was provided to review the details so he clicked it. That was when he realized he had made a mistake.

The link didn’t go to his 401k provider as expected, but instead went to a suspicious looking fake site that was made to look like it. Zeke had gone through information security awareness training, so he knew how to spot forgeries like this. It was very obvious that the site was hosted on a domain made to look like a legitimate bank, but was in fact not associated with it at all. He immediately closed his browser window and waited. His system seemed to be fine. No weird pop ups, no prompts to download any software, no weird slowness. He had dodged a bullet. He remembered that he was supposed to report occurrences like this, but wasn’t entirely sure where. Was it the IT helpdesk? No, it was a special e-mail address….or was it a phone number? He quickly looked up the contact number for someone he knew who worked in information security. Hmm, no answer. It’s still pretty early so that person might not be in. He shrugged it off and went about the business of responding to unanswered mail. By the time his day got going, he forgot all about the incident and it never got reported.


Stories like the one here are common in large organizations. Many companies do their part and invest heavily in security awareness programs that teach employees how to spot phishing attempts and security anomalies so that they can be reported. However, many organizations struggle with the final step in this process — effectively enabling their users to report anomalous activity.

So, why do users fail to report security issues when they recognize them? You might expect me to provide a long-winded underlying psychology perspective. However, the answer is much simple than that. People rarely have the opportunity to report security incidents, so they forget how to do it. Just like Zeke, they forget the e-mail address or the phone number. Further, they are often hesitant about whether anyone actually cares about what they’ve observed, and they’re worried that incompetence will be exposed. Of course, there isn’t incompetence here, but all that matters is that the individual perceives the possibility of it. Nobody likes feeling dumb, so someone certainly aren’t going to go out of their way to report an incident if it means potentially going through multiple layers of people. That increases the chance that perceived incompetence gets exposed. In summation, people are less likely to report security incidents unless it’s incredibly easy, and that is a defense mechanism that is difficult to overcome.

How do you eliminate that defense mechanism? Well, that’s a difficult question with multiple facets and is far beyond the scope of what I have to offer in this humble blog post. I think the better and more practical approach is to make security incident reporting as simple as conceivably possible. For that, I offer a non-technical solution.

The best strategy for reporting security incidents that I’ve seen is simple. Provide every employee with a security reporting contact card (SRCC), like the one seen in the image below.

As you can see, this card is incredibly simple. Ideally, this is printed to the same size as a business card on heavy stock. This provides a form factor sizable enough to display all the necessary information, but small enough to be easily tucked into a wallet or purse. The idea is simple: every employee receives one of these cards and is requested to keep it close at all times. While most employees can’t be expected to remember an obscure e-mail address or phone number, they will remember that they were given this card and can reference it without hassle.

So, what is necessary to include on the SRCC? This can vary, but I recommend making sure that the card can answer these questions:

  • Who can I e-mail/call for any network security related issue?
  • Who can I e-mail/call for any physical security related issue?
  • Where can I forward phishing or scam e-mails?

The purpose of this card is not to educate people on what’s reportable. That should be a goal of your information security awareness training and certainly won’t fit on a card. However, the three questions mentioned above cover a lot of the things that will generally be reportable. By providing e-mail addresses and phone numbers, you provide an implied escalation path if something is deemed to important or time sensitive for e-mail.

A few other tips:

  • Use a bright, easily noticeable color on your card. This will help people spot it and remember where it is in their wallet/purse.
  • Make the design somewhat different from your normal company business card template.
  • Setup a special e-mail address to receive forwarded phishes separate from your normal intake queue. This will help with prioritization and tasking.
  • Build this into your security awareness training. Occasionally challenge people to produce these cards so everyone gets used to keeping them handy. Make sure you are clearly identifying what is reportable and what isn’t based on your organization’s threat model and ability to evaluate reported incidents.

If you want to get started right away, here’s a Microsoft Word template you can download and use now. Just replace the logo and information with your own, print it out, and hand them out to your employees.


So what ever happened with Zeke? Well, it turns out that once he clicked on the link in the phishing e-mail, his browser downloaded a flash exploit which led to a malware infection. An attacker was able to leverage access to this system to retrieve sensitive information about Zeke’s company. It took the attackers a few weeks to complete their attack. But, since the detection tools in the organization didn’t pick it up, and Zeke never reported it, the attack wasn’t discovered until much later. The organization did a lot of things right, but a failure to make incident reporting easy subverted much of their effort. Security contact cards a simple, affordable, effective way to make sure you don’t fall victim to a similar scenario. The minimal cost of printing and distributing these cards is nothing in comparison to what you might pay if something goes unreported.

 

Training Course Scholarships

I’m glad to announce that I’m offering full scholarships for my online training courses to individuals employed by non-profit human services organizations. These are given out based on availability, and each application is evaluated individually by me. This covers the courses listed on my training page, and is my way of serving those who are helping others.

To apply, visit this link and fill out the application:

https://www.surveymonkey.com/r/HQCW5ZN

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.