Decreasing incident response time for OutSystems with AWS serverless technology

IT Professional Comments Off on Decreasing incident response time for OutSystems with AWS serverless technology

OutSystems’ real gain is not merely speed but the replacement of analyst-driven incident handling with a deterministic workflow that compresses repetitive triage into orchestration. The important architectural move is to treat security response as an event-driven system: a finding enters the pipeline, a ticket is opened, the relevant playbook is selected, and predefined actions execute without waiting on human coordination. That matters because response latency in security operations is usually dominated by handoffs, not deep analysis, so automation targets the right bottleneck.

The mechanism is a serverless control plane built from notification, function, and workflow services, with stepwise execution and external lookups embedded where needed. That design fits incidents that arrive unpredictably, because capacity can scale only when triggered rather than remain provisioned idle. The implementation also uses infrastructure as code and a deployment pipeline, which is operationally significant: playbooks can be revised and released consistently, not as fragile one-off scripts. Practitioners should note the architecture’s strength lies in repeatability, not novelty.

The main limitation is that automation only helps where the response logic is well understood and bounded. A playbook can gather evidence, enrich a ticket, or isolate a resource, but it still depends on reliable integrations and carefully maintained decision rules. If threat intelligence sources, internal databases, or downstream actions fail, the workflow can slow or mislead rather than accelerate response. Even so, the measured shift from minutes to seconds shows that serverless orchestration is most valuable when the incident class is predictable enough to standardize.

Leading modern application platform space OutSystems is a low-code platform that provides tools for companies to develop, deploy, and manage omnichannel enterprise applications. Security is a top priority at OutSystems. Their Security Operations Center (SOC) deals with thousands of incidents a year, each with a set of response actions that need to be executed as quickly as possible. Providing security at such large scale is a challenge, even for the most well-prepared organizations. Manual and repetitive tasks account for the majority of the response time involved in this process, and decreasing this key metric requires orchestration and automation. Security orchestration, automation, and response (SOAR) systems are designed to translate security analysts’ manual procedures into automated actions, making them faster and more scalable. In this blog post, we’ll explore how OutSystems lowered their incident response time by 99 percent by designing and deploying a custom SOAR using Serverless services on AWS.

Solution architecture

Security incidents happen with unknown frequency, making serverless services a natural fit to boost security at OutSystems because of their increased agility and capability to scale to zero. There are two ways to trigger SOAR actions in this architecture:
  1. Automatically through Security Information and Event Management (SIEM) security incident findings
  2. On-demand through chat application
Using the first method, when a security incident is detected by the SIEM, an event is published to Amazon Simple Notification Service (Amazon SNS). This triggers an AWS Lambda function that creates a ticket in an internal ticketing system. Then the Lambda Playbooks function triggers to decide which playbook to run depending on the incident details. Each playbook is a set of actions that are executed in response to a trigger. Playbooks are the key component behind automated tasks. OutSystems uses AWS Step Functions to orchestrate the actions and Lambda functions to execute them. But this solution does not exist in isolation. Depending on the playbook, Step Functions interacts with other components such as AWS Secrets Manager or external APIs. Using the second method, the on-demand trigger for OutSystems SOAR relies on a chat application. This application calls a Lambda function URL that interacts with the playbooks we just discussed. Figure 1 represents the high-level architecture of OutSystems’ custom SOAR.
Figure 1. SOAR architecture for AWS
This architecture was deployed with Infrastructure as Code (IaC) using AWS CloudFormation and AWS CodePipeline. This same IaC architecture is used when new playbooks or updates to existing ones are made. Code changes that are committed to a source control repository trigger the CodePipeline which uses AWS CodeBuild and CloudFormation change sets to deploy the updates to the affected resources.

Use cases

The use cases that OutSystems has deployed playbooks for to date include:
  • SQL injection
  • Unauthorized access to credentials
  • Issuance of new certificates
  • Login brute forces
  • Impossible travel
Let’s explore the Impossible travel use case. Impossible travel happens when a user logs in from one location, and then later logs in from a different location that would be impossible to travel between within the elapsed time. When the SIEM identifies this behavior, it triggers an alert and the following actions are performed:
  1. A ticket is created
  2. An IP address check is performed in reputation databases, such as AbuseIPDB or VirusTotal
  3. An IP address check is performed in the internal database, and the IP address is added if it is not found
  4. A search is performed for past events with the same IP address
  5. A WHOIS is performed on the IP address
  6. Recent logins of the user are identified in the SIEM, along with all related information
  7. All of this information is automatically added to the ticket. Every step listed here was previously performed manually; a task that took an average of 15 minutes. Now, the process takes just 8 seconds—a 99.1% incident response time improvement.
The following remediation actions can also be automated, along with many others: Some of these remediation actions are already in place, while others are in development.

Conclusion

At OutSystems, much like at AWS, security is considered “job zero.” It is not only important to be proactive in preventing security incidents, but when they happen, the response must be quick, effective, and as immune to human error as possible. With the implementation of this custom SOAR, OutSystems reduced the average response time to security incidents by 99%. Tasks that previously took 76 hours of analysts’ time are now accomplished automatically within 31 minutes. During the evaluation period, SOAR addressed hundreds of real-world incidents with some threat intel use cases being executed thousands of times. An architecture composed of serverless services ensures OutSystems does not pay for systems that are standing by waiting for work, and at the same time, not compromising on performance. If you are interested in this topic—how to respond to security incidents using AWS serverless services—be sure you also read the Orchestrating a security incident response with AWS Step Functions and How to get started with security response automation on AWS blog posts.
https://aws.amazon.com/blogs/architecture/decreasing-incident-response-time-for-outsystems-with-aws-serverless-technology/

Enjoyed this article? Sign up for our newsletter to receive regular insights and stay connected.