The NIST 800 – 100 Information Security Handbook describes with emphasis the need for program managers, system owners and security personnel in the organization to understand the system security planning(SSP) process and adopt the procedure of minimum set of security controls and it should reflect input from various managers with responsibilities concerning the system. The Federal Information Processing Standard (FIPS) 200 minimum security requirements specifies the seventeen security-related control areas for implementing the federal information and information system and the important deliverables in the system development life cycle (SDLC) process.
The document describes system security plans to be living documents that require periodic review, modification, and plans of action and milestones(POA&M) for implementing security controls and that the SSP should be developed and reviewed prior to proceeding with the security certification and accreditation process for the system.
FIPS 199 security category determined for the information system, and that the threat and vulnerability identification and initial risk determination is identified and documented in the system security plan, risk assessment, or equivalent document.
The Chief Information Officer, Information System Owner, Information Owner, Senior Agency information security officer roles and responsibilities in this section are specific to information system security planning, system security plan approval and boundary analysis and security control.
Chapter 8 of the NIST 800-100 discusses the security planning process and its importance in managing risk for information systems. One of the ways to do this is through the usage of FIPS 199 which categorizes an organization’s information system by giving it an impact level of low, moderate, or high. I’ve learned that there isn’t many security requirements needed for a system to meet compliance laws and regulations. These requirements are found in FIPS 200 and contain 17 different control families. It’s important to determine what controls are necessary for your organizations and how you can implement these controls to meet security compliance. Security planning overall is important because it gives your organization the best chance to minimize or avoid risk and keep your systems secure.
I found the number of control families interesting as well and found this to be more manageable than I previously thought. I think it’s easy to get overwhelmed when trying to draft a security plan. This reading helped make it more approachable and also reinforced the importance of effective classification from FIPS199. I think this is the most important step, and may be the most difficult, as it sets the foundation for the security plan. Once the information is classified, the rest of the work seems to fall in line with the guidance provided by this publication.
Key take away from NIST 800-100 was that the system security plan delineates responsibilities and expected behavior of all individuals who access the system. It also points the collaboration of the team in the planning phase. Program managers, system owners, and security personnel in the organization must understand the system security planning process. In addition, users of the information system and those responsible for defining system requirements should also be familiar with the system security planning process, as the system security plan is an important deliverable in the system development life cycle (SDLC) process.49 Those responsible for implementing and managing information systems must participate in addressing security controls to be applied to their systems.
This chapter discusses the importance of security planning to protect information and information systems. The purpose of a system security plan is to meet system security requirements and to implement and plan controls. System owners and security personnel need to be familiar with the system security planning process, and everyone accessing the system needs to assign work and take responsibility. This section addresses the need for proper procedures to review everyone, and roles and responsibilities are a very important part of SSP.
In NIST 800 100 section 8.3 Rules of Behavior (page 70) the publication discusses the rules of behavior for users of a system. These rules clearly delineate responsibilities and expected behaviors of all users.
A signed acceptable use policy is an example of how a control from NIST SP 800-53 could be implemented to address this requirement. An auditor could request to see the Acceptable Use policy from the organization’s handbook and records showing that users acknowledged the policy before using the system. The acceptable use policy should contain the rules describing user responsibilities and expected behavior for information and system usage, security, and privacy. In addition, records should be kept detailing when users acknowledged the policy initially and if they re-acknowledged this periodically as updates happen.
Hey Matt thanks for sharing. Employees at my company are required to recertify their acknowledgment of the organizational Acceptable Use policy on an annual basis.
I think it could also be beneficial for companies to establish some variation of an acceptable use policy on a department to department basis. This document, which could be some kind of standard operating procedure (SOP) or quick reference guide (QRG), wouldn’t have to be as formalized but it could help close any potential rules of behavior gaps in the overarching acceptable use policy.
In NIST 800-100 8.4.2 Security Controls it is explained that
“FIPS 200 provides seventeen minimum security requirements for federal
information and information systems. The requirements represent a broad-based,
balanced information security program that addresses the management, operational,
and technical aspects of protecting the confidentiality, integrity, and availability of
federal information and information systems. An agency must meet the minimum
security requirements in this standard by applying security controls selected in
accordance with NIST SP 800-53 and the designated impact levels of the information
systems.”
This sparked my interest as to what these 17 requirements were, so I did some research and they are as follows
Access Control
Awareness and Training
Audit and Accountability
Certification, Accreditation, and Security Assessments
Very interesting post! I highlighted these same 17 security-related areas in one of my posts as well this week. They all have an important role when it comes to protecting the confidentiality, integrity, and availability of federal information systems and the information processed, stored, and transmitted by those systems. In my other post, I mentioned that contingency planning is always something that sticks out to me. Glad to see one of my classmates also took interest in these 17 security related areas as well!
Chapter 8 explains the minimum set of security controls’ necessary beforehand, and introduces the possible control that would meet requirements. It is important to not miss the responsibility assigned to the user for sure, we often see examples where employees cause security breaches because controls such as training or policies are not in place for people who have access to information systems. The chapter highlights the effort that should be made to delineate responsibilities and expected behavior for all who can access systems.
There are different people who might need to take more roles in the planning process such as chief information officer, information system owner, information owner, senior agency information security officer, and information system security officer.
– CIO: responsible for developing and maintaining an agency wider information security program, designating and SAISO, developing procedures, policies, and control techniques, managing identification, implementation, and assessment of common controls, ensuring personnels’ alignment with controls (responsibilities), assisting senior agency officials.
– System owner: responsible for developing the system security plan, in coordination with owners and system administrations, ISSO and SAISO, and end-users, maintaining the security plan, ensuring the training offered, and assisting the identification, implementation, and assessment of security controls
– Information owner: responsible for establishing the rules for use and protection (rules of behavior), providing input information system on requirements and control, deciding accesses to the system, and privileges.
The importance of security categorization, which is the first step in the risk management process, was a key takeaway from the reading. An organization that does a good job of identifying and categorizing their information systems in terms of confidentiality and criticality can realize the resource efficiency benefits of Fips 199. This way, organizations can focus on implementing security controls categorized as high-impact rather than systems that are categorized as low-impact.
I struggled with this chapter a little bit and reading your comment actually helped me understand it more so thank you for this clear and short break down
I agree, the first step of the Risk Management process is crucial for realizing your system and implementing the security controls that are identified within the categorization phase. The more thorough an organization takes during the first step, the less time they will have implemented and assessing the package since the guidelines and policy are already there. Otherwise, the organization might have to rewrite and reapprove their Security Plan which can be a tedious process.
My key point from this chapter is that each user has its own responsibilities in the system security plan. As the reading said, program managers, system owners, and security personnel in the organization must understand the system security plan process. The purpose of the system security plan is to provide an overview of the security requirements and describe the controls in place or planned to meet the requirements. In fact, if an organization does not have any requirements or policies that people must follow, it can cause a lot of damages such as breaches or ransomware into the system etc..
The IT department is responsible to implement, control, and monitor all the applications, software, hardware that are essential for the operation of the company. In this department, there is specific people responsible to develop the security system plan in accordance with FIPS 199 and specifies the minimum security requirements in seventeen security-related areas. There are also specific documents used that must be periodically reviewed or modified to implement security controls. Controls must not exceeded neither be less than what an organization may have or need. That’s why security owner, information owner, and information system owner are authorized people that must develop a security plan and delineate responsibilities and expected behavior of all individuals who access the system.
I found the 8.3 section on Rules of Behavior to be an intriguing section. It outlines how there should be clearly defined responsibilities and expected behavior from the individuals with access to the system for which the security plan is designed. The purpose of this is to hold users accountable for their actions and to establish consequences for breaking these rules of expected behavior. I found the example chart they had provided (Table 8-1) helpful in seeing what some of the most important details are when creating these rules. Companies need to ensure that all the individuals that are outlined in the security plan and those responsible for its creation and maintaining are clear in what is expected of them, and the consequences for noncompliance.
8.5 Security control selection: speaks about selecting a set of security controls from one of three security control baselines, which are in NIST SP 800-53. The three impacts are low, moderate, and high, with low an agency must meet the minimum requirements for a low baseline. Agencies must meet moderate requirements for a baseline. For high, agencies must use security controls from the high baseline of security to meet the minimum requirements. The figure 8-2 FIPS 199 is associated with 8.5 and in the chart shows, confidentiality, integrity, and availability for low, moderate, and high. For low = limited, for moderate = serious and for high = severe or catastrophic.
True, even security rules are important to ensure proper security control. As mentioned in the article, “security plans are living documents that require periodic review, modification, and plans of action and milestones (POA&M) for implementing security controls. Procedures should be in place outlining who reviews the plans, keeps the plan current, and follows up on planned security controls.”
NIST SP 800-100 identifies the system security plan to be “an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements” (67). Some important takeaways I took from this section are … (1) System security plans should be periodically reviewed and modified to ensure the plan reflects the correct information about the system. (2) While this process is meant to involve information owners, the system owner, and the senior agency information security officer, program managers, system owners, and security personnel in the organization must understand the system security planning process. Not to mention, users of the information system and those responsible for defining system requirements are expected to be informed about the system security planning process. (3) The system security plan is a product of the system development life cycle (SDLC) process. (4) Ultimately, there may be differences in naming conventions for security planning-related roles and how the associated responsibilities are allocated among agency personnel considering agencies have widely varying missions and organizational structures.
These are some pretty good takeaways you have outlined in your post. I especially can appreciate the point you highlighted about periodically reviewing and modifying the system security plan to ensure it reflects the correct information about the system. Indeed ongoing system security plan maintenance is imperative. Changes in system status, functionality, and design should definitely be reviewed at least once annually. “This documentation and its accuracy are imperative for system recertification and reaccreditation activity.”
In chapter 8 of NIST SP 800-100 page 73, it goes over the common security controls that should be in place. Some of the common security controls mentioned that have the CIO,SAISO,ISSO, authorizing officials and information owners involved are during the development, implementation, and assessment of common security controls. This is done for hardware, software and firmware as well. Once the results are from the security assessments are concluded then the security certification and accreditation processes can begin to allow controls to be applied. This is important because without the security assessment reports then there is no supporting documentation in order to apply the controls where it is needed.
I want to highlight that the role of the CIO is very important in the SSP. The CIO is typically responsible for developing and maintaining an organization-wide information security program, and one of the CIO’s responsibilities is to manage the identification, implementation, and evaluation of common security controls. The purpose of a SSP is to provide an overview of system security requirements and describe the controls implemented or planned to meet those requirements. The CIO is responsible for pointing the direction of IT security strategy and for senior manager to execute plans.
Chapter 8 of NIST SP 800-100 talks to compensating controls. If a control cannot be implemented due to requirements not being capable of the system, then a compensated control can be utilized. For example, if a Security Control pertaining to Information at Rest (SC-28 in the NIST 800-53) then another control could be used to compensate if it is equivalent or comparable. Technically, you could also provide the justification that you could fail the control and use the compensating control as a mitigation as you would still be NOT implementing information at rest (such as bitlocker), but you could compensate by using access control mechanisms to prevent certain individuals from accessing information physically such as PE-3 (Physical Access Control). The result is that the information still isn’t encrypted, but logically the only people permitted to access that information would be compensated within the Physical and Environmental Control family. That is if the system resides in an isolated environment which may make physical access much more difficult to justify as compensation if the system can be accessed remotely.
Chapter 8 of NIST 800-100 mentions about Security planning. To have a security planning is important because of the rapidly changing technical environment. the purpose of security planning is to provide an overview of security requirements and describe the controls in place/ planned for meeting those security requirements that find in FIPS 200. Furthermore, when drafting a security plan, it’s better to consider as a whole because “the system security plan is an important deliverable in the system development life cycle. “
I agree with you that having a security plan is important due to the changing technical environment. One of the ways to do this is through the usage of FIPS 199 which categorizes an organization’s information system by giving it an impact level of low, moderate, or high. Security planning gives your organization the best chance to minimize or avoid risk and keep your systems secure.
This chapter focus on security control, on how organizations protect their information and information systems. The security controls/plans show “…security requirements of the system and describe the controls in place or planned for meeting those requirements”. The plan maps out information owners, the system owners, and the senior agency information security officer (SAISO). Those responsible for defining system requirements should also familiar with system security planning process as the security plan is an important deliverable in the system development life cycle process (SDLC). The FIPS 200 requires minimum security for federal information and information system in seventeen security related areas. Federal agencies must meet FIPS200 by security control in NIST (SP)800-53.
I remember last week I posted about the FIPS 199 categorization table. This particular reading mentions the minimum security requirements an agency must meet, which are outlined in FIPS 199. Moreover, it mentions that there are many facets in the process of “selecting the appropriate security controls and assurance requirements for agency information systems to achieve adequate security”. However, the first step in the risk management process is indeed the security categorization of federal information and information systems, as required by FIPS 199. & again we see that same table that I posted about last week which outlines and guides for an understanding of the (Potential Impact) of unauthorized disclosure, modification, destruction, and or disruption of access to use of information or information system.
The following step would be the agency selecting an appropriate set of security controls for their information systems that satisfy the minimum security requirements set forth in FIPS 200. The selected set of security controls must be one of following baselines:
– Low baseline of security controls defined in NIST SP 800-53
– moderate baseline of security controls defined in NIST SP 800-53
– high baseline of security controls defined in NIST SP 800-53
I believe that the reading having mentioned the table again goes to show how important of a step the security categorization is. It really is the point that sets all of the wheels in motion as far as the risk management process for information systems. Getting the categorization correct will help ensure a successful and efficient implementation of controls. Otherwise if the categorization is done incorrectly, it will lead to an inefficient and likely costly use of resources.
Chapter 8 of NIST SP 800-100 walks the reader through security planning, The chapter first points out that all Information systems must be covered by a security plan and classified as either a major application, general support system, or in the case of minor applications, included under the umbrella of an MA or GSS. The chapter then outlines suggested roles to each take on required security planning responsibilities. The chapter then explains that “rules of behavior” must be outlined, distributed, and signed by each user before the user accesses the system. Next, the chapter outlines the needs for system security plan approval. The chapter then reviews security controls, including the minimum security requirements outlined in FIPS 200, The chapter points out that completion and approval dates should be included. Finally, the last section discusses the importance of periodically reviewing and assessing the plan.
Chapter 8 of NIST SP 800-100 provides guidance on the basic information in order to prepare a system security plan in accordance to federal requirements. Looking at this reading, one thing that stood out to me were the “Rules of Behavior” in section 8.3. A security control found in NIST SP 800-53, they describe that all system users responsibilities and expected behaviors should be identified, as well as the consequences of noncompliance. On top of that, all users should have knowledge of the consequences, and agree to them and understand them. Some typical rules of behavior mentioned in table 8-1 include “Delineate responsibilities, expected use of system, and behavior of all user” & “Be clear on consequences of behavior not consistent with rules”
The NIST 800 – 100 Information Security Handbook describes with emphasis the need for program managers, system owners and security personnel in the organization to understand the system security planning(SSP) process and adopt the procedure of minimum set of security controls and it should reflect input from various managers with responsibilities concerning the system. The Federal Information Processing Standard (FIPS) 200 minimum security requirements specifies the seventeen security-related control areas for implementing the federal information and information system and the important deliverables in the system development life cycle (SDLC) process.
The document describes system security plans to be living documents that require periodic review, modification, and plans of action and milestones(POA&M) for implementing security controls and that the SSP should be developed and reviewed prior to proceeding with the security certification and accreditation process for the system.
FIPS 199 security category determined for the information system, and that the threat and vulnerability identification and initial risk determination is identified and documented in the system security plan, risk assessment, or equivalent document.
The Chief Information Officer, Information System Owner, Information Owner, Senior Agency information security officer roles and responsibilities in this section are specific to information system security planning, system security plan approval and boundary analysis and security control.
Chapter 8 of the NIST 800-100 discusses the security planning process and its importance in managing risk for information systems. One of the ways to do this is through the usage of FIPS 199 which categorizes an organization’s information system by giving it an impact level of low, moderate, or high. I’ve learned that there isn’t many security requirements needed for a system to meet compliance laws and regulations. These requirements are found in FIPS 200 and contain 17 different control families. It’s important to determine what controls are necessary for your organizations and how you can implement these controls to meet security compliance. Security planning overall is important because it gives your organization the best chance to minimize or avoid risk and keep your systems secure.
I found the number of control families interesting as well and found this to be more manageable than I previously thought. I think it’s easy to get overwhelmed when trying to draft a security plan. This reading helped make it more approachable and also reinforced the importance of effective classification from FIPS199. I think this is the most important step, and may be the most difficult, as it sets the foundation for the security plan. Once the information is classified, the rest of the work seems to fall in line with the guidance provided by this publication.
Key take away from NIST 800-100 was that the system security plan delineates responsibilities and expected behavior of all individuals who access the system. It also points the collaboration of the team in the planning phase. Program managers, system owners, and security personnel in the organization must understand the system security planning process. In addition, users of the information system and those responsible for defining system requirements should also be familiar with the system security planning process, as the system security plan is an important deliverable in the system development life cycle (SDLC) process.49 Those responsible for implementing and managing information systems must participate in addressing security controls to be applied to their systems.
This chapter discusses the importance of security planning to protect information and information systems. The purpose of a system security plan is to meet system security requirements and to implement and plan controls. System owners and security personnel need to be familiar with the system security planning process, and everyone accessing the system needs to assign work and take responsibility. This section addresses the need for proper procedures to review everyone, and roles and responsibilities are a very important part of SSP.
In NIST 800 100 section 8.3 Rules of Behavior (page 70) the publication discusses the rules of behavior for users of a system. These rules clearly delineate responsibilities and expected behaviors of all users.
A signed acceptable use policy is an example of how a control from NIST SP 800-53 could be implemented to address this requirement. An auditor could request to see the Acceptable Use policy from the organization’s handbook and records showing that users acknowledged the policy before using the system. The acceptable use policy should contain the rules describing user responsibilities and expected behavior for information and system usage, security, and privacy. In addition, records should be kept detailing when users acknowledged the policy initially and if they re-acknowledged this periodically as updates happen.
Hey Matt thanks for sharing. Employees at my company are required to recertify their acknowledgment of the organizational Acceptable Use policy on an annual basis.
I think it could also be beneficial for companies to establish some variation of an acceptable use policy on a department to department basis. This document, which could be some kind of standard operating procedure (SOP) or quick reference guide (QRG), wouldn’t have to be as formalized but it could help close any potential rules of behavior gaps in the overarching acceptable use policy.
In NIST 800-100 8.4.2 Security Controls it is explained that
“FIPS 200 provides seventeen minimum security requirements for federal
information and information systems. The requirements represent a broad-based,
balanced information security program that addresses the management, operational,
and technical aspects of protecting the confidentiality, integrity, and availability of
federal information and information systems. An agency must meet the minimum
security requirements in this standard by applying security controls selected in
accordance with NIST SP 800-53 and the designated impact levels of the information
systems.”
This sparked my interest as to what these 17 requirements were, so I did some research and they are as follows
Access Control
Awareness and Training
Audit and Accountability
Certification, Accreditation, and Security Assessments
Configuration Management
Contingency Planning
Identification and Authentication
Incident Response
Maintenance
Media Protection
Physical and Environmental Protection
Planning
Personnel Security
Risk Assessment
System and Services Acquisition
System and Communications Protection
System and Information Integrity
Hello Jason,
Very interesting post! I highlighted these same 17 security-related areas in one of my posts as well this week. They all have an important role when it comes to protecting the confidentiality, integrity, and availability of federal information systems and the information processed, stored, and transmitted by those systems. In my other post, I mentioned that contingency planning is always something that sticks out to me. Glad to see one of my classmates also took interest in these 17 security related areas as well!
This is a great post as you mention the 17 minimum security requirements for federal information/information systems.
Chapter 8 explains the minimum set of security controls’ necessary beforehand, and introduces the possible control that would meet requirements. It is important to not miss the responsibility assigned to the user for sure, we often see examples where employees cause security breaches because controls such as training or policies are not in place for people who have access to information systems. The chapter highlights the effort that should be made to delineate responsibilities and expected behavior for all who can access systems.
There are different people who might need to take more roles in the planning process such as chief information officer, information system owner, information owner, senior agency information security officer, and information system security officer.
– CIO: responsible for developing and maintaining an agency wider information security program, designating and SAISO, developing procedures, policies, and control techniques, managing identification, implementation, and assessment of common controls, ensuring personnels’ alignment with controls (responsibilities), assisting senior agency officials.
– System owner: responsible for developing the system security plan, in coordination with owners and system administrations, ISSO and SAISO, and end-users, maintaining the security plan, ensuring the training offered, and assisting the identification, implementation, and assessment of security controls
– Information owner: responsible for establishing the rules for use and protection (rules of behavior), providing input information system on requirements and control, deciding accesses to the system, and privileges.
The importance of security categorization, which is the first step in the risk management process, was a key takeaway from the reading. An organization that does a good job of identifying and categorizing their information systems in terms of confidentiality and criticality can realize the resource efficiency benefits of Fips 199. This way, organizations can focus on implementing security controls categorized as high-impact rather than systems that are categorized as low-impact.
Hello Bryan,
I struggled with this chapter a little bit and reading your comment actually helped me understand it more so thank you for this clear and short break down
Hi Bryan,
I agree, the first step of the Risk Management process is crucial for realizing your system and implementing the security controls that are identified within the categorization phase. The more thorough an organization takes during the first step, the less time they will have implemented and assessing the package since the guidelines and policy are already there. Otherwise, the organization might have to rewrite and reapprove their Security Plan which can be a tedious process.
My key point from this chapter is that each user has its own responsibilities in the system security plan. As the reading said, program managers, system owners, and security personnel in the organization must understand the system security plan process. The purpose of the system security plan is to provide an overview of the security requirements and describe the controls in place or planned to meet the requirements. In fact, if an organization does not have any requirements or policies that people must follow, it can cause a lot of damages such as breaches or ransomware into the system etc..
The IT department is responsible to implement, control, and monitor all the applications, software, hardware that are essential for the operation of the company. In this department, there is specific people responsible to develop the security system plan in accordance with FIPS 199 and specifies the minimum security requirements in seventeen security-related areas. There are also specific documents used that must be periodically reviewed or modified to implement security controls. Controls must not exceeded neither be less than what an organization may have or need. That’s why security owner, information owner, and information system owner are authorized people that must develop a security plan and delineate responsibilities and expected behavior of all individuals who access the system.
I found the 8.3 section on Rules of Behavior to be an intriguing section. It outlines how there should be clearly defined responsibilities and expected behavior from the individuals with access to the system for which the security plan is designed. The purpose of this is to hold users accountable for their actions and to establish consequences for breaking these rules of expected behavior. I found the example chart they had provided (Table 8-1) helpful in seeing what some of the most important details are when creating these rules. Companies need to ensure that all the individuals that are outlined in the security plan and those responsible for its creation and maintaining are clear in what is expected of them, and the consequences for noncompliance.
8.5 Security control selection: speaks about selecting a set of security controls from one of three security control baselines, which are in NIST SP 800-53. The three impacts are low, moderate, and high, with low an agency must meet the minimum requirements for a low baseline. Agencies must meet moderate requirements for a baseline. For high, agencies must use security controls from the high baseline of security to meet the minimum requirements. The figure 8-2 FIPS 199 is associated with 8.5 and in the chart shows, confidentiality, integrity, and availability for low, moderate, and high. For low = limited, for moderate = serious and for high = severe or catastrophic.
True, even security rules are important to ensure proper security control. As mentioned in the article, “security plans are living documents that require periodic review, modification, and plans of action and milestones (POA&M) for implementing security controls. Procedures should be in place outlining who reviews the plans, keeps the plan current, and follows up on planned security controls.”
NIST SP 800-100 identifies the system security plan to be “an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements” (67). Some important takeaways I took from this section are … (1) System security plans should be periodically reviewed and modified to ensure the plan reflects the correct information about the system. (2) While this process is meant to involve information owners, the system owner, and the senior agency information security officer, program managers, system owners, and security personnel in the organization must understand the system security planning process. Not to mention, users of the information system and those responsible for defining system requirements are expected to be informed about the system security planning process. (3) The system security plan is a product of the system development life cycle (SDLC) process. (4) Ultimately, there may be differences in naming conventions for security planning-related roles and how the associated responsibilities are allocated among agency personnel considering agencies have widely varying missions and organizational structures.
Hello Elizabeth,
These are some pretty good takeaways you have outlined in your post. I especially can appreciate the point you highlighted about periodically reviewing and modifying the system security plan to ensure it reflects the correct information about the system. Indeed ongoing system security plan maintenance is imperative. Changes in system status, functionality, and design should definitely be reviewed at least once annually. “This documentation and its accuracy are imperative for system recertification and reaccreditation activity.”
In chapter 8 of NIST SP 800-100 page 73, it goes over the common security controls that should be in place. Some of the common security controls mentioned that have the CIO,SAISO,ISSO, authorizing officials and information owners involved are during the development, implementation, and assessment of common security controls. This is done for hardware, software and firmware as well. Once the results are from the security assessments are concluded then the security certification and accreditation processes can begin to allow controls to be applied. This is important because without the security assessment reports then there is no supporting documentation in order to apply the controls where it is needed.
Hi Wilmer,
I want to highlight that the role of the CIO is very important in the SSP. The CIO is typically responsible for developing and maintaining an organization-wide information security program, and one of the CIO’s responsibilities is to manage the identification, implementation, and evaluation of common security controls. The purpose of a SSP is to provide an overview of system security requirements and describe the controls implemented or planned to meet those requirements. The CIO is responsible for pointing the direction of IT security strategy and for senior manager to execute plans.
Chapter 8 of NIST SP 800-100 talks to compensating controls. If a control cannot be implemented due to requirements not being capable of the system, then a compensated control can be utilized. For example, if a Security Control pertaining to Information at Rest (SC-28 in the NIST 800-53) then another control could be used to compensate if it is equivalent or comparable. Technically, you could also provide the justification that you could fail the control and use the compensating control as a mitigation as you would still be NOT implementing information at rest (such as bitlocker), but you could compensate by using access control mechanisms to prevent certain individuals from accessing information physically such as PE-3 (Physical Access Control). The result is that the information still isn’t encrypted, but logically the only people permitted to access that information would be compensated within the Physical and Environmental Control family. That is if the system resides in an isolated environment which may make physical access much more difficult to justify as compensation if the system can be accessed remotely.
Chapter 8 of NIST 800-100 mentions about Security planning. To have a security planning is important because of the rapidly changing technical environment. the purpose of security planning is to provide an overview of security requirements and describe the controls in place/ planned for meeting those security requirements that find in FIPS 200. Furthermore, when drafting a security plan, it’s better to consider as a whole because “the system security plan is an important deliverable in the system development life cycle. “
Hello Hang Nu Song,
I agree with you that having a security plan is important due to the changing technical environment. One of the ways to do this is through the usage of FIPS 199 which categorizes an organization’s information system by giving it an impact level of low, moderate, or high. Security planning gives your organization the best chance to minimize or avoid risk and keep your systems secure.
This chapter focus on security control, on how organizations protect their information and information systems. The security controls/plans show “…security requirements of the system and describe the controls in place or planned for meeting those requirements”. The plan maps out information owners, the system owners, and the senior agency information security officer (SAISO). Those responsible for defining system requirements should also familiar with system security planning process as the security plan is an important deliverable in the system development life cycle process (SDLC). The FIPS 200 requires minimum security for federal information and information system in seventeen security related areas. Federal agencies must meet FIPS200 by security control in NIST (SP)800-53.
I remember last week I posted about the FIPS 199 categorization table. This particular reading mentions the minimum security requirements an agency must meet, which are outlined in FIPS 199. Moreover, it mentions that there are many facets in the process of “selecting the appropriate security controls and assurance requirements for agency information systems to achieve adequate security”. However, the first step in the risk management process is indeed the security categorization of federal information and information systems, as required by FIPS 199. & again we see that same table that I posted about last week which outlines and guides for an understanding of the (Potential Impact) of unauthorized disclosure, modification, destruction, and or disruption of access to use of information or information system.
The following step would be the agency selecting an appropriate set of security controls for their information systems that satisfy the minimum security requirements set forth in FIPS 200. The selected set of security controls must be one of following baselines:
– Low baseline of security controls defined in NIST SP 800-53
– moderate baseline of security controls defined in NIST SP 800-53
– high baseline of security controls defined in NIST SP 800-53
Hi Joshua,
I believe that the reading having mentioned the table again goes to show how important of a step the security categorization is. It really is the point that sets all of the wheels in motion as far as the risk management process for information systems. Getting the categorization correct will help ensure a successful and efficient implementation of controls. Otherwise if the categorization is done incorrectly, it will lead to an inefficient and likely costly use of resources.
Chapter 8 of NIST SP 800-100 walks the reader through security planning, The chapter first points out that all Information systems must be covered by a security plan and classified as either a major application, general support system, or in the case of minor applications, included under the umbrella of an MA or GSS. The chapter then outlines suggested roles to each take on required security planning responsibilities. The chapter then explains that “rules of behavior” must be outlined, distributed, and signed by each user before the user accesses the system. Next, the chapter outlines the needs for system security plan approval. The chapter then reviews security controls, including the minimum security requirements outlined in FIPS 200, The chapter points out that completion and approval dates should be included. Finally, the last section discusses the importance of periodically reviewing and assessing the plan.
Chapter 8 of NIST SP 800-100 provides guidance on the basic information in order to prepare a system security plan in accordance to federal requirements. Looking at this reading, one thing that stood out to me were the “Rules of Behavior” in section 8.3. A security control found in NIST SP 800-53, they describe that all system users responsibilities and expected behaviors should be identified, as well as the consequences of noncompliance. On top of that, all users should have knowledge of the consequences, and agree to them and understand them. Some typical rules of behavior mentioned in table 8-1 include “Delineate responsibilities, expected use of system, and behavior of all user” & “Be clear on consequences of behavior not consistent with rules”