After Hyper-V HGS and VM protection with VMWare, now the third part of our (E) SAE Deep Dive Series follows. Maybe you follow us on LinkedIn, Xing, Facebook, Instagram or Twitter and have already seen our infographics for the Top Ten (E) SAE measures. If not, make sure to catch up 😊:

• LAPS
• Reduce high privileged service accounts
• Change all non-personal passwords
• Separate admin accounts

But why are we telling you this? Because in this blog series we have decided to dedicate a post to every measure from our top ten list of the most cost-effective measures.

Today we start with the separation of administrative and non-administrative user accounts. This involves using separate accounts for daily productive work, such as e-mail and office applications, and for system administration. The goal is to ensure that an account for productive work never has administrative permissions for infrastructure, server systems or backend applications. The topic is certainly not new and has been propagated for more than a decade. The BSI, for example, provides for the separation of user and administration accounts in the IT-Grundschutz Compendium in the implementation instructions for the SYS.2.1 General Client module:

SYS.2.1.M2 role separation

Basically, a distinction can be made between identifiers for users and administrators. Only administrators manage the IT systems, while normal user IDs only have the rights to perform their workstation-specific tasks. Normal user IDs must not have administration rights in order to protect the operating system and the configuration of the clients from accidental, negligent or intentional modification by the users.

Nevertheless, we see again and again with our customers that this principle is not adhered to. Therefore, we would like to show once again with an example why separation is important.

In 2011 the security company RSA Security was affected by a hack. Some employees had received a phishing e-mail with an Excel attachment. One of the employees opened an Excel file named 2011 Recruitment Plan.xls, which contained a macro that exploited a zero-day vulnerability in Adobe Flash Player and installed Poison Ivy remote control software. The description of the hack on the RSA company blog omits some details, but since Poison Ivy usually installs itself into the Windows system directory, the user who opened the Excel file obviously had local administrator rights on the Windows end device. This gave the attacker the ability to gain access to the company network and to probe servers from there and take over if any vulnerabilities were found. (It is not entirely clear whether the end user’s account still had administrative privileges in the back end. Nevertheless, the scenario illustrates the danger you are running into here). The attacker came into possession of sensitive data for calculating one-time passwords (OTP) and RSA Security ultimately had to replace around 40 million SecurID tokens of their customers. The total cost to the Group was estimated at 66 million US dollars.

This example clearly illustrates that accounts for productive work, with which e-mail in particular is accessed, must not have local administration rights and administrative permissions on infrastructure, servers, middleware and applications.

In our following infographics (don’t forget to follow us on LinkedIn, Xing, Facebook, Instagram and Twitter  to make sure you don’t miss any of the graphics 😉), we will show the whole thing again schematically.

Bob uses the same account for his daily work and for server administration. Bob becomes a victim of a phishing attack and the attacker can use Bob’s account to install malware such as the remote control software mentioned in the RSA example and steal data from the company network without further privilege escalation.

The safe procedure is visualized in the following diagram. Alice is logged on to her office PC with her normal work account and performs her daily work. This account has no additional authorizations, including local administration authorizations on her office PC. Since phishing attacks are becoming more and more sophisticated and, as recent cases have shown, are difficult to detect even by well-trained employees, Alice can also become a victim of them, but the effects of the attack are mitigated. The attacker has to find a way of privilege escalation to be able to execute a tool such as mimikatz. Mimikatz would then be able to read passwords, hashes, PINs and Kerberos tickets directly from the main memory or record password entries. However, this requires administrative privileges on the Windows system.

It is also clear that the mere separation of accounts alone does not reflect a fully comprehensive security concept. Of course, further mechanisms must be implemented, dedicated admin accounts are only the beginning. Just have a look at the next blog articles to learn more…

In summary, small cause great effect. For us, this is clearly the number one cost-effective measure. I hope we were able to recall the topic, as I am sure everyone of you has heard. I am sure that it is strictly implemented by you all, or 😉?