This is an abridged version of my LocoMocoSec 2020 conference talk
How do you set the strategy for a security team? If your goals are vague, people on your team will work on whatever they’re interested in because there’s no clear mission. If you don’t measure impact, your organization will hesitate to give you resources because you won’t be able to show what they get in return.
We use HTTPS to verify web server identities with X.509 certificates, but TLS also supports mutual authentication, where the server uses certs to verify the client’s identity. Given that passwords are a bottomless source of compromise from credential stuffing, phishing, and so on, the idea of using a cryptographically secure, phishing-resistant authentication mechanism already included in every major browsing and operating system seems like a big win.
You can turn on CloudTrail logging with a single command, but how do you use the data for audits and automation? In this post, I’ll describe cloudtrail-parquet-glue, which makes CloudTrail logs efficiently Athena-searchable with minimal custom code (because ”the best code is no code”) using AWS Glue.
First, why use Athena for CloudTrail logs?
AWS IAM policies answer the question “who gets access to what?”. AWS IAM policy conditions answer the more precise question “who gets access to what, when?”. Conditions enhance the expressive power of IAM policies by allowing authors to restrict access control by context. But be warned! They come with surprising gotchas. This blog post describes the AWS global condition context keys (i.e. those prefixed with aws:) and their caveats. Use it as a reference the next time you need to solve advanced IAM access issues.
You can learn a lot by kicking the tires on software. I work on identity systems, so I wanted to take AWS Cognito out for a spin. In this post, I’ll describe my experiment with Cognito to use G Suite SAML for ALB authentication, and how an encoding bug turned my joyride into a flat tire.
Cognito is two identity products: user pools and identity pools. User pools are a white-label user management system for people who don’t want to build one, like iOS developer implementing sign-in with Apple. …
How should we design user access to multiple AWS accounts? As organizations scale, they tend to centralize identity with SSO SAML federation, but there are two patterns for federation with AWS.
Hub-and-spoke: users assume federated roles into a single AWS “identity account” and perform a second role assumption into sub-accounts
Direct: users assume federated roles into AWS sub-accounts directly
Let’s look at examples of each and tradeoffs between the two.
AWS Multiple Account Security Strategy from AWS Answers describes a hub-and-spoke model where IAM Groups of IAM users can assume roles from a central identity account.
If you use IAM…
At Clever, we lock down code access to customer data using AWS IAM roles with session policies.
In Clever’s microservice AWS architecture, each service has a unique IAM role with access to the AWS resources it needs: S3 buckets, DynamoDB tables, and so on. Our services are multi-tenant and customer data is separated via logical control (i.e. our code), so there’s a risk of “crossing the streams” with a difficult-to-spot coding error. We could use separate AWS accounts for each customer or other sharding strategies, but with thousands of customers, these approaches have scaling challenges.
Clever Goals is a new product that tracks students’ educational software usage. It creates progress data, a new type of data for Clever. This sensitive data needs to be protected from unauthorized access, and users should feel in control over how it’s used. How does the Clever security team make sure that new products like Goals keep the bar high for student data protection?
Clever Goals progress data flow diagram, from our security review (component names omitted)
Early on, the Clever product team knew Goals would benefit from security and privacy design thinking. But entirely new products change direction frequently…
Over the past month, Clever worked with CERT to address a vulnerability in our open-source SAML2 library.
Clever maintains an open source library implementing the SAML protocol in Node.js known as saml2-js. We use this library internally in our SAML service provider functionality for schools using Clever SSO and the Clever Portal. It is used by other organizations acting as SAML service providers for verifying SAML assertions.
On January 24, 2108, Clever received an email from CERT describing a potential vulnerability in SAML implementations. We received details about the vulnerability on January 25. We verified the issue affected our saml2-js…
At Clever, one of our tenets is “Always a Student”, and in that spirit of learning we wanted to share the changes we made to fix memory allocation issues in AWS Elastic Container Service related to swappiness.
Swappiness is a Linux Kernel setting that specifies how likely it is for a page in memory to be written to virtual memory on the hard disk, or “swapped”. More precisely, it indicates the eviction preference for file cache pages (with a filesystem source) versus anonymous pages (without file backing, e.g. stack pages). A high swappiness value means anonymous pages are aggressively swapped…
Security for the people.