Take into account the following inquiries regarding the conventional method of identifying and resolving security errors in numerous enterprises at present:
- How does the process of detecting security errors happen?
- When and how often does it occur?
- Who typically addresses these security concerns?
- How do we go about resolving these problems?
- Typically, what is the average duration for resolving the security concerns?
- What would happen if security concerns are never identified or addressed?
Passive logging and monitoring are commonly utilized in various businesses to detect security issues. This approach depends on human intervention to identify alerts and take necessary actions. Such alerts could pertain to issues like unprotected data, failure to activate multi-factor authentication during user creation, failure to activate a security service, or other instances of non-compliant resources.
Although the detection of issues can occur almost immediately, it does not guarantee that an engineer will promptly notice or address the problem. This is because these systems usually depend on humans or engineers to identify the alerts and prioritize fixing the errors. The alerts, which are often consolidated into a Security Information & Event Management system, might initially be noticed by the Security Operations Center (SOC) or other team members. Once an alert is spotted, it may be assigned a priority and placed in a queue for resolution through a ticketing system.
The resolution of the problem is frequently handled using the ticketing systems mentioned earlier. The engineers will manually address the issue or implement a code solution once it has been identified, and then close the ticket. Often, these fixes are temporary and not formally integrated into the system to prevent the problem from recurring.
Detecting a security anomaly in many organizations often requires significant time, whether it be hours, days, or even longer. Furthermore, resolving the issue could extend for days or even weeks. Unfortunately, in some instances, the problem may not be identified or resolved at all.
In the upcoming blog post, I will outline a method to address the issues I previously discussed. The proposed solution utilizes event-driven architectures to automate security response on a large scale.
DevSecOps
Before delving into event-driven architectures for automating security responses, take a moment to ponder a conventional development process. In this process, software is built, tested, and then released to customers. However, on traditional teams, obtaining feedback from customers can be a sluggish and laborious task. This slow feedback loop is often due to barriers such as organizational, process, cultural, and tooling obstacles that impede the flow of feedback. This delay is not necessarily intentional, but rather a result of the organizational inertia that has accumulated over time, causing a lack of emphasis on expediting effective feedback between customers and developers.
By efficiently implementing DevOps principles, you can shorten the duration in which developers receive feedback from customers and improve the standard by dismantling barriers within the organization. This is accomplished by treating all aspects as code and establishing comprehensive automated workflows that handle the construction, testing, deployment, and release of software when necessary for business purposes. When developers receive consistent and valuable feedback from customers, they are more inclined to develop functionalities that align with customer requirements.
The speed at which you can complete this feedback loop affects your ability to respond to customers and your level of innovation. Customers only see value when you are actively working on creating high-quality features they desire. In essence, DevOps involves making organizational, procedural, cultural, or technological changes to enhance the speed and efficiency of these feedback loops between customers and developers.
DevSecOps aims to expedite these feedback loops in a secure manner, minimizing risks and enhancing the quality and assurance. It is important to consider that the prompt delivery of feedback regarding quality is crucial for developing improved and safer products for customers.
Event-Driven Architectures
The concept of event-driven architecture consists of three components: an event producer, an event router, and an event consumer. In terms of security response, multiple sources such as logs, threat analysis, inspections, and configuration changes can act as event producers. These producers generate events, commonly represented in JSON format. Numerous events, potentially in the thousands or millions, are asynchronously sent to an event router. This router takes in, filters, and directs the events to the appropriate consumers. The events received by the event router trigger various actions, such as executing code that automatically resolves noncompliant resources or initiating a remediation workflow.
Security detection and remediation that is based on events is implemented on the Amazon Web Services (AWS) platform.
When it comes to automating security response on AWS, a security event occurs when there is a change. For instance, if there is a configuration change detected by AWS Config, it will initiate AWS Config Rules. The events from these configuration rules are then transmitted to an event router called Amazon EventBridge Rules. This router forwards the event to a responsive control like AWS Lambda, AWS Systems Manager, or AWS Step Functions. These responsive controls carry out the automated action needed to resolve the issue. By following this process, you can swiftly move from identifying the problem to resolving it within a few minutes.
Amazon EventBridge offers instant access to data modifications in AWS services and other origins. Users have the flexibility to select event sources and targets according to event patterns. EventBridge seamlessly integrates with a wide range of AWS services, allowing for analysis of more than 40 incoming event types. Additionally, EventBridge enables the execution of up to five targets for each event rule. Presently, users have the option to execute 15 different target types.
By utilizing AWS Lambda, you can generate functions that execute your code when specific events occur. The management of the necessary computing resources, including servers and their settings, is automatically handled by Lambda. In a given scenario, Lambda is employed to identify whether a recently created S3 bucket has encryption activated through Config Rules. If encryption is not enabled, a Lambda function is triggered to enable encryption for that particular S3 bucket.
Other Target Type Examples
AWS Systems Manager gives you the ability to see and manage your infrastructure on AWS. When it comes to automating security response, you can create automated actions using Systems Manager Documents to fix any security issues.
AWS Step Functions is a tool that enables users to coordinate and manage AWS Lambda functions, various AWS services, and manual activities within a unified workflow. It can be likened to a service that offers a “State Machine as a Service.” An instance where Step Functions can be employed is in monitoring and resolving a security breach, which involves executing both automated and manual actions. This may entail activities such as updating a security ticket, coding, or modifying configurations. By utilizing Step Functions, users can create a streamlined and holistic workflow that automates the entire process until the security incident is successfully addressed.
Continuous Security on AWS
Continuous Delivery allows teams to roll out new updates whenever there is a business requirement. By automating the build, test, deployment, and release processes, Continuous Delivery applies to various changes like applications, configurations, infrastructure, data, and more. Continuous Security follows the same approach, applying automation to security tests, analysis, and the provision of security services.
AWS CloudFormation allows you to provision various resources for your deployment pipeline using code. This includes AWS CodePipeline, which helps in managing release workflows for continuous delivery, and AWS CodeBuild, which helps in performing build and test actions. To illustrate, Figure 6 provides an example of a CodePipeline deployment pipeline.
As a component of the deployment process, it initiates a distinct CloudFormation stack which sets up all the services required for the security response automation system. This stack is specified in a CloudFormation template, allowing it to be utilized, verified, and modified as needed.
Regarding event-driven security, this particular pipeline would set up the necessary AWS security measures and associated services like EventBridge, Config Rules, and Lambda functions responsible for detecting and resolving issues.
After being defined, CodePipeline retrieves the most recent changes from your source control repository and initiates a process that creates Lambda functions. It also performs pre-emptive evaluations on your CloudFormation templates, such as checking for hidden codes. These evaluations can be conducted prior to launching the infrastructure itself. This pipeline can be utilized to set up other security services, like Amazon GuardDuty or Amazon Macie, AWS Config, AWS Systems Manager, or AWS Step Functions. You can establish all of these services as code and deploy them as part of your pipeline. Afterwards, you are able to conduct production tests and canaries once they have been deployed.
Event-Driven Security Cultural Practices
It is important to have discussions among different teams within your organization before implementing this kind of automation. This is particularly important for enterprises. When implemented effectively, everyone is involved in implementing security measures through coding or event-based security methods, on a large scale. Below, I have provided a list of important practices to keep in mind when using security as code.
- Standardize everything, including security measures, allowing engineers to replicate systems and address issues promptly.
- Make a habit of regularly committing to one reliable source of information – This practice allows engineers to rebuild systems with a simple instruction and reduces the need for intricate problem-solving.
- There is one straightforward way to bring products to market successfully: minimize the chances of creating insecure code. To achieve this, it is essential to receive feedback as early as possible during the development process. Additionally, it is crucial to minimize assumptions and gather consistent feedback from end users.
- When there is a failure, the main focus should be on resolving the issue promptly. This can be achieved by simplifying processes and minimizing the financial impact of failures. It is also important to take measures to prevent any obstacles or delays.
- It is important for all individuals to take responsibility for security. Share best practices among different teams and empower application teams to incorporate security measures, while ensuring that there is a set of rules and guidelines that apply to the entire organization.
- Security tests conducted in pipelines aim to detect and address potential security concerns at an early stage of the development process.
- Least privilege means giving only the essential permissions needed to carry out a specific task.
- Defense in depth is the application of multiple levels of security measures implemented as programming code.
- Improve decision-making by receiving clear and immediate feedback.
- Self-service for all needs – minimize the delays and annoyance experienced by engineers.
No comment