Читать книгу The Official (ISC)2 SSCP CBK Reference - Mike Wills - Страница 171

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.