What are the top 20 Security Controls?
When you need to quickly secure your IT infrastructure you can’t afford to spend time patching up low criticality vulnerabilities, wading through a sea of false positives, or implementing redundant practices. You need to prioritize what you can tackle today to make big steps in your cyber defense. With this in mind a consortium of hundreds of security experts from across the public and private sectors including CPNI, SANS, and Tripwire have united to make a prioritized strategy for addressing cyber security.
The top 20 critical security controls are a set of high-priority information security measures and controls that can be applied across an organization in order to improve its cyber defense with a focus on actionable measures with high-payoff results. Studies conducted by SANS found that 73% of those surveyed have adopted the Controls or plan to implement them.
This list of controls and sub controls helps organizations prioritize their efforts to effectively defend against the current, most common and damaging computer and network threats of today as well as those expected in the near future. The order of these controls as well as the recommendations of their sub-controls are updated regularly to reflect changing technology and methods of attack. An abbreviated copy of version 5.0 of the controls can be found at the bottom of this page.
History of the top 20 controls
As IT security threats developed alongside technological advances, so too did frameworks for protecting networks and confidential data. Although often effective, such frameworks were disjointed and tended to be non-prioritized. In 2008 the Office of the Secretary of Defense (OSD) asked the National Security Agency (NSA) to help prioritize the many controls available. That same year the Center for Strategic and International Studies (CSIS) published the Top 20 Controls for the first time.
One of the earliest adopters of these controls was the U.S. Department of State, which achieved an 88% reduction in vulnerability-based risks across 85,000 systems.
CPNI top 20 critical security controls
In December of 2011, the United Kingdom’s Centre for the Protection of National Infrastructure (CPNI) announced that the government would be adopting the 20 Critical Security Controls to help secure the country’s critical infrastructure. CPNI is a government agency of the UK that focusses on protecting national security through the provision of security advice on physical, personal and cyber/information topics.
In 2013 CPNI and Tripwire founded the Council on Cybersecurity. This non-profit organization aims to “create a world in which best practice becomes common practice,” primarily through the promotion of the promotion and coordination of the top 20 controls.
The top 20 controls support organizations at all levels of information security capabilities by establishing a security baseline and then providing steps to improve beyond that baseline. To do so the recommended sub controls have been grouped into four categories dependent on criticality and effort to fix; quick wins, improved visibility and attribution, configuration and improved information security hygiene and advanced.
- Quick wins. These sub controls include fundamental aspects of information security that are relatively simple to implement and can help an organization rapidly improve its security stance. Such changes generally don’t require major procedural, architectural, or technical changes to an organization’s environment. The intent of identifying quick wins is to highlight West security can be improved rapidly.
- Improved visibility and attribution. These sub controls focus on improving the process architecture and technical capabilities of an organization so that they can monitor their networks and computer systems and better visualize their own IT operations.
- Configuration and improved information security hygiene. These sub controls focus on protecting against poor security practices by system administrators and end-users that may leave an organization vulnerable to attack. A well-managed network is typically a much harder target for computer attackers to exploit.
- Advanced sub controls. These sub controls go beyond the other three categories to further improve an organization’s security.
Each control includes a metric section that provides information regarding the specific timing and objectives associated with vital aspects of that control. Each control includes a test section with information on how organizations can evaluate their implementation of the control metric. These tests support automation wherever possible to promote reliable, scalable, and continuous measurements of adherence to the controls and related metrics.
Implementing the top 20 controls
To implement these controls you should begin by comparing all twenty control areas against your cyber security status and create a plan to integrate the controls as part of your overall security program. Many of these controls can be implemented and measured using existing tools already available at your organization. For other controls, such as CSC 4 (Continuous Vulnerability Assessment and Remediation) and CSC 6 (Application Software Security), you will need an automated method to quickly and effectively comply.
If your organization is like most large enterprises, the first step to assessing your security posture and securing your applications will be to inventory all of the applications you have. At Veracode we offer a powerful service to do so quickly and effectively with Web Application Perimeter Monitoring. Once discovered these applications must be scanned for vulnerabilities. Using our Static Analysis and Dynamic Analysis technologies CISO’s are saving their organizations time and money over MPT strategies while greatly increasing the number of applications that they are able to test.
Top 20 Controls
Below are the CPNI Top 20 Security controls from version 5.0 of the controls which can be found at http://www.cpni.gov.uk/. Included are the risks as well as the sub controls. All sub controls are grouped into their respective categories.
1. Inventory of Authorized and Unauthorized Devices
Actively manage (inventory, track, and correct) all hardware devices on the network so that only authorized devices are given access, and unauthorized and unmanaged devices are found and prevented from gaining access.
Attackers, who can be located anywhere in the world, are continuously scanning the address space of target organizations, waiting for new and unprotected systems to be attached to the network. Attackers also look for devices (especially laptops) which come and go off of the enterprise’s network, and so get out of synch with patches or security updates. Attacks can take advantage of new hardware that is installed on the network one evening but not configured and patched with appropriate security updates until the following day. Even devices that are not visible from the Internet can be used by attackers who have already gained internal access and are hunting for internal jump points or victims. Additional systems that connect to the enterprise’s network (e.g., demonstration systems, temporary test systems, guest networks) should also be managed carefully and/or isolated in order to prevent adversarial access from affecting the security of enterprise operations.
As new technology continues to come out, BYOD (bring your own device) — where employees bring personal devices into work and connect them to the network — is becoming very common. These devices could already be compromised and be used to infect internal resources.
Managed control of all devices also plays a critical role in planning and executing system backup and recovery.
CSC 1–1: Deploy an automated asset inventory discovery tool and use it to build a preliminary asset inventory of systems connected to an organization’s public and private network(s). Both active tools that scan through network address ranges and passive tools that identify hosts based on analyzing their traffic should be employed.
CSC 1–2: Deploy dynamic host configuration protocol (DHCP) server logging, and utilize a system to improve the asset inventory and help detect unknown systems through this DHCP information.
CSC 1–3: Ensure that all equipment acquisitions automatically update the inventory system as new, approved devices are connected to the network.
CSC 1–4: Maintain an asset inventory of all systems connected to the network and the network devices themselves, recording at least the network addresses, machine name(s), purpose of each system, an asset owner responsible for each device, and the department associated with each device. The inventory should include every system that has an Internet protocol (IP) address on the network, including but not limited to desktops, laptops, servers, network equipment (routers, switches, firewalls, etc.), printers, storage area networks, Voice Over–IP telephones, multi–homed addresses, virtual addresses, etc. The asset inventory created must also include data on whether the device is a portable and/or personal device. Devices such as mobile phones, tablets, laptops, and other portable electronic devices that store or process data must be identified, regardless of whether they are attached to the organization’s network.
CSC 1–5: Deploy network level authentication via 802.1x to limit and control which devices can be connected to the network. The 802.1x must be tied into the inventory data to determine authorized versus unauthorized systems.
CSC 1–6: Deploy network access control (NAC) to monitor authorized systems so if attacks occur, the impact can be remediated by moving the untrusted system to a virtual local area network that has minimal access
CSC 1–7: Utilize client certificates to validate and authenticate systems prior to connecting to the private network
2. Inventory of Authorized and Unauthorized Software
Actively manage (inventory, track and correct) all software on the network so that only authorized software is installed and can execute and that unauthorized and unmanaged software is found and prevented from installation or execution.
Attackers continuously scan target organizations looking for vulnerable versions of software that can be remotely exploited. Some attackers also distribute hostile web pages, document files, media files, and other content via their own web pages or otherwise trustworthy third–party sites. When unsuspecting victims access this content with a vulnerable browser or other client–side program, attackers compromise their machines, often installing backdoor programs and bots that give the attacker long–term control of the system. Some sophisticated attackers may use zero–day exploits, which take advantage of previously unknown vulnerabilities for which no patch has yet been released by the software vendor. Without proper knowledge or control of the software deployed in an organization, defenders cannot properly secure their assets.
Poorly controlled machines are more likely to be either running software that is unneeded for business purposes, introducing potential security flaws, or running malware introduced by an attacker after a system is compromised. Once a single machine has been exploited, attackers often use it as a staging point for collecting sensitive information from the compromised system and from other systems connected to it. In addition, compromised machines are used as a launching point for movement throughout the network and partnering networks. In this way, attackers may quickly turn one compromised machine into many. Organizations that do not have complete software inventories are unable to find systems running vulnerable or malicious software to mitigate problems or root out attackers.
Managed control of all software also plays a critical role in planning and executing system backup and recovery.
CSC 2–1: Deploy application whitelisting technology that allows systems to run software only if it is included on the whitelist and prevents execution of all other software on the system. The whitelist may be very extensive (as is available from commercial whitelist vendors), so that users are not inconvenienced when using common software. Or, for some special–purpose systems (which require only a small number Quick win (One of the “First Five”) 15 of programs to achieve their needed business functionality), the whitelist may be quite narrow. When protecting systems with customized software that may be seen as difficult to whitelist, use item 8 below (isolating the custom software in a virtual operating system that does not retain infections.).
CSC 2–2: Devise a list of authorized software and version that is required in the enterprise for each type of system, including servers, workstations, and laptops of various kinds and uses. This list should be monitored by file integrity checking tools to validate that the authorized software has not been modified.
CSC 2–3: Perform regular scanning for unauthorized software and generate alerts when it is discovered on a system. A strict change–control process should also be implemented to control any changes or installation of software to any systems on the network. This includes alerting when unrecognized binaries (executable files, DLL’s and other libraries, etc.) are found on a system, even inside of compressed archives. This includes checking for unrecognized or altered versions of software by comparing file hash values (attackers often utilize altered versions of known software to perpetrate attacks, and file hash comparisons will reveal the compromised software components).
CSC 2–4: Deploy software inventory tools throughout the organization covering each of the operating system types in use, including servers, workstations, and laptops. The software inventory system should track the version of the underlying operating system as well as the applications installed on it. Furthermore, the tool should record not only the type of software installed on each system, but also its version number and patch level.
CSC 2–5: The software inventory systems must be integrated with the hardware asset inventory so that all devices and associated software are tracked from a single location.
CSC 2–6: Dangerous file types (e.g., .exe, .zip, .msi) should be closely monitored and/or blocked.
CSC 2–7: Virtual machines and/or air–gapped systems should be used to isolate and run applications that are required for business operations but based on higher risk should not be installed within a networked environment.
CSC 2–8: Configure client workstations with non–persistent, virtualized operating environments that can be quickly and easily restored to a trusted snapshot on a periodic basis.
CSC 2–9: Deploy software that only provides signed software ID tags. A software identification tag is an XML file that is installed alongside software and uniquely identifies the software, providing data for software inventory and asset management.
3. Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations and Servers
Establish, implement and actively manage (track, reporting, correct) the security configuration of laptops, servers and workstations using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.
As delivered by manufacturers and resellers, the default configurations for operating systems and applications are normally geared to ease–of–deployment and ease–of–use – not security. Basic controls, open services and ports, default accounts or passwords, older (vulnerable) protocols, pre–installation of unneeded software; all can be exploitable in their default state.
Developing configuration settings with good security properties is a complex task beyond the ability of individual users, requiring analysis of potentially hundreds or thousands of options in order to make good choices. Even if a strong initial configuration is developed and installed, it must be continually managed to avoid security “decay” as software is updated or patched, new security vulnerabilities are reported, and configurations are “tweaked” to allow the installation of new software or support new operational requirements. If not, attackers will find opportunities to exploit both network–accessible services and client software.
CSC 3–1: Establish and ensure the use of standard secure configurations of your operating systems. Standardized images should represent hardened versions of the underlying operating system and the applications installed on the system. Hardening typically includes: removal of unnecessary accounts (including service accounts), disabling or removal of unnecessary services, configuring non–executable stacks and heaps, applying patches, closing open and unused network ports, implementing intrusion detection systems and/or intrusion prevention systems, and use of host–based firewalls. These images should be validated and refreshed on a regular basis to update their security configuration in light of recent vulnerabilities and attack vectors.
CSC 3–2: Implement automated patching tools and processes for both applications and for operating system software. When outdated systems can no longer be patched, update to the latest version of application software. Remove outdated, older, and unused software from the system.
CSC 3–3: Limit administrative privileges to very few users who have both the knowledge necessary to administer the operating system and a business need to modify the configuration of the underlying operating system. This will help prevent installation of unauthorized software and other abuses of administrator privileges.
CSC 3–4: Follow strict configuration management, building a secure image that is used to build all new systems that are deployed in the enterprise. Any existing system that becomes compromised should be re–imaged with the secure build. Regular updates or exceptions to this image should be integrated into the organization’s change management processes. Images should be created for workstations, servers, and other system types used by the organization.
CSC 3–5: Store the master images on securely configured servers, validated with integrity checking tools capable of continuous inspection, and change management to ensure that only authorized changes to the images are possible. Alternatively, these master images can be stored in offline machines, air– gapped from the production network, with images copied via secure media to move them between the image storage servers and the production network.
CSC 3–6: Negotiate contracts to buy systems configured securely out of the box using standardized images, which should be devised to avoid extraneous software that would increase their attack surface and susceptibility to vulnerabilities.
CSC 3–7: Do all remote administration of servers, workstation, network devices, and similar equipment over secure channels. Protocols such as telnet, VNC, RDP, or others that do not actively support strong encryption should only be used if they are performed over a secondary encryption channel, such as SSL or IPSEC.
CSC 3–8: Utilize file integrity checking tools to ensure that critical system files (including sensitive system and application executables, libraries, and configurations) have not been altered. All alterations to such files should be automatically reported security personnel. The reporting system should have the ability to account for routine and expected changes, highlighting unusual or unexpected alterations.
For investigative support, the reporting system should be able to show the history of configuration changes over time and identify who made the change (including the original logged–in account in the event of a user ID switch, such as with the su or sudo command). These integrity checks should also identify suspicious system alterations such as owner and permissions changes to files or directories; the use of alternate data streams which could be used to hide malicious activities; as well as detecting the introduction of extra files into key system areas (which could indicate malicious payloads left by attackers or additional files inappropriately added during batch distribution processes).
CSC 3–10: Deploy system configuration management tools, such as Active Directory Group Policy Objects for Microsoft Windows systems or Puppet for UNIX systems that will automatically enforce and redeploy configuration settings to systems at regularly scheduled intervals. They should be capable of triggering redeployment of configuration settings on a scheduled, manual, or event–driven basis.
CSC 3–9: Implement and test an automated configuration monitoring system that measures all secure configuration elements that can be measured through remote testing using features such as those included with tools compliant with Security Content Automation Protocol (SCAP), and alerts when unauthorized changes occur. This includes detecting new listening ports, new administrative users, changes to group and local policy objects, (where applicable), and new services running on a system.
4. Continuous Vulnerability Assessment and Remediation
Continuously acquire, assess and take action on new information in order to identify vulnerabilities, remediate and minimize the window of opportunity for attackers.
Cyber defenders must operate in a constant stream of new information: software updates, patches, security advisories, threat bulletins, etc. Understanding and managing vulnerabilities has become a continuous activity, requiring significant time, attention, and resources.
Attackers have access to the same information, and can take advantage of gaps between the appearance of new knowledge and remediation. For example, when new vulnerabilities are reported by researchers, a race starts among all parties, including: attackers (to “weaponize”, deploy an attack, exploit); vendors (to develop, deploy patches or signatures and updates), and defenders (to assess risk, regression–test patches, install).
Organizations that do not scan for vulnerabilities and proactively address discovered flaws face a significant likelihood of having their computer systems compromised. Defenders face particular challenges in scaling remediation across an entire enterprise, and prioritizing actions with conflicting priorities, and sometimes–uncertain side effects.
CSC 4–1: Run automated vulnerability scanning tools against all systems on the network on a weekly or more frequent basis and deliver prioritized lists of the most critical vulnerabilities to each responsible system administrator along with risk scores that compare the effectiveness of system administrators and departments in reducing risk. Use a SCAP– validated vulnerability scanner that looks for both code–based vulnerabilities (such as those described by Common Vulnerabilities and Exposures entries) and configuration–based vulnerabilities (as enumerated by the Common Configuration Enumeration Project).
CSC 4–2: Correlate event logs with information from vulnerability scans to fulfill two goals. First, personnel should verify that the activity of the regular vulnerability scanning tools themselves is logged. Second, personnel should be able to correlate attack detection events with earlier vulnerability scanning results to determine whether the given exploit was used against a target known to be vulnerable.
CSC 4–3: Perform vulnerability scanning in authenticated mode either with agents running locally on each end system to analyze the security configuration or with remote scanners that are given administrative rights on the system being tested. Use a dedicated account for authenticated vulnerability scans, which should not be used for any other administrative activities and should be tied to specific machines at specific IP addresses. Ensure that only authorized employees have access to the vulnerability management user interface and that roles are applied to each user.
CSC 4–4: Subscribe to vulnerability intelligence services in order to stay aware of emerging exposures, and use the information gained from this subscription to update the organization’s vulnerability scanning activities on at least a monthly basis. Alternatively, ensure that the vulnerability scanning tools you use are regularly updated with all relevant important security vulnerabilities.
CSC 4–5: Deploy automated patch management tools and software update tools for operating system and software/applications on all systems for which such tools are available and safe. Patches should be applied to all systems, even systems that are properly air gapped.
CSC 4–6: Carefully monitor logs associated with any scanning activity and associated administrator accounts to ensure that all scanning activity and associated access via the privileged account is limited to the timeframes of legitimate scans.
CSC 4–7: Compare the results from back–to–back vulnerability scans to verify that vulnerabilities were addressed either by patching, implementing a compensating control, or documenting and accepting a reasonable business risk. Such acceptance of business risks for existing vulnerabilities should be periodically reviewed to determine if newer compensating controls or subsequent patches can address vulnerabilities that were previously accepted, or if conditions have changed, increasing the risk.
CSC 4–8: Measure the delay in patching new vulnerabilities and ensure that the delay is equal to or less than the benchmarks set forth by the organization. Alternative countermeasures should be considered if patches are not available.
CSC 4–9: Evaluate critical patches in a test environment before pushing them into production on enterprise systems. If such patches break critical business applications on test machines, the organization must devise other mitigating controls that block exploitation on systems where the patch cannot be deployed because of its impact on business functionality.
CSC 4–10: Establish a process to risk–rate vulnerabilities based on the exploitability and potential impact of the vulnerability, and segmented by appropriate groups of assets (example, DMZ servers, internal network servers, desktops, laptops). Apply patches for the riskiest vulnerabilities first. A phased rollout can be used to minimize the impact to the organization. Establish expected patching timelines based on the risk rating level.
5. Malware Defenses
Control the installation, spread and execution of malicious code at multiple points in the enterprise, while optimizing the use of automation to enable rapid updating of defense, data gathering and corrective action.
Malicious software is an integral and dangerous aspect of Internet threats, and can be designed to attack your systems, devices, or your data. It can be fast–moving, fast– changing, and enter through any number of points like end–user devices, e–mail attachments, web pages, cloud services, user actions, and removable media. Modern malware can be designed to avoid defenses, or to attack or disable them.
CSC 5–1: Employ automated tools to continuously monitor workstations, servers, and mobile devices with anti–virus, anti–spyware, personal firewalls, and host–based IPS functionality. All malware detection events should be sent to enterprise anti–malware administration tools and event log servers.
CSC 5–2: Employ anti–malware software that offers a remote, cloud– based centralized infrastructure that compiles information on file reputations or have administrators manually push updates to all machines. After applying an update, automated systems should verify that each system has received its signature update.
CSC 5–3: Configure laptops, workstations, and servers so that they will not auto–run content from removable media, like USB tokens (i.e., “thumb drives”), USB hard drives, CDs/DVDs, FireWire devices, external serial advanced technology attachment devices, and mounted network shares,.
CSC 5–4: Configure systems so that they automatically conduct an anti– malware scan of removable media when inserted.
CSC 5–5: Scan and block all e–mail attachments entering the organization’s e–mail gateway if they contain malicious code or file types that are unnecessary for the organization’s business. This scanning should be done before the e–mail is placed in the user’s inbox. This includes e–mail content filtering and web content filtering.
CSC 5–6: Enable anti–exploitation features such as Data Execution Prevention (DEP), Address Space Layout Randomization (ASLR), virtualization/containerization, etc. For increased protection, deploy capabilities such as Enhanced Mitigation Experience Toolkit (EMET) that can be configured to apply these protections to a broader set of applications and executables.
CSC 5–7: Limit use of external devices to those that have a business need. Monitor for use and attempted use of external devices.
CSC 5–8: Ensure that automated monitoring tools use behavior–based anomaly detection to complement traditional signature–based detection.
CSC 5–9: Use network–based anti–malware tools to identify executables in all network traffic and use techniques other than signature– based detection to identify and filter out malicious content before it arrives at the endpoint.
CSC 5–10Implement an incident response process that allows the IT support organization to supply the security team with samples of malware running on corporate systems that do not appear to be recognized by the enterprise’s anti–malware software. Samples should be provided to the security vendor for “out–of–band” signature creation and later deployed to the enterprise by system administrators.
CSC 5–11: Enable domain name system (DNS) query logging to detect hostname lookup for known malicious C2 domains.
6. Application Software Security
Manage the security lifecycle of all in house developed and acquired software in order to prevent, detect and correct security weaknesses.
Attacks often take advantage of vulnerabilities found in web–based and other application software. Vulnerabilities can be present for many reasons, including coding mistakes, logic errors, incomplete requirements, and failure to test for unusual or unexpected conditions. Examples of specific errors include: the failure to check the size of user input; failure to filter out unneeded but potentially malicious character sequences from input streams; failure to initialize and clear variables; and poor memory management allowing flaws in one part of the software to affect unrelated (and more security critical) portions. There is a flood of public and private information about such vulnerabilities available to attackers and defenders alike, as well as a robust marketplace for tools and techniques to allow “weaponization” of vulnerabilities into exploits. Attackers can inject specific exploits, including buffer overflows, SQL injection attacks, cross–site scripting, cross–site request forgery, and click–jacking of code to gain control over vulnerable machines. In one attack, more than 1 million web servers were exploited and turned into infection engines for visitors to those sites using SQL injection. During that attack, trusted websites from state governments and other organizations compromised by attackers were used to infect hundreds of thousands of browsers that accessed those websites. Many more web and non–web application vulnerabilities are discovered on a regular basis.
CSC 6–1: For all acquired application software, check that the version you are using is still supported by the vendor. If not, update to the most current version and install all relevant patches and vendor security recommendations.
CSC 6–2: Protect web applications by deploying web application firewalls (WAFs) that inspect all traffic flowing to the web application for common web application attacks, including but not limited to cross–site scripting, SQL injection, command injection, and directory traversal attacks. For applications that are not web–based, specific application firewalls should be deployed if such tools are available for the given application type. If the traffic is encrypted, the device should either sit behind the encryption or be capable of decrypting the traffic prior to analysis. If neither option is appropriate, a host–based web application firewall should be deployed.
CSC 6–3: For in–house developed software, ensure that explicit error checking is performed and documented for all input, including for size, data type, and acceptable ranges or formats.
CSC 6–4: Test in–house–developed and third–party–procured web applications for common security weaknesses using automated remote web application scanners prior to deployment, whenever updates are made to the application, and on a regular recurring basis. Include tests for application behavior under denial–of–service or resource exhaustion attacks.
CSC 6–5: Do not display system error messages to end–users (output sanitization).
CSC 6–6: Maintain separate environments for production and nonproduction systems. Developers should not typically have unmonitored access to production environments.
CSC 6–7: Test in–house–developed web and other application software for coding errors and potential vulnerabilities prior to deployment using automated static code analysis software, as well as manual testing and inspection. In particular, input validation and output encoding routines of application software should be reviewed and tested.
CSC 6–8: For acquired application software, examine the product security process of the vendor (history of vulnerabilities, customer notification, patching/remediation) as part of the overall enterprise risk management process.
CSC 6–9: For applications that rely on a database, use standard hardening configuration templates. All systems that are part of critical business processes should also be tested.
CSC 6–10Ensure that all software development personnel receive training in writing secure code for their specific development environment.
CSC 6–11: For in–house developed applications, ensure that development artifacts (sample data and scripts; unused libraries, components, debug code; or tools) are not included in the deployed software, or accessible in the production environment.
7. Wireless Access Control
The processes and tools used to track/control/prevent/correct the security use of wireless local area networks (LANS), access points and wireless client systems.
Major thefts of data have been initiated by attackers who have gained wireless access to organizations from outside the physical building, bypassing organizations’ security perimeters by connecting wirelessly to access points inside the organization. Wireless clients accompanying traveling officials are infected on a regular basis through remote exploitation during air travel or in cyber cafes. Such exploited systems are then used as back doors when they are reconnected to the network of a target organization. Still other organizations have reported the discovery of unauthorized wireless access points on their networks, planted and sometimes hidden for unrestricted access to an internal network. Because they do not require direct physical connections, wireless devices are a convenient vector for attackers to maintain long–term access into a target environment.
CSC 7–1: Ensure that each wireless device connected to the network matches an authorized configuration and security profile, with a documented owner of the connection and a defined business need. Organizations should deny access to those wireless devices that do not have such a configuration and profile.
CSC 7–2: Configure network vulnerability scanning tools to detect wireless access points connected to the wired network. Identified devices should be reconciled against a list of authorized wireless access points. Unauthorized (i.e., rogue) access points should be deactivated.
CSC 7–3: Use wireless intrusion detection systems (WIDS) to identify rogue wireless devices and detect attack attempts and successful compromises. In addition to WIDS, all wireless traffic should be monitored by WIDS as traffic passes into the wired network.
CSC 7–4: Where a specific business need for wireless access has been identified, configure wireless access on client machines to allow access only to authorized wireless networks.
CSC 7–5: For devices that do not have an essential wireless business purpose, disable wireless access in the hardware configuration (basic input/output system or extensible firmware interface), with password protections to lower the possibility that the user will override such configurations.
CSC 7–6: Ensure that all wireless traffic leverages at least Advanced Encryption Standard (AES) encryption used with at least Wi– Fi Protected Access 2 (WPA2) protection.
CSC 7–7: Ensure that wireless networks use authentication protocols such as Extensible Authentication Protocol–Transport Layer Security (EAP/TLS), which provide credential protection and mutual authentication.
CSC 7–8: Disable peer–to–peer wireless network capabilities on wireless clients, unless such functionality meets a documented business need.
CSC 7–9: Disable wireless peripheral access of devices (such as Bluetooth), unless such access is required for a documented business need.
CSC 7–10Create separate virtual local area networks (VLANs) for BYOD systems or other untrusted devices. Internet access from this VLAN should go through at least the same border as corporate traffic. Enterprise access from this VLAN should be treated as untrusted and filtered and audited accordingly.
8. Data Recovery Capability
The processes and tools used to properly back up critical information with a proven methodology for timely recovery of it.
CSC 8–1: Ensure that each system is automatically backed up on at least a weekly basis, and more often for systems storing sensitive information. To help ensure the ability to rapidly restore a system from backup, the operating system, application software, and data on a machine should each be included in the overall backup procedure. These three components of a system do not have to be included in the same backup file or use the same backup software. There should be multiple backups over time, so that in the event of malware infection, restoration can be from a version that is believed to predate the original infection. All backup policies should be compliant with any regulatory or official requirements.
CSC 8–2: Test data on backup media on a regular basis by performing a data restoration process to ensure that the backup is properly working.
CSC 8–3: Ensure that backups are properly protected via physical security or encryption when they are stored, as well as when they are moved across the network. This includes remote backups and cloud services.
CSC 8–4: Ensure that key systems have at least one backup destination that is not continuously addressable through operating system calls. This will mitigate the risk of attacks like CryptoLocker which seek to encrypt or damage data on all addressable data shares, including backup destinations.
9. Security Skills Assessment and Appropriate Training to Fill Gaps
For all functional roles in the organization prioritizing those mission critical to the business and its security), identify the specific knowledge, skills and abilities needed to support defense of the enterprise; develop and execute an integrated plan to assess, identify gaps and remediate through policy, organizational planning, training and awareness programs.
It is tempting to think of cyber defense primarily as a technical challenge, but the actions of people also play a critical part in the success or failure of an enterprise. People fulfill important functions at every stage of system design, implementation, operation, use, and oversight. Examples include: the actions of end users (who can fall prey to social engineering schemes such as phishing); IT operations (who may not recognize the security implications of IT artifacts and logs); security analysts (who struggle to keep up with an explosion of new information); system developers and programmers (who don’t understand the opportunity to resolve root cause vulnerabilities early in the system life–cycle); and executives and system owners (who struggle to quantify the role that cybersecurity plays in overall operational/mission risk, and have no reasonable way to make relevant investment decisions).
Attackers are very conscious of these issues and use them to plan their exploitations by, for example: carefully crafting phishing messages that look like routine and expected traffic to an unwary user; exploiting the gaps or seams between policy and technology (e.g., policies that have no technical enforcement); working within the time window of patching or log review; using nominally non–security–critical systems as jump points or bots.
No cyber defense approach can begin to address cyber risk without a means to address this fundamental vulnerability. Conversely, empowering people with good cyber defense habits can significantly increase readiness.
CSC 9–1: Perform gap analysis to see which skills employees need and which behaviors employees are not adhering to, using this information to build a baseline training and awareness roadmap for all employees.
CSC 9–2: Deliver training to fill the skills gap. If possible, use more senior staff to deliver the training. A second option is to have outside teachers provide training onsite so the examples used will be directly relevant. If you have small numbers of people to train, use training conferences or online training to fill the gaps.
CSC 9–3: Implement an online security awareness program that (1) focuses only on the methods commonly used in intrusions that can be blocked through individual action, (2) is delivered in short online modules convenient for employees (3) is updated frequently (at least annually) to represent the latest attack techniques, (4) is mandated for completion by all employees at least annually, and (5) is reliably monitored for employee completion.
CSC 9–4: Validate and improve awareness levels through periodic tests to see whether employees will click on a link from suspicious e–mail or provide sensitive information on the telephone without following appropriate procedures for authenticating a caller; targeted training should be provided to those who fall victim to the exercise.
CSC 9–5: Use security skills assessments for each of the mission–critical roles to identify skills gaps. Use hands–on, real–world examples to measure mastery. If you do not have such assessments, use one of the available online competitions that simulate real–world scenarios for each of the identified jobs in order to measure skills mastery.
10. Secure Configurations for Network Devices such as Firewalls, Routers and Switches
Establish, implement and actively manage (track, report on, correct) the security configuration of network infrastructure devices using a rigorous configuration management and change control process in order to prevent attackers from exploiting vulnerable services and settings.
As delivered from manufacturers and resellers, the default configurations for network infrastructure devices are geared for ease–of–deployment and ease–of–use – not security. Open services and ports, default accounts (including service accounts) or passwords, support for older (vulnerable) protocols, pre–installation of unneeded software; all can be exploitable in their default state.
Attackers take advantage of network devices becoming less securely configured over time as users demand exceptions for specific business needs. Sometimes the exceptions are deployed and then left undone when they are no longer applicable to the business needs. In some cases, the security risk of the exception is neither properly analyzed nor measured against the associated business need and can change over time. Attackers search for vulnerable default settings, electronic holes in firewalls, routers, and switches and use those to penetrate defenses. They exploit flaws in these devices to gain access to networks, redirect traffic on a network, and intercept information while in transmission. Through such actions, the attacker gains access to sensitive data, alters important information, or even uses a compromised machine to pose as another trusted system on the network.
CSC 10–1: Compare firewall, router, and switch configuration against standard secure configurations defined for each type of network device in use in the organization. The security configuration of such devices should be documented, reviewed, and approved by an organization change control board. Any deviations from the standard configuration or updates to the standard configuration should be documented and approved in a change control system.
CSC 10–2: All new configuration rules beyond a baseline–hardened configuration that allow traffic to flow through network security devices, such as firewalls and network–based IPS, should be documented and recorded in a configuration management system, with a specific business reason for each change, a specific individual’s name responsible for that business need, and an expected duration of the need.
CSC 10–3: Use automated tools to verify standard device configurations and detect changes. All alterations to such files should be automatically reported to security personnel.
CSC 10–4: Manage network devices using two–factor authentication and encrypted sessions.
CSC 10–5: Install the latest stable version of any security–related updates.
CSC 10–6: Manage the network infrastructure across network connections that are separated from the business use of that network, relying on separate VLANs or, preferably, on entirely different physical connectivity for management sessions for network devices.
11. Limitation and Control of Network Ports, Protocols and Services
Manage (track/control/correct) the ongoing operational use of ports, protocols and services on networked devices in order to minimize windows of vulnerability available to attackers.
Attackers search for remotely accessible network services that are vulnerable to exploitation. Common examples include poorly configured web servers, mail servers, file and print services, and domain name system (DNS) servers installed by default on a variety of different device types, often without a business need for the given service. Many software packages automatically install services and turn them on as part of the installation of the main software package without informing a user or administrator that the services have been enabled. Attackers scan for such issues and attempt to exploit these services, often attempting default user IDs and passwords or widely available exploitation code.
CSC 11–1: Ensure that only ports, protocols, and services with validated business needs are running on each system.
CSC 11–2: Apply host–based firewalls or port filtering tools on end systems, with a default–deny rule that drops all traffic except those services and ports that are explicitly allowed.
CSC 11–3: Perform automated port scans on a regular basis against all key servers and compared to a known effective baseline. If a change that is not listed on the organization’s approved baseline is discovered, an alert should be generated and reviewed.
CSC 11–4: Keep all services up to date and uninstall and remove any unnecessary components from the system.
CSC 11–5: Verify any server that is visible from the Internet or an untrusted network, and if it is not required for business purposes, move it to an internal VLAN and give it a private address.
CSC 11–6: Operate critical services on separate physical or logical host machines, such as DNS, file, mail, web, and database servers.
CSC 11–7: Place application firewalls in front of any critical servers to verify and validate the traffic going to the server. Any unauthorized services or traffic should be blocked and an alert generated.
12. Controlled Use of Administrative Privileges
The processes and tools used to track/control/prevent/correct the use, assignment and configuration of administrative privileges on computers, networks and applications.
The misuse of administrative privileges is a primary method for attackers to spread inside a target enterprise. Two very common attacker techniques take advantage of uncontrolled administrative privileges. In the first, a workstation user running as a privileged user, is fooled into opening a malicious e–mail attachment, downloading and opening a file from a malicious website, or simply surfing to a website hosting attacker content that can automatically exploit browsers. The file or exploit contains executable code that runs on the victim’s machine either automatically or by tricking the user into executing the attacker’s content. If the victim user’s account has administrative privileges, the attacker can take over the victim’s machine completely and install keystroke loggers, sniffers, and remote control software to find administrative passwords and other sensitive data. Similar attacks occur with e–mail. An administrator inadvertently opens an e–mail that contains an infected attachment and this is used to obtain a pivot point within the network that is used to attack other systems.
The second common technique used by attackers is elevation of privileges by guessing or cracking a password for an administrative user to gain access to a target machine. If administrative privileges are loosely and widely distributed, or identical to passwords used on less critical systems, the attacker has a much easier time gaining full control of systems, because there are many more accounts that can act as avenues for the attacker to compromise administrative privileges.
CSC 12–1: Minimize administrative privileges and only use administrative accounts when they are required. Implement focused auditing on the use of administrative privileged functions and monitor for anomalous behavior.
CSC 12–2: Use automated tools to inventory all administrative accounts and validate that each person with administrative privileges on desktops, laptops, and servers is authorized by a senior executive.
CSC 12–3: Configure all administrative passwords to be complex and contain letters, numbers, and special characters intermixed, and with no dictionary words present in the password. Pass phrases containing multiple dictionary words, along with special characters, are acceptable if they are of a reasonable length.
CSC 12–4: Before deploying any new devices in a networked environment, change all default passwords for applications, operating systems, routers, firewalls, wireless access points, and other systems to have values consistent with administration–level accounts.
CSC 12–5: Ensure that all service accounts have long and difficult– to–guess passwords that are changed on a periodic basis, as is done for traditional user and administrative passwords.
CSC 12–6: Passwords should be hashed or encrypted in storage. Passwords that are hashed should be salted and follow guidance provided in NIST SP 800–132 or similar guidance. Files containing these encrypted or hashed passwords required for systems to authenticate users should be readable only with super–user privileges.
CSC 12–7: Utilize access control lists to ensure that administrative accounts are used only for system administration activities, and not for reading e–mail, composing documents, or surfing the Internet. Web browsers and e–mail clients especially must be configured to never run as administrator.
CSC 12–8: Through policy and user awareness, require that administrators establish unique, different passwords for their administrative and non–administrative accounts. Each person requiring administrative access should be given his/her own separate account. Users should only use the Windows “administrator” or UNIX “root” accounts in emergency situations. Domain administration accounts should be used when required for system administration instead of local administrative accounts.
CSC 12–9: Configure operating systems so that passwords cannot be re–used within a timeframe of six months.
CSC 12–10Configure systems to issue a log entry and alert when an account is added to or removed from a domain administrators’ group, or when a new local administrator account is added on a system.
CSC 12–11: Configure systems to issue a log entry and alert when unsuccessful login to an administrative account is attempted.
CSC 12–12: Use multifactor authentication for all administrative access, including domain administrative access. Multi– factor authentication can include a variety of techniques, to include the use of smart cards with certificates, One Time Password (OTP) tokens, and biometrics.
CSC 12–13: When using certificates to enable multi–factor certificate–based authentication, ensure that the private keys are protected using strong passwords or are stored in trusted, secure hardware tokens.
CSC 12–14: Block access to a machine (either remotely or locally) for administrator–level accounts. Instead, administrators should be required to access a system using a fully logged and non–administrative account. Then, once logged on to the machine without administrative privileges, the administrator should transition to administrative privileges using tools such as Sudo on Linux/UNIX, RunAs on Windows, and other similar facilities for other types of systems. Users would use their own administrative accounts and enter a password each time that is different than their user account.
13. Boundary Defense
Detect/prevent/correct the flow of information transferring networks of different trust levels with a focus on security damaging data.
Attackers focus on exploiting systems that they can reach across the Internet, including not only DMZ systems but also workstation and laptop computers that pull content from the Internet through network boundaries. Threats such as organized crime groups and nation–states use configuration and architectural weaknesses found on perimeter systems, network devices, and Internet–accessing client machines to gain initial access into an organization. Then, with a base of operations on these machines, attackers often pivot to get deeper inside the boundary to steal or change information or to set up a persistent presence for later attacks against internal hosts. Additionally, many attacks occur between business partner networks, sometimes referred to as extranets, as attackers hop from one organization’s network to another, exploiting vulnerable systems on extranet perimeters.
To control the flow of traffic through network borders and police content by looking for attacks and evidence of compromised machines, boundary defenses should be multi– layered, relying on firewalls, proxies, DMZ perimeter networks, and network–based IPS and IDS. It is also critical to filter both inbound and outbound traffic.
It should be noted that boundary lines between internal and external networks are diminishing as a result of increased interconnectivity within and between organizations as well as the rapid rise in deployment of wireless technologies. These blurring lines sometimes allow attackers to gain access inside networks while bypassing boundary systems. However, even with this blurring of boundaries, effective security deployments still rely on carefully configured boundary defenses that separate networks with different threat levels, sets of users, and levels of control. And despite the blurring of internal and external networks, effective multi–layered defenses of perimeter networks help lower the number of successful attacks, allowing security personnel to focus on attackers who have devised methods to bypass boundary restrictions.
CSC 13–1: Deny communications with (or limit data flow to) known malicious IP addresses (black lists), or limit access only to trusted sites (whitelists). Tests can be periodically carried out by sending packets from bogon source IP addresses (non–routable or otherwise unused IP addresses) into the network to verify that they are not transmitted through network perimeters. Lists of bogon addresses are publicly available on the Internet from various sources, and indicate a series of IP addresses that should not be used for legitimate traffic traversing the Internet.
CSC 13–2: On DMZ networks, configure monitoring systems (which may be built in to the IDS sensors or deployed as a separate technology) to record at least packet header information, and preferably full packet header and payloads of the traffic destined for or passing through the network border. This traffic should be sent to a properly configured Security Information Event Management (SIEM) or log analytics system so that events can be correlated from all devices on the network.
CSC 13–3: To lower the chance of spoofed e–mail messages, implement the Sender Policy Framework (SPF) by deploying SPF records in DNS and enabling receiver–side verification in mail servers.
CSC 13–4: Deploy network–based IDS sensors on Internet and extranet DMZ systems and networks that look for unusual attack mechanisms and detect compromise of these systems. These network–based IDS sensors may detect attacks through the use of signatures, network behavior analysis, or other mechanisms to analyze traffic.
CSC 13–5: Network–based IPS devices should be deployed to complement IDS by blocking known bad signature or behavior of attacks. As attacks become automated, methods such as IDS typically delay the amount of time it takes for someone to react to an attack. A properly configured network–based IPS can provide automation to block bad traffic. When evaluating network–based IPS products, include those using techniques other than signature–based detection (such as virtual machine or sandbox–based approaches) for consideration.
CSC 13–6: Design and implement network perimeters so that all outgoing web, file transfer protocol (FTP), and secure shell traffic to the Internet must pass through at least one proxy on a DMZ network. The proxy should support logging individual TCP sessions; blocking specific URLs, domain names, and IP addresses to implement a black list; and applying whitelists of allowed sites that can be accessed through the proxy while blocking all other sites. Organizations should force outbound traffic to the Internet through an authenticated proxy server on the enterprise perimeter. Proxies can also be used to encrypt all traffic leaving an organization.
CSC 13–7: Require all remote login access (including VPN, dial–up, and other forms of access that allow login to internal systems) to use two–factor authentication.
CSC 13–8: All enterprise devices remotely logging into the internal network should be managed by the enterprise, with remote control of their configuration, installed software, and patch levels. For third–party devices (e.g., subcontractors/vendors), publish minimum security standards for access to the enterprise network and perform a security scan before allowing access.
CSC 13–9: Periodically scan for back–channel connections to the Internet that bypass the DMZ, including unauthorized VPN connections and dual–homed hosts connected to the enterprise network and to other networks via wireless, dial–up modems, or other mechanisms.
CSC 13–10To limit access by an insider, untrusted subcontractor/vendor, or malware spreading on an internal network, devise internal network segmentation schemes to limit traffic to only those services needed for business use across the organization’s internal network.
CSC 13–12: To minimize the impact of an attacker pivoting between compromised systems, only allow DMZ systems to communicate with private network systems via application proxies or application–aware firewalls over approved channels.
CSC 13–13: To help identify covert channels exfiltrating data through a firewall, configure the built–in firewall session tracking mechanisms included in many commercial firewalls to identify TCP sessions that last an unusually long time for the given organization and firewall device, alerting personnel about the source and destination addresses associated with these long sessions.
CSC 13–14: Deploy NetFlow collection and analysis to DMZ network flows to detect anomalous activity.
14. Maintenance, Monitoring and Analysis of Audit Logs
Collect, manage and analyses audit logs of events that could help detect, understand or recover from an attack.
Deficiencies in security logging and analysis allow attackers to hide their location, malicious software, and activities on victim machines. Even if the victims know that their systems have been compromised, without protected and complete logging records they are blind to the details of the attack and to subsequent actions taken by the attackers. Without solid audit logs, an attack may go unnoticed indefinitely and the particular damages done may be irreversible.
Sometimes logging records are the only evidence of a successful attack. Many organizations keep audit records for compliance purposes, but attackers rely on the fact that such organizations rarely look at the audit logs, so they do not know that their systems have been compromised. Because of poor or nonexistent log analysis processes, attackers sometimes control victim machines for months or years without anyone in the target organization knowing, even though the evidence of the attack has been recorded in unexamined log files.
CSC 14–1: Include at least two synchronized time sources (i.e., Network Time Protocol – NTP) from which all servers and network equipment retrieve time information on a regular basis so that timestamps in logs are consistent, and are set to UTC (Coordinate Universal Time).
CSC 14–2: Validate audit log settings for each hardware device and the software installed on it, ensuring that logs include a date, timestamp, source addresses, destination addresses, and various other useful elements of each packet and/or transaction. Systems should record logs in a standardized format such as syslog entries or those outlined by the Common Event Expression initiative. If systems cannot generate logs in a standardized format, log normalization tools can be deployed to convert logs into such a format.
CSC 14–3: Ensure that all systems that store logs have adequate storage space for the logs generated on a regular basis, so that log files will not fill up between log rotation intervals. The logs must be archived and digitally signed on a periodic basis.
CSC 14–4: Develop a log retention policy to make sure that the logs are kept for a sufficient period of time. Organizations are often compromised for several months without detection. The logs must be kept for a longer period of time than it takes an organization to detect an attack so they can accurately determine what occurred.
CSC 14–5: Have security personnel and/or system administrators run biweekly reports that identify anomalies in logs. They should then actively review the anomalies, documenting their findings.
CSC 14–6: Configure network boundary devices, including firewalls, network–based IPS, and inbound and outbound proxies, to verbosely log all traffic (both allowed and blocked) arriving at the device.
CSC 14–7: For all servers, ensure that logs are written to write–only devices or to dedicated logging servers running on separate machines from the hosts generating the event logs, lowering the chance that an attacker can manipulate logs stored locally on compromised machines.
CSC 14–8: Deploy a SIEM (Security Incident and Event Management) or log analytic tools for log aggregation and consolidation from multiple machines and for log correlation and analysis. Using the SIEM tool, system administrators and security personnel should devise profiles of common events from given systems so that they can tune detection to focus on unusual activity, avoid false positives, more rapidly identify anomalies, and prevent overwhelming analysts with insignificant alerts.
CSC 14–9: Monitor for service creation events and enable process tracking logs. On Windows systems, many attackers use PsExec functionality to spread from system to system. Creation of a service is an unusual event and should be monitored closely. Process tracking is valuable for incident handling.
CSC 14–10Ensure that the log collection system does not lose events during peak activity, and that the system detects and alerts if event loss occurs (such as when volume exceeds the capacity of a log collection system). This includes ensuring that the log collection system can accommodate intermittent or restricted–bandwidth connectivity through the use of handshaking / flow control.
15. Control Access Based on the Need to Know
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.
Some organizations do not carefully identify and separate their most sensitive and critical assets from less sensitive, publicly accessible information on their internal networks. In many environments, internal users have access to all or most of the critical assets. Sensitive assets may also include systems that provide management and control of physical systems (e.g., SCADA). Once attackers have penetrated such a network, they can easily find and exfiltrate important information, cause physical damage, or disrupt operations with little resistance. For example, in several high–profile breaches over the past two years, attackers were able to gain access to sensitive data stored on the same servers with the same level of access as far less important data. There are also examples of using access to the corporate network to gain access to, then control over, physical assets and cause damage.
CSC 15–1: Locate any sensitive information on separated VLANS with firewall filtering. All communication of sensitive information over less–trusted networks should be encrypted.
CSC 15–3: Enforce detailed audit logging for access to nonpublic data and special authentication for sensitive data.
CSC 15–4: Segment the network based on the trust levels of the information stored on the servers. Whenever information flows over a network with a lower trust level, the information should be encrypted.
CSC 15–5: Use host–based data loss prevention (DLP) to enforce ACLs even when data is copied off a server. In most organizations, access to the data is controlled by ACLs that are implemented on the server. Once the data have been copied to a desktop system, the ACLs are no longer enforced and the users can send the data to whomever they want.
16. Account Monitoring and Control
Actively manage the lifecycle of system and application accounts, their creation, use, dormancy, deletion in order to minimize opportunities for attackers to leverage them.
Attackers frequently discover and exploit legitimate but inactive user accounts to impersonate legitimate users, thereby making discovery of attacker behavior difficult for network watchers. Accounts of contractors and employees who have been terminated and accounts formerly set up for Red Team testing (but not deleted afterwards) have often been misused in this way. Additionally, some malicious insiders or former employees have accessed accounts left behind in a system long after contract expiration, maintaining their access to an organization’s computing system and sensitive data for unauthorized and sometimes malicious purposes.
CSC 16–1: Review all system accounts and disable any account that cannot be associated with a business process and owner.
CSC 16–2: Ensure that all accounts have an expiration date associated with the account.
CSC 16–3: Ensure that systems automatically create a report that includes a list of locked–out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire. This list should be sent to the associated system administrator in a secure fashion.
CSC 16–4: Establish and follow a process for revoking system access by disabling accounts immediately upon termination of an employee or contractor. Disabling instead of deleting accounts allows preservation of audit trails.
CSC 16–5: Regularly monitor the use of all accounts, automatically logging off users after a standard period of inactivity.
CSC 16–6: Configure screen locks on systems to limit access to unattended workstations.
CSC 16–7: Monitor account usage to determine dormant accounts, notifying the user or user’s manager. Disable such accounts if not needed, or document and monitor exceptions (e.g., vendor maintenance accounts needed for system recovery or continuity operations).
CSC 16–8: Require that all non–administrator accounts have strong passwords that contain letters, numbers, and special characters, be changed at least every 90 days, have a minimal age of one day, and not be allowed to use the previous 15 passwords as a new password. These values can be adjusted based on the specific business needs of the organization.
CSC 16–9: Use and configure account lockouts such that after a set number of failed login attempts the account is locked for a standard period of time.
CSC 16–10Require that managers match active employees and contractors with each account belonging to their managed staff. Security or system administrators should then disable accounts that are not assigned to active employees or contractors.
CSC 16–11: Monitor attempts to access deactivated accounts through audit logging.
CSC 16–12: Configure access for all accounts through a centralized point of authentication, for example Active Directory or LDAP. Configure network and security devices for centralized authentication as well.
CSC 16–13: Profile each user’s typical account usage by determining normal time–of–day access and access duration. Reports should be generated that indicate users who have logged in during unusual hours or have exceeded their normal login duration. This includes flagging the use of the user’s credentials from a computer other than computers on which the user generally works.
CSC 16–14: Require multi–factor authentication for accounts that have access to sensitive data or systems. Multi–factor authentication can be achieved using Smart cards with certificates, One Time Password (OTP) tokens, or biometrics.
CSC 16–15: For authenticated access to web services within an enterprise, ensure that account usernames and passwords are passed over an encrypted channel and associated password hash files are stored securely if a centralized service is not employed.
CSC 16–16: Configure all systems to use encrypted channels for the transmission of passwords over a network.
CSC 16–17: Verify that all password files are encrypted or hashed and that these files cannot be accessed without root or administrator privileges. Audit all access to password files in the system.
17. Data Protection
The processes and tools used to prevent data exfiltration, mitigate the effects of infiltrated data and ensure the privacy and integrity of sensitive information.
Data resides in many places. Protection of that data is best achieved through the application of a combination of encryption, integrity protection and data loss prevention techniques. As organizations continue their move towards cloud computing and mobile access, it is important that proper care be taken to limit and report on data exfiltration while also mitigating the effects of data compromise.
The adoption of data encryption, both in transit and at rest, provides mitigation against data compromise. This is true if proper care has been taken in the processes and technologies associated with the encryption operations. An example of this is the management of cryptographic keys used by the various algorithms that protect data. The process for generation, use and destruction of keys should be based on proven processes as defined in standards such as NIST SP 800–57.
Care should also be taken to ensure that products used within an enterprise implement well known and vetted cryptographic algorithms, as identified by NIST. Re–evaluation of the algorithms and key sizes used within the enterprise on an annual basis is also recommended to ensure that organizations are not falling behind in the strength of protection applied to their data.
For organizations that are moving data to the cloud, it is important for organizations to understand the security controls applied to data in the cloud multi–tenant environment, and determine the best course of action for application of encryption controls and security of keys. When possible, keys should be stored within secure containers such as Hardware Security Modules (HSMs).
Encrypting data provides a level of assurance that even if data is compromised, it is impractical to access the plaintext without significant resources, however controls should also be put in place to mitigate the threat of data exfiltration in the first place. Many attacks occurred across the network, while others involved physical theft of laptops and other equipment holding sensitive information. Yet, in most cases, the victims were not aware that the sensitive data were leaving their systems because they were not monitoring data outflows. The movement of data across network boundaries both electronically and physically must be carefully scrutinized to minimize its exposure to attackers.
The loss of control over protected or sensitive data by organizations is a serious threat to business operations and a potential threat to national security. While some data are leaked or lost as a result of theft or espionage, the vast majority of these problems result from poorly understood data practices, a lack of effective policy architectures, and user error. Data loss can even occur as a result of legitimate activities such as e– Discovery during litigation, particularly when records retention practices are ineffective or nonexistent.
Data loss prevention (DLP) refers to a comprehensive approach covering people, processes, and systems that identify, monitor, and protect data in use (e.g., endpoint actions), data in motion (e.g., network actions), and data at rest (e.g., data storage) through deep content inspection and with a centralized management framework. Over the last several years, there has been a noticeable shift in attention and investment from securing the network to securing systems within the network, and to securing the data itself. DLP controls are based on policy, and include classifying sensitive data, discovering that data across an enterprise, enforcing controls, and reporting and auditing to ensure policy compliance.
CSC 17–1: Deploy approved hard drive encryption software to mobile devices and systems that hold sensitive data.
CSC 17–2: Verify that cryptographic devices and software are configured to use publicly–vetted algorithms.
CSC 17–3: Perform an assessment of data to identify sensitive information that requires the application of encryption and integrity controls
CSC 17–4: Review cloud provider security practices for data protection.
CSC 17–5: Deploy an automated tool on network perimeters that monitors for certain sensitive information (i.e., personally identifiable information), keywords, and other document characteristics to discover unauthorized attempts to exfiltrate data across network boundaries and block such transfers while alerting information security personnel.
CSC 17–6: Conduct periodic scans of server machines using automated tools to determine whether sensitive data (i.e., personally identifiable information, health, credit card, and classified information) is present on the system in clear text. These tools, which search for patterns that indicate the presence of sensitive information, can help identify if a business or technical process is leaving behind or otherwise leaking sensitive information.
CSC 17–7: Move data between networks using secure,authenticated, and encrypted mechanisms.
CSC 17–8: If there is no business need for supporting such devices, configure systems so that they will not write data to USB tokens or USB hard drives. If such devices are required, enterprise software should be used that can configure systems to allow only specific USB devices (based on serial number or other unique property) to be accessed, and that can automatically encrypt all data placed on such devices. An inventory of all authorized devices must be maintained.
CSC 17–9: Use network–based DLP solutions to monitor and control the flow of data within the network. Any anomalies that exceed the normal traffic patterns should be noted and appropriate action taken to address them.
CSC 17–10Only allow approved Certificate Authorities (CAs) to issue certificates within the enterprise; Review and verify each CAs Certificate Practices Statement (CPS) and Certificate Policy (CP).
CSC 17–11: Perform an annual review of algorithms and key lengths in use for protection of sensitive data.
CSC 17–12: Monitor all traffic leaving the organization and detect any unauthorized use of encryption. Attackers often use an encrypted channel to bypass network security devices. Therefore it is essential that organizations be able to detect rogue connections, terminate the connection, and remediate the infected system.
CSC 17–13: Block access to known file transfer and e–mail exfiltration websites.
CSC 17–14: Define roles and responsibilities related to management of encryption keys within the enterprise; define processes for lifecycle.
CSC 17–15: Where applicable, implement Hardware Security Modules (HSMs) for protection of private keys (e.g., for sub CAs) or Key Encryption Keys.
18. Incident Response and Management
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.
Cyber incidents are now just part of our way of life. Even large, well–funded, and technically sophisticated enterprises struggle to keep up with the frequency and complexity of attacks. The question of a successful cyber–attack against an enterprise is not “if” but “when”.
When an incident occurs, it is too late to develop the right procedures, reporting, data collection, management responsibility, legal protocols, and communications strategy that will allow the enterprise to successfully understand, manage, and recover. Without an incident response plan, an organization may not discover an attack in the first place, or, if the attack is detected, the organization may not follow good procedures to contain damage, eradicate the attacker’s presence, and recover in a secure fashion. Thus, the attacker may have a far greater impact, causing more damage, infecting more systems, and possibly exfiltrate more sensitive data than would otherwise be possible were an effective incident response plan in place.
CSC 18–1: Ensure that there are written incident response procedures that include a definition of personnel roles for handling incidents. The procedures should define the phases of incident handling.
CSC 18–2: Assign job titles and duties for handling computer and network incidents to specific individuals.
CSC 18–3: Define management personnel who will support the incident handling process by acting in key decision–making roles.
CSC 18–4: Devise organization–wide standards for the time required for system administrators and other personnel to report anomalous events to the incident handling team, the mechanisms for such reporting, and the kind of information that should be included in the incident notification. This reporting should also include notifying the appropriate Community Emergency Response Team in accordance with all legal or regulatory requirements for involving that organization in computer incidents.
CSC 18–5: Assemble and maintain information on third–party contact information to be used to report a security incident (i.e., maintain an e–mail address of [email protected] or have a web page http://organization.com/security).
CSC 18–6: Publish information for all personnel, including employees and contractors, regarding reporting computer anomalies and incidents to the incident handling team. Such information should be included in routine employee awareness activities.
CSC 18–7: Conduct periodic incident scenario sessions for personnel associated with the incident handling team to ensure that they understand current threats and risks, as well as their responsibilities in supporting the incident handling team.
19. Secure Network Engineering
Make security an inherent attribute of the enterprise by specifying, designing, and building in features that allow high confidence systems operations while denying or minimizing opportunities for attackers.
System or security designers rarely get to start from scratch and build in all of the security features they might want. And even if they did, systems constantly evolve, new business imperatives appear, attackers develop new techniques, and new technologies emerge to complicate the security problem. In such an environment, attackers take advantage of missing security features, time gaps in deploying new defenses or moving information, and the “seams” between defensive controls. Defenders are quickly overwhelmed with new operational requirements, managing tools and changes, new information, and “fire– fighting”.
CSC 19–1: Design the network using a minimum of a three–tier architecture (DMZ, middleware, and private network). Any system accessible from the Internet should be on the DMZ, but DMZ systems should never contain sensitive data. Any system with sensitive data should reside on the private network and never be directly accessible from the Internet. DMZ systems should communicate with private network systems through an application proxy residing on the middleware tier.
CSC 19–3: Deploy domain name systems (DNS) in a hierarchical, structured fashion, with all internal network client machines configured to send requests to intranet DNS servers, not to DNS servers located on the Internet. These internal DNS servers should be configured to forward requests they cannot resolve to DNS servers located on a protected DMZ. These DMZ servers, in turn, should be the only DNS servers allowed to send requests to the Internet.
CSC 19–2: To support rapid response and shunning of detected attacks, engineer the network architecture and its corresponding systems for rapid deployment of new access control lists, rules, signatures, blocks, blackholes, and other defensive measures.
CSC 19–4: Segment the enterprise network into multiple, separate trust zones to provide more granular control of system access and additional intranet boundary defenses.
20. Penetration Tests and Red Team Exercises
Test the overall strength of an organization’s defenses (the technology, the processes, and the people) by simulating the objectives and actions of an attacker.
Attackers often exploit the gap between good defensive designs and intentions and implementation or maintenance. Examples include: the time window between announcement of a vulnerability, the availability of a vendor patch, and actual installation on every machine; well–intentioned policies which have no enforcement mechanism (especially those intended to restrict risky human actions); failure to apply good configurations and other practices to the entire enterprise, or to machines that come in– and–out of the network; and failure to understand the interaction among multiple defensive tools, or with normal system operations that have security implications.
In addition, successful defense requires a comprehensive program of technical defenses, good policy and governance, and appropriate action by people. In a complex environment where technology is constantly evolving, and new attacker tradecraft appears regularly, organizations should periodically test their defenses to identify gaps and to assess their readiness.
Penetration testing starts from the identification and assessment of vulnerabilities that can be identified in the enterprise. It complements this by designing and executing tests that demonstrate specifically how an adversary can either subvert the organization’s security goals (e.g., the protection of specific Intellectual Property) or achieve specific adversarial objectives (e.g., establishment of a covert Command and Control infrastructure). The result provides deeper insight, through demonstration, into the business risks of various vulnerabilities.
Red Team exercises take a comprehensive approach at the full spectrum of organization policies, processes, and defenses in order to improve organizational readiness, improve training for defensive practitioners, and inspect current performance levels. Independent Red Teams can provide valuable and objective insights about the existence of vulnerabilities and the efficacy of defenses and mitigating controls already in place and even of those planned for future implementation.
CSC 20–1: Conduct regular external and internal penetration tests to identify vulnerabilities and attack vectors that can be used to exploit enterprise systems successfully. Penetration testing should occur from outside the network perimeter (i.e., the Internet or wireless frequencies around an organization) as well as from within its boundaries (i.e., on the internal network) to simulate both outsider and insider attacks.
CSC 20–2: Any user or system accounts used to perform penetration testing, should be controlled and monitored to make sure they are only being used for legitimate purposes, and are removed or restored to normal function after testing is over.
CSC 20–3: Perform periodic Red Team exercises to test organizational readiness to identify and stop attacks or to respond quickly and effectively.
CSC 20–4: Include tests for the presence of unprotected system information and artifacts that would be useful to attackers, including network diagrams, configuration files, older penetration test reports, e–mails or documents containing passwords or other information critical to system operation.
CSC 20–5: Plan clear goals of the penetration test itself with blended attacks in mind, identifying the goal machine or target asset. Many APT–style attacks deploy multiple vectors—often social engineering combined with web or network exploitation. Red Team manual or automated testing that captures pivoted and multi–vector attacks offers a more realistic assessment of security posture and risk to critical assets.
CSC 20–6: Use vulnerability scanning and penetration testing tools in concert. The results of vulnerability scanning assessments should be used as a starting point to guide and focus penetration testing efforts.
CSC 20–7: Devise a scoring method for determining the results of Red Team exercises so that results can be compared over time.
CSC 20–8: Create a test bed that mimics a production environment for specific penetration tests and Red Team attacks against elements that are not typically tested in production, such as attacks against supervisory control and data acquisition and other control systems.