Monday, June 27, 2016

Mike Thorne's Bibliography - Great security resource

Appendix A        References and Resources

The following documents were used in the development of this <paper-type>.
Many publications in this appendix can also be found in these electronic libraries:                                         Bit9 eBooks                                 CJCS Directives, Guides, Instructions, and Manuals              CNSS Instructions                                                  Department of the Navy Issuances                                                                     Defense Technical Information Center                                                  DoD Issuances                              DoD Special Reports; Select Cyber Strategy                                                               Industrial Control Systems Cyber Emergency Response Team                                                        MIT Lincoln Laboratory Mission Areas; Select Cyber Security                                                     MITRE Publications                           Navy Cyber Forces – Handbook and Readiness Manual           COMNAVCYBERFORINST 5239.2B provided URLs for
                                                                                                            both USFF and NCDOC
UNCLAS:                                            NCDOC Unclassified Site
GENSER:                                   NCDOC GENSER Site                     NIST Publications                                      NIST Computer Security Division Publications                        NIST Interagency or Internal Reports                                                          SANDIA National Laboratories Documents and Programs
                                                                                                            Suggested search terms: SCADA, Cyber Incident Response,
                                                                                                            Incident Response                                                SANS Institute InfoSec Reading Room              SEI Emerging Technology Center; Select Cyber Intelligence                                U.S. Computer Emergency Readiness Team Publications           U.S. Fleet Forces Command, Navy Cyber Forces and FCC-C10F                                                      U.S. Government Accountability Office Publications

Table A1  References
Document Description
Bit9 eBook, Breach Detection: What You Need to Know – Detecting and Stopping Advanced Attacks
30 SEP 2014
Bit9 eBook, Cracking the Endpoint: Insider Tips for Endpoint Security
18 MAR 2015
Bit9 eBook, Disrupting the Threat: Identify, Respond, Contain & Recover in Seconds
28 MAY 2015
Bit9 and Monterey Technology Group, Inc. Report and Webinar, APT Confidential: 14 Lessons Learned from Real Attacks
12 JUN 2013
Black Hat USA 2014 Briefings, The State of Incident Response
By Bruce Schneier
7 AUG 2014
Black Hat USA 2015 Briefings, The Memory Sinkhole: An Architectural Privilege Escalation Vulnerability
By Christopher Dumas
An x86 architectural vulnerability allows exploitation of the most protected Ring -2, the System Management Mode (SMM) of the CPU.  Ring 3 is userland, Ring 0 is the kernel, and Ring -1 is the hypervisor.
Principle: Subsystems that are individually secure, but collectively vulnerable.
20 JUL 2015 White Paper;
5-6 AUG 2015 Briefing
Bromium Labs Report, Bypassing EMET 4.1
By Jared DeMott
24 FEB 2014
CJCSI 6510.01F, Information Assurance (IA) and Support to Computer Network Defense (CND)
Current As Of 9 JUN 2015; Issued 9 FEB 2011
CJCSM 6510.01B, Cyber Incident Handling Program
Current As Of 18 DEC 2014; Issued 10 JUL 2012
CNSSI 1253, Security Categorization and Control Selection for National Security Systems
Collateral: Overlay Attachments 1-6 are for Security, Space Platform, Cross Domain Solution, Intelligence, Classified Information, and Privacy
27 MAR 2014
COMNAVCYBERFORINST 5239.2B, Navy Cyber Forces Commander’s Cybersecurity Handbook, version 3
31 AUG 2014
COMNAVCYBERFORINST 5239.3A, Navy Cyber Forces Cybersecurity Readiness Manual, version 2
31 AUG 2014
Council on Cybersecurity and Center for Internet Security, Critical Security Controls for Effective Cyber Defense, v5.1
The actions defined by the Controls are a subset of the comprehensive catalog defined by National Institute of Standards and Technology (NIST) SP 800-53. The Controls do not attempt to replace the Comprehensive Risk Management Framework or the Framework for Improving Critical Infrastructure Cybersecurity. The Controls instead prioritize and focus on a smaller number of actionable controls with high-payoff, aiming for a "must do first" philosophy.
The Consensus Audit Guidelines Critical Security Controls were compiled by a consortium of more than 100 contributors from US government agencies, commercial forensics experts and pen testers.  Authors of the initial draft include members of:
                  US National Security Agency Red Team and Blue Team
                  US Department of Homeland Security, US-CERT
                  US DoD Computer Network Defense Architecture Group
                  US DoD Joint Task Force – Global Network Operations (JTF-GNO)
                  US DoD Defense Cyber Crime Center (DC3)
                  US Department of Energy Los Alamos National Lab, and three other National Labs.
                  US Department of State, Office of the CISO
                  US Air Force
                  US Army Research Laboratory
                  US Department of Transportation, Office of the CIO
                  US Department of Health and Human Services, Office of the CISO
                  US Government Accountability Office (GAO)
                  MITRE Corporation
                  The SANS Institute
7 OCT 2014
Cyber-1 Submarine Force Cyber-Security, Network Readiness, and Information Assurance Manual, Rev B, Commander Submarine Forces
Specifically: Chapter 9, Incident Management; Protect This Document
12 JAN 2015
DISA JIE STIG Overview V1R1, Joint Information Environment (JIE) Security Technical Implementation Guide (STIG) Overview, Version 1 Release 1
5 JUN 2015
DoD Strategy Publication
                  The DoD Cyber Strategy
                  Fact Sheet: The Department of Defense (DoD) Cyber Strategy
