for controlling software execution is a powerful defense against most of the malware infection vectors by prohibiting any software to execute if it is not on a controlled list of previously-approved tasks. If your organization is not using it, it's only a matter of time before you'll wish you had been. See Chapter 7 for more details.
Manage by Groups, Not by Individual Accounts
Modern operating systems such as Windows 10 or Apple's macOS Mojave provide many built-in features that encourage systems administrators (and sole proprietor end users of SOHO systems) to structure their user IDs into groups and arrange those groups in hierarchies. This again implements separation of duties by means of separately entitling a group of like user IDs with the same set of privileges.
The hierarchy starts with separating IDs into major systems groups: root or superuser, trusted installer, security administrator, user account manager, device manager, and so on. Servers and platforms should form another group, which might also include things like print servers, archival storage systems, or backup/restore platforms.
Your systems administrators (you included!) should recognize and support the need for this. Separate the different job functions and duties that your network administrators, database administrators, and security operations specialists must perform into different user account ID groups; set privileges derived from those official duties for each group; and then create each new user ID within a group for each systems administrator so that this unique user ID inherits the privileges from the group it belongs to.
Now the hard part: your ordinary, everyday users. Systems vendors recognize that the retail buyer of a laptop, desktop, or other endpoint device is a “company of one” and needs to have administrative privileges upon the first power-on boot of their new investment. This is also true of organizational purchases, of course. The “company of one,” however, often ends up with that default user account, created with administrative privileges by the original equipment manufacturer (OEM), being used for day-to-day routine operations. Larger organizations, or just ones with a more astute sense of information security, may need to manage subsets of users with separate but overlapping privileges. Retail stores, restaurants, or even banks, for example, might need to create and manage user subgroups such as:
A severely restricted user group for their customer-facing retail sales and service people
Another group for customer service managers, who might have authorities to override transaction limits or errors or perform lookup operations across a customer's transaction history as part of their duties
A different set of privileges for accounting systems operators that would allow them to process transactions but not initiate or modify them; their managers might be in another user group, which has those specific privileges associated with it
And so on
Note that depending upon the business systems, platforms, and technologies involved, this might require user account provisioning at the operating system level, on specific servers or websites, or within specific applications platforms.
Consider a whaling attack, in which a company's chief financial officer receives an email purportedly from his chief executive officer; he knows that she is traveling and working on trying to put together a new, significant deal for the company. The email says, “It's urgent that you wire transfer $15,000 to our new partners' account to bring this deal home. Do that now, please! The account details are….” Separation of duties by means of user IDs should require that although the CFO might be an approval authority on such a transfer of funds that it's actually a disbursement clerk who performs this action; furthermore, when such a transfer exceeds a certain amount or when other suspicious activity conditions are met, the transfer might take multiple interactions, even by the CEO, before the system will allow the clerk to initiate the transfer with the company's bank systems. (Effective use of an attribute-based access control system can significantly lower the risk that even your smart, savvy CFO, a lower-level accounts manager, or even the disbursement clerk might fall for such a whaling attack.)
Managing entitlements by groups of users is far simpler to do than trying to create individual user IDs as “groups of one” and do it account by account. In almost all cases, situations that seem to suggest otherwise might be best handled by role-based user accounts—by requiring that disbursements clerk in the whaling example do a separate re-authentication as they shift from being a “routine transaction handler” as a role they are fulfilling into being a “high-value transaction handler” instead.
Manage Devices in Groups, Too
Two powerful ideas come together when you think about managing access control for groups of devices rather than one by one.
Trusted classes or groups of devices should serve business functions and have the privileges those devices (and their onboard firmware and software) need in order to fulfill those functions.
Nefarious or untrustworthy devices can easily masquerade as other types of devices, as part of an attempted intrusion into your systems.
Applying these principles would lead us to doubt the legitimacy of a printer, for example, trying to create or modify the security settings on a user or process ID or to raise alarms when an intrusion detection system is trying to access the company's employee or payroll database. As with people-based identities, device-based identities can be spoofed, and legitimate known devices previously deemed to be trustworthy can be misused (deliberately or accidentally). A lost or stolen smartphone illustrates the need for device-level access control.
This is not just an endpoint problem! Poorly secured systems and their Wi-Fi access points can end up allowing an intruder device to spoof itself as the Dynamic Host Control Protocol (DHCP) server for that LAN segment; you shouldn't normally consider service providers such as DHCP as endpoint functions, so over-focusing your security efforts on just the endpoints may not help you much in such cases.
Identity and Access Management Systems
There are several prominent methods for authentication in use today, ranging from getting a simple username/password pair to the use of multifactor authentication to the most complex of modern centralized methods. Some of these methods, such as RADIUS, may seem to be legacy systems, but they are alive and well in the marketplace. Infrastructures that are substantially based on Linux or Unix often use a combination of Kerberos and Lightweight Directory Access Protocol (LDAP). Microsoft-centric infrastructures almost invariably use Microsoft's Active Directory. All of these products and systems, to a greater or lesser degree, are platform- and OS-agnostic, supporting almost any device or network system that can work with their respective protocols. Almost all of them use the X.500 Directory Access Protocol or variations of it.
Remote authentication dial-in user service (RADIUS) originated in the early 1990s as a method of authenticating dial-up customers and has seen much use in support of classical remote access. A RADIUS server, when queried by a client supplying candidate login credentials, can reply with either an Access-Accept message, an Access-Reject, or an Access-Challenge. With this lightweight structure, RADIUS can conduct fast and simple authentications when possible or move on to multifactor authentication and even challenge-response dialogs when those are required. RADIUS can also support extensions, such as the Extensible Authentication Protocol (EAP); it also provides support for roaming users and devices.
The Terminal Access Controller Access Control System (TACACS, pronounced “tack-axe”) grew out of early Department of Defense network needs for automating the authentication
