There’s no shortage of noise about cybersecurity. Between the shear number of vendors and daily news coverage about the next big vulnerability or breach, it’s easy to start feeling directionless and reactive. However, there are ways to cut through the noise. The first step is understanding how companies are actually getting breached - not just the ones you hear about in the media. Then, you can create a strategy that’s tailored to your risk profile and attack surface. In this session, you’ll leave with an understanding of how to measure your risk, devise a realistic defense strategy, and deploy high impact security, no matter what your budget or time crunch is.

1. AWS Security Week
Workshop
Stop Wasting Your Time: Focusing on Security
Practices That Actually Matter

2. Agenda
Background
Assessing your Security
Recommendations
2
Please ask questions
throughout!

3. About Us
3

4. Real-Time Host Monitoring
Behavior-based monitoring and detection of
suspicious events, featuring an out-of-the-box
ruleset of alerts for most common security
events.
4
Spanning your Data Center and Cloud
with One Platform
Vulnerability Monitoring
Detect systems and packages containing known
vulnerabilities and cross-reference against more
than two million identified CVEs, automatically
categorize them according to security risk.
Threat Intelligence Correlation
Continuously monitor connections to known
bad addresses and receive real-time alerts
when these connections occur.
Continuous Compliance
Achieve compliance criteria across HIPAA, PCI
DSS, SOC 2, ISO 27001, and SOX 404
regulations and regularly report/audit relevant
activity.
Configuration Auditing
Scan AWS configurations to ensure the proper
security settings have been selected and
enabled, while providing an accurate security
baseline.
Workflow Integrations
Increase efficiency with out-of-the-box
integrations with popular configuration
management and alerting tools, enabling easy
collaboration across security and DevOps
teams.

5. Why didn't the rising tide of “the Cloud” lift
both the operations and security ships?

6. SMB and Enterprise attack surface areas
converged as technical sophistication did

7. ENTERPRISE
MID-SIZED
ENTERPRISE
MID-SIZED
Then Now
Complexity, Attack Surface Area, & Requirements

8. “The state of security is the
absence of unmitigatable surprise.”
– DAN GEER, CISO, IN-Q-TEL

9. Crop image to fit inside this box
BE SURPRISED LESS
● Visibility
● Finding flaws is a good thing, it
means they won’t surprise you
ENSURE THAT WE CAN MITIGATE
SURPRISES
● “It’s not if you’ll be breached, it’s
when”
● Create a feedback loop from
visibility into eng and ops
9
Wait… what?

10. Crop image to fit inside this box
Medical Trial Data on Hygiene &
Health Care Workers
“In most health care institutions,
adherence to recommended
hand-washing practices remains
unacceptably low, rarely exceeding 40% of
situations
in which hand hygiene is indicated. Hand
hygiene reflects attitudes, behaviours and
beliefs.”
Hand hygiene: Back to the basics of infection control
(Purva Mathur, 2011)
Hand hygiene in a pediatric ICU
Perceived rate: ~73%
Observed rate, overt: ~33%
Observed rate, covert: ~11%
Teaching hospital medical staff to handwash (Tibballs, 1996)
10

11. “Federal Agencies Need to Address Aging Legacy
Systems” - GAO report to Oversight (May, 2016)
● Fiscal 2015 Federal IT spending:
○ $61.2b for ops/maintenance (legacy & steady-state)
○ $19.2b for dev/enhancements
● In 2015, 5,233 of the gov’s ~7,000 IT investments (74.76%) were spending all
their funds on ops & maintenance activities
● Not all agencies track system age in the same way
○ In some cases agencies were unsure of the actual age
● DoD uses 8” floppy disks in a legacy system that coordinates the operational
functions of the nation’s nuclear force
11

12. Breaches, APTs, and nation states - oh my!
● Most breaches are boring for the actors, ideally involving no effort (ROI)
○ Excitement is for the movies - this is business
● Most breaches are discovered by a third party over 100 days after they occur
● Most breaches do not involve Advanced Persistent Threats (APTs)
○ Good news because most organizations can’t even defend against drive by, naive,
unsophisticated threats
● Most breaches leverage automation as a force multiplier
12

