Onboarding useable and purposeful security data

Step 1: Ingest request intake

This is a standard first step at any organization, regardless of maturity level. Keep the following in mind for your request process:

• Keep the request form simple.
• Document and track every communication.
• Get a business justification.
• Prioritize the request. After reading the business justification, your request prioritization level as the platform owner might not be the same as that of the data owner.
• Respond. 

Step 2: Onboarding questionnaire interviews

During this stage, you want to identify what you are onboarding and why, so that you can prove the value and prioritize the request appropriately. 

• A call often works better than a form because people tend to give short, incomplete answers to forms so you'll often need to follow up with a call anyway.
• Focus your questions. The following are examples of what answers you should be seeking:
  • What am I onboarding and why? Background and end state, what's been done already, standard or bespoke monitoring, is this a response to a specific threat or incident?
  • What security effects do I need to achieve? How would you like us to respond to an alert/incident on your service?
  • What is the one event that must be actioned immediately? What about this service would do the most damage if compromised? Which events should get people out of bed? 
  • Admin questions
    • People: Who is the main contact? Service manager? Stakeholders? Responders?
    • Timeline: Date onboarding is required by? Why are these times important?
    • Access: Who can and cannot access this data? 
  • Technical questions
    • Ask for service decompositions, high level designs, and network diagrams
    • Describe existing monitoring, data aggregation options
    • At a high level, identify preference, patterns, and quick wins
    • Scale/volume: GB/day, EPS, number of devices?
    • Planned changes, growth, projects
    • How are they expecting to send data
• Administrative details are as important as technical
• Understand what’s important and why
• What are their expectations and desired end state
• Keep “solutionizing” to a minimum

Step 3: Threat modeling

At this stage, you begin to engage other functions around a security service, such as threat modeling. This helps you design and develop use cases to make sure that the data you onboard provides value.

• There are hundreds of models, so be sure to pick a suitable one for you. Here is an example from the National Cyber Security Centre.
• Use models to generate use cases (detections) and responses (who to involve and what actions to take) by decomposing each service.
• Document appropriately.
• If in doubt, use Standard Monitoring: Authentication, Network Traffic, Change and Endpoint Protection. 

Step 4: Data source evaluation

For each data source identified during the threat modeling stage, you will need to gather the following information:

• Technology and type and format
• Get the facts
• Ingestion method/pattern (Whether an add-on exists or you need to build one)
• Normalization effort

Here is an example evaluation:

Step 5: Test, adjust, and promote

In an ideal world, you would have a test environment where you can test the ingestion process end-to-end, including the detections and responses.

• Test
  • Data and compliance
  • Role-based access control
  • Documentation, make a checklist, including elements such as the following:
    • Onboarding sheet
    • Linked to use cases
    • CIM compliant enough
    • RBAC
    • Known coverage
    • Analysis briefed/trained
    • Tested in pre-prod
    • Risk owner happy
    • Sent to live
    • Onboarding complete
  • Detections, use cases and incident response
• Promote to live
  • Analyst walkthroughs  - take them through the new data source, what use cases it's applicable to, any baseline monitoring you have
  • Add to lifecycle review