Sample Logical Access Control Policy

ORGANIZATIONwill control logical access to IT data and systems based on defined business and security requirements. ORGANIZATION will assign a unique access account to each person who requires access. The management of these access controls will be shared between the IT department and the Security department. The ITdepartmentwill be responsible for maintaining the access control systems and accounts. The Securitydepartmentwill be responsible for periodically reviewing rights to ensure that only authorized users are listed and the authentication standards are being followed.

The goal is for users to only have access to the IT resources that is required to perform their designated functions and all Users be properly authenticated prior to accessing and using restricted-access ORGANIZATION IT resources.

The Security and the IT department will share responsibility for maintainingauthentication standards. These standards will include:

• Authentication standards for standardusers, which describe password usage including password length, password complexity, and password change frequency

• Access control standards for standardusersincluding account lockout durations, session timeout, and user managementprocesses

• Authentication implementation standards to describe acceptable network authentication protocols such as Active Directory, RADIUS , or Kerberos

• Authentication requirements for access to corporate resources

• Authentication requirements for administrative or elevated-privilege access control to critical systems

• Access control standards for administrative or elevated-privilege users including account lockout durations, session timeout, and user management processes

• System administrative access standardsdefining how system administrators will authenticate and be granted rights for servers and domains

• Database administrative access standardsdefining how database administrators will authenticate and be granted rights for database servers, databases, and database-related utilities

• Authentication standards for remote access to ORGANIZATION resources from outside the ORGANIZATION facilities

• Authentication standards for service accounts

• Forgotten password/lost token access and recovery procedures

• Emergency access standards for administrative access when systems are in a failedstate

Something You Know

The most common types of authenticators include passwords, personal identification numbers (PINs) , secret questions (what was your mother’s maiden name), service shared secrets (long passwords for software), and cryptographic keys. The whole point of something you know is that the authenticator is a secret. That means if it’s something guessable or discoverable with a little bit of research, it’s not very good. Some of the better systems combine multiple secrets, which is why you see some account reset systems ask you several questions, such as your childhood pet’s name and the make of your first car.

The biggest advantage of something you know is that it’s cheap to implement. This is why we see passwords and PINs everywhere. No extra hardware needed and the programming work is pretty straightforward.¹ If your organization uses passwords for authentication , and I guarantee it does somewhere, then you need to have some published password standards. The current version of the PCI DSS says that you need a minimum of seven characters containing alpha and numeric characters, rotating every 90 days and preventing any of the last four passwords from being reused. Many organizations have slightly higher standards than this .

Something You Have

Electronic authentication by something you have is as straightforward as sticking a key in a lock. Things you have can include hard/soft one-password tokens, digital certificates, USB dongles, smart cards, Kerberos tickets, cryptographic keys, web cookies and cloud service authenticator keys. If you are somewhat technical, you may have noticed that all of these things are actually shared secrets that only the authentication service can verify. Even ordinary locks and keys rely on a semi-secret pattern (visible in plain sight) cut out of the key, which is why Randall Munroe refers to locks as “shape checkers.”² This is why there are services available to duplicate a key if you provide them with a photograph of one.

We don’t want our IT authentication services to be spoofed by easily duplicated artifacts, so a lot real world authentication tokens (like passports) are forgery-resistant with expensive holograms and watermarks. In the digital realm, cryptography is our anti-counterfeiting tool . Because codes obscured by cryptographic secrets are harder to discover, we encode them with another key that only the authentication service knows. For example, authenticator tokens generate and display a visible code based on a hidden shared secret that changes it periodically.³

All of these systems work in a challenge-response fashion , where the authentication service probes the user to respond with the secret from their token or artifact. Sometimes when the artifact is physical, like a smart card, the challenge-response happens locally over a physical computer port. When over the network, the challenge response can be in English (“Enter the code visible on your token”) or via software message to the token.

Because of this cryptographic infrastructure , something you have also requires overhead for authentication. The same danger also exists for authentication by something known: if the secret gets out,⁴ it is easy for attackers to silently impersonate you. There have been a few cases where a breach occurred because a cryptographic authentication key was left in source code or in a script that became publicly available. There are also many attacks, like cookie theft and man-in-the-middle, where attackers intercept and copy an authenticator challenge-response in transit. An additional problem is that theft itself is secret, so the authentication credentials are compromised without the user being aware.

