Network Activity Report (NAR)
Outlines what a NAR is and how to fill one out.
Introduction
A Network Activity Report (NAR) is a report given to a customer which reports anomalous activity on a network. There are many considerations that must be made when filling one out just, namely, the level of technicality and the level of detail. If any of these two considerations are not realized, the network owner may be unable to act on the report thus delaying any fix actions or escalation. Here we will go over the different parts of a NAR and what details should be provided. Below is a link to a template NAR.
SHA256 Checksum of the below document:
97CCAF6F5A0EFAAF352C76FB9C60887D7A76CD8734EE293B3CC480472ED5B0B9
Executive Summary
This is essentially a glorified title. One to two sentences describing what is affected, by what, and the effects.
Terrain Affected
In this section, go into depth on the devices affected by the network activity. The primary details required here are IPs AND hostnames. Remember that this report may be seen by different people at different levels so while the main network admin may know what IP is what host, the senior management may not.
Description
This is the portion that a network owner should be able to read and get a broad understanding of the situation, what's being affected, and what can be done to fix it. Think of this section as the "Elevator Pitch" of the NAR. Provide detail but leave room for the following sections to go into more technical detail. An important part to remember in this section specifically is the use of neutral language. Remember, this report may be seen by different people in different roles. So use neutral language that won't cause people to go into a frenzy unless completely warranted. As an anecdote, just as you wouldn't yell "fire" in a crowded theatre, shy away from language such as "known vulnerable" or "critically dangerous". Again, unless completely necessary. There are of course instances in which you would yell "fire" in a crowded theater. Namely, if there was a fire.
The following would be an example of a situation that may cause undue stress on a network owner simply by the use of language.
While cyber analysts may know port 31337 as "hacker speak" for elite, and commonly used by malware. It simply existing does not inherently pose a danger to a customer.
Don't
Description: During baseline, analysts concluded that port 31337, a known vulnerable hacker port, is not blocked on the firewall.
This may cause network owners to think they have ALREADY been attacked on port 31337 simply by using language. It would also open the door for many more questions such as "What makes it known-vulnerable?"
Do
Description: During baseline, analysts concluded that a port commonly used by adversaries, port 31337, is not blocked on the firewall. While not inherently malicious, it poses a risk that can be avoided by blocking it.
This language allows the network owner to understand the priority of the problem and puts it in the context of the wider situation without causing them to overreact.
Adversary Indicators
This is where you can become more technical on the issue. Here, provide any details you can including commands run, files transferred, or vulnerabilities exploited. If you can correlate these indicators with CVEs or MITRE ATT&CK framework TTPs, that is even better.
The key here is to provide context. More often than not, we've seen NARs that dump 20+ lines of commands without any context. Keep in mind that to the untrained eye (Which 9/10 times the person reading the NAR is not a Cyber Analyst) most commands seem benign. As said above, if you can correlate with CVEs or MITRE TTPs this will provide context to the person reading it on the severity of not just the commands, but the vulnerability itself that is potentially being affected.
Linked below are the MITRE CVE database and MITRE ATT&CK framework website
Risk Mitigation Methods
This portion is arguably the most important part. This is where the knowledge of the network activity, knowledge of the terrain they operate on, and the Analysts' ability to research come to a head. The mitigation method needs to meet a few criteria:
Feasible - The risk mitigation method needs to be something the customer can feasibly do. If the solution is to blow everything up, that is most likely not a feasible solution for the customer. An example of a common unfeasible risk mitigation method would be to pull ALL of a specific type of machine off a network for further host interrogation. While this may allow an Incident response team to solve the problem, in most environments, this may not be possible such as if there are multiple sites with a certain type of machine, or if there is just a lot of them.
Reasonable - The risk mitigation method needs to be something you can reasonably ask a customer to do in their current situation. This means even if it may be a feasible response, is it something that a customer would want to do given THEIR current mission? A common example of an unreasonable risk mitigation method is to pull every domain controller off the network for an undisclosed period for further host interrogation. This, while feasible, is just never going to happen if a customer needs to use any domain-joined assets.
Effective - The risk mitigation method needs to solve the problem. This is where research comes into play. The team writing the NAR needs to do their due diligence to determine if the risk mitigation method would solve the problem. If your NAR is for a vulnerability that existed for a long time, reverting to an old backup or snapshot and not patching, wouldn't solve the problem. A common one we see here is people saying "Reimage / blow away the machine" before fully realizing what the thing that caused the network activity in the first place
Potential Future Effects
This is where you describe what is the potential threat if the risk mitigation methods are not taken. Be specific here, simply saying "The team thinks the network activity will spread to every machine" is not a specific enough future effect to make sense to most people. What are the actual effects of the activity? A good one to have here, given that most customers primarily care about the availability of their network is "How will it affect availability?"This is where you describe what is the potential threat if the risk mitigation methods are not taken. Be specific here, simply saying "The team thinks the network activity will spread to every machine" is not a specific enough future effect to make sense to most people. What are the actual effects of the activity? A good one to have here, given that most customers primarily care about the availability of their network is "How will it affect availability?"
Last updated