Incorporating multi-factor authentication for non-console access

Incorporating multi-factor authentication for non-console access
0 Shares

We previously wrote about the PCI DSS new controls that became mandatory and effective from 1st February 2018. In that article we highlighted the items that impacted merchants, some new controls that impacted only service providers and some that are common to both.

 

This article discusses what is the intent of this control, what would an assessor look for and what type of solutions have been used. Sysnet’s Michael Hopewell provides direction that should your merchant customers require guidance your organisation is in a stronger position to provide assistance.

 

By Michael Hopewell, Managing Information Security Consultant

 

The intent

The scope of this requirement applies to personnel with administrative access to the cardholder data environment (CDE) via non-console access.  But what does non-console access mean? Console access is where the user is physically present at the device and directly accessing the console to conduct actions.

 

For example, a computer user directly typing on the affected device. Non-console means that the user is not physically present and is conducting actions remotely to the device. For example, the user may be present on a laptop in an office, but remotely connected to a device via a secure via virtual private network (VPN) or remote desktop (RDP) session.

 

So if we break up the key words, the main points will be as follows:

 

  • The scope applies to personnel with administrative access to the CDE.
  • The scope applies to personnel with administrative access with non-console access.
  • The scope does not apply to non-personnel, for example application or system accounts conducting automated functions.

 

Multi-factor authentication

Previously, the term two-factor authentication (2FA) was used, but for clarity it is now multi-factor to encourage a minimum of two-factors and a maximum of three factors. Remember that the three factors are:

 

1.Something you know: An item only a user should know such as username and password.

2.Something you have: An item that you have, for example a random access token.

3.Something you are: A feature that you have inherently, for example, biometrics (fingerprint, eye pattern etc.)

 

Two of the three factors are required at a minimum. Therefore using a username (something you know) and a password (something you know) would only be using one factor. Typically, we usually see a successful implementation having s username/password (something you know) and access token (something you have) to meet the minimum of two factors required.

 

Multi-step vs Multi-factor

In some situations, enforcing a minimum of two-factors at one stage may not be possible. It is acceptable to have each factor in turn. For example, entering a random access token (something you have) and after submitting this, entering a username/password (something you know). Multi-step does not matter as long as authenticating via multi-factors is enforced.

 

Webpage URL

Find out more about our Cyber Security and Compliance Solutions

Request a Callback

What about segmentation?

The key message is to enforce multi-factor authentication for any remote non-console access by personnel with administrative access. This means that it does not matter if there is segmentation or not, the user will still be required to use multi-factor authentication.

 

However, let’s take a look at the typical types of connections made via segmentation or no segmentation:

  • No segmentation: Where segmentation is not used, multi-factor authentication is required when:

1.Connecting to the CDE network

2.Connecting to the system directly

 

  • Segmentation: Where segmentation is used, multi-factor authentication is required when connecting to the CDE network or system from a non-CDE network.

 

Multi-factor authentication at network or application level?

Multi-factor authentication can be implemented at both a network-level or system/application level. Here are some examples:

 

  • Access at network level: The user must enter a username/password + random token number, in order to establish a secure VPN/network session to the CDE network.
  • Access at system/application level: The user may conduct a remote session first (for example conduct a remote desktop session) to the computer, then on the computer it will ask for username/password + random token number in order to logon to the computer.

 

Multi-factor on jump server or bastion hosts

Let us just recap the difference between jump server and bastion host:

 

  • Jump server: A jump server is a computer that is located within the CDE network.
  • Bastion host: A bastion host is a computer that is outside the CDE network, but is a tightly locked down endpoint and has authorisation to connect to inside the CDE.

Multi-factor authentication can happen at the network level or at the system/application level (before or on accessing the jump server or bastion host).

 

So what would an assessor look out for?

The reporting requirements dictate the following:

 

8.3.1.a Examine network and/or system configurations, as applicable, to verify multi-factor authentication is required for all non-console administrative access into the CDE.

 

This means the assessor will need to:

  • Sample network and system components. This may include (but not limited to) firewalls, routers, switches and servers.
  • Review configurations to verify that multi-factor authentication is required for all non-console access. This may be looking for configurations on the system that demonstrates the multi-factor prompt is enforced.

It also requires:

 

“8.3.1.b Observe a sample of administrator personnel login to the CDE and verify that at least two of the three authentication methods are used.”

This means the assessor will need to:

 

  • Identify a sample of personnel with administrator access.
  • Conduct a walkthrough with personnel to observe and verify multi-factor authentication was indeed required in order to connect to the CDE or the system.

 

Example scenarios may include the following:

 

  • User needs to connect through a firewall first to connect to the CDE network: A user may need to logon via a web gateway that requires multi-step multi-factor authentication via username and random token number. Successful authentication may open the firewall to allow that computer through. The user can then connect to a server to logon to the device using normal username/password. As multi-factor authentication access is standardised on the gateway/firewall, the assessor will look at the gateway/firewall:

     

    • Review the system configurations on that gateway/firewall to confirm if it is pointing to a multi-factor system.
    • Observe administrators using the multi-factor to confirm the settings are working as expected.

 

  • A user within the CDE network needs to a device already on the CDE: A user may need to access a server, which prompts the user to enter multi-factor authentication via username and random token number. Successful authentication allows them logon access to the server. As multi-factor authentication access is enforced on the server, the assessor will look at the server:

     

    • Review the system configurations on that server to confirm that it is pointing to a multi-factor authentication system.
    • Observe administrators using the multi-factor authentication logging on to confirm the multifactor authentication is requested.

 

  • SSH keys multi-step multi-factor authentication: A user may require to establish a VPN session using username and password (something you know) as the first step. Once VPN is authenticated, the user may require to connect to a Linux server configured to use SSH keys, whereby the individual key (something you have) installed on the user’s laptop is authenticated as step 2, to allow logon to the server. As multi-factor authentication access is across both the VPN and server, the assessor will look at the both the VPN server and Linux server:

     

    • Review the system configurations on VPN server to see how it authenticates the username/password combination (something you know).
    • Review the system configuration on the Linux server to confirm how it is authenticating the SSH keys (something you have).
    • Observe administrators using the multi-step multi-factor authentication to confirm the settings are working as expected.

Summary

The intent of multi-factor authentication for non-console access provides higher assurance of the identity of the individual remotely connecting to a CDE system. It is clear there is no set way to enforce this as there are various implementations including multi-step multi-factor authentication, jump servers or bastion hosts within segmented or non-segmented networks.

 

Your business needs to focus on a pragmatic solution that enforces multi-factor authentication.  Any assessor would need to understand those processes and review the systems that are enforcing the different factors.

 

Webpage URL

Find out more about our Cyber Security and Compliance Solutions

Request a Callback