How Cloud Computing Has Changed Application Security & What You Can Do About It
The public cloud computing model and services has completely changed how we secure our systems and applications. There are several benefits as well as some new challenges.
I will be covering 7 benefits that can be realized by most organizations as well as 4 new security challenges that if not addressed will lead to undesirable outcomes and unnecessary cyber incidents.
First, I will list the 7 positive benefits that are generally associated with cloud computing with large cloud service providers like AWS, Microsoft Azure, and Google:
- Baseline Security From CSP Provides Higher Level Security Posture
- Agility and Improved Application Responsiveness
- Segregation by Default (Isolated Environments)
- Independent VMs & Auto-Scaling for Microservices
- DevOps for application deployment
- Better Elasticity
- Single Pane of Glass For Viewing/Managing Applications
Four new security challenges that are generally associated with public cloud computing platforms (i.e., AWS, Azure, Google) include:
- Limited Visibility (network traffic monitoring/capturing is limited)
- Increased Scope of Application (now have management plane)
- New Threat Models & Attack Surfaces (e.g., stored credentials, management plane, etc.)
- Reduced Transparency (forced to trust and rely on CSP)
Most organizations can realize an overall improvement in their security posture for applications deployed with major cloud service provider platforms (e.g., AWS, Azure, Google) so long as their approach and practices for security are adjusted to align to the new cloud computing model.
Get My Free Cloud Security Journal
In the section below, I will suggest three focus areas that every organization should be reviewing and considering when developing and deploying applications and data with public cloud service providers.
These processes and controls may seem basic, but I can assure you that many organizations that are actively developing and deploying new applications and systems into the public cloud are not following these very basic guidelines.
I suggest using the items listed below as a checklist to ensure your team and organization is at least following the basic guidelines.
1 — Secure Design & Application Development
In the design and development phase of new applications and systems, we want to make sure the following actions and controls are fully and consistently implemented:
- Continuous cloud security training for developers and security professionals (e.g., CCSK, CCSP, AZ-900, AZ-500, etc.)
- Use a SSDLC (secure software development lifecycle)
- Pre-deployment testing for all applications and systems
- Threat modeling and mis-use case exercises
2 — Security Application Deployment
Securely deploying code and applications in public or hybrid cloud environments is new for many organizations and these controls are often overlooked or not adequately implemented as part of the standard baseline.
- Code Review
- Testing (static & dynamic analysis)
- Vulnerability Assessments
- Use a Secure DevOps Process (Secure CI/CD Pipeline)
- Compliance & Governance Checking
3 — Secure Operations
Once the application is in production, ensuring the application is resilient and secure is a key and critical aspect of the overall security plan.
- Implementing Relevant Security Controls (web app firewalls (WAF), proactive application defenses, etc.)
- Continuous Threat Assessments & Monitoring
- Real-Time Activity Monitoring
These controls are not necessarily implemented in phases as listed above. These processes and techniques are designed, managed, and implemented as part of the design, build, and deployment phases associated with the SSDLC process.
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)
