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

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

The Control

The processes and tools used to track/control/prevent/correct secure access to critical assets (e.g., information, resources, and systems) according to the formal determination of which persons, computers, and applications have a need and right to access these critical assets based on an approved classification.

The Attack

Under this control, we must first observe the underlying need for data and system classification. In order to implement a strong access management program you must know which assets and data you are trying to protect, as well as where it is stored. Once data flows have been created which outline where data needs to be accessible from, network policies must be defined to restrict users from accessing systems in which they have no business reason. In addition to network policies, it will be necessary to implement access control lists for access management of users.

Take for example a large office building with multiple departments needing access to different servers (i.e. sales needs access to their CRM, HR needs access to its HR management software, and IT has its own sensitive system administration system). In most network topologies, all users will have at least network access to all of the servers. In some environments, they may have some level of access to the actual operating system or applications running on the servers.

Through my years of testing, I have seen only a few people actually get access management right down to the network level. The diagram below shows what most people would expect to be an average network. It has a firewall and switch, a few networks for departments, and a server network containing multiple systems. Proper implementation of these controls may not necessarily be a topology issue as much as it is a network policy issue. 

Figure 1: An average network

Building a secure network is accomplished by putting the focus on what happens once the topology is in place. For instance, we can conclude the following potential issues from an average topology.

• Sales has network access to HR systems
• HR has network access to system administration servers
• Sales has network access to IT systems
• HR has network access and possibly OS/application access to HR systems

From a network level, most networks are the Wild West with the exception of specifically segmented compliance networks such as PCI for processing credit card transactions. As such, it is usually possible to gain access to any desktop system in the environment through a spear phishing attack, and to use that desktop system to attempt to break into any system containing sensitive information regardless of which department that user is in. Additionally, once on the internal network it is very easy to move laterally or conduct man-in-the-middle (MiTM) attacks on other systems in the same department or perhaps even other departments.

The Solution

As previously stated, I’ve seen some exceptional implementation of access management. In those networks:

• Private VLANs were enabled ensuring that all traffic first routed to a firewall for processing
• Once traffic arrived, the firewall determined which user     attempting to open a connection and checked active directory for the user’s access groups
• The firewall either permitted or denied the network connection depending on whether or not the user belonged to the proper group

By making this privilege determination at the firewall rather than the destination server, organizations are able to prevent network access to systems on top of preventing application access to systems. This puts all servers in a much more secure environment since attackers who phished users in sales could not access HR servers in attempt to extract information, nor could they move laterally to an HR desktop system in order to pivot to HR servers.

Through implementing multiple layers of defense (like an onion) you can further protect assets from attack. This control suggests some of the layers which could be implemented to build a strong asset management program including:

• Restricting network access to servers to allow only users who have a business use for accessing the system
• Encrypting all communications and data at rest
• Enabling private LANs to isolate individual users on the network
• Implementing access control lists on the application or operating system to protect and restrict access to data to only users who have a business use to access the data

The next post will cover CSC 15: Wireless Access Control.