13. What's the Hand Washing Equivalent in Cloud
Security?
TWO MOST COMMON TYPES OF BREACHES WE SEE:
1. Crimes of opportunity – scan everyone for a few issues
2. Crimes of persistence – single target, every vector
BIGGEST DIFFERENCE IS THE WILLINGNESS TO INVEST AND THE
NUMBER OF EMPLOYED VECTORS
“Networks are hard, humans are squishy” is the hypothesis behind spam,
spear phishing, ransomware, etc.
BAD ACTORS CARE ABOUT ROI
13

14. Actor’s Objectives
14
CROWN JEWELS ARE OBVIOUSLY OBVIOUS
▪ e.g. Ashley Madison Breach
ANYTHING CONNECTED TO A CREDIT CARD OR PAYMENT METHOD
▪ Makes Bitcoin mining and DDoS a lot more affordable
▪ e.g., anyone who has ever received an AWS Abuse Warning
▪ e.g., misconfigured Amazon S3 buckets used to host pirated content and
malware
RANSOMWARE IS NOT LIMITED TO YOUR LAPTOPS
▪ AWS console access is equivalent to physical data center access
▪ e.g., Code Spaces breach and MongoDB

15. Bringing the hand washing analogy home
PROCESS DRIVEN (IDEAL)
1. Identify the top risks to your organization (impact, likelihood, etc.)
2. Can you put detection around those risks
3. Can you put controls and enforcement around it?
4. Back to step 1
POLICY DRIVEN (FALLBACK, TOO OFTEN THE DEFAULT)
1. Write a policy
2. Enforce that policy if possible
3. If enforcement isn’t possible, then fear is your last tool in the box (HR)
15

16. Cyber Kill Chain
16
Gives us a model to
understand threats and
their likelihood, regardless
of their sophistication.
Applies equally to
skiddies and APTs!

17. Two Strategic Paths
17

18. 18

20. Where Would You Focus Your Investment?
20
TRADITIONAL BELIEFS
▪ Attribution
▪ Firewalls
▪ Anti-virus
▪ APTs
GROUND TRUTH
▪ Databases on the WAN without
basic auth (see MongoDB &
Elasticsearch)
▪ Record setting DDoS attacks in
volume & complexity
▪ Insider threats, both intentional
and naive
▪ Actors becoming more
sophisticated in regards to AWS
services and APIs

21. 21
Can we use security metrics to gain
critical visibility while impacting
organizational and cultural change?

22. STUDY 1
Critical CIS Benchmark
Misconfigurations on AWS
AWS CUSTOMER TRENDS & BEST PRACTICES

23. What Makes a Misconfiguration Critical?
• Can be leveraged in a direct data breach
• e.g., S3 access
• Can be leveraged trivially in a more complex attack
• e.g., misconfigured Security Groups
• Enables trivial attacks on AWS console
• e.g., no MFA enabled
• Eliminates critical visibility (security or compliance)
•e.g., no AWS CloudTrail
23

24. Critical CIS Benchmark Issues as of 2/1/17
24
% Orgs with Violations Total Violations for All Orgs
AWS Security Groups
with wide open SSH
(0.0.0.0/0 port 22)
73% 2,937
At least one AWS user
without MFA enabled
62% 1,192
S3 buckets ACLs that
grant access to everyone
37% 149
CloudTrail not enabled in
all regions
27% 35

25. STUDY 2
How Do You SSH?
AWS CUSTOMER TRENDS & BEST PRACTICES

26. Logging in as `root` Because YOLO (9/19)
26
▪ 11 orgs logged in as root
▪ 7 of those orgs logged in as root from the WAN
▪ Common non-root WAN logins (all more common than root)
datos
nessus
ansible
ubuntu
ec2-user
admin
deploy
AWS DEFAULTS
“Uses SSH” doesn't mean “must be WAN”
Lots of risk here
Database backup software
Okay, but why from the WAN?

