Secure Software Development Life Cycle (SSDLC) Frameworks For Cloud Computing & Why It Matters
Security is one of the most important aspects of any application, and in the age of cloud computing, it is arguably the most important because an unplanned cybersecurity incident can be damaging and potentially devastating.
There are a few different Secure Software Development Life Cycle (SSDLC) Frameworks that you could adopt and use to help improve the security posture of your application development and deployment processes as well as the overall security posture of the organization.
I have ran into Microsoft’s SSDLC Framework the most, so I will cover it in this article along with some insights and resources that I think you will find helpful.
There are other frameworks from NIST and ISO/IEC which are good resources to help fill in any gaps and they are located in the resources section at the bottom of this article.
Get My Free Cloud Security Journal
CLOUD IMPACT ON SSDLC
Cloud computing inherently forces an organization to rely on the cloud service provider (CSP) and it is important to understand the relationship between SSDLC and cloud services and deployment models.
For example, when designing security controls in the cloud environment, an organization is forced to rely on and trust the cloud service provider (CSP) in ways that traditionally were handled in house by IT. This is why SLA’s must be fully understand and reviewed by all stakeholders (legal, compliance, IT, security, compliance, etc.). I wrote an SLA Checklist article that you may also find helpful.
Services and responsibilities are highly variable between providers and platforms, so do your homework and don’t assume anything.
Management plane and meta-structure are now within scope of application security. The management plane and megastructure are new to cloud-based application development and deployment. Relevant security controls will involve deep automation and services provided by CSP’s and possibly other partners. You will almost certainly have application components making API calls into the cloud to affect other application components and micro-services and how you secure these communications and deal with the new attack surface will be a key part of your application security strategy.
The management plane and megastructure are effectively part of the SSDLC and this is new for many developers and IT functions. IAM and internal controls available from the CSP is also in scope for application security in the cloud because these components are now an integral part of the overall application security controls.
IaaS internal controls provided by the CSP are new to cloud-based application developers. PaaS has significantly changed how applications are designed and deployed and understanding security responsibilities of all parties is not to be overlooked or assumed. IaaS and PaaS controls are now in scope for application security and this is new for many application developers coming from traditional datacenter environments.
Traditional LAMP stack web applications are typically not part of the new cloud architecture (i.e., IaaS, PaaS, FaaS, Microservices, etc.) and so a change in mindset as well as practices are required.
DevOps is the new path forward for cloud application development because it is highly tuned to management via APIs, broad network access, and infrastructure is being defined via code. Integrating DevOps to SSDLC and security to DevOps is critical in the new cloud era.
Application security, network security, and CI/CD pipeline security were not part of traditional SDLC frameworks, so be sure your organization has embraced these new technologies and has evolved into using an SSDLC as described in this article.
Get My Free Cloud Security Journal
MICROSOFT SOFTWARE SECURITY DEVELOPMENT LIFECYCLE (SSDLC)
Microsoft has pioneered SSDLC in many ways and I suggest you are familiar with their framework. I have found many organizations that are designing and deploying cloud-based applications use Microsoft’s SSDLC framework, so it is a good framework to know and understand. While Microsoft’s SSDLC is geared towards Azure, it absolutely still applies to all other public cloud service provider platforms. You can go to Microsoft’s Security Engineering page and review the SDLC information in detail.
Microsoft SSDLC Phases:
- Training
- Requirements
- Design
- Implementation
- Verification
- Release
- Response
Using an SSDLC will help your organization implement a formal application security program that assists you with security activities from start to finish during the development lifecycle.
It should go without saying, but it is critical to engage security and compliance teams before you begin developing your application. Developers have the opportunity to ask the security team at each phase of the SDL whether there are any tasks that may have been missed or overlooked. Building partnerships with peers is not only good for security, but a great way to build long-term relationships that provide dividends over the long term.
If your organization is not currently developing and deploying cloud-based applications using a formal SSDLC framework, this should be a red flag. As a developer or cybersecurity professional, this could be an opportunity for you to be a thought leader and subject matter expert in an area that is valuable to organizations in every industry.
SECURE BY DESIGN MINDSET
By operating and working in a “secure by design” mindset, you will significantly improve your organizations application and overall security posture.
Developers should consider security issues as part of the basic architectural design and software development process and if this not happening, then you could help them improve their security posture by being an advocate of SSDLC. This is an easy way for you to be seen as a valued team member that fills a knowledge gap within the organization.
By partnering with the security team, developers and security professionals have the opportunity to review threats and vulnerabilities that could could lead to damaging security incidents. By taking this approach, the team will be proactively improving the security posture of the application and collaborating to design and develop mitigations for identified threats.
Threat models and mis-use cases are created by the developers and security team and ultimately mitigations are developed early on in the design process by including these critical processes in your SSDLC.
Once you have the threat landscape and mis-use cases documented, the team can work together to mitigate vulnerabilities before threat actors have a chance to exploit them.
If your team and organization is not functioning in a “secure by design” mindset, use the information and the resources in this article to start a new cycle of positive change.
SSDLC RESOURCES
- OWASP Top 10 Proactive Controls
- Microsoft SSDLC Overview
- Microsoft SSDLC 5 Phases
- Microsoft SSDLC Tools & Resources Center
- NIST 800–160 Vol. 1
- NIST 800–37 Rev. 2
- ISO/IEC 27034
- LAMP Stack Overview
Tim Layton specializes in demystifying the complexities and technical jargon associated with cloud computing security and risk management for business stakeholders across the enterprise. Tim is a cloud security thought leader defining actionable and defensible strategies to help enterprise stakeholders make risk-based decisions and prioritize investments in the new digital frontier.
Stay Connected With Tim Layton
LinkedIn: www.Linkedin.com/in/TimLaytonCyber
Website: http://CloudSecurityLaunchPad.com
COMMON CYBERSECURITY RISK TERMS DEFINED
Threat: Any circumstance or event with the potential to adversely impact organizational operations (including mission, functions, image, or reputation), organizational assets, individuals, other organizations, or the Nation through an information system via unauthorized access, destruction, disclosure, or modification of information, and/or denial of service. (NIST 800–30)
Threat: potential cause of an unwanted incident, which can result in harm to a system or organization. (ISO 27001)
Vulnerability: Weakness in an information system, system security procedures, internal controls, or implementation that could be exploited by a threat source. (NIST 800–30)
Vulnerability: weakness of an asset or control that can be exploited by one or more threats. (ISO 27001)
Likelihood: A weighted factor based on a subjective analysis of the probability that a given threat is capable of exploiting a given vulnerability or a set of vulnerabilities. (NIST 800–30)
Likelihood: chance of something happening. (ISO 27001)
Risk: A measure of the extent to which an entity is threatened by a potential circumstance or event, and typically a function of (i) the adverse impacts that would arise if the circumstance or event occurs; and (ii) the likelihood of occurrence. (NIST 800–30)
Risk: effect of uncertainty on objectives. (ISO 27001)
Security Controls: The management, operational, and technical controls (i.e., safeguards or countermeasures) prescribed for an information system to protect the confidentiality, integrity, and availability of the system and its information. (NIST 800–30)
Compensating Security Control: A management, operational, and/or technical control (i.e., safeguard or countermeasure) employed by an organization in lieu of a recommended security control in the low, moderate, or high baselines that provides equivalent or comparable protection for an information system. (NIST 800–30)
Impact Level: The magnitude of harm that can be expected to result from the consequences of unauthorized disclosure of information, unauthorized modification of information, unauthorized destruction of information, or loss of information or information system availability. (NIST 800–30)
Residual Risk: Portion of risk remaining after security measures have been applied. (NIST 800–30)
Security Posture: The security status of an enterprise’s networks, information, and systems based on information assurance resources (e.g., people, hardware, software, policies) and capabilities in place to manage the defense of the enterprise and to react as the situation changes. (NIST 800–30)
