AWS re:Invent — Day 2 reflections
My second day at re:Invent started with a talk titled “How to Automate Security Learning at Scale”. Unlike what you would expect from the title, this talk wasn’t about applying Machine Learning (ML), but what needs to be done to make the massive amount of data that is coming from our security tools usable for ML. It is an interesting problem to both security folks and analytics folks, because security data is in no way as uniform as e.g. a set of images. As an example the speaker talked about the severity of events. Sometimes this is a 1 to 5 scale, sometimes it is a 1 to 10 scale and sometime it is a 1 to 100 scale. On top of that sometimes a relative score of 80% means drop everything and handle this, sometimes it just means “you better look at this in the next few days”. The speaker offered some practical patterns to normalize data so it can be handled by an automated system.
Second talk of the day is titled “Five New Security Automations Using AWS Security Services & Open Source”. So why automate? Humans are awesome, unless you want consistent results. Incident response is hard, especially at 3 a.m. and in such a time you often forget to record the details you need to write a decent report. Automation with e.g. step functions can help you get a consistent view of an incident or even automatically resolve a security issue. Open Source software can help in this automation. But when you use OSS, make sure that the project is healthy and you understand the license.
The talk showed a number of OpenSource security automations:
- SignalHub — A good tool for alerting from security automations
- LambdaCanary — A tool to make sure that you Lambda functions (for IR) are in place and have the correct code from a parent to a child account.
- GuardDuty Multi-Account Manager — The name is pretty descriptive.
- MozDef — Mozilla Defense Platform — An OpenSource Siem
- ExposedKeyRemediator-v2 — A tool to lock down exposed AWS keys.
My last session of this day was titled “Encryption SDK: The Busy Engineer’s Guide to Client-Side Encryption” and it was a 2:15 hour workshop. In this workshop we added client side encryption to an existing application using the Amazon Encryption SDK to help with the heavy lifting. Here are the reasons to use the Amazon Encryption SDK instead of building your own envelope encryption:
- It does the nitty gritty stuff around envelope encryption for you.
- It easily allows you to encrypt against multiple CMK’s in multiple regions
- They made all the mistakes for you (and corrected them) and made client side encryption using KMS easy and secure.
P.S. Don’t roll your own encryption.
