Reply needed 1 Sustaining quality and security in the code is achieved by practicing secure coding standards.

Reply needed 1 Sustaining quality and security in the code is achieved by practicing secure coding standards. Secure coding standards are practices that are implemented to prevent the introduction of security vulnerabilities, like logic laws and viruses. Businesses can drastically reduce their exposure to code vulnerabilities by following these coding standards. According to Whitehatsec, the top secure code standards are:

•Develop a secure coding standard for a platform and development language.

•Validate input from all external data sources including user -controlled files, network interfaces, and command line arguments.

•Deny access by default. Software should identify conditions when access is permitted rather than by exclusion.

•Design software to enforce and implement security policies.

•Use the compiler’s highest warning level to compile your code. Eliminate warning by modifying the code.

•Have a layered defense with multiple strategies. If one does not prevent a vulnerability, the next layer of defense should.

 These coding standards provide protection throughout the entire life cycle of the code. The code protected in its beginning stages because the programmer consults the compiler’s highest warning level when creating the code.  After the code has been implemented, it is protected because all input from external data sources is validated. This prevents any potential attacks or unauthorized editing of the code. In conclusion, following secure coding standards will ensure that the code is high quality and secure.

 References

Whitehatsec, Secure Coding Standards. (n.d.). Retrieved October 15, 2020, from https://www.whitehatsec.com/glossary/content/secure-coding-standards

Reply 2 Needed: For this discussion, I will be examining the act of “identifying new threats” and explain how to perform it.  As we have already learned, the term “threat” is different from “vulnerability” and “risk.” Threats derive from a particular source and exploit a system’s weaknesses or vulnerabilities.  Vulnerabilities can trigger a threat-event without motive (user error, equipment failure, natural disaster, etc.), or they can be intentionally targeted by a malicious actor (Stoneburner, Goguen, & Feringa, 2002).  Even if a threat exists, they do not present a risk unless a vulnerability can be acted upon (Stoneburner et al., 2002).  When determining the likelihood of a threat, the threat-source, vulnerability, and the existing security controls must be considered collectively (Stoneburner et al., 2002).

 The NIST SP 800-30 defines a threat-source as any event or circumstance that can potentially harm an IT system.  Threats can be classified in four different categories: adversarial, accidental, structural, or environmental (Stoneburner et al., 2002).  To effectively determine the threats to a system, an organization should first identify the most critical assets of an organization and predict what threat-events or threat-sources could impact the system (Stoneburner et al., 2002).  To best assess the critical assets of an organization, first there needs to be ample inventory of system-related information.  This includes, but isn’t limited to, hardware, software and operating systems, system interfaces and connectivity specifications, data and information stored within hardware, and system users and permissions.  Organizations can collect this information through information gathering techniques such as interviews, sampling, or document analysis (Stonebruner et al., 2002). 

If an organization is new to threat identification, NIST SP 800-30 Table D-2 includes a list of common threat-sources, their description, and characteristics.  This table is a great place to start to see what threats may apply to a system.  Further threat identification relies on specific knowledge of the information systems being used, the potential adversaries, and other information such as natural disaster threats in their geographic location.  System analysts must do their research on these topics as well as determining what safeguards are in place in their facility to successfully achieve a full-scope threat identification. 

References:

Stoneburner, G., Goguen, A., Feringa, A. (2002). Risk Management Guide for Information Technology Systems. NIST Special Publication 800-30. [PDF file]. Retrieved from https://www.ucop.edu/information-technology-services/initiatives/resources-and-tools/sp800-30.pdf

Reply 3 Needed Software maintenance and sustainment requires a formally defined process to prevent unrepaired vulnerabilities and to ensure newly established security requirements. While both maintenance and sustainment are typically used interchangeably, there is a distinction worth noting. Definitions of the two terms from Mary Ann Lapham begin to clarify things:

· Software Maintenance – “The process of modifying software system or component after delivery to correct faults, improve performance, or other attributes, or adapt to a changed environment”

