NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems” plays a vital role in promoting and securing data across Federal Information systems. It is an effective framework that enhances the protection and integrity of sensitive data. In essence, it establishes a well-defined, adaptable outline for security procedures across various domains of an organization’s information system.
The guide primarily sets out to facilitate a more systematic and well-rounded approach to security. For every Federal Information System, it ensures that there is an existing Security Plan – this is crucial in effectively mitigating the risks and consequences of potential security incidents. Each Security Plan should be crafted to meet the unique requirements of each organization, hence the importance of adaptability and flexibility that the guide underscores.
NIST SP 800-18r1, however, is not just a resource for developing a robust plan but it also serves as a tool for ongoing review and inherent improvement. It makes evident the necessity for routine assessments and continuous updates to keep up with the evolution of threats and technology.
To conclude, the NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems” reflects a thorough understanding of the dynamic nature of security within the landscape of Federal Information Systems. It is a substantial blueprint that motivates the progression toward a more resilient and secure federal information process.
NIST SP 800-18r1 emphasizes a holistic approach to information security, involving not just technology, but also people, management, and processes. It recommends a systematic, thoroughly integrated security plan encompassing all system components to fortify defenses, maintain information integrity and confidentiality, and increase organizational resilience against cyber-threats. Micheal, I really like the part you gave a hint of the dynamic nature of security within the landscape of Federal Information Systems. It is a substantial blueprint that motivates the progression toward a more resilient and secure federal information process.
My profound review of NIST SP 800-18r1, “Guide for Developing Security Plans for Federal Information Systems”, reveals a critical pillar- the emphasis on an organization-wide, holistic approach to information security. The guide underlines the importance of not just focusing on technical and operational aspects, but also on the human element, management, and process aspects for a comprehensive protection strategy. It encourages federal entities to ensure that their security planning is meticulously integrated with their broader strategic planning processes. A managed, consistent, documented, and traceable security planning process is recommended to ensure that all elements of the system are accounted for in security measures. This overarching approach allows for a greater defense against potential threats, elevating the entity’s resilience against malicious attacks while maximizing the integrity and confidentiality of information. Hence, the guide’s viewpoint aligns with the contemporary understanding that security is not just about hardening IT infrastructure; rather, it traverses all organizational levels and aspects.
Hi Ikenna,
I am in alignment with your thought on this.The guide underscores the necessity of a holistic approach to protection strategy, highlighting the crucial role of human and management elements alongside technical and operational facets. It advises federal institutions to astutely intertwine their security objectives with their overarching strategic planning processes. This approach ensures comprehensive coverage and meticulous integration, thereby promoting a resilient and robust security framework.
After reading NIST 800-18r1 I want to speak on chapter 3 Plan Development. The first two chapters talked about the importance of getting to know the company you are developing the plan for as well as system boundaries and security controls. While these are vital to the process, if you are unable to develop a plan, it means nothing. Chapter details the step on how to properly develop your security plan.
The step by step instructions tells you where to go to aide in putting your plan together. For instance, when categorizing your system inventory, you are directed to FIPS 199 for categorization and SP 800-60 which provides guidance on how to implement this task. We will be doing exactly this task in class, so I find it a bit intimidating but having these guides are really helpful with task that are ahead.
I completely agree that even with the guide readily available, I still feel a bit worried on actually putting a plan together. Designating certain aspects of a larger system and implementing specific controls per part of a system seems intimidating, but hopefully we’ll see some more examples of security plans before working on one.
Hello Erskine, I like the emphasis you placed on planning. Planning is something I myself struggle with as sometimes I like to jump into different things head first. You are completely correct when you say how it means nothing if you can’t make a plan, this is why it’s a great thing that the chapter goes through developing a plan. I wonder what are some things a company can do moving forward to teach their employees proper planning? i know training helps but I feel like this is one of those things where you can’t just show a slideshow. You a company would have to figure out a way to convince people at their core to change their priorities if they were to lack inn a certain area.
I completely agree with your statement. Chapter 3 of NIST 800-18r1, “Plan Development,” begins the crucial step of putting theory into motion. While understanding the organization and its security landscape is essential, it’s the ability to translate that knowledge into a concrete plan that makes the difference. It provides a clear roadmap for developing a security plan and breaking down the process into manageable steps. This is especially helpful for those new to security planning or unfamiliar with NIST guidelines.
NIST SP 800-18r1 deals with the step-by-step process of creating a system security plan for any given system within NIST guidelines. The chapter takes the user through the process, from identifying to keeping the system running. One main takeaway I had from this chapter is how thorough any system secuirty plan must be, regardless of criticality. Creating a standard process for securing systems allows for all systems in a given organization to be properly placed and ifentified and ensures that even if the actual controls on each may vary they were all analyzed and set up with the same degree of care and thought. This makes sure that organizations are not only following federal guidelines, but creates a useful understanding for how systems work across the board. This standardization also carries over to other organizations as well. Making sure that there is a standardized framework for how systmes are categorized, controlled etc. means that one could visit a theoretically unknown company or organization that they had no hand in configuring and still generally find their way around the systems provided because they all follow the same layout and guidelines
I agree that having a standard for federal agencies to follow for implementing security plans is very important in protecting important assets. However, one of the more interesting things I noted was that even with these guidelines and frameworks in place, there have been many successful attacks on not only federal but also general companies and organizations. Do you think it may be due to organizations not following these guidelines, or do you think threat actors are evolving faster than guidelines can cover?
Thanks for your comment Kenneth. When it comes to organizations still being vulnerable to attack I think there are a lot of factors, but the number one that I’d wager causes them is probably human error. We’ve seen in previous classes how even with these guidelines in place, attacks can still slip through the cracks due to human error. The Target case is a great example of this, as from what we see the organization was following all federal guidelines at the time, but human negligence allowed attackers to infiltrate their system. Unfortunately there is no accounting for human error beyond a certain point in the process
FedRAMP stands for Federal Risk and Authorization Management Program is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP program categorizes cloud services into different impact levels based on the sensitivity and impact of the data stored, each impact level has separate security controls that include the applicable controls for the particular security baseline.
The SSP template addresses all FedRAMP baselines. The document outlines the system architecture,security controls and measures implemented by a cloud service providers(CSPs) to protect the information and systems within the Federal environment. The SSP provide a detailed overview of how the system is secured and how it meets the requirements of FedRAMP and also provides a sense of transparency and accountability as its list all the involved individuals and the role they play in securing the environment.
Guide for Developing Security Plans for Federal Information Systems is a document that provides a guideline for federal agencies to follow when developing security plans that document the management, technical, and operational controls for federal automated information systems.
These sections guide users in writing a security plan including logical steps which should be followed. The guide shows how to use other NIST publications to effectively support the System Security Plan and one of the publications is the FIPS 199 which is a Federal Information Processing Standard that provides a standard for categorizing federal information and information systems based on their confidentiality, integrity, and availability. It also requires specifying the systems type, environment, interconnection, law, regulation, policies, and minimum security controls.
The guide also emphasizes the importance of regularly assessing the plan and reviewing any changes to make sure it reflects the correct information, as the correctness of this document is important for system certification
As I started to read this publication specially section 1.7 and the certification process, “The results of a security certification are used to reassess the risk, develop the plan of action and milestones (POA&Ms) which are required to track remedial actions, and update the security plan, thus providing the factual basis from an authorizing official render a security accreditation decision”. It makes me think and now understand how in-depth the certification and accreditation process are. The input and outputs in figure 1 pg. 4 put it into perspective to me. I had to then look into what POA&Ms were and the dots are starting to connect as they are a plan of action and milestones which also are referred to as a corrective action plan which is the authoritative agency management tool for documenting the remediation actions of a system risk. Last semester we went over the disaster recovery plan and can only think that you will need a strong security plan in place, so you never have to kick in the DRP.
Pg.20 is an objective that I want to fully understand in this class. It was covered in my prior semester, but I want to be able to 100% understand and utilize it and understand it like second nature. With that being said, this also stood out to me along with 3.4 & 3.5. I did not know that there was a chain of command that was involved with this. Again, this is something I want to see more visually or in real life so I can get a concrete understanding of this. In addition to the in-depth information that the Security plan has I was also intrigued by the structure that it involves. It even states that on pg. 25, “Security controls in the security catalog (NIST SP 800-53, Appendix F) have a well-defined organization and structure”. I feel that someone that is new to this industry, I’m glad that there is a structure to all the information that is out there, specifically security plans.
NIST SP 800-18r1 is a guide for developing security plans for federal systems that have some sensitivity involved and require protection. The point of analysis I want to examine is the distinction between types of applications: major, general support, and minor applications. Major applications are defined at an impact of moderate or high and play an important role to an agency’s mission in some way. General support applications are straightforward in that they provide support for users and/or applications, like LAN terminals, communication networks, radio networks, etc. These can be defined at any impact level depending on what the specific role of the system is as well as its impact on an agency is. Minor applications address tend to have low or moderate impact and cover a minor role in agencies compared to major or general support systems.
Based on the what a system is defined as, the impact and controls necessary to implement on these systems is also designated. The guide introduces some examples of considerations for controls while allowing some room for interpretation.
Your analysis of the Nist article and its classification of applications into categories is insightful Kenneth. The distinction between these types based on impact levels and their respective roles in supporting an agency’s mission provides a clear framework for security planning. It’s interesting to note the flexibility in control considerations, allowing for interpretation based on specific system characteristics. How do you see organizations navigating the balance between implementing standardized controls and tailoring them to the unique attributes of their systems, especially when considering the varying impacts and roles of each application?
Hi Kenneth, I agree with your breakdown of NIST SP 800-18r1 and how it classifies applications into major, general support, and minor types based on their impact levels. It’s important to understand the different roles these applications play in federal systems and how their impact levels relate to the agency’s mission. The guide’s approach of giving examples for controls while allowing some flexibility in interpretation is helpful. It ensures that security plans can be adjusted to fit the specific characteristics of each system, making sure security measures match the significance and role of the applications.
The key part of this reading that intrigued me was about system environment. This is because it goes into the area of awareness. You must be able to do a full assessment of your area and write a couple paragraph paper which describes the system. There are numerous possibilities, but generally you have SOHO which is a small or home office, or a standalone office. A prime example of this would be someone who works alone remotely from home and is owner of the business. Maybe they have one or two employees but this wouldn’t be something used for a fortune 500 company. Then there is enterprise or managed, which would fall in line with a big corporation. the third one mentioned is custom environments., and two main examples of that would be a specialized security limited functionality, and legacy. This section seems simple enough, but the reason why this intrigued me is because nobody has one true type of workstation. There are different ways people work and its important that we recognize that and learn how different environments bring forth different threats.
From the assigned reading, one key point I took away is about the comprehensive approach to vulnerability identification outlined in NIST SP 800-30. The definition of vulnerability as a flaw or weakness in system security is clear, encompassing various aspects such as procedures, design, implementation, and internal controls. The reading emphasizes the importance of utilizing diverse techniques and sources, including reviews of risk assessments, audit reports, vulnerability databases, and security advisories. Notably, the incorporation of system security testing, such as automated vulnerability scanning tools, security test and evaluation, and penetration testing, complements the source reviews. Additionally, the suggestion to develop a security requirements checklist based on the SDLC phases ensures a thorough inspection of the system from conceptualization to implementation. This holistic approach, including a 360-degree inspection and compliance evaluation, contributes to a robust identification of potential vulnerabilities within a system.
I wrote my response to the wrong reading here, this is my response for this one:
The key point I got from the reading is the challenge of implementing security control partitioning within information systems. While the concept is straightforward, practical application requires careful planning, coordination, and perseverance. Successful implementation may take time, and any failure in common security controls could significantly increase agency-level risk. The document then provides guidance on developing a system security plan, emphasizing elements like system categorization and the crucial role of a designated system owner. This underscores the strategic planning needed for effective security control partitioning in federal information systems.
The importance of providing a general description of the system environment cannot be stressed enough. The ease of use and maintenance that comes from a well defined and specific outline is what makes up some of the best practices. It’ll allow both unfamiliar and out of touch users to be brought in to work on the system, whether that be updating it or further securing it from outside threats by knowing what the system is about, how it works and what it needs to function.
In the Security Plan development process, a crucial step is understanding the documents that must be considered. NIST SP 800-18r1 outlines this process for federal information systems, emphasizing compliance with FISMA, OMB Circular A-130, and the Security of Federal Automated Information Resources. Key standards like FIPS 199, FIPS 200, and SP 800-53 define security controls and minimum requirements. Additional support comes from SP 800-30 and SP 800-37, offering risk management guidelines and certification/accreditation procedures if necessary. FISMA and SP 800-18 collaborate to establish minimum Security Plan requirements.
In developing a security plan, NIST provides an open-ended platform or best practices which you can curate to meet your organization’s effective security plan.
NIST SP 800-18r1 provides a systematic framework for securing federal information systems. It emphasizes a risk-based approach, tailored controls, and continuous monitoring.
Some key topics include:
Risk Assessment: Identifying vulnerabilities and threats to prioritize security implementation.
Control Selection: Implementing appropriate security controls based on identified risks.
Plan Documentation: Creating a clear and comprehensive security plan accessible to all stakeholders.
Continuous Monitoring: Regularly evaluate the effectiveness of implemented controls and adapt the plan as needed.
OMB Approval: Ensuring cost-effective security measures and meeting federal acquisition regulations.
Risk Acceptance: Acknowledging operational risks before system authorization.
Essentially, NIST SP 800-18r1 advocates for optimizing resources through cost-effective evaluation methods, significantly contributing to improving control effectiveness. It enables a deeper understanding of the risks that could impact operations, assets, personnel, and the nation. Furthermore, by following its detailed and comprehensive assessment procedures, agencies can generate more accurate, reliable, and trustworthy information, bolstering the overall security posture.
I like how spread out the key topics when talking about NIST SP 800-18r1. The also like how the guide advises catering your security plan to those who are using the information systems. Having your target audience familiarizing themselves with the planning process and offer feedback. I mentioned in my post who I like the detail that NIST SP 800-18r1 goes into showing others how to put together a successful plan.
From your post, I learnt NIST SP 800-18r1 offers a systematic framework for fortifying federal information systems, championing a risk-based approach, tailored controls, and consistent monitoring. This protocol cultivates a thorough understanding of potential risks, encouraging the deployment of cost-effective security practices. Its comprehensive procedures bolster accuracy, reliability, and the overall security stance. Thank you for this post Kelly.
NIST SP 800-18r1 explains the importance of developing a security plan that gives an insight into the security requirements of a network. The security plan gives a detailed description of requirements and also the control in place. This will also help assign tasks to the people involved. Security planning is not only meant for certain people; all staff are responsible for security planning within an organization.
Akintunde Thank you for sharing. Your point. There is no doubt that in any organization, everyone is responsible for securing the data. And to add to your point, In terms of accountability and decision-making, I believe that at some point, someone must sign off on a specific security plan and any changes to it.
Just like cybersecurity in general, all staff are responsible for security planning within an organization. As I read through the article, I did notice that in 3.3 pg.19 it goes into detail about system owner and how a designated system owner must be identified in the system security plan for each system. It shows that the person must be a POC for the system and is responsible for coordinating system development life cycle activities specific to the system. I did not know if had to be very specific, so this wouldn’t be role that cannot be rotated throughout the company.
Hi Jeff,
I agree with you that it is everyone’s responsibility to plan regarding the security of the organization. I also didn’t know that the role of a system owner should be specific and unique to each system. After a deep thought, I agree because the system owners have comprehensive knowledge about the systems which is essential for the maintenance of the systems through their life cycle.
The information systems inventory was the main point that stood out to me. FISMA requires federal agencies to maintain an inventory of all information systems and categorize them using FIPPS 199. The inventory serves as the foundation for the Security Plan, so accuracy is critical. Responsibilities and boundaries cannot be determined without a thorough understanding of the information systems environment, the information stored, and the impact of that information.
Michael Obiukwu says
NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems” plays a vital role in promoting and securing data across Federal Information systems. It is an effective framework that enhances the protection and integrity of sensitive data. In essence, it establishes a well-defined, adaptable outline for security procedures across various domains of an organization’s information system.
The guide primarily sets out to facilitate a more systematic and well-rounded approach to security. For every Federal Information System, it ensures that there is an existing Security Plan – this is crucial in effectively mitigating the risks and consequences of potential security incidents. Each Security Plan should be crafted to meet the unique requirements of each organization, hence the importance of adaptability and flexibility that the guide underscores.
NIST SP 800-18r1, however, is not just a resource for developing a robust plan but it also serves as a tool for ongoing review and inherent improvement. It makes evident the necessity for routine assessments and continuous updates to keep up with the evolution of threats and technology.
To conclude, the NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems” reflects a thorough understanding of the dynamic nature of security within the landscape of Federal Information Systems. It is a substantial blueprint that motivates the progression toward a more resilient and secure federal information process.
Ikenna Alajemba says
NIST SP 800-18r1 emphasizes a holistic approach to information security, involving not just technology, but also people, management, and processes. It recommends a systematic, thoroughly integrated security plan encompassing all system components to fortify defenses, maintain information integrity and confidentiality, and increase organizational resilience against cyber-threats. Micheal, I really like the part you gave a hint of the dynamic nature of security within the landscape of Federal Information Systems. It is a substantial blueprint that motivates the progression toward a more resilient and secure federal information process.
Ikenna Alajemba says
My profound review of NIST SP 800-18r1, “Guide for Developing Security Plans for Federal Information Systems”, reveals a critical pillar- the emphasis on an organization-wide, holistic approach to information security. The guide underlines the importance of not just focusing on technical and operational aspects, but also on the human element, management, and process aspects for a comprehensive protection strategy. It encourages federal entities to ensure that their security planning is meticulously integrated with their broader strategic planning processes. A managed, consistent, documented, and traceable security planning process is recommended to ensure that all elements of the system are accounted for in security measures. This overarching approach allows for a greater defense against potential threats, elevating the entity’s resilience against malicious attacks while maximizing the integrity and confidentiality of information. Hence, the guide’s viewpoint aligns with the contemporary understanding that security is not just about hardening IT infrastructure; rather, it traverses all organizational levels and aspects.
Michael Obiukwu says
Hi Ikenna,
I am in alignment with your thought on this.The guide underscores the necessity of a holistic approach to protection strategy, highlighting the crucial role of human and management elements alongside technical and operational facets. It advises federal institutions to astutely intertwine their security objectives with their overarching strategic planning processes. This approach ensures comprehensive coverage and meticulous integration, thereby promoting a resilient and robust security framework.
Erskine Payton says
After reading NIST 800-18r1 I want to speak on chapter 3 Plan Development. The first two chapters talked about the importance of getting to know the company you are developing the plan for as well as system boundaries and security controls. While these are vital to the process, if you are unable to develop a plan, it means nothing. Chapter details the step on how to properly develop your security plan.
The step by step instructions tells you where to go to aide in putting your plan together. For instance, when categorizing your system inventory, you are directed to FIPS 199 for categorization and SP 800-60 which provides guidance on how to implement this task. We will be doing exactly this task in class, so I find it a bit intimidating but having these guides are really helpful with task that are ahead.
Kenneth Saltisky says
Hi Erskine,
I completely agree that even with the guide readily available, I still feel a bit worried on actually putting a plan together. Designating certain aspects of a larger system and implementing specific controls per part of a system seems intimidating, but hopefully we’ll see some more examples of security plans before working on one.
Hashem Alsharif says
Hello Erskine, I like the emphasis you placed on planning. Planning is something I myself struggle with as sometimes I like to jump into different things head first. You are completely correct when you say how it means nothing if you can’t make a plan, this is why it’s a great thing that the chapter goes through developing a plan. I wonder what are some things a company can do moving forward to teach their employees proper planning? i know training helps but I feel like this is one of those things where you can’t just show a slideshow. You a company would have to figure out a way to convince people at their core to change their priorities if they were to lack inn a certain area.
Kelly Conger says
Erskine, my man!
I completely agree with your statement. Chapter 3 of NIST 800-18r1, “Plan Development,” begins the crucial step of putting theory into motion. While understanding the organization and its security landscape is essential, it’s the ability to translate that knowledge into a concrete plan that makes the difference. It provides a clear roadmap for developing a security plan and breaking down the process into manageable steps. This is especially helpful for those new to security planning or unfamiliar with NIST guidelines.
Andrew Young says
NIST SP 800-18r1 deals with the step-by-step process of creating a system security plan for any given system within NIST guidelines. The chapter takes the user through the process, from identifying to keeping the system running. One main takeaway I had from this chapter is how thorough any system secuirty plan must be, regardless of criticality. Creating a standard process for securing systems allows for all systems in a given organization to be properly placed and ifentified and ensures that even if the actual controls on each may vary they were all analyzed and set up with the same degree of care and thought. This makes sure that organizations are not only following federal guidelines, but creates a useful understanding for how systems work across the board. This standardization also carries over to other organizations as well. Making sure that there is a standardized framework for how systmes are categorized, controlled etc. means that one could visit a theoretically unknown company or organization that they had no hand in configuring and still generally find their way around the systems provided because they all follow the same layout and guidelines
Kenneth Saltisky says
Hi Andrew,
I agree that having a standard for federal agencies to follow for implementing security plans is very important in protecting important assets. However, one of the more interesting things I noted was that even with these guidelines and frameworks in place, there have been many successful attacks on not only federal but also general companies and organizations. Do you think it may be due to organizations not following these guidelines, or do you think threat actors are evolving faster than guidelines can cover?
Andrew Young says
Thanks for your comment Kenneth. When it comes to organizations still being vulnerable to attack I think there are a lot of factors, but the number one that I’d wager causes them is probably human error. We’ve seen in previous classes how even with these guidelines in place, attacks can still slip through the cracks due to human error. The Target case is a great example of this, as from what we see the organization was following all federal guidelines at the time, but human negligence allowed attackers to infiltrate their system. Unfortunately there is no accounting for human error beyond a certain point in the process
Mariam Hazali says
FedRAMP stands for Federal Risk and Authorization Management Program is a government-wide program that provides a standardized approach to security assessment, authorization, and continuous monitoring for cloud products and services. FedRAMP program categorizes cloud services into different impact levels based on the sensitivity and impact of the data stored, each impact level has separate security controls that include the applicable controls for the particular security baseline.
The SSP template addresses all FedRAMP baselines. The document outlines the system architecture,security controls and measures implemented by a cloud service providers(CSPs) to protect the information and systems within the Federal environment. The SSP provide a detailed overview of how the system is secured and how it meets the requirements of FedRAMP and also provides a sense of transparency and accountability as its list all the involved individuals and the role they play in securing the environment.
Mariam Hazali says
please disregard this post
Mariam Hazali says
Guide for Developing Security Plans for Federal Information Systems is a document that provides a guideline for federal agencies to follow when developing security plans that document the management, technical, and operational controls for federal automated information systems.
These sections guide users in writing a security plan including logical steps which should be followed. The guide shows how to use other NIST publications to effectively support the System Security Plan and one of the publications is the FIPS 199 which is a Federal Information Processing Standard that provides a standard for categorizing federal information and information systems based on their confidentiality, integrity, and availability. It also requires specifying the systems type, environment, interconnection, law, regulation, policies, and minimum security controls.
The guide also emphasizes the importance of regularly assessing the plan and reviewing any changes to make sure it reflects the correct information, as the correctness of this document is important for system certification
Jeffrey Sullivan says
As I started to read this publication specially section 1.7 and the certification process, “The results of a security certification are used to reassess the risk, develop the plan of action and milestones (POA&Ms) which are required to track remedial actions, and update the security plan, thus providing the factual basis from an authorizing official render a security accreditation decision”. It makes me think and now understand how in-depth the certification and accreditation process are. The input and outputs in figure 1 pg. 4 put it into perspective to me. I had to then look into what POA&Ms were and the dots are starting to connect as they are a plan of action and milestones which also are referred to as a corrective action plan which is the authoritative agency management tool for documenting the remediation actions of a system risk. Last semester we went over the disaster recovery plan and can only think that you will need a strong security plan in place, so you never have to kick in the DRP.
Pg.20 is an objective that I want to fully understand in this class. It was covered in my prior semester, but I want to be able to 100% understand and utilize it and understand it like second nature. With that being said, this also stood out to me along with 3.4 & 3.5. I did not know that there was a chain of command that was involved with this. Again, this is something I want to see more visually or in real life so I can get a concrete understanding of this. In addition to the in-depth information that the Security plan has I was also intrigued by the structure that it involves. It even states that on pg. 25, “Security controls in the security catalog (NIST SP 800-53, Appendix F) have a well-defined organization and structure”. I feel that someone that is new to this industry, I’m glad that there is a structure to all the information that is out there, specifically security plans.
Kenneth Saltisky says
NIST SP 800-18r1 is a guide for developing security plans for federal systems that have some sensitivity involved and require protection. The point of analysis I want to examine is the distinction between types of applications: major, general support, and minor applications. Major applications are defined at an impact of moderate or high and play an important role to an agency’s mission in some way. General support applications are straightforward in that they provide support for users and/or applications, like LAN terminals, communication networks, radio networks, etc. These can be defined at any impact level depending on what the specific role of the system is as well as its impact on an agency is. Minor applications address tend to have low or moderate impact and cover a minor role in agencies compared to major or general support systems.
Based on the what a system is defined as, the impact and controls necessary to implement on these systems is also designated. The guide introduces some examples of considerations for controls while allowing some room for interpretation.
Alex Ruiz says
Your analysis of the Nist article and its classification of applications into categories is insightful Kenneth. The distinction between these types based on impact levels and their respective roles in supporting an agency’s mission provides a clear framework for security planning. It’s interesting to note the flexibility in control considerations, allowing for interpretation based on specific system characteristics. How do you see organizations navigating the balance between implementing standardized controls and tailoring them to the unique attributes of their systems, especially when considering the varying impacts and roles of each application?
Nicholas Nirenberg says
Hi Kenneth, I agree with your breakdown of NIST SP 800-18r1 and how it classifies applications into major, general support, and minor types based on their impact levels. It’s important to understand the different roles these applications play in federal systems and how their impact levels relate to the agency’s mission. The guide’s approach of giving examples for controls while allowing some flexibility in interpretation is helpful. It ensures that security plans can be adjusted to fit the specific characteristics of each system, making sure security measures match the significance and role of the applications.
Hashem Alsharif says
The key part of this reading that intrigued me was about system environment. This is because it goes into the area of awareness. You must be able to do a full assessment of your area and write a couple paragraph paper which describes the system. There are numerous possibilities, but generally you have SOHO which is a small or home office, or a standalone office. A prime example of this would be someone who works alone remotely from home and is owner of the business. Maybe they have one or two employees but this wouldn’t be something used for a fortune 500 company. Then there is enterprise or managed, which would fall in line with a big corporation. the third one mentioned is custom environments., and two main examples of that would be a specialized security limited functionality, and legacy. This section seems simple enough, but the reason why this intrigued me is because nobody has one true type of workstation. There are different ways people work and its important that we recognize that and learn how different environments bring forth different threats.
Nicholas Nirenberg says
From the assigned reading, one key point I took away is about the comprehensive approach to vulnerability identification outlined in NIST SP 800-30. The definition of vulnerability as a flaw or weakness in system security is clear, encompassing various aspects such as procedures, design, implementation, and internal controls. The reading emphasizes the importance of utilizing diverse techniques and sources, including reviews of risk assessments, audit reports, vulnerability databases, and security advisories. Notably, the incorporation of system security testing, such as automated vulnerability scanning tools, security test and evaluation, and penetration testing, complements the source reviews. Additionally, the suggestion to develop a security requirements checklist based on the SDLC phases ensures a thorough inspection of the system from conceptualization to implementation. This holistic approach, including a 360-degree inspection and compliance evaluation, contributes to a robust identification of potential vulnerabilities within a system.
Nicholas Nirenberg says
I wrote my response to the wrong reading here, this is my response for this one:
The key point I got from the reading is the challenge of implementing security control partitioning within information systems. While the concept is straightforward, practical application requires careful planning, coordination, and perseverance. Successful implementation may take time, and any failure in common security controls could significantly increase agency-level risk. The document then provides guidance on developing a system security plan, emphasizing elements like system categorization and the crucial role of a designated system owner. This underscores the strategic planning needed for effective security control partitioning in federal information systems.
Alex Ruiz says
The importance of providing a general description of the system environment cannot be stressed enough. The ease of use and maintenance that comes from a well defined and specific outline is what makes up some of the best practices. It’ll allow both unfamiliar and out of touch users to be brought in to work on the system, whether that be updating it or further securing it from outside threats by knowing what the system is about, how it works and what it needs to function.
Chidiebere Okafor says
In the Security Plan development process, a crucial step is understanding the documents that must be considered. NIST SP 800-18r1 outlines this process for federal information systems, emphasizing compliance with FISMA, OMB Circular A-130, and the Security of Federal Automated Information Resources. Key standards like FIPS 199, FIPS 200, and SP 800-53 define security controls and minimum requirements. Additional support comes from SP 800-30 and SP 800-37, offering risk management guidelines and certification/accreditation procedures if necessary. FISMA and SP 800-18 collaborate to establish minimum Security Plan requirements.
In developing a security plan, NIST provides an open-ended platform or best practices which you can curate to meet your organization’s effective security plan.
Kelly Conger says
NIST SP 800-18r1 provides a systematic framework for securing federal information systems. It emphasizes a risk-based approach, tailored controls, and continuous monitoring.
Some key topics include:
Risk Assessment: Identifying vulnerabilities and threats to prioritize security implementation.
Control Selection: Implementing appropriate security controls based on identified risks.
Plan Documentation: Creating a clear and comprehensive security plan accessible to all stakeholders.
Continuous Monitoring: Regularly evaluate the effectiveness of implemented controls and adapt the plan as needed.
OMB Approval: Ensuring cost-effective security measures and meeting federal acquisition regulations.
Risk Acceptance: Acknowledging operational risks before system authorization.
Essentially, NIST SP 800-18r1 advocates for optimizing resources through cost-effective evaluation methods, significantly contributing to improving control effectiveness. It enables a deeper understanding of the risks that could impact operations, assets, personnel, and the nation. Furthermore, by following its detailed and comprehensive assessment procedures, agencies can generate more accurate, reliable, and trustworthy information, bolstering the overall security posture.
Erskine Payton says
Hi Kelly,
I like how spread out the key topics when talking about NIST SP 800-18r1. The also like how the guide advises catering your security plan to those who are using the information systems. Having your target audience familiarizing themselves with the planning process and offer feedback. I mentioned in my post who I like the detail that NIST SP 800-18r1 goes into showing others how to put together a successful plan.
Ikenna Alajemba says
From your post, I learnt NIST SP 800-18r1 offers a systematic framework for fortifying federal information systems, championing a risk-based approach, tailored controls, and consistent monitoring. This protocol cultivates a thorough understanding of potential risks, encouraging the deployment of cost-effective security practices. Its comprehensive procedures bolster accuracy, reliability, and the overall security stance. Thank you for this post Kelly.
Akintunde Akinmusire says
NIST SP 800-18r1 explains the importance of developing a security plan that gives an insight into the security requirements of a network. The security plan gives a detailed description of requirements and also the control in place. This will also help assign tasks to the people involved. Security planning is not only meant for certain people; all staff are responsible for security planning within an organization.
Samuel Omotosho says
Akintunde Thank you for sharing. Your point. There is no doubt that in any organization, everyone is responsible for securing the data. And to add to your point, In terms of accountability and decision-making, I believe that at some point, someone must sign off on a specific security plan and any changes to it.
Jeffrey Sullivan says
Just like cybersecurity in general, all staff are responsible for security planning within an organization. As I read through the article, I did notice that in 3.3 pg.19 it goes into detail about system owner and how a designated system owner must be identified in the system security plan for each system. It shows that the person must be a POC for the system and is responsible for coordinating system development life cycle activities specific to the system. I did not know if had to be very specific, so this wouldn’t be role that cannot be rotated throughout the company.
Akintunde Akinmusire says
Hi Jeff,
I agree with you that it is everyone’s responsibility to plan regarding the security of the organization. I also didn’t know that the role of a system owner should be specific and unique to each system. After a deep thought, I agree because the system owners have comprehensive knowledge about the systems which is essential for the maintenance of the systems through their life cycle.
Samuel Omotosho says
The information systems inventory was the main point that stood out to me. FISMA requires federal agencies to maintain an inventory of all information systems and categorize them using FIPPS 199. The inventory serves as the foundation for the Security Plan, so accuracy is critical. Responsibilities and boundaries cannot be determined without a thorough understanding of the information systems environment, the information stored, and the impact of that information.