Overview
In the past few years, the digital world has witnessed an unprecedented increase in malicious and sophisticated cyber attacks, costing organizations over millions of dollars. According to Statista, the incidence of breaches in the U.S. has significantly increased within the past decade from 662 cases in 2010 to more than a thousand cases by 2020.
As such, companies across the globe have started taking a proactive approach to prevent security breaches and institute centralized policies, i.e. shifting security left.
In this article, we will go over some of the terms that are important in the field of security.
What is DevSecOps?
DevSecOps stands for development, security, operations. The practice integrates security into every phase of the software development cycle. In the past, security was the last step before a software was released. There was a separate security team in a siloed development structure. This approach worked fine for traditional software development models such as the Waterfall model, where even iterations to software took several months.
Organizations , today, are increasingly adopting the agile method of software development, which has shortened the development cycle considerably. New iterations of an application are released within weeks or even days. Keeping security for the very end is no longer feasible. DevSecOps integrates infrastructure and application security into development processes. Security issues are addressed as they emerge, which makes them easier to fix.
DevOps Vs DevSecOps: The Difference
Both methodologies rely on automation and continuous processes to increase efficiency. DevOps focuses only on the development side of things. The aim is to improve the speed of delivery. DevSecOps, on the other hand, shifts security to the left, or to the beginning of the development cycle. It ensures that the codebase is secure from the very beginning. While shifting security to the left might increase delivery time of a software to begin with, development teams can benefit from faster iterations and better cost efficiency.
In addition, DevSecOps makes security a shared responsibility of the entire team. Security is no longer the sole responsibility of the QA team. Developers share the responsibility, translating to a more agile development process.
To learn more about What is DevSecOps and why is it important.
What is Security-as-Code?
Teams, be they Developers or Ops or security, have been operating in silos. In the past it was the Dev team and the Ops team operating independently, giving rise to the DevOps where both Devs could do some of the Ops work and vice versa.
Now there’s a need for the DevOps and security teams to work collaboratively, where some of the DevOps mindset, ideas, and agility can be brought to the security forefront. There’s an utmost need to bring security into basically the pipeline starting off from the development all the way to deployment - from code to cloud.
By doing so, security is not an afterthought, it doesn’t come at the tail-end of development, it's non-intrusive, and doesn’t hinder or slow down development. Security-as-code is all about breaking down silos between Ops teams, Devs, and Security teams so everyone is security conscious and all work with each other, as opposed to working against each other.
A brief definition of security-as-code:
“It’s about codifying your security policies and workflows, baking security practices into the development process, automatically and continuously detecting vulnerabilities and security violations before they are delivered to the cloud.“
To learn more about security-as-code, check out this article.
What is Policy-as-Code?
Policy-as-Code or PaC is the process of codifying your security policies. In this scenario, DevOps teams use code to manage and automate security policies. As such, it's pretty similar to the concept of IaC.
To implement your policies, you can use a policy engine like an Open Policy Agent. This approach helps enterprises enforce certain rules across the organization or within a specific cluster. Codified policies improve efficiency and automation protocols. They also help implement policies that better secure the environment.
What is Compliance-as-Code?
Compliance-as-code can be understood as a logical extension of policy as code. Policy as code is the practice of encoding policies so that they can be managed and automated company wide. Writing policy into code allows for automated testing and deployment across your IT estate.
Writing compliance into code creates a common standard and keeps everyone on your team on the same page – a rare attainment in today’s landscape. Thomson Reuters, a leading source of business information services, has declared that “the single biggest culture or conduct risk facing firms is creating a unified compliance culture.” Meeting that challenge, therefore, and facing that risk automatically puts a firm head and shoulders above the competition.
Continuous compliance assistance creates that compliance culture and helps to detect infrastructure drift by continuously monitoring and reporting compliance violations. Likewise, continuous security and compliance checks enforce cloud security and best practices throughout, from build to deployment.
Compliance as code allows risks to be visualized so that users can apply a common set of benchmarks to assess compliance across all assets. The practice also makes it easy to issue detailed reports so that they can be addressed as quickly as possible.
The Benefits of Compliance-as-Code can be found here.
What is GitOps?
GitOps is an approach to software development where you leverage DevOps best practices like collaboration, CI/CD tooling, code version control, and infrastructure automation. It's crucial because the infrastructure needs to be elastic to manage cloud resources for continuous deployments effectively.
In this case, Git is often the basis for defining and controlling DevOps workflows and synchronizing them across systems. For infrastructure definitions, GitOps also uses the Git repository as a single source of truth. In other words, the ".git" folder in a project is a repository that tracks all changes made to project files.
What is Infrastructure-as-Code?
IaC represents the process of managing and provisioning infrastructure (or networks, virtual machines, load balancers, and connection topology) through code. This approach helps optimize operations and is far better than traditional manual processes.
IaC is also the practice of tracking and keeping all infrastructure configurations as saved code files. However, depending on your approach and organizational policies, the actual desired state may or may not be stored as code.
For example, you can create configuration files with your infrastructure specifications. This makes it much easier to edit and distribute configurations. As a result, IaC is now a crucial DevOps practice used in conjunction with continuous delivery.
For more information on policy-as-code and infrastructure-as-code, and GitOps, check out this 101 guide.
What are Kubernetes Security Context Settings?
Kubernetes tools like security context settings allow every container and pod to boost security and avert a potential security incident. Kubernetes security context includes tools like Open Policy Agent (OPA)Gatekeeper and policies like Pod Security Policies. However, securing containers and pods isn't easy because of the knowledge gap.
"Security context" basically indicates specific constraints when it comes to access and permissions at an individual pod level that's configured at runtime. Such settings include a wide range of configurations like the following:
- System-level capabilities
- Container root filesystem ready (or not)
- Run privileged (or not)
- Access control based on UID and GID
Getting these settings and configurations right is the first step to fortifying your environment. As such, we should tread carefully when implementing each setting. Check out the full article here.
What is Zero Trust Security?
Zero-trust is built on the idea that any entity accessing corporate networks must continuously prove that they have the necessary rights and permissions to access any given asset or area. In this scenario, a simple username and password aren’t enough to be “trusted.”
This means that users will only have access enabled by specific permissions within an effective zero trust architecture (ZTA). Whenever user behavior is deemed suspicious or outside their usual purview, an automatic alert will be triggered.
Practical Zero Trust has Five Crucial Elements:
- Application trust
- Data trust
- Device trust
- Transport/session trust
- User trust
Most modern zero-trust systems concentrate on device and user trust areas. This makes perfect sense, considering how companies think about cybersecurity. But in the cloud, there are many more variables that increase your risk exposure.
In response, other areas like application trust and data are coming into prominence in a cloud-first world. Instead of addressing security from just an identity standpoint, we must add breadth to strategies by addressing zero-trust from a controlled access standpoint.
How does zero-trust architecture work? Check this article to learn more.
5 mins read
back
Comments and Responses