Detect - Cyber Security Basics: Protect your organization by applying the fundamentals (2016)

Cyber Security Basics: Protect your organization by applying the fundamentals (2016)

Section Two: Detect

“The world is full of obvious things which nobody by any chance ever observes.”

Sherlock Holmes


One of the greatest fears of any security professional is that there is malicious activity going on undetected somewhere on the network. Stealth is one of the main modus operandi of attackers and how the majority of malware behaves. An Advanced Persistent Threat (APT) is malware that persists on a network to observe and report, for an extended period of time and without notice. An interesting definition of APT comes from the security vendor Damballa: “Advanced Persistent Threats (APTs) are a cybercrime category directed at business and political targets. APTs require a high degree of ‘stealithiness’ over a prolonged duration of operation in order to be successful. The attack objectives therefore typically extend beyond immediate financial gain, and compromised systems continue to be of service even after key systems have been breached and initial goals reached.”[14]

This section discusses the detective form of security, where sensors generate alerts for security personnel to respond to. The response taken should have the following attributes:

· Pre-defined

· Documented

· Rehearsed

· Communicated to the team

· Periodically reviewed

· Kept current

Security alerts that do not have a defined response have debatable value, and may just end up providing noise and distracting busy work.

To be able to rely on security controls to provide constant real-time monitoring, assurance that those sensors are running is needed. The monitors need monitors, in other words. Just because an alert (such as from a scan or perceived attack) is not sounded, a security event could still be taking place. To paraphrase the famous saying: “If a tree falls in a forest but there is no one there to hear it, the tree still fell, there just wasn’t a working sensor to observe it.”

An uptime monitor, such as a heartbeat, can play an important part of the implementation of any security control. This heartbeat monitors the health and continuous operation of a sensor. A dashboard can be set up to display the status of heartbeats, and an overview of the health of all of the sensors deployed to the network and endpoints can be provided.

The focus of this section is the tactics, techniques and procedures (TTP) that can be used to assist with the detection of security events. Defensive tactics can include the implementation of individual controls, or of a larger security solution that provides various sensors. The techniques and procedures used by a security team should be clearly defined, documented and rehearsed before sensors are enabled and generating alerts. The worst time to determine how to respond to a security alert is when the response is needed.

As with section one, each of the following security controls have a security maturity level indicator, which is based on the item’s implementation and maintenance complexity and cost, as well as how fundamental the item is to the foundation of a typical organization’s information security program.

2.1 Continuous Monitoring

Continuous monitoring provides a constant awareness of what is taking place on the network and all endpoints connected to it. This awareness is provided by sensors that are installed on endpoints and at various places throughout the network. These sensors generate security alerts and monitoring information that can be collected by a centralized log repository like a SIEM solution (referred to from this point forward as a SIEM.) Based on rules, the SIEM will generate alerts based on certain events that it receives. A SIEM provides aggregation, alert generation, and a “single pane of glass” view of alerts received from multiple, disparate devices, all in real-time.

Figure 2.1: An event repository like a SIEM can receive alerts and log information from multiple sensors in real time.

When receiving and processing security alerts, there are two rules that should considered:

· If an alert is not generated or received, it does not necessarily indicate the absence of an event

· If an alert is generated, it should not be assumed that it will automatically be observed or responded to

Once a sensor is installed, it should be considered to be the equivalent of a living entity in that it requires its own monitoring and maintenance, to help ensure that it continues to perform as expected, and that it can be relied on when it is most needed. Along those lines, here are a couple of scenarios that you want to avoid:

· “We installed a sensor correctly, but were not aware that it stopped running.”

· “Our sensor was running correctly at the time, but no one saw the alerts.”

As sensors are computing devices unto themselves, they have certain attributes that can be monitored, such as those listed in the following table:



Storage space

Is the hard disk running out of space?

CPU utilization

Is there some sort of infinite loop or resource exhaustion event that is causing the CPU to max out?

Memory consumption

Is there a memory leak that is causing all available memory to be used?

Network ping

Is the system reachable via the network?

Table 2.1: There are several system properties that can be monitored to help ensure system uptime.