27. SSHD Traffic Accepted From WAN (9/19)
27
12.6% of orgs accepted SSH from WAN
▪ 44.6% on port 22
▪ 25.0% on port 22202
▪ 20.6% on port 15520
▪ 1.8% on port 2129
▪ 1.1% on port 2222
▪ 1.0% on port 3022
▪ Other 78% of ports were all <1%
PORT OBFUSCATION,
BECAUSE APPARENTLY
NMAP ISN'T A THING

28. STUDY 3
Immutable Infrastructure
& Software Updates

29. % Orgs Upgrading Software per Day
29

30. Average Life of Agents by Month They Were
Registered In
30

31. OS uptime as of 2/1/17 @ 23:23:00-0000
31
Average: 31.39 days
On 9/20/16: 16.64 days
Youngest: 37 seconds
On 9/20/16: 42 minutes
Oldest: 1,244.39 days (~=3 years, 4 months)
On 9/20/16: 1,021.25 days (~= 2 years 10 months)

32. Assessing Your Pains &
What Cloud Changed
32

33. Security Team Pains
33
You don’t actually get this many resources and you’re
surrounded by infinite waves

34. Security Team Pains
34
* Even if you could buy all this stuff, do you have enough people to use it all?

35. Things that you will never hear...
35

36. Crop image to fit inside this box
“Here’s an
award for not
letting us get
breached.”
36

37. Crop image to fit inside this box
37
“I don’t mind
that you get in
my way
because it’s
protecting our
company.”

38. Crop image to fit inside this box
38
“I get it! That
single chart
very clearly
communicates
how much
you’ve reduced
our risk.”

39. 39
“A breach
wouldn’t be
that big of a
deal.”

40. 40
Security is a serious business.

41. It’s not that this job had become more
difficult, it’s that how we do our job has
changed.
(Assumes you want to be effective.)
41

42. AWS Foundation Services
Compute Storage Database Networking
AWS Global
Infrastructure
Regions
Availability Zones
Edge Locations
Encryption Key Management Client and Server Encryption Network Traffic Protection
Platform, Applications, Identity & Access Management
Operating System, Network & Firewall Configuration
Customer content
Customers
Customers are
responsible for their
security configuration
IN the Cloud
AWS looks after the
security of the platform
Obligatory shared responsibility reminder

43. 43
Traditional security architecture, modern data
center
outside
Hardware
Hypervisor
VM VM
App App App
inside
(LAN)
Firewall
NIDS
Perimeter security
Eng
&
Ops
Security &
Physical Ops

44. 44
Traditional security architecture, modern data
center
outside
Hardware
Hypervisor
VM VM
App App App
inside
(LAN)
Eng
&
Ops

45. 45
The world we saw when we built Threat Stack
● Run time
monitoring
● Detection
● Contextualization
Hardware
Hypervisor
VM VM
App App App
AWS
Threat
Stack
App Sec
WAF, CDN, etc.

46. Is this a good change?
● Security always wanted host level visibility
○ Danger: traditionalists have adopted the religion of network analysis and don’t always
understand why. Bigger problem in the enterprise.
● In public clouds like AWS, you must monitor both the host and their APIs
○ The AWS APIs are rarely the objective. They are usually a means to an end (initial breach point).
● Forces conversations about trust that previously were not considered.
○ Can you trust the wire? The hardware? AWS’s employees?
○ More importantly, is this relevant in your threat model?

47. Assessing Your
Security
47

48. Security Should Be in the Context of Business
Availability
48
Performance Compliance & Security

49. Why Security? Why Now?
What are the
security drivers in
your organization?
49
What are the
consequences of
NOT paying
attention now?
Why do they
matter now?

50. How Secure is Your Cloud Today?
3 mins, complete questionnaire
50

51. 51
People
Process Tools

52. 52
People
Process Tools

53. 53
People
Process Tools

54. 54
People
Process Tools

55. What does success look like?
55
SecurityOps

56. Go Make it Happen
56

57. The flow we want
1. Identify the top risks to your organization (impact,
likelihood, etc.)
○ Requires visibility into the environment - who is doing
what, where are workloads and what’s on them, what is
software doing, etc.
2. Put detection around those risks
○ Understand what is normal vs. weird vs. bad, then start
alerting on weird and bad
3. Can you put controls and enforcement around it?
○ Work with operations to understand why something is
happening
○ Try to remediate the risk, understanding that this may
require a compensating control
4. Back to step 1
57
Security
Security
Security Ops

