Intro

In this lesson, we look at security for devices connected to networks: servers, storage, and end-user devices. I examine how the cyber kill chain, zero-trust networks, and network access control help manage the associated risk. You can download the script for this video from above or at the end of the video. The script contains all graphics included in this lesson.

Cyber Kill Chain

In the CISSP Domain 4 video series, I've covered most of what you need to know about protecting the network in general. However, one thing we haven't covered yet is the highest risk to any network: end-user devices. End-user devices today, whether mobile or static, present the greatest security risk to any organization. This graphic is my version of the cyber kill chain created by Lockheed Martin. It represents the basic attack process, a chain of links or objectives, that an attacker must complete to reach their threat objectives. Preventing a threat actor from completing any one step or link can prevent her from reaching her attack objectives. However, we always try to do more than that by breaking two or more links in the chain. I will step through this process and discuss how you can reduce risk associated with end-user devices.

Reconnaissance and OSINT

The first step a threat actor takes in any attack is reconnaissance. Reconnaissance enables the threat actor to learn as much about a target without any invasion of a target's network. A lot of information is available across public resources. Exploring these resources and collecting relevant information is known as open-source intelligence, or OSINT. Sources of OSINT on the web include blogs, discussion groups, any user created content, online publications, social networking sites, database services, including Factiva, LexisNexis, and Dialogue, as well as information stored in the internal network, but on internet-facing devices. OSINT resources found off the web include public government data, commercial and professional publications, imagery, and financial-industrial analysis. Most organizations understand that these already described resources might contain valuable information needed to identify valuable target resources and how to find them. However, there are other resources known as gray literature that are less likely to be considered when identifying available OSINT. This is known as gray literature, and includes technical reports, preprints, patents, working papers, unpublished works, newsletters, business proposals, and requests for proposal.

Use of OSINT in Attack Planning

Once the OSINT is collected, the threat actor can use it to craft social engineering attacks that target specific targets. Password guessing is easier when a threat actor understands a target user's interests and environments, including family names, understanding the organization's network helps determine what should be attacked and why. This helps a threat actor compromise the best device he can use to launch attacks against his intended target resources. A threat actor can use OSINT also to gain insight into the operating systems and applications running on target resources. This helps a threat actor identify useful vulnerabilities and known exploits. A threat actor might not be able to get all needed information in one place, however, he can gather bits of information across multiple resources that can be aggregated to provide a big picture attack surface.

OSINT Defense

It's impossible to completely sanitize OSINT resources. To prevent threat actor access. however, an organization can take steps to minimize the effectiveness of reconnaissance. Organizations must understand what information is available about them across the web and in public documents. This can help with partial sanitization and adjusted defenses. Organizations must control what resources are accessible via the internet. It is not uncommon for employees to place documents on servers or other devices that can be scanned remotely with internet tools. Employees must be trained to help ensure they don't post information potentially usable to threat actors on social media or other publicly accessible places. Even so, organizations should scan social networks to find out what information about their business is actually out there, and organizations must control the distribution of project research and other sensitive documentation. For a more detailed look at OSINT and a tool demonstration, watch the video Open-source Intelligence for Cyber Offense and Defense at the link shown.

Weaponization

The next link in the chain is weaponization. This is the point at which the threat actor uses reconnaissance information to create an attack package that has a high probability of success. There isn't much an organization can do to break this link. A step that can make it harder, in addition to the steps to hinder OSINT collection, is keeping systems and their applications patched. This reduces the attack surface and makes weaponization more difficult. If target objectives don't provide enough value based on the effort, the threat actor is likely to move on to another target. I'm using this graphic to explain the activities that take place during the remaining links in the cyber kill chain. It is from Part 2 of a series I did on that chain. The article, Advanced Malware: How It Works, is available at the link shown.

Delivery - Lures

After the threat actor creates her exploit kit, she uses one or more lures to get users to deliver her payload. This is the first step in the delivery link. Lures include email links, Microsoft office macros included in attachments, links on social networking sites, and DNS redirection to malicious servers.

Delivery and Installation

In many attacks, a user clicking on a link or opening an infected file causes a drop file to be downloaded and installed. The drop file then calls home to a malicious server and downloads the rest of the attack package. In other cases, the entire attack packet is downloaded and installed in the initial download. These steps include the cyber kill chain delivery and installation links. We can break the delivery and installation links by using anti-malware, which is never enough, email filtering, and blockage of high-risk attachments, preventing execution of macros not explicitly approved, preventing users from installing any software not specifically in the organization's approved software list, blocking the threat actor's ability to call back to her server to complete the delivery via web filtering and other tools, ensure that no internal device can create an encrypted session such as HTTPS or TLS directly with an external device. This requires a device that intercepts TLS requests from internal users and then creates an encrypted session between itself and the external device. This allows filtering of all encrypted traffic. And finally, train users not to fall for the lures several of these safeguards apply to this and the following links.

Command and Control

Once the exploit kit is installed, the exploit kit calls home to establish the command and control, or C2, link in the chain. This is how the threat actor provides instructions to the malware and receives back data. C2 is often encrypted to hide the threat's activities. This is why we try to block all direct encrypted links between internal and external devices that we cannot filter. In addition to helping to block download and installation of the exploit kit, blocking C2 via web filtering and ensuring the filtering of all encrypted sessions with the outside world is needed. This starts with implementing host-based intrusion detection and firewall solutions.

Actions and Objectives

