Mike Wills - The Official (ISC)2 SSCP CBK Reference

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.

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.

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 of remote users. By 1984, it started to see widespread use in Unix-based server systems; Cisco Systems began supporting it and later developed a proprietary version that it called Extended TACACS (XTACACS) in 1990. Neither of these was an open standard. Although they have largely been replaced by other approaches, you may see them still being used on older systems.

TACACS+ was an entirely new protocol based on some of the concepts in TACACS. Developed by the Department of Defense and then later enhanced, refined, and marketed by Cisco Systems, TACACS+ splits the authentication, authorization, and accounting into separate functions. This provides systems administrators with a greater degree of control over and visibility into each of these processes. It uses TCP to provide a higher-quality connection, and it also provides encryption of its packets to and from the TACACS+ server. It can define policies based on user type, role, location, device type, time of day, or other parameters. It integrates well with Microsoft's Active Directory or with LDAP systems, which means it provides key functionality for single sign-on capabilities. TACACS+ also provides greater command logging and central management features, making it well suited for systems administrators to use to meet the AAA needs of their networks.

LDAP is a directory service based on the X.500 Directory Access Protocol standard developed by the International Telecommunications Union Technical Standardization sector (known as ITU-T). It was designed to take advantage of the IP protocol suite, which evolved after the adoption of the X.500 Directory Access Protocol. LDAP is often compared to an old-fashioned telephone directory. An LDAP server contains information about users in a directory tree, and clients query it to get details. Large enterprises maintain replicated LDAP servers at various points across the enterprise to facilitate quick response.

Each entry in an LDAP directory tree is a collection of information about an object, pointed to by a unique identifier called a distinguished name (DN). The DN represents the complete path in the tree to the desired entry. A set of named component parts called attributes hold the data for that entry. Various user attributes are typically stored in LDAP directories, including telephone numbers, physical addresses, postal addresses, and email addresses.