Custom Frameworks Compliance and Critical Controls Introductions Michael

Custom Frameworks, Compliance, and Critical Controls

Introductions Michael Montagliano Chief Technology Officer, Vice President of Consulting mmontagliano@iv 4. com Jeanne Morelli Vice President of Operations, Senior Business Technology Consultant jmorelli@iv 4. com

Agenda • • • Intro Control Framework – What is it? NIST Overview Risk Categorization and Boundaries SU Case Study CIS 20 Critical controls ENIA Case Study Other Considerations How you get there?

Controls, the Oh My Part!

What does Control Framework mean? A control framework is a set of controls that protects data within the IT infrastructure of a business or other entity. Acts as a comprehensive security protocol that protects against fraud or theft from a spectrum of outside parties, including hackers and other kinds of cyber-criminals. • Vary based on the needs and characteristics of the business or organization. • Various key characteristics are often part of these plans including: • Risk assessment ideas such as objective setting, event identification and developed response plans. • Compliance with government requirements or industry • Monitoring and other elements called control activities. • Monitoring processes can involve transaction reviews, quality assurance checks and various kinds of audits. • Control activities promote compliance and risk mitigation and may include authorizations, reviews and verifications of IT processes, hardware setups, or other elements of an infrastructure.

Major Control Frameworks In its simplest terms, a framework is an arrangement of parts that provides a form, or structure, to the whole. • A structured way of categorizing controls to ensure the whole spectrum of control is covered adequately. • Can be informal or formal. • A formal approach will more readily satisfy the various regulatory or statutory requirements for organizations subject to them. • Some frameworks focus solely on process maturity analysis and others focus more on standardized policies and checklists for IT controls.

Major Control Frameworks No single framework that is all encompassing and "complete" in every sense of the word. • There is no single framework that covers all aspects of providing the information services and management team with the tools and direction they need to move from regulatory requirements to implementing policy, procedure, and process controls that meet those requirements. The major players in the IT framework arena are: • Some of the frameworks mentioned below are publicly available and others are for purchase. AICPA/CICA Carnegie Mellon University (CMU/SEI) OCTAVE CICA Co. Co – Criteria of Control Framework CICA IT Control Guidelines CMMI – Capability Maturity Model Integration Cobi. T COSO GAISP – Generally Accepted Information Security Principles ISF Standard of Good Practice for Information Security ISO 9000 ITIL Malcolm Baldridge National Quality Program OECD Principles of Corporate Governance OPMMM Six Sigma Recommended Security Controls for Federal Information Systems, NIST SP 800‐ 53 rev. 4 CIS 20 Critical Controls ISO 17799: 2005 and the ISO 27000 series

Today’s Focus

NIST SP 800 -53 Rev. 4

NIST 800‐ 53 Rev. 4 Overview Document 800. 53 provides a comprehensive set of security controls, three security control baselines (low, moderate, and high impact) Guidance for tailoring the appropriate baseline to specific needs according to the organization's missions, environments of operation, and technologies used Revision 4 has been updated to reflect the evolving technology and threat space. • • Mobile and cloud computing Insider threats Applications security Supply chain risks Advanced persistent threat Trustworthiness Assurance Resilience of information systems

NIST 800‐ 53 Rev. 4 Overview Each publication within NIST's 800 series provides guidance for implementing the steps in the NIST Risk Management Framework. NIST Special Publication 800‐ 53 covers the steps in the Risk Management Framework that address security control selection (i. e. , determining what security controls are needed to protect organizational operations and assets, individuals, other organizations, and the US as a nation) in accordance with the security requirements in the US's FIPS 200‐ 4. This includes: Selecting an initial set of baseline security controls based on a FIPS 199 worst-case, impact analysis Tailoring the baseline security controls Supplementing the security controls, as necessary, based on an organizational assessment of risk.

