Part 2: How Workflow Influences CI/CD Process

BlueVoyant uses a comprehensive set of processes to develop and distribute what we consider our code base. See our previous guide, CI/CD Pipelines Efficiently Delivers the most Accurate and Updated Security Content to better understand defining your code base and standard practices in CI\CD development.

Here we dive deeper into the backend and focus on the workflow and processes that govern our CI\CD pipeline process.

Workflow

Software development environments separate functions as Backend and Frontend. The Frontend accepts user interaction, translates it to a language understood by the backend. The Backend receives the Frontend input, does specific actions, and sends back to the Frontend for visualization.

Using this methodology, we have defined two workflows connected by a common language we call our BlueVoyant Information Mode: Detection Logic and Parsing Logic. Each set of logic uses the same Design -> Build -> Test -> Deploy methodology as most CI\CD Pipeline systems. This results in collections of input -> action -> output patterns which are supported across multiple teams.

Detection Logic

Content developers build and design detection logic based on known vulnerabilities and threats to the environment. These individuals are security experts and are continually staying abreast of attack techniques and common attack patterns. Their workflow is as follows:

Design - Use Cases are developed and documented into a JIRA as a story. From there specific requirement tasks are created such as identify data sets, key fields, develop query logic, etc…
Build - Content developers build the requirements query logic (either in SPL or Micosoft’s KQL) based on the BlueVoyant Information Model. This is done as a Feature Branch in GitLab. These requirements prompt the creation of additional requirements in the Parsing Logic workflow to develop Technology Add-ons by data engineers.
Test - We have two branches for testing.
- Feature Branches are merged to the Development Branch for testing via our collection of runners. Once the runners are all passed it’s deployed to our Testing environment.
- Development Branch and once all the automated runners, the detection logic is deployed to a Testing environment where data is generated and detections are tested and validated. This is where Detection Logic and Parsing Logic intersect again and cross collaboration is critical to ensure a successful product.
Deploy - Once all testing is complete, the Development Branch is merged into the Main Branch which acts as the production level code base. This branch is then deployed to all customers.

Parsing Logic

Any data engineers or SIEM experts know one of the hardest components is keeping data normalized to a common schema to ensure all detections are consistent and accurate. Our Data Engineering team has developed and streamlined workflow that takes in feedback from the Detection Logic and partnered vendors to keep parsing as up to date as possible.

Design - Data sources are priorities based on detection logic and models are validated.
Build - Data Engineers being with a Feature Branch that builds the praising logic and all required configurations based on requirements passed from the Detection Logic Workflow
Test - We have two branches for testing
- Feature Branches are merged to the Development Branch for testing via our collection of runners. Once the runners are all passed it’s deployed to our Testing environment.
- Development Branch is deployed to the Testing environment where data generated to validate key fields are parsed correctly based on versions and formats. Detection Logic is validated against the TA’s.
Deploy - Once all testing is complete, the Development Branch is merged into the Main Branch which acts as the production level code base. This branch is then deployed to all customers.

Now let’s put it all together in an example.

Use Case Example

A Standard Use Case used by many SOC’s is “Alert me when a user is added to a security enabled group where they are provided privilege escalation at the domain level.”

Phase	Final Branch	Detection Logic	Parsing Logic
Design	Feature	Content Engineer will research the different domain centric authentication systems such as Active Directory, Okta, AWS IAM, etc… These data sources are identified and key fields are determined such as an EventId or Message Signature. This is then passed to the Parsing Logic.	The Parsing Logic receives the data sources in which to target and the key fields required for normalization. They check to see if the data is available, and if so they document the requirements needed to build the parsing.
Build	Feature	Content engineer will use the BlueVoyant information model to craft a query based and check it in for Testing.	Data Engineers develop the parsing logic based on sample data and received requirements. Once complete they check it in for Testing.
Test	Development	Automation Runners validate and test the content based on predefined tasks. Once in the Development Branch a Quality Control expert runs the content against the data to validate the requirements. If bugs are identified they are brought back to the Design Phase to go back through the process.	Automation Runners validate and test the content based on predefined tasks. Once in the Development Branch a Quality Control expert runs the content against the data to validate the requirements. If bugs are identified they are brought back to the Design Phase to go back through the process.
Deploy	Main	Once all testing and Quality Control is performed and all tests are passed, the branch is merged into the Main branch for delivery to customers

Cyber Defense Platform

Part 2: How Workflow Influences CI/CD Process

Workflow

Detection Logic

Parsing Logic

Use Case Example