About the customer
Fortune 500 financial services firm focused on global investments for pension funds, institutions, and individuals.
The environment
The company has taken an aggressive stance toward digital transformation, making cloud investments across all aspects of its business. This includes the development of proprietary applications that facilitate critical activities ranging from evaluating risk for internal investment decision makers to facilitating portfolio management workflows for external investing clients. The company’s platforms include Amazon Web Services (AWS), private cloud, and on-premises environments. It relies on Microsoft Azure Active Directory for user authentication and management, GitLab for source code management and CI/CD and HashiCorp’s Terraform to manageits infrastructure-as-code (IaC) through projects’ life cycles. Its development effort and continuous integration process are relatively mature for its industry. There are more than 60,000 containers and 3,000 code repositories.
Efforts to secure development
The cloud security team’s primary goal is to reduce and mitigate as much risk as possible. That means having visibility into cloud assets and workloads, identifying infrastructure vulnerabilities and misconfigurations, as well as finding code flaws that could expose the company or its clients. The team works closely with its development and DevOps counterparts to make sure the company’s software, environments, and processes meet the highest standards.
The cloud security team uses JFrog Xray, Lacework, ShiftLeft, Tenable, and Wiz across development, pre-production, and post- production to scan artifacts, builds, releases, and production environments, as well as to find code vulnerabilities, infrastructure misconfigurations, exposed secrets, and more.
The challenges:
1. Remediation
Even if they could zero in on actual root problems and owners, the actual process of fixing each issue was manual and tedious, involving researching the issue online, fixing it at the source, and ensuring it didn’t pop up again elsewhere.
2. Fidelity and context
Besides having to sort through duplicate security alerts, the team also found that many of the alerts were low-fidelity, with lots of false positives, and/or lacked the context needed to correlate between the code and the pipeline that created it, and solve the problem efficiently.
3. Ownership
Once the team collapsed alerts to their root causes, the process of finding the code owner responsible for fixing those problems was also time consuming. Adopting a modern architecture allowed the development team to decentralize, making engineers more efficient but harder to track down as they created and released their own services independently. The team cobbled together a process to track owners using spreadsheets, email, and too many web meetings and follow-up phone calls.
4. Duplication
Because there were multiple detection tools alerting on the same issues, but from a variety of angles, the majority of alerts were duplicates. Because each tool handles detections a little bit differently, it was hard to tell when they were the same, and took manual effort to find and deduplicate them. The team also found that many issues had a single root cause, so further collapsing and grouping them was onerous for engineers.
The solution: Dazz
As part of an effort to respond to the Log4j vulnerability and make cloud security more sustainable generally, the company purchased the Dazz Unified Remediation Platform.
With a simple API-based integration, the team connected Dazz to GitLab so it could discover and map all of the organization’s code-to- production development pipelines. In a single pane of glass, Dazz showed which tools were in use, automatically deduplicated alerts by more than 90% (including reducing thousands of Log4j alerts to just 62 rich-context root causes), and identified the code owner of each unique issue based based on developer’s activity in the code repository.
Beyond reducing issues and identifying code owners, the Dazz platform also auto-generated developer-friendly fixes right in the developer’s workspace. Developers can now take corrective action in a fraction of the time. Specifically, the team was able to cut mean-time-to-remediation (MTTR) by more than 90% and close the risk window of unremediated vulnerabilities from 4+ weeks to 1-2 days.
In addition to collapsing security issues and reducing MTTR, the company found several other benefits of using the Dazz platform, including more accurately assessing their IaC deployment as well as visualizing and quantifying pipeline resources.
What's next?
Next up on the company’s agenda is to work toward a more automated remediation workflow by thoroughly testing, adopting sequencing adoption, and putting protocols in place for automated roll- back and system resiliency. The team is also planning to use Dazz to help it shift remediation leftward by implementing policies to catch issues before they get too far down the pipeline.