Checklist For Security Functions in Application Development SDLC Frameworks For Cloud Computing
In this article, I share the type of security functions that should exist with a Secure Software Development Life Cycle (SSDLC) process in any organization that is developing and deploying applications in the cloud.
If you are an application developer or security professional, use this article as a checklist to make sure the correct security functions are part of each phase of your SDLC process.
While there are a variety of different SSDLC Frameworks, the phases can be generalized as follows:
Training -> Define -> Design -> Develop -> Test
I recently wrote an article about SSDLC Frameworks and why they matter that you may want to review.
SECURITY FUNCTIONS IN SDLC FRAMEWORKS
TRAINING PHASE
The development and security teams need training and experience in the following key areas:
- Secure Coding Practices
- Security Testing
- Technical Training on the Cloud Service Provider (CSP) Platform & Services
There is a high correlation with quality security training and the reduction of security errors that people make, so don’t overlook this opportunity to improving your security posture.
Security professionals are well served by earning vendor agnostic cloud security certifications like the CCSK, CCSP, and CCAK as the foundation and then layering in provider specific training from provides like AWS, Microsoft, Google and others based on the environments deployed and roles within the team.
Get My Free Cloud Security Journal
DEFINITIONS PHASE
In the definitions phase, you can expect to be writing coding standards and security functional requirements.
You can expect to address things like how you the organization is handling authentication to cloud. How will you be avoiding the use of static credentials in code to the cloud service provider when making API calls?
You will want to set these requirements and standards ahead of time so the application developers understand how to implement these important elements at an application code level.
For example, if you require privileged accounts to have two-factor authentication, what is the standard for implementing this? The concepts will be very similar, but the specifics will vary by cloud service provider and this is why creating standards is so important.
DESIGN PHASE
In the design phase, this is where you start to focus on threat modeling, mis-use case development, and secure design principles.
Depending on your cloud service provider, you will most likely be integrating some of their services to improve your application security posture.
Most organizations are opting to push more of the attack surface onto the cloud service provider by leveraging the shared responsibilities model. If you can leverage a security service in the providers PaaS deployment model for example, then this may be a good fit for your organization based on available resources.
Pushing the attack surface to the CSP is increasingly common because the cloud service providers are typically going to have more resources and possess more capabilities versus your organization trying to dedicate internal resources in addition to taking on patching and configuration hardening responsibilities.
DEVELOP PHASE
In the develop phase, you will see integration with DevOps. This includes code review, unit testing, static analysis, dynamic analysis.
Depending on the deployment model and cloud service provider, the kinds of testing will need to be reviewed and negotiated. The CSP’s terms of service may not allow penetration testing for example.
External scanning is an area that cloud service providers normally disallow, so be sure to think about how you will be able to accomplish similar objectives. This is why we are seeing savvy organizations implementing security functions within the CI/CD pipeline.
TESTING PHASE
In the testing phase, you will normally perform vulnerability assessments, dynamic analysis, functional tests, and QA.
Based on the provider, their terms of service, and your deployment model, all of this will likely impact your testing phase significantly.
For example, running a vulnerability assessment against a serverless application isn’t going to work as it would in a traditional IT environment.
The point to remember is that testing still needs to occur, but how testing is performed and executed in the cloud environment and specifically with your cloud service provider will need to be considered and designed ahead of time.
I hope this article has helped you think about the role of security within cloud-based SDLC processes in your organizastion.
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)
