AWS | Techlist.io

datadogNov 1, 20182 min readCurated summary

Improving trust with Datadog Log Management

Datadog handles hundreds of thousands of emails daily and uses Amazon SES for critical messages such as password resets. Because SES and CloudWatch did not provide sufficiently accessible, support-friendly event data, Datadog built a serverless pipeline that forwards SES events to Datadog Log Management. This provides low-maintenance delivery infrastructure, searchable email metrics, and monitoring for failures. ## Exporting Amazon SES Events - SES configuration sets define which email events to capture: - Send - Reject - Bounce - Complaint - Delivery - Open - Click - Events are published to an Amazon SNS topic. - SNS invokes an AWS Lambda function for every event. - The Lambda forwards the event to Datadog Logs using the Datadog API key. - Terraform provisions the SNS topic, SES configuration set, event destination, IAM role, and Lambda function. - The example uses Python 2.7 and stores the API key as a Lambda environment variable; production systems should encrypt the key. - This architecture avoids maintaining a custom email service while preserving visibility into email processing. ## Making SES Events Searchable in Datadog - SES events arrive in Datadog as JSON. - Datadog’s existing AWS integration pipeline processes the logs automatically. - Important fields can be converted into facets directly from a log entry. - Datadog uses fields such as the email event type and subject to quickly search for specific password reset activity. ## Monitoring and Operational Benefits - Support teams can verify whether a recipient received or interacted with a password reset email. - The entire delivery and logging pipeline is serverless and requires minimal maintenance. - Monitors can be configured on the logs to alert normal escalation channels when any part of the pipeline fails. - The solution combines the reliability of Amazon SES with Datadog’s observability and search capabilities. Overall, routing SES events through SNS and Lambda into Datadog Log Management is a practical way to create a trusted, observable password-reset email system without operating a separate mail infrastructure.

Read original

AWS Database Design Datadog Log Management+4

datadogSep 20, 20173 min readCurated summary

Secure (and usable) multi-AWS account IAM setup

Managing multiple AWS accounts increases billing, compliance, and operational complexity, but it provides valuable security boundaries between workloads. The post proposes a centralized IAM design in which users exist in only one account, receive minimal default permissions, and temporarily assume narrowly scoped roles in target accounts. MFA and short-lived credentials further limit the impact of compromised credentials, although the approach is constrained to roughly ten accounts by IAM group limitations. ## Why Use Multiple AWS Accounts? - Accounts isolate workloads at several levels: - **Network:** VPCs are separate unless explicitly peered. - **API access:** A compromised account cannot access others without delegated roles. - **Compute and billing:** Per-account spending limits, billing alerts, and CloudTrail monitoring can contain or reveal abuse such as cryptocurrency mining. - The main challenge is gaining these security benefits without creating unmanageable administrative overhead. - The proposed pattern is better suited to production environments than development setups where every developer may have a separate account. - Current IAM group limitations restrict the design to approximately ten accounts. ## Centralized IAM User Management - Each IAM user should exist in only one account. - Centralizing users makes onboarding, offboarding, password policies, and auditing easier. - Other accounts can be monitored for unexpected IAM user creation, which should generally never occur. - Users receive only the permissions needed to manage their own authentication settings. ## Why Use IAM Instead of SSO? - SSO would centralize authentication through an existing identity provider. - However, the post argues that SSO can limit the ability to apply MFA protection precisely to privileged operations. - Since MFA is central to the proposed privilege-escalation model, standalone IAM users are retained despite their administrative drawbacks. ## Minimal Default Permissions By default, users should be able to: - View their own IAM record. - Change their console password. - Create, update, or delete their own API credentials. - Create their own MFA device. They should have no meaningful access to other AWS APIs. This limits the blast radius of stolen usernames, passwords, or API keys: without the user’s MFA device, an attacker can generally do little more than inspect the compromised user’s record. ## Temporary Privilege Through Role Assumption - Users perform privileged work by calling `sts:AssumeRole` in the target account. - Assuming a role provides temporary credentials and a session token. - Credentials have a short lifetime, normally no more than one hour by default. - This resembles the Unix `sudo` model: users begin with restricted permissions and explicitly elevate privileges when necessary. ## MFA-Protected Privilege Escalation A role assumption should succeed only when both conditions are met: - The user has an active MFA device and can authenticate with it. - The user belongs to a group authorized to assume the requested role. MFA does not eliminate compromise risk, but it makes stolen API credentials substantially less useful and limits the damage they can cause without the corresponding MFA device. ## Privileges Grouped by Operational Topic - Administrative capabilities are divided into roles based on responsibility rather than assigning broad account-wide permissions. - Example roles include: - A **VPC role** for network configuration. - An **EC2 role** for instance management. - An **S3 role** for storage administration. - Users can then be mapped to groups and roles according to their job responsibilities, making permissions easier to understand and maintain. ## Practical Recommendation Use multiple AWS accounts as deliberate security boundaries, but centralize IAM users, keep their baseline permissions minimal, require MFA for role assumption, and grant temporary, topic-specific roles. This provides strong isolation while keeping privilege management manageable, particularly for production environments with a limited number of accounts.

Read original

AWS Api Security Iam Mfa+4

datadogAug 15, 20173 min readCurated summary

Improving cloud security visibility with ChatOps