APR 2015
DoD Defense Science Board, Task Force Report: Resilient Military Systems and the Advanced Cyber Threat
JAN 2013
DoDD 3000.07, Irregular Warfare (IW)
28 AUG 2014
DoDD 3000.09, Autonomy in Weapon Systems
21 NOV 2012
DoDD 3115.16, The Defense Warning Network
5 DEC 2013
DoDI 5200.39, Critical Program Information (CPI) Identification and Protection Within Research, Development, Test, and Evaluation (RDT&E)
28 MAY 2015
DoDI 5200.44, Protection of Mission Critical Functions to Achieve Trusted Systems and Networks (TSN)
5 NOV 2012
DoDD 5200.47E, Anti-Tamper (AT)
4 SEP 2015
DoDD 5205.02E, DoD Operations Security (OPSEC) Program
20 JUN 2012
DoD Manual 5205.02-M, DoD Operations Security (OPSEC) Program Manual
3 NOV 2008
DoDD 5205.16, The DoD Insider Threat Program
30 SEP 2014
DoDI 5240.05, Technical Surveillance Countermeasures (TSCM)
3 APR 2014
DoDI 8410.02, NetOps for the Global Information Grid (GIG)
19 DEC 2008
DoDI 8410.03, Network Management (NM)
29 AUG 2012
DoDI 8500.01, Cybersecurity
14 MAR 2014
DoDI 8510.01, Risk Management Framework (RMF) for DoD Information Technology (IT)
12 MAR 2014
DoDI 8523.01, Communications Security (COMSEC)
22 APR 2008
DoDI 8540.01, Cross Domain (CD) Policy
8 MAY 2015
DoDI 8551.01, Ports, Protocols, and Services Management (PPSM)
28 MAY 2014
DOE Office of Electricity Delivery and Energy Reliability, National SCADA Test Bed – A Summary of Control System Security Standards Activities in the Energy Sector
OCT 2005
FIPS PUB 180-4, Secure Hash Standard (SHS)
AUG 2015
FIPS PUB 199, Standards for Security Categorization of Federal Information and Information Systems
FEB 2004
FIPS PUB 200, Minimum Security Requirements for Federal Information and Information Systems
MAR 2006
FIPS PUB 202, SHA-3 Standard: Permutation-Based Hash and Extendable-Output Functions
AUG 2015
Information Security Group Publication, Lucky Thirteen: Breaking the TLS and DTLS Record Protocols
By Nadhem J. AlFardan and Kenneth G. Paterson          Information Security Group
6 FEB 2013
(ISC)2 Training, International Information System Security Certification Consortium, Inc. Courses
MIT Lincoln Laboratory Publication, Systematic Analysis of Defenses Against Return-Oriented Programming
By R. Skowyra, K. Casteel, H. Okhravi, N. Zeldovich, and W. Streilein Boston University, MIT Lincoln Laboratory, and MIT CSAIL
Sponsored by Assistant Secretary of Defense for Research & Engineering under Air Force Contract #FA8721-05-C-0002
14 JUN 2013
MITRE Book, Ten Strategies of a World-Class Cybersecurity Operations Center, 346 pages
By Carson Zimmerman
Exceptional resource.  Donated to the public domain.
Copyright 2014
MITRE Technical Report MTR130531, Cyber Resiliency and NIST Special Publication 800-53 Rev 4 Controls
SEP 2013
NAVSEA Commander’s Intent Memo, NAVSEA Commander’s Intent for Shipboard and Selected Shore Control-Platform Information Technology Systems Cyber Readiness Improvements
4 SEP 2015
NAVSEA INTERIM Technical Publication T9070-BQ-DPC-010/402-1, Naval Control Systems Cyber Security Best Practices Manual
Additional revisions are anticipated in 2015, following 10 Jul 2015.
10 JUL 2015
NAVSEA/NAVIDFOR Symposium, Cyber Security Waterfront Symposium 2015
JUL 2015
NIST SP 800-30 Rev 1, Guide for Conducting Risk Assessments
SEP 2012
NIST SP 800-34 Rev1, Contingency Planning Guide for Federal Information Systems
MAY 2010
NIST SP 800-37 Rev 1, Guide for Applying the Risk Management Framework to Federal Information Systems: A Security Life Cycle Approach
FEB 2010 with Updates Through JUN 2014
NIST SP 800-39, Managing Information Security Risk: Organization, Mission, and Information System View
MAR 2011
NIST SP 800-52 Rev 1, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementations
APR 2014
NIST SP 800-53 Rev 4, Security and Privacy Controls for Federal Information Systems and Organizations
APR 2013 with Updates Through JAN 2015
NIST SP 800-53A Rev 4, Assessing Security and Privacy Controls in Federal Information Systems and Organizations
DEC 2014
NIST SP 800-59, Guideline for Identifying an Information System as a National Security System
AUG 2003
NIST SP 800-60 Rev 1, Guide for Mapping Types of Information and Information Systems to Security Categories Volumes 1 and 2
AUG 2008
NIST SP 800-61 Rev 2, Computer Security Incident Handling Guide
AUG 2012
NIST SP 800-64 Rev 2, Security Considerations in the System Development Life Cycle
OCT 2008
NIST SP 800-70 Rev 2, National Checklist Program for IT Products – Guidelines for Checklist Users and Developers
FEB 2011
NIST SP 800-82 Rev 2, Guide to Industrial Control Systems (ICS) Security
MAY 2015
NIST SP 800-83 Rev 1, Guide to Malware Incident Prevention and Handling for Desktops and Laptops
JUL 2013
NIST SP 800-86, Guide to Integrating Forensic Techniques into Incident Response
AUG 2006
NIST SP 800-92, Guide to Computer Security Log Management
SEP 2006
NIST SP 800-126 Rev 2, The Technical Specification for the Security Content Automation Protocol (SCAP): SCAP Version 1.2
SEP 2011
NIST SP 800-128, Guide for Security-Focused Configuration Management of Information Systems
AUG 2011
NIST SP 800-137, Information Security Continuous Monitoring (ISCM) for Federal Information Systems and Organizations
SEP 2011
NISTIR 7756 Second Draft, CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Model (Second Draft)
Draft NIST Interagency Report (NISTIR) 7756, CAESARS Framework Extension: An Enterprise Continuous Monitoring Technical Reference Architecture.
This publication presents an enterprise continuous monitoring technical reference architecture that extends the framework provided by the Department of Homeland Security’s CAESARS architecture. The goal is to facilitate enterprise continuous monitoring by presenting a reference architecture that enables organizations to aggregate collected data from across a diverse set of security tools, analyze that data, perform scoring, enable user queries, and provide overall situational awareness. The model design is focused on enabling organizations to realize this capability by leveraging their existing security tools and thus avoiding complicated and resource intensive custom tool integration efforts.
JAN 2012
NISTIR 7799 (Draft), Continuous Monitoring Reference Model, Workflow, and Specifications (Draft)
Draft NIST Interagency Report (NISTIR) 7799, Continuous Monitoring Reference Model Workflow, Subsystem, and Interface Specifications.
This publication provides the technical specifications for the continuous monitoring (CM) reference model presented in NIST IR 7756. These specifications enable multi-instance CM implementations, hierarchical tiers, multi-instance dynamic querying, sensor tasking, propagation of policy, policy monitoring, and policy compliance reporting. A major focus of the specifications is on workflows that describe the coordinated operation of all subsystems and components within the model. Another focus is on subsystem specifications that enable each subsystem to play its role within the workflows. The final focus is on interface specifications that supply communication paths between subsystems. These three sets of specifications (workflows, subsystems, and interfaces) are written to be data domain agnostic, which means that they can be used for CM regardless of the data domain that is being monitored.
JAN 2012
NISTIR 7800 (Draft), Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains (Draft)
Draft NIST Interagency Report (NISTIR) 7800, Applying the Continuous Monitoring Technical Reference Model to the Asset, Configuration, and Vulnerability Management Domains.
This publication binds together the Continuous Monitoring workflows and capabilities described in NIST IR 7799 to specific data domains. It focuses on the Asset Management, Configuration and Vulnerability data domains. It leverages the Security Content Automation Protocol (SCAP) version 1.2 for configuration and vulnerability scan content, and it dictates reporting results in an SCAP-compliant format. This specification describes an overview of the approach to each of the three domains, how they bind to specific communication protocols, and how those protocols interact. It then defines the specific requirements levied upon the various capabilities of the subsystems defined in NIST IR 7799 that enable each data domain.
JAN 2012
NSS Labs, Cyber Resilience: It’s Not About the 98 Percent You Catch, It’s About the 2 Percent You Miss
By Bob Walder and Chris Morales
6 AUG 2014
SANDIA Complex Adaptive System of Systems Engineering Research Domain, Incident Response and Recovery Prioritization, with Strategic Recovery Model Lead Andjelka Kelic  (505) 844-5266
Goal for Project: Develop an understanding of recovery and implement a model that represents infrastructure recovery under the various constraints imposed by a disaster scenario to allow for the identification of best practices and recovery prioritizations that can be used to minimize the impact of a disaster.  Evaluate the efficacy, cascading impacts, and unintended consequences of different recovery practices.
Approach: Develop CAS models of interacting infrastructure networks.  Conduct sensitivity analyses to identify conditions that increase the effectiveness of restoration and recovery by decreasing the number of post-disaster associated deaths.

