Security Automation Development Lifecycle (SADLC)

Revolutionising the landscape of cybersecurity, low-code/no-code security automation platforms have emerged as a game-changing technology, enabling rapid development and deployment of security automations with unprecedented ease and accessibility.

However, it's crucial to acknowledge that behind every drag-and-drop interface and each visual block of an automation diagram, there lies a sophisticated codebase making it all possible. This underlying complexity underscores the importance of not just leveraging these tools but understanding the foundation upon which they stand.

In collaboration with my friends and fellow cybersecurity enthusiasts, and , together we share our journey and lessons learned in the evolving landscape of security automation.

Over five years ago, our first encounter with a security automation platform opened up our eyes to the potential and to the pitfalls of low-code automation. While initially promising simplicity and efficiency, the reality soon revealed that true automation extended well beyond the rudimentary tasks of enrichments, demanding a deep dive into custom coding. This pivotal experience prompted us to critically evaluate the Security Development Lifecycle (SDLC) tailored for automation: Could simply integrating custom code into a SOAR platform suffice?

The prevailing approach among many organizations is to embrace security automation or SOAR platforms for their low-code/no-code appeal, mistakenly believing this simplifies the creation of automation. This perspective is fundamentally flawed and often spells the beginning of a Security Automation Program's downfall. Security automation wields immense power, but wielding it requires responsibility and a structured approach, not just the assembly of code blocks without stringent control or processes.

A core principle that guides our framework is the understanding that automating a flawed process only amplifies its issues, leading to adverse outcomes. In contrast, applying automation to a well-structured process can produce remarkable efficiencies and enhancements. The journey to effective security automation begins not with the tools themselves but with the development of comprehensive detection use cases, incident response workflows, and operating procedures. A manual process ripe for automation is the cornerstone of any successful Security Automation Development Lifecycle.

The Power of Process-First:

Before diving into the intricacies of SADLC (Security Automation Development Lifecycle), let's rewind. Security automation thrives alongside well-developed detection use cases, incident response workflows, and operational procedures. Remember, automation amplifies. You need a robust manual process waiting for that power boost.

This blog post lays the foundation, exploring the vital elements of a successful Security Automation Program. In the next one, we'll delve deeper into how security automations seamlessly integrate with your detection rule development and security operations processes. Don't miss it!

Introducing the Security Automation Development Lifecycle (SADLC)

SADLC differs from traditional SDLC by blending software development with DevOps practices, tailored specifically for security automation with a simplified set of steps.

The SADLC Steps:

1. Gathering Requirements and Analysis

2. Automation Development

3. Testing

4. Deployment

5. Maintenance

The process begins with Detection Use-case development. Once the detection rule is analyzed and tested, we develop operating procedures for managing specific alerts, covering essential IR steps: Analysis, Containment, Eradication, and Recovery.

Tools like Scribe can simplify the documentation of these manual processes, a technique I plan to explore in a future guide.

With the groundwork laid, we embark on the SADLC journey:

1. Requirements and Analysis

In this crucial phase, we not only gather requirements but also analyze the logic behind the automation request, taking into account potential pitfalls that could lead to initial errors and jeopardize trust in the automation. Addressing these concerns upfront is critical for a smooth implementation and long-term success.

Understanding Stakeholder Concerns:

Before diving into specifics, it's essential to acknowledge that initial errors in automation flows can create friction within the organization, impacting various stakeholders:

• Expected Inputs and Outputs: Precision in defining what goes into and comes out of the automation process cannot be overstated. Questions regarding the reliability of input data, potential format variations, and their frequency are essential to ensure the automation's effectiveness and reliability. Initial distrust from end-users often originates from inconsistencies or inaccuracies in automation outputs. By rigorously analyzing input and output requirements, you can preemptively address these trust issues.

• Team managers and organizational leaders might harbor skepticism about automation's efficiency and benefits. We'll address their specific concerns by providing tailored examples and data demonstrating automation's positive impact in similar scenarios.

• Detection Rule Efficacy: A thorough understanding of how detection rules operate and whether all necessary data for creating an automated workflow are available is vital. Considerations about the volume of alerts and the practicality of responses, especially in high-volume scenarios, are critical. This step helps in avoiding automation solutions that, while theoretically sound, may lead to operational inefficiencies or unintended consequences, further fueling skepticism among organizational leaders and end-users.

• Automation engineers might feel frustrated if their work gets canceled or significantly altered due to unclear requirements. We'll ensure they're involved in the early stages to understand their expertise and potential challenges, leading to well-defined requirements that minimize late-stage changes.

Tailoring Requirements for Success:

