using hackers’ own methods & tools to defeat persistent adversaries · · 2017-12-18using...
TRANSCRIPT
Using Hackers’ Own Methods & Tools to Defeat Persistent Adversaries
Michael A. Davis, CTO CounterTack
1
About Our Presenter
Michael A. DavisChief Technology Officer CounterTack
Technology Expertise– CounterTack: Manage technology vision to push
defenders ahead of the attackers– External IT: Unifying business, security and IT– Savid Technologies: Fastest Growing Security
Company in 2010 ranked by Inc.o Consulted for Global 1000 organizations
Noted Author and Presenter– Author: Hacking Exposed, Hacking Exposed:
Malware & Rootkits– Author: Regular contributor to InformationWeek
and Dark Reading– Speaker at conferences including RSA, Black Hat,
ISSA, ISACA, InfosecWorld, SecureWorld, DEFCON
2
Agenda
Why Attackers are Winning
Why You Aren’t Keeping Up
What New Approaches Can Solve This Problem?
3
Example: Professional Interface
4
What is different?
Compromising the user is always easier then
compromising the technology!
7
Enterprise Concerns
25%22%
34%39%
52%
29% 27%22%
42%38%
Assessingrisk
Gettingadequatefunding
Preventingdata
breaches
Enforcingsecuritypolicies
Managingthe
complexity
2012 2013
Source: Information Week Data Survey, 2013
8
Complexity is everywhere
Application integration
OS
Database
Collaboration
Business intelligence/ Analytical
applications
Application development
tools
Hardware platform
Applications
Services
Computer Network Storage
FS Applications
SecurityIDS
Content Filtering
Management
AV/Spyware Anti-Spam
Identity Management
Regulatory Compliance
Firewalls
Vulnerability Assessment
Monitoring
Network & Systems Management
Management Vendors
Dynamic Provisioning
Storage
Source: CA, 2009
What The Heck Can I Do?
Make Better Decisions
Complex IT Projects Fail - A lot
Out Of 200 Multi-nationals:
67% Failed To Terminate Unsuccessful Projects
61% Reported Major Conflicts
34% Of Projects Were Not Aligned With Strategy
32% Performed Redundant Work
1 In 6 Projects Had A Cost Overrun Of 200%!
2011 Harvard Business Review – Berlin Univ Technical survey
We All Do Them
Source: InformationWeek Analytics Strategic Security Survey
The Reality
Source: InformationWeek Analytics Strategic Security Survey
How Companies Make Decisions
14
15
Failure Mode Effects Analysis
FMEA is a design tool for identifying risk in the system with the intent of mitigating those risks with design changes. The FMEA risk mitigation:
1. Recognizes and evaluates the potential failure of a system and its effects;
2. Identifies actions which could eliminate or reduce the chance of a potential failure occurring.
16
Quick History
First used in the 1960’s in the Aerospace industry during the Apollo missions
In 1974, the Navy developed MIL-STD-1629 regarding the use of FMEA
In the late 1970’s, the automotive industry was driven by liability costs to use FMEA
Later, the automotive industry saw the advantages of using this tool to reduce risks related to poor quality
17
Testing Conditions
Conditions can exist at various times, but the effect is the result when the action occurs and the conditions exist at the same time and space.
Infinite Continuum
As we continue our investigation we find baby steps,
Leading to inserting causes inside of causes, or
Each cause leads to another set of causes in the form of action and conditions,
Developing an infinite continuum
Will the Stage Make it from Hangman’s Hill to Placer Gulch?
20
Mars Spirit Rover Flash Memory Problem
“The thing that strikes me most about all this is how critical it was to have that INIT_CRIPPLED command in the system. It’s not the kind of command that you’d ever expect to use under normal conditions on Mars. But back during the earliest days of the project Glenn realized that someday we might need the flexibility to deal with a broken flash file system, and he put INIT_CRIPPLED in the system and left it there. And when the anomaly hit, it saved the mission.”
–From “Roving Mars” by Steve Squires, Hyperion 2005
Be prepared for the low probability event with a huge consequence.
21
FMEA Procedure
1. For each input (start with high value inputs), determine the ways in which the input can go wrong (failure mode) (Attack)
2. For each failure mode, determine effects– Select a severity level for each effect (Privileges, access, etc)
3. Identify potential causes of each failure mode– Select an occurrence level for each cause (SQL Injection, Weak Hashes)
4. List current controls for each cause– Select a detection level for each cause (WAF, None)
22
FMEA Procedure (Cont.)
5. Calculate the Risk Priority Number (RPN)
6. Look at frequency!!!
7. Develop recommended actions, assign responsible persons, and take actions– Give priority to high RPNs– MUST look at severities rated a 10
Process Steps
23
Severity, Occurrence, and Detection
Severity– Importance of the effect on environment (CIA)– 1 = Not Severe, 10 = Very Severe
Occurrence– Frequency with which a given cause occurs and
creates failure modes (obtain from past data if possible)– 1 = Not Likely, 10 = Very Likely
Detection– The ability of the current control scheme to detect
(then prevent) a given cause (may be difficult to estimate early in process operations).– 1 = Easy to Detect, 10 = Not easy to Detect
Severity Occurrence Detection RPNX X =
24
Risk Fish!
https://www.societyinforisk.org/content/veris-risk-fish
The idea is relatively simple - take a "Fish" or Ishikawa Diagram (http://en.wikipedia.org/wiki/Ishikawa_diagram) for root cause analysis - and apply it to information risk.
25