For system health monitoring, one way to generate a heartbeat is to send the sensor a test event. This event should flow through to the SIEM. The heartbeat generator could be a perpetually running script whose only job is to periodically create a test (or heartbeat) event (e.g. every 60 seconds.) The SIEM can be set up with rules to handle any “heartbeat” events it receives. If the SIEM does not catch the event, then it’s “Houston, we have a problem.”

Figure 2.2: A heartbeat can be used to ensure an IPS is alive and well, and can be relied on to send alerts when needed.

Using heartbeat scripts to monitor the health of sensors is not a perfect solution, as the script itself can fail due to various reasons, such as those listed in Table 2.1. Therefore, it is advisable that the heartbeat scripts themselves are monitored in some way. This could be in the form of a separate monitoring process or script that helps ensure that the heartbeats themselves are running reliably.

2.1.1 Alerts

Level 1 - Most SIEM solutions provide the ability to perform a specific action based on receiving an alert from a security device. Examples of these actions can include sending an email or adding an item to a dashboard. The response actions taken by a SIEM need to get the attention of security analysts so that they are responded to quickly. If the SIEM will be sending notifications, the organization’s existing messaging solution should be leveraged if possible. This could be the organization’s email infrastructure or a simple messaging service (SMS). The information contained in these notifications should be reviewed from a confidentiality standpoint to ensure sensitive information is not inappropriately disclosed. This review should include asking questions such as:

· What if the contents of the message ended up in the wrong person's inbox?

· What could be done with that information?

· Who else could benefit from receiving this notification?

Using a system that can automatically create notifications for individuals and teams runs the risk of sending too many notifications and overwhelming its recipients. A SIEM can create a security event based on the alerts it receives. The event needs to actionable however; otherwise it may only serve as distracting noise. If an event gets the attention of an analyst, it had better be worth the time of that valuable security resource. Therefore, there needs to be a balance between the volume of events, and the finite resources available to respond to them. This is where prioritization comes in. A severity or priority rating (e.g. 1 to 5, where 5 is most severe) can be assigned to each event to help the analyst and team decide which events deserve immediate attention, and which ones can wait.

Remember: “If everything is a priority, then nothing is a priority.”

If there are too many events to be handled appropriately, security personnel may start to become desensitized and start tuning them out. Event apathy appears to have contributed to the expensive and widely-publicized incident suffered by Target Corporation in 2013, where alerts generated by a malware prevention appliance were not seen (and therefore not responded to) by security personnel until it was too late.[15] Also, keep in mind that distraction is sometimes part of the adversary’s TTP. This is also known as misdirection. The attacker may cause an incident, such as adistributed denial of service (DDoS) attack, in order to draw the attention of a security team away from another attack (such as information theft.) Ideally there will be security resources available to respond to both the primary and secondary events.

Once an event notification is received, what happens next should be determined in advance. The response taken should be captured in a document (known as a use case) that is accessible by all security staff who may be called on to handle similar events in the future. The use case should be communicated and made available to the security team, and reviewed periodically to ensure it continues to be relevant and current. Just as the security landscape constantly fluctuates and evolves, so do the use cases employed by a security team.

Security sensors and solutions should be set up so that they generate alerts. These alerts provide awareness and actionable events for the security team to respond to. Therefore, due to the essential nature of security alerts, they are considered a level 1 security objective.

2.1.2 Security Information and Event Management (SIEM)

Level 2 - A Security Information and Event Management solution (referred to as a SIEM from this point forward) provides a couple of main benefits. First, it provides a centralized location to collect log files from disparate sources. Appliances and sensors like IPS, firewalls, Internet proxies, databases and servers can send events to a SIEM. A SIEM is flexible enough so that it can receive events from almost anything that can generate and send information to a specified IP address and port. Connectors are established to provide the conduit between a logging source and the SIEM.

A SIEM is also a powerful tool for mining and correlating thousands to trillions of data. This can be done automatically in real-time, or as a background process, and alerts and dashboards can be generated based on rules provided by the vendor or developed by members of the security team.