6 SEP 2015 
SANDIA Position Paper for DHS Workshop on Future Directions in Cyber-Physical Systems Security, Protecting Process Control Systems Against Lifecycle Attacks Using Trust Anchors
By Adrian R. Chavez
22-24 JUL 2009
SANDIA Report SAND2005-2846P, Penetration Testing of Industrial Control Systems
MAR 2005
SANDIA Report SAND2007-5792, A Threat Analysis Framework as Applied to Critical Infrastructures in the Energy Sector
SEP 2007
SANDIA Report SAND2010-4765, Assessment of Current Cybersecurity Practices in the Public Domain: Cyber Indications and Warnings Domain
SEP 2010
SANDIA Report SAND2010-4766, National Cyber Defense High Performance Computing and Analysis: Concepts, Planning and Roadmap
SEP 2010
SANDIA Report SAND2012-9188, Human Dimensions in Cyber Operations – Research and Development Priorities
NOV 2012
SANS Reading Room, A Proactive Approach to Incident Response
By Jake Williams
Paper can be downloaded, but written permission is required to repost.
The author discusses three incident response maturity models: manual forensics; basic forensics; and proactive incident response.  The author shares how to plan for proactive incident response.  Proactive IR requires tools, processes, and training.  It must be actively evolved.  Integration of all tools is as important as capability.  Teams require trained and experienced staff.  Proactive IR ingredients include: adequate capacity planning; 30-60 days of packet capture data; and threat intelligence and reputation data integration from threat intelligence feeds with large member populations.
31 AUG 2015
SANS Reading Room, Detecting and Preventing Attacks Earlier in the Kill Chain
By Chris Velazquez
Paper can be downloaded, but written permission is required to repost.
Abstract: Most organizations place a strong focus on intrusion prevention technologies and not enough effort into detective technologies.  Prevention of malicious attacks is ideal, but detection is mandatory in combatting cyber threats.  Security vendors will only provide blocking signatures when there is a near zero false-positive rate.  Because of this, there are signatures that are not implemented resulting in false-negatives from one’s security devices.  This paper provides a look at tools that can be used to improve the detection of attackers at every phase of their attack.  The intelligence learned from these attacks allows one to defend against these known attack vectors.  This paper will look at a variety of open-source network IDS capabilities and other analysis tools to look at preventing and detecting attacks earlier in the cyber kill chain.
31 AUG 2015
SANS Reading Room, The Industrial Control System Cyber Kill Chain
By Michael J. Assante and Robert M. Lee
Abstract: Read this paper to gain an understanding of an adversary's campaign against ICS. The first two parts of the paper introduce the two stages of the ICS Cyber Kill Chain. The third section uses the Havex and Stuxnet case studies to demonstrate the ICS Cyber Kill Chain in action.

SANS Survey, Maturing and Specializing: Incident Response Capabilities Needed
By Alissa Torres, with Jake Williams
Conclusion: Although automation was the most commonly cited area for future IR improvement in last year’s survey, only a little progress has been made in increasing visibility through automation of endpoint and network data collection and analytics, or remediation.  This continues to be a key factor in improving IR process efficiency. As the amount of data collected from endpoints and network traffic grows, teams must move toward automation to conduct analysis and data correlation with the goal of shortening the time needed to detect and remediate incidents.
Our survey results also suggest the need for more specialized IR skills. By reducing false positive alerts and baselining endpoint and network traffic to better detect anomalies, understaffed teams will have more actionable alerts. The shortage of skilled technical staff may not have an immediate solution, but organizations can maximize the actions of existing IR team members by moving to automated detection and remediation processes.
Reports of data destruction and denial of service attacks have been covered in the media recently, and the responses from our survey participants substantiate the growing frequency of such adversary tactics. IR teams, frequently overworked and charged with constantly putting out fires, rarely have time to craft a new playbook for attacks requiring different IR processes and containment procedures. Current trends, as seen in the Sony and Las Vegas Sands Casino attacks, foreshadow what today’s IR teams will be faced with in future attacks. Anticipate, plan, test and validate response procedures for the worst attacks—because, inevitably, they are coming.
AUG 2015
SANS Training, SysAdmin, Audit, Network, Security Institute Courses
Course Families: Security, Developer, Forensics, Management, Audit, Legal, Industrial Control Systems, Special, and Hosted
Particularly helpful for this <paper-type>:
SEC 505 – Securing Windows with PowerShell and the Critical Security Controls
SEC 511 – Continuous Monitoring and Security Operations
SEC 566 – Implementing and Auditing the Critical Security Controls – In‑Depth
SECNAV M-5239.1, Department of the Navy Information Assurance Program Information Assurance Manual
NOV 2005
Still Active
OPNAVINST 5239.1C, Navy Information Assurance (IA) Program
This Instruction has much to say regarding reporting and managing incidents.
20 AUG 2008
Still Active
SECNAVINST 5239.3B, Department of the Navy Information Assurance Policy
17 JUN 2009
Still Active
SECNAVINST 5239.19, Department of the Navy Computer Network Incident Response and Reporting Requirements
18 MAR 2008
Still Active
SECNAVINST TBD – CYBERSAFE, Department of the Navy Cybersecurity Safety (CYBERSAFE) Program, Draft v0.6
Draft 22 Apr 2015; Collect Final When Released
Sentinel Labs Intelligence Report, The Case of Gyges, the Invisible Malware: Government-Grade Now in the Hands of Cybercriminals
By Udi Shamir
JUL 2014
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, Cyber Intelligence Conceptual Framework
Downloaded 10 JUL 2015
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, Cyber Intelligence Tools Reference Sheet
Downloaded 10 JUL 2015
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, Implementation Framework – Cyber Threat Prioritization
SEP 2013
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, Intelligence Methodologies Reference Sheet
Downloaded 10 JUL 2015
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, Organizational Impact (of the Cyber Threat on the Target) Fillable Template – Operations and Strategic Interests
Downloaded 10 JUL 2015
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, The State of the Practice of Cyber Intelligence
Featuring Jay McAllister and Troy Townsend, Podcast with Suzanne Miller
The Emerging Technology Center defines cyber intelligence as being the acquisition and analysis of information that is used to identify, track, and predict cyber capabilities or intentions of people, and enhance decision-making using that intelligence.
The difference between cyber security and cyber intelligence: cyber security is a lot more of ones-and-zeros analysis.  “I found a threat.  Why is that a threat to my network?”  Then, “Let’s go ahead and fix that threat.”  Cyber intelligence brings in all of the different aspects of the business to tell the story, which can then help decision-makers who are not so technically savvy.
Five core concepts:
       Define the environment – network, users, external exposure, competitors, influence domain, potential threats, what is at risk of loss?
       Gather data, internal and external – stay on top of your intelligence activities.
       Functional or technical analysis – ones-and-zeros analysis that supports the cyber-security mission.  What’s going on and how do I fix it?”
       Strategic analysis – marry the network data (that very functional data) with context from open source and multi-source kinds of data to paint a bigger picture of why somebody’s going after that data.  Who’s doing this to me and why are they doing it?”
       Reporting and feedback – communicate the strategic importance of the network activity, to the decision maker, with meaning for understanding.
