This document discusses application whitelisting as a security control that can complement traditional threat-centric security approaches. It notes that application whitelisting works on a principle of default deny by only allowing approved applications to run, whereas traditional antivirus uses a default allow approach. The document outlines challenges with traditional antivirus, including its inability to keep up with the exponential growth of malware. It advocates for implementing application whitelisting to prevent both known and unknown threats from executing. Key considerations for implementation include scope, stakeholder engagement, approval processes, and change management. The document argues that application whitelisting can significantly reduce malware incidents when implemented effectively.

1. Presented by
Osama Salah
Application Whitelisting
Complimenting Threat Centric with Trust Centric Security

2. Application Whitelisting
Is Application
on whitelist?
Is Application
on Blacklist?
Deny! Don’t Run!
Run it!
Don’t Run!
Allow! Run it!
Yes
No
Yes
No
Threat
Centric
Trust
Centric
Else
Else
Default Allow
Default Deny

3. Blacklist Fail

4. Decision Rationale
Objective Q1. What do we
know more about,
the bad or the good?
Q2. Is it easy to
mange?
Malware Prevent malware from
executing.
The Good White List
But we do Black List
No (White List)
Yes (Black List)
Access
Control
Allow access to
employees only.
The Good White List Yes
No-Fly List Prevent known bad
people from getting on
planes.
The Bad Black List Yes

5. What is the Problem?
…in the context of this presentation.

6. Exponential Malware Growth
Source: AV-TEST, www.av-test.org
0
50
100
150
200
250
300
2005 2006 2007 2008 2009 2010 2011 2012 2013 2014
Millions
Total Malware
New Malware

7. How are we typically
trying to solve the
problem?

8. Traditional Malware Prevention Stack
DataCenterFirewall
EndpointProtection
HostFWAntivirus
HIPS
AntiAPT
Firewall
WebFilterAntivirus
IPS
Firewall
WebFilterAntivirus
IPS

9. Antivirus Effectiveness
“When none of the antivirus scanners
detected a malware sample on the first day, it
took an average of two days for at least one
antivirus scanner to detect it”
“Over the course of 365 days, no single antivirus scanner had a perfect day - a day in which it caught every
new malware sample”
“After a year, there are
samples that 10% of the
scanners still do not
detect”
Source: lastline.com, Antivirus Isn’t Dead, It Just Can’t Keep Up
“On Day 0, only
51% of antivirus
scanners detected
new malware
samples”
“After two weeks, there was a
notable bump in detection rates
(up to 61%), indicating a
common lag time for antivirus
vendors”

10. How do we get infected today?
• Watering Hole Attacks
• Zero-Day Vulnerabilities
http://
where ever target
typically
hangs out
• Google says the best phishing scams have 45% success
rate (2014).
• FireEye on Spear Phishing: 70% open rate, 50% of those
click on links. (2012)

11. APT Protection
Turing Test in Reverse: New Sandbox-Evasion techniques
Seek Human Interaction (fireeye.com, June 2014)
“Cybersecurity is a constant arms race. Simulating mouse movement
and clicks is not enough to fool the most advanced sandbox-
evading malware. Now malware authors are incorporating real-world
behaviors into their evasion strategies.”
“Simulating these behaviors—the way actual people scroll documents,
click the mouse button, and move the cursor— is a huge challenge for
cybersecurity. Anticipating future evasion techniques might be even
tougher. Expect malware authors to employ more novel
techniques that look for that human touch.”
Microsoft phishing emails target corporate users, deliver
malware that evades sandboxes (scmagazine.com 02.2015)
Quarian Targeted-Attack Malware Evades Sandbox
Detection (blogs.mcafee.com 09.2014)
One additional prediction: To date, cybercriminals have
mainly focused on escaping application sandboxes.
However, increasingly popular standalone sandbox systems
offered by security software vendors pose a new hurdle for
cyberthieves. In response, cybercriminals have begun to
explore ways for their malware to escape from those sandbox
systems. Today a significant number of malware families
identify and evade sandbox-based detection.
(McAfee Labs Threat Report Nov. 2014)
Malware Authors Using New Techniques to Evade
Automated Threat Analysis Systems (symantec.com 10.2012)
An Independent test of APT attack detection appliances
(MRG Effitas and CrySyS Lab, Nov. 2014)

12. What are others saying?
Secure Standard Config
Application Whitelisting
Patch Applications
Patch Operating System
Minimize user with Admin priv.
Application Sec. Patching
“..prevents 85% of targeted
cyber intrusions..”
“…are the most effective means yet found to stop
the wave of targeted intrusions that are doing the
greatest damage to many organizations.”
Software Whitelisting
System Sec. Patching
No Admin Priv. Browsing/Emailing

13. Source: Gartner Hype Cycle for Infrastructure Protection, 2014

14. What is probably the most successful
App Whitelisting Implementation?