Figure 2.3: Events from various systems can be collected by a SIEM.

Using a SIEM makes the activity of finding interesting and potentially malicious activity more efficient because all of the log files are in one location where events from several different systems can be correlated and aggregated. A key element to being able to tie events together is to have the clocks of all reporting systems synchronized. Network Time Protocol (NTP) can be used, which uses a central time server that all networked systems can leverage. As a result, all systems use the same clock, and all log events will have a synchronized timestamp that allows for the accurate correlation of events across multiple and disparate systems.

By having the ability to connect events from different systems, a security analyst gains a complete picture. For example: a sequence of packets was received by a firewall, passed to an IPS, then finally received by a web server, resulting in a XSS attack. Synchronized event timestamps provides an accurate end-to-end history of what happened, which can make analysis easier and response quicker.

A SIEM solution enables an organization to have a consolidated view of security events from disparate systems. Using heartbeats with the SIEM can help ensure that security controls and sensors are up and running, and utilizing NTP ensures that the log events are synchronized.

While a SIEM can provide immense value to an organization, it does require a more seasoned professional to implement it so that it can be used effectively. For this reason, it is considered a level 2 security objective.

2.1.3 Reporting

Level 1 - A challenge of most information security programs is communicating the value that the program provides to the organization. That is because when it comes to security, no news is good news. However, no news can be seen by others as a poor use of money and resources. It is therefore critical to be able to communicate the value that the information security team provides to the organization, and to do so on a regular basis, even if significant security events or incidents have not taken place. An effective report is:

· Repeatable

· Based on facts (quantitative)

· Provides a clear message

· Is tailored to the intended audience

Reports should be created which show the alerts, events and incidents the team has addressed, and attacks that were mitigated. It matters how “attack” is defined. Scans happen all the time; is this just Internet noise or an actual precursor to something more nefarious? How security appliances define attacks, and the severity they assign various alerts, varies greatly. The message you are trying to convey with the report will help determine whether or not it is helpful to categorize scans as attacks.

Reports can serve to support an organization’s information security program. Taking the time to make sure the reports are objective, clearly convey a message to the intended audience, and are reproducible in an automated way, can help ensure that an information security program will continue to get the support and resources required to be effective. Communication is essential for communicating the value an IT security team provides to an organization. Therefore, it is considered a level 1 security objective.

2.2 Network Activity

There are several different kinds of network activity that should be monitored. Being aware of certain events, or combinations of events, could lead to the detection of malware installations, attacks, scans, and other unwanted activities. The following discusses some of the network activity that you may want to monitor as part of protecting your own organization.

2.2.1 DNS Query Monitoring

Level 3 - Domain Name Resolution (DNS) is a mechanism that saves people from having to remember an IP address (a series of numbers) in order to reach web sites. While DNS is helpful today with the ubiquity of IPv4 addresses (in n.n.n.n notation), this tool will prove essential once the Internet has transitioned to IPv6, which uses numerical addresses like fe80::b089:75ff:fefd:47a4. Try memorizing that.

