•  

SEC566.5: Critical Controls 16, 17, 18, 19 and 20

A session at Critical Security Controls Summit

Sunday 18th August, 2013

9:00am to 5:00pm (EST)

During day 5, we will cover Critical Controls 16, 17, 18, 19 and 20.

Critical Control 16: Account Monitoring and Control

Attackers frequently impersonate legitimate users through inactive user accounts. This method makes it difficult for network watchers to identify attackers' behavior. Although most operating systems include capabilities for logging information about account usage, these features are sometimes disabled by default. Security personnel can configure systems to record more detailed information about account access and utilize homegrown scripts or third-party log analysis tools to analyze this information. The system must be capable of identifying unauthorized user accounts when they exist on the system. To evaluate the implementation of Control 16 on a periodic basis, the evaluation team must verify that the list of locked out accounts, disabled accounts, accounts with passwords that exceed the maximum password age, and accounts with passwords that never expire has successfully been completed daily.

Critical Control 17: Data Loss Prevention

The loss of protected and sensitive data is a serious threat to business operations, and potentially, national security. While some data is leaked or lost as a result of theft or espionage, the vast majority of these problems result from poorly understood data practices. These include, but are not limited to, a lack of effective policy architectures and user error. The phrase "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. Commercial DLP solutions are available to look for exfiltration attempts and detect other suspicious activities associated with a protected network holding sensitive information. The system must be capable of identifying unauthorized datum leaving the organization's systems whether via network file transfers or removable media. To evaluate the implementation of Control 17 on a periodic basis, the evaluation team must attempt to move test datum sets (that trigger DLP systems but do not contain sensitive data) outside of the trusted computing environment via both network file transfers and via removable media.

Critical Control 18: Incident Response Capability (validated manually)

Without an incident response plan, an organization may not discover an attack in the first place. Even if the attack is detected, the organization may not follow proper procedures to contain damage, eradicate the attacker's presence, and recover in a secure fashion. Thus, the attacker may have far higher impact on the target organization, causing more damage, infecting more systems, and possibly exfiltrating more sensitive data than would otherwise be possible. After defining detailed incident response procedures, the incident response team should engage in periodic scenario-based training. This includes, but is not limited to, working through a series of attack scenarios that are fine-tuned to the threats and vulnerabilities the organization faces.

Critical Control 19: Secure Network Engineering (validated manually)

Security controls can be circumvented in networks that are poorly designed. Without carefully planned and properly implemented network architecture, attackers can pivot through the network to gain access to target machines. To help ensure a consistent, defensible network, the architecture of each network should be based on a template that describes the overall layout of the network and the services it provides. Organizations should prepare network diagrams for each of their networks. Network diagrams should show components such as routers, firewalls, switches, significant servers, and groups of client machines.

Critical Control 20: Penetration Tests and Red Team Exercises (validated manually)

Attackers penetrate networks and systems through social engineering and by exploiting vulnerable software and hardware. Penetration testing involves mimicking the actions of computer attackers, and exploiting them to determine what kind of access an attacker can gain. Each organization should define a clear scope and the rules of engagement for penetration testing and red team analyses. The scope of such projects should include, at least, systems with the highest value information and production processing functionality.

CPE/CMU Credits: 6

About the speaker

This person is speaking at this event.
Dr. Eric Cole

Dr. Cole- cyber security professional, instructor, keynote speaker & expert witness. He is a senior fellow with SANS & security consultant. bio from Twitter

Sign in to add slides, notes or videos to this session

Tell your friends!

When

Time 9:00am5:00pm EST

Date Sun 18th August 2013

Short URL

lanyrd.com/scddhw

Official event site

www.sans.org/info/124742

View the schedule

Share

See something wrong?

Report an issue with this session