Identification phase of incident handling involves detecting security incidents. Most detections will come from your security appliances like firewalls or intrusion detection systems (IDS). People can also be your eyes and ears, and with adequate training, they can be aware of security threats and whom to report.

Before we dive into how to identify incidents we need to know what to do if and when there is an Incident. Who is in charge of the incident, who do we alert, and most importantly when to alert and when to keep watch. Everyone should know of the classic story of The Boy Who Cried Wolf and if you have not its a story of a boy who was tasked to watch a herd of sheep and to alert the town if there was ever to be a wolf. The boy would get bored and cry wolf, and everyone would react and come to assist but when they arrived there was no wolf. When the wolf did come, and the boy cried out for help, no one came to the rescue. So I'm not saying to cry wolf but be willing to alert early and don't be scared to declare an incident. Even if there is not an alert, you still help the organization by giving the team the opportunity to learn in determining when there is an actual threat so treat this as a training opportunity. Take note that for an incident to form there needs to be a constant stream of information or events so be sure to provide these indications and warnings to validate your claims. Upon alerting for a possible security incident, it's ideal to assign one person as the primary incident handler and another person to assist him/ her to aid in communication and gathering of evidence. Make sure the handlers know which systems need to be validated and what needs to be documented so, in other words, do not leave your handler asking questions upon arriving and starting the investigation. The most crucial step is enforcing a need to know policy and I couldn't possibly say this enough because the majority of the time what you think is going to be the case turns out to not be the case. This change in assumption is widespread, and rumors spread faster than wildfires. The last thing you want for your organization is a news article publishing false claims about the events that took place. On another note, not enforcing this type of policy could hurt your investigation by alerting a possible inside threat and in return ruins your research and possible loss of evidence. When communicating during a potential security incident always use secure forms of communication. Rely on phones and encrypted email, but it's best practice to deliver in person and keep notes on hard copies.

Where

Although identification can occur anywhere in your network here are the most common network zones for gathering events.

Internet perimeter

• Firewalls
• IPS/IDS
• Honeypots
• DMZ

Host perimeter

• Local Firewalls
• Local IPS
• Port sentry tools

Host Detection

• Endpoint Security
• File integrity tools
• Help Desk ticket from user noticing strange behavior of the system

Application detection

• Application generated Logs

I will go over clear examples of each later in the series, for now, know these are the systems that will generate information for us to analyze. In the ideal world, you want to identify and contain all threats at the Internet perimeter stopping threats from getting to your internal network. Unfortunately, attacks are more sophisticated and therefore detected after the fact. Please note that its impossible for these systems to recognize every attack or possible threat so as a system administrator or analyst you should know what natural looks like and look out for anomalies. Network spikes increased traffic, an abnormal number of failed login attempts to a particular system, or a user logged in on a system that shouldn't be are all examples.

What

So a system administrator or security analyst what are you exactly looking for when trying to identify a potential incident? In short, you are looking for the following unusual things.

• Processes and services
• Files
• Network usage
• Scheduled task
• Accounts
• Log entries

Start with network connections is ideal when determining where to start. Then work through processes and services associated with those connections. In Windows a tremendous free tool used for mapping ports with the associated program is TCPView.

See my post on windows for extra tools that will aid you past windows built-in capabilities.

To get a detailed understanding of identifying unusual things like Scheduled task see my post on how-to-find-anomalies.

HOW

So you've identified a possible threat or compromise on your network, and now you might ask how do you assess the situation. That's a great question and start by asking yourself the following questions. Do you have enough evidence to support your claim? Is it possible that the potential threat is a reasonable mistake? When I mean mistake ask your self-things like; Is there a misconfiguration or is it possible the user might not be aware they are trying to login in the wrong domain? What are other possibilities? It's a great idea to start documenting your evidence and collaborate with your team to see if they have encountered something similar or if there is a routine pen test.

Assess the situation

When looking at the situation, you need to determine how considerable damage could affect your organization. Executives will be asking questions like if there will be possible data loss or how the system will change and how this will affect business.

Common questions to have answers to

• How widely deployed is the affected platform or application
• What is the effect of vulnerability exploitation or if a vulnerability is present
• What is the value of the systems impacted so far
• What is the worth of the data in question
• How is the vulnerability exploited
• Is this a publicly available exploit

Risk assessment

When answering the following questions, it's a good idea to assess risk concerning the incident. A widely deployed system across the network can be terrifying in contrast to a custom internal application for a team. The larger the deployment, the harder it is to contain and therefore it poses a higher risk to your network and data. Regarding the effects, you need to know if this is a denial of service, surveillance, information compromise, or root/admin user account compromised. The type of threat is essential to know not only for risk assessment but will be needed later in the containment process of incident handling. Determining the value of a system will help you better assess how much of a risk the threat is. The thing to think about here is what types of data are on the system. Systems with sensitive data pose a higher risk than those with publicly available information. Where the threat is coming from is good to know as this will help with successfully containing the danger promptly. If the executed exploit didn't originate from the internet, then containment can be isolated on the LAN vs. installing firewall rule from the internet edge of your network. If the threat is an exploit check to see if this exploit is available to the public. Most of the time public available exploits contain documentation on how the exploit works, which systems are affected, and how to patch these systems. If there is an exploit and public obtained information isn't available, you may be dealing with a zero-day exploit, and then the stakes are severely raised. Lenny Zeltser has prepared an Initial Security Questionaire for responders that may be very helpful in this phase in the process.

Establish and maintain chain of custody

Remember to document everything and never delete any files until the finalization of the case. It's recommended to even then keep these files as evidence for future legal matters. A policy for a retention time frame should be approved by legal. Evidence should always be in the hands of one person, and no one else should tamper with the evidence. HANDS OFF! Get a signature from law enforcement if and when you turn over evidence.

Takeaways

Know your network and know where to look for anomalies
Know your system administrators and establish a baseline for your systems
Use tools to your advantage to identify threats
Ask questions and build a case by documenting evidence
Perform risk assessment and gather as much information as possible
Establish a chain of custody

Remember the more you document and information you gather will help see the incident through to the end.

Containment

If this has been helpful to you, please support this blog by buying a coffee