15. Why aren’t more enterprises implementing Whitelisting?
• Maturity and Culture
– Change Control, Admin Control on Workstations
– Software Asset Management discipline
– Balancing between security and operations
– Complaints Management
• It’s not easy
• Perception that its is not flexible
• Perception: Performance overhead, another agent on endpoints,
doesn’t play nice with AV
• Decision maker not impacted (Externality)
• Bad Marketing

16. It’s a Question of Trust…
• Trust the Solution
– Vulnerabilities or Evasion possible
– Risk Reduction not elimination
– Augmenting other controls not replacing
• Trust the Implementer
– Skills, capabilities, references
• Trust the Administrator
– Control through process and audits

17. Possible Enforcement Policies:
• Low: Allowed to run, monitor only
• Medium: Prompt Users, allow to run locally
• High: Block untrusted
• Run policies in monitoring mode (what if?)
• On Existing or new files
• Combine with Local or Global Approvals
• Combine with Reputation/Trust Level
It’s not all Black and White

18. Lessons Learnt:
Application Trust Policy Options
To put it in context, below some figures of our particular deployment
1.8 Million Unique Files
Collected over a period of approx. 6 months
1800 End Users 1300 Workstations 220 Servers

19. Trusted Publishers
48%
Signed Files
Non-Signed
Files
52%
~ 1.8 Million Files
~ 8300 Publishers

20. Trusted Publishers
“…the Darkhotel attackers are using a variety of digital certificates to sign
their malware. Attackers often employ stolen certificates in this way, but
the Darkhotel group seems to have taken a different tack, duplicating
legitimate certificates that have weak keys.”
Certificate Authority Hacks
Stolen Certificates
Code Signing System Hack
DigiNotar Files Bankruptcy in Wake of
Devastating Hack (09.2011)
Independent Iranian Hacker Claims
Responsibility for Comodo Hack (03.2011)
VeriSign Hit by Hackers in 2010 (02.2012)
Hackers Breached Adobe Server in Order to Sign
Their Malware (09.2012)Bit9 Hackerd into, the Criminals Seize Code-signing
Certificate (02.2013)
Sony attackers also stole certificates to sign malware
(02.2013)
Zeus malware found with valid digital signature (04.2014)
Certificates Revocation
HP accidentally signed malware, will revoke
certificate (10.2014)
Microsoft Revokes Certificates Used by Flame
Malware (06.2012)
Adobe to revoke code signing certificate (09.2012)
Weak Certificate Hack

21. Trusted Publishers
Some Issues
• Publisher dropping non-signed files.
• Publisher replacing previously signed files with non-signed files.
Application Whitelisting Features
• Typically you can put trusted publishers manually on a whitelist or
automate it by using reputational approval of the publisher.
• You also ban publishers.
• Publisher Check on new file detection
• Periodic Certificate re-check
• Exclude Weak Certificates

22. Trusted Directories
• Files located in a specific directory and executed
from it are allowed to deploy.
• Can be used to further lockdown updater policies by
limiting where the files need to be coming from like:
C:WSUSWsusContent
• Easy option if you can control what goes into the
Trusted Directory
• Don’t use with removable drives

23. Trusted User or Group
• Selected users can be granted permissions to
deploy software.
• Can be granted in urgent/exceptional cases.

24. Trusted Software Delivery System
• Software Distribution Systems like Microsoft SCCM, PDQ
Deploy…
• Software that updates itself like Adobe Reader, Chrome, AV
software etc.
• Patch Management Solutions (WSUS, …)
• Solutions come with a list of preconfigured Updaters
• Add updater rules manually, basically by selecting the
process that will do the updating.

25. Threat Levels
• Clean
• Potential Risk
• Malicious
• Unknown
Clean
26%
Unknown
74%
Trust Levels
0
200
400
600
800
1000
1200
1400
-1 0 1 2 3 4 5 6 7 8 9 10
Thousands

26. File Type Distribution (1.8M files)
76%
8%
7%
4%
5%
exe
msi
jar
dll
vb,reg
mui,sys
com,bat

27. Implementation Considerations
• Application whitelisting is augmenting existing
controls, it is not replacing them.
• Determine Scope of Deployment
– Workstations, Laptops, Servers..
• Determine the stakeholders and understand
how they will be impacted. Engage them early.
– End Users, Client Support, Systems Eng., Developers, Anyone
who currently has admin rights…
• Strategy: Stop the bleeding, cleanup later

28. Implementation Considerations
• Develop Application Whitelisting Policy & Procedure (align with
software asset management lifecycle)
– Obtaining, testing, approving, deploying, maintaining
• Why and how are new applications entering the company?
• New Deployments, Trial Software, Updates, Patching, Web
Download, Email, USB…
• What is the approval process? How can you automate it?
• Be ready to respond quickly (emergency), especially early on in
the project.

29. Benefits Summary
• Reduce number of malware incidents
• Zero-Day Protection
• Improve security of end-of-life or hard to patch endpoints
• Detect insider threats or bad behavior
• Improved forensic capabilities (Data, Drift Reports, Snapshots)
• Better Change management will require better planning and can
lead to less downtime
• Permit usage of USB devices (if the risk is introducing malware not
data leakage)

30. THANK YOU FOR YOUR TIME