The first domain in the SSCP CBK is Access Controls. This domain accounts for 16% of the SSCP exam.
The Access Controls domain defines four (4) tasks that a certified SSCP should be able to perform:
- Implement Authentication Mechanisms
- Operate Internetwork Trust Architectures
- Participate in the Identity-Management Lifecycle
- Implement Access Controls
This is part 1 in a 7-part series on the (ISC)2 SSCP Common Body of Knowledge (CBK).
Remember: An SSCP who can recall this information will likely pass the exam, but the SSCP who can explain how these concepts are applied in real-world situations is more likely to get hired.
Implement Authentication Mechanisms
Authentication is the process of validating a user’s identity (i.e., he is who he says he is). This is not to be confused with authorization, the process of determining which resources a user is permitted to access.
Systems and applications can be configured with one or more authentication factors, or pieces of evidence that supports the user’s claim. The most common example of single factor authentication is the username/password combination, with the password being something the user knows.
Additional authentication factors traditionally include:
- Something the user has (e.g., token, certificate)
- Something the user is (e.g., biometrics, such as fingerprint)
- Somewhere the user is (e.g, geolocation data)
When a user is required to provide multiple types of evidence before gaining access to a system or application, this is referred to as multifactor authentication.
In order to reduce the number of credential sets and authentication factors that users must maintain, an organization may implement a single sign-on (SSO) solution. An SSO solution validates a user’s identity once, and then grants the user a token that other systems and/or applications can recognize. When the user then tries to access another of those systems or applications, the target system or application automatically accepts the token as evidence instead of prompting the user for any additional evidence.
Device authentication requires that the user’s device must be known and trusted by the network before the device is allowed to access network resources. This is often accomplished by having an administrator installed security certificates on all trusted devices, and then configuring the network to check for those certificates any time a device attempts to connect.
Operate Internetwork Trust Architectures
Understanding basic network architectures is a crucial first step in understanding how to establish trust between networks.
An intranet is an internal network, restricted (ideally) to authorized users only. An extranet is an extension of the intranet, exposing a subset of systems and/or applications externally so that authorized users can access those resources while off-site. Federation is the process of establishing trust between two separate networks, one where a user’s identity is established (authentication against an identity provider), and another where that user has been authorized to access certain systems or applications (from a service provider).
Domains are a set of resources (systems and applications) that have been grouped together so they can be centrally managed. These domains have a defined set of administrators who apply unique security controls and policies to those resources. Similar to federation, a domain may contain resources that users from another domain wish to access.
In order to grant users that access, administrators may need to establish a trust relationship. Trust relationships come in multiple forms.
- One-way trust relationship – Configuring a trusting domain which controls certain resources (e.g., file servers) to permit trusted users from another domain to access those resources.
- Two-way trust relationship – Two separate one-way trust relationships established between separate domains.
- Transitive trust relationship – When three or more domains have trust relationships, the trust is extended by association. In other words, if domain 1 trusts domain 2, and domain 2 trusts domain 3, then by association, domain 1 also trusts domain 3.
Security-conscious administrators understand that the most permissive trust relationships also present the greatest risk. An attacker on a trusted domain would have the ability to access resources on other domains where trust relationships have been established.
Participate in the Identity-Management Lifecycle
When a user attempts to access a secured resource, a properly implemented security control should prompt the user for evidence that the user really is who he or she claims to be. This process is sometimes referred to as proofing.
Once a user’s identity has been verified, the access control system then checks to see what exactly the user is allowed to do. For example, a regular user may have the ability to change his or her password, while an administrator may have the ability to change the password for any user. This distinction between permissions, based on the individual’s identity, is part of the authorization process.
But what if a user doesn’t have an account in the system at all? Someone (e.g., an administrator) or something (e.g., an automated system) needs to first create the user’s account, assign the account a temporary password, and determine which resources that specific user should be permitted to access. The process of configuring a system to link resources to an authorized users is known as provisioning. Similarly, removing these links to ensure a user can no longer access a particularity resource (when a user leaves the company, for example) is known as deprovisioning.
Within the identity management world, these resources (e.g., domain group memberships, application roles, local system accounts) are often referred to as entitlements.
As you can imagine, organizations change over time. Companies merge with one another, and either acquire smaller companies or are acquired themselves. Employees who have worked at a company for a longer period of time may have been promoted, or been transferred to another department. Mature organizations understand the need to have both trained employees and automated systems who support the maintenance of identities over time.
Implement Access Controls
When it comes to implementing access controls, there are multiple models available.
- Mandatory – A subject (e.g., person) is granted clearance, and then objects are protected based on classification. Militaries and governments often rely on mandatory access controls. For example, a person with Secret clearance cannot access a file that has been classified as Top Secret.
- Discretionary – Instead of applying clearances and classifications, access control decisions are made by an administrator on a case-by-case basis.
- Non-Discretionary – Sometimes referred to as role-based access controls (RBAC), non-discretionary access controls determine which resources (entitlements) a user should be able to access based on the user’s role within the company. For example, IT Administrators may need local admin rights to support their end users, based on their job role.
- Attribute-Based – This model relies on attributes associated with a user’s account to determine entitlements. Users in a particular location, for example, may be granted access to a file share that contains data for just their office.
What Else Should I Know About Access Controls?
This is a high level introduction to the concepts you need to know as an SSCP, based on the (ISC)2 SSCP Certification Exam Outline. It’s not intended to be a deep-dive into everything you need to know in order to pass the exam.
You’ll increase your chances of passing the exam the first time if you read these two (2) books next:
- Start with the SSCP All-in-One Exam Guide (2nd Edition).
- Then read the (ISC)2 SSCP Official Study Guide.
If you prefer videos to books, use our list of recommended online training providers to take advantage of FREE offers to help you prepare for the exam.
Keep at it!
SSCP Domain 2 – Security Operations and Administration