Today, to visit, the web browser resolves this domain name into an IPv4 address (e.g. This address serves as the location of the server hosting Google’s web site. There are thousands of DNS servers across the Internet that perform the resolution of domains into IP address for Internet users and web sites all over the globe. The problem is that DNS was created in the early days of the Internet, when people were more concerned about connectivity than security.

Figure 2.4: A DNS query is made to resolve an easy to remember domain name to a harder to remember IP address.

DNS hijacking is, at a high level, an attack where the DNS record for a web site is changed so that a victim is redirected to a compromised site (which may host a malicious payload.) So if the DNS record for was hijacked, for example, instead of going to Google, people could instead be redirected to a site pretending to be Google but in actuality is a site laden with malware or asking the user for sensitive information.

Monitoring the DNS queries that take place on the network can also be an effective way to detect infected devices. Several different strains of malware will connect to Internet servers (known as Command and Control (C&C) servers) to receive instructions, download additional modules or payloads, or upload the sensitive data it pilfers. The domain names of many of these sites is known through the sharing of cyber intelligence. Watching for any DNS queries to these malicious domains can be a good indicator of infected devices on the network.

Implementing DNS monitoring is non-trivial, and should considered after more fundamental security solutions have already been implemented and are proving their value. For this reason, DNS monitoring is considered a level 3 security objective.

2.2.2 Data Loss Prevention

Level 2 – Preventing the exfiltration of sensitive data, such as confidential information, customer data, or intellectual property, relies on monitoring data and documents that are sent from a trusted internal network to the Internet. A Data Loss Prevention (DLP) monitoring and prevention solution should therefore be set up to watch any points where the two networks intersect, such as perimeter Internet gateways. These solutions look for certain textual content and documents such as:

· Strings and numbers that looks like social security or credit card numbers

· Electronic documents that contain proprietary information

· Presentations that are labeled as confidential

· Any encrypted files sent by non-full time employees (non-FTEs)

A growing challenge to DLP monitoring is the blurring of the perimeter. This is due in large part to the increasing use of cloud service providers. Another challenge is the increasing use of encryption for everyday use, for both data at rest and in transit. The contents of encrypted files and communications are unable to be inspected.

Figure 2.5: A DLP solution monitors traffic leaving a network to alert on and prevent sensitive data from leaving the network.

Cloud providers are sensitive to concerns about security and ensuring the confidentiality of protected data. Most provide controls to ensure data segregation and activity logging. These controls should be reviewed carefully as part of the overall evaluation of any cloud hosting providers being considered for use by an organization.

For using DLP with encryption there are also options, such as blocking encrypted files from being emailed by non-FTEs, or doing a man-in-the-middle implementation of DLP where traffic is first decrypted and inspected, then re-encrypted before exiting the Internet gateways (though this method has its own privacy and security concerns.)

Protection against inbound attacks should be implemented and providing value to an organization before looking at monitoring and preventing outbound data. Because of this, DLP is considered a level 2 security objective.

2.2.3 Anonymizer Network Monitoring

Level 3 - The Onion Router (TOR) network and the Invisible Internet Project (I2P) are networks that can be used to proxy Internet traffic, which renders individuals “anonymous” as they browse the web. The word “anonymous” is in quotes because there is some debate about just how anonymous people really are when using TOR. Regardless, this network is used ostensibly to preserve privacy, but is also being increasingly used by malware to hide activity, such as data exfiltration and downloading instructions and payloads from C&C servers. Everyone has the right to be anonymous on the Internet. A large percentage of anonymizer network usage is benign (you can buy homemade cookies using TOR and Bitcoin, for example [16]). However, here we are talking about preventing malicious activity on an organization’s network.

Figure 2.6: The Internet activity is ostensibly non-attributable when using an anonymizer network.

By being aware of the different anonymizer networks that may be used for malicious purposes (such as by malware), correct monitoring can be put in place to gain awareness if any activity involving IP addresses associated with these networks. The monitoring can be done by maintaining a list of current TOR exit nodes, and there are several open-source sites that provide this. It should be noted that the IP addresses used by these networks constantly change, so the list used for monitoring should also be refreshed on a regular (e.g. hourly) basis. Identifying endpoints on the network that are connecting to these IP addresses may point to a compromised device, or an insider threat that is covering his or her tracks.

A script could be created that downloads this list of IP addresses on an hourly basis, then adds those IP addresses to a lookup table in the SIEM. With a dashboard or alert set up, it is possible to be notified whenever someone (or something) visits an anonymizing network. Anonymizer network monitoring may be considered to be more in the research realm of IT security, as it is a recent development in malware discovery, and its value is not guaranteed. For this reason, fundamentals should first be focused on, making this a level 3 security objective.

2.2.4 Honeypots

Level 3 - A honeypot is a host or server on the network that appears, for all intents and purposes, to be just another legitimate asset on the network. Or it could be dressed up to be more attractive to adversaries, by hosting files with names like salaries.xls or passwords.txt. The goal is to actually be targeted by attackers. This is because the purpose of a honeypot is to provide information about the different attacks that the organization is potentially exposed to. Observing attacks against a honeypot could also reveal an insider threat, such as an employee who copies sensitive files and uploads them to the Internet. Honeypots can also distract and occupy the attention of attackers, “thus making them think they're getting away with something, when in reality they're chasing their tails.”[17]

There is some debate whether the use of a honeypot is actually entrapment. But it could be argued that while a honeypot provides opportunity, it is still the adversary that deliberately performs the malicious action and should therefore be held responsible for doing more than just falling for a trap.

The use of honeypots should be explored only after the fundamentals have been implemented and proven effective. For this reason, a honeypot is considered a level 3 security objective.

2.3 Vulnerability Scanning

Level 2 - Vulnerability scanning serves two purposes: evaluating assets for their security hardiness and identifying all endpoints that are connected to the network.

A common process for vulnerability scanning is to first do a network scan. This is useful for asset identification, including finding those items that are not documented or previously known. These could be rogue endpoints, or devices that have been installed for legitimate purposes, but not with consent nor awareness of the security team. Assets that are discovered and determined to be legitimate should be documented in a repository such as a configuration management database (see CMDB in Section 1 of this book.) Rogue devices should be found and removed from the production network ASAP.

The next step is to iterate the list of discovered assets and perform a more detailed scan of each. This is known as an asset scan, which can be very useful for finding patching opportunities. Caution should be used however, as a scan could cause the target to fail due to it being subjected to an excessive amount of network activity that a scan can generate. Some assets may need to be exempt from scanning to avoid them from crashing, though it can be said that a scan that crashes a system identifies a system that is prone to denial of service attacks.

There are two types of asset scans: authenticated and non-authenticated. Authenticated scans require the scanner to actually log onto the device, which provides much more access for the scanner and therefore more scan coverage. An account that follows the principle of least privilege should be created specifically for the scanner to use. Non-authenticated scans may be considered safer because the scanner does not log onto the asset, but the scan coverage can be less comprehensive as a result.

Figure 2.7: An administrator can schedule and launch vulnerability scans against any device on the network, or against segments on the network.

Initiating scans can be trivial, but establishing and following a process where findings are followed up with the appropriate groups to ensure systems are patched in a timely manner is a non-trivial effort. Vulnerability scanning can help ensure that endpoints are secured and all networked assets are identified. For vulnerability scans to be truly effective, however, they need to be part of a dedicated vulnerability management program.

Patching may be one of the most effective ways to improve the security posture of an organization. The implementation of an effective vulnerability management program, however, takes well thought out processes, coordination with several teams, and persistence to get the systems updated. Therefore, it is considered a level 2 security objective.

2.4 Cyber Intelligence

Level 2 - Cyber intelligence is shared information that provides ways to identify attacks, adversaries and malware, and prevent attacks from taking place as a result. There are many sources of intel, both free and paid-for. There are also several communities that exist where members freely share information based on their own experience and research. Finding intel is not the problem. The challenge is finding information of value: actionable intelligence.

Intel also has an expiration date, and usually a short one at that. Once the details about an attack campaign or malware are known, the effectiveness of the attack is severely diminished since people now know how to protect against it. The tactics adapt and change as a result. Intel needs to be received in a timely manner, and assigned an expiration date based on when it was received, or at least reduce its value as time goes on. Otherwise you run the risk of collecting intel ad infinitum, which will make it increasingly more resource-intensive to use the information as the collection grows.

It is recommended for the security team to maintain its own cyber intelligence repository. The information it contains can be plugged into detective and protective controls, and a SIEM, but its contents need to be maintained to ensure the intel is current, relevant, and has value. Despite the challenge of being able to both bring in intelligence feeds and integrate them into monitoring and alerting processes, there is a significant amount of value that cyber intel can provide for detecting and preventing attacks. For these reasons, it is considered a level 2 security objective.

The following are some of the different kinds of cyber intelligence and how they can be used.

2.4.1 Indicators of Compromise (IOC)

An Indicator of Compromise (IOC) is a piece of information that can be used to help identify a malware, an attack, or other potentially malicious activity. IOC’s (once obtained from a reputable source) can be added to a continuous monitoring solution such as a SIEM so that if there are any matches of IOC’s against actual events observed on endpoints or the network, an alert can be thrown.

Some caution when using IOC’s from intel feeds, however: not all are created equal. For example, sometimes non-malicious IP addresses and domains get swept up in the information collected from a previous security event. For example, a security incident may involve a Google IP address, because the attack started when someone searched for something on Google, and the search results included a link to malware (because of a search engine optimization (SEO) attack.) If all IOC’s were automatically added to a monitoring solution without prior review, then legitimate sites like Google could start triggering alerts, quickly overwhelming the security staff with false positives. Therefore, take all IOC’s with a grain of salt, and subject them to some sort of quality control check before use.

2.4.2 Domain Names

A domain name is registered by an individual or an organization, and is often intended to represent an entity on the Internet, such as is the web presence for Microsoft Corporation. A domain can be thought of as a mailing address, and at that address can be one or more rooms, or hosts. For example: is the main web site for Microsoft, whereas is a software update site that Microsoft also hosts.

Domain names do not have to be easy to read either. The domain may also be legitimate (and is completely made up), but it impossible to know what it represents just by looking at it. This is where the value of cyber intelligence comes in. If an intel feed provided the IOC, and the feed is trustworthy, then this domain can be plugged into detective and protective controls. As a result, an alert would be thrown if a device attempted to visit this domain, identifying a potentially-compromised device. Or an internet proxy could block the domain altogether.

There are also top-level domains (TLD), such as .com,, .bank, etc. This is appended to the domain name, and represents a high-level categorization or grouping, such as country of origin or content category (.ru for Russia, .org for non-profits, for example.) There may be limited value in setting up monitoring based on TLD’s, however, as blocking an entire category of anything runs the risk of blocking legitimate sites. Command and control (C&C) servers

A Command and Control (C&C) server is used by malware to receive instructions, download additional functionality, or receive stolen data. The C&C server can be identified by a domain name or an IP address, and this server can either be a host created by an adversary, or a legitimate server that has been compromised. Being aware of any endpoint communicating with a C&C server may indicate the device is infected with malware.

Using IP addresses to identify C&C servers may not be effective, however, as attackers will “throw off the scent” by using disposable IP addresses, or by using services that quickly change the IP address used by domains at regular and short intervals. Lastly, it is also possible for a C&C server to actually exist somewhere on the organization’s network, versus somewhere on the Internet. This is the modus operandi of several malware variants.

Given all of these challenges, there is still value in monitoring and blocking traffic to known C&C servers, as it can prevent malware from being fully functional or exfiltrating sensitive data.

2.4.3 IP Addresses

One of the least effective ways to identify the source of a scan or attack is to use the IP address from which it originates. IP addresses are basically disposable and can be spoofed or routed through proxies to hide the true source. An IP address may even lead to someone who is innocent but has a compromised device. For these reasons, attribution based on the IP address is not reliable.

Being able to ascribe attribution to a particular part of the world also can be difficult. The South Korean government experienced over 110K cyber-attacks in 5 years, and almost none of those were sourced from a North Korean IP address.[18] Despite their relatively low value, IP addresses may still provide a starting point to create alerts and dashboards. And sometimes miscreants are lazy and forget to hide their IP address, or sometimes they make mistakes. So IP addresses are not totally without value from an attribution standpoint.

There are some IP addresses that are perpetually compromised or evil, and will always be the source of low-grade attacks and scans. These IP addresses are low hanging fruit that should be plugged into protection controls to block what should otherwise be considered Internet noise.

2.4.4 File Hashes

Installing and using hashes with an file integrity checker (FIC) was discussed in section 1 of this book. Known bad file hashes can be supplied by cyber intelligence sources and fed to an alerting solution, such as a SIEM, or perhaps to endpoint FICs themselves. If any files are discovered to have a hash that matches an intel-provided hash, there are several response options, which include generating an alert, and having the endpoint software quarantine the suspicious file.

2.4.5 Email

Phishing is one of the most effective methods used by adversaries to get a victim to download and install malware. Information collected from previous phishing campaigns can provide indicators that can be used to block the same phish from reaching other people’s inboxes. The following are elements of an email message that can be used to cross reference IOC’s and block malicious emails.



Sender Address

This includes not just what the email client displays, but also the email address that the message was really sent from.

Subject Line

This is the subject of the email message, which is a popular way to identify phishing emails.


Files attached to the email (PDF and Office documents, for example) that can be detached and scanned by an appliance such as an email gateway or malware prevention solution (MPS). These attachments can be identified by the file name or checksum.

Sender IP

This is the IP address from which the email originated. This is helpful for identifying email from malicious actors when the sender address is spoofed.

Links in Message Body

The links in an email message can be isolated and evaluated by appliances like an email gateway or analysis sandbox to determine whether the link points to a malicious URL.

Table 2.2: Emails have several identifying properties that can be used to mitigate phishing attacks.

2.5 Summary

Hopefully this section has provided the reader with a good overview of what goes into building out a capability to detect and protect against different types of attacks. Mitigation involves the use of a combination of detective and protection controls placed at strategic locations throughout the network, and at the Internet-facing perimeter. Taking the time to create a comprehensive inventory of all the assets on the network will help ensure that vulnerability scans are thorough, and the security team can quickly get detailed information about any asset that requires investigation or removal from the network. Lastly, the use of cyber intelligence can provide information about adversaries and the attacks they launch, though this information can have varying quality and a limited shelf life.

The maturity level assigned to each item represents the level of maturity an organization’s security team (or SOC) should be at to effectively implement the respective security control. It is recommended to pursue these security controls according to what is appropriate for your organization, and in the order of their maturity levels. The order of the items for each level does not represent their importance or the order in which they should be pursued.

2.5.1 Level 1

· Alerts

· Reporting

2.5.2 Level 2


· Data Loss Prevention

· Vulnerability Scanning

· Cyber Intelligence

2.5.3 Level 3

· DNS Query Monitoring

· Anonymizer Network Monitoring

· Honeypots

2.6 Terms and Definitions

The following are the terms that were discussed in this section.




Application Programmer Interface. An alternate way to interact with a system.


Advanced Persistent Threat. Definitions vary, but generally an APT is a focused effort to get a persistent and undetectable foothold on a network for purposes such as long term monitoring and data exfiltration.

Asset Scan

Scanning individual endpoints to identify vulnerabilities, missing patches, and information disclosed by the target.

Cyber Intelligence

Shared information about attacks and threat actors that can help protect others against the same threats.


Command and Control. These are hosts under an attacker’s control that provide malware with instructions, modules, payloads, and also receive data exfiltrated by malware.


Distributed Denial of Service. A type of network-based attack where a collection of Internet-connected devices overwhelm a specific target such as a web site or gaming network.


Data Loss Prevention. This is an effort initiated by many organizations to prevent or at least limit the data that is exfiltrated by employees and insider threats.


Domain Name Service. Part of the backbone of the Internet, these are servers across the globe that resolve domain names to IP addresses.

Domain Name

A web server address expressed in alpha numeric characters that is often more user friendly than its IP address equivalent.


Indicator of Compromise. Cyber intelligence collected from security events and incidents that is shared, so that other organizations can use the information to prevent themselves from suffering the same attack.


Intrusion Prevention System. A security appliance that generates alerts or blocks network packets based on observing certain patterns or behaviors.


A tactic used by adversaries to distract from the actual, main attack.

Network Scan

Scanning the network to identify assets installed on it.


Network Time Protocol. This is a standard method for getting the time from a centralized clock so that all the devices are synchronized.


Search Engine Optimization. A type of attack where the miscreant manipulates a search engine so that search results for certain keywords link to sites under the attacker’s control.


Security Information Event Management. A solution that provides a centralized log repository, data mining, alerting, and a consolidated view of events from disparate sources.


Top Level Domain. Part of a domain that indicates the country of origin or category of a web site.


The Onion Router. An anonymizer network that allows users to hide their true identity on the Internet.


Tactics Techniques and Procedures. Borrowed from the military, this describes the elements used by an adversary to perform an attack.