NIST Risk Management Framework Security Lifecycle SP 800 -37 / SP 800 -53 A Continuous Monitoring MONITOR Security Controls Continuously track changes to the information system that may affect security controls and reassess control effectiveness Starting Point FIPS 199 CATEGORIZE Information System Define criticality /sensitivity of information system according to potential impact of loss SP 800 -37 Risk Management FIPS 200 / SP 800 -53 CSC Control Tailoring SELECT Security Controls Select baseline (minimum) security controls to protect the information system; apply tailoring guidance as appropriate SP 800 -53 / SP 800 -30 Security Center Analysis AUTHORIZE SUPPLEMENT Information System Security Controls Use risk assessment results to supplement the tailored security control baseline as needed to ensure adequate security and due diligence Determine risk to agency operations, agency assets, or individuals and, if acceptable, authorize information system operation SP 800 -53 A Control Effectiveness Audit ASSESS Security Controls Determine security control effectiveness (i. e. , controls implemented correctly, operating as intended, meeting security requirements) SP 800 -70 CSC Controls Roll out IMPLEMENT Security Controls Implement security controls; apply security configuration settings SP 800 -17 System Security Plan (SSP) DOCUMENT Security Controls Document in the security plan, the security requirements for the information system and the security controls planned or in place

NIST 800‐ 53 Rev. 4 Strengths NIST 800 -53 has become a cornerstone authority document for many organizations outside of the US Federal Government. Such as the healthcare community with the adoption of the Centers for Medicaid and Medicare adapting their CMS Information Security Acceptable Risk Safeguards document to it, and having many of the same controls also appear within the payment card industry's PCI‐DSS. NIST 800‐ 53, unlike the ISO series and some of the others, also has its own audit guideline (Special Publication 800‐ 53 A, Guide for Assessing the Security Controls in Federal Information Systems). Weaknesses While strong, the NIST series has really only been adopted within the United States and hasn't been adopted as well within other countries.

NIST Publications Special Publication (SP) 800‐ 53 rev 4 is guiding document for this project. Supplemental documentation listed below: • FIPS Publication 199 (Security Categorization) • FIPS Publication 200 (Control Family Definitions) • NIST Special Publication 800‐ 30 (Risk Assessment) • NIST Special Publication 800‐ 53 (Recommended Security Controls) • NIST Special Publication 800‐ 53 A (Security Control Assessment) • NIST Special Publication 800‐ 60 (Security Category Mapping) • NIST Special Publication 800‐ 137 (Continuous Monitoring)

