The Role of the SOC in DevSecOps
There are many buzzes, topics, areas, and responsibilities to take care of in every environment – SIEM, SOC, DevSecOps, Cloud-Native Security, App Risk, App Sec. WOW. This post focuses on The Role of the SOC in DevSecOps.
The SOC is changing and will be changed dramatically in the following years. There are many reasons for all of those changes, but the known one and the central fact is that the Cybersecurity landscape is changing in many aspects. The recent security incidents show that many came from the application security (#appsec), open-source and cloud-native areas.
Does your SOC know how to handle and identify those security incidents? Or mitigate the security issue during the development cycle? Mostly, NOT! If I can take a great example is an example of “Apiiro Discovers 0-Day Software Supply Chain Vulnerability in Argo CD.” For more information, see the link below. 👇
The SOC and the incident response team don’t need to remediate vulnerabilities. Still, it needs to know how the development cycle works, which artifacts the process has, and how to create detection rules to identify malicious actions and investigate the incident.
Besides all of these, we know that technologies are in a race and changing every day. Today’s technologies, such as Cloud-Native, DevOps, and Open-Source, are not only for developers. If you’re a security person, you might need to know how to handle security around those areas.
TIP: It must be changed if you’re struggling with too many daily alerts and incidents. Otherwise, you will find that your SOC will not provide the benefits that should be provided.
Your SOC needs to merge development, security, and operations teams into a unified model known as DevSecOps. Does the SOC still have a role in DevSecOps? What will SOC processes look like in a modern, collaborative environment when cloud-native, open-source, and development is the critical part of the company?
SOC Analysts – DevSecOps View
It’s worth reminding you that DevSecOps is a confusing moniker. It technically contains independent and distinct elements of an enterprise – development, security, and operations – and does not simply tack on the familiar SecOps.
The big question is, does the SOC need to know, be familiar, or be an expert with all technologies? Of course not, but this is a big BUT. The SOC must know which technologies, tools, and data are part of the environment. When securing DevOps, the SOC needs to know the process, the security tools, and the fact that DevSecOps is an element that should be helpful. And why is that? Below are a few main points that can play a significant role with SOC and DevSecOps.
Automation is the King
As SOC engineers, you should want insights into new software’s tooling and development process. So, in the same way, the code of cloud-native applications is automated to allow engineers to deploy updates and ensure reliability easily. A build should also involve the automation of security assessments during the planning and production phases of the software lifecycle.
DevSecOps automation is one of the most significant benefits of shifting security left in your development process. The aftermath of Log4j, SolarWinds, and other breaches should be on your mind if your organization considers moving to DevSecOps.
To ensure process efficiencies, DevSecOps relies on automation, which enables developers, infrastructure, and SOC teams to focus on delivering value instead of making mistakes or repeating routine tasks without the ability to know if there are any breaches.
Now that we know that DevSecOps and automation are vital parts that could take the SOC team one step ahead, we should adopt DevSecOps and automation as part of the SOAR.
Implement Kubernetes or container orchestration solution to apply, provision, and manage repeatable security best practices through container orchestration. A great example of DevSecOps automation is to implement orchestration for Containers. This approach allows you to move to container orchestration systematically by starting small with one project, taking your lessons learned, and expanding orchestration throughout your cloud-native projects where it makes technology and business sense.
As a SOC, you can take all these findings and ingest the security insight into your SIEM. From this point, you should create detection rules, proactive hunting, etc.
The Sec in DevSecOps
DevSecOps, SecOps, OpSec, whatever you want to call it, call it 😜. While you’ve got a multi-cloud and hybrid environment, cloud components, networks, applications, and other assets that the SOC needs to protect, it makes sense that security teams use the tools and platforms – including the previously mentioned SOAR – that are also constructed with this architecture. This will then traffic into the SOC the attractive benefits of cloud-native: rapid innovation, scalability, and business resiliency, which help improve threat detection, investigation, and response.
DevSecOps Security Culture
The fusion of development and security functions indicates that a breakdown of silos is underway. Anytime security can be viewed as a partner helps disrupt the common perception within organizations that infosec is a highly risk-averse group that says “no” to any new tools, applications, cloud services, or ways of doing things. In a remote-centric era, that is good for overall business chemistry because it means more collaboration within disciplines that don’t typically speak the same language.
How can DevSecOps affect SOC?
DevSecOps can be partnered with or managed via a SOC. Here are some methods by which a SOC can modernize its processes even though a SOC in and of itself is a form of silo.
- Develop a distributed SOC with DevOps members – SOC team who’s familiar with DevSecOps can assist with incident response. They have an in-depth understanding of the systems and can gain knowledge of vulnerabilities and threats from security staff.
- Threat Hunters with DevOps team – threat hunters can communicate directly with DevSecOps or DevOps teams to address security gaps at their core, rather than isolating a threat and reporting it to management.
- Creating security experts – the SOC can work with specific DevSecOps dev and operation groups to implement security best practices. They can convey these favorable results to the entire organization to encourage DevSecOps practices.
- The SOC as advisory – everyone working with security should be able to quickly contact the SOC and be part of the security story. DevSecOps and DevOps should know how to address a security issue and talk with the SOC team.
How the SOC and DevSecOps should be? The diagram below describes, in general, the level of SOC, Cloud, DevSecOps, and DevOps that needs to be part of the process that feeds the SOC with indicators and security insights and can minimize the security issues in the development cycle.
DevSecOps Key elements
As w know, the SOC want helpful information such as indicators, security insight, events of interest, and all the information that can provide them the ways to create detection rules or proactive hunting and know when the organization is exposed to some vulnerabilities or worst is under breach that occurs from the development process.
DevSecOps provides frameworks, approaches, elements, and many more ways to secure DevOps development as seamlessly and transparently as possible. The main elements below are part of the DevSecOps approach and might be changed per environment and development process.
Analysis of code – deliver code in small pieces so the team can quickly identify vulnerabilities.
Submitting changes – permit anyone to submit changes, increasing efficiency and speed. Afterward, see if the change is successful or not.
Monitor compliance – be prepared for an audit at all times, which means always being compliant.
Investigate threats – identify possible threats each time the team updates code so they can respond quickly.
Assess vulnerability – identify vulnerabilities with code analysis and ensure the team quickly attends to them.
DevSecOps & Velocity
DevSecOps is a practice that integrates security into the DevOps process. The goal of DevSecOps is to bridge the gap that DevOps created between IT and security by adding security practices into an already faster and more agile software delivery process. Organizations using a DevSecOps model now understand that security cannot be an afterthought and must be a central part of the Software Development Life Cycle (SDLC), Secure Software Development Framework (SSDF), and SLSA.
DevSecOps collaboration is more challenging than DevOps itself because you need to achieve two seemingly conflicting aims simultaneously. Specifically, you need to speed up the delivery process and take time to ensure the code is secure and free from vulnerabilities. Some even argue that security should not be rushed and claim it is better to slowly release a safe product than run an insecure product to market.
To implement DevSecOps without decreasing application or product quality, organizations created a culture that treats Security as Code by inspiring developers to consider security aspects and motivating security teams to automate tasks. Organizations also focused on flexible and continual cooperation between IT engineers, SOC teams, software developers, and security teams by promoting communications and collaborations.
In the past, operations and security teams had conflicting goals. Operations were responsible for setting up systems to achieve uptime and performance goals. Security was responsible for verifying a checklist of regulatory or compliance requirements, closing security holes, and putting defenses in place. In this environment, security was a burden—perceived as slowing operations and creating overhead. But in reality, security is part of the requirements of every IT system, just like uptime, performance, or basic functionality.
SecOps combines operations and security teams into one organization. Instead of having ops set up a system, security comes in to secure it, and systems are built with security in mind. Security is “shifting left”—instead of coming in at the end of the process. It is present at the beginning when requirements are stated, and systems are designed.
SecOps has additional implications in organizations that practice DevOps—joining development and operations teams into one group with shared responsibility for IT systems. SecOps involves even broader cooperation between security, ops, and software development teams in this environment. This is known as DevSecOps. It shifts security even further left—baking security into systems from the first iteration of development.
image credit: snipeyes
SOC & DevSecOps adaptation
Can the SOC and the DevSecOps do adoptions? Is it possible? Here are a few ways the modern SOC can encourage a DevSecOps mentality.
- Analysts can continuously inform operations staff about threats to the organization’s systems and incidents.
- Analysts can proactively seek out security gaps and work with operations to close them.
- Operations can come to the SOC for guidance about the security implications of systems, components, vendors, or changes.
And the points described in how DevSecOps can affect SOC.
- Creating a distributed SOC with DevOps members — DevOps teams can help with an incident response due to their deep knowledge of IT systems. They can learn from security staff about threats and critical vulnerabilities. Here are a few ways a SOC can integrate its processes with dev and IT.
- Pairing threat hunters with DevOps team leaders — instead of discovering a threat and reporting it upwards, threat hunters can work directly with dev or ops teams to close the security gap at its source.
- Opening the SOC for guidance and advice — anyone working with a security impact should have an easy path to reach the SOC and consult with the organization’s top security experts.
- Creating security centers of excellence — the SOC can work with selected dev and operations groups to implement security best practices and then showcase these successes to the entire organization to promote SecOps practices.
The big question is. How Microsoft Sentinel and DevSecOps can take you into this process? The next post will be focused on some examples and scenarios.