These problems mean you should have standards defined to ensure authentication tokens are protected when being transmitted or stored. The common tool for this is more encryption. There should also be standards for token issuance, rotation, and revocation.

Something You Are

Usually when we talk about something you are, we mean biometrics. Biometrics is authentication based on a unique human characteristic used to identify you. One of the simplest kinds of biological measurements is the CAPTCHA, which stands for Completely Automated Public Turing test to tell Computers and Humans Apart . This biometric test uses your brain’s ability to read squiggly letters to determine if you’re a human or software. That’s all this biometric determines but it is useful in blocking some automated attacks. The more useful biometrics is unique to each human individual, like fingerprints, facial configurations, iris patterns, and palm geometry. Some biometrics are so broad—such as CAPTCHA or gait recognition—that they work better for identification than other authentication.

For authenticating non-humans, there is a variety of techniques used in access control. For network security, often IP or MAC address can identify a machine. IP address works very well for firewall authentication over the Internet when combined with difficult-to-spoof protocols such as TCP/IP . Software objects can be authenticated based on what they are based on a unique type of checksum called a hash , which is based on the numeric representation of the software object. Done perfectly, a hash is unique to a software object .

One of the biggest challenges with authenticating something you are is that many of these factors are things that you cannot easily keep secret, unless you wear gloves and a mask like Spider-Man. It’s even harder for non-human objects to hide their uniqueness, as we can see how IP addresses are spoofed when combined with services that use weak protocols for address verification.⁵ The implications and issues of this are discussed more in Chapter 17, which covers network security.

Another challenge for biometrics is that you usually need special hardware. Now most mobile phones have built-in cameras and fingerprint sensors, so this is getting easier. Lastly, there are very few standards for trustworthy sharing of biometric information. What often happens is each system that authenticates via biometrics needs an infrastructure to enroll new users, capture the factor, and securely store it (usually as a hash). All of this implies additional infrastructure that must be built.

Multifactor Authentication

You can combine at least two of these things to be multi-factor authentication. A certificate, a fingerprint, or a token by itself is not two-factor authentication. You must combine the factors . This is why tokens and bank cash cards have PINs associated with them and passports have your photograph. The security comes from raising the difficulty of impersonating the user by a compromise of one of the factors. You may duplicate her fingerprint⁶ but you still need her password to login. This is why IPsec virtual private networks use a combination of shared secrets (something you know) and IP addresses (something you are). Software objects combine something that you are, like checksum hashes and embedded digital keys (something you have).⁷

Authentication Standards

Standards for authentication are important , but what should they specify? To fully understand the need and the standards definition, you need to delve deeper into the goals and control failure modes of authentication controls. The goal is pretty straightforward: restrict access to only authorized entities that can be identified to some degree of certainty. The more important the resource, the higher the assurance (certainty) required around identification. From here, you can see why we would want differing authentication standards for administrative access and scoped systems. Since passwords are vulnerable to phishing and keylogging, they aren’t strong enough for access to critical systems or access from high-risk environments (remote access). The industry standard (as of this writing) is username and password authentication for standard access and two-factor authentication for high-value/high-risk access.

What are the failure modes for this control? The simplest is that an attacker guesses the password. Let’s make that hard by setting a password standard requiring hard-to-guess passwords. In addition, we can set a standard number of allowed password attempts before locking the account and sounding some kind of alarm.

For something you have authentication, you don’t want that something to be stolen. When it comes to passwords, keys in scripts, or pinned certificates in software, you really don’t want full trust built into a software object in perpetuity. This can also apply to stored password hashes, which can also be stolen off systems. All of these risks can be reduced by authentication rotation. The idea is that if a password hash is stolen, the bad guys will attempt to cryptographically break the hash and guess the password. Some security practitioners mistakenly believe that shorter rotation cycles are always better (like 45 day cycles), but that is not necessarily true.⁸ Based on current technology and threat capability, a reasonable rotation scheme for passwords and administrative tokens is around three months. Certificates can rotate at least once a year.

