janitor vs cleaner
TRANSCRIPT
Are you Janitor or a Cleaner?
John “geekspeed” Stauffacher@g33kspeed/[email protected]
Matthew “mattrix” Hoy @mattrix_ / [email protected]
Brief Bio Matthew
• About:
– Information Security Professional for over 15 years
– CISSP and GCIH
• Contact:
– @mattrix_
Brief Bio John
• About:
– Information Security Professional for over 13 years
– CISSP
• Contact:
– @g33kspeed
Purpose of this talk
• Reliance on automated detection has caused many organizations to be weak in response to an incident
• Many organizations have no idea who attacked them, why they were attacked or how the attack was executed
• Use of old school methods with less reliance on automated tools can help to understand who, how and why (motive)
• Strike Back
Purpose of this talk
• Where we have failed
• Many organizations fall victim to dangerous mindsets that prevent them from having an effective security program
• How do we move forward
• In order to strike back – we need to have our house in order.
The Janitor
Re-images owned boxes and does not identify or analyze the attacker.
The Cleaner
Goes beyond just re-imaging owned boxes. Can identify threat, attacker’s capability and take actions to stop attacker.
Incident Response vs. Immediate Action
Theoretical
Lifecycle of Incident Handling
• Preparation
• Identification
• Containment
• Eradication
• Recovery
• Lessons Learned
Immediate Action
During an attack there is no immediate order or lifecycle
• True Preparation – Probably didn’t happen
• Identification of Attacker
• Isolate and Study Attacker
• Stop Attacker
• Restore Services
• Take Attackers methods and rebuild defenses
Preparation
• What is not working
– Set it and forget it mentality
– Inadequate staffing
– Improper use of Vulnerability Assessments
– No asset inventory
– No classification of data
Preparation is key
• Attackers have managed to run organizations that are not unlike the ones they attack
Preparation is key
- Reconnaissance
- Weaponize
- Deliver
- Exploit
- Install
- C^2
- Act on Objectives
Preparation is key
• Marketing
• Operations
• Development
• Accounting
• HR
Preparation is key
• Attackers are streamlined, efficient
– Development takes days, not weeks.
– Rapidly adapts to a changing landscape
– Laser focus
– Aren’t rushed by artificial deadlines / other interests
Where We Have Failed
• We need to fill that position
Where We Have Failed
• We let the business dictate our security posture.
Where We Have Failed
• “Our department doesn’t do ‘preventative’ security scanning. We only scan after the application is in production.”
Where We Have Failed
• “We can’t scan that server – it might crash.”
Where We Have Failed
• Monitor mode
Where We Have Failed
• Sandboxing
The sandboxing appliances popularly deployed today are performing well against your average"0-day" malware threat, but capabilities decline dramatically the more targeted an adversary becomes. As such, organizations are much better at stopping the generic non-targeted "Internet threats", but becoming more vulnerable to marginally tuned malware. For example, any piece of malware that requires the user to perform an action at a specific time (before it acts maliciously) is sufficient to evade detection in most cases. - Gunter Ollmann (2013)
Where We Have Failed
Where We Have Failed
• Bloat: in some organizations it is typical for individual business units to have their own security staff
– …that don’t talk to each other
– …that don’t share information
– …that duplicate efforts
Where We Have Failed
• When security takes a back seat to business
What we need to change
• Security is EVERYONEs job.
• Misalignment of security goals should be looked at as a vulnerability in itself – and dealt with accordingly
What we need to change
• Attaching real monetary value to security incidents is a key way to get the attention of the stakeholders
• Rather than being defensive – and feeling responsible – security organizations should monetize all incidents and use it as justification for program budget
What we need to change
• We often fail inform management of something as simple as:
- Cost of the solution vs Cost associated with a security incident.
What we need to change
Executives rely on the bottom line numbers, as well as their advisors to guide their decisions. They know very little about technology and most of them don’t really care.
Speak their language. Express your concerns in dollar amounts and impact to the business.
What we need to change
~$250 per record for a DB breach
(42 states have mandatory notification laws)
If 3200 records of a database were breached…
$800,000
What we need to change
How much was that WAF?
What we need to change
• Get serious about hiring
• Stop putting bodies in chairs because somebody said we needed a body in a chair.
What we need to change
• Teamwork
• Align goals
• Share information
• Share tactics
What we need to change
• Security needs to assert itself as a fixture
• Too commonly thought of as an afterthought, or a remedy for an already bad situation
• Security needs to have the ear of the major decision makers in the company.
• The only tool for this is communication, and interaction
• Security needs to have teeth
• Back up your policy with corrective action
What we need to change
• We need to fight back.
True Preparation
• The (enemy) Attacker
1. Has no rules
2. Does not need Change Management to run Vulnerability Assessments against your people or infrastructure
3. Does not use checkbox settings in their tools to exploit your people or infrastructure
4. HAS NO RULES
Identification
• What is not working– Reliance on automated detection
– Set it and forget it mentality
– Staffing
• How was the incident identified?– Finding out about the compromise when you lose
availability
– Being Blacklisted
– Pastebin
Identification Immediate Action
• Assess your attacker’s capability
• Skill Level of attacker – Direct or Indirect method
• Create a dossier on your attacker
• Identify attacker’s Motive - Usage
• IP Addresses / Map this out / CIDR
Often Overlooked
• Actual – Physical Assets• Data Value – What is on the physical asset?• Network Connectivity – Where did the attack take
place from? Was this a pivot? Is there true defense in depth?
• Target Value – Was this a crafted attack? Who’s machine is this? What access does the person have? –Yes APT again.
• What devices do you have on the network to identify the attacker?
• Ask people (end user) questions – Hey did you guys see any weird email?
Tools I Use
• robtex.com, spokeo.com, google.com, IRC• NMAP, Wireshark • Network Tap• Acevpn, External Internet • traceroute, telnet, ssh, netstat –an, RDP• If you are looking during an ongoing attack – Bro
IDS and Splunk can be put in place quickly• Plain pen and paper – important to use a book for
each incident – this may be used for chain of custody
Containment
• What is not working
– We will just unplug the machine
– Switch to DR which has the very same vulnerability that production had if not more
– Re-image box and put it back into production
Flush out your attacker
• If you found a phishing email?
• Feed it some bogus info – You will need to provide at least 50 pieces of info
• Check your application logs for that very same info (fake username)
• Look at the timing – Is this automated or human?
• Are there multiple IP Addresses used or just one?
Assess Attacker’s Capability
• IP Addresses used
• Determine Attacker’s potential for Ddos by IP Address space
• Time for some OSINT
• Do not be afraid to probe your attacker
• I have scanned my attacker to determine the attacker’s assets
Strike Back
• Get direct with your attacker after identification
• Go to Meat Space – email or phone call
• If you can’t be direct with the attacker than the ISP or host may be able to help
• Or maybe not…
Strike Back
• An incident occurred with intellectual property in which my client was accused of leaking
• We were provided a single website of where this was leaked to
• After determining that this did not originate from our side we were then able to turn the tables.
• Maltego was used for the target• Spokeo was used for the target• End result - The person who leaked this was going
to receive a very interesting letter
Lessons Learned
• What is wrong
– This is often a report that is seldom read
– Focuses more on damage control
– Does not solve the issue
Lessons Learned Immediate Action
• Intelligence gathering
• Attacker’s skillset
• Understand the motive of your attacker
• Create automated tools to identify future attacks – Robert Rowley provided an excellent example of this in his “Teach your WAF new tricks” talk
• Use OSINT to learn about similar attackers