NIST 800‐ 53 Rev. 4 Security Controls • The management, operational, and technical controls (i. e. safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information • Selecting and tailoring controls applied to a Risk Management Framework. Starting # of Controls: 800+ with 8 new Privacy Families

NIST 800‐ 53 Rev. 4 Control Families Security Control Family ID Low Medium High Total Access Control AC 11 34 41 110 AT 4 5 5 10 AU 10 18 27 56 Security Assessment and Authorization CA 7 10 12 22 Configuration Management CM 8 21 31 50 Contingency Planning CP 6 22 35 48 Identification and Authentication IA 15 23 25 56 Incident Response IR 7 12 16 34 Maintenance MA 4 9 13 26 Awareness and Training Audit and Accountability

NIST 800‐ 53 Rev. 4 Control Families Security Control Family ID Low Medium High Total Media Protection MP 4 9 12 22 Physical and Environmental Protection PE 10 18 26 49 Planning PL 3 6 6 10 Personnel Security PS 8 8 9 15 Risk Assessment RA 4 7 8 13 SA 7 13 17 83 SC 10 24 29 117 SI 6 21 27 81 System and Services Acquisition System and Communication Protection System and Information Integrity

Controls Mapped to Risk Levels • All xx-1 controls refer to the creation of a policy. One for each control family • All other controls in a control family require a procedure • Common controls are controls that apply to all systems across authorization and compliance boundaries • Systems classified as LOW would have 124 Controls applied. Control Enhancements are then applied as needed • Any systems that fall into a compliance boundary are classified HIGH

NIST Control Sample

NIST Control Audit NIST Assessment Plan 800 -53 A

Risk Categorization ‐ CIA SECURITY OBJECTIVE Confidentiality Integrity Availability FIPS 199 DEFINITION A loss of confidentiality is the unauthorized disclosure of information. A loss of integrity is the unauthorized modification or destruction of information. A loss of availability is the disruption of access to or use of information or an information system.

System Categorization and Impact Analysis FIPS 199 LIMITED SERIOUS CRITICAL Confidentiality The loss of confidentiality could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of confidentiality could be expected to have a critical adverse effect on organizational operations, organizational assets, or individuals. Integrity The loss of integrity could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of integrity could be expected to have a critical adverse effect on organizational operations, organizational assets, or individuals. Availability The loss of availability could be expected to have a limited adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a serious adverse effect on organizational operations, organizational assets, or individuals. The loss of availability could be expected to have a critical adverse effect on organizational operations, organizational assets, or individuals.

System Categorization and Impact Analysis* LIMITED C I A SERIOUS CRITICAL System includes data with low confidentiality. X System requires low data integrity. X System requires moderate availability. X *Show System Categorization Workbook System Risk Categorization Moderate

Information System and Compliance Boundaries • Information System and Compliance Boundaries represent logical containers that share a common set of security controls. All systems residing in a boundary inherit the high water mark for risk categorization (low, moderate, high) and therefore all of the associated controls within the specified boundary. • Systems within Compliance Boundaries are rated high impact for risk categorization and are subject to the entire security control catalog. • Information systems in separate boundaries that are connected are excluded from controls out their specific boundary.

Boundary Risk Assignment Example – Higher Education University has defined two types of system boundaries for university information systems: 1 Information System Boundary: Based on University data classification as follows: a. Confidential (High Impact): Documents and information with legal access or use restrictions; protected products of human intelligence and creation; copyrighted works; patented inventions. b. Enterprise (Moderate Impact): Data regarding the University’s business, students, employees, alumni or affiliated individuals, disclosure of which could cause embarrassment to the University and the individual, but would not ordinarily be expected to result in material harm. c. Public (Low Impact): Data that can be freely used and distributed by anyone without damage to the University or any person, and without access or use restrictions.

Boundary Risk Assignment Example – Higher Education Boundary: Information Systems that store information pertaining 2 Compliance to and governed by regulatory compliance, which include the following: a. Federal Educational Rights and Privacy Act (FERPA): Student education records directly related to a student i. e. grades, class schedule, financial aid. b. Health Insurance Portability and Accountability Act (HIPAA): Information regarding physical or mental health, or provision of care where there is a reasonable basis to believe the individual can be identified from the information. c. Payment Card Industry Data Security Standard (PCI DSS): Information containing cardholder data related to credit card transaction and subject to identity theft or unauthorized transactions.

Boundary Risk Assignment Example – Higher Education Information Systems Blackboard Applications People. Soft Financials People. Soft HRPayroll People. Soft Student Administration People. Soft Portal Exchange Mail Website (www. uni. edu) Website (expressions. uni. edu) VMware v. Sphere ESX Hosts Health Services System MEDcat & Pro Form Public Enterprise Confidential Public Enterprise FERPA‐ Directory FERPA‐Records PCI DSS HIPAA PII X X X X X X X X X X X X X X X

NIST Documentation Objectives System Security Plan (SSP) The purpose of the system security plan is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements. • Delineates responsibilities and expected behavior of all individuals who access the system. • The system security plan should be viewed as documentation of the structured process of planning adequate, cost‐effective security protection for a system. Plan of ActionMilestone (POAM) A remedial action plan (the process of accepting or resolving a risk) which helps the agency to identify and assess: • Information system security and privacy weaknesses • Set priorities • Monitor progress toward mitigating the weaknesses.

Case Study – Higher Education • Project Kick‐off January 2015 • Project lasted 7 Months • 29+ participants including CIO, 5 ACIO’s, ISO, Project Management, and Security, System Engineers, and Support Staff from 6 Teams • SU supplied 123 documents for review (not including web content) • 207 organizationally‐defined fields completed (55. 8%) • 217 action items listed in POAM • Phase 1 of control implementation completed at the end of April, 2016 with 2 additional phases in the queue.

Case Study – Higher Education • Considered multiple Control Frameworks • Concluded that NIST was the right technical Framework • Ability to report to Board • Create auditable Framework Controls Selected to Control Not Selected 452 56. 4% [VALUE] 43. 6% Implementation Status of 350 Controls Selected [VALU 90 E] 94 Control Implemented Controls Selected Not Selected Control Partially Implemented Control Planned

Control Implemented Control Partially Implemented Control Planned ns n n cy iva Pr I) (S (S C) gr ity te In ec tio (S A) RA ) t( n io ui sit ot Pr io at rm fo m /In te Sy s tio ica Ac q en ) M L) (P (P in g PE ) l( ta ) PS P) (M A) (M ) (IR (IA ) y( Pl an m ss se As es rv ic Se un m d sk Ri gr am ro en nn Pl a n rit cu Se nm En vir o y. P rit cu Se an om /C em st Sy em st n l& el tio n P) (C se ce an ec ot Pr nn so Pe r ia ed M en pn es t. R ai nt M en tio ica nt he Au t ) CM (C A) U) T) (A (A t( n ni ng la n tio en em y. P nc ag an cid In d an M ge in nt ica ys Ph n tio Co io n lit y bi iza or th Au ta ng AC ) l( tro ni Tr ai un co nd sa Ac nd ta ra t igu ica io at rm tif en Sy fo In Id nf Co en sm nd di ta Au es y. A ss rit cu Se on s. C es Ac c es en ar Aw Case Study – Higher Education SSP Control Family Implementation State 60 50 40 30 20 10 0

CIS 20 Critical Controls

CIS Critical Security Controls v 6. 0 Overview The CIS 20 Critical Security Controls (http: //www. cissecurity. org) are a recommended set of actions for cyber defense, designed to provide specific and actionable ways to stop today’s most pervasive attacks • They were developed and are maintained by a volunteer consortium of hundreds of security experts from across the public and private sectors. • An underlying theme of the Controls is support for large‐scale, standards‐ based security automation for the management of cyber defenses. • The Critical Security Controls process takes a community‐based (as opposed to specific enterprise‐based) approach to the notion of a risk assessment.

CIS Critical Security Controls v 6. 0 Overview • Derived from the most common attack patterns and were vetted across a very broad community of government and industry, with very strong consensus on the resulting set of controls, they serve as a very strong basis for high‐value action. • Bring focus and priority to a smaller number of actionable controls with high‐leverage and high‐payoff, aiming for a “do first–must do” philosophy. • Do not attempt to replace the NIST comprehensive Risk Management Framework. • The actions defined by the Critical Security Controls are demonstrably a subset of the comprehensive catalog defined by NIST SP 800‐ 53.

CIS Critical Security Controls v 6. 0 Strengths CIS 20 Critical Controls was developed to scale to the ability of SMB organizations in the implementation, measurement, and maintenance of a security control framework. The SMB space represented over 60% of all breaches that occurred in 2015. The “do first‐must do” approach allows organizations to focus on controls that will provide the greatest risk reduction, while reducing the administrative overhead associated with building a Risk Management Framework.

CIS Critical Security Controls v 6. 0 Weaknesses While strong, certain control families are missing from the framework i. e. Physical Controls. Additionally, the regulatory cross‐walk must be thoroughly evaluated based on which controls are implemented since the 20 Critical Controls does not align with all regulatory compliance. For example, 29 additional control requirements must be covered that do not map to the 20 Critical Control framework.

20 Critical Controls RMF Security Lifecycle Control implementation starts with a few basic questions that every corporate leader ought to be able to answer: • Do we know what is connected to our systems and networks? (CSC 1) • Do we know what software is running (or trying to run) on our systems and networks? (CSC 2) • Are we continuously managing our systems using “known good” configurations? (CSC 3) • Are we continuously looking for and managing “known bad” software? (CSC 4) • Do we limit and track the people who have the administrative privileges to change, bypass, or over-ride our security settings? (CSC 5) Count Repeat Configure Patch Control

CIS CSC and Supplemental Publications The CIS Critical Security Controls for Effective Cyber Defense version 6. 0 is guiding document for this project. Supplemental documentation listed below: • CIS “A Measurement Companion to the CIS Critical Security Controls (version 6. 0) • NIST FIPS Publication 199 (Security Categorization) • IV 4 20 Critical Controls Gap Analysis Assessment Tool • IV 4 20 CSC System Categorization Workbook

20 Critical Security Control “Categories” Critical Control 1: Inventory of Authorized and Unauthorized Devices Critical Control 2: Inventory of Authorized and Unauthorized Software Critical Control 3: Secure Configurations for Hardware and Software on Mobile Devices, Laptops, Workstations, and Servers Critical Control 4: Continuous Vulnerability Assessment and Remediation Critical Control 5: Controlled Use of Administrative Privileges Critical Control 6: Maintenance, Monitoring, and Analysis of Audit Logs Critical Control 7: E-mail and Web Browser Protections Critical Control 8: Malware Defense Critical Control 9: Limitation and Control of Network Ports, Protocols, and Services Critical Control 10: Data Recovery Capability Critical Control 11: Secure Configurations for Network Devices such as Firewalls, Routers, and Switches Critical Control 12: Boundary Defense Critical Control 13: Data Protection Critical Control 14: Controlled Access Based on the Need to Know Critical Control 15: Wireless Access Control Critical Control 16: Account Monitoring and Control Critical Control 17: Security Skills Assessment and Appropriate Training to Fill Gaps Critical Control 18: Application Software Security Critical Control 19: Incident Response and Management Critical Control 20: Penetration tests and Red Team Exercises The word “control” in the Critical Security Controls is used differently than in the NIST Framework. One of the Top 20 Critical Security Controls is more like a “control category”, mapping to one or more sub‐controls.

Controls “By the Numbers” Overview The breakdown of sub‐controls to critical control are as follows: Control # of CSC Category Control # 1 6 System Control # 2 4 System Control # 3 7 System Control # 4 8 System Control # 5 9 System Control # 6 6 System Control # 7 8 System Control # 8 6 System Control # 9 6 System Control # 10 4 System Total 149 Control # of CSC Category Control # 11 7 Network Control # 12 10 Network Control # 13 9 Network Control # 14 7 Application Control # 15 9 Network Control # 16 14 Application Control # 17 5 Application Control # 18 9 Application Control # 19 7 Application Control # 20 8 Application

CIS Critical Security Control 8: Malware Defenses Control Category: System CIS Critical Security Control 8 Policy Purpose These policies provide expectations to authorized users regarding the proper management of company computing resources. Computing resources include but are not limited to: systems, applications, databases, networks, and electronic data. These policies will ensure periodic, accurate, and consistent application of configuration management controls. Scope This policy and other related policies apply to company departments, organizations and workers, including but not limited to: employees, contractors, vendors, consultants, and temporary staff as well as personnel affiliated with third parties, and the networks, equipment, systems, and applications (hereafter known as “systems”) on which corporate and client information is stored, processed, or managed. The deployment of controls will be consistent with applicable state and federal mandates and laws. Policy Company shall 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.

CIS Critical Security Control 8. 1 CSC 8. 1 Requirement: 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 8. 1 Procedure: The organization: 1. Deploys Mc. Afee Virus Scan Enterprise plus Antispyware Enterprise on company systems such as laptops, desktops, and servers (physical and virtual). Systems are updated Daily. 2. Deploys Malwarebytes Anti‐malware to provide additional protection against malicious code. 3. Mc. Afee e. Policy Orchestrator administrative console is deployed on premise in the VMware virtual server infrastructure and provides centralized management of systems including; verification and logging for deployment of software, and signature file updates. 4. Malwarebytes administrative console is deployed in the same VMware environment for centralized management for malware protection. 5. Internal and external facing laptops and tablets have Windows Firewall enabled to provide ingress and egress port filtering. (Planned) 1. Company is testing Cisco Sourcefire and Fire. Amp appliances as edge firewalls for additional network virus and malware scanning. 2. Internal facing workstations and servers have Windows Firewall disabled and company is reviewing the use case and impact for enabling this security feature.

CIS Critical Security Control

CIS Risk Threshold Values tied to System Categorization For each Measure, CIS presents Metrics, which consist of three “Risk Threshold” values: Lower Risk Threshold Critical System Categorization Moderate Risk Threshold Serious System Categorization Higher Risk Threshold Limited System Categorization These are offered as a way for adopters of the Controls to think about and choose Metrics in the context of their own security improvement programs. An alternative approach is to think of the metrics as Organizationally Defined Values. IV 4 has found the upside down Risk Threshold values approach confusing to our clients are offer the suggestion that Risk Thresholds as defined by NIST 800‐ 53 rev. should be used to maintain clarity and alignment with system categorization.

CIS Critical Security Controls Audit Overview Measurement is an essential component of any successful security program. • To support good decision‐ making, you must be able to assess your current state and also have a way to measure and report on progress. The CIS Critical Security Controls include a set of Metrics for every Control in order to help adopters manage their implementation projects. • Adopters use sample Metrics as a starting point to identify key information to assist with tracking progress and to encourage the use of automation. If you have worked in security for any amount of time, at there is a lot of security “fog” around the use of such terms. For example, there are many things that can be measured, but it is very unclear which of them are in fact worth measuring (in terms of adding value to security decisions). And since there are very few “absolutes” in security, there is always the challenge of making a judgment about the measurement value that is “good enough” in terms of managing risk.

CIS Critical Security Controls Audit Sample CSC 8 Control Auditing

Case Study – Insurance • Project Kick‐off in January 2016 • Project lasted 3. 5 Months • 6 participants including VP of Information Technology, 2 System Engineers, and IV 4 consulting • ENIA supplied 15 documents for review • 120 of 149 controls chosen for implementation (80. 5%) • 74 action items listed in POAM • Numerous technical control were in place, but measurement of effectives lacking • Chosen to support Board of Directors concerns for demonstrable security metrics

Other Considerations – Unified Compliance Framework • While not directly called out as part of System Security Plan, providing a regulatory compliance cross‐walk between controls allows for consolidation of effort • Substantial supplementary documentation available from NIST, CIS, and 3 rd parties • Provides compliance auditors with a standardized view of control framework relative to the entire organization CSC 14: Controlled Access Based on the Need to Know CSC 14. 1 Requirement: PCI DSS HIPAA Requirement: 164. 308: a 4(ii)A Isolating health care clearinghouse functions (R) Segment the network Requirement If a health care clearinghouse is part of a larger organization, the based on the label or 1. 3 Prohibit direct classification level of the public access clearinghouse must implement policies and procedures that protect information stored on between the Internet the e. PHI of the clearinghouse from unauthorized access by the larger the servers. Locate all organization. and any system sensitive information on component in the 164. 308: a 4(ii)B Access authorization (A) separated VLANS with Implement policies and procedures for granting access to e. PHI, for cardholder data firewall filtering to example, through access to a workstation, transaction, program, environment. ensure that only process or other mechanism. authorized individuals 164. 312: a 2(vi) Encryption and decryption (A) are only able to Implement a mechanism to encrypt and decrypt e. PHI. communicate with 164. 312: e 1(i) Integrity controls (A) systems necessary to Implement security measures to ensure that electronically transmitted fulfill their specific e. PHI is not improperly modified without detection until disposed of. responsibilities. CSC 14. 2 Requirement: PCI DSS HIPAA Requirement: 164. 308: a 4(ii)A Isolating health care clearinghouse functions (R) All communication of Requirement If a health care clearinghouse is part of a larger organization, the sensitive information 1. 3 Prohibit direct over less trusted clearinghouse must implement policies and procedures that protect public access networks should be between the Internet the e. PHI of the clearinghouse from unauthorized access by the larger encrypted. Whenever organization. and any system information flows over a component in the 164. 308: a 4(ii)B Access authorization (A) network with a lower Implement policies and procedures for granting access to e. PHI, for cardholder data trust level, the example, through access to a workstation, transaction, program, environment. information should be process or other mechanism. encrypted. 164. 312: a 2(vi) Encryption and decryption (A) Implement a mechanism to encrypt and decrypt e. PHI. 164. 312: e 1(i) Integrity controls (A) Implement security measures to ensure that electronically transmitted e. PHI is not improperly modified without detection until disposed of.

Other Considerations – Concept of IT Operations (Con. Ops) A Concept of Operations (Con. Ops) is a document describing the characteristics of a proposed system from the viewpoint of an individual who will use that system. It is used to communicate the quantitative and qualitative system characteristics to all stakeholders. • Provides high level overview of systems, applications, and Infrastucture an organizations IT staff supports • Provides context to control framework mapping control to supported technologies and processes • Addition to, but not required by either NIST 800‐ 53 rev. 4 or CIS 20 Critical Security Control frameworks

Wrapping up ‐ How You Get There! • System Risk Categorization – based on internal requirements and Compliance • Inventory of existing controls, policies and processes • Review selected control framework and supporting documentation • Make decisions on which Controls to apply (control breakout sessions) • Review selected controls and apply existing documented policies and processes • Create Systems Security Plan (SSP) • Map required compliance controls to selected control framework • Create Plan of Action Milestones (POAM) • Create Concept of IT Operations (Con. Ops) • Build audit process to measure compliance with controls, remediate, and repeat

THANK YOU! Western NY 1387 Fairport Road Suite 730 Fairport, NY 14450 (585) 598‐ 3300 IV 4. com @IV 4 inc Central NY 344 West Genesee Street Suite 103 Syracuse, NY 13202 (315) 424‐ 7736 IV 4, Inc.