· Software Sustainment – “The processes, procedures, people, material, and information required to support, maintain, and operate the software aspects of a system” (2006).

Based on these definitions, maintenance focuses more on the change initiatives associated with the software, such as providing patches for bugs or releasing new features by version, while sustainment addresses more than just maintenance related issues including the managerial and support aspects of the software. Therefore, there is a clear distinction between the two processes, although both are equally important when trying to achieve greater software assurance.

Once the software has been deployed in a production environment, software sustainment commences helping ensure the system is functioning as intended. The intentions are often unique to each organization but, in general, the software is designed with a particular purpose in mind. While meeting functional requirements is one area of importance, satisfying all security requirements is another that is very likely to be unique to each environment it is deployed in. With most organizations operating in extremely dynamic environments, it is difficult to account for software vendors to keep up with the constant changes. Therefore, as part of the secure software sustainment activities must be conducted regularly. One such activity is conducting an impact analysis of new threats to assess the level of risk vulnerabilities might produce. As changes occur, evaluations must be conducted on all software, software-intensive systems, policies, processes, or objectives that could be impacted by the change (DHS, 2007). To help support change it is advised to include impact analysis as part of the evaluation to help estimate the potential impact it could have. The DHS recommends, “perform impact analysis on affected interfaces and, from that, design a specific response strategy for each interface using good development practices” (2007). Impact analysis provides the details to determine the best course of action when change takes place, as there is no one response that will fit every situation.

Furthermore, impact analysis should include a formal methodology for delivering a specific remediation strategy. In defining how impact analysis will be performed, it is a good idea to include such evaluations throughout the entire software development life cycle. To perform a successful implementation or development it requires an analysis of risk at each phase, and to continue analysis after project completion. Research promotes analysis throughout the SDLC because it is easier to mitigate or avoid risk when conducting root cause analysis across the entirety of the project (Bhujang & V., 2014). As impact analysis begins, one should first obtain the following information:

· System mission

· System and data criticality

· System and data sensitivity (Stoneburner et al., 2002).

This information should be easily obtainable assuming proper documentation has been created by the organization. After this, there are various techniques one can apply to conduct impact analysis. In general, the following steps should be followed:

1. Identify the scope of analysis in which artifacts could be impacted by the change,

2. Identify relationships that could be dependent upon affected artifacts,

3. Include any uncovered relationships of the dependent artifacts in the scope of analysis, and

4. Continue the process to produce a complete analysis beginning with the selected artifacts and finishing with artifacts that have no other dependencies (Ward, 2017).

Finally, one should conduct either static or dynamic analysis, or a combination of both, to fully estimate the impact of risk making a change in the software could have. Various tools exist for static and dynamic analysis, which can be identified to fit the impact evaluation needs of the organization. Despite the various tools that exist, there appears no clear standard in the industry for performing impact analysis.

References

Bhujang, R. K., & V., S. (2014, August). Risk impact analysis across the phases of software development. Lecture Notes on Software Engineering, 2, (3). http://www.lnse.org/papers/137-E2001.pdf.

Department of Homeland Security. (2007, October). Software assurance: A curriculum guide to the common body of knowledge to produce, acquire, and sustain secure software. https://learn.umgc.edu/content/enforced/515613-022073-01-2208-GO1-9040/Common_Body_of_Knowledge2007.pdf?_&d2lSessionVal=yHNXTIp6y56ZPEX8jKq29unVQ&ou=313879&_&d2lSessionVal=u14iDQ9ERIh9FV4qCy22z6WrC&ou=515613.

Stoneburner, G., Goguen, A., & Feringa, A. (2002, July). Risk management guide for information technology systems. National Institute of Standards and Technology. https://www.hhs.gov/sites/default/files/ocr/privacy/hipaa/administrative/securityrule/nist800-30.pdf.

Ward, M. (2017). Change impact analysis. Software Technology Research Lab, De Montfort University. http://www.gkc.org.uk/msc-se-2017/03-change-impact-analysis.pdf.