Build vs Buy: Considerations for Remediation Platforms

Considerations for fixing vulnerabilities efficiently - and cost effectively

Introduction

For some companies, there are reasons why on the surface it makes sense to build a custom remediation platform. Every company has different vulnerability data sources, prioritization logic, and remediation workflows. If you have in-house development resources and experts who understand the code to cloud pathway and all security detection sources, why not build a platform to harness it all together?

We’ve spoken to many large organizations with plentiful development resources that have tried to build their own remediation platform. While some have made marginal gains in improved visibility and prioritization, most have fallen short of driving a measurably improved remediation process.

In this guide, we’ll break down the considerations to weigh if you’re thinking about building a remediation platform rather than buying one.

Working with the Data

A remediation platform needs to ingest data from numerous sources, including security detection tools, cloud infrastructure, development pipelines, source code, and more. This means that a platform needs to account for:

Data Heterogeneity

Disparate solutions often generate data in different formats, structures, and schemas.

Data Quality

Each solution may have its own data quality issues, such as missing values, duplicates, or inconsistencies. When aggregating data, these issues can compound and lead to inaccurate or unreliable results.

Data Processing

Disparate solutions may generate large volumes of data at varying rates. Handling high data volumes and fast data velocity requires robust infrastructure and data processing capabilities.

API Versioning and Updates

Software and system updates can lead to changes in data formats or APIs, which can disrupt data aggregation efforts. Maintaining compatibility with evolving systems can be a constant challenge.

{{bvb-1="/whitepaper-banners"}}

Build considerations

• How long will it take to build a framework to normalize data from disparate sources? Do you have the expertise needed across Sec and Dev teams?
• How long will you need to test data quality once you’ve unified the data?
• How much data will be processed and how will you store it?
• How will you deal with vendor API changes to maintain data schemas and normalization? Do you have a headcount dedicated to this?

Analyzing the Data

A remediation platform should not only ingest and correlate data from disparate sources, it should also make data as actionable as possible to enable processes to shorten the time needed to resolve issues. This means remediation platforms should automatically identify the root causes of security issues and highlight the most effective fixes to make. A custom-built remediation platform will need to account for:

Root Cause Analysis

The ability to automatically pinpoint the root cause of vulnerabilities, down to the code repos, lines of code, and associated developers drastically reduces the time needed to remediate. Root cause analysis needs to take into account different technologies, including container orchestration, infrastructure as code (IaC), and machine image creation.

{{bvb-2="/whitepaper-banners"}}

Remediation Owners

How do you tie any root cause back to the owner (developer/team-lead/infrastructure owner) who is the best person to make the fix? Is this something you can automate?

Data Normalization and Deduplication

How can you normalize and deduplicate data from disparate sources to make it easy to search security alerts across any detection sources, vulnerabilities, infrastructure and resources, and more

Build considerations

• Can you build automation that traces security alerts to the artifacts and code that introduces them? How much time will you need to build and test the efficacy of this automation?
• Do you have a framework to begin the process of data normalization already built? If not, how long will it take to build?

Automating Remediation Actions

Once you’ve found the most pressing risks, how can you automate the remediation process? Automations are key to reducing manual work, enriching data to make it actionable, and making the fix faster. A remediation platform should:

Automate code fixes when possible

When a viable code fix is discovered, a remediation platform should be able to raise a pull request and integrate it into existing CI/CD pipelines to test and deploy it.

Auto assign owners to detected issues

Using custom logic, you should be able to automatically assign future security detections to particular people. For instance, you may assign alerts associated with a certain cloud account to a specific DevOps engineer who owns it. Or, you may assign alerts for a specific code repository to a specific leader on the AppDev team.

Adjust SLA due dates and severity according to custom logic

After you have agreed upon remediation SLAs across all teams and stakeholders, a platform should be able to standardize SLA tracking across all detection tools

Dismiss, deprioritize, and risk accept findings according to custom logic

A remediation platform should allow you to customize conditions for which to mark certain alerts as dismissed, deprioritized, or risk accepted

{{bvb-3="/whitepaper-banners"}}

Build considerations

• How do you plan to integrate fixes at the root cause level into your CI/CD pipeline?
• How long will it take to build these automated actions and API calls? How easy will they be to maintain and update?
• How will you automate SLA due date creation, severity ratings, and security issue status across numerous tools?
• How long will it take to build automation for severity, due date, and more? Will you be able to automatically dismiss, deprioritize, and risk-accept findings across all detection tools?

Visualization and Reporting

If you’re going to invest the time in getting that data to be actionable and building automation on top of it, then you’ll also need to build visualizations for reporting purposes.

If you’re already using business intelligence tools, it’s likely you’re already feeding various data feeds to a custom dashboard that tracks remediation efforts. Once you’ve gotten data into an actionable and reliable state, you’ll still need to spend the time building the right reports.

Build considerations

• What system will be used for reporting? Who has access to and knowledge of this reporting system?
• Is any coding needed to generate a new report or are there no-code report creation options?
• Will dashboards update dynamically based on the data?

Time to Value

We’ve outlined many build considerations, which need to be answered to understand the time to value for remediation. What do we mean by value? Value will differ from your objectives, but we typically find that companies realize value when:

• All security findings are unified, correlated, and contextualized in one console
• The root cause of security issues begins to be automatically detected
• Workstreams and automation are in place to make fixes faster, with a path to a measurable reduction in the meantime to remediate (MTTR)

With all the considerations outlined, building a remediation solution from scratch can take more time than procuring existing software. Timing aside, the risk of failure is also high: the solution you build may not turn out to reliably and consistently fulfill your requirements. 

Long-term Value & Solution Maintenance

Beyond time to value, a successful custom-built remediation solution may be harder to maintain long term for a multitude of reasons.

Technology Changes

As you switch out technologies across used security, development, and infrastructure teams, you may need to rebuild data models, reports, and automation. Moreover, even if you stick with the same solutions, vendor APIs change so frequently that someone will need to have the capacity dedicated to making changes.

People Risk

What happens if your experts who created the solution leave? How easy will it be to maintain if new employees need to work on the custom-built solution?

Opportunity Cost

How many security and development resources would need to be involved in maintaining the solution? What other business initiatives could they support if they were offloaded from system maintenance?

Conclusion

Your company may have more developers and capacity to build custom solutions than most. However, the execution risk and costs involved in building your own remediation solution are considerable.

If you’re weighing this decision and would like to understand how Dazz approaches remediation, reach out to us. We’d be happy to help in any way we can.