We learn from the NIST 800 100 Information Security Handbook Chapter 8 that it works closely with guidance from the FIPS 199 Categorization. The organization must meet the minimum security requirements in FIPS 199 by selecting the appropriate security controls and assurance requirements as described in NIST SP 800-53. Security categorization of federal, is the first step in the risk management process. Their security controls must meet the minimum security requirements of the FIPS 200. The chosen set of security controls must determine the impact levels: low, medium, high for each security objective Confidentiality, Integrity, and Availability. The main goal of system security planning is to improve the protection of information systems. The protection of a system
must be well documented in a system security plan.
It is recommended that agencies develop policies on their system security planning process. These plans require periodic reviews, modification, and plans of action for applying security controls. The outlines of the procedures should indicate who reviews the plans, keeps the plan up to date, and always follow up on security controls.
Table 8-2 FIPS 199 Categorization provided a quick reference on the categorization of data and resources. It covers all three areas of security objectives: confidentiality, integrity, and availability. The low moderate and high impact levels along with the potential impacts are a great way to quickly identify the impact level against a specific resource within the organization.
Great point Xiduo. The FIPS 199 security categorization seems to be recurring piece of information provided in the federal guidelines. Perhaps, because security categorization sets the entire risk management framework in motion, where the designated impact levels of CIA determines the controls selected, implemented, assessed, authorized and monitored.
A key concept in NIST SP 800-100 is that security plans are documents that are required to be continually reviewed, modified, and plans of action and milestones to make sure security controls are kept up to date. There should be procedures in place for who in the organization needs to be reviewing, updating, and making sure any changes have been implemented. Also, according to FIPS 200, there are seventeen minimum security requirements that should be implemented in order to address the management, operational, and technical aspects of the system which overall will help ensure the three security objectives are being upheld.
Hi Nicholas – I agree that NIST SP 800-100 (and many other regulatory documents) drive home the importance of regular review and upkeep of security plans. Threats to information security develop incredibly quickly, so the security plan to respond to those threats must be adjusted as quickly as possible and reviewed regularly. To facilitate this, the documentation outlines clearly who in the organization is responsible for that upkeep.
I agree with your point. A business is changing everyday, whether it be a process, a vendor, business lines, etc. Each change can introduce further risk, some of the risk may be known and some is unknown. A regular and frequent review of the system security plan is a very good thing to hopefully consider a mitigation to some of the risks introduced by the changes.
This chapter provides overview of the security requirements of the system and describe the controls in place for meeting those requirements. It also emphasizes the importance of drawing system boundary before the system security plan can be developed. These boundaries determine the scope of responsibility for all aspects of system security, from the implementation of technical controls to testing requirements for a system’s certification. Fully establishing a system’s boundaries requires four steps: defining the system type and security requirements, establishing the physical boundaries, determining the logical boundaries, and lastly, documenting the system interconnections and rationales behind those interconnections.
A key takeaway is the need for ongoing system security plan maintenance. Given the dynamic threat landscape, it imperative that SSPs are “living documents”, that is, it should not be one and done. SSPs should be periodically reviewed, specifically – annually, as recommended by the guidance. Such review ensures that any changes to system, design, functionality are updated and SSPs reflect the most accurate and current information system security requirements. Also, the ongoing review and maintenance of these documents facilitates the recertification and reaccreditation process.
Hi Lakshmi, thank you for the input. I think you are correct in identifying that the threat landscape is incredibly dynamic. I think it is also important for those interacting with security plans to understand the evolving nature of the security threat environment. I think this will allow those using the plan to better apply it by understanding that new and evolving threats by not be explicitly covered by the plan.
My key takeaway from this reading is that security plans need to be updated at least annually. Security threats are always evolving, so it is important for new threats to be identified. I was also not very familiar with OMB Circular A-130, so it was interesting to read that this document requires the creation and upkeep of a security plan. These plans are vital to the health of a company
I agree that it is important for companies to continually update their security plans. Personally, I’d even go a step further and require companies to update their plans as needed in addition to annually. Security threats don’t wait for you to update your plans and neither should you.
OMB Circular A-130, Appendix III shows what should the typical rules of behavior covered. It is a form of security control should in NIST SP 800-53. It should clearly explain the expected behavior and responsibilities of all individuals who can access the system. It requires each user to sign the acknowledgment receipt which indicates they have understood, agree, and read to abide by the rules of behavior. The rules should explain the consequences of inconsistent or non-compliant behavior and be available to all users before they are authorized to access the system.
Rules of behavior are an essential aspect of system security plans and essential controls. I think they’re more commonly referred to as acceptable use policies. Rules of behavior need to clearly define the responsibilities and expected behavior of ALL individuals using a system. Most policies and procedures people probably won’t read. But the rules of behavior require their own signature because they are that important. The non-compliance consequences also help users understand how important compliant behavior is.
Jonathan, thank you for your input. in addition to defining the responsibilities and expectations, policies and procedures also hold members accountable if someone goes wrong.
The roles and responsibility section was informative, as many of the titles are similar. Each role has their own distinct and individual responsibilities. Specifically the differences between the Information System Owner, the Information Owner, and the Information System Security Officer were of particular interest as I did not know the difference. The information System Owner is responsible for all things related to the system or application such as development and operations and maintenance, whereas the Information Owner is owner of the data that flows through the system and is responsible for controls to protect the data lifecycle process. The Information System Security Officer is responsible to ensure the operational security of the system.
Hi Christa. That’s an excellent point that you bring up here. Separation of duties is critical to effective internal control because it reduces the risk of both erroneous and intentional malice actions that may be caused by internal employees. All organizations and businesses should use NIST 800 100 as guidance to separate functional responsibilities to ensure that errors, intentional or unintentional actions. By separating deities among employees, one employee can discover another person’s mistakes within the organization.
What stood out to me from this text was the discussion of common security controls. NIST SP 800-100 clearly defines common security controls as security controls that apply to all agency IS systems, a group of IS systems, or common hardware or software at multiple sites. The text also identifies the method in which these are identified, which includes several IS officials in an agency-wide collaborative effort. I found this especially interesting since I have never been exposed to the approach of separating security control into common security controls. I find this approach to be extremely efficient and intuitive for enterprises, as the standardized documentation, implementation, and review adds a lot of efficiency to the security control process. I think this is especially true for larger organizations where inefficiencies sprout up where processes are being repeated since different departments or sites are not being communicative.
One of the key things that stood out to me from this reading was about the use of common security controls versus system-specific security controls. The chapter mentioned that the concept of using these two classes of controls is straightforward, but that applying it takes planning, perseverance, and coordination. I think this is a really good point to make and I can definitely see how the use of common security controls across an agency or organization could require a lot of effort. The part that stood out most to me though was about the increase in agency-level risk should there be a failure of one of the common security controls, since there may be multiple information systems relying on those controls operating effectively. As an auditor or security professional, you would have to view the common security controls from a bigger picture perspective rather than just at the individual information system level.
I think the concept of common security controls and the way to implement them is key to this chapter. Assessment and approval of common security controls, and maintaining documentation and re-assessing those controls, can save an organization time and money. It allows different business units with similar information systems to reference existing documentation for a control, easing implementation. Importantly, if a common control is poorly assessed (perhaps it is not as effective at mitigating a particular risk as the organization originally thought), then implementing that control across the organization creates significant systemic risk. It is imperative that common controls be re-assessed frequently and accurately for this reason.
Chapter 8 of the NIST 800 100 Information Security Handbook outlines the significance of security planning to protect information and information systems. A key take away I learned, is the objective of the system security plan or (SSP) is to summarize the security requirements of the system and describe the controls in place. The SSP also outlines the responsibilities of the individuals who access the systems. Once the plan is accepted it should be consistent with FIPS 199 in order to be certified. The results from the certification are used to monitor, reevaluate risks, and update the plan.
To build off of your point, it was interesting to see how other documents we’ve read, such as FIPS 199, are implemented in other documentation. It helps paint the entire picture of an organizations security plan. These templates all help organizations build a comprehensive security plan.
My biggest takeaway from the reading is the section on “Rules of Behavior.” This is not a term that I’ve heard before. That being said, it makes a lot of sense and really draws out the division of labor, alongside what is appropriate. For example, I’m sure Rules of Behavior would cover a scenario where a user is using his access to look up customer information for personal use, rather than business use. And finally, it also lays out the punishment for users who do not follow these rules. I personally like Rules of Behavior because it goes beyond the simple access control and litigates behavior for approved users.
The key point i took out of the reading is that the system security plan should be revised on a regular basis. This to me makes sense, as the business changes processes or vendors, this implements new risks, some of the risks are known, however, most may be unknown. The frequent review will help mitigate some of the risks.
We learn from the NIST 800 100 Information Security Handbook Chapter 8 that it works closely with guidance from the FIPS 199 Categorization. The organization must meet the minimum security requirements in FIPS 199 by selecting the appropriate security controls and assurance requirements as described in NIST SP 800-53. Security categorization of federal, is the first step in the risk management process. Their security controls must meet the minimum security requirements of the FIPS 200. The chosen set of security controls must determine the impact levels: low, medium, high for each security objective Confidentiality, Integrity, and Availability. The main goal of system security planning is to improve the protection of information systems. The protection of a system
must be well documented in a system security plan.
It is recommended that agencies develop policies on their system security planning process. These plans require periodic reviews, modification, and plans of action for applying security controls. The outlines of the procedures should indicate who reviews the plans, keeps the plan up to date, and always follow up on security controls.
Table 8-2 FIPS 199 Categorization provided a quick reference on the categorization of data and resources. It covers all three areas of security objectives: confidentiality, integrity, and availability. The low moderate and high impact levels along with the potential impacts are a great way to quickly identify the impact level against a specific resource within the organization.
Great point Xiduo. The FIPS 199 security categorization seems to be recurring piece of information provided in the federal guidelines. Perhaps, because security categorization sets the entire risk management framework in motion, where the designated impact levels of CIA determines the controls selected, implemented, assessed, authorized and monitored.
A key concept in NIST SP 800-100 is that security plans are documents that are required to be continually reviewed, modified, and plans of action and milestones to make sure security controls are kept up to date. There should be procedures in place for who in the organization needs to be reviewing, updating, and making sure any changes have been implemented. Also, according to FIPS 200, there are seventeen minimum security requirements that should be implemented in order to address the management, operational, and technical aspects of the system which overall will help ensure the three security objectives are being upheld.
Hi Nicholas – I agree that NIST SP 800-100 (and many other regulatory documents) drive home the importance of regular review and upkeep of security plans. Threats to information security develop incredibly quickly, so the security plan to respond to those threats must be adjusted as quickly as possible and reviewed regularly. To facilitate this, the documentation outlines clearly who in the organization is responsible for that upkeep.
Nicholas,
I agree with your point. A business is changing everyday, whether it be a process, a vendor, business lines, etc. Each change can introduce further risk, some of the risk may be known and some is unknown. A regular and frequent review of the system security plan is a very good thing to hopefully consider a mitigation to some of the risks introduced by the changes.
This chapter provides overview of the security requirements of the system and describe the controls in place for meeting those requirements. It also emphasizes the importance of drawing system boundary before the system security plan can be developed. These boundaries determine the scope of responsibility for all aspects of system security, from the implementation of technical controls to testing requirements for a system’s certification. Fully establishing a system’s boundaries requires four steps: defining the system type and security requirements, establishing the physical boundaries, determining the logical boundaries, and lastly, documenting the system interconnections and rationales behind those interconnections.
A key takeaway is the need for ongoing system security plan maintenance. Given the dynamic threat landscape, it imperative that SSPs are “living documents”, that is, it should not be one and done. SSPs should be periodically reviewed, specifically – annually, as recommended by the guidance. Such review ensures that any changes to system, design, functionality are updated and SSPs reflect the most accurate and current information system security requirements. Also, the ongoing review and maintenance of these documents facilitates the recertification and reaccreditation process.
Hi Lakshmi, thank you for the input. I think you are correct in identifying that the threat landscape is incredibly dynamic. I think it is also important for those interacting with security plans to understand the evolving nature of the security threat environment. I think this will allow those using the plan to better apply it by understanding that new and evolving threats by not be explicitly covered by the plan.
My key takeaway from this reading is that security plans need to be updated at least annually. Security threats are always evolving, so it is important for new threats to be identified. I was also not very familiar with OMB Circular A-130, so it was interesting to read that this document requires the creation and upkeep of a security plan. These plans are vital to the health of a company
Hi Charlie,
I agree that it is important for companies to continually update their security plans. Personally, I’d even go a step further and require companies to update their plans as needed in addition to annually. Security threats don’t wait for you to update your plans and neither should you.
OMB Circular A-130, Appendix III shows what should the typical rules of behavior covered. It is a form of security control should in NIST SP 800-53. It should clearly explain the expected behavior and responsibilities of all individuals who can access the system. It requires each user to sign the acknowledgment receipt which indicates they have understood, agree, and read to abide by the rules of behavior. The rules should explain the consequences of inconsistent or non-compliant behavior and be available to all users before they are authorized to access the system.
Rules of behavior are an essential aspect of system security plans and essential controls. I think they’re more commonly referred to as acceptable use policies. Rules of behavior need to clearly define the responsibilities and expected behavior of ALL individuals using a system. Most policies and procedures people probably won’t read. But the rules of behavior require their own signature because they are that important. The non-compliance consequences also help users understand how important compliant behavior is.
Jonathan, thank you for your input. in addition to defining the responsibilities and expectations, policies and procedures also hold members accountable if someone goes wrong.
The roles and responsibility section was informative, as many of the titles are similar. Each role has their own distinct and individual responsibilities. Specifically the differences between the Information System Owner, the Information Owner, and the Information System Security Officer were of particular interest as I did not know the difference. The information System Owner is responsible for all things related to the system or application such as development and operations and maintenance, whereas the Information Owner is owner of the data that flows through the system and is responsible for controls to protect the data lifecycle process. The Information System Security Officer is responsible to ensure the operational security of the system.
Hi Christa. That’s an excellent point that you bring up here. Separation of duties is critical to effective internal control because it reduces the risk of both erroneous and intentional malice actions that may be caused by internal employees. All organizations and businesses should use NIST 800 100 as guidance to separate functional responsibilities to ensure that errors, intentional or unintentional actions. By separating deities among employees, one employee can discover another person’s mistakes within the organization.
What stood out to me from this text was the discussion of common security controls. NIST SP 800-100 clearly defines common security controls as security controls that apply to all agency IS systems, a group of IS systems, or common hardware or software at multiple sites. The text also identifies the method in which these are identified, which includes several IS officials in an agency-wide collaborative effort. I found this especially interesting since I have never been exposed to the approach of separating security control into common security controls. I find this approach to be extremely efficient and intuitive for enterprises, as the standardized documentation, implementation, and review adds a lot of efficiency to the security control process. I think this is especially true for larger organizations where inefficiencies sprout up where processes are being repeated since different departments or sites are not being communicative.
One of the key things that stood out to me from this reading was about the use of common security controls versus system-specific security controls. The chapter mentioned that the concept of using these two classes of controls is straightforward, but that applying it takes planning, perseverance, and coordination. I think this is a really good point to make and I can definitely see how the use of common security controls across an agency or organization could require a lot of effort. The part that stood out most to me though was about the increase in agency-level risk should there be a failure of one of the common security controls, since there may be multiple information systems relying on those controls operating effectively. As an auditor or security professional, you would have to view the common security controls from a bigger picture perspective rather than just at the individual information system level.
I think the concept of common security controls and the way to implement them is key to this chapter. Assessment and approval of common security controls, and maintaining documentation and re-assessing those controls, can save an organization time and money. It allows different business units with similar information systems to reference existing documentation for a control, easing implementation. Importantly, if a common control is poorly assessed (perhaps it is not as effective at mitigating a particular risk as the organization originally thought), then implementing that control across the organization creates significant systemic risk. It is imperative that common controls be re-assessed frequently and accurately for this reason.
Chapter 8 of the NIST 800 100 Information Security Handbook outlines the significance of security planning to protect information and information systems. A key take away I learned, is the objective of the system security plan or (SSP) is to summarize the security requirements of the system and describe the controls in place. The SSP also outlines the responsibilities of the individuals who access the systems. Once the plan is accepted it should be consistent with FIPS 199 in order to be certified. The results from the certification are used to monitor, reevaluate risks, and update the plan.
Hi Elias
To build off of your point, it was interesting to see how other documents we’ve read, such as FIPS 199, are implemented in other documentation. It helps paint the entire picture of an organizations security plan. These templates all help organizations build a comprehensive security plan.
My biggest takeaway from the reading is the section on “Rules of Behavior.” This is not a term that I’ve heard before. That being said, it makes a lot of sense and really draws out the division of labor, alongside what is appropriate. For example, I’m sure Rules of Behavior would cover a scenario where a user is using his access to look up customer information for personal use, rather than business use. And finally, it also lays out the punishment for users who do not follow these rules. I personally like Rules of Behavior because it goes beyond the simple access control and litigates behavior for approved users.
The key point i took out of the reading is that the system security plan should be revised on a regular basis. This to me makes sense, as the business changes processes or vendors, this implements new risks, some of the risks are known, however, most may be unknown. The frequent review will help mitigate some of the risks.