A key point from NIST SP 800-53Ar4 “Assessing Security and Privacy Controls for Federal Information and Information Systems” was the timeline of assessments within the system development life cycle. Security assessments are to be conducted routinely during the development and acquisition phase as well as the implementation phase of the lifecycle. Privacy assessments are to be done in these phases as well. This is to ensure that the security and privacy controls are correctly designed, developed, and implemented before the operations and maintenance phase of the system. The main reason for this timeline is to catch weaknesses and deficiencies within the security and privacy controls early in the life cycle, which makes solutions easier and more cost effective. It is also expected that security and privacy assessments will be done during the operations and maintenance phases to make sure the controls continue to be effective during operations. Finally, these assessments are conducted at the end of the system life cycle for information disposal and retention scheduling. The main point I drew from this is that security and privacy assessments should be an ongoing process. This is essential in the fast-paced, rapidly evolving environment of security and privacy. New laws and regulations are consistently being added and modified, so organizations must assess controls as often as possible. Similarly, security issues are ever-evolving. New data breaches and security patches are evidence of this.
The document NIST SP 800 53A talks about accessing security and privacy controls implemented in an information system. This assessment is step 4 in the risk management framework security life cycle. In steps 1-3 of this life cycle and information system is categorized, security controls are selected, and those security controls are implemented. Next, the security controls need to be assessed to make sure they were implemented correctly, operating as intended, and lastly the expected outcome is being met. Performing these assessments during the system development life cycle can greatly increase chances that the implemented security controls are performing correctly and meeting the overall goal of protecting confidentiality, integrity, and availability.
A key takeaway I had from this publication is the key activities that an organization needs to perform to prepare for a security and privacy control assessment. Security assessments can be extremely complex. Some examples of activities that an organization does to prepare for a security assessment are: Ensuring that security and privacy controls identified as common controls (and the common portion of hybrid controls) have been assigned to appropriate organizational entities (i.e., common control providers) for development and implementation, and Establishing time frames for completing the assessments and key milestone decision points required by the organization to effectively manage the assessments. The key to an effective assessment is for the organization to be as detailed as possible up front. This allows the organization to receive as much productive feedback as possible, which leads to them making productive changes to fix any weak points in their system.
Hi Christopher. Excellent point that you bring up. I agree with you that security assessments can be very complicated and complex. As you stated having detailed information about the organization’s data is fundamental for proper cybersecurity. Information technology security assessment is an ongoing process and cycle. It is never over and will always need to be reassessed and adjusted to the needs of risk and vulnerabilities.
A key take away I took away from this reading was that security and privacy assessments can be done in many different stages of the system development life cycle to certify that security and privacy controls are effective. This publication gives us a variety of procedures to support security and privacy assessment activities. For example, security assessments are conducted by developers and system integrators during the development phase of the life cycle. Privacy assessments are conducted by senior agency officials. The many assessments ensures the controls are properly developed, implemented, and consistent with the organization’s goals and security architecture before it enters the operations and maintenance phase. This includes design and code reviews, application scanning, regression testing, etc. It is much quicker, more efficient, and cost effective when security and privacy related weaknesses are found early on in the SDLC process.
I agree that the security and privacy controls assessments should be reviewed in as many stages and possible with the SDLC. I think you pointed out a key point, in the examples provided that different teams are working in different phases.
A key takeaway is that findings from the assessment of security and privacy controls labelled as “other than satisfied” will either result in immediate attention and remedial action or maybe deemed “inconsequential” as it presents no significant risk to the entity. In both instances of either action or non-action require Senior leadership to be involved in the mitigation process; this ensures that resources are first allocated to high-risk information assets. If such an approach is not used, chances are resources could be poured into correcting deficiencies that pose the least degree of risk. This would no doubt create and perhaps expand opportunities for threat actors to take advantage of poorly protected information systems/assets.
The key point in the NIST SP 800-53Ar4 reading was the descriptions of how security and privacy assessments conduct themselves during their life cycles. Privacy assessment is nonstop due to compliance purposes with applicable privacy laws and policies, and at the end of the life cycle, security assessments are conducted to ensure that important organizational information is removed from the information system prior to disposal.
A key point from this reading is its emphasis on identifying, implementing, and assessing common controls. An organization that uses common controls across different business units will save itself money and time in multiple ways. When one business unit already has experience with the implementation of a control, any other departments can rely on the guidance of the that unit when implementing the same control, There may also be lower marginal costs for instances of the control beyond the initial implementation, saving the organization money over time. When multiple areas use the same control for their systems, it also simplifies the assessment and review process. Approvers and auditors don’t have to familiarize themselves with additional controls if multiple systems use the same common control.
In a similar vein, the document also points out the value of implementing organization-wide tools and techniques in the assessment process itself. This provides the same utility of common controls, in that different business areas can pool resources and knowledge-share during their assessment process.
My key takeaways from the guidance are the fact that the (1) security and privacy assessments can take place at any point within the system development lifecycle and the (2) procedures/starting point for completing these assessments were provided. Security and privacy assessments should be performed on an ongoing basis, as change is constant and compliance with various laws and regulations is required. Depending on the risk and criticality of the project, assessments might be necessary at multiple points in a project. The assessment procedures are outlined and explain the various options for completion including examine, interview, and test. Determining which method to use depends on the coverage (scope and breadth of the processes) and the depth (level of detail to drill down when performing the testing processes) required for the level of assessment. The procedures can help drive consistency between organizations regarding the manner in which security and privacy assessments are completed and how to prioritize controls for testing.
Many organizations probably do assessments or audits with a grading scale for controls or requirements, such as 1 through 5 maturity range. NIST Special Publication 800-53A, “Assessing Security and Privacy Controls for Federal Information and Information Systems,” prescribes something a little different. When looking at the requirements, NIST SP 800-53A directs assessors to either find that the organization “satisfied” the required controls or “other than satisfied.” Basically you either did or did not meet the requirement The guidance does, though, leave it up to assessors to determine if they want to elaborate beyond just “other than satisfied” and use a scale, for example. An organization I have worked at used Compliant, Partially Compliant, and Non-Compliant as scores in its NIST SP 800-53 assessments.
NIST 800 53Ar4 section 3.2 provided detailed steps on how to develop security and privacy assessment plans. It includes the determination of which security or privacy controls are to be assessed, selection procedures to assess the security or privacy controls, tailored assessment procedures, developed assessment procedures for organization-specific controls, optimized selection assessment procedures to ensure maximum efficiency, and finalized assessment plans and obtained approval to execute plans. This section provides a detailed roadmap of how to conduct a security assessment.
One of the key takeaways of NISR Special Publication 800-53A Revision 4 “Assessing Security and Privacy Controls in Federal Information Systems and Organizations is the analyzing assessment report results.” By using the labels “satisfied” and “other than satisfied”, the report format of the assessment results provides visibility to organization officials so that they can understand specific weaknesses and deficiencies in the internal or inherited security or proprietary controls of the information system. According to the organization’s priority, it shows that the organization’s resources are effectively allocated. It can make sure to provide resources for the information system first to support the organization’s most critical and sensitive tasks. It can also correct the shortcomings of posting the greatest degree of risk.
My key takeaway is that the security and privacy requirements should be reviewed through all phases of the System Development Livecycle. This point is important for any organization to consider as each phase of the SDLC is created by different parts of the IT team. It is good that each phase, and subsections of each phase are reviewed on a consistent basis so the final product is safe and secure.
Great point, Mike. It makes sense that security and privacy requirements are reviewed at each stage of the SDLC, as these requirements may change when progressing through the phases. This approach would ensure that any potential issues are immediately remediated.
The part that stood out to me the most from reading NIST Special Publication 800-53A was the very first sentence in the Foreward: “Security control assessments and privacy control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass inspections or audits—rather, such assessments are the principal vehicle used to verify that implemented security controls and privacy controls are meeting their stated goals and objectives.” As a former auditor of over 10 years, this really resonates with me. I think it’s an important message for the auditor and the auditee. Auditors are not out to catch people making mistakes or be like cops. They exist to help give assurance that controls will help an organization meet stated goals and objectives. Auditees should understand why controls exist and how they contribute toward meeting goals and objectives instead of thinking they are just “check-the-box” activities that have no point.
As an IT Auditor myself I really appreciate the sentiment. We are definitely not cops. Thankfully, I have not had any problems in my young career. I’ve heard many horror stories but the message you chose is very important.
This document provides guidance for implementing specific steps in the Risk Management Framework. With help of this guidance, organizations able to tailor the basic assessment procedures provided, include customizing the assessment procedures to match the characteristics of the information system more closely, and/or adding assessment procedures details to adequately meet the risk management needs of the organization. This document is intended to serve a diverse group of information system, information security, and privacy professionals. However, success requires the cooperation and collaboration among all parties having a vested interest in the organization’s information security.
As some of my other classmates have noted, my biggest takeaway is the section outlining security assessments that are conducted within the system development lifecycle. Typically, we tend to overlook security in the development phase. That being said, it is important that best practices are being used in the development phase such as segregation of duties and dummy data. Developers shouldn’t be deploying and deployers shouldn’t be developing what they’re deploying. Additionally, test accounts and information should be used, not real account information that has access to the live environment.
Hi Panayiotis – It is plain from the reading that to achieve effective application security, information security best practices should be followed throughout application development. Even beyond application security, the security of production data must be maintained, and if developers have access to any kind of real production data, that represents a serious vulnerability to the organization’s information.
The key take-away I found interesting was that the purpose of implement security and privacy assessments in the system development SDLC life-cycle is to confirm that security and privacy controls are effectively implemented in the operational environment. The objectives from, NIST 800 53Ar4, are outlined to help that organizational information systems have effective plans in place to keep security and privacy at an appropriate level. In the document, section 3.2 provides the steps to develop security assessment plans. The procedures outline in NIST 800 53Ar4 provides a foundation for security and privacy that organizations can use to fully benefit from these implemented plans.
A key point from NIST SP 800-53Ar4 “Assessing Security and Privacy Controls for Federal Information and Information Systems” was the timeline of assessments within the system development life cycle. Security assessments are to be conducted routinely during the development and acquisition phase as well as the implementation phase of the lifecycle. Privacy assessments are to be done in these phases as well. This is to ensure that the security and privacy controls are correctly designed, developed, and implemented before the operations and maintenance phase of the system. The main reason for this timeline is to catch weaknesses and deficiencies within the security and privacy controls early in the life cycle, which makes solutions easier and more cost effective. It is also expected that security and privacy assessments will be done during the operations and maintenance phases to make sure the controls continue to be effective during operations. Finally, these assessments are conducted at the end of the system life cycle for information disposal and retention scheduling. The main point I drew from this is that security and privacy assessments should be an ongoing process. This is essential in the fast-paced, rapidly evolving environment of security and privacy. New laws and regulations are consistently being added and modified, so organizations must assess controls as often as possible. Similarly, security issues are ever-evolving. New data breaches and security patches are evidence of this.
The document NIST SP 800 53A talks about accessing security and privacy controls implemented in an information system. This assessment is step 4 in the risk management framework security life cycle. In steps 1-3 of this life cycle and information system is categorized, security controls are selected, and those security controls are implemented. Next, the security controls need to be assessed to make sure they were implemented correctly, operating as intended, and lastly the expected outcome is being met. Performing these assessments during the system development life cycle can greatly increase chances that the implemented security controls are performing correctly and meeting the overall goal of protecting confidentiality, integrity, and availability.
A key takeaway I had from this publication is the key activities that an organization needs to perform to prepare for a security and privacy control assessment. Security assessments can be extremely complex. Some examples of activities that an organization does to prepare for a security assessment are: Ensuring that security and privacy controls identified as common controls (and the common portion of hybrid controls) have been assigned to appropriate organizational entities (i.e., common control providers) for development and implementation, and Establishing time frames for completing the assessments and key milestone decision points required by the organization to effectively manage the assessments. The key to an effective assessment is for the organization to be as detailed as possible up front. This allows the organization to receive as much productive feedback as possible, which leads to them making productive changes to fix any weak points in their system.
Hi Christopher. Excellent point that you bring up. I agree with you that security assessments can be very complicated and complex. As you stated having detailed information about the organization’s data is fundamental for proper cybersecurity. Information technology security assessment is an ongoing process and cycle. It is never over and will always need to be reassessed and adjusted to the needs of risk and vulnerabilities.
A key take away I took away from this reading was that security and privacy assessments can be done in many different stages of the system development life cycle to certify that security and privacy controls are effective. This publication gives us a variety of procedures to support security and privacy assessment activities. For example, security assessments are conducted by developers and system integrators during the development phase of the life cycle. Privacy assessments are conducted by senior agency officials. The many assessments ensures the controls are properly developed, implemented, and consistent with the organization’s goals and security architecture before it enters the operations and maintenance phase. This includes design and code reviews, application scanning, regression testing, etc. It is much quicker, more efficient, and cost effective when security and privacy related weaknesses are found early on in the SDLC process.
Quynh,
I agree that the security and privacy controls assessments should be reviewed in as many stages and possible with the SDLC. I think you pointed out a key point, in the examples provided that different teams are working in different phases.
A key takeaway is that findings from the assessment of security and privacy controls labelled as “other than satisfied” will either result in immediate attention and remedial action or maybe deemed “inconsequential” as it presents no significant risk to the entity. In both instances of either action or non-action require Senior leadership to be involved in the mitigation process; this ensures that resources are first allocated to high-risk information assets. If such an approach is not used, chances are resources could be poured into correcting deficiencies that pose the least degree of risk. This would no doubt create and perhaps expand opportunities for threat actors to take advantage of poorly protected information systems/assets.
The key point in the NIST SP 800-53Ar4 reading was the descriptions of how security and privacy assessments conduct themselves during their life cycles. Privacy assessment is nonstop due to compliance purposes with applicable privacy laws and policies, and at the end of the life cycle, security assessments are conducted to ensure that important organizational information is removed from the information system prior to disposal.
A key point from this reading is its emphasis on identifying, implementing, and assessing common controls. An organization that uses common controls across different business units will save itself money and time in multiple ways. When one business unit already has experience with the implementation of a control, any other departments can rely on the guidance of the that unit when implementing the same control, There may also be lower marginal costs for instances of the control beyond the initial implementation, saving the organization money over time. When multiple areas use the same control for their systems, it also simplifies the assessment and review process. Approvers and auditors don’t have to familiarize themselves with additional controls if multiple systems use the same common control.
In a similar vein, the document also points out the value of implementing organization-wide tools and techniques in the assessment process itself. This provides the same utility of common controls, in that different business areas can pool resources and knowledge-share during their assessment process.
My key takeaways from the guidance are the fact that the (1) security and privacy assessments can take place at any point within the system development lifecycle and the (2) procedures/starting point for completing these assessments were provided. Security and privacy assessments should be performed on an ongoing basis, as change is constant and compliance with various laws and regulations is required. Depending on the risk and criticality of the project, assessments might be necessary at multiple points in a project. The assessment procedures are outlined and explain the various options for completion including examine, interview, and test. Determining which method to use depends on the coverage (scope and breadth of the processes) and the depth (level of detail to drill down when performing the testing processes) required for the level of assessment. The procedures can help drive consistency between organizations regarding the manner in which security and privacy assessments are completed and how to prioritize controls for testing.
Many organizations probably do assessments or audits with a grading scale for controls or requirements, such as 1 through 5 maturity range. NIST Special Publication 800-53A, “Assessing Security and Privacy Controls for Federal Information and Information Systems,” prescribes something a little different. When looking at the requirements, NIST SP 800-53A directs assessors to either find that the organization “satisfied” the required controls or “other than satisfied.” Basically you either did or did not meet the requirement The guidance does, though, leave it up to assessors to determine if they want to elaborate beyond just “other than satisfied” and use a scale, for example. An organization I have worked at used Compliant, Partially Compliant, and Non-Compliant as scores in its NIST SP 800-53 assessments.
NIST 800 53Ar4 section 3.2 provided detailed steps on how to develop security and privacy assessment plans. It includes the determination of which security or privacy controls are to be assessed, selection procedures to assess the security or privacy controls, tailored assessment procedures, developed assessment procedures for organization-specific controls, optimized selection assessment procedures to ensure maximum efficiency, and finalized assessment plans and obtained approval to execute plans. This section provides a detailed roadmap of how to conduct a security assessment.
One of the key takeaways of NISR Special Publication 800-53A Revision 4 “Assessing Security and Privacy Controls in Federal Information Systems and Organizations is the analyzing assessment report results.” By using the labels “satisfied” and “other than satisfied”, the report format of the assessment results provides visibility to organization officials so that they can understand specific weaknesses and deficiencies in the internal or inherited security or proprietary controls of the information system. According to the organization’s priority, it shows that the organization’s resources are effectively allocated. It can make sure to provide resources for the information system first to support the organization’s most critical and sensitive tasks. It can also correct the shortcomings of posting the greatest degree of risk.
My key takeaway is that the security and privacy requirements should be reviewed through all phases of the System Development Livecycle. This point is important for any organization to consider as each phase of the SDLC is created by different parts of the IT team. It is good that each phase, and subsections of each phase are reviewed on a consistent basis so the final product is safe and secure.
Great point, Mike. It makes sense that security and privacy requirements are reviewed at each stage of the SDLC, as these requirements may change when progressing through the phases. This approach would ensure that any potential issues are immediately remediated.
The part that stood out to me the most from reading NIST Special Publication 800-53A was the very first sentence in the Foreward: “Security control assessments and privacy control assessments are not about checklists, simple pass-fail results, or generating paperwork to pass inspections or audits—rather, such assessments are the principal vehicle used to verify that implemented security controls and privacy controls are meeting their stated goals and objectives.” As a former auditor of over 10 years, this really resonates with me. I think it’s an important message for the auditor and the auditee. Auditors are not out to catch people making mistakes or be like cops. They exist to help give assurance that controls will help an organization meet stated goals and objectives. Auditees should understand why controls exist and how they contribute toward meeting goals and objectives instead of thinking they are just “check-the-box” activities that have no point.
As an IT Auditor myself I really appreciate the sentiment. We are definitely not cops. Thankfully, I have not had any problems in my young career. I’ve heard many horror stories but the message you chose is very important.
This document provides guidance for implementing specific steps in the Risk Management Framework. With help of this guidance, organizations able to tailor the basic assessment procedures provided, include customizing the assessment procedures to match the characteristics of the information system more closely, and/or adding assessment procedures details to adequately meet the risk management needs of the organization. This document is intended to serve a diverse group of information system, information security, and privacy professionals. However, success requires the cooperation and collaboration among all parties having a vested interest in the organization’s information security.
As some of my other classmates have noted, my biggest takeaway is the section outlining security assessments that are conducted within the system development lifecycle. Typically, we tend to overlook security in the development phase. That being said, it is important that best practices are being used in the development phase such as segregation of duties and dummy data. Developers shouldn’t be deploying and deployers shouldn’t be developing what they’re deploying. Additionally, test accounts and information should be used, not real account information that has access to the live environment.
Hi Panayiotis – It is plain from the reading that to achieve effective application security, information security best practices should be followed throughout application development. Even beyond application security, the security of production data must be maintained, and if developers have access to any kind of real production data, that represents a serious vulnerability to the organization’s information.
The key take-away I found interesting was that the purpose of implement security and privacy assessments in the system development SDLC life-cycle is to confirm that security and privacy controls are effectively implemented in the operational environment. The objectives from, NIST 800 53Ar4, are outlined to help that organizational information systems have effective plans in place to keep security and privacy at an appropriate level. In the document, section 3.2 provides the steps to develop security assessment plans. The procedures outline in NIST 800 53Ar4 provides a foundation for security and privacy that organizations can use to fully benefit from these implemented plans.