Downloaded 10 JUL 2015
Software Engineering Institute’s Emerging Technology Center Cyber Intelligence Decision Making Resources, SEI Innovation Center Report: Cyber Intelligence Tradecraft Project – Summary of Key Findings
JAN 2013
Symantec Article TECH122466, Virus Removal and Troubleshooting on a Network
3 JUL 2015
Symantec Security Response, The Black Vine Cyberespionage Group v1.1
By Jon DiMaggio
28 JUL 2015

The following table, from NIST SP 800-61 Rev 2 (Computer Security Incident Handling Guide), Appendix E, outlines data exchange specifications that are applicable to incident handling.  A comment about SCAP conformance for these specifications, and component specifications, follows this table.
Asset Identification
Asset Results Format
Common Attack Pattern Enumeration and Classification
Common Configuration Enumeration
Common Event Expression
Common Platform Enumeration
Common Vulnerabilities and Exposures
Common Vulnerability Scoring System
Common Weakness Enumeration
Cyber Observable eXpression
Malware Attribute Enumeration and
Open Checklist Interactive Language
Open Vulnerability Assessment
RFC 4765
Intrusion Detection Message Exchange
Format (IDMEF)
RFC 5070
Incident Object Description Exchange
Format (IODEF)
RFC 5901
Extensions to the IODEF for Reporting
RFC 5941
Sharing Transaction Fraud Data
RFC 6545
Real-time Inter-network Defense (RID)
RFC 6546
Transport of Real-time Inter-network Defense (RID) Messages over HTTP/TLS
Security Content Automation Protocol
Extensible Configuration Checklist
Description Format
Table A2  Data Exchange Specifications Applicable to Incident Handling
(NIST SP 800-61 Rev 2, Appendix E with Current Links)

Robust and timely situation awareness and security intelligence are necessary, to improve the speed and precision of incident response.  One enabler for robust situation awareness is for sensor, analysis, presentation, and decision making tools to share common data specifications.
The Security Content Automation Protocol (SCAP) standard provides much of that common denominator for information sharing between cybersecurity tools.  The NIST SP 800-126 Rev 2 technical specification for SCAP Version 1.2 explains the relationship between many of the data exchange specifications for the table above, in this way, in Section 2, SCAP 1.2 Conformance:
The component specifications included in SCAP 1.2 are as follows:
·       Languages
§  Extensible Configuration Checklist Description Format (XCCDF) 1.2, a language for authoring security checklists/benchmarks and for reporting results of evaluating them [XCCDF]
§  Open Vulnerability and Assessment Language (OVAL) 5.10, a language for representing system configuration information, assessing machine state, and reporting assessment results [OVAL]
§  Open Checklist Interactive Language (OCIL) 2.0, a language for representing checks that collect information from people or from existing data stores made by other data collection efforts [OCIL]
·       Reporting formats
§  Asset Reporting Format (ARF) 1.1, a format for expressing the transport format of information about assets and the relationships between assets and reports [ARF]
§  Asset Identification 1.1, a format for uniquely identifying assets based on known identifiers and/or known information about the assets [AI]
·       Enumerations
§  Common Platform Enumeration (CPE) 2.3, a nomenclature and dictionary of hardware, operating systems, and applications [CPE]
§  Common Configuration Enumeration (CCE) 5, a nomenclature and dictionary of software security configurations [CCE]
§  Common Vulnerabilities and Exposures (CVE), a nomenclature and dictionary of security-related software flaws9 [CVE]
·       Measurement and scoring systems
§  Common Vulnerability Scoring System (CVSS) 2.0, a system for measuring the relative severity of software flaw vulnerabilities [CVSS]
§  Common Configuration Scoring System (CCSS) 1.0, a system for measuring the relative severity of system security configuration issues [CCSS]
·       Integrity
§  Trust Model for Security Automation Data (TMSAD) 1.0, a specification for using digital signatures in a common trust model applied to other security automation specifications [TMSAD].

Appendix B        Course Outlines of Valuable SANS Training

This appendix contains two course outlines for both their educational value (they illustrate moving parts), and their correlation with themes in this <paper-type>.  It is also desirable for key personnel to take the courses.
The following training and education are exceptionally useful for the goals of this <paper-type>.
·       SANS SEC 511     Continuous Monitoring and Security Operations
·       SANS SEC 566     Implementing and Auditing the Critical Security Controls - In-Depth
·       Book                          Ten Strategies of a World-Class Cybersecurity Operations Center, 346 pages
By Carson Zimmerman      Donated to the public domain by Zimmerman and MITRE
The Carson Zimmerman book condenses years of MITRE Corporation lessons learned in assisting  Government sponsors with computer network defense.  A concise summary of Zimmerman’s ten strategies appears in Appendix D.  The book can be downloaded for free.

Some education and training equip participants with skills, tools, and knowledge.
Sometimes they change paradigms in crucial ways.
These courses both equip and change paradigms.

It is highly recommended that representatives (perhaps one each) from Program of Record technical leadership, systems engineering leadership, and cybersecurity workforce staff attend both courses.  The courses will sharpen focus for cybersecurity practices and priorities that are particularly valuable for addressing pervasive threat actors, by engineering people, process, and technology activities toward:
·       Truly effective design, protect, detect, respond, and recover requirements implementations.
·       Efficient strategies for Program of Record and Fleet security operations with installed systems.

Continuous Monitoring and Security Operations teaches students how to lead their teams to assess, design, and defend their systems from pervasive threats.  Students learn how to design their systems in order to perform network security monitoring (data in transit, network traffic analysis) and continuous security monitoring (data at rest, vulnerability analysis, and endpoint security) in search of actionable detections of pervasive threat activity in every stage of the cyber intrusion kill chain.  The course shows students how to perform most tasks with free and open source tools, to illustrate that both free and commercial approaches can be tailored for the priorities of an organization.
Please see the course description below.

Implementing and Auditing the Critical Security Controls – In-Depth teaches students how to lead their teams to implement 20 families of high priority controls in a manner that are particularly effective against pervasive threats.  The control families are positioned squarely on the “critical path” of the cyber intrusion kill chain.  The course presents many techniques to automate both the original implementation, and tests for the ongoing successful operation, of the controls, in order to present actionable detections of anomalous behavior.  One purpose for automation, and the instructor’s emphasis on the time metrics that are taught in this course, is to set student expectations for minimizing time to detect and time to respond to intrusions.  A few controls are manual by nature.  Test cases for auditing control effectiveness are provided.  System diagrams for automating the controls are provided.  The course delves much deeper than the Critical Security Control white paper.  SANS does not say the following in the course, but when automation of the controls are combined, what seems to emerge is a virtual cybersecurity control system for protect, detect, and respond.  Anomalies in the Afloat system are detected and facilitated through that cybersecurity control system.

Each of the 20 control families is a subset of the NIST SP 800-53 Rev 4 controls.  By using the principles from the SANS SEC 566 course, system designers can implement their own NIST SP 800-53 Rev 4, <yyy source>, or <zzz source> requirements with greater impact, by cross-checking their requirements implementations with the paradigms and implementation patterns that are described in this course, for those same requirements.

