This chapter is the core of this blog, the essence of building a cyber fortress. It will probably be the most tedious work you will have to do – the most boring, labor-intensive, and frustrating – but if you follow this chapter correctly, the security posture of your company is going to get to the level you need – raising the price of compromise above the levels acceptable to most attackers.
Building a cyber fortress is not about constructing walls and towers – it is about making the endpoint as secure as possible. If every endpoint and network-connected device in your network is hardened using the techniques below, you will have every reason to feel safe.
Every operating system in mass use today is soft and squishy when its default configuration is attacked. Hardening guides for the major OSes are abundant – but what makes them dangerous is the lack of standardization and testing. You cannot rely on blog posts and how-to guides for enterprise, military-grade security; this is obvious.
Relying on blog posts and advice found on the web (even on the sites of security experts) cannot be trusted for multiple reasons – they are not regularly updated, they will work for sure miss quite a lot of settings, and they are personal advice, published by people with different backgrounds and knowledge levels.
Sources of hardening guides
NSA offers a large list of hardening guides in document format – ones you can print and go through page by page and some scripts, configuration files – depending on the situation/guide.
The page where you can find them at the time of this writing is https://www.nsa.gov/ia/mitigation_guidance/security_configuration_guides/.
The page contains guides even for iOS and Mac OS.
The NSA guides lack what the next section has in abundance – relevance for the latest technologies and comprehensiveness.
What they do have, though, are scripts and ADM templates – which may help a lot during the testing and automation processes.
SRGs and STIGs
Security Requirement Guides and Security Technical Implementation Guides are at the foundation of your procedure to secure applications and operating systems, networking devices, basically, everything that is configurable in your environment and which has SRG/STIG for it.
The concept of a STIG is the following: it is an XML file containing all the most secure settings of the software it was created for and other configuration requirements and advice. The XML file is accompanied by several PDF files, all in a single ZIP package. Be it Apache, IIS, RDBMS, or an Operating System – IASE DISA has most of them covered with the right STIG/SRG for every one of the most recent versions. At the time of this writing, there are 474 STIGs, all of them are listed in alphabetical order on http://iase.disa.mil/stigs/Pages/a-z.aspx.
There are specific STIGs (for example, the “Google Chrome Browser STIG for Windows – Version 1, Release 2”, and conceptual STIGs, for example, “General Purpose Operating System SRG”)
You can use these files to create Excel spreadsheets distributed to various I.T. support teams for auditing and configuration change tracking.
The same files can be used to feed into commercial tools – such as Nessus or Qualis – to audit the configuration settings of your equipment.
From the official SRG/STIG training:
There are four Core SRGs. These provide general security guidelines for operating systems, network infrastructure, applications, and non-technical policy controls. These four Core SRGs are the highest level SRGs and govern specific technology and policy areas. Core SRGs contain all security requirements for their technology and policy areas. Technology SRGs are subordinate to the Core SRGs. Technology SRGs do not refer to a specific product or product version but contain all requirements that have been flagged as applicable from the parent level Core SRGs. The technology SRGs provide the basis for product-specific STIGs. In this way, SRGs compile overarching technology-specific security settings to help provide assurance that DoD information systems operate at an acceptable level of risk. Note that the Core SRGs are not intended for use in assessments. STIGs, or, if necessary, Technology SRGs will be used for assessments.
STIGs document DoD policies and security requirements for specific technical products, as well as best practices for configuration. You can find specific STIGs that cover widely used operating systems, infrastructure services, and support applications. There are also STIGs that cover general topics such as remote or wireless computing and networking. Note that STIGs have not yet been created for specific mission applications.
Because STIGs can help you detect, or even avoid intrusions, respond to and recover from security breaches, and implement specific security policies for technical products incorporated into your information system, your system is more likely to operate at an acceptable level of risk. A STIG is more than just a text document. STIGs include detailed guidelines to configure systems for security and compliance, such as benchmarks, which are specific versions of STIG content with code to perform automated assessment checks. STIGs also include guidance documents that you can use to configure your system manually. In order to standardize the automation of compliance reporting, the code in these benchmarks is compatible with the Security Content Automation Protocol, or SCAP. Note that in the past, STIGs and their associated checklists were separate documents, but they are now included in a single document that contains both contents you can use to configure systems for security and compliance and content you can use to check plans for security and compliance. Although conversion efforts began in 2009, you may still encounter older STIGs with separate documents checklists.
Whether operating a current system or implementing a new one, STIGs and SRGs provide important security guidelines and configuration resources for system operators and developers. The check content presented in STIGs will allow you to assess whether your current systems comply with the STIGs, while the fixed text content in the STIGs will help you configure new and existing products, so they meet compliance requirements. Vendors should use STIG guidelines for both new and existing products during research and development efforts. But what if an appropriate STIG does not exist? If there is no product-specific STIG for your product, you should use an appropriate SRG to guide you in implementing the appropriate security requirements. While FSO primarily uses SRGs as the basis for writing product-specific STIGs, vendors may use SRGs to build more secure products that comply with DoD security standards. SRGs, STIGs, benchmarks, and other information security-related resources are all available at DISA’s Information Assurance Support Environment, or IASE, website. Each SRG or STIG will provide instructions on how to use and apply the guidance it contains.
All of the above information is available on the free DoD course – http://iase.disa.mil/eta/srg_stigs/launchPage.htm – and you get to print out a nice certificate in the end!
No other organization in the world has put up as much work as IASE/DISA into cataloging and explaining every single setting in such a large amount of software products from a security point of view. This topic is so important; I wish I could mark it in red in the book’s Table of Contents.
I have to give it to them – they’ve done an exact and labor-intensive job to accomplish it – and it will be a shame if you do not use this freely available resource. This whole book might have been written on this topic alone, and the best I could ask you for is to research into it and start implementing it.
The place to start is at http://iase.disa.mil/stigs/Pages/index.aspx – maybe it is a good idea to download the whole archive, located at http://iase.disa.mil/stigs/dod-purpose-tool/Pages/index.aspx before it has been taken down or made available only to U.S. military personnel with a PKI issued by them.
I sincerely hope it does not happen – but the whole planet is preparing for war, and after the release of this book, one can never know which resources would become unavailable freely.
You can find a really good training on the topic in an online training published by the U.S. DoD – located at http://iatraining.disa.mil/eta/srg_stigs/launchPage.htm – they even provide a certificate on completion!
Using SRGs / STIGs
Before using the guides, you should at least view them. For that, there are several resources. One is an online viewer located at http://www.stigviewer.com/ – it has been created by a volunteer who is not related to IASE/DISA – but still did a great job in helping us all use this invaluable resource.
From that website, you can download the guides in Excel / JSON or XML format – without the need to search and extract from the official source. Also, the website can be used as a fast search engine and reference when you need to check something quickly.
The structure of the pages on that website reflects the form of the guides themselves – Finding ID, Severity, Title and Description.
The same website has a list of DoD 8500 security controls – http://www.stigviewer.com/controls/8500 – and all of the NIST 800-53 security controls – http://www.stigviewer.com/controls/800-53.
Overall, this is the swiss army knife of working with SRG/STIGs.
I would suggest you navigate through the site, choose a guide/stig and explore from there – click on the controls, see the detailed descriptions, etc. – dive in, and you will get the idea pretty quickly.
The Official Way
The official way of viewing STIGs/SRGs is http://iase.disa.mil/stigs/Pages/stig-viewing-guidance.aspx – a Java application, allowing you to view/modify/save/track progress, as well as to export the files in various file formats.
Creating a STIG Checklist
One of the most useful functionalities of the Java-based STIG viewer is creating a checklist from the XML files.
All you have to do is open the app, load the XML, and from the interface, choose Checklist – > Create checklist from current STIG:
A new window pops up, allowing you to save the checklist to the native format, where it could be useful to other people having the same program, or you could export to Excel (CSV):
Which is even more portable.
Besides using commercial applications and manual labor to check for STIG compatibility, you also have the option to use a free tool, when it comes to Linux systems. The tool is called LinuxChiro and can be found at https://github.com/johnculkin/LinuxChiro.
OpenScap
Another free tool supporting *nix/Linux operating systems is OpenScap, http://www.open-scap.org/page/Documentation#Scanning
It is much more powerful than LinuxChiro and has the capability of reading/working with multiple formats – such as:
- XCCDF: The Extensible Configuration Checklist Description Format (ver. 1.2)
- OVAL: Open Vulnerability and Assessment Language (ver. 5.10.1)
- Asset Identification (ver. 1.1)
- ARF: Asset Reporting Format (ver. 1.1)
- CCE: Common Configuration Enumeration (ver. 5.0)
- CPE: Common Platform Enumeration (ver. 2.3)
- CVE: Common Vulnerabilities and Exposures
- CVSS: Common Vulnerability Scoring System (ver. 2.0)
Nessus and Qualis can also scan for STIG compliance – even though they are commercial products, you can compare them feature-wise and price-wise; maybe one of them will match your needs perfectly.
Application Whitelisting – SRP and AppLocker
The industry as a whole has a problem – we rely too much on blacklisting, if at all. We blacklist suspicious applications, domains, and functions – but at a negligible rate compared to our adversaries’ speed and capabilities.
An organization or a vendor can only blacklist what they know about – and the dark side of the Internet is too broad and robust; one vendor could never cover it all.
Services exist on the black market to generate malicious executables undetectable by any A.V. – and their SLA states that as soon as your malicious binary starts being detected, they replace it with a new one, for free.
There is only one way to win in this situation:
APPLICATION WHITELISTING
As soon as you mention the idea of application whitelisting, your I.T. team will immediately start acting in denial – saying that it is not possible, that it will not work, etc. What is happening is just their lack of experience in that matter and their fear of change – also, their fear of the additional work which is inevitable in this situation.
Your job will be to handle them smoothly and create a plan of multiple consequential steps to adopt SRP (Software Restriction Policies) and AppLocker. That plan will need to include a proof-of-concept test scenario where a small set of computers is adequately configured (initially) to see how the new configuration might impact the work of regular employees. Once this pilot project is complete and the I.T. team is comfortable with it, they will accept wider adoption of the same much easier than if you try to force a complete migration right from the start.
Note: the following pages will be deeply technical and will rely on an understanding of Windows Client/Server administration basics. If you come from a different background, you may need to consult with your systems administrators / I.T. team. In the references section, you will find all whitepapers on which this chapter is founded – as well as at the end of the chapter itself, for your convenience. It is best if you print them out or save them as PDF files and hand them in a discussion meeting to your I.T. team.
The amount of available exploits for Windows components (remote/local exploitation, privilege escalation) grows, generally, servers and desktops get patched on a set schedule, and some of them lag months behind – in the best-case scenario.
Execution of code on any node should be controlled and impossible without authorization. This means that all applications and executables present in the environment need to be pre-approved and on an authorized list (system) before being allowed execution. This sounds and is a lot of work initially, but as your organization matures and more and more applications are added to the authorized list, the easier it gets and the fewer requests for new additions you will receive. Without this last rule, your defenses will be almost helpless against attacks – even if your nodes are hardened to the maximum possible in their configuration.
Blocking the execution of unauthorized code in any of its reincarnations is the only way to keep your network immune and healthy.
It is no longer enough to block the downloads of executables on the proxy/firewalls – malware now uses encrypted data inside JPG files, unpacks them in memory, decrypts, and executes code and you can’t control or contain that without blocking the execution of the initial malicious payload.
If any malicious payload gets executed and obtains access to a system, the game is over – it can do whatever it wants and security teams would have a very difficult time stopping it. Your goal is to prevent this initial infection from happening.
The vectors of attack are known: USB (including smartphones, flash drives, e-cigarettes, basically any USB device), e-mail attachments, e-mail links, infected web pages, malvertising – all of them rely on the user opening a file, extracting a file from a zip file (sometimes double zipped), clicking on a link or simply loading a web page.
Infected web pages usually rely on unpatched versions of Java or Flash – and they usually succed, as most companies don’t believe they can update Java and Flash at the same pace exploits for them, get released, without breaking legacy applications.
Blocking this specific vector – Java and Flash exploits – is not a part of this chapter, please refer to the next chapter, where I will talk about browser sandboxes and browser isolation.
The reason you can’t control Java and Flash exploits via SRP / AppLocker is simple – if you allow Flash and Java, they become whitelisted and any malicious code anywhere on the Internet is free to exploit your decision at will.
My personal recommendation is to disable Flash completely – I can’t think of a valid reason for having it, now that most video sharing sites are using HTML5 to deliver content, and most modern browsers use HTML5 (I hope you are not using IE8).
Disabling Java in a corporate environment is not possible – but you can disable the execution of Java applets on untrusted sites (sites not explicitly defined in a whitelist). Thankfully Oracle developed Deployment Rule Sets – unfortunately, documentation on that front is lacking. They announced the new feature here –
https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets – but the initial documentation is unclear and easy to follow, according to many people. Still, their documentation and several blog posts, such as http://kylebubp.com/2013/11/use-java-whitelisting-to-further-secure-your-organization/, http://ephingadmin.com/administering-java/, and https://isc.sans.edu/diary/How-To%27s+for+the+Holidays+-+Java+Whitelisting+using+AD+Group+Policy/17267.
Java whitelisting is a highly complex topic – nevertheless, you will need to put it in a standalone project and work through its completion if you want to control this very large execution vector in your environment.
Are you ready to jump right into configuring application whitelisting? Not so fast!
Execution Monitoring
First, you need to know what is happening in your environment. Since by default Windows operating systems don’t have any process execution tracking, you would have to either use SysMon by Microsoft (https://technet.microsoft.com/en-us/sysinternals/dn798348 ) or use a third-party tool such as http://www.nexthink.com/ or https://www.bit9.com/solutions/carbon-black/ (I only recommend products I’ve used, others might exist but I cannot cover all of them in that book, as it would be unfair to mention things I have no experience with personally). In any case, it is imperative that you store all executions of binaries in a central database, away from the endpoint, for later investigations or for real-time analysis and alerting. SysMon logs can be sent and analyzed in a SIEM, for example. Having a log like this will help you with the actual application whitelisting implementation process – without it, you will be working with one eye closed and one hand tied behind your back.
(Note on Sysmon: the best article I’ve read about it – which tops even Microsoft TechNet – is at https://jon.glass/discusses-sysmon-v2/ and https://jon.glass/discusses-sysmon-v2-filtering-rules/)
I will talk more about system monitoring in the SIEM and Logging chapters – this is relevant just for this chapter.
Now that you’re done with your process monitoring, you can start planning the actual application whitelisting process.
Your first step is to determine which technique is more suitable for you – using Software Restriction Policies or AppLocker.
Microsoft has created a good (although not that great) comparison table here:
https://technet.microsoft.com/en-us/library/ee424371%28v=ws.10%29.aspx
This is also the point when you should decide if you are going to use Whitelisting or Blacklisting. Because you can block execution from specific folders and still be relatively protected from Internet threats (the folders used by browsers as download and temporary file storage).
I will only do a small deviation from the Whitelisting topic to define the best practice for Application Blacklisting:
Application Blacklisting with SRP
Not as recommended nor as secure, but some organizations still prefer to go with it as it is less hassle to maintain (but trust me, much more hassle if you get compromised and your whole business shuts down for a week, with your job being given to someone else as a result).
For application blacklisting to work correctly, you will need to create 2 separate accounts per user for your admins – and your regular users should have no admin rights.
Your Admins should never log in to Windows as Administrator – in fact, their log on locally right should be denied. They will only run applications with admin rights using the Run As… function, and their administrative users should be exempt from most of the SRP rules – all of them except execution from Temporary Internet File and Downloads folders.
For Local Group Policy editing, when the machine is not part of the domain, you will still be able to set up two sets of group policies for two groups of users (admins and non-admins(built-in)) following this guide:
https://technet.microsoft.com/en-us/library/cc766291%28v=ws.10%29.aspx
Here are the rules:
Software restriction policies:
-Security Levels:
–Default: Unrestricted
Additional Rules:
Path Rules: (set all to Disallowed)
%Temp%*
%USERPROFILE%AppDataLocalTemp*
%USERPROFILE%AppDataLocalMicrosoftWindowsINetCacheIE*
%USERPROFILE%AppDataLocalMicrosoftWindowsTemporary Internet Files*
%USERPROFILE%Local SettingsTemp*
E:*
F:*
Explanation: blocking execution from E: and F: usually is enough to block execution from USB devices. Blocking execution from temporary internet files prevents many malicious programs from silently downloading and running executables, the same applies to the Temp folder. The %temp% rule prevents execution from opened Zip archives (for example, when a user opens a zip file and then runs the “PDF” .exe from inside the zip file directly).
Another way to block USB execution is using Group Policy Editor and using the specific policy setting:
Administrative Templates, System, Removable Storage Access:
Yet another way to block removable storage execute access is using the tool Ariad by Didier Stevens – http://blog.didierstevens.com/programs/ariad/
As already mentioned, only admins will run installations with the rules above. Another consequence is that some software, which loads and runs executable code to/from temporary locations, will fail to run. You will have to make the decision which is more important: having this software, finding other options, or enabling exceptions in order to run the software.
Moving users with this software to groups with other rules applied (specific rules disabled, all the rest – still on) might work.
Once again: application blacklisting is only recommended for non-critical environments when you have excellent control over the web traffic (website whitelisting) and over your firewall, utilizing a next-generation firewall technology with IDS/IPS turned on protocol whitelisting, and so on.
In other words: use with extreme caution, use only if you want your security to be slightly better than no execution prevention at all.
One more thing that will be beneficial for you before starting with Application Whitelisting is to read the U.S. DoD / NSA leaflets on the topic (just 2 pages each): https://www.nsa.gov/ia/_files/factsheets/i43v_slick_sheets/slicksheet_applicationwhitelisting_standard.pdf and https://www.nsa.gov/ia/_files/factsheets/Application_Whitelisting_Trifold_Jan_2013.pdf. The same can be provided to your team/manager/executives for their understanding before any further discussions arise (the logos on the paper weigh more than the paper itself).
AppLocker Whitelisting Limitations
Please keep in mind that AppLocker only prevents the execution of binaries and scripts from storage media. It does not prevent direct exploitation where code is loaded and executed only in memory – for that, you will need to have other controls, limiting the amount of foreign code which can touch your internet-facing applications (such as browsers). Most state-sponsored exploits in 2015 and onwards operate in memory only – you will have to think about mitigations such as website whitelisting, java applet whitelisting, disabling Flash completely, browser sandboxing, and others mitigate state-sponsored malware.
Also, by default, DLL control rules are not enabled and need to be created – without them, you will be missing a significant portion of the benefits provided by AppLocker. A lot of the malicious code is distributed and used in the form of DLLs.
Mitigation for common attacks against AppLocker:
- Deploy SMBv2 packet signing to mitigate Man in the Middle style attacks.
- Restrict paths that binaries can be executed from to local non-removable media sources where possible.
In order not to turn this book into an application or protocol-specific manual – and because much better manuals have been written by military organizations already, I will just leave 4 links on the topic here:
http://www.ncsc.govt.nz/assets/NCSC-Documents/NCSC-Applocker-public-v1.0.5.pdf – the New Zealand guidance on Applocker implementation – probably the best guide out there.
The Australian Government Department of Defense has also published a short paper on application whitelisting, located here: http://www.asd.gov.au/publications/protect/Application_Whitelisting.pdf – it’s not a stellar one, but nonetheless is useful (in my opinion, the most useful part of that document are the two links at the bottom of it).
It goes hand in hand with their page for Mitigation Strategies, located at http://www.asd.gov.au/infosec/mitigationstrategies.htm
The sister page of NSA on mitigation strategies is located at https://www.nsa.gov/ia/mitigation_guidance/ – and it also includes guidance on mitigating targeted malware at https://www.nsa.gov/ia/_files/factsheets/Defending_Against_Destructive_Malware.pdf
One question I keep asking myself: if http://support.microsoft.com/kb/2532445 has been out for four years, why none of the papers listed before – NSA, Australian – mention it? Do they want you to believe AppLocker is safe without this hotfix, to be able to bypass it? In any case. You got the proper implementation here, with one exception. http://www.wilderssecurity.com/threads/circumventing-srp-and-applocker-by-design-with-sandbox_inert-new-process.291593/page-3 is still not fixed.
I generally recommend free and open source solutions and try to avoid recommending commercial solutions due to the many “snake oil” salesmen in that arena. But… in this case, I can recommend Bit9 + Carbon Black. It’s expensive – and effective.
Practical advice
The articles linked above will give you best practices for implementing Applocker.
My practical advice: have 2 users (I mentioned this multiple times throughout the book) for your admin users and for the users who need exceptions when running specific tasks/software.
You can have different policies applied to 2 or more groups of users, based on their needs.
Sometimes, you may even need 3 users for your admins if they’re doing installations – especially if you have different rules for accessing the Internet for users and admins (generally users with admin rights should not have Internet access).
Other uses of SRP & Applocker include the ability to block the execution of an outdated or a vulnerable application until a patch is deployed (actually forever – you don’t need that older version running ever again once it’s blacklisted). For example, as soon as a new version of your favorite PDF reader comes out, block the hashes of all previously known versions.
You should block any scripting interpreters not used on a specific machine/server/subnet for business purposes – that includes python, Perl, cscript, on some machines – even powershell.exe, AutoIt, etc. One more idea on PowerShell – you should DISABLE it with a policy for all non-administrative users, and administrators should only use it on specific machines. Remember that Powershell is called “a post-exploitation framework” by hackers – they value it more than gold when available after an initial compromise.
Finally, this document is in the list of references of this book at the end of it – but I know nobody reads the list of references. But you should read it! https://dl.mandiant.com/EE/library/MIRcon2014/MIRcon_2014_IR_Track_APT_Detection.pdf
2-factor authentication for servers
Using password-based authentication is a call for trouble. Your passwords (and even Kerberos authentication tickets) can be stolen in so many different ways there is not enough space on one page to list them. Think software keyloggers, hardware keyloggers (wired and wireless, including ones planted inside your keyboard), remote micro cameras, exploits, etc.
One of the best solution to thwart attempts to use a stolen password to authenticate to your critical servers is 2-factor authentication.
http://blogs.msdn.com/b/rds/archive/2014/04/30/using-rd-gateway-with-azure-multi-factor-authentication.aspx is one suggestion by Microsoft on using Azure services for 2-factor auth.
Besides the commercial applications (which are multiple and not mentioned here) you could even use open source software:
https://github.com/LastSquirrelIT/MultiOneTimePassword-CredentialProvider and http://www.multiotp.net/ as well as https://github.com/sbeh/RDP-OTP for Windows-based systems.
For Linux and BSD there are many more options – for Debian-based distros, just apt-cache search 2-factor or OTP, and you will find plenty.
Biometrics
Commercial solutions providing biometric matching of typed passwords are excellent. I’ve tried several, and they work well – some even lock a desktop as soon as they detect a typing pattern that is not recognized as the rightful owner/user of the system. This eliminates the risk of losing a device and is more user-friendly, potentially deployable not just for your admins and core servers but for the whole organization.
Caution:
Be careful to prepare for the loss of your 2-factor auth device/key/phone – and have procedures in place to roll back to password authentication.
Have a procedure in place to deactivate access for stolen/lost 2-factor auth devices.
Maintaining your operating systems
I don’t know if I should even mention patching. But noticing how many organizations put patching behind and are sometimes years (!) behind schedule on updating essential components after an exploit has been published for them, maybe it’s a good idea to repeat a well-known truth.
If your organization does not have an official patch policy, this could lead to chaos and, depending on the emotional disposition of your system admins, whether your devices will be patched on time or not.
That is why I recommend creating a patch policy based on https://www.first.org/cvss/cvss-based-patch-policy.pdf – as it strictly defines the timelines depending on the patch and vulnerability criticality.
Always be careful with devices brought in by external vendors – servers, appliances – everything which contains an operating system of some sort – as many times vendors are only trying to sell a product and rarely strive to keep it updated.
*Everything* should be patched – everything which is patchable and for which a security patch has come out must be patched as soon as possible, according to the above or similar policy. Ensure you have the proper mailing lists and subscriptions to receive notifications on new security patches from all vendors used in your environment. Make successful on-time patching part of the KPIs of your system admins and infosec teams.