By understanding these potential concerns, we can tailor our requirements gathering and analysis to mitigate them:

• What type of automation are you building? We'll consider the complexity (enrichment, response, or utility) and potential impact on various users, ensuring the level of accuracy and robustness aligns with expectations.

• What are the expected inputs and outputs from the automation? Is the input data formatting reliable? We'll go beyond simply identifying data sources and delve into potential variations and inconsistencies in formatting. This will inform data validation processes and ensure reliable automation output, fostering trust among end-users.

• How does the detection rule work? Do you have all the necessary data needed to create an automated workflow? What is the expected volume of alerts triggered? We'll carefully analyze the detection logic and data availability to avoid creating automation that triggers on invalid data or overwhelms systems with excessive alerts.

• Do you possess all the necessary integrations to facilitate the automated workflow? This includes integrations for data input, processing (enrichment), and output. The availability of necessary integrations and the adequacy of actions/API calls are foundational to the development of a seamless automated workflow. However, possessing these integrations is only part of the equation. Ensuring that you have the appropriate levels of access for your technical or service accounts is equally critical. Lack of necessary permissions or functionalities can lead to automation failures, contributing to the frustration experienced by automation engineers and diminishing faith in the automation’s value within the organization.

Building a Foundation for Trust and Success:

By dedicating this initial phase to thorough requirements gathering and analysis, we lay a solid foundation for successful automation implementation. Addressing potential concerns from all stakeholders, defining clear expectations, and ensuring data reliability contribute to building trust in the automation. This, in turn, fosters wider adoption and maximizes the benefits of automation within your organization.

2. Development

This phase involves either developing new integrations or expanding the actions on existing ones. After this, you proceed with the development of the automated workflow.

Recommendations for this phase include:

• Ensure you have both development and staging environments to test the automation.

• Proper versioning of the automations developed is essential, as many SOAR platforms may save the automation without proper versioning or an audit trail.

• Implement the four-eye principle: once the automated workflow is developed, having it reviewed by someone else before production deployment is best. Many SOAR/Security Automation platforms lack this capability, so take this into account when selecting your platform.

• (Custom) code review: if the automation contains custom code added to the workflow, ensure that it follows best practice and its functionality and risks are assessed.

• It's good practice to store your code in a code repository (outside of your automation platform). This ensures that if you need to share a piece of code with another stakeholder, you won't need to grant them access to your Security Automation platform. This is particularly important if your platform does not offer an effective way to track versioning or code differences. Additionally, in case of issues with your automation platform, you have a backup of your workflows.

3. Testing

Once the automation is ready, we move on to testing. It's recommended to start with simulated events in the development/staging environment and then conduct a dry run in production. This allows the automation to run in production for a short period while you closely monitor the output.

It is a good opportunity to also inspect what potentially unexpected impact your automation can have on third party integrated apps (licensing, computing, costs) which are called during execution.

4. Deployment

At this stage, we activate the automation in production. It's crucial to have proper technical documentation for each automated workflow. Ideally, one should have a two-step approval process for deploying. The person that deploys the code should not be able to do so without the approval of another engineer. This will ensure that in case one of the engineers is compromised, then new flows with potential disruptive impact does not make its way into production. Visual diagrams of the process can be extremely helpful, as well as well-documented error handling.

5. Maintenance/Reporting

With the automated workflow operational, ensure that each automation has appropriate reporting mechanisms. Two key areas to consider are:

• Health checks: Does the automation run as expected? Ideally one should have two methods to monitor for all failures in the flows:

  • Generate timely reports for each of the flows and monitor for unseen events - this can help in identifying issues with the platform, with connections or within the workflows themselves;

  • For any communication end-user-facing - one should take into consideration leaving an easy method of contact so that users are encouraged to contact at the first time of an issue. Your end-users are your best monitors for issues within your workflows.

• Performance: How well is the automation performing? This evaluation is all about Return on Investment (ROI). Some of the SOAR platforms provide cost reduction mechanisms based on the hours saved. It is crucial to remember that once the automation has been deployed, the process is not ended and from that time saved, one must subtract the number of hours required for monitoring and maintenance.

Conclusion

Implementing SADLC from the start sets your program on the path to success. Don't delay – the longer you wait, the more entangled you become in reactive, manual processes. Remember, automation amplifies: it amplifies good processes, but also magnifies flawed ones. Embrace SADLC and unlock the true potential of security automation – build a program that delivers results, not regret.

Join the Movement:

In our next blog post, we'll delve deeper into the practical application of SADLC, guiding you through its stages and best practices. We'll also explore how security automation seamlessly integrates with your detection rule development and security operations processes, solidifying your cybersecurity posture. Don't miss it!