The 31 Aug 2014 COMNAVCYBERFORINST 5239.2B, Navy Cyber Forces Commander’s Cybersecurity Handbook v3, Enclosure (13), lists implementation of the Critical Security Controls for Effective Cyber Defense as an industry best practice.
Tenable, Tripwire, Qualys, and LogRhythm each feature the Critical Security Controls in their paradigms.  See Appendix A, Council on Cybersecurity and Center for Internet Security, for URLs to their projects.
The Council on Cybersecurity and Center for Internet Security both offer the whitepaper for download: Critical Security Controls for Effective Cyber Defense
Please see the course description below.

SANS SEC 511 Course
Continuous Monitoring and Security Operations

Author Statement
We are just beginning to accept that every organization can and will be breached. Perimeter-focused preventive security controls have failed. Attackers simply have to find one way into most organizations, and then the lack of internal security controls allows adversaries to take their time to achieve the goal.
This course assesses the current state of security architecture and continuous monitoring, and provides a new approach to security architecture that can be easily understood and defended. What I love most about this course is that when students walk out they have a list of action items in hand for making their organization one of the most effective vehicles for frustrating adversaries. Students are able to assess deficiencies in their own organizations’ security architectures and effect meaningful changes that are continuously monitored for deviations from their expected security posture.
– Eric Conrad and Seth Misenar

Day 1
SEC511.1:  Current State Assessment, SOCs, and Security Architecture

The prevention-dominant security model has failed. Given the frequency and extent of significant intrusions, this should not come as a surprise. In order to address the root of the problem, we must understand the current architecture and the design gaps that facilitate the adversary's dominance. What do we need to address to begin to make things better? Can we ever hope to win? What would winning look like? These are important questions that we must answer if we hope to substantially improve our security posture.
We begin with the end in mind, and define the key techniques and principles that will allow us to achieve that state. An effective modern SOC or Security Architecture must enable an organization's ability to rapidly find intrusions to facilitate containment and response. Both significant knowledge and a commitment to continuous monitoring are required to achieve this goal.

Day 1: Current State Assessment, SOCs, and Security Architecture
·       Traditional Security Architecture
·       Perimeter Focused
·       Addressed Layer 3/4
·       Centralized Information Systems
·       Prevention-Oriented
·       Device-driven
·       Traditional Attack Techniques

Modern Security Architecture Principles
·       Detection-oriented
·       Post-Exploitation focused
·       Decentralized information systems/data
·       Risk-informed
·       Layer 7 Aware
·       Security Operations Centers
·       Network Security Monitoring
·       Continuous Security Monitoring
·       Modern Attack Techniques
·       Adversarial Dominance

Frameworks and Enterprise Security Architecture
·       Enterprise Security Architecture
·       Security Frameworks

Security Architecture - Key Techniques/Practices
·       Threat Vector Analysis
·       Data Exfiltration Analysis
·       Detection Dominant Design
·       Zero Trust Model (Kindervag)
·       Intrusion Kill Chain
·       Visibility Analysis
·       Data Visualization
·       Lateral Movement Analysis
·       Data Ingress/Egress Mapping
·       Internal Segmentation
·       Network Security Monitoring
·       Continuous Security Monitoring

Security Operations Center (SOC)
·       Purpose of a SOC
·       Key SOC roles
·       Relationship to Defensible Security Architecture

Day 2
SEC511.2:  Network Security Architecture

Understanding the problems with the current environment and realizing where we need to get is far from sufficient: we need a detailed roadmap to bridge the gap between the current and desired state. Day two introduces and details the components of our infrastructure that become part of a defensible network security architecture and SOC. We are long past the days where a perimeter firewall and ubiquitous antivirus was sufficient security. There are many pieces and moving parts that comprise a modern defensible security architecture.
In addition to discussing technologies like Next Generation Firewalls, UTM devices, Malware Detonation Devices, SIMs, DLP, and Honeypots that may not be found in all organizations, we will focus on repurposing traditional devices such as layer 3/4 firewalls, routers, switches, and NIDS. The goal of this course is not to give you a long list of items to add to the next year's budget, so we will focus on maximizing the capabilities of your current information security architecture, while pointing out new technologies that may offer a compelling return on investment (ROI).

Day 2: SOCs and Defensible Network Security Architecture

SOCs/Security Architecture - Key Infrastructure Devices
·       Traditional and Next Generation Firewalls, and NIPS
·       Web Application Firewall
·       Malware Detonation Devices
·       HTTP Proxies, Web Content Filtering, and SSL Decryption
·       SIMs, NIDS, Packet Captures, and DLP
·       Honeypots/Honeynets
·       Network Infrastructure - Routers, Switches, DHCP, DNS
·       Mobile Devices and Wireless Access Points
·       Threat Intelligence

Segmented Internal Networks
·       Routers
·       Internal SI Firewalls
·       VLANs
·       Detecting the Pivot

Defensible Network Security Architecture Principles Applied
·       Internal Segmentation
·       Threat Vector Analysis
·       Data Exfiltration Analysis
·       Detection Dominant Design
·       Zero Trust Model (Kindervag)
·       Intrusion Kill Chain
·       Visibility Analysis
·       Data Visualization
·       Lateral Movement Analysis
·       Data Ingress/Egress Mapping

Day 3
SEC511.3:  Network Security Monitoring

Designing a SOC or security architecture that enhances visibility and detective capabilities represents a paradigm shift for most organizations. However, the design is simply the beginning. The most important element of a modern security architecture is the emphasis on detection. The network security architecture presented in days one and two emphasized baking visibility and detective capabilities into the design. Now we must figure out how to look at the data and continuously monitor the enterprise for evidence of compromise or changes that increase the likelihood of compromise.
We must first understand the approach and goals of monitoring and define a methodology for analysis. Key terms such as Network Security Monitoring (NSM), Continuous Diagnostics and Mitigation (CDM), and Continuous Security Monitoring (CSM) can cause confusion, and we will make sure these terms are understood, enabling the security professional to guide an organization in the best practices. Speaking of best practices: we will emphasize the continuous monitoring of the Critical Security Controls.
Then we will describe enabling continuous monitoring by developing a model for employing robust Network Security Monitoring (NSM). NSM will allow an organization to deal with and make sense of data that will rapidly allow for the detection of potential intrusions or unauthorized actions.

Day 3: SOCs and Network Security Monitoring

Continuous Monitoring Overview
·       Defined
·       Network Security Monitoring (NSM)
·       Continuous Security Monitoring (CSM)
·       Continuous Monitoring and the 20 Critical Security Controls

Network Security Monitoring (NSM)
Evolution of NSM
The NSM Toolbox
NIDS Design
Analysis Methodology
Understanding Data Sources
·       Full Packet Capture
·       Extracted Data
·       String Data
·       Flow Data
·       Transaction Data
·       Statistical Data
·       Alert Data
·       Tagged Data
·       Correlated Data

Practical NSM Issues

Cornerstone NSM
·       Service-Side and Client-Side Exploits
·       Identifying High-entropy Strings
·       Tracking EXE Transfers
·       Identifying Command and Control (C2) Traffic
·       Tracking User Agents
·       C2 via HTTPS
·       Tracking Encryption Certificates

Day 4
SEC511.4:  Endpoint Security Architecture

One of the hallmarks of modern attacks is an emphasis on client-side exploitation. The days of breaking into networks via direct frontal assaults on unpatched mail, web, or DNS servers are largely behind us. We must focus on mitigating the risk of compromise of clients. Day four details ways in which endpoint systems can be both more resilient to attack and also enhance detective capabilities.

Day 4: SOCs and Defensible Endpoint Security Architecture

