Top 20 CIS Critical Security Controls (CSC) Through the Eyes of a Hacker – CSC 19

In this blog series, members of Optiv’s attack and penetration team are covering the top 20 Center for Internet Security (CIS) Critical Security Controls (CSC), showing an attack example and explaining how the control could have prevented the attack from being successful. Please read previous posts covering:

• CSC 1: Inventory of Authorized and Unauthorized Devices
• CSC 2: Inventory of Authorized and Unauthorized Software
• CSC 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers
• CSC 4: Continuous Vulnerability Assessment and Remediation
• CSC 5: Controlled Use of Administrative Privileges
• CSC 6: Maintenance, Monitoring, and Analysis of Audit Logs
• CSC 7: Email and Web Browser Protections
• CSC 8: Malware Defenses
• CSC 9: Limitation and Control of Network Ports, Protocols and Services
• CSC 10: Data Recovery Capability
• CSC 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
• CSC 12: Boundary Defense
• CSC 13: Data Protection
• CSC 14: Controlled Access Based on the Need to Know
• CSC 15: Wireless Access Control
• CSC 16: Account Monitoring and Control
• CSC 17: Security Skills Assessment
• CSC 18: Application Software Security

CSC 19: Incident Response and Management

The Control

Protect the organization’s information, as well as its reputation, by developing and implementing an incident response infrastructure (e.g. plans, defined roles, training, communications, management oversight) for quickly discovering an attack and then effectively containing the damage, eradicating the attacker’s presence and restoring the integrity of the network and systems.

The Attack

Unlike the previous posts that depicted fairly specific attack types, let’s instead approach this by inspecting the kill chain affiliated with typical attack patterns. The following image, taken from National Institute of Standards and Technology (NIST), manages to reduce the complexity of the kill chain to a consumable visual aid.

Note a few important details about this graphic:

1. Despite the kill chain appearing sequential in nature, the steps (or a subset of the steps) are typically iterative as new information, privileges and access is obtained.
2. The graphic is split into loose classifications relative to organizational defenses. One for proactive defense and the other for reactive.

For this blog post we’re primarily concerning ourselves with the reactive response. Specifically, handling the stages of kill chain related to exploitation, installation, command and control (C2), and action objectives. After all, incident response is purely aimed at restoring system, data and network integrity by eradicating attacker access.

Within the steps of the kill chain there are further defined actions that you can break up into categories such as lateral network movement, privilege escalation, etc. Each of these stages often have specific indicators of compromise (IOCs) that can be useful for tracing an attacker’s methods and path throughout your network. For example, a common kill chain may follow this pattern:

1. Open source, passive and active reconnaissance against the organization to identify attack vectors and targets. In our example, we identify through social media and business listing the names, emails and job titles of several employees.
2. Deploy a non-attributable infrastructure, procure a source domain and create a malicious Microsoft Word document.
3. Execute (deliver) a spear phish to a list of high-value targets gathered during reconnaissance.
4. The document results in the compromise of a user workstation, through which the attackers have now gained access to the internal network. We now move from the proactive to reactive portion of an organization’s security posture. This is now an incident response situation for the target.
5. Establish persistence via Windows task scheduler, registry settings or some other means.
6. Escalate privileges locally if possible and needed.
7. Retrieve local password hashes or cleartext credentials by interrogating LSASS.
8. Attempt to utilize compromised accounts to move laterally throughout the network, potentially replaying local administrative credentials or domain account credentials.
9. Extract password hashes and credentials from LSASS as needed until escalating privileges to Domain Administrator.
10. Identify high-value target workstations, servers and users, methodically compromising each using necessary privileges and remote access methods.
11. Repeat/ignore any of these steps as needed until the objective has been accomplished (e.g. credit card data obtained, intellectual property exfiltrated, etc.)

Consider that 80 percent of organizations breached in 2016, according the Verizon Data Breach Report, took weeks or longer to discover the breach. In 7 percent of those cases, the breach went unnoticed for more than a year. This is staggering. The longer an attacker persists in the network the greater the potential damage, cost and difficulty to eradicate. Detection is the lynchpin event that begins the execution of an incident response plan.

Although technical controls can be effective at identifying the initial breach and the attack kill chain, this information is only valuable to an organization if properly collected, analyzed and acted upon. For this reason, technical controls operating in tandem to support clearly defined incident response procedures are paramount to minimizing the impact of a compromise. It’s the difference between an effective incident response program and ineffective one. Certainly, incident response depends on tools and active response techniques, but much of its effectiveness is rooted in procedure and policy.

The Solution

So let’s look at the components necessary to create an effective incident response program.

• Deployment of monitoring agents, endpoint security products, and log correlation and collection technologies to enable detective and forensic capabilities.
• 24x7 monitoring and analysis of event data through local or managed security services providers.
• Procedures and roles must be explicitly defined and communicated to employees such that actions and expectations are clearly known. This information should be formalized and include technical and management resources, decision-maker authority, vendors, and any other relevant parties and communications expectations such that events can be triaged rapidly without confusion or conflict. For more specific details, refer to the official CSC control document which contains a nice summary of these items.
• Periodic table-top walkthroughs and reviews to adapt the policies and procedures to evolving threats and to ensure all actions, personnel and vendors maintain relevance within a changing business landscape.
• Periodic exercises and live-fire tests to evaluate the effectiveness of the incident response program. Post-mortem analysis should be used to mitigate deficiencies and influence security spending where necessary.

As a member of Optiv’s attack and penetration practice performing offensive engagements, I can’t stress enough the importance of that final bullet point. Organizations rarely perform live-fire tests to evaluate their incident response capabilities, getting the opportunity to assess their program only after an actual breach occurs. That’s putting a lot of hope on an untested, unrefined and often complicated process that’s being executed under pressure. We’ve performed assessments that have tested organization’s processes for the first time, only to have the organization learn that they are grossly understaffed or incapable of eradicating the breach prior to the exfiltration of millions of sensitive database records. You don’t know whether it works until there’s a breach – you’re better off letting it be a controlled exercise. 

This discussion segues nicely into our 20th and final CSC series post: CSC 20 – Penetration Tests and Red Team Exercises.