Across nearly all compliance standards, securing the login is a major focus. Why?

Success for most IT leaders looks like establishing and maintaining a certain level of security. And IT is under more pressure than ever. But all too often, IT teams focus on continually checking whether an environment remains compliant. That's not the answer. It's not enough to keep checking whether the walls are still standing.

You need to see how the environment is used, and determine whether that usage falls outside the limits you've set.

So, the question becomes: just how far down the usage “rabbit hole” do you go to determine if you’re compliant or not?

Of course, you don’t want to wait until a breach happens to realize you’re not compliant. You need a way to test out compliance much earlier in the usage process.

Fortunately, one such compliance test exists: the logon.

Login security isn't just a matter of security protocol to keep unwanted eyes out. The logon is a pivotal point at which time a specific user identifies themselves.

Exactly how the user identifies themselves at the logon is critical. Because attackers compromise credentials so frequently, best practice calls for at least a second factor of authentication to prove that the user is who they say they are.

Multi-factor authentication (MFA) is an additional layer of security to ensure the right person is using the right ID and password.

But the importance of the logon also goes beyond the ID and password. Dig a bit deeper. Details, such as the day and time of logon, the IP address and workstation logged on from, and even the frequency of logon all play a role in identifying whether an environment is compliant.

Take this example:

A user with access to data subject to a compliance mandate logs on after hours several times in succession from a remote computer.

There are three red flags here:

• The time of day

• The number of logons

• The location from which the logon occurred

The bad news? The logon doesn’t tell you flat out you’re in breach of compliance. But it does give you key indicators that there may be a problem well before any access (read: compliance breach) occurs.

Most compliance standards and regulations are keenly aware of the importance of the logon and successive actions.

For example, let's take a look at one of the most detailed standards today, the PCI Data Security Standard (PCI DSS), to see how login security plays a role in compliance.

The goal of the PCI DSS is to protect cardholder data from any unauthorized access. Take the following precautionary measures found in the current PCI standard:

• Requirement 7: Restrict access to cardholder data by business need to know

• Requirement 8: Identify users and authenticate access

• Requirement 9: Restrict physical access to cardholder data

• Requirement 10: Track and monitor all access to network resources and cardholder data

Each of these requirements is necessary to ensure cardholder data is secure. But each depends on one keyword in each of these requirements: access.

This single word represents the process of an account being used to actively connect to a system and open/read/copy/download cardholder data — an action that begins with the logon.

The authors of PCI get it: Requirement 8 (Identify and authenticate access to system components) exists to establish individual access and usage of the environment. This requirement exists to ensure there is a way (in requirement 10) to audit each user’s interaction with the network and, eventually, cardholder data.