Security Architecture - Endpoint Protection
·       Anti-malware
·       Host-based Firewall, Host-based IDS/IPS
·       Application Whitelisting, Application Virtualization
·       Privileged Accounts, Authentication, Monitoring, and UAC
·       Whole Disk Encryption
·       Virtual Desktop Infrastructure
·       Browser Security
·       EMET

Dangerous Endpoint Applications
·       Java
·       Adobe Reader
·       Flash
·       Microsoft Office
·       Browsers

·       Process
·       To Test or Not to Test
·       Microsoft
·       3rd Party

Day 5
SEC511.5:  Automation and Continuous Security Monitoring

Network Security Monitoring (NSM) is the beginning: we need to not only detect active intrusions and unauthorized actions, but also know when our systems, networks, and applications are at an increased likelihood for compromise. A strong way to achieve this is through Continuous Security Monitoring (CSM) or Continuous Diagnostics and Mitigation (CDM). Rather than waiting for the results of a quarterly scan or an annual penetration test to determine what needs to be addressed, continuous monitoring insists on proactively and repeatedly assessing and reassessing the current security posture for potential weaknesses that need be addressed.
The volume of data that must continuously be sought and mined is vast: the goal of continuous monitoring would be out of reach without scripting and automation. Naturally, there are vendors and tools to scratch this itch, but they will be incomplete and require their own care, feeding, and monitoring. Day five describes how to perform continuous monitoring with simple tools and scripts.
Knowing how to script and automate is pointless unless you know what data should be captured and analyzed on a continuous basis. Again leaning on the Critical Security Controls, we will determine high value targets for continuous monitoring in an enterprise.

Day 5: Automation and Continuous Security Monitoring

·       Continuous Security Monitoring (CSM) vs. Continuous Diagnostics and Mitigation (CDM) vs. Information Security Continuous Monitoring (ISCM)
·       Cyberscope and SCAP

Industry Best Practices
·       Continuous Monitoring and the 20 Critical Security Controls
·       Australian Signals Directorate (ASD) Strategies to Mitigate Targeted Cyber Intrusions

Winning CSM Techniques
Maintaining Situational Awareness
Host, Port and Service Discovery
Vulnerability Scanning
Monitoring Patching
Monitoring Applications

Monitoring Service Logs
·       Detecting Malware via DNS logs

Monitoring Change to Devices and Appliances
Leveraging Proxy and Firewall Data
Configuring Centralized Windows Event Log Collection

Monitoring Critical Windows Events
·       Hands on: Detecting Malware via Windows Event Logs

Scripting and Automation
·       Importance of Automation
·       PowerShell
·       Hands-on: Detecting Malicious Registry Run Keys with PowerShell

Day 6
SEC511.6:  Capstone: Design, Detect, Defend

The course culminates in a team-based design, detect, and defend the flag competition. Powered by NetWars, day six provides a full day of hands-on work applying the principles taught throughout the week.
Your team will progress through multiple levels and missions designed to ensure mastery of the modern cyber defense techniques promoted all week long. From security architecture, network security monitoring, endpoint security, and continuous monitoring, this challenging exercise will reinforce key principles in a fun, hands-on, team-based challenge.

Day 6: Capstone - Design/Detect/Defend

Security Architecture
Assess provided architecture
Continuous Security Monitoring
Using tools/scripts assess the initial state
Quickly/Thoroughly find all changes made

SANS SEC 566 Course
Implementing and Auditing the Critical Security Controls - In-Depth

Author Statement
As we've had the opportunity to talk with information assurance engineers, auditors, and managers over the past ten years, we've seen frustration in the eyes of these hardworking individuals who are trying to make a difference in their organizations by better defending their data systems. It has even come to the point where some organizations have decided that it's simply too hard to protect their information, and many have started to wonder, is the fight really worth it? Will we ever succeed? We see companies and agencies making headway, but the offense keeps pushing. The goal of this course is to give direction and a realistic hope to organizations attempting to secure their systems.
The 20 Critical Security Controls: Planning, Implementing, and Auditing offers direction and guidance from those in the industry who think through the eyes of the attacker as to what security controls will make the most impact. What better way to play defense than by understanding the mindset of the offense? By implementing our defense methodically and with the mindset of a hacker, we think organizations have a chance to succeed in this fight. We hope this course helps turn the tide.
– Eric Cole, Ph.D. and James Tarala

Day 1
SEC566.1:  Introduction and Overview of the 20 Critical Controls

During day 1, we will cover an introduction and overview of the 20 Critical Controls, laying the foundation for the rest of the class. For each control the following information will be covered, and we will follow the same outline for each control:

1. Overview of the Control
2. How it is Compromised
3. Defensive Goals
4. Quick Wins
5. Visibility & Attribution
6. Configuration & Hygiene
7. Advanced
8. Overview of Evaluating the Control
9. Core Evaluation Test(s)
10. Testing/Reporting Metrics
11. Steps for Root Cause Analysis of Failures
12. Audit/Evaluation Methodologies
13. Evaluation Tools
14. Exercise to Illustrate Implementation Or Steps for Auditing a Control

In addition, Critical Controls 1 and 2 will be covered in depth.

Critical Control 1: Inventory of Authorized and Unauthorized Devices
Any time a new device is installed on a network, the risks of exposing the network to unknown vulnerabilities or hampering its operation are present. Malicious code can take advantage of new hardware that is not configured and patched with appropriate security updates at the time of installation. Attackers can use these vulnerable systems to install backdoors before they are hardened. In automating critical control 1, it's critical for all devices to have an accurate and up-to-date inventory control system in place. Any device not in the database should be prohibited from connecting to the network. Some organizations maintain asset inventories by using specific large-scale enterprise commercial products or by using free solutions to track and sweep the network periodically. To evaluate the implementation of Control 1 on a periodic basis, the evaluation team will connect hardened test systems to at least 10 locations on the network. This will include a selection of subnets associated with DMZs, workstations, and servers.

Critical Control 2: Inventory of Authorized and Unauthorized Software
An organization without the ability to inventory and control its computer's installed programs makes its systems more vulnerable to attack. Furthermore, poorly controlled machines are more likely to be running software that is unneeded for business purposes, introducing potential security flaws. Compromised systems become a staging point for attackers to collect sensitive information. In order to combat this potential threat, an organization should scan a network and identify known or responding applications. Commercial software and asset inventory tools are widely available. The best tools provide an inventory check of hundreds of common applications, pulling information about the patch level of each installed program. This ensures that it's the latest version and that it leverages standardized application names, like those found in the Common Platform Enumeration (CPE) specification. In addition to inventory checks, tools that implement whitelists (allow) and blacklists (deny) of programs are included in many modern end-point security suites. To evaluate the implementation of Control 2 on a periodic basis, the team must move a benign software test program that is not included in the authorized software list on 10 systems on the network. The team must then verify that the software is blocked and unable to run.

Day 2
SEC566.2:  Critical Controls 3,4,5 and 6

During day 2, we will cover Critical Controls 3, 4, 5 and 6.

