Module Objectives
- Define the process of user and systems access reviews.
- Apply the appropriate control types/categories for provisioning and deprovisioning of identifies.
User Access Review
Identity and Access Provisioning Lifecycle in this at the development of the enterprise security architecture, the security architect will map business requirements to technology agnostic views or statements that enforce the security policy and answer business goals throughout the organization. These architectural views or statements are what provide guidance for implementation of cohesive technology solutions that come from specific design elements that are informed by the architecture.
Within the lifecycle of identity and access provisioning, it is imperative that user access reviews are conducted on an on-going basis once an account has been created and provisioned. The review will be based upon the business requirements that are expressed within the enterprise security architecture. Scheduled and regular user access reviews could reveal vulnerabilities that might require the need for revocation, disablement, or deletion of an account.
Related Product : Certified Information System Security Professional | CISSP
These occurrences are causes for revocation/disablement/or deletion of user access:
- If a user is voluntarily or involuntarily terminated from an organization.
- If an account has been inactive for a period that surpasses the organizational policy.
- If the user account is no longer appropriate for the job description or role.
- If user account privileges have experienced unnecessary access aggregation.
System Account Access Review
System accounts such as “administrator,” “sudo,” or “root” accounts present an often-exploited vulnerability for attackers. Making a non-linear representation between the user ID name and its function could represent the first layer of defense against attackers. Disconnecting the account name from the function is as simple as renaming the account to something that looks more like a traditional user name or randomly generated name. In addition to identifying an account by the name, an attacker could also identify the account by other attributes such as system assigned static numeric ID. Therefore, “security by obscurity” or only renaming the system account is insufficient due diligence to protect them from anything more than trivial exploitation efforts.
Here are examples of built-in user accounts that are associated with a Microsoft Windows system:
- SID: S-1-5-21domain-500 Name: Administrator
Description: A user account for the system administrator. By default, it is the only user account that is given full control over the system. - SID: S-1-5-21domain-501 Name: Guest
Description: A user account for people who do not have individual accounts and does not require a password. By default, the Guest account is disabled. - SID: S-1-5-21domain-512 Name: Domain AdminsDescription: A global group whose members are authorized to administer the domain. By default, the Domain Admins group is a member of the Administrators group on all computers that have joined a domain, including the domain controllers. Domain Admins is the default owner of any object that is created by any member of the group.
Current systems associate administrator privileges with individual users for the duration that the privileges are required for a specific function and then return the level escalated privileges when the specific task is completed.
Some system accounts are predefined to be used as service accounts and are not always recognized by the security subsystem so may, therefore, not be reviewable with the typical views or calls as a traditional “administrator” or “root” account. Service accounts may possess extensive privileges within a computing system and behave as the computing system within a network. Service accounts will often have unbated access and control of most system objects. In addition to the wide-ranging access maintained by system accounts, the account itself will often be active without any method of authentication and will not be associated with any logged-on user account.
A compromised system account may yield access and information that could make a system vulnerable to attack. Many service accounts do not need as high a privilege level as is granted in the default configuration, and if that is true of a system, then demoting the privileges to the least level would be an appropriate application of the principle of least- privilege.
Provisioning and Deprovisioning
Provisioning and deprovision of access and identities involves a list of activities that are driven by business needs and requirements, job function and role, asset classification and categorization, and dynamic legal and regulatory issues. Users needing access to system resources go through a process of provisioning that rightly begins with the data/information owner expressing a business need for the stated access.
Vulnerabilities that are readily ascribed to technology often have their introduction by means of a lack of due care and due diligence related to administrative controls. Identity and access management (IAM) forms a lifecycle that begins with provisioning or enrollment, access and consumption of resources, and finally deprovisioning or revocation of access.
The Federal Identity, Credential, and Access Management (FICAM) Roadmap and Implementation Guidance 4.7.1. As-is Analysis provides for three phases that manage the Provisioning and Deprovisioning process.
- Provision a user account and apply user permissions
- Modify user permissions
- Deprovision user account and end user permissions
Process Flow
The as-is process flow for this use case is broken into three parts.
Part 1: Provision a user account and apply user permissions
- An Individual completes a request for access to an application and provides it to the individual responsible for access approvals (hereafter referred to as the Privilege Manager).
- The Privilege Manager validates the Individual’s need for access and provides the access request to the Application Administrator.
- The Application Administrator creates a user account for the Individual in the application with the appropriate user permissions.
- The Application Administrator notifies the User of the account creation.
Part 2: Modify user permissions
- The User completes a request for a change in privileges.
- The Privilege Manager validates the User’s need for access and provides the access request to the Application Administrator.
- The Application Administrator updates the User’s access permissions in the application.
- The Application Administrator notifies the User of the permission change, often via phone, email, or another manual process.
Part 3: Deprovision a user account
- The Privilege Manager notifies the Application Administrator that the User no longer requires access to the application.
- The Application Administrator removes the access permissions and the User account from the application.
Activity: Identify the Roles and Control Types and Categories of Provisioning and Deprovisioning
Working together in small teams answer the questions below.
- What additional controls (choose from the confidentiality, integrity, and availability (CIA) triad) could be added to the three phases of the process flow?
- Add control types
- Add control categories
- What roles can you identify in the process flow (i.e., Custodian, Data Owner, etc.)?
Follow Us
https://www.facebook.com/INF0SAVVY
https://www.linkedin.com/company/14639279/admin/
