| Page Properties | ||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
|
Rationale
By definition, a user account or principal may perform operations on systems and operations constitute an inherent risk.
A user account requires oversight during its lifecycle. For instance:
its password may need to be reset,
it must be deactivated or deleted when no longer needed,
someone must be available to answer questions regarding it,
someone must have authority to take decisions regarding it.
Hence, clear ownership must be assigned on user accounts.
Inactive Accounts
It would be wrong to consider that inactive accounts do not need an owner.
For instance, there are undeletable native accounts that are deactivated to reduce the attack surface of the operating system. Break-the-glass procedures make it possible to reactivate the native account to execute an authorized operation. Such accounts obviously need an owner.
Also, when an account is deactivated as part of the leaver process, the original account owner is no longer here to speak for that account. Would the organization need to reactivate the account for administrative or technical reasons (e.g. to regain access to a particular resource), we would need an account owner as well.
Bad Practices
Accounts with no owner
Accounts with 2 or more owners
Implementation Details
Issue an account management policy including:
clear description of exhaustive account categories
description of how ownership is assigned and maintained for all account categories
description of the rules for ownership over inactive accounts
requirement for all employees to report non-compliant accounts with clear communication channels
Assure you have record systems to maintain information on account owners
Manage exceptions with a structured process
Implement controls to ensure this best practice is complied with
Quotes
AC-2 ACCOUNT MANAGEMENT
Control: The organization:
(…) b. Assigns account managers for information system accounts; (…)
(NIST, 2013, p. F-7)
See Also
...
fine-grained data lineage on critical data elements provide visibility on how the sensitive data flows throughout the organization from capture or origination to consumption via transformations.
This map reveals the access points on sensitive data. Hence, the IAM function should collaborate with the Data Office function to leverage this valuable information and integrate it into the access rights management process to mitigate the risk of unauthorized access.
Bad Practices
No coordination between the Data Office and IAM functions
No visibility in how sensitive data flows throughout the organization
Implementation Details
Liaise with the Data Office function to coordinate data lineage efforts
Re-use data lineage to gain a holistic view of sensitive data access points
Leverage data lineage to mitigate the risk of unauthorized access to sensitive data
Quotes
Of all data-management capabilities in banking, data lineage often generates the most debate. Data-lineage documents how data flow throughout the organization—from the point of capture or origination to consumption by an end user or application, often including the transformations performed along the way. Little guidance has been provided on how far upstream banks should go when providing documentation, nor how detailed the documentation should be for each “hop” or step in the data flow. As a result of the lack of regulatory clarity, banks have taken almost every feasible approach to data-lineage documentation.
In some organizations, data-lineage standards are overengineered, making them costly and time consuming to document and maintain. For instance, one global bank spent about $100 million in just a few months to document the data lineage for a handful of models. But increasingly, overspending is more the exception than the rule. Most banks are working hard to extract some business value from data lineage; for example, by using it as a basis to simplify their data architecture or to spot unauthorized data-access points, or even to identify inconsistencies among data in different reports.
Our benchmarking revealed that more than half of banks are opting for the strictest data-lineage standards possible, tracing back to the system of record at the data-element level (Exhibit 3). We also found that leading institutions do not take a one-size-fits-all approach to data. The data-lineage standards they apply are more or less rigorous depending on the data elements involved. For example, they capture the full end-to-end data lineage (including depth and granularity) for critical data elements, while data lineage for less critical data elements extends only as far as systems of record or provisioning points.