Infrastructure Security on Latacora

Latacora Achieves AWS Advanced Tier Services Partner Status

Tue, 27 Jan 2026 15:00:00 -0600

We are thrilled to announce a major milestone for Latacora: we have achieved the Amazon Web Services (AWS) Advanced Tier Services Partner status within the AWS Partner Network (APN).

This designation reflects Latacora’s technical expertise and diligence in delivering exceptional cloud security and compliance solutions to our clients, and confirms that we have successfully completed a rigorous validation process demonstrating a proven track record of customer success delivered by a team of AWS-certified professionals with specialized technical capabilities.

ECS on EC2: Covering Gaps in IMDS Hardening

Thu, 02 Oct 2025 11:18:59 -0700

Introduction

AWS ECS is a widely-adopted service across industries. To illustrate the scale and ubiquity of this service, over 2.4 billion Amazon Elastic Container Service tasks are launched every week (source) and over 65% of all new AWS containers customers use Amazon ECS (source).

There are two primary launch types for ECS: Fargate and EC2. The choice between them depends on factors like cost, performance, operational overhead, and the variability of your workload.

Introducing Replik8s, a Modern Security Tool for Kubernetes

Mon, 22 Sep 2025 12:00:00 -0400

Introduction

Security tools are often designed to highlight specific issues by consuming APIs and applying predefined logic. Each tool implements its own data structures, storage formats, and evaluation logic. While effective in narrow contexts, this approach creates challenges for teams managing a diverse toolset. Moreover, most tools are optimized to fetch only the data needed for specific findings, limiting their utility in broader contexts such as incident response or historical analysis.

Datomic and Content Addressable Techniques: An Ultimate Data Wonderland

Fri, 13 Sep 2024 12:00:00 -0500

Latacora collects and analyzes data about services our clients use. You may have read about our approach to building security tooling, but the tl;dr is we make requests to all the (configuration metadata) read-only APIs available to us and store the results in S3. We leverage the data to understand our clients' infrastructure and identify security issues and misconfigurations. We retain the files (“snapshots”) to support future IR/forensics efforts.

This approach has served us well, but the limited scope of a snapshot meant there was always a problem of first needing to figure out which files to look at. We love aws s3 sync and grep as much as anyone but security analysis requires looking for complex relationships between resources; text search is, at best, only a Bloom filter. What we really wanted was a performant way to ask any question across all the data we have for a client that would support complex queries using logic programming.

Remediating AWS IMDSv1

Wed, 11 Aug 2021 12:16:23 -0400

2024-12-17 Updated to include Declarative Policies

Compute resources in AWS (for example, EC2 instances, ECS tasks/services, etc.) get access to AWS credentials, such as temporary instance role credentials, via the Instance Metadata Service (IMDS). The compute resources use these credentials to access other AWS services such as SQS, DynamoDB and Secrets Manager.

Introduction: Problems with IMDSv1

There was originally only one version of IMDS, now called “v1,” which unfortunately many people still use. The technical risks and high profile incidents (the Capital One breach comes to mind) associated with v1, as well as the existence of v2 are well-documented. When an application hosted on an EC2 instance is vulnerable to SSRF, XXE or RCE, attackers can likely steal the temporary AWS credentials of the IAM role configured for the instance. This service is a particularly interesting target for attackers:

Gripes with Google Groups

Tue, 29 May 2018 17:14:00 -0400

If you’re like me, you think of Google Groups as the Usenet client turned mailing list manager. If you’re a GCP (Google Cloud Platform) user or maybe one of a handful of SAML (Security Assertion Markup Language) users you probably know Google Groups as an access control mechanism. The bad news is we’re both right.

This can blow up if permissions on those groups aren’t set right. Your groups were probably originally created by a sleep-deprived founder way before anyone was worried about access control. It’s been lovingly handcrafted and never audited ever since. Let’s say their configuration is, uh, “inconsistent”. If an administrator adds people to the right groups as part of their on-boarding, it’s not obvious when group membership is secretly self-service. Even if someone can’t join a group, they might still be able to read it.

Infrastructure Security on Latacora

Latacora Achieves AWS Advanced Tier Services Partner Status

ECS on EC2: Covering Gaps in IMDS Hardening

Introduction #

Introducing Replik8s, a Modern Security Tool for Kubernetes

Introduction #

Datomic and Content Addressable Techniques: An Ultimate Data Wonderland

Remediating AWS IMDSv1

Introduction: Problems with IMDSv1 #

Gripes with Google Groups

Introduction

Introduction

Introduction: Problems with IMDSv1