Security Best Practices for Developing and Deploying Cloud-Native Applications

What Is the Difference Between Traditional Application Security and Cloud-Native Security?

In traditional applications before the cloud, development and security requirements were fulfilled by teams of developers. Infrastructure management was managed by a different team but end-to-end securing of the network, compute, and storage was ensured by developers. This required more manpower, processes, and policies such as setting up hardware firewalls, DDOS mitigations on-prem, etc.

With the advent of the cloud and its security, the only important thing is the context of operation for your application. Surely, the cloud has a lot to offer in terms of flexibility along with a range of services and infrastructure. However, these features also enlarge the attack surface area in order of magnitude as compared to traditional application security. In light of this, understanding the context in which your application is operating becomes crucial because now you need to model your application while understanding its input/output patterns, interaction pieces, etc. Your applications may have inputs from event streams, cloud storage changes, and databases, potentially introducing additional attack vectors. Hence, you must secure the platform and the infrastructure that enables your application. Only this kind of thorough and continuous hardening would implement application security in a cloud-native environment.

Does This Imply That the Advent of the Cloud Has Made Security More Difficult Rather Than Easy?

It hasn’t made security difficult per se; however, the advent of the cloud has instituted the concept of Shared Responsibility.

As mentioned earlier, traditional application development, infrastructure, and security were managed by on-prem IT teams but with the cloud, some of those responsibilities have been outsourced to the Cloud Service Providers (CSPs) who are responsible to secure their infrastructure and software layers that they operate on, formally known as Inherited Security Controls, that covers the security from CSPs’ side.

For the startups using these services, the responsibility to secure their domain lies with themselves. For example, configuration management, identity and access management policy, securing databases, data encryption in-transit and in-rest, etc.

CSPs provide you with tools to secure your domain. The ultimate responsibility lies with you in the Shared Responsibility Model to administer the right configurations and apply the right guard rails at each layer.

Cloud has not made security difficult. Instead, it has divided the responsibility between the service providers and startups to ensure robust and secure applications.

How Would You Describe a Secure Software Development Lifecycle?

To secure any software development lifecycle (SDLC), having third-party APIs or open-source libraries is no longer enough. Instead, security has to be catered to at every stage of the software development lifecycle. It is ideal to have a secure automated testing pipeline built into all stages of SDLC of your application.

For cloud-native security, however, you need to protect all of the assets that you have deployed on the cloud. This requires, first of all, understanding the context and substrate your application operates in e.g. containers or VMS. Ensuring security at Operating Systems (OS) and application levels requires administering good principles and policies.

Firstly, Static Application Security Testing (SAST) which is built into the CI/CD pipeline allows developers to statically analyze vulnerabilities in their source code and the third-party libraries.

Secondly, Dynamic Application Security Testing (DAST) also known as penetration testing is carried out once the application has been deployed. It allows the developers to scan the ports and IPs of your space, anything that is open and vulnerable. Once identified, you can take measures to mitigate it.

Thirdly, Interactive Application Static Testing IAST resembles DAST in operating dynamically. However, the goal of IAST is to find out runtime vulnerabilities in a runtime scanning infrastructure that continuously scans and monitors your environment.

Lastly and more recently, Runtime Application Self-Protection (RASP) where your applications are built in a way (or are supported by services) that essentially detect these issues that happen at runtime and then do self-mitigating actions, generate real-time alerts if something suspicious has happened. For example, say there’s a DDoS going on, how to detect and automatically remediate it. This is what falls under RASP.

All of these measures together contribute to creating a secure development lifecycle for an application.

What Are the Best Practices for Secure Application Development and Deployment?

For ironclad secure application development, Identity and Access Management (IAM), encryption, threat monitoring response, data privacy and compliance, and automated security testing are major boxes that need to be checked irrespective of what cloud you are going to deploy online.

For Identity and Access Management, the principle of Zero Trust is followed which means you should not trust anyone. You have to model your application with knowledge of who is going to access it, and what is the level of privileges they have. CSPs give you tools to implement these identities and access management.

The importance of data encryption is undisputed. There are different types of data encryptions namely, in-transit, in-rest, and in-use. In-transit, in-rest and in-use encryptions help protect your data during communication, when data is stored/is at rest, and when data is operated on, respectively.

For threat monitoring and incident response, you need to have an infrastructure in place that continuously scans and monitors for threats. Once a threat is detected, you must have a strategy in place to respond to that threat. If these strategies are an afterthought for a startup, they can expect a huge blast radius when they are hit with a threat. So, detection and response to security-related incidents are critical.

Data privacy and compliance deal with different localities, regulations, and laws that apply to these local sites. The data privacy and compliance mechanisms in your application have to identify and address these differences depending on your location and the location of your CSPs.

The necessity of Automated Security Testing cannot be stressed enough and it implies that ideally at each stage of SDLC, you have all of the controls i.e. SAST, DAST, and RASP have been built in the CI/CD pipeline.

Lastly, securing your APIs and secure modeling of the communications patterns that your application exhibits is really important as well.

Is Monolithic Architecture More Secure Than Microservice Architecture?

Monolithic architecture is a single-tier design with security parameters built around that tier. This might make securing that one tier relatively easy, but monoliths have their disadvantages. For example, you cannot innovate fast enough, or add new features efficiently. Whereas, microservices architecture can decouple the responsibility of each service and is iteratively able to improve and consequently upgrade your product fast. Modern architecture requires you to have that very fast prototyping and development and no matter how secure monoliths may be, microservices are the future.

