While we are on the topic of WWW, let’s talk about a very important topic – the browser your employees are using to access the Web (and your own Intranet).
It is a sad fact that many organizations are still using IE (some even avoid updating to the newer versions of it for ‘compatibility reasons’).
While IE can be kept relatively secure (with ad blocking at the gateway level, emet, removing Flash, switching to a different PDF reader, implementing the proper STIG and securing its settings to the maximum level possible), it is still a good idea to replace it with something modern.
Microsoft Edge is coming out with Windows 10 – but until then I recommend switching to Google Chrome.
You don’t even have to re-invent the wheel for the deployment phase – NSA has already written the most comprehensive guide on a secure deployment of Google Chrome here: https://www.nsa.gov/ia/_files/app/deploying_and_securing_google_chrome_in_a_windows_enterprise.pdf
It is from 2012 and a bit outdated but the basic principles are still valid.
The policy templates for deployment can be found here:
https://www.chromium.org/administrators/policy-templates – specifically, https://dl.google.com/dl/edgedl/chrome/policy/policy_templates.zip
If you need a detailed description of any policy mentioned in the guide or in Chrome’s about:policy, the folder above contains a help html file: policy templatescommonhtmlen-USchrome_policy_list.html
The ADM policy template can be imported to your domain controller or to a workstation locally.
It is a very good idea to combine the NSA manual with the IASE DISA Google Chrome STIG:
http://www.stigviewer.com/stig/google_chrome_current_windows/
by generating a matrix in Excel or your favorite spreadsheet application where you could map the matching / overlapping / unique configuration settings per guide and decide which ones to test and implement. Focus on the red and yellow findings in the STIG.
Implementing a blacklisting/whitelisting policy in Chrome
I’ll show you a very clever trick. It is recommended that you implement a whitelisting policy, which will greatly improve your security – but if that is not possible a blacklist is an option, too.
Navigate to the Google section in the policy editor, find Google Chrome, in the right pane you should see a list of policy settings. Find the following 2 settings:
(Block access to a list of URLs and Allow access to a list of URLs)
To enable a whitelisting (only specific hosts can be reached) policy, enable both. In the Block access setting, you will see an option to show the editor box for entering new URLs to block:
For a Whitelist, block ALL websites (careful, settings apply immediately) here by entering an asterisk character and saving: *
Then in the “Allow access to a list of URLs”, enter the list of URLs you want to allow (up to 1000, the rest will be ignored):
In the above example, the website and all sub-domains and folders – coursera.org – will be allowed.
The about:* and chrome://policy/ need to be whitelisted if you want to be able to display the current policy settings by typing about:policy in the address bar. If you don’t want to enable your users seeing the list of blocked sites (good idea to disallow that), remove the aforementioned entries.
To enable just a list of blocked sites, instead of an asterisk just enter up to 1000 blocked domains. Any domains after 1000 will be ignored.
Another very useful set of settings can be found in the Google Chrome > Content Settings branch.
Specifically “Allow JavaScript on these sites” and the respective “Block JavaScript on these sites”.
Their logic is the same as above.
In “Content Settings”, the “Default plugins setting” should be as in the screen below:
If Chrome is not your favorite, you can and should still refer to the IASE DISA Application Security – Browser Guidance: http://iase.disa.mil/stigs/app-security/browser-guidance/Pages/index.aspx
