It is estimated that 68% of companies will use DevSecOps to secure their cloud-native applications in the next two years. This is an increase from the 8% that currently use DevSecOps teams. Why the change? Organizations are increasingly realizing that traditional security methods and processes don't work when it comes to cloud-based systems. To properly secure their clouds, and their products, organizations must adapt their security practices. Often, this means adopting cloud-native solutions.

In this article, you'll learn what cloud-native DevSecOps is, as well as some considerations for implementing cloud-native security.

What Is Cloud-Native DevSecOps?

The term Cloud-native DevSecOps refers to implementing development, operations, and security practices in a way that fully integrates with cloud capabilities. A cloud-native implementation uses and secures scalable, dynamic components. This can include containers, microservices, service meshes, declarative APIs, and immutable infrastructures.

Like traditional DevSecOps, the various tools, configurations, and systems are managed with automation whenever possible. This automation enables engineers to quickly and predictably make changes to products and reduces manual work on repetitive or tedious tasks.

Cloud-native security tools are designed to run in an elastic and distributed way, adapting to demands on the fly. These tools enable the integration of meta-data based security policies and help development and operations teams to operate autonomously and securely. Ideally, cloud-native tools can provide increased performance, scalability, and efficiency over traditional tools.

Considerations for Cloud-Native Security

Cloud-native security shares many of the concepts and practices of traditional security. The major differences lie in the way it is implemented and the tools used. Below are some issues to keep in mind when addressing these differences.

Shared Responsibility Model

Cloud service providers use a shared responsibility model in which you are responsible for a certain share of your cloud system. The amount you are responsible for depends on whether your provider offers Infrastructure as a Service (IaaS) or Platform as a Service (PaaS).

With IaaS, you are responsible for securing any Operating Systems (OS), applications, data, and user access. With PaaS, you are responsible for securing applications, data, and user access. The provider takes care of the pieces you are not responsible for, including maintenance of physical components, infrastructure, network, and virtualization. In the case of PaaS, the provider also takes care of any OS.

This shared responsibility has both positive and negative aspects. On the positive side, your security team is responsible for fewer components. Additionally, cloud providers often have access to significantly more security staff and expertise than an individual business does.

On the negative side, because the provider is responsible for securing components, you won't have access to them. This means that traditional security methods focusing on the use of network or host-based control often won't work. Thankfully, most cloud providers offer robust tools and services for securing the components you are responsible for. These tools and services are already cloud-native and designed especially for securing cloud systems.

Containerization

With containerized workloads, you must shift your security focus to securing the application layer. You should use the 4Cs as a base: cloud, cluster, container, code.

Cloud

To secure your containers in the cloud, you should focus on setting up secure configurations and permissions. You should restrict access to APIs, nodes and ectd (if you are using Kubernetes).

Using Role-Based Access Control (RBAC) authorization for access to API can help prevent attackers from illicitly accessing your containers. You should also make sure to encrypt everything, including all communications and data.

Cluster

To secure your clusters, focus on components that make up the clusters and on components running the clusters. You need to take care that one vulnerable workload doesn't negatively affect others so try to reduce interdependencies to the minimum.

Critical components should be isolated as much as possible. During your configuration, make sure to employ pod security policies. Doing so can reduce the chance that a successful attack affects an entire cluster.

Container

To secure your containers you should periodically scan for known vulnerabilities. A variety of open-source, as well as paid tools, are available for this purpose. Make sure to use image signing and enforcement policies with your containers.

These policies can help ensure that your container contents have not been modified without your consent. You should also take care not to create privileged users. Try to separate user permissions by roles or tasks rather than assigning a wealth of privileges to one user.

Code

Securing your code is the area in which you have the most control. It's vital that you minimize dependencies in your applications and follow basic open-source security practices. The more dependencies you include, the greater the chance that you will unknowingly include vulnerabilities.

This is true whether you use individual snippets or entire libraries. You should periodically perform static code analysis to identify flaws and vulnerabilities in source code. Overall, if you stick to secure coding practices, your application and your system will remain much safer.

API Vulnerabilities

API vulnerabilities are impossible to completely avoid in cloud environments as they are the basis of communication. To reduce your risks, use HTTPS for all communications if possible. Using password hashing, in addition to encryption, will ensure that even if credential information is intercepted, it is kept private. It is also important not to expose confidential information, like passwords or API keys, in URLs. If you expose this information you are giving attackers easy entry to your system.

Stateless APIs are safest to use as they require real-time authentication and authorization, as opposed to relying on cookies or sessions. Similarly, you shouldn't rely on a cached permission matrix for credential authentication. If you do, attackers might be able to take advantage of expired credentials that have not been cleared from your system.

Third-Party Tools

If you do not wish to use the tools that are already available through your cloud provider, you can choose to implement third-party tools. Many vendors offer cloud-native services and solutions, many of which are managed for added convenience. If you do wish to use one of these tools, first verify that it supports a range of infrastructures. Any tool you select should provide coverage for all components of cloud-native infrastructures including containers, serverless functions, and virtual machines.

Try to select tools that include whitelist-based controls. With whitelisting, you can block anything or anyone that is not on your list. This method is easier to lock down than blacklisting. With whitelisting, you don't need to worry about constantly updating your list to block new threats.

The most valuable tools have the ability to adapt to future technology. Tools should also include automation features. Automation can help you account for the speed of attacks and the significant number of threats against your cloud. By automating routine and minor security tasks, good tools enable your team to focus on more serious threats.

Conclusion

DevSecOps is increasingly being adopted by organizations to help secure their applications and systems. However, traditional security tools and practices are often not a good fit for the cloud-based processes used by DevOps teams. This does not mean that all security practices need to be discarded, only carefully adapted. The considerations covered here are an excellent place to start with this adaptation. Keeping them in mind should help you and your security team ensure that your applications and cloud is kept as secure as possible.

##

About the Author

Gilad David Maayan is a technology writer who has worked with over 150 technology companies including SAP, Samsung NEXT, NetApp and Imperva, producing technical and thought leadership content that elucidates technical solutions for developers and IT leadership.

LinkedIn: https://www.linkedin.com/in/giladdavidmaayan/