Skip to main content
Lantern Home

 

Splunk Lantern

Using a security data onboarding maturity model

  1. Last updated
  2. Save as PDF

A common security data workflow for any company is to recognize that they have data, ingest the data into their software, and then maybe find a use case for the data six months later. The thought process here is that all data is valuable, but in reality, this process creates more problems than it solves. This goal-less ingestion creates a data graveyard where paying to store unnecessary data not only wastes resources, but leads to data onboarding fatigue with endless updates and maintenance, rather than delivering value.

You want to have a better process for your organization. 

Solution

Follow this beginner-friendly onboarding process with achievable, simple, and repeatable goals.

Level 1: Ingested and searchable

The data is in the Splunk platform, we can find it, and the right people have access. In level one, you work on the following:

Data is searchable Relevant access controls Basic documentation

Make sure the following are correct:

  • Index
  • Sourcetype
  • _time
  • Onboarding documentation. Create a data inventory page where analysts can see the data available in the platform

Level 2: Compliance and coverage

The data is usable and has a purpose. In level two, you work on the following:

CIM compliant enough Mapped to use cases Know your "physical" coverage
  • Data at scale is expensive, so if you can't map it to a security use case, don't onboard it. You want data that is
    • Ready for audit
    • Ready for automation
    • Ready for security needs
  • Data source inventories
  • Plan to know your coverage at this point rather than have 100% coverage
    • How many of your systems are covered by the data you have?
    • How does your coverage change with new systems onboarding?
  • Have a plan to test your coverage as new systems come online 

Level 3: Assured and enriched

The data is reliable, being used to enrich other information inside your platform, and context-aware, meaning it is tailored toward your security use cases. In level three, you work on the following:

Feed service alerts Enrichment Tailored
  • Timely, useful notifications of an outage in monitoring
  • What use cases are affected by outages so you know what analytics to re-run after the outage to cover the gaps
  • Normalized assets and identities
  • Annotated with importance and ownership
  • Filter your data ingest to reduce search load on the system and use your resources more wisely

Level 4: Actively managed

The data drives strategy and action. You shouldn't be simply reacting to fulfill any service request. In level four, you work on the following:

Data source review Use case driven onboarding Automated onboarding

Threats and technologies change over time. At least once a year you should be reviewing your data onboarding with the following questions in mind:

  • Is my data still good?
  • Does it still answer my use cases?
  • Does it still provide value?
  • Security frameworks and threat modelling drive onboarding to target it toward gaps in your coverage
  • Don’t just annotate with MITRE ATT&CK; drive priorities with it
  • Monitoring patterns integrated into infrastructure as standard
  • Automated remediation

Next steps

Now that you have a solid data onboarding process to follow, watch the full .conf25, From request to response: Mastering security data onboarding. In the talk, you'll learn about specific steps you can take to mature your data onboarding practice.