Content Engineering
Contents
Objective
Kate Brew from Alien Vault makes an observation that resonates with this author, stating:
- "If you Google “SIEM Content Engineer,” “SIEM Threat Content Engineer,” or “SIEM Content Developer,” you will see a bunch of ads, job listings and very little other content." (Kate Brew, 2018)
This author argues that Content Engineering is not a new concept, just a new role being defined. The objective of this is to create rules, use cases, tool sets and other needs which deliver "content" to the Security Analysts. It helps to maximize the value of the tools in the SOC while reducing risk dynamically.
Why is this different from a Security Engineer? It occurs to me that this is more specialized though the industry may prove that to be incorrect. Some organizations define a Security Engineer as those deploying new tools versus utilizing those tools.
Process
Content Engineering has several processes which can be effective. This is by no means an exhaustive list:
- Request Submission - A customer (e.g. Security Operations analyst) requests new content be developed
- Portfolio Prioritization - Content Engineers will have a series of requests. Ideally, those are compiled into a records system and prioritized.
- Implementation - See
- Quality Control Process
Tooling
The tooling here can be quite varied for multiple reasons. However, some considerations are helpful:
- Training in the tool where the content must be deployed
- A test environment, regression methods or other Quality Contol mechanisms
- Development environment & software - to develop scripts, API work, automation or other developments
- Data Analysis tools
Ticketing
Requests for content development must be recorded, prioritized and then implemented. Consider including in the captured data elements:
- Requesting team or source - this helps identify if any specific teams are the bulk of requests and what Staffinglevel is needed to meet their needs.
- Date Request was Made and Date Request was completed - This helps identify velocity
- Reason or Cause for Implementation - Tracks sources like Threat Intelligence, Risk Management, GRC or Compliance as sources of content needs
- Active Time to Implement (ATI) - How much time did the Content Engineer actually spend working on the request.
- Risk level - This supports Reporting and can be qualitative or quantitative. Implement that based on maturity and level of effort in iterations.
- Tool where the content was implemented - This tracks what tools are providing dynamic value.
Reporting
- Content Requests Fulfilled - Tracks velocity and performance
- Average Active Time to Implement (ATI) - This helps to predict velocity going forward based on volume
- Risk Reduction - Use the Risk Levels to identify how much risk was reduced.
- Tool Used for Deployment - Identifies the dynamic tools which the organization is using.
Staffing
Decide if Content Engineering should be a
- Partial FTE - A Security Operations associate is assigned this responsibility as part of their requirements. Check into Context Switching and be aware that they will need ramp up and ramp down time which will impact velocity based on how many different responsibilities they have.
- A full FTE - If there is a high volume of requests or the organization is just starting this up, a full time person on Content Development may be ideal.
- Distributed Model - Other teams may own the controls and countermeasures. In this model, the SOC is making requests to them to implement.
Budgeting
- VMs do help with implementation, however consider the purchase of a testing environment.
- Deploying a test environment while the team is fully engaged may require contractors to supplement bandwidth
- Some tools are commercially developed and have corresponding support. This may be an option to explore.
- Reporting will help identify what value the organization is receiving from these investments.
Communications
Content Engineers need to either generate or receive what content should be developed. Interfacing with other teams can be a good input and those communication channels, which are highly specific to the organizational structure and RACI, can be opened up:
- Threat Intelligence teams
- Security Operations Analysts
- Governance, Risk and Compliance (GRC)
- Data Governance
Documentation
- Process Documentation
- Prioritization methodology
- System architecture
- Testing Process & Procedure
- Test environment
Lessons Learned | Pain Points
- Assigning Content Engineering responsibilities to a SOC analyst can be appropriate if they have the right skill set, resources and focus time
- Training in a tool can be very valuable in the long run
Citations
Kate Brew. 2018. SIEM Content Engineer - Why Is It a “Thing”?. Retrieved from https://www.alienvault.com/blogs/security-essentials/siem-content-engineer-why-is-it-a-thing
