This document summarizes steps for hardening Windows systems used in industrial control systems (ICS). It recommends:
1. Performing basic hardening steps like removing unnecessary software, disabling services, and restricting file system access.
2. Leveraging the native Windows firewall to prevent backdoors and malware from communicating.
3. Implementing whitelisting of authorized software using Software Restriction Policies or AppLocker to prevent unauthorized code execution.
4. Using Enhanced Mitigation Experience Toolkit (EMET) for exploitation mitigation to reduce the impact of zero-day vulnerabilities.
5. Leveraging PowerShell remoting and Just Enough Administration (JEA) to restrict remote access without using
4. Who? (cont)
Speaker at: Hackers 2 Hackers Conference, CeBIT Hannover, Defcon
Bangalore, Brazil Automation, FISL (Intl. Free Software Forum) & more
Co-author of “Seguranca de Automacao
Industrial e SCADA”(SCADA & Industrial
Automation Security)
first book on this subject in Brazilian Portuguese
6. Who? (cont)
Features:
*NIX/BSD freak
Digital tools blacksmith / python & C lover
Lousy guitar player
Coffee dependent
Hates printers, doesn't likes social networks anything
Selectively-social
7. A huge number of ICS/SCADA systems
runs on Windows OS
DEC VAX & other *NIXes → Windows Family (XP mostly)
8. Standard axioms
Once installed, not much changes on machine (not even patches)
Clear (?) network connection matrix
Custom scripts (bat/vbs) might be used
Terminal Services probably will be used for remoting if needed
12. Start with all the basic steps for your everyday
hardening:
Remove software (Games, Word, Windows Messaging)
Disable services
Restrict/tune file-system access
Perform service-user/account separation + least privilege
15. Firewall adds up:
Prevents backdoors from listening for connections
Prevents malware/shell from communicating with attacker machine
(if egress filtering is done properly)
Separates local interface services (which sometimes listens globally)
from external world
16. Firewall doesn't solves:
Abusing existing allowed ports
Shut down original service, listen on its port
Abusing existing connections
http://www.slideshare.net/bz98/defcon-22-bypass-firewalls-application-white-lists-secure-remote-desktops-in-20-seconds
18. Problem:
Employees intentionally installs
unauthorized software
and/or
Employees are foiled and
runs unauthorized software
Software has/is a malware
which compromises the machine
Attackers can deploy tools locally
for lateral movement
21. About scripting:
AppLocker/SRP cannot restrict code running within environments
(Office VBS, Perl, Python interpreters etc)
CMD, BAT, VBS and PowerShell scripts can be individually signed
22. Whitelisting adds up:
Prevents unauthorized software from running
(hacker tools, misbehaving employees)
Allows controlled use of scripts
Flexibility enables security with minor (yeah, I know) business/operation
hog
23. Whitelisting doesn't solves:
In-memory code execution (e.g. DLL injection)
http://leastprivilege.blogspot.com.br/2013/04/bypass-applocker-by-loading-dlls-from.html
Allowed application exploitation
OS or enforcement application vulns/0days
Running DLLs from rundll32.exe
https://www.attackdebris.com/?p=143
27. Problem (example scenario):
All software on Machine M001
is unpatched
ICS software was coded by people
without secure SDLC mindset
Lots of software vulns. are present
and won't be fixed soon
32. EMET adds up:
Reduces impact/likelihood of 0day exploitation
Adds complexity to attacks
Foils most off-the-shelf exploits
33. Bypassing EMET is not impossible, but it's tricky:
“We started looking at EMET since version 4.0 and it’s come a long
way since. There's no doubt that Microsoft are stepping up their efforts
at making EMET ever more effective. This sort of layered defense goes
a long way in disrupting commodity attacks and increasing the level of
effort required for successful exploitation.”
https://www.offensive-security.com/vulndev/disarming-and-bypassing-emet-5-1/
34. Bypassing EMET is not impossible, but it's tricky:
“We found that EMET was very good at stopping pre-existing
memory corruption attacks (a type of hacker exploit). But we
wondered: is it possible for a slightly more technical attacker to bypass
the protections offered in EMET? And yes, we found ways to bypass all
of the protections in EMET.”
http://labs.bromium.com/2014/02/24/bypassing-emet-4-1/
35. Bypassing EMET is not impossible, but it's tricky:
“(…) But truth be told EMET has tons of good protections which
render a lot of methods useless (…) EMET fights tough, more than any
public exploit mitigation solution out there. A lot tougher than MBAE
and enterprise exploit detection products.
But if we get to study the system, its only a matter of time.”
http://casual-scrutiny.blogspot.com.br/2015/03/defeating-emet-52.html
36.
37. EMET caveats:
Application might still be exploitable by other means
EMET can be bypassed within a good effort
Some applications might not go well with EMET
Windows XP has very limited support
38. PowerShell Remoting and JEA
Because most of the times you don't really need Terminal Service
39. Problem (example scenario):
Machine M001 runs Software XYZ
Software XYZ runs as Administrator
User ABC needs to restart Software XYZ
User ABC ends up with Administrator account on Machine M001
40.
41. PS Remoting and JEA adds up:
Enables remote operation without Terminal Service
Enables restricted operation environment
Works cross-domains
42. PS Remoting and JEA caveats:
Requires Windows Management Framework (WMF) 5.0
Requires some coding knowledge
Requires some more attention to PS traffic on your wires
44. Deploy from your domain or configure locally:
Firewall rules
EMET install / updates / configuration
Software Restriction Policies (Win XP / Vista)
App Locker policies (Win 7+)
45. Suitable for mixed environments:
Software Restriction Policies & App Locker can coexist
Basic firewall rules applies to whole Windows XP/Vista/7/8
Appropriate version of EMET can be deployed to specific hosts
50. Windows PowerShell Desired State Configuration (DSC)
DSC provides a set of Windows PowerShell language extensions, new
Windows PowerShell cmdlets, and resources that you can use to
declaratively specify how you want your software environment to be
configured.
https://technet.microsoft.com/en-us/library/dn249912.aspx