In this course, we discussed the implements that of the Risk Management Framework. The implement step is supported by NIST Special Publication 800-18, guide for developing security plans for Federal Information Systems, NIST Special Publication 800-34, contingency planning guide for Federal Information Systems, and NIST Special Publication 800-70, national checklist program for IT products, which is the guidelines for checklists users and developers. The implement step has two tasks, control implementation and update control implementation information. The purpose of this step is to implement security controls based on the organizational system needs. In this step, we implement the controls in the security and privacy plans, also known as the System Security Plan or the SSP. For the system and for the organization and document in a baseline configuration the specific details of the controls that were implemented. Basically, the security controls specified in the security plans are implemented by taking into account the minimum organizational assurance requirements. System security and privacy engineering methodologies are used to implement the controls in the Security and Privacy Plan or the SSP, which describe how the controls are employed within the information system and its operational environment. The Security Assessment Plan documents the methods for testing these controls and the expected results throughout the system's life cycle. The plans are updated based on information obtained during the implementation of the controls and testing. Any changes to the planned implementation of the controls are documented, updated in the plan and should follow the organizational change management control process. Listed on the screen are the documents that we use for the implementation process. In addition to the FIPS-199, 200, 800-53 and 800-70, we also use the NIST Special Publication 800-18, guide for developing security plans for Federal Information Systems and NIST Special Publication 800-34, contingency planning guide for Federal Information Systems. Over the next few screens will break these down and their contributions to the risk management process. Let's start with 800-53, Rev. 4. This is the recommended security controls for Federal Information Systems. It provides guidelines for selecting and specifying security controls for information systems and provides the foundation for assessing and measuring the effectiveness of the security controls. 800-53, Rev.5, is currently in draft and will be released soon. It has significant changes to the controls, control enhancements, and supplemental guidance section when compared to the current 800-53, Rev. 4. Rev. 5 includes changes to make the controls more consumable via wider audience or consumer group. The major changes to the publication will include; making the security and privacy controls more outcome-based by changing the structure of the controls. It will have 20 control families versus the current 18 control families by adding two new groups, IP for Individual Participation Control group, which has 6 sub controls, Individual Participation Policy and Procedures, consent, redress, privacy notice, Privacy Act Statement, and individual access. The other Control is PA, Privacy Authorization, which has 4 sub controls. Privacy Authorization policy and procedure, authority to collect, purpose specification, and information sharing with external parties. Rev. 5 will also separate the control selection process from the actual controls. It will promote the integration with different risk management and cybersecurity approaches, including the NIST cybersecurity framework. It will also clarify the relationships between security and privacy to improve the selection of controls necessary to address the full scope of security and privacy risks. In separating the process of control selection from the security and privacy controls, a significant amount of tailoring guidance and other informative material previously contained in special publication 800-53 was eliminated from the publication. That content will be moved to other publications such as NIST special publication 800-37, Risk Management Framework during the next update cycle for that document. Until that happens, we will focus on 800-53 Rev.4. NIST 800-53 describes how to develop specialized sets of controls or Overlays tailored for specific types of missions, business functions, technologies, or environments of operation. The use of overlays is described in Appendix I of the 800-53. Within the risk management framework, Overlays are implemented as part of the tailoring process after the completion of an initial security categorization process using the FIPS-199 and NIST 800-60 in order to determine the impact level of the information system, which is subsequently used to select an initial set of security controls from one of the security control baselines in Appendix D, the Security Control baseline summary of 800-53. There may also be some overlaps in the protection articulated by the security controls within the different Control families. On the screen, I have an example of overlaying the control families against an organization's mission or possible business functions. In this template, we put the controls by the identification number and family against the organization's missions, functions of financial policy, legal, technical, operational, privacy, and security. The level of detail included in the overlay is at the discretion of the organization initiating the overlay, but should be of sufficient breadth and depth to provide an appropriate rationale and justification for the resulting Taylor baselines developed, including any risk-based decisions made during the overlay development process. Security controlled baseline tailoring using the concept of overlays, results in security plans that are subject to approval by authorizing officials. The example templates are in Appendix I, the overlay template of 853, and it consists of the eight sections displayed here on the screen. Identification overlay characteristics, applicability, overlay summary, detailed overlay control specification, tailoring considerations, definitions, and additional information and instructions. I've placed an example on the screen of what an overlay may look like. It just happens to be for a space platform. Tailoring of controls happens in three primary areas. Scoping guidance, compensating controls, and organizational defined parameters specifications which are aligned with organizational activities and operating environments. On the screen I've placed the tailoring guidance you see on the far left, the initial security control baselines, which would be dependent on the fifth 199 classification of low, moderate, or high. We would then apply the tailoring overlays, which result in the tailored baseline controls, those baselines with be evaluated against the organizational criteria and security control decisions which feed the end product. A tailored baseline. Security controls containing organizational defined parameters give organizations the flexibility to define certain portions of the control to support specific organizational requirements or objectives. On the screen is an example of these organizational defined parameters. Tailoring provides flexibility to support organizational requirements and implement security based on the organizational risk. It may be assigned by a law, executive order, policy, regulation, or directive like O and B's requirement to tests contingency plans at least annually as part of the Federal Information Security Management Act. Tailoring, can be assigned at any tier as appropriate. Parameter values provide flexibility to support organizational requirements and implement security based on organizational risk. All of the controls in 853 have areas where the organization can tailor the control to their needs. I've highlighted all of these areas just for example purposes in blue on the screen. Those are the areas that the organization would tailor based on their policies, procedures, standards, or needs. Scoping considerations help ensure that organizations select and implement only those controls needed for appropriate protection of information systems, organizations should apply scoping consideration as needed to assist with making risk-based decisions on security control selection, scoping considerations are not intended to limit organizations in rendering risk-based decisions. Instead, they can be used to control allocations and placement considerations, tune in operational or environmental related considerations like mobility, single-user systems and operations, data conductivity and bandwidth, limited functionality for systems or components, information and system non persistence and public access. Another area would be security objective related considerations, technology-related considerations, or mission requirement related considerations. Sometimes a digital controls may be required due to specific threats, technologies that are being used, environments of operations, et cetera. In these cases, the baseline controls may not be sufficient to address specific threats and vulnerabilities. Other situations provided in red four include cross-domain services, mobility and classification information. These situations can also be addressed at the community level by the overlays. Inputs for supplementation may include risk assessments, regulatory requirements, or policies. These are not the same as compensating controls, which are put in place when a control cannot meet the required intent. Remember that additional security controls or control enhancements will be needed to address specific threats and vulnerabilities. Organizations are encouraged to make maximum use of security control catalogs to facilitate the process of enhancing security controls or adding controls to the tailored baselines. Organizations assess and accept risks associated with implementing compensating controls in lieu of baseline controls. The compensating controls can be selected from Special Publication 853, Appendix F, which lists all the controls. An example of a compensating control would be an operational procedure instead of an automated control when operational management or technical controls are employed in lieu of the recommend controls, they must provide either an equivalent or comparable protection for that system. In some cases, they must provide more safeguards than the original controls intent. To prevent access to specific workstations. The information system activates session locks automatically after a specified time period. The issue is that it's not practical when immediate supervisor or operator's response are required. For example, in an air traffic control system, what are the possible compensating controls for this situation? Well, we could increase physical security, we could increase personal security, or we could increase logging and auditing as a compensating control. Privacy is another area of concern for organizations. Appendix J of 853 provides a structured set of controls for protecting privacy and serves as a road-map for organizations to use in identifying and implementing privacy controls concerning the entire life-cycle of personally identifiable information, PII, whether in paper or electronic form. The controls focus on information privacy as well as distinct from, but highly interrelated with information systems. The objectives of Appendix J is to promote closer cooperation between privacy and security officials. It is intended for organizational privacy officers like the Chief Privacy Officer, working with Program Managers, Information System Developers, Information Technology staff, and Information Security personnel, to apply each control with respect to the organization's distinct mission in operational needs. This is going to be based on legal authorities and obligations. Also note that the term Chief Privacy Officer is being replaced in the new 853 rev. 5 by the Senior Agency Official for privacy. That term Chief Privacy Officer will be outdated once 853 rev. 5 comes into production. This screen simply shows you the eight families and 26 controls under special publication 853 rev. 4 Appendix J in order to orient you to them. The risk management process applies to cloud, mobility, or any other technology in the same way as it does to any other type of system; you categorize, select, implement, assess, authorize, and monitor. There may be additional or different threats that need to be addressed in these systems, but the process is going to be the same. E-authentication assurance levels are based on OMB M04-04 E-authentication guidelines for information agencies, which has four levels. Level 1, little or no confidence of the asserted identity's validity, Level 2, some confidence in the asserted identity's validity. Level 3, confidence in the asserted identity's validity, and Level 4, which is very high confidence in the asserted identity's validity. Then we have 863, which is a suite of documents that can be used independently or in concert in order to meet the identity needs. They are, special publication 863A, enrollment and identity proofing, 863B, authentication and life-cycle management, and 863C, federation and assertion. The assertion levels in 863 are very similar to that of OMB's M04-04, but they only go down three levels. Identity assertion Level 1, Level 2, and Level 3. I have them listed on the screen here for you. This screen is about applying control documentation. What we're doing here is updating the security plan with enough detail on the controls implementation so that it can be used by the assessors and serve as a system configuration baseline. The problem is that control implementations are carried out with the as implemented control implementation details but that as implemented state may not always be feasible, so we need to update the plan. Documenting the as implemented control information is essential to providing the capabilities to determine when there are changes to the controls. Whether those changes are authorized and they implement the changes on the security and privacy posture of the system and the organization is authorized. Management controls are categorized by stating the views of management and their position in particular topics such as information security. For example, the information security policy is a management control wherein the management states its intent, support, and direction for security. Administrative controls, sometimes called management or directive controls, are implemented by creating and following organizational policies, procedures, or regulations. Users training and awareness also falls into this category of administrative controls or management controls. While a policy is a high level document that provides the intent of the management, administrative controls are to implement the policy. Physical controls are implemented with physical devices such as locks, fences, gates, security guards, or any of the other ones listed here on the slide as types of physical controls. Physical security covers a broad spectrum of controls to protect the physical assets, primarily the people in an organization. Physical controls are sometimes referred to as operational controls in some risk management frameworks. Operational controls can focus on human elements such as policies, processes, or procedures. For example, with training and awareness. Documentation can include configuration management plans, detailed information assurance, architecture documentation, hardware, software, firmware baseline inventories, information assurance vulnerability management plans, incident response plans, disaster recovery and contingency plans or memorandums of agreements or understanding, as well as test plans, procedures, and results. Technical controls, sometimes referred to as logical controls, are implemented using software, hardware, or firmware that restricts logical access to an information technology system. They can include elements like firewalls, filters, operating systems, applications, and even routing protocols. NIST special publication 800-92, Guide to Computer Security Log Management, provides guidance on identifying log sources, analyzing logged data, responding to identify the events, and long-term data storage and security. System-level administrators need to configure log sources so that they can capture what the organization has identified as necessary information in a format that is retrievable and at a location that has enough storage allocation to accommodate the appropriate retention periods as identified in the organizational policies. Log analysis is often treated as reactive, something to be done after a problem has been identified through other means, rather than proactive to identify ongoing activities and look for signs of impending problems. These logs contain records related to security events occurring within systems and networks. The sheer number, volume, and variety of security logs has increased greatly, which has created the need for log management to ensure that security records are stored with sufficient detail for an appropriate period of time. Routine log analysis is beneficial for identifying security incidents, policy violation, fraudulent activity, and operational problems. Logs are also useful for establishing baselines, performing auditing and forensics analysis, supporting internal investigations, and identifying operational trends, as well as long-term problems. The fundamental problem with log management is balancing a limited amount of resources with a continuous supply of log data. Key practices recommended to meet the main challenges in log management are prioritizing log management appropriately throughout the organization, establishing policies and procedures for log management, creating and maintaining a secure log management infrastructure, and providing proper training for all staff with log management responsibilities. Log generation and storage is complicated mainly by a high number of log sources, inconsistent log formats among sources, and a large volume of log data generated on a daily basis. System-level administrators need to determine how each log source should store its data. This should be driven primarily by organizational policies regarding log storage. Another area that needs to be addressed by documentation is incident response handling. Special Publication 800-61, Computer Security Incident Handling, would be the guide that we use. It has four steps listed, preparation, detection and analysis, containment, eradication and recovery, and post-incident activity. First, you need to understand that any incident that involves a compromise, a personally identifiable information, must be reported to the US-CERT within one hour of detection, regardless of the incident category being reported and the time frame. This is required for all US government organizations. Incident response reporting categories are category 0, exercise or network defense testing. Category 1, unauthorized access. Category 2, denial of service attacks. Category 3, malicious code. Category 4, inappropriate usage. Category 5, scans, probes, or attempts to access a computer system. Category 6, investigations. Incident response agencies are US-CERT, DoD-CERT agency such as a service-based organization, Information Analysis Infrastructure Protection, CERT Coordination Center, and Information Sharing and Analysis Center. On the screen, I've placed the table which shows the contingency planning process. First, we develop a contingency plan policy, then we conduct our business impact analysis, identify preventative controls, create the contingency strategies, then we've developed our contingency plan. After we have developed our contingency plan, we test the plan, conduct training and exercises to ensure that the plan works. Then we have plan maintenance which is basically updating the plan based on any testing, training, exercises, or changes in our environment which cause us to update our contingency planning process. The criteria we use for contingency planning are maximum tolerable downtime, recovery time objectives, and recovery point objectives. Everything is completed by our work recovery times. In order to establish our incident response capabilities, we have to first figure out what our recovery point objectives are. Our recovery point objectives are anything that happens after the incident. For example, the restoration of all our databases and everything in order to get us back to a steady state or a baseline. So in this case, the restoration of my databases, if I had full backups, incremental backups, or partial back-ups, would all have to be accomplished as part of my recovery point objective. I want to get all of those done by this point. My recovery time objective is the point that I want everything back up and running. All the primary business services have to be restored. So that means that all of the restorations of databases, equipment exchanges, everything has to be accomplished by that time period. Anything that goes pasts my recovery time objective starts heading towards my maximum time of disruption. My maximum time of disruption is the point where my business now becomes affected because of this disruption. I want to keep under my maximum time of disruption, anything past that has a significant impact on the business. The work recovery time is everything that overlays from my recovery point to the maximum time of disruption, all of the work that I'm doing in between. Getting the servers up and running, getting the power restoration, getting the databases restored, verifying all of the services are running, the verification and integrity of all the data, etc. In this course, we discussed the implementation step of the risk management process, implementation documents, NIST 800-53, Rev 4 and Rev 5, overlays, tailoring controls, types of controls, such as management also known as administrative, physical, operational, technical also known as logical, control logs, and incident response.
