This section of the document addresses the issues of security considerations that are entirely unique to the SDLC. Among the various key security activities is risks assessment or assessing risks to system. The purpose of risk assessment is to evaluate current knowledge of the system’s design. It includes the stated requirements, and even the least security requirements attained from the security categorization process used to determine the effectiveness of the risk assessment strategies used to avoid the projected risks. For risk assessment strategies to be successful, the must be formulated, implemented and monitored by people with adequate knowledge in the disciplines within the risks assessment system domain such as operations experts and technology experts.
Security risk assessment measures should be implemented design specifications are approved to facilitate additional specifications and provide room for further improvement and justification of the design specifications. However, apart from applying the risk assessment measures, organizations must evaluate how the measures will affect their organizations lest they yield more risks. Hence enterprise reviews are important to provide more clear understanding of the risks, threats and vulnerabilities that seek to be controlled. A refined risk assessment is expected to be a mature system design that reflects on the potential risks of a system, knows the actual weaknesses of a design, the contracts of a project and controls them, based on the present information and the goals of the organization.
A security risk assessment identifies, assesses, and implements key security controls in applications. It also focuses on preventing application security defects and vulnerabilities.
Carrying out a risk assessment allows an organization to view the application portfolio holistically—from an attacker’s perspective. It supports managers in making informed resource allocation, tooling, and security control implementation decisions. Thus, conducting an assessment is an integral part of an organization’s risk management process.
I’d like to give my opinion on 3.2.3.3 “Design Security Architecture”
When it comes to the enterprise security or server system, thoughtful integration and environmental design should support safety. As the need for information services increases, it is becoming more important to plan these services and understand how they will be integrated into the system. The description addresses
“EA should be reviewed for optimal integration.” However, I think it also should be planned ahead, because you need to keep revisiting it. Keeping security discreet and strong is something more architects and architects should make a priority.
system auditing strategy that should be developed to enable an accurate trace or reconstruction of all priority and high-risk work flows. To develop system auditing strategy, the NIST or other guidelines and control frameworks should apply for it. Each control framework typically has a big amount of controls that are meant to assist audit, anything from user passwords to data storage or physical controls.
As I was reading through the NIST 800-64 publication, which revolved around “Security Considerations in the Software Development Life Cycle”, I took a particular interest in the section focusing on how and why testing is conducted. While I had initially known that testing was meant to be performed on the developmental, functional and security aspects of a given project as it makes its way through the software development life cycle, I did find more detailed information through the reading on what we look for during testing on each of these aspects. What we look for, in order to ensure that testing is thorough and ensures both functional and security requirement compliance, is specificity, repeatability, and iteration. Specificity entails that scoped testing is performed to ensure relevant security requirements function in an appropriate environment as intended. Repeatability involves repeated functionality testing yielding the same or similar results every time. Iteration requires that testing segments of or whole processes produce satisfactory results in regards to functionality requirements of the system. One more thing that I was surprised to learn about while reading through this section was how important automation can be in certain parts of the testing process, as it is helps perform tests that need to be repeated in order to replicate the same circumstances every time.
Hello Imran, I like how you chose to focus on the “testing” aspect of the security considerations in the software development life cycle. Testing, as we’ve learned this year, is a critical aspect to insuring the functionality, capability, and limits of a new software. The repeatability of testing that you touched upon does sound like the theory of “insanity”. I feel that when testing a software’s security specifications, we must have a level of insanity to ensure that the users, their data, and the overall CIA of the system will be protected. Nice response!
In IT service delivery & support course, reviewing documentation and internal policy are mentioned repetitively. It is interesting here in “security considerations in the SDLC” mentioned several general types of control gates for the development phase which are all about reviewing. Those control gates are: Architecture/Design Review which including planned system design, potential integration with other systems, and incorporation of shares services and common security control; System performance review which evaluated the capability of delivering. System functional review is about reviewing the functional requirements and ensure they are detailed enough and testable, Mid-project status &financial review is really about ensuring is it still worth it regarding the effectiveness. Follow-on review of risk management decisions if the system/security controls/requirements change. Those control gates are interesting to know, and I would like to know more about how they are going to do reviewing and what metric are. I assume that goes back to the company’s internal policy and metric documents.
Hello,
As I read through your thoughts from the NIST reading on the “Security Considerations in the SDLC”, I found that you covered a lot of ground regarding control gates commonly found in the development phase in your response. A predominately featured type of control you mentioned frequently in your response was reviews, including financial reviews and regular design and performance reviews in order to ensure functionality and requirement compliance. I, too, would also be more interested in learning about some of the metrics used in some of the more specialized types of reviews for various types of projects.
The point that I want to talk about in this article is Develop Security Documentation. This article’s main idea is to assist agencies in building security into their IT development processes. For the part that we should read is how to incorporate security into SDLC in different phases. Authors mentioned that in developing security documentation the most prominent document is the System Security Plan. In the plan, it could include a configuration management plan, contingency plan, security awareness, training and education (SATE) plan, and other plans. The main purpose of these plans is to consider the security within the SDLC. Moreover, there are some tips for implementation. The security operations should not be driven by documentation of compliance but based on system need and described in compliance with security guidelines.
I like your points. System Security Plan is important. In NIST SP 800-18, the purpose of the system security plan is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements. The system security plan also delineates responsibilities and expected behavior of all individuals who access the system. The system security plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system.
Design security architecture is an enterprise alignment of the system to ensure the initiative fits the prospects of agencies and does not conflict or unnecessarily provide redundant services. Also, as the system matures and more decisions are made as to services utilized. Security designing consider services obtained externally, planned system interconnections, and the different orientations of system users. Security architecting can provide effective compensating controls when there are issues with implementing minimal security requirements with the system’s design specification and identify common controls that the system will inherit as well as who has responsibility for those common controls. For example, system auditing strategy developed to enable an accurate trace or reconstruction of all priority and high –risk workflows. The auditing strategy includes various audit records from several different components including the Web application, databases, mainframe, and Web services. The purpose should provide enough information to investigate potential security breaches and system failures, not be captured as much audit information as possible.
Hi Zhu,
You drove to a good discussion point about compensating controls. When performing risk assessment and its associated control testing, most organization tend to take compensating controls for granted. Compliance is always a concern for every organization that handles customers’ data. Unfortunately, it’s not always easy for companies to meet the security requirements of frameworks like HIPAA, PCI DSS, SOX etc., In the event an organization can’t satisfy the requirement for a protective measure, it adopts another mechanism that offers a similar level of security as the original standard. That’s where compensating controls come in. Some organizations think of compensating controls as shortcuts by which they can achieve compliance with little effort and little money spent that is completely wrong.
Compensating controls are useful when it comes to compliance. But they’re impermanent fixes that organizations should replace with the original control as soon as possible. Companies should never use them as shortcuts to achieve compliance.
This document focus on SDLC Phase: Development and Acquisition. What I found interesting is the section about Select and Document Security Controls. It reminds me of the planning phase of an information system project that we have discussed. The 4 phases include project initiation, planning, executing, closing. The selection of security controls consists of three activities: the selection of baseline security controls (including common security controls); the application of security control tailoring guidance to adjust the initial security control baseline; and the supplementation of the tailored baseline with additional controls based on an assessment of risk and local conditions.
So basically, agencies should go over the risk framework and evaluate risk carefully. More detailed “attack prevention” requirements will also help to ensure that security controls and methods are tested prior to release. Security controls are not one-dimensional and should be addressed as appropriate on multiple components throughout the system. Depending on the system, the assessment may need to be planned for all, some or none.
The purpose of the Select Step is to identify, select, tailor, and document the security and privacy controls necessary to protect the system and the organization commensurate with the risk to organizational operations and assets, individuals, other organizations, and the Nation.
NIST 800-64 publication focusses on incorporating security in each phase of SDLC from Initiation, Development, Implementation, Maintenance and Disposal phase. Reading assignment in PP 21-31 includes the second and third phase of SDLC which is security considerations in the development/acquisition phase and implementation/assessment phase. The security activity which interested me the most is Risk Assessment (3.2.3.1) to the system. I believe risk assessment process is an important task which decides the project success and it is the key component in SDLC. It contributes to the project success by establishing a list of internal and external risks. This assessment typically includes the identified risks, probability of occurrence, potential impact and proposed actions. Effective risk assessment strategies allow us to identify project’s strengths, weaknesses, opportunities and threats and thereby helps us to plan for the unexpected events.
Hi, I totally agree with your ideas of the important role of risk assessment. Many projects face some uncertainty in determining requirements. Ignoring these uncertainties early in the project and not addressing them as the project progresses can pose a significant threat to the project’s success. For the whole SDLC process, once the risks are not identified and solved in the earlier phase, it could affect the following phases.
Well said, Deepa. Risk is unavoidable when it comes to information systems. The threat of being breached has significantly increased. As a result, it is important that organizations take measures to prevent breaches and mitigate the damage if/when they do occur. The first place to start is with a risk assessment. Organizations that conduct risk assessments are better able to understand where their strengths and weaknesses lie when it comes to ensuring their data.
The assigned part in the NIST Special Publication 800-64 Security Considerations in the System Development Life Cycle describe the security consideration under SDLC Development/Acquisition and Implementation / Assessment phases. The question to be answered during the system design phase is how to achieve goals. The task of this phase is to design and implement the technical scheme of logic model according to the functional requirements specified in the system specification and considering the actual conditions. At the development stage, the security objectives of the system are determined through risk assessment, and this is also the phase which perform the most risk assessment. The system implementation phase is the stage to put the designed system into practice. The tasks of this stage include the purchase, installation and debugging of computers and other equipment, the preparation and debugging of programs, personnel training, data file conversion, system debugging and conversion. The assessment phase determines whether the system’s security objectives are met through risk assessment.
Hi Yuqing, I agree with your idea that the risk assessment is critical in the development stage. For an organization, risk assessment is a process to identify potential hazards and analyze what could happen if a hazard occurs. Moreover, if a potential risk is identified, a solution or plan of action should be developed.
In the NIST Special Publication 800-64 Revision 2, I took special interest in section 3.3.3.2 Integrate Security into Established Environments or Systems. This was particularly interesting because it focused on an issue very relevant to the Information Systems sphere of today — adding the security aspect to an existing legacy system. As we learned from last weeks class on “criteria for grading an information system” — security was not always at the forefront of everyone’s mind. Therefore, implementing security on one of these “legacy systems” could be a relevant opportunity for auditors in the future.
What I took away from the entire reading and this individual section was that documentation is a critical aspect of all IT Auditing. So, when the test and dev sites are updated, the corresponding documentation needs to reflects that. In addition, making sure the data on the site is clean and secure is a critical step in this process as well.
I agree with your takeaway. Documentation is crucial. It is important to have documentation that lists, in detail, any changes or updates to the testing and developing phases. I also believe that this documentation needs to be consistent and formatted accordingly.
This Chapter shows that ganizations align their risk management roles with complementary or similar roles
defined for the SDLC whenever possible, and consistent with missions and business functions.
RMF tasks are executed concurrently with, or as part of, the SDLC processes in the organization. Executing RMF tasks concurrently with SDLC processes helps to ensure that organizations are effectively integrating the process of managing information security and privacy risks into SDLC processes. Moreover, the expected outputs required by the RMF. RMF cannot individually work without SDLC. RMF tasks are closely aligned with the ongoing activities in the SDLC processes, ensuring the seamless integration of security and privacy protections into organizational systems—and taking maximum advantage of the artifacts generated by the SDLC process to produce the essential evidence in authorization packages to facilitate credible.
There is a thing of interest called “control gates” I took away from the NIST “Security Considerations in the SDLC”, pp.21-31. It introduced some general types of control gates for SDLC, which are the following:
• Architecture/Design Review: evaluates the planned system design, potential integration with other systems, incorporation of shared services and common security controls.
• System Performance Review: whether the system can deliver to the owner’s documented expectation; whether the system behaves in a predictable manner if it is subjected to improper use.
• System Functional Review: ensures identified functional requirements are sufficiently detailed and are testable.
• Mid-Project Status & Financial Review: ensure cost-benefit ratios are monitored and effective decisions are continued.
I think these controls gates are interesting, and I want to know the purpose of these control gates. From my research, a control gate may be viewed as a point in time to evaluate the system development effort, and management will use it to determine whether the project should continue, change direction or be discontinued.
The reading about control gates caught my eyes as well. Control gates are technically always in use but o because of how well they are integrated into the system, we don’t necessarily pay it any mind but it is essential to evaluate the status of the project.
Hi, thank you for providing more information about control gate that a control gate may be viewed as a point in time to evaluate the system development effort, and management will use it to determine whether the project should continue, change direction or be discontinued.
From NIST’s “Security Considerations in SDLC”, it focuses primarily on the security considerations of the development/acquisition phase.
Key security activities they address are conducting risk assessments, analyzing security requirements, perform functional and security testing, preparing initial documents for system certification/accreditation, and design the security architecture. The security analysis has to be iterated until every activity achieves consistency and completeness.
Control gates are also implemented in this phase of the SDLC.
An Architecture/Design Review
A system Performance Review
A system Functional Review
Mid-Project Status & Financial Review
A Follow-on review of risk management decisions
These security activities implemented are interesting to me because I can see a pattern being applied for different phases as well, and there’s such a heavy emphasis on not just the overall development but the continuous risk maintenance afterward.
Hi Mei,
we have found a similar interesting point from this chapter is that the document is very related to risk security evaluation, which is very important to security consideration in SDLC. The application of security control tailoring guidance to adjust the initial security control baseline; and the supplementation of the tailored baseline with additional controls based on an assessment of risk and local conditions.
To me, the most interesting part of project management and the development of life cycle processes was always risk management. More specifically, the testing is always interesting to me. I like to think of it as playing chess against yourself. I am trying to breach myself, while also trying to keep myself from being breached. When I was an Intern at Morgan, Lewis, & Bockius LLP, I would always catch the phishing emails sent out by the IT team. Any discussion on security and risk assessment is always interesting to me because these concepts and principles could be applied to any area of business
Hi, Panayiotis:
Testing is definitely a critical element of the development of the life cycle, and it is very interesting that you mentioned you catch phishing emails from the IT team. I assume that is a part of employee security awareness training. I am curious to know what happened if employees fail the phishing email testing?
Great comments. I think employees should be aware of many kinds of phishing emails. Also, discussion about security and risk assessment between employees can help increase employees’ security awareness.
Nice comment- I like that you can relate the reading to a real-life experience, and of course I find it interesting because I’ve been in that field for 6 years. Not only is it important to train staff on these matters, but it’s also important to review these practices with experts and clients, or any other outside person that the company has regular contact with. For the firm I work for, no sensitive information is ever communicated via email, however, much larger firms sometimes can’t avoid this due to distance between parties. I think a lot of the time, people who don’t work within the IT department just think that they’re covered in terms of IS protection, but in reality, this makes them an easy target for malicious activity.
It addresses security considerations unique to the SDLC phase, Development/Acquisition. One key security activity is design security architecture. It is to plan the key security services and understand how they will be integrated into the system. At the system level, security should be architected and then engineered into the design of the system. Security designing at the system level should take into consideration services obtained externally, planned system interconnections and the different orientations of system users. It is able to can provide effective compensating controls when there are issues with implementing minimal security requirements and identify common controls that the system will inherit as well as who has responsibility for those common controls.
Design security is an indispensable part of SDLC phases. Security Architecture is one component of a products/systems overall architecture and is developed to provide guidance during the design of the product/system. Also. A security model outlines the requirements necessary to properly support and implement a certain security policy.
During the development/acquisition stage of the SDLC, proper documentation regarding security activities is imperative due to anticipated changes during system development. When the risk assessment is performed during this phase, we are better able to identify what specific controls are necessary depending on the nature of the components within the system. Proper documentation may aid in avoiding pitfalls during testing, which will then allow us to move forward rather than taking two steps back and reassessing the issue. We can kind of relate this to the role communication plays in project planning- everything needs to be documented so to ensure that the necessities are covered, while also considering any type of residual effects that may arise in the process.
The section concerning the authorization of an information system was interesting to read. Authorizing the information system is a significant element of the SDLC phase implementation/ assessment. Authorization or security accreditation involves the acceptance and management of risk. That is, the risk to agency operations and agency assets. When making the final decision, the authorizing officials must weigh the necessary factors (completed system security plan, security test and evaluation results, POA&M) and decide to accept or reject the risk prior to placing the system into operation. When accrediting an information system, it is also important to consider the agency’s mission and operational responsibilities because the information system must deliver a high degree of functionality and adequate security so as not to place the agency’s missions at unacceptable levels of risk.
POA&M: The Plan of Actions & Milestones describes the current disposition of any discovered vulnerabilities and system findings.
Feng Gao says
This section of the document addresses the issues of security considerations that are entirely unique to the SDLC. Among the various key security activities is risks assessment or assessing risks to system. The purpose of risk assessment is to evaluate current knowledge of the system’s design. It includes the stated requirements, and even the least security requirements attained from the security categorization process used to determine the effectiveness of the risk assessment strategies used to avoid the projected risks. For risk assessment strategies to be successful, the must be formulated, implemented and monitored by people with adequate knowledge in the disciplines within the risks assessment system domain such as operations experts and technology experts.
Security risk assessment measures should be implemented design specifications are approved to facilitate additional specifications and provide room for further improvement and justification of the design specifications. However, apart from applying the risk assessment measures, organizations must evaluate how the measures will affect their organizations lest they yield more risks. Hence enterprise reviews are important to provide more clear understanding of the risks, threats and vulnerabilities that seek to be controlled. A refined risk assessment is expected to be a mature system design that reflects on the potential risks of a system, knows the actual weaknesses of a design, the contracts of a project and controls them, based on the present information and the goals of the organization.
Zhu Li says
A security risk assessment identifies, assesses, and implements key security controls in applications. It also focuses on preventing application security defects and vulnerabilities.
Carrying out a risk assessment allows an organization to view the application portfolio holistically—from an attacker’s perspective. It supports managers in making informed resource allocation, tooling, and security control implementation decisions. Thus, conducting an assessment is an integral part of an organization’s risk management process.
Xinye Yang says
I’d like to give my opinion on 3.2.3.3 “Design Security Architecture”
When it comes to the enterprise security or server system, thoughtful integration and environmental design should support safety. As the need for information services increases, it is becoming more important to plan these services and understand how they will be integrated into the system. The description addresses
“EA should be reviewed for optimal integration.” However, I think it also should be planned ahead, because you need to keep revisiting it. Keeping security discreet and strong is something more architects and architects should make a priority.
system auditing strategy that should be developed to enable an accurate trace or reconstruction of all priority and high-risk work flows. To develop system auditing strategy, the NIST or other guidelines and control frameworks should apply for it. Each control framework typically has a big amount of controls that are meant to assist audit, anything from user passwords to data storage or physical controls.
Imran Jordan Kharabsheh says
As I was reading through the NIST 800-64 publication, which revolved around “Security Considerations in the Software Development Life Cycle”, I took a particular interest in the section focusing on how and why testing is conducted. While I had initially known that testing was meant to be performed on the developmental, functional and security aspects of a given project as it makes its way through the software development life cycle, I did find more detailed information through the reading on what we look for during testing on each of these aspects. What we look for, in order to ensure that testing is thorough and ensures both functional and security requirement compliance, is specificity, repeatability, and iteration. Specificity entails that scoped testing is performed to ensure relevant security requirements function in an appropriate environment as intended. Repeatability involves repeated functionality testing yielding the same or similar results every time. Iteration requires that testing segments of or whole processes produce satisfactory results in regards to functionality requirements of the system. One more thing that I was surprised to learn about while reading through this section was how important automation can be in certain parts of the testing process, as it is helps perform tests that need to be repeated in order to replicate the same circumstances every time.
Alexander Reichart-Anderson says
Hello Imran, I like how you chose to focus on the “testing” aspect of the security considerations in the software development life cycle. Testing, as we’ve learned this year, is a critical aspect to insuring the functionality, capability, and limits of a new software. The repeatability of testing that you touched upon does sound like the theory of “insanity”. I feel that when testing a software’s security specifications, we must have a level of insanity to ensure that the users, their data, and the overall CIA of the system will be protected. Nice response!
Shuyue Ding says
In IT service delivery & support course, reviewing documentation and internal policy are mentioned repetitively. It is interesting here in “security considerations in the SDLC” mentioned several general types of control gates for the development phase which are all about reviewing. Those control gates are: Architecture/Design Review which including planned system design, potential integration with other systems, and incorporation of shares services and common security control; System performance review which evaluated the capability of delivering. System functional review is about reviewing the functional requirements and ensure they are detailed enough and testable, Mid-project status &financial review is really about ensuring is it still worth it regarding the effectiveness. Follow-on review of risk management decisions if the system/security controls/requirements change. Those control gates are interesting to know, and I would like to know more about how they are going to do reviewing and what metric are. I assume that goes back to the company’s internal policy and metric documents.
Imran Jordan Kharabsheh says
Hello,
As I read through your thoughts from the NIST reading on the “Security Considerations in the SDLC”, I found that you covered a lot of ground regarding control gates commonly found in the development phase in your response. A predominately featured type of control you mentioned frequently in your response was reviews, including financial reviews and regular design and performance reviews in order to ensure functionality and requirement compliance. I, too, would also be more interested in learning about some of the metrics used in some of the more specialized types of reviews for various types of projects.
Ryu Takatsuki says
The point that I want to talk about in this article is Develop Security Documentation. This article’s main idea is to assist agencies in building security into their IT development processes. For the part that we should read is how to incorporate security into SDLC in different phases. Authors mentioned that in developing security documentation the most prominent document is the System Security Plan. In the plan, it could include a configuration management plan, contingency plan, security awareness, training and education (SATE) plan, and other plans. The main purpose of these plans is to consider the security within the SDLC. Moreover, there are some tips for implementation. The security operations should not be driven by documentation of compliance but based on system need and described in compliance with security guidelines.
Feng Gao says
I like your points. System Security Plan is important. In NIST SP 800-18, the purpose of the system security plan is to provide an overview of the security requirements of the system and describe the controls in place or planned for meeting those requirements. The system security plan also delineates responsibilities and expected behavior of all individuals who access the system. The system security plan should be viewed as documentation of the structured process of planning adequate, cost-effective security protection for a system.
Zhu Li says
Design security architecture is an enterprise alignment of the system to ensure the initiative fits the prospects of agencies and does not conflict or unnecessarily provide redundant services. Also, as the system matures and more decisions are made as to services utilized. Security designing consider services obtained externally, planned system interconnections, and the different orientations of system users. Security architecting can provide effective compensating controls when there are issues with implementing minimal security requirements with the system’s design specification and identify common controls that the system will inherit as well as who has responsibility for those common controls. For example, system auditing strategy developed to enable an accurate trace or reconstruction of all priority and high –risk workflows. The auditing strategy includes various audit records from several different components including the Web application, databases, mainframe, and Web services. The purpose should provide enough information to investigate potential security breaches and system failures, not be captured as much audit information as possible.
Deepa Kuppuswamy says
Hi Zhu,
You drove to a good discussion point about compensating controls. When performing risk assessment and its associated control testing, most organization tend to take compensating controls for granted. Compliance is always a concern for every organization that handles customers’ data. Unfortunately, it’s not always easy for companies to meet the security requirements of frameworks like HIPAA, PCI DSS, SOX etc., In the event an organization can’t satisfy the requirement for a protective measure, it adopts another mechanism that offers a similar level of security as the original standard. That’s where compensating controls come in. Some organizations think of compensating controls as shortcuts by which they can achieve compliance with little effort and little money spent that is completely wrong.
Compensating controls are useful when it comes to compliance. But they’re impermanent fixes that organizations should replace with the original control as soon as possible. Companies should never use them as shortcuts to achieve compliance.
Yuchong Wang says
This document focus on SDLC Phase: Development and Acquisition. What I found interesting is the section about Select and Document Security Controls. It reminds me of the planning phase of an information system project that we have discussed. The 4 phases include project initiation, planning, executing, closing. The selection of security controls consists of three activities: the selection of baseline security controls (including common security controls); the application of security control tailoring guidance to adjust the initial security control baseline; and the supplementation of the tailored baseline with additional controls based on an assessment of risk and local conditions.
So basically, agencies should go over the risk framework and evaluate risk carefully. More detailed “attack prevention” requirements will also help to ensure that security controls and methods are tested prior to release. Security controls are not one-dimensional and should be addressed as appropriate on multiple components throughout the system. Depending on the system, the assessment may need to be planned for all, some or none.
Yuan Liu says
The purpose of the Select Step is to identify, select, tailor, and document the security and privacy controls necessary to protect the system and the organization commensurate with the risk to organizational operations and assets, individuals, other organizations, and the Nation.
Deepa Kuppuswamy says
NIST 800-64 publication focusses on incorporating security in each phase of SDLC from Initiation, Development, Implementation, Maintenance and Disposal phase. Reading assignment in PP 21-31 includes the second and third phase of SDLC which is security considerations in the development/acquisition phase and implementation/assessment phase. The security activity which interested me the most is Risk Assessment (3.2.3.1) to the system. I believe risk assessment process is an important task which decides the project success and it is the key component in SDLC. It contributes to the project success by establishing a list of internal and external risks. This assessment typically includes the identified risks, probability of occurrence, potential impact and proposed actions. Effective risk assessment strategies allow us to identify project’s strengths, weaknesses, opportunities and threats and thereby helps us to plan for the unexpected events.
Yuqing Tang says
Hi, I totally agree with your ideas of the important role of risk assessment. Many projects face some uncertainty in determining requirements. Ignoring these uncertainties early in the project and not addressing them as the project progresses can pose a significant threat to the project’s success. For the whole SDLC process, once the risks are not identified and solved in the earlier phase, it could affect the following phases.
Raisa Ahmed says
Well said, Deepa. Risk is unavoidable when it comes to information systems. The threat of being breached has significantly increased. As a result, it is important that organizations take measures to prevent breaches and mitigate the damage if/when they do occur. The first place to start is with a risk assessment. Organizations that conduct risk assessments are better able to understand where their strengths and weaknesses lie when it comes to ensuring their data.
Yuqing Tang says
The assigned part in the NIST Special Publication 800-64 Security Considerations in the System Development Life Cycle describe the security consideration under SDLC Development/Acquisition and Implementation / Assessment phases. The question to be answered during the system design phase is how to achieve goals. The task of this phase is to design and implement the technical scheme of logic model according to the functional requirements specified in the system specification and considering the actual conditions. At the development stage, the security objectives of the system are determined through risk assessment, and this is also the phase which perform the most risk assessment. The system implementation phase is the stage to put the designed system into practice. The tasks of this stage include the purchase, installation and debugging of computers and other equipment, the preparation and debugging of programs, personnel training, data file conversion, system debugging and conversion. The assessment phase determines whether the system’s security objectives are met through risk assessment.
Ryu Takatsuki says
Hi Yuqing, I agree with your idea that the risk assessment is critical in the development stage. For an organization, risk assessment is a process to identify potential hazards and analyze what could happen if a hazard occurs. Moreover, if a potential risk is identified, a solution or plan of action should be developed.
Alexander Reichart-Anderson says
In the NIST Special Publication 800-64 Revision 2, I took special interest in section 3.3.3.2 Integrate Security into Established Environments or Systems. This was particularly interesting because it focused on an issue very relevant to the Information Systems sphere of today — adding the security aspect to an existing legacy system. As we learned from last weeks class on “criteria for grading an information system” — security was not always at the forefront of everyone’s mind. Therefore, implementing security on one of these “legacy systems” could be a relevant opportunity for auditors in the future.
What I took away from the entire reading and this individual section was that documentation is a critical aspect of all IT Auditing. So, when the test and dev sites are updated, the corresponding documentation needs to reflects that. In addition, making sure the data on the site is clean and secure is a critical step in this process as well.
Panayiotis Laskaridis says
Hi Alex,
I agree with your takeaway. Documentation is crucial. It is important to have documentation that lists, in detail, any changes or updates to the testing and developing phases. I also believe that this documentation needs to be consistent and formatted accordingly.
Yuan Liu says
This Chapter shows that ganizations align their risk management roles with complementary or similar roles
defined for the SDLC whenever possible, and consistent with missions and business functions.
RMF tasks are executed concurrently with, or as part of, the SDLC processes in the organization. Executing RMF tasks concurrently with SDLC processes helps to ensure that organizations are effectively integrating the process of managing information security and privacy risks into SDLC processes. Moreover, the expected outputs required by the RMF. RMF cannot individually work without SDLC. RMF tasks are closely aligned with the ongoing activities in the SDLC processes, ensuring the seamless integration of security and privacy protections into organizational systems—and taking maximum advantage of the artifacts generated by the SDLC process to produce the essential evidence in authorization packages to facilitate credible.
Penghui Ai says
There is a thing of interest called “control gates” I took away from the NIST “Security Considerations in the SDLC”, pp.21-31. It introduced some general types of control gates for SDLC, which are the following:
• Architecture/Design Review: evaluates the planned system design, potential integration with other systems, incorporation of shared services and common security controls.
• System Performance Review: whether the system can deliver to the owner’s documented expectation; whether the system behaves in a predictable manner if it is subjected to improper use.
• System Functional Review: ensures identified functional requirements are sufficiently detailed and are testable.
• Mid-Project Status & Financial Review: ensure cost-benefit ratios are monitored and effective decisions are continued.
I think these controls gates are interesting, and I want to know the purpose of these control gates. From my research, a control gate may be viewed as a point in time to evaluate the system development effort, and management will use it to determine whether the project should continue, change direction or be discontinued.
Mei X Wang says
Hi Penghui,
The reading about control gates caught my eyes as well. Control gates are technically always in use but o because of how well they are integrated into the system, we don’t necessarily pay it any mind but it is essential to evaluate the status of the project.
Haixin Sun says
Hi, thank you for providing more information about control gate that a control gate may be viewed as a point in time to evaluate the system development effort, and management will use it to determine whether the project should continue, change direction or be discontinued.
Mei X Wang says
From NIST’s “Security Considerations in SDLC”, it focuses primarily on the security considerations of the development/acquisition phase.
Key security activities they address are conducting risk assessments, analyzing security requirements, perform functional and security testing, preparing initial documents for system certification/accreditation, and design the security architecture. The security analysis has to be iterated until every activity achieves consistency and completeness.
Control gates are also implemented in this phase of the SDLC.
An Architecture/Design Review
A system Performance Review
A system Functional Review
Mid-Project Status & Financial Review
A Follow-on review of risk management decisions
These security activities implemented are interesting to me because I can see a pattern being applied for different phases as well, and there’s such a heavy emphasis on not just the overall development but the continuous risk maintenance afterward.
Yuchong Wang says
Hi Mei,
we have found a similar interesting point from this chapter is that the document is very related to risk security evaluation, which is very important to security consideration in SDLC. The application of security control tailoring guidance to adjust the initial security control baseline; and the supplementation of the tailored baseline with additional controls based on an assessment of risk and local conditions.
Panayiotis Laskaridis says
To me, the most interesting part of project management and the development of life cycle processes was always risk management. More specifically, the testing is always interesting to me. I like to think of it as playing chess against yourself. I am trying to breach myself, while also trying to keep myself from being breached. When I was an Intern at Morgan, Lewis, & Bockius LLP, I would always catch the phishing emails sent out by the IT team. Any discussion on security and risk assessment is always interesting to me because these concepts and principles could be applied to any area of business
Shuyue Ding says
Hi, Panayiotis:
Testing is definitely a critical element of the development of the life cycle, and it is very interesting that you mentioned you catch phishing emails from the IT team. I assume that is a part of employee security awareness training. I am curious to know what happened if employees fail the phishing email testing?
Penghui Ai says
Hi Panayiotis,
Great comments. I think employees should be aware of many kinds of phishing emails. Also, discussion about security and risk assessment between employees can help increase employees’ security awareness.
Sarah Puffen says
Nice comment- I like that you can relate the reading to a real-life experience, and of course I find it interesting because I’ve been in that field for 6 years. Not only is it important to train staff on these matters, but it’s also important to review these practices with experts and clients, or any other outside person that the company has regular contact with. For the firm I work for, no sensitive information is ever communicated via email, however, much larger firms sometimes can’t avoid this due to distance between parties. I think a lot of the time, people who don’t work within the IT department just think that they’re covered in terms of IS protection, but in reality, this makes them an easy target for malicious activity.
Haixin Sun says
It addresses security considerations unique to the SDLC phase, Development/Acquisition. One key security activity is design security architecture. It is to plan the key security services and understand how they will be integrated into the system. At the system level, security should be architected and then engineered into the design of the system. Security designing at the system level should take into consideration services obtained externally, planned system interconnections and the different orientations of system users. It is able to can provide effective compensating controls when there are issues with implementing minimal security requirements and identify common controls that the system will inherit as well as who has responsibility for those common controls.
Xinye Yang says
Hey Haixin
Design security is an indispensable part of SDLC phases. Security Architecture is one component of a products/systems overall architecture and is developed to provide guidance during the design of the product/system. Also. A security model outlines the requirements necessary to properly support and implement a certain security policy.
Sarah Puffen says
During the development/acquisition stage of the SDLC, proper documentation regarding security activities is imperative due to anticipated changes during system development. When the risk assessment is performed during this phase, we are better able to identify what specific controls are necessary depending on the nature of the components within the system. Proper documentation may aid in avoiding pitfalls during testing, which will then allow us to move forward rather than taking two steps back and reassessing the issue. We can kind of relate this to the role communication plays in project planning- everything needs to be documented so to ensure that the necessities are covered, while also considering any type of residual effects that may arise in the process.
Raisa Ahmed says
3.3.3.4 Authorize the Information System
The section concerning the authorization of an information system was interesting to read. Authorizing the information system is a significant element of the SDLC phase implementation/ assessment. Authorization or security accreditation involves the acceptance and management of risk. That is, the risk to agency operations and agency assets. When making the final decision, the authorizing officials must weigh the necessary factors (completed system security plan, security test and evaluation results, POA&M) and decide to accept or reject the risk prior to placing the system into operation. When accrediting an information system, it is also important to consider the agency’s mission and operational responsibilities because the information system must deliver a high degree of functionality and adequate security so as not to place the agency’s missions at unacceptable levels of risk.
POA&M: The Plan of Actions & Milestones describes the current disposition of any discovered vulnerabilities and system findings.