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

Property	Details
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 www.google.com, the web browser resolves this domain name into an IPv4 address (e.g. 8.8.8.8). 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 www.google.com 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 microsoft.com 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: www.microsoft.com is the main web site for Microsoft, whereas update.microsoft.com is a software update site that Microsoft also hosts.

Domain names do not have to be easy to read either. The domain caff5nzmnlb0jyorapa.com 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 caff5nzmnlb0jyorapa.com, 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, .co.kr, .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.

2.4.2.1 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.