58. Unsure where your risks are? Start here:
58
• Are you still allowing root logins?
- Make sure your security groups are configured correctly
• Are devs logging into production?
- Automate away reasons
• Who’s not using MFA?
• Who’s logging in, from where, at what time?
• What software is running in your environment?
• What third party services is production connecting to and using?

59. Example 1
Editing & Copying Files
59

60. You’re always adding
new code, new
systems, updating
security groups and
DNS entries…
But, how do you know
these things are being
updated by code and
not manual /
unauthorized users?
Continuous Delivery
ALERT FATIGUE | JULY 26, 2016

61. Identifying the risk
61

62. Identifying the risk
62

63. Understanding what’s happening
● Database backups are required for compliance and best practices
○ Reasonable, but should be automated
○ Value to automating:
■ Prevent human error
■ Ensure that backups always happen & to the correct destination
■ Free those humans up to do non-automatable tasks like building
● Need to pull data for analytics and business intelligence
○ Reasonable, especially for sub-enterprise shops without a “data warehouse”
○ Value to automating:
■ Clarity of controls (host and application/data access controls are typically different)
■ Humans stop logging into production databases unless they need to break fix
63

64. ● Security can more easily control software than humans
○ “Why is Bob using his access to change the database server config?”
● Operations prefers automation over humans because software typically causes
less outages than humans (root cause)
○ “Whoops, I didn’t realize that running that dump would lock the whole table!”
● VP of Engineering/Operations gets more efficiency from hires since they aren’t
doing the work of software
● CEO hears less fighting and more cooperation between organizations
Recognizing cross function value
64

65. ● Security can more easily control software than humans
○ “Why is Bob using his access to change the database server config?”
● Operations prefers automation over humans because software typically causes
less outages than humans (root cause)
○ “Whoops, I didn’t realize that running that dump would lock the whole table!”
● VP of Engineering/Operations gets more efficiency from hires since they aren’t
doing the work of software
● CEO hears less fighting and more cooperation between organizations
Recognizing cross function value
65
You only get credit for all of this if you can bubble it up, contextualizing it
for both the technical and non-technical team members.

66. Example 2
Near Production Outage
Is Really a Security Incident
66

67. First Clue
67
Queues are backing up in production. When on-call responds
they see a queue that they’ve never heard of before and
it doesn’t have a consumer so it just keeps backing up.

68. Second Clue
68
After deleting the queue they try to figure out where it
came from (after hours). They look for all network traffic
to the server since the queue was created earlier that night.

69. 69

70. Third Clue
70
After removing the rogue software, they look at what
else the software has been doing.

71. 71

72. 72

73. This is when you
escalate from
“incident” to “breach”
73

74. Fourth Clue
74
Luckily they have access to that other environment,
so they log into the control panel and reset the password to gain access.

75. Pay Off
75
It wasn’t Colonel Mustard, it was a rogue engineer running
an unauthorized experiment in production, sending customer data
to an unauthorized and insecure environment to do “analysis”
because they knew no one would approve of it.

76. You’ve Given Your
Devs Access To
Production To Help
Them Go Faster….
But How Do You Track
Down Who Did What,
When?
Trust But Verify
ALERT FATIGUE | JULY 26, 2016CLOUD SECURITY: YOU’VE GOT THIS, RIGHT? | JULY 26, 2016

77. ● Incident Response is another form of debugging, you keep following clues until
you find the pay off - Mean Time to Know is really Mean Time to First Clue
● There was nothing sexy about this scenario - no malware, APTs, or 0-days - just
good ol’ fashion customer data mishandling and a narrowly avoided leak
● Traditional tools (logs) and traditional practices (logging into every involved
server) would have taken hours, instead the whole process took minutes
It’s worth noting...
77

78. Scenarios from Audience?
78

79. Want to Learn More?
www.threatstack.com
Come talk to us!