info@teal-consulting.de       Tel: 0211/936752250211/93675225 

Follow TEAL:                   

ESAE series part 4 – Protective measures for the environment - TEAL Technology Consulting GmbH
1819
post-template-default,single,single-post,postid-1819,single-format-standard,bridge-core-3.1.4,,qode-title-hidden,qode-child-theme-ver-1.0.0,qode-theme-ver-30.3,qode-theme-bridge,disabled_footer_top,qode_header_in_grid,qode-wpml-enabled,wpb-js-composer js-comp-ver-7.5,vc_responsive

10 Sep ESAE series part 4 – Protective measures for the environment

Posted at 09:03h in SAE by

In this part of the series, we would like to reiterate the requirements from part 2 (Link) and demonstrate which measures have been taken to protect the critical systems.

However, before we start off with the requirements, there needs to be clarity over which systems are classified as tier 0, tier 1 and tier 2. This definition may vary depending on the client and the situation. The scope of the specific client scenario was, as described in part 2, the Global Authentication Service (GAS), not directly all client systems. That’s why we chose a classification that diverts from the Microsoft definition:

Here, as a small recap, the requirements from part 2 again:

Layer separation and least privilege administration

  • Physical and logical separation of the tier 0 systems from tier 1 and 2
  • No use of tier 1 and 2 services that could compromise a tier 0 system (e.g. a monitoring agent)
  • Access restriction of the accounts (administration only on the same tier. No login on a lower tier):

Source: Microsoft

  • Principle of least privilege with just-in-time administration

Hardening

  • Hardening of all systems according to best practices.
  • Administrative access only via hardened privilege admin workstations with multi-factor authentication
  • Encryption of the hard drives
  • Installation only from trustworthy sources (hash control)
  • Long passwords with short durations. For service accounts, group managed service accounts are used, if possible

Processes and operation

  • Reduction of tier 0 administrators to a minimum
  • Well-trained staff with positive proof of good conduct

Below, the requirements and measures are displayed – in table format, for reasons of clarity of the overview. For some formulations above multiple requirements need to be derived and as some client-specific framework conditions were pre-existing, there are ultimately more requirements than the number of bullets above.

​Requirement ​Measure
​ R1. Physical separation ​M1: The systems have to be set up in a separate data centre/room/rack with respective access control. In the specific client scenario, hosting was provided by a co-location provider. Access to the rack is only granted to tier 0 administrators. The decision to host the systems with a co-location provider (which naturally has physical access to the systems) results in another requirement:
​R2. Encryption of all hard drives of the Hyper-V hosts​ ​M2: Fortunately, with Bitlocker, Microsoft directly delivers the right tool as part of the operating system. The recovery keys were stored in the AD and in a password safe for security’s sake.
​R3. Logical separation ​M3: Due to the classification into the tiers during the project, the requirement was implemented as follows: tier 0 and tier 1 systems are separated from all other systems by a firewall. The firewall may of course be operated only by an tier 0 administrator. With our client, however, the decision was made to have the entire network for GAS operated by one provider. In order to prevent them from being able to capture sensitive data or compromise the systems, this results in the following additional requirement:
​R4: Encryption of any network traffic within the GAS environment​ ​M4: To avoid having to deal with the different encryption options at the application level, the requirement was configured through Windows IPSec encryption and implemented via Group Policy.
​R5: No usage of tier 1 and 2 services that could compromise a tier 0 system ​M5: This requirement led to the implementation of a WSUS and a SCOM specifically for GAS.
​R6:  Access restriction of the accounts (administration only on the same tier, no login on lower tier) ​M6: For every tier, corresponding admin users were created. If a person was allowed to administer both CSI tier 0 and CSI tier 1 systems (due to the small scope), two accounts were created for this person.
​R7: Principle of least privilege with just-in-time administration ​ ​M7: For this, the admin forest described in part 2 of the series was set up with MIM-PAM and corresponding roles.
​R8: Hardening of all systems according to Best Practice​ ​M8.1: Whenever possible, the systems were installed in the core variant.

