Defending Against the “Compromised Insider”
- September 28, 2018
- 348 views
Today’s utilities face a growing litany of digital threats, from SCADA targeting malware to air-gap jumping techniques, anti-forensics tools and more. But for the average utility today, one of the biggest risks they face is a basic one — the “compromised insider.”
A constant refrain in the security world is that people are the weakest link in any security framework. This remains true today and it will become even more important years from now, as security technologies advance, continually raising the costs and difficulty level for attackers. Surveys consistently show that attackers prefer human targeting in order to bypass technical security controls.
The easiest way to compromise a network or physical facility is to bypass the security perimeter altogether and simply hijack the access of a trusted employee. This can be accomplished by stealing the employee’s password or network credentials through social engineering and other tricks (examples include phishing emails, “vishing,” fake websites, fileless malware, web-based attacks like XSS and reusing stolen passwords from other breaches).
Once the attacker has this access, he or she can login to the system as the trusted user, access everything that person can access and perform whatever functions that person is allowed to perform.
The best way to defend against compromised insider attacks is to have a strong privileged account management (PAM) program in place.
Here is a brief overview:
The challenge for utilities:
The control and monitoring systems used in industrial controls – including the utility industry – were developed in a far different threat environment than what we now face:
— Isolated dedicated networks were used
— The system implementation depended far more upon numerous trained individuals rather than centralized automation
— Sophisticated state-level attack frameworks and associated toolsets were not widely available
Now systems are heavily automated, dedicated networks have been abandoned for the ubiquitous and inexpensive internet, sophisticated state level attack toolkits are widely available, and state level attacks on utility networks have already occurred in Ukraine and Estonia, in addition to many malware infections across the world, including the US.
A major risk — shared management:
Traditionally, enterprises — and utilities — have deployed servers using shared management/root/administrative keys. These could be the server root keys for a cluster/workgroup of *nix servers, or a domain administrator key for a group of Windows servers.
These shared keys made management simpler, allowing for easy management, process control and scripting by multiple administrators with access to the appropriate keys. However, this setup also means that a compromise of any one machine connected to that workgroup enables the attacker to compromise all systems with which it shares a key. That is a major vulnerability, particularly for a critical environment like a utility. Essentially what it means is that if a single user or user device is compromised, the attacker can spread laterally throughout the network, wreaking untold damage on the utility’s network, data and (ultimately) services.
As we look for ways to mitigate this risk, we inevitably come to cryptography - specifically, Public Key Cryptography (PKC). PKC will lock privileged control channels – but it also introduces a complex and expensive Public Key Infrastructure (PKI) overhead – and the imminent possibility of creating a self-inflicted denial-of-service due to the PKI setup, letting certificates expire or management oversight of the PKI. This risk is unacceptable in the utility environment. And experience has shown us that letting certificates expire is all too common an occurrence, even when attackers are not trying to help compromise or shut down the systems.
Privileged Account Management:
Experience from both the governmental and commercial sectors teaches us that organizations need to assume that all but the most strongly managed corporate accounts are likely to be compromised.
Thus organizations need to architect their systems to maintain reasonable security in the face of compromised corporate accounts and desktops. While it is possible to architect and implement secure management systems with isolated management networks, dedicated terminals, jump servers, and the like, the necessary expertise to craft and maintain such environments is in short supply.
Privileged Account Management (PAM) software has been developed by vendors to offer much of the security and capabilities of security-focused management networks, without requiring the security expertise that would otherwise be necessitated.
Privileged account systems typically do not follow the complex PKI model. Rather, they allow each managed system to have unique passwords while also providing a management and scripting interface that hides this complexity from the administrator. Typically, they will allow these passwords to be changed either on a time or usage basis – such as every day, or after each use. Such rapid changes greatly reduce the value of compromised system credentials – in the case of unique credentials that are changed after each session, capture of a credential provides no value as the attacker had to have administrative access to perform the capture and gains neither the ability to access the system in the future, nor the ability to access other systems.
Commercial PAM functionality is often highly configurable. It is possible to configure PAM software securely and follow usage patterns that minimize security risks. It is also possible to configure PAM software insecurely, so that many of the security advantages offered by the PAM software are lost. The makers of PAM software will provide guidance as to how to configure their software securely, but many organizations configure their PAM software to a level that the users hope is secure enough, but is far more convenient to operate. For organizations that are potentially facing dedicated persistent attack, such tradeoffs must be considered very cautiously.
Configuring PAM systems to maximize security protections:
PAM implementations can greatly harden the organization that deploys them. But in the process, they create a particularly valuable and inviting target – the PAM system itself. If an attacker can compromise the enterprise PAM system, the attacker will have virtually free reign within the enterprise’s systems. Thus, even if an organization chooses for its implementation to fall more on the feature/convenience side of the security/convenience balance, it should still focus upon security in its implementation of PAM and the supporting PAM environment.
It is important in the implementation choices to consider the threats. As a starting point, assume that the normal corporate account of the user is compromised (phishing, carefully targeted e-mail, browser compromise, etc.). Unless the organization has taken extensive steps (dedicated locked down thin client, dedicated Secure Administrative Workstation / Privileged Account Workstation with locked down hardware and trusted boot), we should assume that the user’s client system is also compromised. In such situations we must assume that the organization needs to enable its staff to perform security critical operations from compromised systems. This is not something we want to do for the management of the PAM system itself, but the PAM system can be used to provide a security buffer for privileged operations elsewhere in the organization.
The PAM system itself should be isolated and be managed from hardened isolated clients with administrators using second factor authentication tokens such as smart cards, U2F tokens, or the like. If possible, it is best if PAM administration is done from known and preconfigured locations, adding a networking defensive layer to the defensive array. The maker of the PAM software will provide guidance for configuring and managing the PAM system for maximum security.
The PAM system must be configured to provide tool systems / working environments for users who are using the PAM software for their work. These tool systems / working environments should be function specific and provide the tools needed to perform the work for the design functionality – and no more. The requirements for a database administrator are much different than an Apache web server administrator, which are much different than a *nix system administrator, which are much different than a Windows Enterprise or Domain administrator. Users must log into tool systems / working environments that are configured appropriately for the expected functionality.
PAM users must login using second factor tokens – smart cards, U2F tokens, or equivalent over encrypted communications channels from their clients. They log into the PAM system using accounts that are separate and distinct from their normal user accounts, which maps them to tool systems / working environments – where the user does all their work. The user clients provide a screen and keyboard, and hence a compromised client can monitor what the user sees and types, and potentially can inject keyboard strokes and mouse movements. If the user is alert and sees such unexpected behavior, they must shut down their client immediately and alert system management of a compromise. But aside from this, malware on the client can not drive the functionality that the user is exercising, as that functionality is being driven from the tools system / working environment, which is locked down and does not allow user modifications.
The tools systems / working environments hosted by or accessed by the PAM system must be strongly locked down and carefully monitored for unauthorized changes. It is important to try and prevent code / thread injection by attackers in the tools systems / working environments. Thus, if at all possible, scripting in these environments should be either blocked or restricted to known and approved scripts. This is typically accomplished by restricting scripts to pre-established scripts loaded into a scripting directory, or more strongly by script code signing.
Since individual defensive measures may be actively or inadvertently compromised at times, we construct secure operations by layering multiple independent security layers. Thus, implementing network level access control over administrators and sensitive user access to and through PAM adds barriers to an external attacker who is unlikely to have physical access to a control room / control office that has restricted network access to the PAM system.
We have not mentioned the Microsoft Active Directory Enhanced Security Environment (Red Forest) architecture, even though it exhibits all the characteristics of PAM architectures, including the use of SAW’s and PAW’s, because this environment is specific to Microsoft environments; and utility environments are not pure Microsoft environments.
The compromised insider poses a grave threat to utilities, given the sensitive nature of these operations. For this reason, it is critical that operators prioritize this risk. PAM is one of the best methods for doing so, but it is important to avoid key pitfalls when implementing PAM or this security management tool could create its own vulnerabilities. By implementing PAM properly, utilities can be assured of a robust protection for its trusted users.