Aws

A long time ago I wrote about my method of book-keeping using Ledger CLI. Nearly 10 years later, I’m still using it track my finances down to the penny. It’s an amazing tool, and has helped me identify problematic spending habits. But it does have one achilles heel, it’s not very friendly to non-technical people. I share my finances with my family because I want to teach financial literacy and help them feel like they are a part of any decision-making activities related to money. Given that Ledger is text-based, it means they don’t need to install any programs. But because it is text-based, it means they need to learn to use a text editor and the terminal (I could import it into things like Gnu Cash, but I’m not going down that rabbit hole). To improve this accessibility problem, I devised an automated notification scheme whereby once I finish updating the ledger, a summary is emailed to everyone. Here’s how I did it. ...

This is part 4 in a series of articles. To follow along via code, visit the Github repository. In the last article, I reviewed the template for operational and security risks. Let’s go fix some of them now. Making Unsafe Defaults Safe First, some guard rails are added to the template. Remove the Default attribute from both SSHLocation and HTTPLocation, ensuring that the caller specifies them in the CloudFormation template. That way, if the caller does use 0.0.0.0/0, it is a decision they have made, not the template. ...

This is part 3 in a series of articles. To follow along via code, visit the Github repository. The last article discussed some refactoring use new(-ish) CloudFormation features, which help improve the readability and reduce the template’s file size. This article temporarily moves away from template modifications and focuses on how someone can review a CloudFormation template for security and operational risks. Parameters Let’s start with the Parameters section, because that is going to tell us what dependencies we need to bring into this template from our AWS or organizational environment. ...

This is part 2 in a series of articles. To follow along via code, visit the Github repository. In the last article, I showed how we can improve the operational capabilities of the AlienVault sensor deployment in AWS, simply by adding some automation and formatting changes to the generic CloudFormation template supplied to customers. Let’s further improve the YAML template to make it more readable and less code-heavy by using the newest features of CloudFormation. ...

This is part 1 in a series of articles. To follow along via code, visit the Github repository. I recently needed to review the AlienVault Sensor deployment for AWS and, well, it left me wanting more. Many companies are smart to offer infrastructure-as-code for their appliances. It provides customers with a near one-click deployment model. It also provides customers with insight into what permissions, servers, and resources the appliance will require. The issue with vendor-supplied code is that it needs to apply to a generic customer base; a sort of lowest common denominator scenario where insecure defaults are needed to fit various environments and customers with various skill levels. ...

I am working on a new project, Security Awareness for Busy People, and I accidentally found a trick to bypass one of the restrictions when working in the AWS SES sandbox. But first, can I just say that I love finding undocumented functionality in AWS? I feel like a techie version of Indiana Jones! AWS SES, or Simple Email Service, is a service provided by Amazon Web Services that allows customers to send emails. This is similar to services like SendGrid. Emails can be sent either via SMTP or through their API. It’s really cool, fairly cheap, and very easy to setup and get started. The best part is that you can hook your incoming or outgoing emails into the entire AWS ecosystem and process them automatically. But I digress. ...

UPDATE 2019-10-07: There is a bug in CloudFormation when outputting the LogGroup ARN. See the change below in 4. Define a Policy. UPDATE 2020-06-16: Thanks to jplock, I have fixed an error in the ARN syntax for log-group, where a / should have been a :. I notice that the AWS documentation and even their managed policies (e.g. AWSLambdaBasicExecutionRole) all provide users with insecure examples of how to setup permissions for their Lambda functions to emit their logs to CloudWatch Logs. The permissions are not least privilege, meaning they provide more permission to the Lambda function than are necessary and can lead to unintended consequences. Let’s look at the common example given to users: ...

I love using CloudFormation for provisioning AWS services but one of the more annoying aspects about working with it is that setting up the initial CloudFormation stack is an all-or-none endeavour. This is in contrast to when a stack exists and is being updated, where changes are reversible and the stack is almost always left in a working state. This annoyance is compounded when I write a stack definition with multiple resources and, as it inevitably happens, there is a typo somewhere. CloudFormation dutifully creates all the resources, trips on the error, and rolls back the entire stack to nothingness. Then I need to delete the stack and start again instead of issuing an update or changeset request. It’s a time-sink and I wanted to find a better way. ...

A common pattern I see used by Engineering teams when I provide security consulting is them creating Lambda function and hosting their code in their own S3 buckets. This S3 bucket means the Engineering team needs to secure the bucket, which means the following controls are active and maintained: no public S3 access (bucket or object) access logging (logs are sent to yet another bucket!) default encryption of all objects access control and monitoring backups failover region segregation of code written by different departments …and that’s just the start. All of that is tedious and creates security busy-work, not to mention you are still responsible for those code assets. Since AWS is hosting my Lambda function, they can host my code too. Here’s how you do it. ...

IAM provides a way for users and roles to become another role. This is known as IAM role switching and uses the underlying sts:AssumeRole action. You can restrict IAM role switching in one of two ways, what I like to call the single lock and double lock methods. With any IAM role switch, there involves a two-way handshake. The person (source) switching to the role (target) must be allowed to assume the role, plus the target must allow the source to assume it. That way, an IAM role switch can be used to switch between roles within the same account, or roles within different AWS account (maybe one that you don’t even own). ...