Almost every day, there seems to be a new headline about a high-profile data compromise. But the incidents we hear about only make up the tip of the iceberg — many incidents can go undetected for a long time. Do you know how to detect a breach on your network?

It’s concerning that the average time to detect an incident — known as dwell time — is still fairly long. According to FireEye’s “M-Trends 2018” report, the global median dwell time was 101 days in 2017, ranging from 75.5 days in the Americas to 175 days in Europe, the Middle East and Africa (EMEA) and a whopping 498 days in Asia-Pacific.

It’s extremely difficult to tell when a system has been infiltrated, let alone fluently and properly organize a response to such intrusions, so it’s important to prepare proactively.

What’s the Difference Between a Precursor and an Incident?

There are essentially two different types of signs of an incident: precursors and indicators.

A precursor indicates that an incident may occur in the future. This is based on publicly available information, such as vendor advisories and security blogs, and information received via threat intelligence sources or detection of reconnaissance actions from attackers. Precursors allow security professionals to anticipate a possible forthcoming attack and tighten protection measures accordingly.

An indicator signals that an incident may have occurred or is underway. Indicators can come via alerts from security solutions, suspicious behavior observed in logs, or reports from people within or outside the organization. Whereas the occurrence of precursors is relatively rare, the volume of indicators can be very high, which contributes to inefficiencies in the incident response process.

How to Look for Common Indicators

There are a few typical event types you should look for to detect an intrusion. A complete list is fairly impossible to build due to the broad and growing variety of possible attack methods, but the following common signs will require further attention:

• Unusually high system, disk or network activity, especially while most applications are idle.
• Activity on unusual network ports or applications listening to unusual network ports.
• Presence of unexpected software or system processes.
• Configuration changes that can’t be traced back to an approval, such as firewall changes, reconfiguration of services, installation of startup programs or added scheduled tasks.
• Anomalous user activity, such as logging in at abnormal times, from unusual locations or from multiple locations in a short time frame. Most cloud services have a “last activity” overview to track abnormal behavior.
• Unexpected user account lockouts, password changes or sudden group membership changes.
• Repeated system or application crashes.
• Alerts from your malware protection solutions or notifications that these suites have been disabled.
• Abnormal behavior during browsing, such as repeated pop-ups, unexpected redirects or changes in the browser configuration.
• Reports from contacts that they received unusual messages purporting to come from you via email or social networks.
• A message from an attacker, for example via ransomware.

How to Detect a Breach on Your Network: 5 Key Steps

If any of the indicators above raise significant suspicion of a breach in your network, there are a few general guiding principles to follow in the start of your response. Below are five steps organizations should take to improve their ability to detect and respond to a data breach.

1. Don’t Make Changes

The first rule is not to alter anything on the suspected systems, as this could potentially tamper evidence and, in some situations, make things even worse. In practice, this means you should not immediately take actions that have a high impact on the system.

You may be faced with a trade-off, taking into account the gravity of the incident, the intent, and impact of the attack and your business’s objectives.

If the observed incident concerns, for example, a steady outgoing stream of your intellectual property, then your first goal would be to stop this stream and risk tampering the evidence. The courses of action matrix can provide valuable input when choosing which actions are best to apply.

2. Collect Evidence

To get all the details from an intrusion, both for incident analysis and, eventually, post-incident actions, you need to safeguard the evidence and collect forensic data.

This data can include log files, memory and disk information, network flows, malware samples, or a list of running processes, logged-in users or active network connections. Obtaining this information can sometimes contradict the first rule: Don’t change anything on the system. This, again, requires you to weigh the benefits against possible disadvantages.

Some tools allow you to do remote forensics, but not every organization will have these capabilities. You will most likely also have to rely on the capabilities of your IT operations team to assist with collecting the evidence. If you do not have central logging, at least make sure the logs are copied to a read-only location, away from the suspected machine.

3. Log Everything

Throughout each phase, it’s important that you take a step back and take note of every action. The verification, correlation and pivoting actions are often done iteratively; you can use your notes to ensure that you have not missed anything important.

These notebooks can also serve as a source to supplement timelines and find areas that need improvement. Note-taking is most valuable when done during the incident response, not afterward.

4. Validate With Peers

When you have a basic understanding of what’s going on, it can be useful to verify the findings with your peers. This can be via threat intelligence sources, industry information sharing and analysis centers (ISACs), or the national computer security incident response teams (CSIRTs). This peer verification step allows you to learn what others have already done to contain the incident and recover from it.

5. Report Internally

Besides the regular reporting of observed incidents to stakeholders, you also should inform them of the critical ongoing incidents that have (or can have) a business impact.

The reporting can include a high-level analysis of the attack, including:

• Whether it was targeted;
• Whether it’s has been observed before;
• Whether industry peers are observing a similar attack;
• What damage it has caused so far;
• What damage it might cause in the future; and
• The intent of the attack.

Your stakeholders will also be very interested to hear which mitigation actions were already executed, whether they were effective and what future actions you foresee. Don’t focus on the technical details; instead, communicate the impact this has for the business and employees.

Make Your Team Known

Remember that reports coming from people within the organization can also count as indicators. Internal reports can be very valuable sources of information for detecting abnormal behavior or situations, besides being essential post-incident communications.

A key success factor for this indicator is that you make the reporting process as easy as possible for your users. Make sure that the contact information and procedure is universally known and easily accessible. Include it in your awareness campaigns, have it published on the internal portal website, distribute webcam covers that hold the security team contact details or include a “report a security incident” button in the corporate email application.

You can also seek valuable input from the IT help desk. Prepare a set of procedures so the help desk staff knows in advance which questions to ask reporters and what information to collect before transferring the incident to you.

Above all, be transparent. If someone reports a security incident, update them on the progress and outcome of the investigation.

This sense of involvement and feedback can trigger your colleagues to approach you sooner whenever your they suspect something unusual is happening on their systems. It will also help you develop a strong security culture within your organization — which is possibly the most valuable defense available to prevent a breach from occurring in the first place.