M8.2: The Security Baseline GPOs for Windows Server 2016 have been implemented. In the baseline already, some services were deactivated. The following services which were also not needed had to be deactivated via registry key: HKLM\System\CurrentControlSet\Services\CDPUserSvc HKLM\System\ HKLM\System\CurrentControlSet\Services\OneSyncSvc HKLM\System\CurrentControlSet\Services\OneSyncSvc<random number>CurrentControlSet\Services\CDPUserSvc<random number> HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc HKLM\System\CurrentControlSet\Services\PimIndexMaintenance HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc HKLM\System\CurrentControlSet\Services\PimIndexMaintenanceSvc<random number>eSvc<random number>​
​R9: Administrative access only via hardened privilege admin workstations with multi-factor authentication​ ​M9.1: Notebooks were purchased specially for the purpose of the administration of the GAS environment

M9.2: The security baseline GPOs for Windows 10 were implemented.

M9.3: In our client scenario, a certificate + username/password which is checked by the VPN appliance in GAS serves as a second factor.
​R10: Encryption of the hard drives​ ​M10: All hard drives (OS + data) of all systems (hosts, VMs, PAWs) were encrypted using Bitlocker.
​R11: Installation only from trustworthy sources (hash control) ​M11: When installing all components, the clean source principle was applied. This means that either the hash released by the manufacturer was checked or the file was downloaded twice via different network links on different devices and the hash was compared. The latter offers no protection against files that are already compromised on the source server, of course, but at least it prevents a compromise along the way.
R12:  Long passwords with short durations. For service accounts group managed service accounts, if possible ​M12: CSI tier 0 accounts: 20 characters, 60-day duration. CSI tier 1 accounts: 15 characters, 60-day duration. Service accounts: 30 characters, 200-day duration.
​R13:  Reduction of tier 0 administrators to a minimum ​M13: A virtual team of several organisational units was formed which is fully responsible for the GAS environment. This prevents too many people becoming tier 0 administrators down to the classical separation of responsibility in, among others, operating system, database, and application administrators.
​R14: Well-trained staff with positive proof of good conduct​ ​M14: For the virtual team, only long-term employees who were specially trained for the administration of the GAS environment were selected.

Below, we’ve listed a few further requirements and measures that we haven’t mentioned in part 2 of the series for reasons of clarity, but which shall not be missed in this detailed article.

Requirement​ ​Measure​
​R15: Forwarding relevant logs to the central log management system for evaluation via the Security Information and Event Management (SIEM)​ ​M15: In order to collect the logs within GAS, they are forwarded via Windows EventLog to an NXLog server within GAS (source computer initiated), which forwards the collected logs to the central log management. The logging policy is configured centrally using Group Policy/Subscription Manager.​
​R16: Backup RTO is 4 hours, RPO for the AD is 1 day; for all other systems, it’s a week​ ​M16: Not very exciting as a requirement, but not a trivial one either in the implementation within the CSI context. The enterprise backup solution is not a CSI tier 0 system and isn’t able to encrypt the backups in such a way that the keys are known only to CSI tier 0 administrators. Setting up one’s own backup infrastructure for GAS only wasn’t possible for financial reasons. The problem got solved with a scheduled task which executes a script that takes a backup of the servers into a VHD using Windows Server. The VHD is encrypted using Bitlocker and copied to a file server outside the GAS environment. The number of local and remote copies is configurable, of course. The keys are managed by the administrators of each respective component and are different for each server.​
​R17: Installation of all security patches within 14 days​ ​M17: Since, also for financial reasons, no management solution similar to SCCM could be set up for GAS only, a WSUS serves as an update source. The servers are configured in such a way to automatically download updates. That way, a quick installation by administrators is possible. The updates of the other software and hardware manufacturers currently still have to be checked and installed manually.

The list of measures shows how complex the implementation of a secure ESAE-like environment is. In the next part of the series, we would like to take a closer look at one particular measure: the encryption of network traffic using IPSec.

Source: freepik.com

<< Back

LATEST POSTS