Does all the data need to be encrypted?

Ideally, yes! But, of course, there are costs associated with it.

When you encrypt data at rest, it requires additional resources in terms of time and money for ensuring the cryptographic validity of your data. The overhead extends to performance as well because encryption requires decryption. So, your encryption scope is defined by the context your application is operating in. You have to strike a balance between performance and data security.

How Is DevOps Different From DevSecOps?

DevSecOps is just a subset of DevOps. The concepts differ in the notion that DevOps is purely just CI/CD and IaC allows you to rapidly develop applications and deploy them whereas DevSecOps deals with automated security testing that is built into the pipelines resulting in development and security operations. On one hand, DevOps facilitates the configuration of your IaC and on the other, DevSecOps facilitates the additional guardrails built for security-specific functions. That is where the industry normally decouples the concepts of DevOps and DevSecOps in the application’s continuous integration and deployment.

A right DevOps pipeline must have security built-in, it can’t be an afterthought. DevSecOps directly targets the security-specific things in a DevOps pipeline and a DevOps pipeline is essentially just the application’s continuous integration and deployment.

Does Cloud-Native Security Mitigate Insider Threats?

Insider threats are a vast and interesting domain as there are models that can be used to predict them but mostly they are very hard to find. Insider threat means that you either have some unauthorized user who has their privilege elevated or there is some malicious insider who essentially has access to data and has somehow exported it out.

Cloud-native security provides you with the tools to mitigate insider threats. For example, you can set up the right access identity and access management and follow the principle of least privilege where the people who are supposed to have access to that data are the ones who do, and then you can also establish parameters around services. You have, at your disposal, tools to implement these controls but insider threats will still happen and you need to have a robust incident management detection and response strategy to deal with that.

How to Ensure Long-Term Data Safety in the Case of Cloud Payment Applications?

For payment industry solutions, there is a specific standard called Payment Card Industry Data Security Standard (PCI DSS). It has checklists of principles that are implemented for any application that provides a payment solution. For example, it includes having active firewalls, the right IAM, the encryption in place, and protecting the cardholder. Any application that is being built with a payment feature has to abide by these standards. What is important to note here is that with the increasing amount of CSPs in the market, all of them ensure that their services are PCI DSS compliant. Still, as an application developer or a startup founder, you have to make sure that you have the right vetting in place to guarantee standard compliance.

Is Cloud Security Offered by Cloud Service Providers (CSPs) Enough for Your Application?

CSPs will ensure their layers of software, hardware, and infrastructure are secure and any breach in those layers will be their responsibility. Keeping Shared Responsibility Model in mind, the second layer is the domain of the startup using the services. Therefore, securing that layer is the responsibility of the startup itself. For example, robust IAM strategy, patch management, and configuration management need to be secured by your company to deter exploits.

How Do I Secure Hybrid and Multi-Cloud Environments?

Hybrid environments are a challenge because there are different tools for on-prem and cloud to implement security. Ideally, there would be a single dashboard to store, operate, and monitor such environments. CSPs have been increasingly providing features for a seamless experience across different environments. For example, Google has Anthos where you can run the Kubernetes engine on-prem as well as on the cloud at the same time and have a single pane of management across them. Similarly, AWS has AWS Outposts which allows you to use AWS stack and services on-prem as well. The important thing to note here is knowing the context; what are the communication patterns that exist on-prem, what are the communication patterns that exist on the cloud, how do you secure them, can you have one solution that spans across both or will you have to have different solutions that logically create a single security interface but are decoupled in physical implementation?

How Is Application Security Guaranteed in a Multi-Geo Environment?

In the shared responsibility model, the third layer is customer-specific and depends on the operation site of your application. For example, the Global Data Protection Regulation (GDPR) standards and protocols need to be followed for customer data stored in Europe. According to their data regulations or their environmental regulations, this data cannot move out of said location. So if you are developing an application that spans different geographies, the tools to implement security guardrails are available but a robust strategy to develop an end-to-end secure application that operates in different jurisdictions and has different governing laws has to be formulated by the startups.

What Should Be the Course of Action in Case the Breach Has Happened?

There are a few standardized steps, for example, you have to capture events in your system and analyze them. You need to know not only the source IP of the malicious request but also the destination IP, the protocol, and the fields inside these requests. There are different ways to address a breach. Some startups build in-house solutions that define the rules that are applicable for such events. Analyzing and mapping these events to normal traffic generates alerts. The incident response team has automated pipelines in place to identify and launch actions that address said alerts. Generally, continuous threat monitoring and incident response are one of the very critical functions of having security in this day and age.

In Proactive Security Strategies, Does Artificial Intelligence (AI) Play a Role?

Proactive security detection means automated security testing throughout your SDLC. Tools are available that allow you to continuously scan your Static Source Code to find out vulnerabilities and then automatically suggest solutions to mitigate those vulnerabilities. Similarly, Dynamic Code Analysis and Runtime Code Analysis allow you to map traffic patterns so that you can identify any anomaly. AI models help you predict these patterns and identify anomalies. This, in itself, is a vast domain and AI plays a role in contextualizing the full security problem.

To Watch the Complete Episode, Please Click on This YouTube Link:

https://www.youtube.com/watch?v=hPT1Zj3tNV4&t