Often I have heard that in a large enterprise it becomes difficult for audit, compliance, DevSecOps or DevOps teams to implement these controls centrally in order to monitor and govern in real-time and generate reports on press of a button whenever needed.
Technically it is very easy but from a logistics standpoint it is very complex given the nature of operations of the distributed teams. Typical scenarios are:
Sprawling Technology Stack
Different teams have different responsibility areas; some are developing front-ends on java or microservices that combine together to form an application. Some are purely working on the back-end capabilities. Each team may select their own preferred technology stack or tools (DevOps and DevSecOps toolchain) based on their requirements (and perhaps, convenience). Typically these choices are based on:
Application Type
Take an example of a bank, so you will find separate teams for core banking, internet banking, mobile banking, asset management, capital markets, and so on.
I have often seen one team using Jenkins as a CI tool and have extended capabilities for continuous delivery by writing scripts on top of Jenkins whereas other teams using Jenkins as CI along with a specialized tool for CD – Spinnaker or Argo.
Target Deployment Destination
In certain cases even the target deployment destinations may vary – some on VMs and some microservices on containers. The destination may be on premise or on cloud depending upon the security / compliance requirements.
Below illustrations explain these scenarios
While Team A may use Jenkins as CI and Urban Code for CD purposes, It is possible that Team B may extend the functionality of Jenkins to perform CD activities by writing scripts that are executed on Jenkins. The process or the workflow between these teams may also differ.
Not to mention that they may not have a fully automated pipeline or a workflow and it may be disjointed.
In such scenarios it is extremely difficult to obtain 360 degree insights into what’s happening in each team with respect to security and compliance controls. Are they adhering to policies or there are violations that are unnoticed.
How do you centrally manage and enforce these controls?
OpsMx Deploy Shield helps you to enforce policies and implement these controls to help central teams to implement compliance and ensure the policies are adhered and there are no violations. Deploy Shield also helps them to generate proof points for audit reporting.
Let me explain this by providing insights into the benefits and value OpsMx Deploy Shield brings to these enterprises.
How OpsMx Deploy Shield Fits into Your Environment
OpsMx Deploy Shield is an independent layer that sits on top of your existing assets by seamlessly integrating with your entire tool-chain, irrespective of the teams.
Out of the box Integration
So whether you are using Gitlab or Github or Bitbucket, Jenkins or Bamboo, Jira or Service Now, Data Dog or Appdynamics, Sonarqube or CheckMarx or Trivy within different teams, OpsMx allows you to integrate with all of these tools without having the need to write any code.
Data Synthesis and Analysis
The integration allows these tools to act as a data source. This data is ingested to the synthesis and analysis layer to enable enterprises to automate data-driven approvals, verification, security checks, dynamic policies, etc. for automating almost any controls as part of a connected CI/CD pipeline. You need not execute any task manually that may lead to inconsistencies.
Role Based Access Control for additional CI/CD guardrails
OpsMx enables RBAC and allows distributed teams to work with a centralized tool without interfering and getting distracted with the integrations and workflows of other teams. They see and operate on their assets only.
Central teams can obtain a consolidated view categorized by applications in a unified dashboard while distributed teams will be able to obtain views for the applications they are responsible for.
Scalability
OpsMx Deploy Shield is extremely scalable and enterprise ready to cater to the needs of a global enterprise with ease.
Automated Application Security Posture Management (ASPM) across different stages of the pipeline
This integration also enables you to determine the security posture of your application across different stages of your pipeline. This helps you to determine if the security vulnerability got inserted at a specific stage because of a particular activity. It enables enterprises to detect issues early in the application lifecycle making it less expensive operationally.
The capabilities include suggestions on how to fix a specific vulnerability. Please go through a comprehensive blog on getting started with AppSec and SecOps and how to integrate it within your CI/CD pipelines.
Inbuilt Security Frameworks and Specific Policies / Rules
OpsMx Deploy Shield comes bundled with the best practices in the form of proven security frameworks like NIST and specific policies that are part of the rules library. These rules can be implemented for specific teams and specific pipelines or specific stages within as per the need. Please read this blog to know more about selecting the compliance or security policies for the available libraries of rules.
These rules can be enforced centrally across all distributed teams and their specific pipelines / workflows.
Unified Dashboards and Audit Reports
You would definitely like to get insights into the controls you’ve set up. OpsMx provides you out of the box dashboards with visual illustrations offering insights into ASPM, performance, compliance rules, audits, pipeline executions, etc, with drill down capabilities.
Needless to say the notification mechanism includes emails, updates to the governance tools, as well as chatOps (Microsoft Teams, Slack, etc.)
Deployment Firewall
Deployment Firewall allows you to keep the bad code out and ensure your production deployments are vulnerability and performance-defects free.
Deployment Firewall enforces policies at the deployment stage of your pipeline and takes an automated decision on what goes to the deployment and what doesn’t goes to the deployment.
So whether you are deploying to VMs or to containers, the Deployment Firewall assesses the state of security or performance for your application or services, ingests data from your pipeline and DevOps tool chain and takes a decision whether the deployment is to be blocked or to be allowed.
Irrespective of teams and their specific services, deployment firewalls can be enforced to the deployment stages of each and every workflow or CD pipelines across distributed teams. This happens via seamless integration of OpsMx Deploy Shield to any existing CD tool.
Go through this article to get details on why do you need a deployment firewall and how it helps you to keep the bad code out.
Delivery Bill of Materials (DBOM)
DBOM is an extension of Software Bill of Materials (SBOM), that helps you to do the provenance check if there is any variation in the bill of materials during the build stage or an image and the bill of materials post deployment. This variation allows you to detect risks by obtaining a smart diff.
This variation or provenance check can be enforced with a policy to ensure that there are minimal risks during production deployment.
This also helps teams to determine which services are getting affected due to the variation in bill of materials.
There are numerous other benefits that are byproducts of automation and policy enforcement but if you want to learn more, you may speak to one of our top Secure Software Delivery experts or request a call back.
0 Comments