Downloaded 451 times
![21.29%
EQUIFAX
SECURE
CERTIFICATE
AUTHORITY
10.37%
ENTRUST.NET
SECURE
SERVER
CERTIFICATION
AUTHORITY
10.07%
DIGICERT
HIGH
ASSURANCE
EV
ROOT
CA
8.97%
GO
DADDY
CLASS
2
CERTIFICATION
AUTHORITY
7.91%
GEOTRUST
GLOBAL
CA
7.23%
ADDTRUST
EXTERNAL
CA
ROOT
6.48%
HTTP://WWW.VALICERT.COM/
6.04%
GTE
CYBERTRUST
GLOBAL
ROOT
4.45%
VERISIGN
CLASS
3
PUBLIC
PRIMARY
CERTIFICATION
AUTHORITY
-‐
G5
4.08%
CLASS
3
PUBLIC
PRIMARY
CERTIFICATION
AUTHORITY
3.82%
BALTIMORE
CYBERTRUST
ROOT
3.22%
CLASS
3
PUBLIC
PRIMARY
CERTIFICATION
AUTHORITY
-‐
G2
1.37%
THAWTE
PRIMARY
ROOT
CA
1.36%
THAWTE
PREMIUM
SERVER
CA
1.33%
ENTRUST.NET
CERTIFICATION
AUTHORITY
(2048)
0.65%
GLOBALSIGN
ROOT
CA
[The
CAs
which
had
<
0.5%
traffic
have
been
edited
out
for
brevity.
More
info
here:
h"p://codeascraX.com/2013/07/16/reducing-‐the-‐roots-‐of-‐some-‐evil/]
Our
raw
results:](https://image.slidesharecdn.com/attackdrivendefense-130829101820-phpapp01/75/Attack-driven-defense-76-2048.jpg)
More Related Content
Similar to Attack-driven defense
![Vibe Coding vs. Spec-Driven Development [Free Meetup]](https://cdn.slidesharecdn.com/ss_thumbnails/vibecodingvsspecdrivendevelopment-251209105622-43f455e7-thumbnail.jpg?width=640&height=640&fit=bounds)
Attack-driven defense
- 1. A"ack-‐Driven Defense zane@signalsciences.com @zanelackey
- 2. Who am I? • Co-‐Founder/CSO @ Signal Sciences • Previously built/led the Security Engineering group @ Etsy • Prior to that, offensive research/pentesJng @ iSEC Partners
- 3. This talk simply isn’t possible without a number of people: – Ben Hughes – Brendan Adamson – Corey Benninger – Kai Zhong – Ken Lee – Kyle Barry – Marcus Barczak – Mike Arpaia – Omar Ahmed
- 4. Also a shout out to secteams we’ve enjoyed collaboraJng with: Facebook/GitHub/Google/Square/Twi"er
- 5.
- 6.
- 7. Etsy? Security? … Why!?
- 8.
- 9. This talk is about shiXing from historically un-‐contextualized defensive approaches
- 10. To building defenses around real world a"ack pa"erns
- 11.
- 12. Historically defense has: – Focused on the perimeter – Deployed commodity security products that don’t address real a"ack scenarios – Treated vulnerability enumeraJon (or worse, compliance) as “pentesJng”
- 13.
- 14. What should we be doing?
- 15. Fundamentally we have three goals: 1) Raise cost to a"ackers 2) Increase the odds of detecJng compromise 3) Iterate defenses based on real a"ack pa"erns
- 16.
- 17. Build your defenses from an offensive mindset
- 18. Instrument detecJon mechanisms around key areas of the a"ack chain: • IniJal compromise – Defensive rootkicng • Persistence/C2 – Host level – OrganizaJonal level • Lateral Movement – Network/systems discovery – InformaJon discovery
- 19.
- 20. Rootkit your endpoints before your a"ackers do
- 21. Focus on the combinaJon of system behaviors and commands executed
- 22. Specifically, log commands executed on endpoints and analyze this data
- 23. Analyze the data and build automaJc alerJng from anomalies
- 24.
- 25. From a macro level, bucket users into technical vs non-‐technical
- 26. Pa"erns then break down into: – Anomalous if by a non-‐technical user – Anomalous if by technical user – Always anomalous
- 27. Non-‐Technical bucket: – Alert off any commands which show technical capabiliJes • It’s either an a"acker or your IT team Technical bucket: – Treat individual commands and behaviors as low quality signals • Aggregate commands, look for unique combinaJons and bursts Always anomalous (both buckets): – Analyze a"ack pa"erns and idenJfy commands/behaviors strongly indicaJve of compromise • We’re looking at you, `uname -‐a`
- 28. Non-‐Technical bucket: – Alert off any commands which show technical capabiliJes • It’s either an a"acker or your IT team Technical bucket: – Treat individual commands and behaviors as low quality signals • Aggregate commands, look for unique combinaJons and bursts Always anomalous (both buckets): – Analyze a"ack pa"erns and idenJfy commands/behaviors strongly indicaJve of compromise • We’re looking at you, `uname -‐a`
- 29. Non-‐Technical bucket: – Alert off any commands which show technical capabiliJes • It’s either an a"acker or your IT team Technical bucket: – Treat individual commands and behaviors as low quality signals • Aggregate commands, look for unique combinaJons and bursts Always anomalous (both buckets): – Analyze a"ack pa"erns and idenJfy commands/behaviors strongly indicaJve of compromise • We’re looking at you, `uname -‐a`
- 30.
- 31. Host level persistence: – Look for common pa"erns of persistence via programs executed on boot, kernel modules loaded, etc
- 32. Host level persistence: – Look for common pa"erns of persistence via programs executed on boot, kernel modules loaded, etc – Understand that in pracJce sophisJcated persistence mechanisms won’t be detected • Aim to detect the basics, and increase a"acker cost by forcing use of custom persistence mechanisms
- 33. Shout out to @mimeframe and the FB secteam for their work on BigMac: h"p://www.slideshare.net/mimeframe/ ruxcon-‐2012-‐15195589
- 34. PresenJng the Etsy version of a host IDS:
- 35. PresenJng the Etsy version of a host IDS: Tripyarn
- 36. Tripyarn’s goal is to alert off real world pa"erns of compromise and persistence
- 37. Lessons learned from detecJng hosJle persistence mechanisms
- 38. First, find the legiJmate OS-‐provided mechanisms you’re interested in instrumenJng
- 39. Treat addiJons to/modificaJon of these mechanisms as an event
- 40. For rare events, alert on every occurrence – Low false posiJve cost Ex: – New SSH keys being added to a host – Crontabs being created – etc
- 41. For events that happen oXen, use data aggregated across the organizaJon to detect anomalies
- 42. Example: Kernel modules
- 43. Goal: Detect a malicious kernel module loading on an endpoint – We thought kernel modules loading would be fairly rare aXer boot and we could alert off that alone. We were wildly wrong. – WhitelisJng/blacklisJng kernel module names wouldn’t be effecJve – Instead, analyze a kernel module being loaded for organizaJonal uniqueness
- 44. Goal: Detect a malicious kernel module loading on an endpoint – We thought kernel modules loading would be fairly rare aXer boot and we could alert off that alone. We were wildly wrong. – WhitelisJng/blacklisJng kernel module names wouldn’t be effecJve – Instead, analyze a kernel module being loaded for organizaJonal uniqueness
- 45. Goal: Detect a malicious kernel module loading on an endpoint – We thought kernel modules loading would be fairly rare aXer boot and we could alert off that alone. We were wildly wrong. – WhitelisJng/blacklisJng kernel module names wouldn’t be effecJve – Instead, analyze a kernel module being loaded for organizaJonal uniqueness
- 46. Goal: Detect a malicious kernel module loading on an endpoint – We thought kernel modules loading would be fairly rare aXer boot and we could alert off that alone. We were wildly wrong. – WhitelisJng/blacklisJng kernel module names wouldn’t be effecJve – Instead, analyze a kernel module being loaded for organizaJonal uniqueness
- 47. “Did module X that just got loaded on endpoint Y get loaded on less than N systems across the organizaJon in the last D days?”
- 48. Use a"ack post-‐exploitaJon techniques in a defensive context by separaJng your objecJves from your tooling
- 49. Specifically, collect data on the endpoints and analyze/alert from that data on the server-‐side
- 50. When an a"acker discovers and analyzes your endpoint security mechanisms they shouldn’t be able to automaJcally learn all alerts in place
- 51. OrganizaJonal level persistence: – LegiJmate remote access mechanisms or cloud systems with data desired by a"acker • Ex: VPN and GMail – Use a mixed approach of manual and automated anomaly detecJon for these systems • GeneraJng daily rollups of new accounts/keys created • AlerJng off account creaJon/modificaJon at unusual Jmes, from unusual locaJons, etc
- 52. OrganizaJonal level persistence: – LegiJmate remote access mechanisms or cloud systems with data desired by a"acker • Ex: VPN and GMail – Use a mixed approach of manual and automated anomaly detecJon for these systems • GeneraJng daily rollups of new accounts/keys created • AlerJng off account creaJon/modificaJon at unusual Jmes, from unusual locaJons, etc
- 53. Example: GMail
- 54. Goal: Instrument GMail to detect compromise of domain admin accounts – GMail provides logs of interesJng acJons via Admin Audit API and Email Audit API – Pull down logs via these APIs, store them locally so you have a record of acJons – Perform alerJng on strong signals of compromise and persistence: • Signins from unusual locaJons/Jmes • CreaJon of new admin level accounts • CreaJon of new mail-‐forwarding filters • Any change to 2FA secngs • Etc
- 55. Goal: Instrument GMail to detect compromise of domain admin accounts – GMail provides logs of interesJng acJons via Admin Audit API and Email Audit API – Pull down logs via these APIs, store them locally so you have a record of acJons – Perform alerJng on strong signals of compromise and persistence: • Signins from unusual locaJons/Jmes • CreaJon of new admin level accounts • CreaJon of new mail-‐forwarding filters • Any change to 2FA secngs • Etc
- 56. Goal: Instrument GMail to detect compromise of domain admin accounts – GMail provides logs of interesJng acJons via Admin Audit API and Email Audit API – Pull down logs via these APIs, store them locally so you have a record of acJons – Perform alerJng on strong signals of compromise and persistence: • Signins from unusual locaJons/Jmes • CreaJon of new admin level accounts • CreaJon of new mail-‐forwarding filters • Any change to 2FA secngs • Etc
- 58.
- 59. Focusing on two areas of lateral movement: 1. Network/systems discovery 2. InformaJon discovery
- 60. Use endpoint firewalls as a detecJon mechanism (NOT a blocking one)
- 61. Build alerts around services unused on your network but likely interesJng to a"ackers
- 62. By alerJng on (but not blocking!) traffic you don’t immediately signal there’s a detecJon mechanism in place
- 63. Also endpoint firewalls counter Jming-‐based evasions
- 64. Any traffic to targeted service, no ma"er how slow, causes alerts
- 65.
- 66. What internal systems provide informaJon that help an a"acker achieve their goals?
- 67.
- 68. Instrument these systems the way you would other high-‐value pieces of infrastructure
- 69. Alert off behavioral anomalies such as: – Usage outside of normal hours • Your a"ackers are rarely in your Jme zone – Bursts of acJvity • Viewing all security Jckets in the bug tracker isn’t even done by the security team – Etc
- 70.
- 71. Make compromise more expensive – We’ll discuss: • Reducing trusted CA roots • Removing cheap exploitaJon vectors • Forcing updates without the force • LimiJng drive-‐by exposure • PracJcal goals for security awareness training
- 72. How can you reduce the likelihood of a DigiNotar-‐like MITM happening against your organizaJon?
- 73. If you remove unused CAs, when one is compromised it can’t silently MITM your endpoints
- 74. We performed several months of anonymized traffic analysis to record what CAs were seen during our employees Internet usage
- 75. We found less than 29% of SSL CerJficate AuthoriJes trusted by our endpoints were actually used
- 76. 21.29% EQUIFAX SECURE CERTIFICATE AUTHORITY 10.37% ENTRUST.NET SECURE SERVER CERTIFICATION AUTHORITY 10.07% DIGICERT HIGH ASSURANCE EV ROOT CA 8.97% GO DADDY CLASS 2 CERTIFICATION AUTHORITY 7.91% GEOTRUST GLOBAL CA 7.23% ADDTRUST EXTERNAL CA ROOT 6.48% HTTP://WWW.VALICERT.COM/ 6.04% GTE CYBERTRUST GLOBAL ROOT 4.45% VERISIGN CLASS 3 PUBLIC PRIMARY CERTIFICATION AUTHORITY -‐ G5 4.08% CLASS 3 PUBLIC PRIMARY CERTIFICATION AUTHORITY 3.82% BALTIMORE CYBERTRUST ROOT 3.22% CLASS 3 PUBLIC PRIMARY CERTIFICATION AUTHORITY -‐ G2 1.37% THAWTE PRIMARY ROOT CA 1.36% THAWTE PREMIUM SERVER CA 1.33% ENTRUST.NET CERTIFICATION AUTHORITY (2048) 0.65% GLOBALSIGN ROOT CA [The CAs which had < 0.5% traffic have been edited out for brevity. More info here: h"p://codeascraX.com/2013/07/16/reducing-‐the-‐roots-‐of-‐some-‐evil/] Our raw results:
- 77. By removing only unused CAs you don’t teach users to click through SSL errors ConJnue traffic analysis, add/remove trusted CAs as appropriate
- 78.
- 79.
- 81. What did we learn when we removed Java web plugins from the enterprise?
- 82. • Hardly any groups actually needed it – Network OperaJons, for legacy networking equipment • For them, we built dedicated Java jump boxes
- 83. Benefits: 1. No Java on any laptops/desktops 2. Boxes with Java can’t hit Internet 3. Able to frequently re-‐image jump boxes 4. Only a few boxes to patch
- 84. But… Java shows back up when you apply Apple patches.
- 85. But… Java shows back up when you apply Apple patches. Remove it on an ongoing basis
- 86.
- 87.
- 88. We wanted a less heavy handed approach to ensuring up to date browsers
- 89. Built browser detecJon logic into our internal SSO point
- 90. UX is key: Show in screenshots how quick it is to update, provide a bypass mechanism
- 92. Simply asking users to update works shockingly well
- 93.
- 94. Funny story, users will install malware because an ad popup told them to.
- 95. Funny story, users will install malware because an ad popup told them to. O8en.
- 96. You can almost enJrely kill this source of compromise (for free!) by pushing adblocker plugins to the organizaJon
- 97.
- 98. Historically we’ve focused on reducing the number of people who fall for phishing
- 99. Historically we’ve focused on reducing the number of people who fall for phishing This is the wrong goal
- 100. If you go from being 36% on fire to 27% on fire you’re s;ll on fire
- 101. Instead, focus on incenJvizing users to:
- 102. The metric to track/increase is the likelihood of phishing emails being reported to security Even if 36% sJll fall for phishing, as long as one in the group reports it IR can begin
- 103. XXX Running effecJve a"ack simulaJons
- 104. Problems with “pentesJng” are well understood in the offensive community but not as well in the defensive community
- 105. Pentests typically result in a list of enumerated known vulnerabiliJes to be patched, not data on how a real a"acker would operate against a given environment
- 106. A"ack simulaJons should be done to learn how a"ackers are likely to achieve goals against your organizaJon NOT to show compromise is possible (spoiler alert: it is.)
- 107. Use this a"ack data to focus where/how to build detecJon mechanisms
- 108. From an organizaJonal side, a"ack simulaJons compliment vulnerability enumeraJon/ compliance/etc
- 109. Vulnerability enumeraJon/compliance are checklists to make sure you’re covering the basics
- 110. But checklists aren’t owning you, a"ackers are
- 111. Four keys to effecJve a"ack simulaJons: – Goal oriented • “Obtain domain admin”, “read the CEOs email”, “view credit card data”, … – Full organizaJon in scope • Have a"ack team call a contact if they’re about to do something risky – Simulate realisJc compromise pa"erns • Start the a"ack team on a standard laptop/desktop endpoint inside the organizaJon to simulate phishing/clientside compromise • Start the a"ack team on a database or web server to simulate SQL injecJon/ RCE • A"ack team should be encouraged to use 0days – Break simulaJon down into iteraJons: • Don’t spend the full engagement Jme on only round of tesJng, once one team achieve goal(s), then swap in new a"ack team to achieve the same goal(s) – Ex: We try to run 3-‐4 iteraJons per several week simulaJon
- 112. Four keys to effecJve a"ack simulaJons: – Goal oriented • “Obtain domain admin”, “read the CEOs email”, “view credit card data”, … – Full organizaJon in scope • Have a"ack team call a contact if they’re about to do something risky – Simulate realisJc compromise pa"erns • Start the a"ack team on a standard laptop/desktop endpoint inside the organizaJon to simulate phishing/clientside compromise • Start the a"ack team on a database or web server to simulate SQL injecJon/ RCE • A"ack team should be encouraged to use 0days – Break simulaJon down into iteraJons: • Don’t spend the full engagement Jme on only round of tesJng, once one team achieve goal(s), then swap in new a"ack team to achieve the same goal(s) – Ex: We try to run 3-‐4 iteraJons per several week simulaJon
- 113. Four keys to effecJve a"ack simulaJons: – Goal oriented • “Obtain domain admin”, “read the CEOs email”, “view credit card data”, … – Full organizaJon in scope • Have a"ack team call a contact if they’re about to do something risky – Simulate realisJc compromise pa"erns • Start the a"ack team on a standard laptop/desktop endpoint inside the organizaJon to simulate phishing/clientside compromise • Start the a"ack team on a database or web server to simulate SQL injecJon/ RCE • A"ack team should be encouraged to use 0days throughout engagement – Break simulaJon down into iteraJons: • Don’t spend the full engagement Jme on only round of tesJng, once one team achieve goal(s), then swap in new a"ack team to achieve the same goal(s) – Ex: We try to run 3-‐4 iteraJons per several week simulaJon
- 114. Four keys to effecJve a"ack simulaJons: – Goal oriented • “Obtain domain admin”, “read the CEOs email”, “view credit card data”, … – Full organizaJon in scope • Have a"ack team call a contact if they’re about to do something risky – Simulate realisJc compromise pa"erns • Start the a"ack team on a standard laptop/desktop endpoint inside the organizaJon to simulate phishing/clientside compromise • Start the a"ack team on a database or web server to simulate SQL injecJon/ RCE • A"ack team should be encouraged to use 0days throughout engagement – Break simulaJon down into iteraJons: • Don’t spend the full engagement Jme on only round of tesJng, once one team achieve goal(s), then swap in new a"ack team to achieve the same goal(s) – Ex: We try to run 3-‐4 iteraJons per several week simulaJon
- 115. The project output should be a>ack chains showing how a"ack team went from A-‐>B-‐>C to achieve goals, what steps they took and why
- 116. Just as importantly, what steps they didn’t take Ex: “We didn’t try to find internal network diagrams on your wiki because zone transfers were enabled so we could got enough data about your network from that”
- 117. Remember, the goal is to simulate realisJc a"ack behaviors and pa"erns that can be used to enhance detecJon
- 118. In addiJon, simulate varying a"ack profiles from quick & noisy to quietly maintaining persistence
- 119. Over mulJple iteraJons learn what behaviors overlap between a"ackers and what strong signals of lateral movement in your environment look like
- 120. TL;DR (The secJon formerly known as “Conclusions”)
- 121. Defend like an a"acker
- 122. Where should defense focus? – Increase a"acker cost by reducing cheap compromise vectors – Build detecJon mechanisms around real a"ack pa"erns • Analyze past compromises, new offensive research, and conduct realisJc a"ack simulaJons to obtain data – Depending on scale, have true offensive capabiliJes on staff or a call away – Have product/tooling development capabiliJes within your security team • Roughly one quarter of our team is soXware engineers who focus on building internal security products
- 123. Thanks! zane@signalsciences.com @zanelackey