Critical Control 3: Secure Configurations for Hardware and Software on Laptops, Workstations, and Servers
Default configurations of software are often geared to ease-of-deployment and ease-of-use and not security, leaving some systems exploitable in their default state. Attackers attempt to exploit both network-accessible services and client software using various forms of malware. Without the ability to inventory and control installed and running, enterprises make their systems more vulnerable. Organizations can implement this control by developing a series of images and secure storage servers for hosting these standard images. Configuration management tools can be employed to measure the settings of the installed software and to look for deviations from the standard image configurations used by the organization. To evaluate the implementation of Control 3 on a periodic basis, an evaluation team must move a benign test system (one that does not contain the official hardened image, but does contain additional services, ports, and configuration files changes) onto the network. The evaluation team must then verify that the systems generate an alert or e-mail notice regarding the changes to the software.

Critical Control 4: Continuous Vulnerability Assessment and Remediation
Soon after new vulnerabilities are discovered and reported by security researchers or vendors, attackers engineer exploit code and launch it against targets of interest. Any significant delays finding or fixing software with critical vulnerabilities provides ample opportunity for persistent attackers to break through and gain control of vulnerable machines. A large number of vulnerability scanning tools are available to evaluate the security configuration of systems. The most effective vulnerability scanning tools compare the results of the current scan with previous scans to determine how the vulnerabilities in the environment have changed over time. All machines identified by the asset inventory system must be scanned for vulnerabilities. To evaluate the implementation of Control 4 on a periodic basis, the evaluation team must verify that scanning tools have successfully completed their weekly or daily scans.

Critical Control 5: Malware Defenses
Malicious software is an integral and dangerous aspect of Internet threats. It targets end users and organizations via Web browsing, e-mail attachments, mobile devices, and other vectors. Malicious code may tamper with a system's contents, capture sensitive data, and spread to other systems. To ensure anti-virus signatures are up-to-date, effective organizations use automation. They use the built-in administrative features of enterprise endpoint security suites to verify that anti-virus, anti-spyware, and host-based Intrusion Detection Systems (IDS) features are active on every managed system. They also run automated assessments daily and review the results to find and mitigate systems that have deactivated such protections or do not have the latest malware definitions. The system must identify any malicious software that is either installed, attempted to be installed, executed, or attempted to be executed, on a computer system. To evaluate the implementation of Control 5 on a periodic basis, the evaluation team must move a benign software test program appearing to be malware onto a system and make sure it is properly discovered and remediated.

Critical Control 6: Application Software Security
Criminal organizations frequently attack vulnerabilities in both web-based and non-web-based application software. In fact, it's a top priority for criminals.
Application software is vulnerable to remote compromise in three ways:
·       It does not properly check the size of user input
·       It fails to sanitize user input by filtering out potentially malicious character sequences
·       It does not initialize and clear variables properly
To avoid attacks, internally developed and third party application software must be carefully tested to find security flaws. Source code testing tools, web application security scanning tools, and object code testing tools have proven useful in securing application software. Another useful tool is manual application security penetration testing by testers who have extensive programming knowledge and application penetration testing expertise. The system must be capable of detecting and blocking an application-level software attack, and must generate an alert or send e-mail to enterprise administrative personnel. To evaluate the implementation of Control 6 on a monthly basis, an evaluation team must use a web application vulnerability scanner to test software security flaws.

Day 3
SEC566.3:  Critical Controls 7, 8, 9, 10 and 11

During day 3, we will cover Critical Controls 7, 8, 9, 10 and 11.

Critical Control 7: Wireless Device Control
Attackers who gain wireless access to an organization from nearby parking lots have initiated major data thefts. This allows attackers to bypass an organization to maintain long-term access inside a target. Effective organizations run commercial wireless scanning, detection, and discovery tools as well as commercial wireless intrusion detection systems. The system must be capable of identifying unauthorized wireless devices or configurations when they are within range of the organization's systems or connected to its networks. To evaluate the implementation of Control 7 on a periodic basis, the evaluation team staff must configure unauthorized but hardened wireless clients and wireless access points to the organization's network. It must also attempt to connect them to the organization's wireless networks. These access points must be detected and remediated in a timely manner.

Critical Control 8: Data Recovery Capability (validated manually)
When attackers compromise machines, they often make significant changes to configurations and software. Sometimes attackers also make subtle alterations of data stored on compromised machines, potentially jeopardizing organizational effectiveness with polluted information. Once per quarter, a testing team should evaluate a random sample of system backups by attempting to restore them on a test bed environment. The restored systems should be verified to ensure that the operating system, application, and datum from the backup are all intact and functional.

Critical Control 9: Security Skills Assessment and Appropriate Training to Fill Gaps (validated manually)
An organization hoping to find and respond to attacks effectively relies on its employees and contractors to find the gaps and fill them. A solid security skills assessment program can provide actionable information to decision makers about where security awareness needs to be improved. It can also help determine proper allocation of limited resources to improve security practices. The key to upgrading skills is measurement, not with certification examinations, but with assessments that show both the employee and the employer where knowledge is sufficient and where there are gaps. Once the gaps have been identified, those employees who have the requisite knowledge can be called upon to mentor the employees who do not. The organization can also develop training programs that directly maintain employee readiness.

Critical Control 10: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches
Attackers penetrate defenses by searching for electronic holes in firewalls, routers, and switches. Once these network devices have been exploited, attackers can gain access to target networks, redirect traffic on that network (to a malicious system masquerading as a trusted system), and intercept and alter information while in transmission. Organizations can use commercial tools that will evaluate the rule set of network filtering devices, which determine whether they are consistent or in conflict and provide an automated check of network filters. Additionally, these commercial tools search for errors in rule sets. Such tools should be run each time significant changes are made to firewall rule sets, router ACLs, or other filtering technologies. To evaluate the implementation of Control 10 on a periodic basis, an evaluation team must make a change to each type of network device plugged into the network. At a minimum, routers, switches, and firewalls need to be tested. If they exist, IPS, IDS, and other network devices must be included.

Critical Control 11: Limitation and Control of Network Ports, Protocols, and Services
Attackers search for remotely accessible network services that are vulnerable to exploitation. Many software packages automatically install services and turn them on as part of the installation of the main software package. When this occurs, the software rarely informs a user that the services have been enabled. Port scanning tools are used to determine which services are listening on the network for a range of target systems. In addition to determining which ports are open, effective port scanners can be configured to identify the version of the protocol and service listening on each discovered open port. The system must be capable of identifying any new unauthorized listening network ports that are connected to the network. To evaluate the implementation of Control 11 on a periodic basis, the evaluation team must install hardened test services with network listeners on ten locations on the network, including a selection of subnets associated with DMZs, workstations, and servers.

Day 4
SEC566.4:  Critical Controls 12, 13, 14 and 15

During day 4, we will cover Critical Controls 12, 13, 14 and 15.

Critical Control 12: Controlled Use of Administrative Privileges
The most common method attackers use to infiltrate a target enterprise is through an employee's own misuse of administrator privileges. An attacker can easily convince a workstation user to open a malicious e-mail attachment, download and open a file from a malicious site, or surf to a site that automatically downloads malicious content. If the user is logged in as an administrator, the attacker has full access to the system. Built-in operating system features can extract lists of accounts with superuser privileges, both locally on individual systems and on overall domain controllers. These accounts should be monitored and tracked very closely. To evaluate the implementation of Control 12 on a periodic basis, an evaluation team must verify that the organization's password policy is enforced and administrator accounts are carefully controlled. The evaluation team does this by creating a temporary, disabled, limited privilege test account on ten different systems. It then attempts to change the password on the account to a value that does not meet the organization's password policy.

