Modern cloud-native applications are more assembled than developed using a combination of VMs, containers and PaaS services, including serverless PaaS. These cloud-based applications and the delivery of their capabilities need protection from attacks.
As per Gartner, through 2025, more than 99% of cloud breaches will have a root cause of preventable misconfigurations or mistakes by end users. By taking explicit advantage of the built-in security capabilities and high levels of automation available from IaaS computing and network fabrics, enterprises can significantly reduce the chance of misconfiguration, mismanagement and mistakes. Doing so will reduce the surface area for attack and improve their overall cloud security posture. Cloud-based infrastructure and platform services can be more secure than those in the enterprise data center.
7 Cloud Application Security Best Practices
1. Overconcern About Data Location is Meaningless in Cloud Security
In order to implement the right controls, it is critical for the organization to understand its security responsibility based on the type of cloud deployment. The overconcern about data location is meaningless as data security responsibility is always owned by the organization, regardless of the type of cloud deployment, while the security responsibility of other components is variously shared depending on deployment type.
Organizations will need to implement security controls for data in the cloud, and those controls are likely different from those used on-premises, such as bring own encryption keys. By sharing some other security responsibilities with CSPs, organizations are able to focus on protecting their most core assets. However, this incorrect focus on the physical data location sacrifices the benefits of cloud computing. CSPs can be more secure than private cloud and traditional data centers simply because of economies of scale.
2. Identify the Extent of Security Responsibilities with Cloud
Most organizations’ overfocus on data location is because they have difficulties architecting and implementing cloud security, and most cloud security failures are due to customer misconfiguration. This is not only due to the disappearance of assets’ physical boundaries, but also because organizations don’t know how to implement security with CSPs. However, cloud security is based on the shared security responsibility concept and security responsibility varies depending on the type of cloud mode.
3. Establish Capabilities for Cloud Security
Cloud deployments vary depending on organizations’ needs. Cloud resources are characterized as shared concept, short-life cycle, automated and programmatic. Existing security expertise for protecting on-premises data centers is not applicable for securing all cloud resources. Organizations need to establish the required cloud security capabilities.
Cloud Security Architect
- Successful cloud security requires a cloud security architect role supported by the business, IT and security organization.
- To address the complexity of cloud security, IT organizations benefit from hiring or promoting a senior-level architect to oversee cloud security initiatives
Cloud Security Engineers
- Cloud security engineers are technical professionals with broad skills that extend beyond the domain of any particular security silo, such as network security, server security, vulnerability management, application security and data security.
To adapt quickly to your organization’s security needs, its highly advisable to engage Certified Cloud Security specialists. You can engage certified partners who have on board the requisite consultative and execution capabilities on Cloud security.
4. Establish a Cloud Security Architecture
Organizations with existing processes and tools need to update their security architecture to take into account new deployment models such as SaaS, PaaS and IaaS. Follow and apply security architectures defined as standards in the industry. Few of them can be:
- Sherwood Applied Business Security Architecture (SABSA)
- National Institute of Standards and Technology (NIST) Cybersecurity Framework
- Cybersecurity mesh architecture (CSMA)
5. Cloud Security Tool Group
Because of the shared cloud security responsibility and complexities in cloud offerings, customers require new groups of security tools to help them use the cloud securely. Cloud security vendors generally take a modular approach to provide services and consolidate capabilities into a portfolio.
Cloud Access Security Brokers (CASBs): CASBs provide crucial cloud governance controls for visibility, compliance, data security and threat protection by consolidating multiple types of security policy enforcement into one place for SaaS, IaaS and PaaS.
Examples: Authorization, user and entity behaviour analytics (UEBA), adaptive access control, data loss prevention (DLP), device profiling, object encryption, tokenization, logging, alerting and malware removal.
Cloud Workload Protection Platforms (CWPPs): CWPPs are workload-centric security offerings that protect server workloads in hybrid, multicloud data centers. CWPPs should provide consistent visibility and control for physical machines, virtual machines, containers and serverless workloads, regardless of location.
Use Case: CWPP offerings protect the workload using a combination of system integrity protection, application control, behavioural monitoring, intrusion prevention and optional anti-malware protection
Cloud Security Posture Management (CSPM): CSPM offerings continuously manage cloud security posture through prevention, detection, response and proactive identification of cloud infrastructure risk. The core of CSPM offerings applies common frameworks, regulatory requirements, and enterprise policies to discover and assess risk/trust of cloud service configuration and security settings proactively and reactively. If an issue is identified, remediation options (automated or human-driven) are provided.
Cloud-Native Application Protection Platforms (CNAAPs): CNAPP is an integrated set of security and compliance capabilities designed to help secure and protect cloud-native applications across development and production.
Use Case: CNAPP consolidates a large number of previously siloed capabilities, including container scanning, cloud security posture management, infrastructure as code scanning, cloud infrastructure entitlement management and runtime CWPPs.
Emerging Tools Such as SaaS Security Posture Management (SSPM): SaaS security posture management (SSPM) is a type of automated security tool for monitoring security risks in software-as-a-service (SaaS) applications. SSPM identifies misconfigurations, unnecessary user accounts, excessive user permissions, compliance risks, and other cloud security issues.
Cloud security posture management (CSPM) can bring broader visibility to cloud infrastructure and assets, help ensure consistent configuration management and establish a baseline of best practices for compliance mandates.
SaaS Management Platforms (SMPS): SaaS Management Platforms (SMP) enable SaaS Application daily operations including identifying SaaS applications, security management, IT operations, spend management, and vendor management.
Use Case: It reduces non-compliant SaaS Applications and unauthorized access, increases operational productivity through the use of workflow automation, & reduces cost by removing redundant applications and underutilized features.
Open-Source Tools: Open-source tools are good options for cloud security, especially when there are no commercial tools available. They are not only cost-effective, but also provide flexibility and innovation. However, the use of open-source tools requires careful evaluation as it also brings risks.
Security Rating Services: Security rating services for cybersecurity provide continuous, independent scoring and rating for enterprises with a visible presence on the internet. They gather data from public and private sources via non intrusive means, analyze the data, and rate security using proprietary scoring methodologies. These tools are used for internal security, cyber insurance underwriting, due diligence in mergers and acquisitions, and third-party/vendor cybersecurity assessments and monitoring.
Advantages of Native Cloud Provider Security Tools
CSPs offer an ever-expanding range of native tools for enforcing security. Some are rudimentary, whereas others are approaching equivalency to enterprise-class vendor products:
- Taking a cloud-native-security-tool-first approach can be cost-effective and address many security requirements quickly and easily, due to existing control integration with the cloud service
- Native cloud security tools are easy to purchase and implement, it is important to evaluate them against use cases, capabilities and integration with existing on-premises security tools and processes
6. Evaluate Cloud Service Provider Risk
CSP risk is an unneglectable factor for cloud adoption regardless of the type of cloud deployment:
Tier 1 Cloud Service Providers
Most public cloud activity is within a small number of well-established, financially secure CSPs that have dominated the market for over five years (prominent examples include AWS and Microsoft, Oracle Cloud, Alibaba Cloud, Tencent Cloud, Huawei Cloud, e Cloud,)
Tier 2 Cloud Service Providers
A growing number of midsize providers and some large, name-brand software providers that lack a significant cloud-first track record represent the middle tier of vendor sophistication and reliability. Some Tier 2 providers are relatively immature in their security and operations, and they often lack third-party evaluations.
Tier 3 Cloud Service Providers
Most CSPs are such small providers that you cannot ever know how well-run they are. Tiny CSPs lack the resources to undergo a third-party evaluation, and they may have only a limited ability to fully answer a security questionnaire. You must assume they are not secure, both because it won’t be worth your time and effort to prove that they are and their relative financial fragility means that their status may change on short notice.
7. Take Advantage of Security Certifications
Several forms of third-party certification programs differ as to their level of rigor and areas of examination, a successfully completed evaluation provides a high level of evidence that a CSP is adequately controlling the security of its offering.
International Organization for Standardization (ISO) 27001
- Health Insurance Portability and Accountability Act (HIPAA)
- System and Organization Control (SOC) 2
- Trusted Cloud Certification
- CSA STAR: The Security, Trust, Assurance and Risk (STAR) Registry
Payment Card Industry (PCI) Data Security Standard (DSS)
- Health Information Technology for Economic and Clinical Health (HITECH)
- NIST Cybersecurity Framework (NIST CSF)
- ISO 27001/27017/27018 Certification
- SOC 2 and SOC 3 Attestations
Health Information Trust Alliance (HITRUST)
- Cloud Security Alliance (CSA) Security, Trust and Assurance Registry (STAR)
- FedRAMP for the U.S. federal cloud
- ITSS Cloud Computing Service Capability Assessment
- Cybersecurity Maturity Model Certification (CMMC)
Our experts are certified on Oracle, AWS & Microsoft cloud to implement Multi-cloud strategies. We have delivered several first-time right cloud deployments and have also ensured we deliver projects much within the committed SLAs with minimum to no disruption to your business.
With serving 1600 Enterprise customers for their critical ERP applications, ITC is one of the 7 certified CSPE partners with expertise to consult, build, architect, operate and manage critical applications: all under one contract, with Gartner Recognition 10 years in a row.
8 Cloud API Security Best Practices
1. Proactively Scan Code for Vulnerabilities in Development
Enterprise-developed applications (including serverless PaaS) need to be scanned for known and unknown vulnerabilities. The most common mistake in cloud-native applications is the use of known vulnerable OSS components and frameworks, which constitutes about 80% of the code in cloud-native applications. In addition, all exposed APIs should be scanned as well.
2. Expand your Definition Scanning for Application Risk Beyond Just Vulnerable Software
Cloud risk comes in many forms, not just misconfiguration and missing patches, but also things like embedded secrets (API keys, hard-coded passwords, encryption keys and so on). These are placed in cloud scripts, templates and in the developer’s source code. Also, ensure correct configuration of PaaS services in terms of permissions and network connectivity. All of these risks should be scanned proactively and reactively.
3. Architect for Resiliency Using Cloud-native Capabilities
Simply taking an on-premises application and running it in the cloud doesn’t make it scalable or more resilient. Design applications that can scale out using cloud-native load balancers and built-in auto scaling capabilities. Resilience across availability zones should be architected into the application.
4.Use a Cloud-native Web Application Firewall (WAF), But Expect to use a Third-party Offering
This is an area where the built-in capabilities of the cloud providers have lagged their commercial counterparts. Third-party providers or third-party rulesets may be needed to manage the policies of the built-in IaaS/PaaS provider’s WAF service. Alternatively, WAF services may be automatically inserted as part of a dynamic SASE connection. Within cloud-native applications, WAF filtering of lateral (referred to as east/west) traffic will require some form of embedded WAF or micro-WAF capability. For denial of service protection, using what the cloud provider offers built-in is sufficient.
5. Beyond WAF, Embrace Web Application and API Protection
WAF protection alone is not enough for protecting modern cloud-native applications. WAFs were designed to protect the user interface, but the UI doesn’t reflect the majority of exposed functionality in a modern cloud-native application. Specifically, cloud-native applications should also have API and anti-automation (bot) protection. This is an expanded set of capabilities we refer to as web application and API protection.
6. Use an API Gateway or Event Bus as a Control Point
Enabled only Access to serverless functions should be through the use of an API gateway or event broker. The cloud provider’s own API gateway may be used, or a third-party API gateway. Even if the serverless code is only used internally, the API gateway/event broker acts as a critical security visibility and control point.
7. Converge Operational and Security Monitoring
At the application layer, there is no need to have two separate tools (one for security, one for operations) performing detailed monitoring of the service. At a minimum, the data will be shared across teams, but ideally application performance monitoring and security monitoring will merge into application monitoring and performance supporting a single DevSecOps team. This will become increasingly important as more managed container and serverless code is used and information security won’t have an OS to instrument.
8. Don’t Treat PaaS Security as a Fundamentally Different Problem
PaaS security is not a separate problem or market. It is an emergent discipline that uses the combination of the capabilities described thus far in this research. PaaS security discipline is rooted in strong identity and access management principles, proper infrastructure configuration and hardening, continuous cloud security posture assessment, pervasive monitoring and application-layer scanning and security.