supports global redundancy with low latency Write CM recipes for managing apps & services Implement a monitoring & alerting system Manage a continuous integration & deployment pipeline … also “security”
Attack Surface CIA Triad Asset: the thing to protect Vulnerability: A weakness that exposes an asset Threat: What we’re protecting against (bad actor, virus…) Risk = Threat + Asset + Vulnerability Shit Security People Say
in Google Play store are Malware John McAfee plants key loggers in laptops, gifts them to Belizean government workers Stuxnet targets centrifuges in Iranian nuclear enrichment plants IETF standards working groups undermined by NSA What is a Sys Admin to do?
of billions of guesses/sec Brainflayer, DefCon 2015: “a single day should be more than enough time for a botnet to check every possible eight character ASCII password and XKCD- style passphrase against every Bitcoin address that has ever received funds”
API, Google account, GitHub, etc • SSH via Duo Sec Do not use shared and/or default accounts Use sudo for auditability SSH private keys should always have a passphrase Beware of SSH agent forwarding hijack - Demo
and only for simple cases. credentials sent with every request. HTTP Digest Auth - Safer to use without SSL, but server must store pw with a weak hash.. but without SSL the server cannot be trusted Mutual/2-way SSL - Underappreciated today, esp. for server-to- server comms. Not scalable for large # of clients. Username/Pw + token/Oauth - Most widely deployed & understood. Often implemented poorly
or mutual SSL, or API key & secret Secure all API endpoints, even those used only internally Possibly use path-based routing to limit access to sensitive interfaces Custom/NIH solutions should be vehemently mistrusted
Apply principle of least privilege for accessing the DB from apps App to DB connection must be encrypted Replication between cluster nodes must also be encrypted & authenticated (usually via mutual SSL) Some data stores have NO option for encryption and only weak auth (redis)
services that ask for IAM access & secret keys Instead, use the IAM AssumeRole feature IAM administrator access considered harmful Enable MFA for root account, disable API keys, do not use root account On instances, replace or disable the default username and associated key CloudTrail
for sources in SG rules Allow all traffic (0.0.0.0/0) or large network ranges (10.0.0.0/8, 192.168.0.0/16) Create one SG per system “role” Assign many security groups to an instance Programmatically manage SGs (via CloudFormation, custom scripts, etc) Permit any ports that are unneeded Name & Tag security groups Include granular outbound rules
in depth) Enable with only SSH allowed, save as part of a base image Open ports as needed based on the system’s services & functionality Best managed via CM “But troubleshooting is so much harder!”
to the network through a bastion or VPN • NACLs complicate things but can be useful to segment subnets • Complete VPC isolation is better • Subnets do (almost) nothing for security • Port knocking is a fun toy • 3rd party services (Dome9) can enable/disable group rules via browser extension • VPC Flow Logs • Peered VPCs & VPN Gateway • Beware of connected network proliferation • Note SG limitations for communication between VPCs
(Heartbleed, POODLE, FREAK, LogJam) Selection of ciphersuite of paramount importance ECDHE defeats all known crypto attacks Ultra paranoid? Replace Diffie Hellman group parameters, and/or only use >= 2048 bit primes awk '$5 > 2000' /etc/ssh/moduli > new_moduli && mv new_moduli /etc/ssh/moduli See weakdh.org
Certificate Authorities 300+ trusted CAs by default Interference with the operations of middleboxes “Cryptographic Overhead” Like everything else, thwarted by weak end user security
Group Autoscale Group Security Group Users Security Group Security Group Persistence Services Public Private https https MySQL TLS token auth Redis - Auth only SSH or VPN
defaults CIS Benchmarks Standard Disable default services Create separate partitions & set mount options Harden the SSH config (https://goo.gl/PBqEWr) Configure log rotation & centralized system logs Remove unused SUID binaries AWS Share the base image between accounts Avoid community AMIs
< 1 week (Defense in depth is only defense) Must be able to orchestrate updates across fleets of servers Using immutable systems? Now go replace them all Which is worse - downtime because a patch broke something, or exposure of customer data due to vulnerable software? But don’t be premature about it Can software repositories be trusted?
image Can be a source of vulnerability Secrets in plain text in repositories (db passwords, API keys, private keys, etc) Runs as root or root-ish Can be triggered remotely, often without further auth Authenticated using public key crypto Mitigation Use vault/encrypted attributes rather than plain text Keep config mgmt software patched Follow vendor security guidelines
Attack vectors via CI/CD Integrations with Slack/Hipchat Does your bot have root? Dependencies on external services When containers don’t contain Docker is the new wheel Colocated containers can subvert the principle of least privilege Insecure configurations --privileged, --net=host
Security Center https://aws.amazon.com/security/ AWS security best practices http://media.amazonwebservices.com/AWS_Security_Best_Practices.pdf Secure OpenSSH Config https://goo.gl/PBqEWr CIS Benchmarks https://benchmarks.cisecurity.org/downloads/benchmarks/ Pocket Vulnerability https://www.gnu.gl/blog/Posts/multiple-vulnerabilities-in-pocket/ VPC Security http://docs.aws.amazon.com/AmazonVPC/latest/UserGuide/VPC_Security.html How to securely hash passwords http://security.stackexchange.com/questions/211/how-to-securely-hash-passwords Countdown to Zero Day (Stuxnet book) http://www.amazon.com/Countdown-Zero-Day-Stuxnet-Digital/dp/077043617X