The Streisand Effect, for those not aware, is where an attempt to remove, hide, or censor a piece of information has the unintended consequence of publicizing that information more widely by way of drawing attention to it. It is named after Barbara Streisand, who once filed a lawsuit to have an arial image of her home removed from the Internet. In her case, it resulted in a flood of publicity and thousands of people viewing that image.
What happened here?
An individual took issue with a post that I wrote 8 years ago. The identity of the person and the content of the post aren’t relevant to this post, but what is important is that prior to this event, the post was sitting by itself, pretty much left alone except for for the occasional web crawler visiting it. The post would have stayed that way, except that the person who had an issue with my post decided to complain in a heavily trafficked forum. This resulted in the post receiving more traffic than the previous several months combined. Additionally, many more people were made aware of the contents of the post, which I’m fairly sure the person complaining did not want to see happen.
How about some numbers?
Here’s a graph of HTTP requests to that page over time:
Note the huge spike, when is when the post in question was mentioned. Approximately one thousand separate people visited the post in question during the spike in traffic.
As a service to the Philly tech community (and because folks asked), I took notes at tonight’s presentation, called “Security Practices for DevOps Teams”. It was presented by Chris Merrick, VP of Engineering at RJMetrics.
Security is a “cursed role”
…in the sense that if you’re doing a really good job as a security engineer, no one knows you exist.
It isn’t sexy
It’s hard to quantify
It’s never done
As DevOps engineers, we are all de facto security engineers
Some tips to avoid ending up like this [Picture of a dismembered C3PO]
Obscurity is not Security
“A secret endpoint on your website is not security”
“Don’t rely on randomness to secure things”
Do not give more privileges than are needed
If you talk to an insecure system, you’re at risk
Breaking into datacenters
Any vector that comes through an application you developed
Applications you didn’t write
Phishing, social engineering
Authentication is who you are
Authorization is what you can access
Don’t access production directory
Good news: this is our job anyways
Don’t spread private keys around
Don’t put in your Dropbox
Don’t let it leave the machine you generated it on
Use SSH agent forwarding
ssh -A you@remote
Don’t use shared accounts
Be able to revoke access quickly
Time yourself. Go.
We use Amazon OpsWorks to help us achieve these goals
Chef+AWS, with some neat tricks: simple autoscaling, application deployment, and SSH user management
“Logs are your lifeline”
When you get into a high pressure security investigation, you start with your logs
Capture all authentication events, privilege, escalations, and state changes.
From your Os and all running applications
Make sure you can trust your logs
Remember – they’re your lifeline
Have a retention policy
We keep 30 days “hot”, 90 days “cold”
Logging – ELK
We use ELK for hot log searching
Kibana creates logs and lets you monitor your application in real time
Keep unencrypted secrets out of code
Otherwise, a MongoLab exploit becomes your exploit
Don’t keep old code around
Make deployment and rollback easy
More good news: this is our job anyways
When dealing with a security issue, the last thing we need a “hard last step” in order to get the fix out
Don’t use your root account, ever.
Set a long password and lock it away
Set a strong password policy and require MFA
Don’t create API keys where API access isn’t needed
Same goes for a console password
Use Managed Policies
To make management easier
Use Roles to gran taccess to other systems
No need to deploy keys, auto-rotates
IAM Policy Pro Tips
Don’t use explicit DENY policies
Keep in mind that everything is denied by default
Don’t assume your custom policy is correct just because it saves – the interface only confirms the JSON is valid
Use the policy simulator
Know Thy Enemy
People are out there scanning for AWS keys – treat your private key like a private SSH key