Examples include CreateUser and PutUserPolicy.įinally, the security team is alerted directly if the action is something that should rarely or never happen during the normal course of business, or is an obvious misconfiguration violating some security guarantee. It also serves as a gentle reminder to the engineer that certain actions have security implications and require extra thought.
#Slack duo mobile verification#
This prevents the security team from being inundated with false-positives by pushing verification of the event to the one who initiated the action. We do this in order to protect against the event of a compromised AWS user account. We notify the engineer that initiated the API call directly, and assert that they were indeed the one who performed the action. We log calls that are less worrisome than others or that may be useful later in a forensic investigation. Then, we divided the list into three severities, log, notify, and alert. So the first thing we did was to create a list of specific API calls that are relevant to the security of our accounts. We use CloudTrail to log all the AWS API calls on every account, but this is a massive firehose of data. This is the data we need to be able to detect potential security events, but efficiently and thoroughly monitoring a firehose of API calls without creating and staffing a Security Operations Center is no trivial task. AWS helpfully provides various mechanisms through which customers may observe or log these calls to gain insight on what is actually happening within their accounts. This presents an interesting security problem: given an entirely cloud-based product and nearly 200 geographically dispersed engineers, how can we monitor multiple AWS accounts to ensure that they are safe from malicious actors AND prevent well-meaning engineers from accidentally exposing sensitive data via misconfiguration?Īs you may know, every action performed in AWS generates an API call, whether it is initiated via the web console or command line tools. With 15+ AWS accounts and a large customer base, Datadog is responsible for a lot of AWS API activity.
#Slack duo mobile software#
The ProblemĪs a Software as a Service company Datadog spends a lot of time in the cloud and relies on several service providers, one of which is AWS. The pipeline sends data to a dedicated security-oriented AWS account while data collection is easily deployed to every Datadog AWS account via Terraform. To create a highly available security monitoring and alerting pipeline we used several AWS service offerings. Via a centralized security orchestration framework, we integrate with Slack, Duo and PagerDuty to notify, alert and authenticate potential security-relevant API calls.
The Datadog security team has created a robust, largely serverless security monitoring and alerting pipeline to monitor our extensive operations in the AWS cloud.
This post highlights some recent work to improve our cloud-based monitoring and alerting pipeline. Datadog maintains multiple compliance and security layers and employs a number of controls to prevent and detect unauthorized access.
0 kommentar(er)