Critical Control 13: Boundary Defense
By attacking Internet-facing systems, attackers can create a relay point to break into other networks or internal systems. Automated tools can be used to exploit vulnerable entry points into a network. To control the flow of traffic through network borders and to look for attacks and evidence of compromised machines, boundary defenses should be multi-layered. These boundaries should consist of firewalls, proxies, DMZ perimeter networks, and network-based intrusion prevention systems and intrusion detection systems. Organizations should regularly test these sensors by launching vulnerability-scanning tools. These tools verify that the scanner traffic triggers an appropriate alert. The captured packets of the Intrusion Detection Systems (IDS) sensors should be reviewed using an automated script each day, which ensures log volumes are within expected parameters, are formatted properly, and have not been corrupted. To evaluate the implementation of Control 13 on a periodic basis, an evaluation team must test boundary devices. This is done by sending packets from outside a trusted network, which ensures that only authorized packets are allowed through the boundary. All other packets must be dropped.

Critical Control 14: Maintenance, Monitoring, and Analysis of Audit Logs
At times, audit logs provide the only evidence of a successful attack. Many organizations keep audit records for compliance purposes but rarely review them. When audit logs aren't reviewed, organizations don't know their systems have been compromised. Attackers rely on this. Most free and commercial operating systems, network services, and firewall technologies offer logging capabilities. Such logging should be activated, and logs should be sent to centralized logging servers. The system must be capable of logging all events across the network. The logging must be validated across both network and host-based systems. To evaluate the implementation of Control 14 on a periodic basis, an evaluation team must review the security logs of various network devices, servers, and hosts.

Critical Control 15: Controlled Access Based On Need to Know
Some organizations do not carefully identify and separate sensitive data from less sensitive, publicly available information within an internal network. In many environments, internal users have access to all or most of the information on the network. Once attackers have penetrated such a network, they can easily find and exfiltrate important information with little resistance. This control is often implemented using the built-in separation of administrator accounts from non-administrator accounts. The system must be able to detect all attempts by users to access files without the appropriate privileges and must generate an alert or e-mail for administrative personnel. This includes information on local systems or network accessible file shares. To evaluate the implementation of Control 15 on a periodic basis, the evaluation team must create test accounts with limited access and verify that the account is unable to access controlled information.

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

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.

Appendix C        Ten Strategies of a World-Class Cybersecurity Operations Center

Carson Zimmerman posted the following article on 16 Dec 2014, with principles that will aid organizations with their cybersecurity operations.  System designers and ship’s force can use many of these principles without establishing a formal security operations center (SOC).  As cyber impacts grow, however, the security operations function will reorganize and mature by necessity.

Article: Active Threat-based Defense – Ten Strategies for Becoming a World-Class CSOC
Book: Ten Strategies of a World-Class Cybersecurity Operations Center
By Carson Zimmerman, 346 pages.  Donated to the public domain by Zimmerman and MITRE Corp.

During a decade of helping government sponsors with computer network defense (CND), my MITRE colleagues and I noticed that the same questions kept coming up from others involved in cybersecurity operations—"what data should I collect," "how many analysts do I need," and “where does my shop belong on the org chart?" Specifically, they wanted to know what organizational structure works best, how to design effective policies, what data sources to tap, and what technologies to invest in.
Since the answers to these questions seemed to come from many sources, the time seemed ripe to bring together all that we had learning from supporting Cybersecurity Operations Centers (CSOCs or just "SOCs") into one document we could share with others.
The most pressing concerns coalesce around ten common themes—the inspiration for Ten Strategies of a World-Class Cybersecurity Operations Center. Here's a summary.

1. Consolidate CND under one organization
This is the most obvious, but least likely to happen. Entities, both public and private, sometimes tend to divide their core CND functions (incident monitoring; detection; response; coordination; and CND tool engineering, operation, and maintenance) into separate units. But fragmentation fosters distrust and undermines effectiveness. Not only should all these functions be brought into one organization—the SOC—they should also be physically co-located.

2. Achieve balance between size and agility
The SOC faces competing needs—it must be large enough to cover the entire enterprise, yet agile enough to react swiftly to adversarial actions. To strike the right balance, the SOC has to decide on the best organizational model, where to place SOC functions with line managers in the command structure, and where to physically locate. Particularly in large enterprises, this may mean that CND functions are broken into tiers, with distributed execution and centralized coordination.

3. Give the SOC the authority to do its job
Every SOC needs written policies to grant it the authority to exist, procure resources, and effect change. Solid policies regarding supporting IT and cybersecurity functions are also key. SOCs that lack written authority often spend more time begging for help, than in making a positive impact. The book provides a policy template that can be modified to fit different organizational models and capabilities.

4. Do a few things well
Favoring quantity over quality can undermine the SOC in the eyes of the very entities it depends on for mission success. The SOC needs to determine which of a host of responsibilities (from threat assessment and forensic artifact handling, to security consulting and media relations) to assume and at what level (basic, advanced, or optional). As the SOC matures, it may build upon its successes, mature along various paths, and take on additional roles in network defense.

5. Favor staff quality over quantity
People are the most important element in cybersecurity. But who do you hire, how many people do you hire, and how do you get them to stay? Mindset and skillset are key in individual hiring. Determining the right number of analysts can be tricky. The book provides some general considerations, points out areas where automation and streamlining are possible, and lays out a plan for minimizing turnover.

6. Maximize the value of technology purchases
The SOC needs to consider every technology purchase in light of its relevancy to the constituency, its longevity, and its operator feedback, among other things. Resources should be dedicated to continuously improving tools as well as integrating them into one coherent architecture and workflow.

7. Exercise discrimination in the data you gather
Collect too little data and you can't find the intrusions; collect too much and the red flags are lost among the nonessentials. The SOC must gather the right data in the right amounts from the right places—with a thoughtful approach to effort and expense. This means knowing where to place your sensors and how to select and hook up your data feeds. A prag­matic, operations-driven approach helps prioritize resources.

8. Protect the SOC mission
A SOC must function even when its constituency's assets have been compromised. The best ones operate in an out-of-band fashion that isolate passive monitoring systems, analytics, and sensitive data storage from the rest of the enterprise. They must also achieve near zero packet loss at designated monitoring points of presence and prevent the adversary from detecting (and evading) their monitoring capabilities. Yet at the same time they must provide a measured degree of transparency and reporting to their customers to maintain trust and maximize impact.

9. Be a sophisticated consumer and producer of cyber threat intelligence
Today's defenders must constantly adapt their techniques, tactics, and procedures to respond to a changing threat environment. This proactive approach involves creating cyber threat intelligence based on observations and analysis and trading in cyber threat reporting with other SOCs. A cyber threat analysis cell (a group of analysts who focus on the advanced persistent threat) can facilitate this intel exchange, and we provide a roadmap for creating one.

10. Stop, think, respond … calmly
The typical SOC has to respond to thousands of threats a year, and each response must be delivered in a professional, trustworthy, and effective manner. Among our recommendations, we suggest: develop, refine, and follow a set of standard operating procedures, be the "level head" that manages concerns and excitement when a big incident does arise, do your best to understand the full extent of the intrusion given time and resource constraints, and use that knowledge in the context of your specific mission or business.

Carson Zimmerman is a principal cybersecurity engineer with The MITRE Corporation. He has 10 years of experience working with various CSOCs to better defend against the adversary. He has held roles in the CSOC ranging from tier 1 analyst to cyber architect.