The final link in the cyber kill chain, actions and objectives, can take many forms, including attempts to gain access to high-value targets across the internal network. For this to be effective, the compromised user device must be able to see the targets over the network. Attempts to gather information from resources the users logged into the device can access or use, and attempts to package the stolen data for transmission over the C2 link. Some of the safeguards already covered can help break this chain. Additional safeguards to break this link include network segmentation that helps prevent direct access to databases and other storage of sensitive information, zero-trust networking that helps identify anomalous user or device behavior and take steps to manage it, strong authentication for resource access helps prevent threat actors from breaking authentication for access across the enterprise, separation of duties limits what a user can do and what a threat actor can leverage, need to know limits what a user can access and therefore what a threat actor can see on a compromised device.

Mobile Device Security

The safeguards we've discussed apply to all devices, but mobile devices and servers need additional attention. First, mobile devices. One of the biggest risks associated with mobile devices is they're lost via theft or other means. Many mobile devices contain large amounts of sensitive data. They are also configured to connect via safeguards like certificates. This requires training users on how to maintain control of these devices. Mobile devices connecting to public networks are at increased risk of compromise. All public networks, both wireless and wired, should be considered hostile. To mitigate the risk, start with system and network hardening, as provided above. But organizations should also consider the considerations in the next slide. Organizations must control what is actually stored on mobile devices. This is easily done by forcing mobile users to access resources via virtual desktops running in the cloud or in the organization's data center. No data is sent to the remote device except what is shown on the screen. Once the session ends, there are no trace of data on the mobile device. If virtual desktops are not used, the organization should consider using tools designed to help control what is stored locally and how it is stored on remote devices, and for how long it stays there. All remote sessions should run over a secure link. The most common approach to this is to use VPN or other implementations of TLS. As shown, the remote device engages in a handshake with the server to establish an encrypted connection. For a detailed look at how this works, watch the video above. Access to the network resources by mobile devices should be controlled by strong authentication and, if possible, Attribute-based Access Control. Strong authentication usually takes the form of multi-factor authentication. For a detailed look at multi-factor authentication, watch the video above. Attribute-based authentication goes beyond user role assignment. It also looks at characteristics of the entity attempting access, including time of day, day of the week, location of the device attempting access, the kind of device attempting access, and resources to be accessed. Full-disk encryption of mobile devices helps ensure a threat actor with physical access to a device cannot gain access to anything on the device. This encryption should be protected with strong user authentication if the device contains sensitive data or has access to sensitive resources in the cloud or in the internal data center. Finally, organizations should consider using a centralized mobile device management tool or MDM. They range from easy to use and very inexpensive tools like Microsoft InTune to a more extensive tool, and more expensive tool, like MobileIron. MDM solutions can help manage access and the device policies needed to protect mobile data. Further, MDM provides the ability to wipe a lost device. MDM and other mobile security considerations are detailed in the NIST Special Publication 800-125 available at the link shown.

Bring Your Own Device (BYOD)

Now let's look at bring your own device or BYOD. BYOD has grown over the past decade as employees want more flexibility and employers strive to reduce costs. Employees using their own devices can often run their own tools and applications. BYOD also enables easily taking personal applications to the office and taking business work home. But in addition to general mobile device security, organizations must take additional steps to protect BYOD data. The biggest problem with BYOD is increased risk when the organization does not or cannot properly manage personal devices that connect to its resources. This graphic from the draft of NIST SP 100-22b Mobile Device Security: Bring your own device, is available at the link shown. one of the most important risk management steps is to separate data belonging to the user from the data belonging to the organization. This is possible with higher-end MDM solutions. If an MDM is not possible, policies must provide strong control, including periodic audits or data leakage scans to ensure BYOD devices do not have sensitive data in unexpected locations. One way to manage all of this is to use virtual desktops. Another is to require full disk encryption on all BYOD devices. As with all remote access, all connections to resources must be encrypted. The organization must know if high-risk applications exist on BYOD devices. For devices that access highly classified data, the detection of high-risk applications can result in blocking device access to organization resources. Attribute-based Access Control, ABAC, which we've already covered, helps with controlling what devices can connect and with what resources. All BYOD devices must include anti-malware solutions. In addition, host-based firewalls and IDS should be considered. Use of certificates helps to identify approved BYOD devices when they attempt connections. Combined with user multi-factor authentication and ABAC or Attribute-based Access Control, this helps ensure only expected and managed devices connect. MDM tools can track what applications are installed what data is stored, and the locations from which devices attempt to connect. However, there is a boundary between user privacy and organization risk management. This boundary shifts based on the role of the user, the classification of data accessed, and the categorization of resources used. In many cases, BYOD may introduce more risk than management is willing to accept.

Server Hardening

Finally, let's look at server hardening. Each server requires a general set of hardening steps that apply to all servers in the enterprise and a set of specific hardening steps, depending on each server's role in supporting one or more systems. General hardening steps include keeping the OS patched and up to date; ensuring only required applications are running; disabling the use of browsers to access the internet directly from the server; blocking direct internet access for servers not providing web services; use strong authentication use strong password and account policies; disabling USB ports; using full disk encryption where appropriate; using secure firmware like intel's platform firmware resilience; and using confidential computing technology. In general, each server should perform a specific role. Only applications and tools that support that role should run. This is easily done when using virtual servers. Another consideration is to not mix data of different classifications on the same server. For example, we should not place confidential data on the same server as top-secret data. Mixing includes data that are processed, pass through, or are stored on or by a server. Each server runs one or more applications. These applications and supporting tools require special attention that likely require risk-based considerations for hardening, including check for vulnerabilities daily and ensure vendors manage any vulnerabilities found quickly and effectively; patch or upgrade as needed; segment application servers from database servers and control access at the network level; monitor and control changes to applications; monitor and control installation of applications; audit application use; use multi-factor authentication for applications when risk dictates; monitoring and controlling activity with network and host-based IDS and IPS; and use one or more anti-malware layers based on risk. That's it for this lesson. If you have questions, please ask. ...and until next time, be careful what you click.