Building vs. Buying an ASPM Solution (And What We Can Learn from Raising Tamagotchis)

Originally published by Dazz.

Let’s travel back in time to the mid ‘90’s, shall we?

Tamagotchis—those adorable, electronic virtual pets—were introduced to the market in 1996 and absolutely exploded. In less than a year, Bandai had sold more than 10 million little e-critters, and to date, over 91 million units have been sold. They were the most entertaining, buzzy toy on the market for a while, but they caused a problem.

Some virtual pet owners reported having to check their pets every 20 minutes or so to maintain 100% happiness – from feeding them to playing with them to…marrying them off? (True story). Tamagotchis became so distracting and engrossing that some schools began banning them. Worst of all, kids (and adults) alike felt remorse, guilt, sadness, and a sense of failure if and when Tamagotchis were neglected and moved on to their keychain-sized mansions in the sky. What was once a fun project became a literal “burden in the hand” that siphoned away time, attention, and perhaps a level of sanity.

The allure of the Tamagotchi is clear, but in the end the conclusion is the same:

This sounded like a great idea at first, and now, not so much.

This is the sentiment many technology teams face when it comes to build vs. buy debates. Designing and building can be exciting, and may appear more cost effective for organizations with plentiful development resources. But maintaining it is not so fun—particularly when the solution isn’t productized and requires constant care and feeding to keep working.

When it comes to building an application security posture management (ASPM) solution in particular, we’ve heard a common theme: while some cybersecurity teams did make progress on visibility and prioritization with their home-grown solution, they ultimately fell short of driving a measurably improved remediation process.

So—how should you be thinking about building vs. buying an ASPM solution?

A Few Build vs. Buy Considerations

Data ingestion and quality

An ASPM platform needs to account for:

• Data heterogeneity: every tool that knows about your environment describes it slightly differently. The ability to understand the differences in the data and how to normalize it requires a lot of time and expertise across each of these solutions.
• Data quality: finding duplicates, missing values, and inconsistencies can eat up too much time. The right ASPM takes this problem off of the table.
• Data storage: how long do you need to retain data? How far do you need to look back into vulnerabilities and issues? Storage costs can add up very quickly as you begin to unify historical data.
• Data processing: high performance databases are needed to process large amounts of historical data - another significant cost to consider
• API versioning and updates: your vendors are frequently changing APIs and data schemas. As they do, your modeling and DIY solution instantly breaks.

Questions to ask yourself around data if you’re thinking of building might include:

1. How long will it take to build a framework to normalize data from disparate sources?
2. Do you have necessary expertise across security and engineering teams?
3. Once you’ve unified the data, how long will you need to test quality?
4. How much data will be processed?
5. How will you store the data?
6. How will you handle vendor API changes, and do you have the resources available to dedicate to making those adjustments?

Actioning the data to reduce remediation time

Along with data ingestion and correlation, your platform should make the data actionable with the goal of shortening the time required to resolve issues effectively. And this is where many teams hit snags.

Root cause analysis gives you the ability to drill down into vulnerabilities at their core—and if you’re unable to do this at the code level and identify the owners who committed the code, you’ll miss the mark on having an ASPM solution in the first place: faster, more efficient, more permanent issue resolution.

If you’re looking to build, think about these questions as they pertain to data analysis:

1. Can you build (and do you have the time to build) an automation to trace security alerts to their artifacts and introductory code?
2. Do you have a framework to begin the process of data normalization?

Automated remediation

According to the CSA State of Security Remediation report, about 75% of organizations have security teams spending over 20% of their time performing manual tasks when addressing security alerts despite 83% reporting they use some kind of automation in their remediation process. You need automations that work and actually reduce the amount of time and effort required to address the most critical vulnerabilities.

Whether you build or buy, your ASPM solution will need to:

• Automate code fixes when possible
• Auto-assign owners to address flagged issues
• Utilize custom logic to adjust SLA due dates and severity
• Customize conditions to mark alerts as dismissed, deprioritized, or risk accepted

Visualization and reporting

Once your data is in a reliable state and is ready for action, you’ll still need to spend time building the right reports for pertinent stakeholders.

If you’re building, consider:

1. What system will be used for reporting (and who your internal person with the knowledge of that system is)
2. Whether special coding is needed to generate reports
3. If dashboards will automatically update based on data received

Long term value and maintenance

And here’s where the Tamagatchi-esque feeding, caring, and nurturing comes in.

Even if a security team has successfully built an ASPM solution, many want to continue expanding on the capabilities they built initially to include prioritization, root-cause analysis, expanded integrations, automated workflows and visual dashboards and reports... but balancing the maintenance of the current capabilities while adding new complex capabilities is very costly and time consuming. Organizations that go down this path often end up with a less capable and far more expensive alternative with less availability and lower adoption.

Additional challenges to bear in mind include:

• Technology changes: Switching out technologies utilized across security, dev, and infrastructure teams may require rebuilding elements like automations and data models. And, as previously mentioned, when vendor APIs change, someone will need to be a vigilant resource with the time to make changes.
• Team changes: If the people who build the solution leave the company, they may take with them the tribal knowledge necessary to understand and maintain a custom solution.
• Opportunity cost: What other initiatives could team members be actively pursuing if they weren’t tethered to system maintenance for the potential Frankenstein they’ve created?

To build or to buy depends on the solution under consideration, the criticality to the team, and the budget and resources required to make it happen, and naturally, the decision will be unique to the company and the situation. Just make sure that execution risk and costs involved are carefully weighed while making the choice to ensure you’re able to keep your important ASPM initiative alive and thriving, and keep you and your stakeholders happy.

Even a Tamagotchi could tell you that.