In developing an information security plan, it is first important to categorize information systems using the FIPS 199 security categorization – that is, an impact of high, moderate, or low, should confidentiality, integrity or availability be compromised. This categorization would ultimately determine the controls that would be selected and implemented.
A security plan for an information system should have detailed information on the categorization of data being stored, assign ownership of the system and information to make sure everyone knows who to contact, a technical description of the environment, any security controls being used, and much more. Having a security plan will allow for a complete security overview of the system and help make sure the all three security objectives (Confidentiality, Integrity, and Availability) are being enforced.
Information systems requires a system security plan be in place because of dangerous risks caused from misuse or unauthorized access of information in the application. That is why there are procedures such as the NIST security standards and guidelines to prevent or reduce levels of risk, and the FIPS 199 to categorize information based on the level of risk.
The NIST SP 800-18r1 is not only targeting the organizations that have regularity compliance requirements from the federal government. It also targets the program managers, system owners, and security personnel in any organization, as well as the users within the organization. The NIST SP 800-18r1 is designed to provide guidelines on how to prepare a system security plan and it can be adapted to fit variety of organizations.
One key takeaway I had from this reading is that the guidance on System Security Plans does a very good job promoting ownership and accountability for risk. For example, the guidance mentions that a senior manager must authorize a system to operate and also mentions there must be procedures in place identifying who is responsible for reviewing, keeping current, and following up on controls as well as rules of behavior that identify responsibilities and consequences if the rules are not followed. The Plan also names specific owners. This really stood out to me because in my experience as a non-IT auditor in the private sector, ownership and accountability have been two of the biggest challenges I’ve seen in making sure risk and control ownership are in place.
Hi Megan! Having a system security plan to hold employees accountable of their for proper risk management is crucial. I would like to also add that the system security plan must also be reevaluated frequently in order to adjust to emerging risks and changes made in management. Overall, the system security plan should be used as guidance and be reevaluated for effectiveness.
System security plans are not static documents. They need to be reviewed and modified periodically. Being that they are such important and critical documents, the onus for this doesn’t just fall on one person. Nist SP 800-18 defines many roles and responsibilities surrounding planning and maintaining a system security plan. The CIO sets the policies and procedures that guide system security plans and ensures that those developing the plan are well trained. The information system owner maintains the plan and ensures that it is implemented, as well as updates the plan when a change in the system occurs. The information owner establishes the rules for proper use of the information and decides who has access. There should also be a senior agency information security officer, an information system security officer, and an authorizing official involved. The authorizing official approves the plan and allows the information system to be operated.
Jonathan, i agree. As long as the organization understands that the onus does not fall onto one person and there needs to be constant review this will help with a successful plan.
The purpose of this guidance is to provide an overview of the security requirements of the system. It lists out all the basic information on how to prepare a system security plan and how to make it to be adaptable in a variety of organizational structures. It also describes responsibilities and expected behavior of all individual who have authority to access to the system, such as Information System Owner who is the agency official responsible for the overall procurement, development, integration, modification, and maintenance of the information system. In addition, this guidance provides detail of minimum security requirements for the information system, where an agency has the flexibility to tailor the security control baseline by following terms and conditions set forth in the standard.
Hi Wei, I think your takeaway about the document providing a security control baseline, while also promoting the flexibility of security controls, is especially important. Baselines are extremely useful for organizations, especially those who need guidance with selecting security requirements. However, the suggestion to tailor security requirements reminds us of an important fact: the ideal security controls varies per organization, and it is essential that enterprises acknowledge this and curate their security controls to best suit themself individually.
A critical area in developing the System Security Plan is determining what is in and out of scope. The section on Scoping Guidance provided key considerations to utilize when determining how the baseline controls should be applied to an organization. The guidance also reiterated the importance of including a rationale for the type of considerations that were made. A documented rationale to support critical decisions is important for the Authorizing Official to understand and will be reviewed in situations where errors occur or threats are realized. (Auditors like having a documented rationale too!).
Hi Christa – I agree that the determination of the scope of applicability for an organization’s controls is necessary, and the scoping guidance included in the document is helpful in that process. Controls might be completely useless or irrelevant depending on the system being considered, so determining what is in the scope of a control can prevent effort being wasted attempting to implement an irrelevant control.
I found this reading’s detailed descriptions of the responsible parties in a system security plan to be interesting. Ultimately, per NIST guidelines, there is a single individual responsible for authorizing a system security plan, and therefore is accountable for failings within the plan. Despite this, there are a variety of other individuals, from information / information system owners to security officers to even the CIO, who the authorizing official relies on to provide them with the input needed to make an information authorization decision.
Mitch, thank you for sharing. your point. There is no question that in any organization there are teams responsible for securing the organization’s data. I think in terms of accountability and decision making, ultimately someone has to sign off for a specific security plan and any changes to the plan.
I also took note of the different roles and responsibilities regarding the system security plan. I believe you make a good point that while yes, someone has to be accountable for approving the plan, that person isn’t making this decision and evaluation by themself. At least I don’t think they should. An entire team should be involved with putting together and reviewing the plan. It’s too critical to leave to one person.
When agencies identify the system inventory, it must use FIPS 199. NIST Special Publication 800-60, Guide for Mapping Types of Information, and Information Systems to Security Categories to categorize the security object and its potential impact level. The FIPS 199 Category has separate three security objectives: confidentiality, integrity, and availability, with three different potential impacts: low moderate, and high. Users can determine the appropriate value of the information or information system according to the protection needs and assign a value to it.
One key takeaway I had was the freedom organizations have to define an Information System. The flexibility in this aspect of the guide allows for senior leaders to tailor their plans more effectively. This also helps when FIPS 199 classifications are assigned. Since FIPS 199 classifications are always set by the highest level in the IS system, this flexibility allow for (in some cases) systems to be separated by criticality. This is not always the case, but should be considered when possible.
The goal of system security planning is to improve the protection of information system resources. NIST SP 800-18r1, provides guidelines on how to prepare a system security plan and it can be adapted to fit many different types of organizations. The system security plan should be viewed as a process of planning acceptable, cost, and effective security protection for an information system. It should reflect input from various managers and shareholders with responsibilities concerning the system, the system owner, data owners, and the information security officer. The goal of a security plan is to provide an overview of the requirements of the system and describe the risk controls designed for achieving those requirements.
The key point I took from this assigned was I learned about the purpose of the NNIST SP 800-18R1. The Title III of the E-Government Act(FISMA), required each federal agency to develop, document, and implement company wide information security program to provide information security for the data and IS that support the operations and assets of the agency. Even including data/systems held at another agency, contractor, or other source. System security planning supports the system development life cycle (SDLC) and should be updated as different changes in events trigger a need for revision. This is important in helping to accurately reflect the most current state of the system. The system security plan gives a summary of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements. The plan includes risk assessment, plan of action, accreditation decision letter, privacy impact assessment, contingency plan, configuration management plan, security configuration checklists, and system interconnection agreements as appropriate. The target audience for this guide are program managers, system owners, and security personnel in the organization.
Hi Quynh, thanks for sharing the information. It is really helpful. I look further about Title III of the E-Government Act and find out Privacy Impact Assessments (PIA) is one of the most important section for E-Government Act. A PIA is an analysis of how information in identifiable form is collected, stored, protected, shared, and managed. The purpose of a PIA is to demonstrate that system owners and developers have incorporated privacy protections throughout the entire life cycle of a system.
The key point that stood out for me was the information systems inventory. FISMA requires that federal agencies have an inventory that includes all of the information systems inventory and that they be categorized using FIPPS 199. It’s important that this be done accurately as the inventory lays the foundation for the Security Plan. Responsibilities and boundaries cannot be determined if there’s not a detailed understanding of the information systems environment, the information stored and the impact of this information.
Ashleigh, I think this is a great point. Having an inventory of information systems seems very basic but it is so foundational to the rest of the process! I find this to be something applicable outside of federal government organizations as well, and often something that may be overlooked. Not only can this impact responsibilities and boundaries, as you noted above, but it can also impact risk assessments and ultimately what controls are put in place. How do you know what risks are present if you do not even have a grasp of the information systems in your environment?
I thought it was interesting to not that a system security planning is a continuous process. The constant review of security threats, vulnerabilities by all areas of the business. The collaborative effort is vital for all units and the organization to understand and have a responsibile security plan.
Highly agree Michael. With all the malicious activity going on, we definitely need a security plan that is continuously updated at all times in case any threats may be encountered.
One key takeaway I gathered was that NIST’s Guide for Developing Security Plans for Federal Information Systems does a very good job of designating responsibilities to the pertinent IT professionals in an organization. NIST does mention that roles and titles vary greatly among organizations, but it is to be understood that the roles and responsibilities within the guide would be most efficient. NIST outlines that the Chief Information Officer (CIO) is the point person responsible for both developing and maintaining the information security program. The CIO is also responsible for designating a senior agency information security officer (SAISO). The Information System Owner is responsible for procurement, development, integration, modification, operation, and maintenance of the information system. The Information Officer is responsible for creating the controls for the security plan. The Senior Agency Information Security Officer (SAISO) takes the role as the liaison between the CIO and the information systems owners within the agency. I found it interesting to understand the responsibility hierarchy present here, as well as the built-in risk controls, such as making sure the individual in charge of maintenance is not the CIO.
In developing an information security plan, it is first important to categorize information systems using the FIPS 199 security categorization – that is, an impact of high, moderate, or low, should confidentiality, integrity or availability be compromised. This categorization would ultimately determine the controls that would be selected and implemented.
A security plan for an information system should have detailed information on the categorization of data being stored, assign ownership of the system and information to make sure everyone knows who to contact, a technical description of the environment, any security controls being used, and much more. Having a security plan will allow for a complete security overview of the system and help make sure the all three security objectives (Confidentiality, Integrity, and Availability) are being enforced.
Information systems requires a system security plan be in place because of dangerous risks caused from misuse or unauthorized access of information in the application. That is why there are procedures such as the NIST security standards and guidelines to prevent or reduce levels of risk, and the FIPS 199 to categorize information based on the level of risk.
The NIST SP 800-18r1 is not only targeting the organizations that have regularity compliance requirements from the federal government. It also targets the program managers, system owners, and security personnel in any organization, as well as the users within the organization. The NIST SP 800-18r1 is designed to provide guidelines on how to prepare a system security plan and it can be adapted to fit variety of organizations.
One key takeaway I had from this reading is that the guidance on System Security Plans does a very good job promoting ownership and accountability for risk. For example, the guidance mentions that a senior manager must authorize a system to operate and also mentions there must be procedures in place identifying who is responsible for reviewing, keeping current, and following up on controls as well as rules of behavior that identify responsibilities and consequences if the rules are not followed. The Plan also names specific owners. This really stood out to me because in my experience as a non-IT auditor in the private sector, ownership and accountability have been two of the biggest challenges I’ve seen in making sure risk and control ownership are in place.
Hi Megan! Having a system security plan to hold employees accountable of their for proper risk management is crucial. I would like to also add that the system security plan must also be reevaluated frequently in order to adjust to emerging risks and changes made in management. Overall, the system security plan should be used as guidance and be reevaluated for effectiveness.
System security plans are not static documents. They need to be reviewed and modified periodically. Being that they are such important and critical documents, the onus for this doesn’t just fall on one person. Nist SP 800-18 defines many roles and responsibilities surrounding planning and maintaining a system security plan. The CIO sets the policies and procedures that guide system security plans and ensures that those developing the plan are well trained. The information system owner maintains the plan and ensures that it is implemented, as well as updates the plan when a change in the system occurs. The information owner establishes the rules for proper use of the information and decides who has access. There should also be a senior agency information security officer, an information system security officer, and an authorizing official involved. The authorizing official approves the plan and allows the information system to be operated.
Jonathan, i agree. As long as the organization understands that the onus does not fall onto one person and there needs to be constant review this will help with a successful plan.
The purpose of this guidance is to provide an overview of the security requirements of the system. It lists out all the basic information on how to prepare a system security plan and how to make it to be adaptable in a variety of organizational structures. It also describes responsibilities and expected behavior of all individual who have authority to access to the system, such as Information System Owner who is the agency official responsible for the overall procurement, development, integration, modification, and maintenance of the information system. In addition, this guidance provides detail of minimum security requirements for the information system, where an agency has the flexibility to tailor the security control baseline by following terms and conditions set forth in the standard.
Hi Wei, I think your takeaway about the document providing a security control baseline, while also promoting the flexibility of security controls, is especially important. Baselines are extremely useful for organizations, especially those who need guidance with selecting security requirements. However, the suggestion to tailor security requirements reminds us of an important fact: the ideal security controls varies per organization, and it is essential that enterprises acknowledge this and curate their security controls to best suit themself individually.
A critical area in developing the System Security Plan is determining what is in and out of scope. The section on Scoping Guidance provided key considerations to utilize when determining how the baseline controls should be applied to an organization. The guidance also reiterated the importance of including a rationale for the type of considerations that were made. A documented rationale to support critical decisions is important for the Authorizing Official to understand and will be reviewed in situations where errors occur or threats are realized. (Auditors like having a documented rationale too!).
Hi Christa – I agree that the determination of the scope of applicability for an organization’s controls is necessary, and the scoping guidance included in the document is helpful in that process. Controls might be completely useless or irrelevant depending on the system being considered, so determining what is in the scope of a control can prevent effort being wasted attempting to implement an irrelevant control.
I found this reading’s detailed descriptions of the responsible parties in a system security plan to be interesting. Ultimately, per NIST guidelines, there is a single individual responsible for authorizing a system security plan, and therefore is accountable for failings within the plan. Despite this, there are a variety of other individuals, from information / information system owners to security officers to even the CIO, who the authorizing official relies on to provide them with the input needed to make an information authorization decision.
Mitch, thank you for sharing. your point. There is no question that in any organization there are teams responsible for securing the organization’s data. I think in terms of accountability and decision making, ultimately someone has to sign off for a specific security plan and any changes to the plan.
I also took note of the different roles and responsibilities regarding the system security plan. I believe you make a good point that while yes, someone has to be accountable for approving the plan, that person isn’t making this decision and evaluation by themself. At least I don’t think they should. An entire team should be involved with putting together and reviewing the plan. It’s too critical to leave to one person.
When agencies identify the system inventory, it must use FIPS 199. NIST Special Publication 800-60, Guide for Mapping Types of Information, and Information Systems to Security Categories to categorize the security object and its potential impact level. The FIPS 199 Category has separate three security objectives: confidentiality, integrity, and availability, with three different potential impacts: low moderate, and high. Users can determine the appropriate value of the information or information system according to the protection needs and assign a value to it.
One key takeaway I had was the freedom organizations have to define an Information System. The flexibility in this aspect of the guide allows for senior leaders to tailor their plans more effectively. This also helps when FIPS 199 classifications are assigned. Since FIPS 199 classifications are always set by the highest level in the IS system, this flexibility allow for (in some cases) systems to be separated by criticality. This is not always the case, but should be considered when possible.
The goal of system security planning is to improve the protection of information system resources. NIST SP 800-18r1, provides guidelines on how to prepare a system security plan and it can be adapted to fit many different types of organizations. The system security plan should be viewed as a process of planning acceptable, cost, and effective security protection for an information system. It should reflect input from various managers and shareholders with responsibilities concerning the system, the system owner, data owners, and the information security officer. The goal of a security plan is to provide an overview of the requirements of the system and describe the risk controls designed for achieving those requirements.
The key point I took from this assigned was I learned about the purpose of the NNIST SP 800-18R1. The Title III of the E-Government Act(FISMA), required each federal agency to develop, document, and implement company wide information security program to provide information security for the data and IS that support the operations and assets of the agency. Even including data/systems held at another agency, contractor, or other source. System security planning supports the system development life cycle (SDLC) and should be updated as different changes in events trigger a need for revision. This is important in helping to accurately reflect the most current state of the system. The system security plan gives a summary of the security requirements for the information system and describes the security controls in place or planned for meeting those requirements. The plan includes risk assessment, plan of action, accreditation decision letter, privacy impact assessment, contingency plan, configuration management plan, security configuration checklists, and system interconnection agreements as appropriate. The target audience for this guide are program managers, system owners, and security personnel in the organization.
Hi Quynh, thanks for sharing the information. It is really helpful. I look further about Title III of the E-Government Act and find out Privacy Impact Assessments (PIA) is one of the most important section for E-Government Act. A PIA is an analysis of how information in identifiable form is collected, stored, protected, shared, and managed. The purpose of a PIA is to demonstrate that system owners and developers have incorporated privacy protections throughout the entire life cycle of a system.
The key point that stood out for me was the information systems inventory. FISMA requires that federal agencies have an inventory that includes all of the information systems inventory and that they be categorized using FIPPS 199. It’s important that this be done accurately as the inventory lays the foundation for the Security Plan. Responsibilities and boundaries cannot be determined if there’s not a detailed understanding of the information systems environment, the information stored and the impact of this information.
Ashleigh, I think this is a great point. Having an inventory of information systems seems very basic but it is so foundational to the rest of the process! I find this to be something applicable outside of federal government organizations as well, and often something that may be overlooked. Not only can this impact responsibilities and boundaries, as you noted above, but it can also impact risk assessments and ultimately what controls are put in place. How do you know what risks are present if you do not even have a grasp of the information systems in your environment?
I thought it was interesting to not that a system security planning is a continuous process. The constant review of security threats, vulnerabilities by all areas of the business. The collaborative effort is vital for all units and the organization to understand and have a responsibile security plan.
Highly agree Michael. With all the malicious activity going on, we definitely need a security plan that is continuously updated at all times in case any threats may be encountered.
One key takeaway I gathered was that NIST’s Guide for Developing Security Plans for Federal Information Systems does a very good job of designating responsibilities to the pertinent IT professionals in an organization. NIST does mention that roles and titles vary greatly among organizations, but it is to be understood that the roles and responsibilities within the guide would be most efficient. NIST outlines that the Chief Information Officer (CIO) is the point person responsible for both developing and maintaining the information security program. The CIO is also responsible for designating a senior agency information security officer (SAISO). The Information System Owner is responsible for procurement, development, integration, modification, operation, and maintenance of the information system. The Information Officer is responsible for creating the controls for the security plan. The Senior Agency Information Security Officer (SAISO) takes the role as the liaison between the CIO and the information systems owners within the agency. I found it interesting to understand the responsibility hierarchy present here, as well as the built-in risk controls, such as making sure the individual in charge of maintenance is not the CIO.