Should all companies offering cloud services ascribe to be FedRAMP authorized? What are some situations where this would (and wouldn’t be beneficial) to a company to implement a security plan like this?
The creation of an information security plan is usually delegated to the Senior Agency Information Security Officer. This person is typically appointed by the Chief Information Officer. A security plan should include the following information:
Identifiers and Classifications:
– System Name and Identifier- This should be unique and support the agency’s ability to collect information and metrics specific to the system.
– System Categorization- These are based on FIPS 199 and classifies the sensitivity of the data in the system.
– System Operational Status- This details the present state for the system, i.e. if it’s implemented, being implemented, or being modified.
– Information System Type- Describes whether the system is a major application or a general support system.
– General Description/ Purpose- Describes the function and purpose of the system.
– System Environment- Describes the systems in place and any environmental or technical factors that raise special security concerns.
– System Interconnection/Information Sharing- Provides an overview of how the system interfaces with other systems and what information may be exchanged.
Contacts for the system:
– System Owner- This is the point of contact for the system in addition to being responsible for coordinating the system development life cycle.
– Authorizing Official- This is a senior manager who has the authority to authorize operation of an information system.
– Other Contacts- Key personnel that can address inquiries into the system.
– Responsible Parties- Individuals who are responsible for each system’s operation and security.
Regulations and Controls:
– Laws, Regulations, and Policies Affecting the System- This should list any legal, regulatory, or policy requirements for the confidentiality, integrity, or availability of the system.
– Security Controls- Should be informed by NIST SP 800-53 and based on the system categorization from FIPS 199. Controls should be titled and contain a description of how the control is being implemented, scope of the control, and who is responsible for the implementation.
Administration and Maintenance:
– Completion and Approval Dates- The completion of the system security plan should be documented. This should be updated when the plan is reviewed and updated.
– Ongoing System Security Plan Maintenance- The plan should be assessed periodically to review any changes in system status, functionality, design, etc. Revisions should be made to address these changes.
The purpose of a system security plan is to give anyone looking into an organization’s cybersecurity posture insight or a readable overview of their security requirements and the controls they have in place to meet those requirements. A SSP should reference security-related documents for the information system such as a risk assessment, plan of action and milestones, accreditation decision letter, privacy impact assessment, contingency plan, configuration management plan, security configuration checklists, and system interconnection agreements as appropriate. The planning of system security supports the SDLC and should be kept updated to accurately reflect the most current state of the system. According to NIST, the Chief Information Officer (CIO) and Systems Security Officers are ultimately responsible for creating a system security plan for their organization.
Hi Michael,
The IS Security Plan template on page 28 of NIST SP 800-18R1 or the whole part 3 of this document can give you what should be included in the IS security plan in generally.
Since the risk cannot be eliminated 100% and there is always residual risk remaining, how important is it to asses a residual risk on information systems, and what could be the examples for residual risk? Is it also important to assess residual risk as much as the risks we can control while working on system security plan?
When small businesses encounter some risk losses that are not enough to warrant spending money to avoid the risk, they may choose to accept the risk. These risks are usually not catastrophic, or they are too expensive to be worth the extra money, so businesses choose to accept them. Small businesses may self-insure, or use third-party insurance to transfer risk to insurance companies.
I do not think that accepting risk by default should be a practical option, even for smaller companies. Even if the company is small in size they should still perform a system characterization of their assets and then identify potential threats and vulnerabilities. After this they can prioritize control and allocate their resources to the systems that will have the highest risk rating. Once they have determined they can no longer afford to limit mitigate or transfer these risk then accepting may be the only option they have remaining.
In the case of Small Businesses, I would say that in most cases accepting risk is the only viable option. Depending on the size of the business, the risks are likely not going to have catastrophic results. Since they cannot financially deal with the risks via controls or insurance, the best option would to have someone, or a few people, again depending on the size of the business, who have some level of risk management knowledge, and who can provide training/awareness to those who don’t. This can hopefully mitigate anything too hazardous.
How do you test and evaluate a system to determine what security controls are implemented within the system and who’s responsibility would this fall under?
Hi Michael,
From my understanding, a security controls assessment is the first step in the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization. This assessment includes the severity of weaknesses discovered in the information system and its environment of operation. A final report is produced with the results and findings from the assessment, and includes corrective actions to address the identified vulnerabilities. This assessment is typically conducted by a security control assessor. However, the Chief Information Officer’s responsibilities do include the identification and coordination of common security controls for the agency; they are usually assisted by the information system owner and information owner as well.
Hi Ryan,
In my opinion, I believe there is a system owner and an authorizing official so two different people. A system owner is the individual responsible for the overall procurement, development, integration, modification, operation, maintenance, and retirement of an information system. An authorizing official is responsible to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals. From these definitions, my answer is no they are not the same individual. This is to avoid a conflict of interest between the individual authorizing the system and the owner/manager of the system
I believe it would be difficult for companies to automate all parts of the SSP. For completion of the SSP requires contributions from the management team of each organization that is designing one. Each SSP is different for each system and how it will be utilized at the organization. The same system at one company would have a different SSP than at another company. For this reason I would find automating very difficult.
Additionally, since SSPs are not a “one-size-fits-all” solution, I believe that automating any part of the SSP preparation could result in important factors specific/unique to the company being forgotten or skipped over.
I am not sure if I understood your question but I believe we need IS security architecture during building enterprise IS architecture because all of this are related to information systems. If we want to build a strong enterprise IS architecture, we need the necessary controls, software, application in order to protect our system from hackers. That’s why we are referring to firewalls, perimeter to make sure we have strong physical security that will block people from accessing the building and intrusion detection system that will alert if unauthorized people are trying to get into the system.
yes, it considers to everyone to properly implement security control and protect the organization in any type of threat environment, it warns about what will be lost if setup wrong security control how they impact system security, work environment, financial losses, goodwill in the market trust of customers will be lost.it defines a very clear picture of user level, data flow process, application standards, minimum security control, incident response, and more which is one of the best documentation for the security professional.
A company of any size can save on costs by building the SSP early on. If an SSP is built later on, the company may need to retroactively add in controls and/or reorganize systems which can be more costly and less effective.
In an ideal world an SSP would be developed before an organization uses a system or set of systems to support business operations – however, the majority of the time this is never the case. An SSP should be developed as soon as possible and should constantly be monitored and / or updated periodically to ensure security objectives are in line with business objectives.
Regarding your second question, if an organization were looking to adopt a new system this could potentially delay the development of an SSP. If, for example, the organization didn’t determine what functionality components they would deploy in the system than this certainly would be a good reason to delay development of the SSP.
Bryan great point. In addition, the SSP is used is a sufficient document that provides detail on how each planning control should be implemented in order for the business operation and objective can be achieved.
Question for the week: Asked in reference to NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems”, pp. 18-26
Are there any laws, regulations, or policies besides the Privacy Act of 1974, that you are familiar with which establishes specific requirements for confidentiality, integrity, or availability?
This is a great question and I was asking myself the same thing. However, even though the System Owner and Chief Information Officer are very similar in what their duties are, I believe it is important to have the System Owner. And I believe it is because the system owner is a little more hands on in the planning and works directly with the other information owners which I believe to be critical.
Great points, Jason! Additionally, especially in a larger corporation, I believe that having someone who can be more focused on the system is important. the CISO of a large company may have numerous things to oversee which would keep them from being able to give a specific system the attention that it needs.
“FIPS 200 provides seventeen minimum security requirements for federal information and
information systems. The requirements represent a broad-based, balanced information
security program that addresses the management, operational, and technical aspects of
protecting the confidentiality, integrity, and availability of federal information and
information systems. An agency must meet the minimum security requirements in this
standard by applying security controls selected in accordance with NIST SP 800-53 and
the designated impact levels of the information systems.”
What is the Penalty for not meeting these standards?
In system security, everyone is responsible for the Security plan because, in the business and handling data, you have to make sure to keep information reliable and remain aware of security threats like bad actors.
The risk assessment process I believe is trued and tried, and so effective for the most part. One thing I think that organization’s don’t do enough of is an assessment of risks that similar organizations face. If an organization in the same industry has something marked as medium risk but your organization has it marked as low, maybe some research should be done as to why they consider it to be medium risk.
Corey, the six risk assessment process will be to Identify the area of concern and to Analyze the found areas of this risk by Prioritizing the risk phase and Owning to the flaws and thinking on how better to Respond to mitigate it risk before it gets overly escalated beyond control and Monitoring the effective control put in place to monitor the whole process.
A question I have in regards to this weeks reading has to do with FedRAMP. I’m curious what steps an organization must complete in order to achieve FedRAMP certification/authorization?
The Federal Risk and Authorization Management Program (FedRAMP) is a federal-level program that encourages the use of safe cloud services by establishing a standardized method to security assessment, authorization, and continuous monitoring of cloud goods and services.
FedRAMP enables agencies to employ modern cloud technology while focusing on government data security and preservation.
Should all companies offering cloud services ascribe to be FedRAMP authorized? What are some situations where this would (and wouldn’t be beneficial) to a company to implement a security plan like this?
What should be included in a system security plan and who should ultimately be responsible for creating this plan for an organization?
The creation of an information security plan is usually delegated to the Senior Agency Information Security Officer. This person is typically appointed by the Chief Information Officer. A security plan should include the following information:
Identifiers and Classifications:
– System Name and Identifier- This should be unique and support the agency’s ability to collect information and metrics specific to the system.
– System Categorization- These are based on FIPS 199 and classifies the sensitivity of the data in the system.
– System Operational Status- This details the present state for the system, i.e. if it’s implemented, being implemented, or being modified.
– Information System Type- Describes whether the system is a major application or a general support system.
– General Description/ Purpose- Describes the function and purpose of the system.
– System Environment- Describes the systems in place and any environmental or technical factors that raise special security concerns.
– System Interconnection/Information Sharing- Provides an overview of how the system interfaces with other systems and what information may be exchanged.
Contacts for the system:
– System Owner- This is the point of contact for the system in addition to being responsible for coordinating the system development life cycle.
– Authorizing Official- This is a senior manager who has the authority to authorize operation of an information system.
– Other Contacts- Key personnel that can address inquiries into the system.
– Responsible Parties- Individuals who are responsible for each system’s operation and security.
Regulations and Controls:
– Laws, Regulations, and Policies Affecting the System- This should list any legal, regulatory, or policy requirements for the confidentiality, integrity, or availability of the system.
– Security Controls- Should be informed by NIST SP 800-53 and based on the system categorization from FIPS 199. Controls should be titled and contain a description of how the control is being implemented, scope of the control, and who is responsible for the implementation.
Administration and Maintenance:
– Completion and Approval Dates- The completion of the system security plan should be documented. This should be updated when the plan is reviewed and updated.
– Ongoing System Security Plan Maintenance- The plan should be assessed periodically to review any changes in system status, functionality, design, etc. Revisions should be made to address these changes.
Hi Michael,
The purpose of a system security plan is to give anyone looking into an organization’s cybersecurity posture insight or a readable overview of their security requirements and the controls they have in place to meet those requirements. A SSP should reference security-related documents for the information system such as a risk assessment, plan of action and milestones, accreditation decision letter, privacy impact assessment, contingency plan, configuration management plan, security configuration checklists, and system interconnection agreements as appropriate. The planning of system security supports the SDLC and should be kept updated to accurately reflect the most current state of the system. According to NIST, the Chief Information Officer (CIO) and Systems Security Officers are ultimately responsible for creating a system security plan for their organization.
Hi Michael,
The IS Security Plan template on page 28 of NIST SP 800-18R1 or the whole part 3 of this document can give you what should be included in the IS security plan in generally.
Since the risk cannot be eliminated 100% and there is always residual risk remaining, how important is it to asses a residual risk on information systems, and what could be the examples for residual risk? Is it also important to assess residual risk as much as the risks we can control while working on system security plan?
Is accepting risk by default a practical option for small businesses, presuming that they can not afford to avoid, limit, or transfer risk?
Hi Elizabeth,
When small businesses encounter some risk losses that are not enough to warrant spending money to avoid the risk, they may choose to accept the risk. These risks are usually not catastrophic, or they are too expensive to be worth the extra money, so businesses choose to accept them. Small businesses may self-insure, or use third-party insurance to transfer risk to insurance companies.
Hi Elizabeth,
I do not think that accepting risk by default should be a practical option, even for smaller companies. Even if the company is small in size they should still perform a system characterization of their assets and then identify potential threats and vulnerabilities. After this they can prioritize control and allocate their resources to the systems that will have the highest risk rating. Once they have determined they can no longer afford to limit mitigate or transfer these risk then accepting may be the only option they have remaining.
Elizabeth,
In the case of Small Businesses, I would say that in most cases accepting risk is the only viable option. Depending on the size of the business, the risks are likely not going to have catastrophic results. Since they cannot financially deal with the risks via controls or insurance, the best option would to have someone, or a few people, again depending on the size of the business, who have some level of risk management knowledge, and who can provide training/awareness to those who don’t. This can hopefully mitigate anything too hazardous.
How do you test and evaluate a system to determine what security controls are implemented within the system and who’s responsibility would this fall under?
Hi Michael,
From my understanding, a security controls assessment is the first step in the testing or evaluation of security controls to determine the extent to which the controls are implemented correctly, operating as intended, and producing the desired outcome with respect to meeting the security requirements for an information system or organization. This assessment includes the severity of weaknesses discovered in the information system and its environment of operation. A final report is produced with the results and findings from the assessment, and includes corrective actions to address the identified vulnerabilities. This assessment is typically conducted by a security control assessor. However, the Chief Information Officer’s responsibilities do include the identification and coordination of common security controls for the agency; they are usually assisted by the information system owner and information owner as well.
Should the system owner and the authorizing official of the system security plan be the same individual? Why or why not?
Hi Ryan,
In my opinion, I believe there is a system owner and an authorizing official so two different people. A system owner is the individual responsible for the overall procurement, development, integration, modification, operation, maintenance, and retirement of an information system. An authorizing official is responsible to formally assume responsibility for operating an information system at an acceptable level of risk to agency operations (including mission, functions, image, or reputation), agency assets, or individuals. From these definitions, my answer is no they are not the same individual. This is to avoid a conflict of interest between the individual authorizing the system and the owner/manager of the system
Can the companies automate the process of documenting the SSP? If yes, What tools are available to do so?
Hi Shubham,
I believe it would be difficult for companies to automate all parts of the SSP. For completion of the SSP requires contributions from the management team of each organization that is designing one. Each SSP is different for each system and how it will be utilized at the organization. The same system at one company would have a different SSP than at another company. For this reason I would find automating very difficult.
Additionally, since SSPs are not a “one-size-fits-all” solution, I believe that automating any part of the SSP preparation could result in important factors specific/unique to the company being forgotten or skipped over.
Do we need to consider IS security architecture during building enterprise IS architecture?
Hi Hang,
I am not sure if I understood your question but I believe we need IS security architecture during building enterprise IS architecture because all of this are related to information systems. If we want to build a strong enterprise IS architecture, we need the necessary controls, software, application in order to protect our system from hackers. That’s why we are referring to firewalls, perimeter to make sure we have strong physical security that will block people from accessing the building and intrusion detection system that will alert if unauthorized people are trying to get into the system.
yes, it considers to everyone to properly implement security control and protect the organization in any type of threat environment, it warns about what will be lost if setup wrong security control how they impact system security, work environment, financial losses, goodwill in the market trust of customers will be lost.it defines a very clear picture of user level, data flow process, application standards, minimum security control, incident response, and more which is one of the best documentation for the security professional.
For a small start-up company, how should they lay out the system security plan to save cost?
A company of any size can save on costs by building the SSP early on. If an SSP is built later on, the company may need to retroactively add in controls and/or reorganize systems which can be more costly and less effective.
When should an SSP be developed? Why would an organization delay creating an SSP?
In an ideal world an SSP would be developed before an organization uses a system or set of systems to support business operations – however, the majority of the time this is never the case. An SSP should be developed as soon as possible and should constantly be monitored and / or updated periodically to ensure security objectives are in line with business objectives.
Regarding your second question, if an organization were looking to adopt a new system this could potentially delay the development of an SSP. If, for example, the organization didn’t determine what functionality components they would deploy in the system than this certainly would be a good reason to delay development of the SSP.
Bryan great point. In addition, the SSP is used is a sufficient document that provides detail on how each planning control should be implemented in order for the business operation and objective can be achieved.
Question for the week: Asked in reference to NIST SP 800-18r1 “Guide for Developing Security Plans for Federal Information Systems”, pp. 18-26
Are there any laws, regulations, or policies besides the Privacy Act of 1974, that you are familiar with which establishes specific requirements for confidentiality, integrity, or availability?
Is it important to have a System owner if we already have a Chief Information Officer?
Hello Ornella,
This is a great question and I was asking myself the same thing. However, even though the System Owner and Chief Information Officer are very similar in what their duties are, I believe it is important to have the System Owner. And I believe it is because the system owner is a little more hands on in the planning and works directly with the other information owners which I believe to be critical.
Great points, Jason! Additionally, especially in a larger corporation, I believe that having someone who can be more focused on the system is important. the CISO of a large company may have numerous things to oversee which would keep them from being able to give a specific system the attention that it needs.
“FIPS 200 provides seventeen minimum security requirements for federal information and
information systems. The requirements represent a broad-based, balanced information
security program that addresses the management, operational, and technical aspects of
protecting the confidentiality, integrity, and availability of federal information and
information systems. An agency must meet the minimum security requirements in this
standard by applying security controls selected in accordance with NIST SP 800-53 and
the designated impact levels of the information systems.”
What is the Penalty for not meeting these standards?
Should members of the business be involved in developing a system security plan? If so, who should be involved? When do they get involved?
In system security, everyone is responsible for the Security plan because, in the business and handling data, you have to make sure to keep information reliable and remain aware of security threats like bad actors.
What are your thoughts on the six step risk assessment process?
Corey,
The risk assessment process I believe is trued and tried, and so effective for the most part. One thing I think that organization’s don’t do enough of is an assessment of risks that similar organizations face. If an organization in the same industry has something marked as medium risk but your organization has it marked as low, maybe some research should be done as to why they consider it to be medium risk.
Corey, the six risk assessment process will be to Identify the area of concern and to Analyze the found areas of this risk by Prioritizing the risk phase and Owning to the flaws and thinking on how better to Respond to mitigate it risk before it gets overly escalated beyond control and Monitoring the effective control put in place to monitor the whole process.
A question I have in regards to this weeks reading has to do with FedRAMP. I’m curious what steps an organization must complete in order to achieve FedRAMP certification/authorization?
Does FedRAMP apply to Cloud infrastructure?
The Federal Risk and Authorization Management Program (FedRAMP) is a federal-level program that encourages the use of safe cloud services by establishing a standardized method to security assessment, authorization, and continuous monitoring of cloud goods and services.
FedRAMP enables agencies to employ modern cloud technology while focusing on government data security and preservation.
What are the major categories of driving driving forces that a company must consider for the future?