Datadog built a largely serverless AWS security monitoring pipeline to detect suspicious API activity across more than 15 AWS accounts. Rather than process every CloudTrail event equally, it categorizes actions as log, notify, or alert, reducing false positives while preserving broad visibility. The system centralizes events, batches activity, and uses automated workflows to verify engineers’ actions or escalate potential compromises. ## The Security Monitoring Challenge - Datadog manages extensive AWS infrastructure across multiple accounts and nearly 200 geographically distributed engineers. - Every console or CLI operation generates an AWS API call, creating a high-volume CloudTrail data stream. - The monitoring system must detect malicious activity while also catching accidental exposure caused by configuration mistakes. - Processing every event manually would require an expensive, constantly staffed Security Operations Center. ## Prioritizing Relevant API Calls - Datadog maintains a focused list of security-relevant AWS API calls and assigns each to one of three categories: - **Log:** Lower-risk events retained for investigation, such as `CreateGroup` or `UpdateUser`. - **Notify:** Events that require the initiating engineer to confirm their identity and intent, such as `CreateUser` or `PutUserPolicy`. - **Alert:** Rare, dangerous, or clearly misconfigured actions sent directly to the security team. - A representative alert is `AuthorizeSecurityGroupIngress` with `0.0.0.0/0`, which exposes an EC2 security group to the entire Internet. - User verification reduces false positives and helps identify compromised AWS credentials. ## Cross-Account Event Pipeline - CloudTrail records API activity in each AWS account. - CloudWatch Event Rules filter for the selected API calls and publish matching events to SNS. - SNS forwards events across accounts to an SQS queue in a dedicated security AWS account. - Centralization is necessary because CloudWatch could not directly send events cross-account to SQS. - The queue also supports batching, which is important when Terraform generates many AWS changes in a short period. - A CloudWatch rule triggers a Lambda function every two minutes to drain the SQS queue and forward events to the security orchestration layer. ## Automated Decision-Making with Komand - Datadog uses Komand, a security orchestration and automation platform, to construct workflows from built-in and custom plugins. - A custom decision plugin evaluates: - The calling user - The event’s age - Request parameters and their content - Other contextual details - Based on the analysis, the workflow silently logs the event, notifies the engineer, or pages the security team through PagerDuty. ## Engineer Verification and Escalation - For notification-level events, the engineer receives an interactive Slack message containing API call details. - Confirming the action triggers a Duo push for second-factor identity verification. - If the engineer denies the action or fails to respond promptly, the workflow alerts the security team. - Komand coordinates the Slack, Duo, PagerDuty, and custom integration logic in one centralized workflow. ## Visibility and Continuous Improvement - Every workflow execution is logged and sent to Elasticsearch. - The resulting data helps Datadog visualize security events, measure detection effectiveness, identify behavioral trends, and improve alerting. - The pipeline is designed to provide actionable security intelligence without overwhelming engineers or security personnel. Datadog’s approach combines selective event filtering, cross-account centralization, batching, and automated identity verification. Organizations facing similar AWS-scale monitoring challenges can use the same principles to reduce alert fatigue while maintaining strong detection and response capabilities.

Read original

AWS Slack Terraform Security Monitoring+4

figmaJun 19, 20172 min readCurated summary

Combine is taking on the design venture capitalist world | Figma Blog

Combine is a new seed-stage venture firm founded by former Facebook and Airbnb design leaders Soleio Cuervo and Adam Michela. Rather than relying on publicity, it plans to build an elite, design-focused portfolio and provide hands-on support through an in-house team of design partners. The firm’s model combines early investment with design-studio services, reflecting the growing importance of user experience in competitive software markets. ## A Quiet Venture Launch - Combine launched with little publicity, sharing only cryptic images of its warehouse office and no formal Medium announcement. - Despite its low profile, Silicon Valley insiders were watching closely. - The founders’ understated approach reflects their belief that reputation should come from past work rather than promotional claims. ## Founders with Deep Design Experience - Soleio Cuervo was Facebook’s second design hire. - He helped shape the company’s early design culture. - He led work on Facebook Messenger, Groups, and the original Like button. - Adam Michela joined Facebook after Cuervo’s departure. - He created Facebook’s first design system. - He later built a design system at Airbnb. - Their contrasting personalities complement each other: - Cuervo is an expressive, relationship-oriented connector. - Michela is a quieter, methodical operator. - Both share a strong interest in design and people, along with a reluctance to self-promote. ## A Venture Firm Built Around Design - Combine had raised more than $12 million for its first fund. - The firm planned to maintain a small, selective portfolio. - It intended to hire a team of highly experienced design partners. - These partners would work directly with portfolio companies on: - Branding and marketing - User research - Product design - Recruiting and team-building - The model resembles Andreessen Horowitz’s service-oriented venture approach, but with an unusually strong focus on design. ## The Growing Importance of Design - Combine was launching as startups increasingly compete through user experience. - Cloud infrastructure has made software cheaper and easier to build, giving consumers more alternatives. - As functional differences narrow, thoughtful design can become a company’s strongest competitive advantage. - Users increasingly blame a product—not themselves—when they cannot understand how to use it, making usability central to business success. Combine’s approach represents a shift from venture capital as primarily financial support toward venture capital as an active operating partnership. Its success would depend on whether elite design expertise can meaningfully improve early-stage companies and establish a repeatable model for design-driven investing.

Read original

AWS Figma Design Systems User Experience+1