Most data in federal information systems is sensitive, and protection of information systems is part of good management practice. The goal of system security planning is to improve the protection of information system resources, and system protection must be documented in the system security plan. The creation of a security plan begins by classifying systems by impact level using the FIPS 199 standard. This plan includes a summary of all security requirements and the security controls implemented to support those requirements. The system security plan document requires periodic review, recertification, revision, and action plans to implement its supporting controls. The organization should also have procedures in place to determine who will review the plan, update the plan, and follow up on established controls. The program must also be accredited and accredited.
A System Security Plan requires some important steps that must be taken in consideration in order to implement the specific controls related to informations systems security. In order to start this process, all people participating in this plan must be eligible to do so. In other terms, specific controls must be implemented by people that are only authorized to complete the process and approves by the designated Authorizing Official.
The purpose of a System Security Plan is to “provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements.”
In this sense FIPS 199 helps us categorize the security information system impact levels (low, moderate, high) based on the organization assets.
In my opinion, this plan is important because it allows companies to provide detailed information to support many processes and activities in the system development life cycle. A thorough system security plan in place will assign all the specific areas that need more protection and make sure that the appropriate resources, processes and procedures are implemented in the system to reduce any risks that may be harmful for the company .
Overall, based on the reading, I would say that any organization must have this plan in their security objective and must come up with the necessary tools, procedures and processes they need to implement in their system. Major/minor applications, general support system are essential for the operation of the organization. If one application or software does not align to the company mission and vision, the company must reevaluate their security controls to make sure they have the correct processes for their system
I think you raise an important point about a company’s mission and vision. These are important indicators of the “tone at the top” which informs an organization’s valuation of security. If a company doesn’t value security, they may opt to assume more risk since they feel the costs of implementing a robust plan outweigh the returns and/or don’t align with their current focus. This can result in technical debt should the company change its strategy in the future and decide to increase their security posture.
In section 3.12, Laws, Regulations, and Policies Affecting the System, the publication notes that laws affecting the confidentiality, integrity, and availability of the system be noted in the security plan. The level to which laws are listed is up to the agency drafting the plan.
An example law that should be included in this section of the plan is the Health Insurance Portability and Accountability Act (HIPAA). In this case, systems containing patient data may require additional steps to disclose the breach of information during an incident. In addition, controls may need to be implemented as the data classification rating may increase as HIPAA has strict confidentiality requirements.
Very interesting post. I actually formed this week’s one question to ask my fellow classmates to facilitate discussion around this section of the reading (3.12 Laws, Regulations, and Policies Affecting the System). I appreciate you using HIPAA as an example! That is a law that I am very aware of due to working in a few different health care environments over the years. However, it wasn’t one that I thought of right away when reading this section. The reading referenced the ‘Privacy Act of 1974’, and I was not familiar with that particular legislation. Thanks again, because I really appreciate the example you have given in this post!
After reading “Guide for Developing Security Plans for Federal Information Systems”, I learned that the main purpose of security planning is to “improve protection of information system resources. Every federal system requires a plan of protection. This security plan is meant to provide a detailed overview of the requirements of the system and lay out what controls are in place to help achieve these requirements. Through this plan responsibilities/duties will be assigned to each user who has authorization to access the system. This plan is very important for a company because you want to make sure that everyone is on the same page and in line with the mission/values of the company.
The one key point, I learned from the NIST 800-18r1 reading is the importance of “rules of behavior”. I think it’s a great way to keep employees or any person who has access to information systems accountable for their actions. NIST explains the steps would be necessary to complete in order to keep federal information systems, but it’s important that federal assets’ user risk is eliminated as much as possible. Hopefully, with rules of behavior guidance, users are aware of the responsibilities, expected use, limits on interconnections, service provisions, restoration priorities, consequences of inconsistent behavior and this awareness becomes control that avoids user behavior risk. Since the “examples of controls contained in rules of behavior” lists work-at-home and connection to internet topics, it made me think how much adaption federal agencies had to make to this guidance after covid started and the working environment has changed.
You bring up a good point about Covid and how it changed many working environments, I think many will agree working from home is different from working in the office and brings about its own challenges, dealing with a spouse, children or anyone else who may live there, sometimes it can become tricky to navigate a normal work day. I agree it took agencies much adaption to address these issues in the rules of behavior for both office and home environments.
I can tell you that COVID was a challenge for all agencies dealing with data sensitive information systems as restrictions that are imposed on organizations make it more difficult to gain access to certain systems. The other issue is approving the use of sensitive data to be transported from the workplace and into the home. Adding these extra layers, despite the precautions such as signing agreements stating the users will not disclose data and take the necessary precautions, this still results in loss of security as you’re increasing the likelihood for spillage. Even if the spill was indirectly from human error, or purposely from taking advantage of new policies.
I am personally curious in the long term results of what COVID changed and how much financial impact it had regarding new policies, whether they were significant or not.
One of the key point that i took from the reading is the section 1.4 which is about the systems Inventory and Federal Information Processing Standards (FIPS 199)
A system inventory is a one-stop resource for discovering information about the information resources owned or operated by an organization. Many organizations, from corporations to federal agencies typically have different information resources to meet various needs.
FISMA requires that agencies have in place an information systems inventory. All information systems in the inventory should be categorized using FIPS 199 as a first step in the system security planning activity. FIPS 199 is the mandatory standard to be used by all federal agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to impact.
Security categorization standards for information and information systems provide a common framework and understanding for expressing security that, for the federal government, promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices.
The NIST SP 800-18r1 guide describes the purpose for developing a security plan as “[providing] an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements” (39). Aside from that, the objective of system security planning is to improve the protection of information system resources and outline responsibilities and expected behavior of all individuals who have access to the system. Considering federal systems such as Law Enforcement and Emergency Services systems, Financial systems, and Health systems have highly classified information and applications that are critical to the agency’s mission, it is imperative that the protection of these systems be documented in a SSP. This can explain why FedRAMP introduced their High Baseline to account for the government’s most sensitive environments with special emphasis on data that involves the protection of life and financial ruin.
The NIST 800-18 R1 describes how to outline plans for Information Systems. One of the subjects it mentions is when developing security controls derived from NIST 800-53 and tailoring the controls depending on the type of information system. Fielding a system requires a set of “common” controls that generally applies to all information systems. However, for sets of more specific controls some information systems may be “system specific” and delegate those controls to the Information System Owner (ISO). These can also be hybrid depending on the requirements of the system – especially if the controls are “enhancements” of other controls.
The reason I highlighted this section of the guide is that the requirements for information systems can change depending on the environment. Stand-alone enclaves that have no internet access will have less restrictive security requirements then enterprise systems that are fielded across thousands of employees with internet access. For example; Enterprise Security Suites may not be entirely applicable to stand-alone systems as they can’t update their endpoint servers through conventional means (receiving patches through the internet). Or they may use real-time operating systems that cannot utilize certain security controls due to resource costs; which would change the applicable baseline outlined within the security plan.
That‘s an interesting point you mentioned, information system requirements can change with the environment. I think data should be collected on all information systems, including the physical environment, etc., to help in the first step of risk assessment. Develop a plan for defining security categories for systems and prioritizing risks based on the potential impact of a breach of confidentiality, integrity, and availability of the system as described in FIPS 900.
The guide for the system security plan’s last section (3.16) highlight that it is important for the plan to be periodically reviewed. I found it interesting that the guide stated that an annual review of these plans should be sufficient. It is vital to make sure that the system security plans are current with the with all the information that it requires. I believe that some systems may require the updates to happen more frequently, which the section does outline is suggested if appropriate. My takeaway is that it is better to be on the more liberal side of the frequency in which you review these plans. If the plans are reviewed too infrequently and crucial data is incorrect then it could lead to erroneous management of the system.
The third and last part of NIST 800-18 R1 is Plan Development. This document guides readers in writing a system security plan. It is important that the plan should be written in logical steps, so the C-suite/ Board of directors, information security managers can revise their plans how the IS security plans are to be controlled and accessed prior to initiation of the activity.
FIPS 199 and 200 are is the mandatory standard to be used to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to impact. FIPS 199 and FIPS 200 Security categorization standards for information and information systems provide a common framework and understanding for expressing security that, for the federal government, promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices. interesting with security standards for information. The security objectives and categorization refer to the CIA triad of Confidentiality, Integrity, and Availability. These security categories are ranked with the approriate potential impact of Low, Moderate, and High and the FIPS 200 addresses the specification of seventeen minimum security requirements for federal information and information systems.
Organizations are made to comply with the federal standard and to determine the security category of their information system in accordance with FIPS 199 and FIPS 200 Standards for Security Categorization and not forgeting to apply the NIST SP 800-53.
Security controls are split into three groups: management, operational, and technical. Technical controls are automated and run by computer systems while operational controls are run by people. management controls are controls that help manage the entire information system. All three types of controls are necessary to successfully secure systems as no one type of control would be enough to keep any system secure. All three types of controls work together to build a robust system.
I also thought it was fascinating that these security controls were broken down into three groups. Every federal system requires a plan of protection, and all three of these controls are necessary if you want to achieve the most secure system possible. Making sure all employees are aware of the controls and guidelines set in place is vital so that everyone is on the same page.
Something that stood out to me when reading the NIST SP 800-18r1 was the Table 1: FIPS 199 Categorization at the top of page 20.
It’s basically an outline and guide which shows the (Potential Impact) of unauthorized disclosure, modification, destruction, and or disruption of access to use of information or an information system. Moreover section 3.2 System Categorization says, “Each system identified in the agency’s system inventory must be categorized using FIPS 199.” (NIST SP 800-18r1)
The table shows the CIA triad / Security Objectives on the left hand side in the vertical direction. We can see the objectives of Confidentiality, Integrity, and Availability being defined adequately. & then we see the potential adverse impacts of each if they were to be compromised. In bold we see that a low potential impact is considered limited. A moderate impact would be regarded as serious, while the high potential impacts of the CIA triad are all considered to be (& this word always worries me) CATASTROPHIC!
Hi Joshua, yes this is something that everyone should be worried about because if the. unauthorized disclosure of information, modification, destruction, or disruption is done over giving the wrong person access it can be catastrophic whether it is intention or unintentional it is a lot of responsibility to handle.
I felt the reading provided quality information and guidance on the components of developing security plans. Some of crucial components include identifying key points of contact (i.e. system name/owner, authorizing officials, etc.), identifying system purpose, environment, and usage, and identifying system interdependencies. These components are absolutely crucial when deploying security controls but, as the reading notes, it’s essential that once the security plans are deployed they must also be periodically reviewed (at least annually) to ensure security objectives are still consistently being met.
The key point that I learned this week was about the system owner 3.3 in NIST Sp800-18r1. The system owner is a designated owner who is identified in the security plan for each system. They are a key point of contact for the system and are responsible for coordinating system development life cycle (SDLC) The system owner must have expert knowledge of the capabilities of their system.
Hi Corey thanks for sharing and I agree identifying and establishing a system owner for each system is important. If organizations have excess resources it probably be a good idea to a designated backup system owner in cases where the main system owner isn’t available. Doing so could be very beneficial if a component of the system security plan needed to be updated in their absence. Additionally, it could also aid the organizations succession planning process.
One key point I took away from this article was from section 10.2 Risk Mitigation, specifically Figure 10-4, and the reason for that is due to a main point I took away from the introduction, which is that “the principal goal of an organization’s risk management process is to protect the organization and its ability to perform its mission, not just its information assets”. It is impossible to completely eliminate risk, so it is essential to have the necessary risk-reducing controls as recommended by NIST SP 800-53. Figure 10-4 is an easy to understand flowchart of how the process works by looking at key factors to determine if a risk is acceptable or unacceptable in order to determine the necessity of implementing additional controls to mitigate a risk if unacceptable.
In NIST SP800-18r1 rules of behavior stood out to me for implementing controls for users. It gives a good example of how controls and responsibilities of the users are delineated through expected uses and behavior of user. It also mentions point of access to certain fountains such as work from home, dial in access, The limits of interconnection, provisioning/restoration and consequences are also great ways to organize the controls as once users are aware of their limits and the do’s and don’ts then there should be a less internal attacks whether it be intentional or unintentional.
In NIST SP 18r1 the chapter we focused on describes the process on writing a security plan, including the steps to follow in plan development, structure/content, & how to effectively support system security planning. In this chapter a key point that stood out to me was section 3.16, which is ongoing security plan maintenance. This part stood out to me because once the system security plan has been completed, it’s not the end. The plan must be continually assessed for things such as functionality & design to ensure that the plan continues to contain accurate system information, as this is critical to system certification activity. This assessment should occur annually, with some examples of things to look out for being a change in system architecture, system status, the authorizing official, etc.
The protection of information security is not the responsibility of anyone person in the organization, all are responsible for the protect assets of the organization. All staff, senior management, and users are responsible for the information security protection, The main objective of information security planning is to improve the protection of Information Technology resources, all organizations always have some level of sensitivity and required protection, the protection of available assets of the organization must be documented in the system security plan.
When anyone takes charge of system security in the organization must be aware of the security program component and government system security requirements to ensure compliance. These are included for CIOs, CISOs, and security managers at all levels. All staff are responsible for the system security planning,
Most data in federal information systems is sensitive, and protection of information systems is part of good management practice. The goal of system security planning is to improve the protection of information system resources, and system protection must be documented in the system security plan. The creation of a security plan begins by classifying systems by impact level using the FIPS 199 standard. This plan includes a summary of all security requirements and the security controls implemented to support those requirements. The system security plan document requires periodic review, recertification, revision, and action plans to implement its supporting controls. The organization should also have procedures in place to determine who will review the plan, update the plan, and follow up on established controls. The program must also be accredited and accredited.
A System Security Plan requires some important steps that must be taken in consideration in order to implement the specific controls related to informations systems security. In order to start this process, all people participating in this plan must be eligible to do so. In other terms, specific controls must be implemented by people that are only authorized to complete the process and approves by the designated Authorizing Official.
The purpose of a System Security Plan is to “provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements.”
In this sense FIPS 199 helps us categorize the security information system impact levels (low, moderate, high) based on the organization assets.
In my opinion, this plan is important because it allows companies to provide detailed information to support many processes and activities in the system development life cycle. A thorough system security plan in place will assign all the specific areas that need more protection and make sure that the appropriate resources, processes and procedures are implemented in the system to reduce any risks that may be harmful for the company .
Overall, based on the reading, I would say that any organization must have this plan in their security objective and must come up with the necessary tools, procedures and processes they need to implement in their system. Major/minor applications, general support system are essential for the operation of the organization. If one application or software does not align to the company mission and vision, the company must reevaluate their security controls to make sure they have the correct processes for their system
Ornella,
I think you raise an important point about a company’s mission and vision. These are important indicators of the “tone at the top” which informs an organization’s valuation of security. If a company doesn’t value security, they may opt to assume more risk since they feel the costs of implementing a robust plan outweigh the returns and/or don’t align with their current focus. This can result in technical debt should the company change its strategy in the future and decide to increase their security posture.
In section 3.12, Laws, Regulations, and Policies Affecting the System, the publication notes that laws affecting the confidentiality, integrity, and availability of the system be noted in the security plan. The level to which laws are listed is up to the agency drafting the plan.
An example law that should be included in this section of the plan is the Health Insurance Portability and Accountability Act (HIPAA). In this case, systems containing patient data may require additional steps to disclose the breach of information during an incident. In addition, controls may need to be implemented as the data classification rating may increase as HIPAA has strict confidentiality requirements.
Hey Matthew,
Very interesting post. I actually formed this week’s one question to ask my fellow classmates to facilitate discussion around this section of the reading (3.12 Laws, Regulations, and Policies Affecting the System). I appreciate you using HIPAA as an example! That is a law that I am very aware of due to working in a few different health care environments over the years. However, it wasn’t one that I thought of right away when reading this section. The reading referenced the ‘Privacy Act of 1974’, and I was not familiar with that particular legislation. Thanks again, because I really appreciate the example you have given in this post!
After reading “Guide for Developing Security Plans for Federal Information Systems”, I learned that the main purpose of security planning is to “improve protection of information system resources. Every federal system requires a plan of protection. This security plan is meant to provide a detailed overview of the requirements of the system and lay out what controls are in place to help achieve these requirements. Through this plan responsibilities/duties will be assigned to each user who has authorization to access the system. This plan is very important for a company because you want to make sure that everyone is on the same page and in line with the mission/values of the company.
The one key point, I learned from the NIST 800-18r1 reading is the importance of “rules of behavior”. I think it’s a great way to keep employees or any person who has access to information systems accountable for their actions. NIST explains the steps would be necessary to complete in order to keep federal information systems, but it’s important that federal assets’ user risk is eliminated as much as possible. Hopefully, with rules of behavior guidance, users are aware of the responsibilities, expected use, limits on interconnections, service provisions, restoration priorities, consequences of inconsistent behavior and this awareness becomes control that avoids user behavior risk. Since the “examples of controls contained in rules of behavior” lists work-at-home and connection to internet topics, it made me think how much adaption federal agencies had to make to this guidance after covid started and the working environment has changed.
Hello Miray,
You bring up a good point about Covid and how it changed many working environments, I think many will agree working from home is different from working in the office and brings about its own challenges, dealing with a spouse, children or anyone else who may live there, sometimes it can become tricky to navigate a normal work day. I agree it took agencies much adaption to address these issues in the rules of behavior for both office and home environments.
Hi Miray,
I can tell you that COVID was a challenge for all agencies dealing with data sensitive information systems as restrictions that are imposed on organizations make it more difficult to gain access to certain systems. The other issue is approving the use of sensitive data to be transported from the workplace and into the home. Adding these extra layers, despite the precautions such as signing agreements stating the users will not disclose data and take the necessary precautions, this still results in loss of security as you’re increasing the likelihood for spillage. Even if the spill was indirectly from human error, or purposely from taking advantage of new policies.
I am personally curious in the long term results of what COVID changed and how much financial impact it had regarding new policies, whether they were significant or not.
One of the key point that i took from the reading is the section 1.4 which is about the systems Inventory and Federal Information Processing Standards (FIPS 199)
A system inventory is a one-stop resource for discovering information about the information resources owned or operated by an organization. Many organizations, from corporations to federal agencies typically have different information resources to meet various needs.
FISMA requires that agencies have in place an information systems inventory. All information systems in the inventory should be categorized using FIPS 199 as a first step in the system security planning activity. FIPS 199 is the mandatory standard to be used by all federal agencies to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to impact.
Security categorization standards for information and information systems provide a common framework and understanding for expressing security that, for the federal government, promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices.
The NIST SP 800-18r1 guide describes the purpose for developing a security plan as “[providing] an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements” (39). Aside from that, the objective of system security planning is to improve the protection of information system resources and outline responsibilities and expected behavior of all individuals who have access to the system. Considering federal systems such as Law Enforcement and Emergency Services systems, Financial systems, and Health systems have highly classified information and applications that are critical to the agency’s mission, it is imperative that the protection of these systems be documented in a SSP. This can explain why FedRAMP introduced their High Baseline to account for the government’s most sensitive environments with special emphasis on data that involves the protection of life and financial ruin.
The NIST 800-18 R1 describes how to outline plans for Information Systems. One of the subjects it mentions is when developing security controls derived from NIST 800-53 and tailoring the controls depending on the type of information system. Fielding a system requires a set of “common” controls that generally applies to all information systems. However, for sets of more specific controls some information systems may be “system specific” and delegate those controls to the Information System Owner (ISO). These can also be hybrid depending on the requirements of the system – especially if the controls are “enhancements” of other controls.
The reason I highlighted this section of the guide is that the requirements for information systems can change depending on the environment. Stand-alone enclaves that have no internet access will have less restrictive security requirements then enterprise systems that are fielded across thousands of employees with internet access. For example; Enterprise Security Suites may not be entirely applicable to stand-alone systems as they can’t update their endpoint servers through conventional means (receiving patches through the internet). Or they may use real-time operating systems that cannot utilize certain security controls due to resource costs; which would change the applicable baseline outlined within the security plan.
Hi Michael,
That‘s an interesting point you mentioned, information system requirements can change with the environment. I think data should be collected on all information systems, including the physical environment, etc., to help in the first step of risk assessment. Develop a plan for defining security categories for systems and prioritizing risks based on the potential impact of a breach of confidentiality, integrity, and availability of the system as described in FIPS 900.
The guide for the system security plan’s last section (3.16) highlight that it is important for the plan to be periodically reviewed. I found it interesting that the guide stated that an annual review of these plans should be sufficient. It is vital to make sure that the system security plans are current with the with all the information that it requires. I believe that some systems may require the updates to happen more frequently, which the section does outline is suggested if appropriate. My takeaway is that it is better to be on the more liberal side of the frequency in which you review these plans. If the plans are reviewed too infrequently and crucial data is incorrect then it could lead to erroneous management of the system.
The third and last part of NIST 800-18 R1 is Plan Development. This document guides readers in writing a system security plan. It is important that the plan should be written in logical steps, so the C-suite/ Board of directors, information security managers can revise their plans how the IS security plans are to be controlled and accessed prior to initiation of the activity.
FIPS 199 and 200 are is the mandatory standard to be used to categorize all information and information systems collected or maintained by or on behalf of each agency based on the objectives of providing appropriate levels of information security according to impact. FIPS 199 and FIPS 200 Security categorization standards for information and information systems provide a common framework and understanding for expressing security that, for the federal government, promotes: (i) effective management and oversight of information security programs, including the coordination of information security efforts throughout the civilian, national security, emergency preparedness, homeland security, and law enforcement communities; and (ii) consistent reporting to the Office of Management and Budget (OMB) and Congress on the adequacy and effectiveness of information security policies, procedures, and practices. interesting with security standards for information. The security objectives and categorization refer to the CIA triad of Confidentiality, Integrity, and Availability. These security categories are ranked with the approriate potential impact of Low, Moderate, and High and the FIPS 200 addresses the specification of seventeen minimum security requirements for federal information and information systems.
Organizations are made to comply with the federal standard and to determine the security category of their information system in accordance with FIPS 199 and FIPS 200 Standards for Security Categorization and not forgeting to apply the NIST SP 800-53.
Security controls are split into three groups: management, operational, and technical. Technical controls are automated and run by computer systems while operational controls are run by people. management controls are controls that help manage the entire information system. All three types of controls are necessary to successfully secure systems as no one type of control would be enough to keep any system secure. All three types of controls work together to build a robust system.
Hi Amelia,
I also thought it was fascinating that these security controls were broken down into three groups. Every federal system requires a plan of protection, and all three of these controls are necessary if you want to achieve the most secure system possible. Making sure all employees are aware of the controls and guidelines set in place is vital so that everyone is on the same page.
Something that stood out to me when reading the NIST SP 800-18r1 was the Table 1: FIPS 199 Categorization at the top of page 20.
It’s basically an outline and guide which shows the (Potential Impact) of unauthorized disclosure, modification, destruction, and or disruption of access to use of information or an information system. Moreover section 3.2 System Categorization says, “Each system identified in the agency’s system inventory must be categorized using FIPS 199.” (NIST SP 800-18r1)
The table shows the CIA triad / Security Objectives on the left hand side in the vertical direction. We can see the objectives of Confidentiality, Integrity, and Availability being defined adequately. & then we see the potential adverse impacts of each if they were to be compromised. In bold we see that a low potential impact is considered limited. A moderate impact would be regarded as serious, while the high potential impacts of the CIA triad are all considered to be (& this word always worries me) CATASTROPHIC!
Hi Joshua, yes this is something that everyone should be worried about because if the. unauthorized disclosure of information, modification, destruction, or disruption is done over giving the wrong person access it can be catastrophic whether it is intention or unintentional it is a lot of responsibility to handle.
In reading NIST SP 800-18
The compensating controls section stood out to me, this particular line
” and (iii) the agency assesses and formally accepts the risk
associated with employing the compensating controls in the information system”
Just reminded me that everything comes with Risks, even implementing new/compensating security controls
I felt the reading provided quality information and guidance on the components of developing security plans. Some of crucial components include identifying key points of contact (i.e. system name/owner, authorizing officials, etc.), identifying system purpose, environment, and usage, and identifying system interdependencies. These components are absolutely crucial when deploying security controls but, as the reading notes, it’s essential that once the security plans are deployed they must also be periodically reviewed (at least annually) to ensure security objectives are still consistently being met.
The key point that I learned this week was about the system owner 3.3 in NIST Sp800-18r1. The system owner is a designated owner who is identified in the security plan for each system. They are a key point of contact for the system and are responsible for coordinating system development life cycle (SDLC) The system owner must have expert knowledge of the capabilities of their system.
Hi Corey thanks for sharing and I agree identifying and establishing a system owner for each system is important. If organizations have excess resources it probably be a good idea to a designated backup system owner in cases where the main system owner isn’t available. Doing so could be very beneficial if a component of the system security plan needed to be updated in their absence. Additionally, it could also aid the organizations succession planning process.
One key point I took away from this article was from section 10.2 Risk Mitigation, specifically Figure 10-4, and the reason for that is due to a main point I took away from the introduction, which is that “the principal goal of an organization’s risk management process is to protect the organization and its ability to perform its mission, not just its information assets”. It is impossible to completely eliminate risk, so it is essential to have the necessary risk-reducing controls as recommended by NIST SP 800-53. Figure 10-4 is an easy to understand flowchart of how the process works by looking at key factors to determine if a risk is acceptable or unacceptable in order to determine the necessity of implementing additional controls to mitigate a risk if unacceptable.
In NIST SP800-18r1 rules of behavior stood out to me for implementing controls for users. It gives a good example of how controls and responsibilities of the users are delineated through expected uses and behavior of user. It also mentions point of access to certain fountains such as work from home, dial in access, The limits of interconnection, provisioning/restoration and consequences are also great ways to organize the controls as once users are aware of their limits and the do’s and don’ts then there should be a less internal attacks whether it be intentional or unintentional.
In NIST SP 18r1 the chapter we focused on describes the process on writing a security plan, including the steps to follow in plan development, structure/content, & how to effectively support system security planning. In this chapter a key point that stood out to me was section 3.16, which is ongoing security plan maintenance. This part stood out to me because once the system security plan has been completed, it’s not the end. The plan must be continually assessed for things such as functionality & design to ensure that the plan continues to contain accurate system information, as this is critical to system certification activity. This assessment should occur annually, with some examples of things to look out for being a change in system architecture, system status, the authorizing official, etc.
The protection of information security is not the responsibility of anyone person in the organization, all are responsible for the protect assets of the organization. All staff, senior management, and users are responsible for the information security protection, The main objective of information security planning is to improve the protection of Information Technology resources, all organizations always have some level of sensitivity and required protection, the protection of available assets of the organization must be documented in the system security plan.
When anyone takes charge of system security in the organization must be aware of the security program component and government system security requirements to ensure compliance. These are included for CIOs, CISOs, and security managers at all levels. All staff are responsible for the system security planning,