How about the operational and implementation failures? You should have a standard defining the acceptable authentication tools and technologies. This can include specific technologies that you know work in your organization like Windows Active Directory, Soft tokens, Toenail biometric scans, and so forth. Another operational failure mode is how the authentication is first provided to the user. You don’t want the helpdesk printing out people’s passwords and leaving them face up on the desks. The same goes for password resets in case of lockout. A common attack technique is to phone the helpdesk and impersonate the user to get a password reset. You should have defined procedures for authentication distribution and verification .

Another authorization (not authentication) problem is users leaving the firm and HR failing to inform the IT department. A good control here is to have IT verify that all accounts are active with fresh logins once a month. You can set a threshold (for example, 45 days) that if after which time no activity is seen, the account is locked. This control also takes care of the user who never bothers to login to the system and leaves a dormant account lying around.

When you were doing your business process review, a few more authentication scenarios may have come up; for example, temporary access for vendors needing only to be on the system for a few days or weeks. By definition, these accounts are not going to stick around very long. A procedure can be defined to ensure that the accounts have automatic self-destruct dates added when the account was created.

Role-based Access Control

Authorization implemented in the manner that provides the most amount of control while still allowing users to get work done is called role-based access control. It means looking at specifically what each user needs to do, from where, at what time, and how they connect. For example, Matt takes a credit card order over the phone, so he needs access to the credit card database. However, he only needs write access to the database from 8am to 5pm, Monday through Friday, from his computer on the local area network. We assign processing refunds to Mathilda and give her a different access, but not the ability to enter orders (separation of duties) . Take this a step further and don’t assign these privileges to Matt and Mathilda directly, assign them to user groups called Order takers and Refunds, then put their users in those groups. It makes a lot easier to review who has what privileges and to update their rights when things change .

Compartmentalization at this level can be difficult, but worth doing for access to critical systems. The opposite stance, default permit all, should be avoided at all cost. Organizing roles and rights can take work, but building hierarchies of access that inherit privileges from the larger groups can make this easier. For the largest groups, like all users, you give the most basic privileges like sending jobs to the printer and read-only access to the corporate file shares. Then you add departmental and specific job roles on top of that. Watch out for escalating privileges, where users who change roles frequently and end up with rights to everything. It’s important to have periodic reviews of accounts and permissions.

Limit Administrative Access

The biggest target of least privilege and role-based access should be limiting administrative access. The first thing to do is to limit the number of administrators to the lowest number possible. Whenever you can, do not give out blanket full administrative access. Create and split up role-based access accounts for administrators based on what they need to do. For example, create roles based on common tasks like server restarts, applying patches, log checks, and backups. A good way to do this is to have separate user accounts for administrative work and regular work. A sysadmin would have a special account she would use for doing server work. She would then logout and log back in with a lower-authorization user account to read her e-mail or surf the Web.

Another way to limit administrative access is to use internal perimeters and jump workstations. In this configuration, all administrative access must be done over designated jump workstations, which are the only systems authorized to access the scoped secure environment. Jump workstations are discussed in more detail in Chapter 17. With this configuration, the actions that administrators can perform are constrained to the tools and network connections on those jump workstations. It also provides a clear authentication wall between the sensitive environment and the rest of the organization. You can also skip putting two-factor authentication on every single host within the sensitive environment if you just make sure that it’s on the jump box. Revisiting the scope diagram from Chapter 6, let’s expand it to show how this works.

Figure 16-1. Simplified scope barrier

System Authorization

Authorization access controls don’t just need to apply to users and people. Network firewall rules should also follow least privilege and minimize the services needed to pass through in both directions. Stored authentication tokens in programs can also be restricted using the valet key concept,¹⁰ which limits direct access by clients to services .

Sample Authorization Standards

Based on what we’ve covered so far, we have some additional security standards that we can add to our access control policy:

• Administrative accesswill be limited as much as possible, both in role and in activity. No user will have default admin privileges, either globally or locally.

• AllAdministrative accesswill be proxied via jump workstations, which will be positioned as the sole systems allowed to administer sensitive services, data, and infrastructure.

• Users will be assigned role-based access based on the resources assigned to them for their work. Each department will work with the IT department to develop standards of access for their respective department. Upon leaving the role, access to those resources will be removed.

• Access reviews will be conducted quarterly by the resource owners to ensure only authorized persons have access.