Securing client infrastructure is a major challenge for IT departments worldwide. Time and again, companies are compromised due to a lack of security precautions. Often, however, simple configuration changes could have prevented these initial gateways.
In this document, some of the most important security measures - tailored to the infrastructure of the TU Wien - are documented.
These measures are based on the document "IT Security Recommendations for Users".
1. Password Policy
Passwords secure our digital identities. Without an appropriate technical password policy, however, end users often use insecure combinations. For example, poor quality and very short passwords (e.g. 12345) can be used. These are also not protected against bruteforce attacks. Therefore, it is recommended (also based on the NIST Digital Identity Guidelines and the currently valid Privacy and Information Security Guideline) to implement a minimum password length of 8 characters, as well as an account lockout (e.g.: 3 attempts; then 10 minutes lockout).
If there is a central Active Directory in the infrastructure, the necessary changes can be implemented there. Instructions on how to do this can be found at:
- Password Policy: https://activedirectorypro.com/how-to-configure-a-domain-password-policy/
If there is no Active Directory, it is recommended to make the corresponding settings in the default image so that at least future end devices are secured accordingly. In this case, the configuration also applies to local user accounts. The following Microsoft document describes how local group policies can be implemented:
Benefit: End-user passwords must meet minimum quality requirements and are protected against bruteforce attacks.
2. PowerShell Security
The program "PowerShell" is a powerful tool in Windows environments and designed to facilitate the daily work of administrators. "However, PowerShell is also the tool of choice for attackers. Therefore, it should be secured as far as possible.
2.1 Disable Powershell V2
Especially the outdated version 2.0 is very popular among attackers, as it contains relatively few security options, which is why it is recommended to uninstall it. In normal operation, this should usually have no effect, since scripts can usually be executed with newer PowerShell versions.
The following command allows you to uninstall the outdated version without rebooting:
Dism /online /Disable-Feature /FeatureName:"MicrosoftWindowsPowerShellV2Root"
If there is a central Active Directory in the infrastructure, a Scheduled Task can be used to execute the above command (as SYSTEM) on all clients and servers: https://www.windowspro.de/wolfgang-sommergut/geplante-aufgaben-ueber-gruppenrichtlinien-anlegen-loeschen (only in German).
If there is no central Active Directory, it is recommended to disable PowerShell version 2 in the default image (using the command documented here).
Advantage: If Powershell v2 is deactivated, attackers can no longer use this version, which means that many attacks come to nothing.
2.2 Powershell Constrained Language Mode
After Powershell version 2.0 has been disabled, as described in the previous chapter, the Constrained Language Mode can be introduced. This makes it impossible for attackers to use Powershell.
The use of AppLocker is recommended for implementation. The following tutorial on TenForums shows a corresponding implementation via Active Directory (for Windows 10 Enterprise or Education). However, this can also be implemented in a standard image. https://www.tenforums.com/tutorials/124016-use-applocker-allow-block-script-files-windows-10-a.html
The main advantage of this solution is that your own scripts can be explicitly excluded from this restriction.
Fig. 1: Local Security Policy
As an alternative, the environment variable __PSLockDownPolicy can be set in exceptional cases. See for this https://itfordummies.net/2015/06/01/powershell-constrained-mode/. All scripts that require the full Powershell functionality can explicitly request it using the Remove-Item Env:_PSLockdownPolicy
Advantage: By using the Constrained Language Mode, the misuse of Powershell is made much more difficult.
Office macros are a commonly used gateway for initial infection. With Office 2016, Microsoft published a new group policy called „Block macros from running in Office files from the Internet“, which enables additional security measures. If this is activated, macros can no longer be executed in documents from the Internet (downloaded or sent by mail).
Fig. 2: MacroSecurity
The user still has the option to unlock important documents immediately. Internally stored files with macros (e.g.: on file servers) are unaffected by this setting and function as before (provided that the internal file server is classified as "Intranet").
End users can use the "File Properties" feature to remove the "mark-of-the-Web" and explicitly agree to macro execution.
Fig. 3: View file properties
The following link describes how to roll out the setting via an Active Directory: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/
If no Active Directory is available, it is recommended to discuss with the user whether he/she needs the macro execution option. If not, this should be deactivated as described in the document "IT Security Recommendations for Users".
4. Dangerous file types
Under Windows, certain script files can be executed directly with a simple double-click. This standard configuration is abused by a variety of malware. Currently, Cryptolocker in particular relies on this technique. Therefore, it is recommended to adjust the Windows file association so that instead of executing the script file, it is opened in Notepad, for example.
Critical file types: .hta, .vbs, .js, .jse, .vbe, .reg
If an Active Directory exists, the following instructions can be used to automatically roll out the configuration to all end users: https://community.webroot.com/general-140/disable-execution-of-script-files-303074
If no AD is available, the setting can already be implemented in the default image with the free tool FileTypesMan (https://www.nirsoft.net/utils/file_types_manager.html).
Fig. 4: View FileTypesMan
Advantage: The configuration makes it more difficult for the attacker to execute dangerous code.
5. Hard disk encryption
A lot of important company data is not only stored on central file shares, but also on end users' devices. Since not all PCs currently use hard disk encryption, this data can be read very easily in the event of device theft. All that is needed is to remove the hard drive and connect it to another device.
To prevent this attack, it is recommended to introduce hard disk encryption with TPM support for all end devices. Both Windows (Microsoft Bitlocker) and most virus scanners offer simple ways to encrypt devices easily and transparently.
If an Active Directory exists, the deployment can be fully automated: https://www.der-windows-papst.de/wp-content/uploads/2017/11/Windows-Bitlocker-einsetzen.pdf (in German only).
If no AD is used, the BitLocker configuration must be ensured during the deployment process for new end devices. This is also essential from a data protection perspective.
Advantage: If a computer is lost or stolen, important data cannot be accessed without authorization.
6. Screen lock
If an employee leaves his or her workstation, the respective PC should lock automatically after a certain period of inactivity. It is recommended to set the limit to 5 - 10 minutes.
For all Active Directory environments, the setting can be rolled out relatively easily and quickly via the group policy "Interactive logon: Machine inactivity limit". See for this: https://docs.microsoft.com/en-us/windows/security/threat-protection/security-policy-settings/interactive-logon-machine-inactivity-limit
Fig. 5: Local Security Policy
In stand-alone infrastructures, the configuration should be integrated in the default image (also via the above policy).
Advantage: Devices do not run (sometimes for hours) unlocked. This prevents unauthorized access to the data stored on them.
7. Local administrators
Modern malware, such as Trickbot, can misuse the same administrative credentials of local users with so-called "pass the hash" attacks for spreading in the network. If the malware is able to read the hash of the administrator's password on one computer, and all or many computers use the same password, it is very likely that it will spread throughout the infrastructure. It is therefore crucial to use different passwords for the local admin users on all end devices.
In Active Directory environments, Microsoft LAPS can be used for this purpose. This tool, which is free of charge but supported by Microsoft, is used to randomize the passwords of the local administration account. LAPS should be installed on clients as well as on servers. A corresponding implementation can be realized in about 1 - 4 hours. In the background, a client side group policy extension is installed on all devices (via e.g. GPO). Afterwards, the computers automatically generate a new administrator password at certain intervals and store it in the AD computer object. Appropriately authorized admins can read it out as needed.
For all non-centrally managed devices, for example, a random password could be generated during deployment (net user administrator /random) and stored in a secure location (e.g.: shielded fileshare).
Advantage: If a system is compromised, it is no longer possible to propagate via the local administrator.
https://www.tuwien.at/index.php?eID=dms&s=4&path=Richtlinien%20und%20Verordnungen/Datenschutz%20und%20Informationssicherheit.pdf (zuletzt abgerufen am 20.01.2021).
 See for this: https://devblogs.microsoft.com/powershell/powershell-constrained-language-mode/ (zuletzt abgerufen am 20.01.2021).
 See for this: https://www.microsoft.com/security/blog/2016/03/22/new-feature-in-office-2016-can-block-macros-and-help-prevent-infection/ (zuletzt abgerufen am 20.01.2021)
 See for this: https://blog.thesysadmins.co.uk/group-policy-internet-explorer-security-zones.html (zuletzt abgerufen am 20.01.2021).