We’re now in the second half of my eight-part series in the Telecommunications Security Framework (also known as TSA/TSR), and we are now getting to the technically interesting items.
PAM – what is it anyway?
There’s a lot of discussion about privileged access management, and even more confusion with the term ‘PAM’. This term can refer to various technical solutions for managing privileged access, the Pluggable Authentication Module within Linux and of course privileged access management itself. For the purposes of this article, privileged access management will solely concern itself with the requirements for privileged access itself from a governance perspective.
Before we start, it’s important to understand what the term privileged access actually means as this is causing confusion.
The exact definition for Privileged Access / Administrative Access from the Code of Practice is:
“An access to network equipment where greater capabilities are granted than a standard user or customer. Any access over the management plane, or to management ports of network equipment is privileged access.”
This is especially important as privileged roles move towards super users from just admin accounts, so understanding this journey is crucial.
The Telecommunications Security Framework (TSF) ultimately requires that we implement AAA (authentication, authorisation and accounting) in daily operation to deliver the mantra of “never trust, always verify” from zero trust approaches; but this requires that we understand the access paths in place in order to maintain the balance between managing known credentials used by individuals and services with the needs of vendors to support systems during emergency situations (often using generic accounts).
Understanding the boundaries of privileged access within the TSF
Of course, it’s always worth remembering that the scope of privileged access management is constrained to the key functions for the operation and oversight of the Public Electronic Communications Network (PECN) or the Public Electronic Communications Service (PECS).
Specifically, the TSF requires that the following risks are managed in relation to privileged access:
- risks of security compromises to which the network as a whole and each particular function, or type of function, of the network may be exposed
- risks of unusual/anomalous events causing security compromises
- risks of unauthorised activities of people involved in the provisioning/operation of the PECN/PECS causing security compromises
- risks of security compromises occurring as a result of monitoring and analysis tools being stored on equipment located outside of the United Kingdom
- risks of activities of third party suppliers causing security compromises to the PECN/PECS, either deliberately or accidentally
The remainder of this document will discuss the bulk of the risks above, all of which require annual review, although privileged access management from third-party administrators and access to monitoring/analysis tools hosted outside of the UK will be discussed in the next article.
Let’s look at each stage of the AAA process in turn:
Authentication – prove who they are
You need to ensure that default credentials are managed, by ensuing that:
- Default passwords are changed where they can be and mitigations are implemented where they can’t.
- Default accounts are disabled where possible and mitigations implemented where they can’t
Access is to be linked to individuals in the following ways:
- Security critical functions are to have named accounts for all access
- MFA is to be used when carrying out privileged/administrative functions
- Network equipment is to have named accounts for all access, with break glass accounts configured for emergency access
- Break glass accounts shall alert when used and be reset to a new value after use
- Where a single account is used to access multiple roles, this is to be subject to risk assessment
- Privileged activities are to be capable of being automated through the use of verified commands
Authentication is to occur over secure methods, ensuring that:
- Privileged access is over secure, encrypted authenticated protocols (where possible) (this is concerned with connections used to manage security critical functions and network oversight functions)
- Privileged access is undertaken over authenticated and encrypted network connections (this is concerned with how endpoints connect to manage security critical functions and network oversight functions)
- Dedicated management functions are used to manage network oversight functions, with privileged access only possible using connections from authorised management infrastructure
Ensure that credentials are managed, making sure that:
- Authentication credentials (e.g. usernames and passwords) which are in constant use by users are stored in a centralised service, access to which is protected by means of Role-Based Access Control (RBAC)
- Authentication credentials (e.g. usernames and passwords) which are static for break glass etc. are protected and only access to responsible staff during an emergency
- Ensure that all static credentials are stored in hardware-backed storage or have effective mitigations for credential theft
Authorisation – control what they can do
Ensure that what privileged users can do is defined and limited to minimum required, ensuring that:
- Roles and responsibilities for security of security critical functions are defined
- Clear roles and responsibilities are defined for privileged access between administrators from third parties and the provider
- Privileged access is reviewed regularly
- Risks relating to authorised actions by privileged users are reviewed at least annually
- All privileged access is the minimum required, assigned according to their role from a template
- Ensure that all access to electronic information related to the operation of the PECN/PECS is controlled, including the transfer of information between different administrative zones
- Ensure that accounts used for the management of the virtualisation fabric do not have privileged access to other systems or workloads
- Ensure that management access to network oversight functions is limited to those with a defined role
- Ensure that network oversight functions are operated within the UK, using UK-based staff
- Ensure that only specific users with defined roles can modify log events, and ensure that monitoring data is protected
Ensure that the minimum amount of privileged users are configured:
- Limiting the amount and extent of security permissions given
- Ensuring that only the minimum number of privileged users can administer the virtualisation fabric and only have the rights to manage the virtual functions that they need to manage
Ensure that technical architectures are used to control privileged access, by:
- Ensuring that access to security critical functions are not available from countries listed in the schedule of prohibited countries
- Ensuring that the direct access to security critical functions isn’t routinely possible, and only permitted under break-glass scenarios
- Making sure that the management plane within providers operates on a browse-down architecture where users are always granted the minimum of user and network access and always requires authentication for any user or network level for administration
- Making sure that the management plane mitigates the risk of lateral movement between managed functions, ensuring that access into the plane is via element managers
- Ensuring that the management is segregated in a manner which ensures that disruption of a single segment doesn’t impact the other segments
Ensure that break-glass access is managed, making sure that:
- Access to break-glass accounts is controlled
- Privileged access controls are only temporarily suspended during an emergency, with any suspension being recorded and reset as quickly as possible
- Use of break-glass is possible, but raises an alert when used
- Break-glass accounts are reset after use
Ensure that privileged users are competent to carry our their role, by:
- Ensuring that adequately trained personnel manage the security of security critical functions
- Ensuring that there is a UK-based capability for technical subject-matter expertise in the operation of the PECN/PECS
Accounting – record what they did
Ensure that activities of privileged users are recorded, making sure that:
- All access to security critical functions and network oversight functions are logged
- Privileged management activity is recorded
- All privileged access is linked to operational events for change and incidents
Ensure that activities of privileged users are monitored, by:
- Ensuring that all unauthorised access to security critical functions and network oversight functions is logged and raised as a security event
- Ensuring that monitoring of activity occurs where the trust level changes
What are the types of activities involved with privileged access management?
As can be seen in the figures below, and the detail of the areas to be covered above, there is a range of activities that must be undertaken to meet the requirements of the code of practice, although the bulk are at the beginning and the end of the current indicative timescales to provide evidence.
As can be seen above, privileged access isn’t just about the passwords in use but also the governance surrounding them.
What are the challenges with privileged access?
There are a number of challenges with meeting the requirements for privileged access within communications providers though as discussed below:
The network architecture is much more ‘Cloudy’ than it has been in the past
The following figure reflects the current perception of privileged access within the code of practice:
The architectural challenge looks very manageable, with the information to be managed (including the centralised directories used for authentication) held on-premise. However, the reality is very different (especially after the organisation changes to use of Cloud during and post-COVID)
Figure 4 above reflects the reality now, with credentials and information at the very least stored within a hybrid Cloud deployment model if not now fully off-site in Cloud.
The operational reality in figure 5 below when you show how third-party administrators enter and egress the network (which will be discussed in greater details in the next article) presents a much greater challenge.
None of this makes the requirements from the code of practice any less relevant, but it does mean that those undertaking the analysis, remediation and design of policy and network architectures need to be much more aware of what is happening.
Local accounts are much more prevalent than many realise
Within networking, Unix or Unix-derivate network functions are much more common and cannot easily be taken into centralised control. This leads to its own challenges as the requirement to remove default accounts is more problematic, especially when looking at how existing global support agreements are implemented where the accounts need to be retained.
This challenge amplifies when there are often a range of local privileged accounts which are not declared to the customer which are used for support and monitoring. It’s also important to understand not only the accounts, but the privileges that they have.
Don’t be fooled into thinking that the myriad of ‘PAM solutions’ on the market will solve this either as solutions which ‘take ownership’ of local accounts within their vaults are still managing the local accounts in situ, and there is no vendor out there that will recommend owning the default root account.
I have collaborated with vendors to determine the challenges to managing local accounts, and how different approaches can lead to blended approach, including the use of open source software to leverage these local accounts centrally in an article here.
This presents a compliance challenge in the code of practice itself, as it may not be possible to meet the centralised requirements for all local accounts with Unix-derivate systems. However as already stated, this simply means you document the risks, gaps and how you mitigate them.
The issue isn’t just legacy – the current Cloud state requires review
This above issue isn’t just within legacy systems, but also the Cloud-native functions and reporting components that are common within the ‘Telco Cloud’ or NFVI vendor-virtualised Cloud platforms that are increasingly deployed within providers.
Whilst the Cloud platforms themselves and the components with network functions are often very capable of adopting the types of centralised authentication and secure access methods required, the functions hosted on the Cloud platforms are often the same open source components for access and reporting that you find in smart home automation and are not always secure out of the box.
It’s becoming clear that many of the commercial products which are Cloud native share some of these components, and this means that you have to review the use of Cloud platforms and the functions hosted on them to work out where and how centralised secure authentication methods are deployed. These functions often share components (daemons) from the Unix-derivate systems and need careful review.
Are the controls managing the risk?
As above, PAM solutions can deliver effective controls where centralised access is available but there is always a balance when it comes how much the solution can manage by itself. No solution is a panacea and it’s often necessary to gain a level of understanding of the risks and controls to determine what will be managed by the PAM solution and what will be delivered by other other controls.
An example of this is lateral movement, where an account may well be capable of managing an account on a host but that hosts could then use another credential to reach another system.
Do you know what you will do in an emergency?
I’ve discussed the challenges with PAM solutions above, and the requirements within the code of practice to remove default accounts. There is a dichotomy where the existing direct access methods could provide an existing method for emergency access in the event that access is compromised (albeit that this access would have be managed in accordance with the alerting and reset requirements).
With PAM solutions not recommending that they manage default root accounts, it’s important that providers review the risks relating to the use of accounts for break-glass/emergency access and balance that against the requirements to remove the default accounts.
Out of band access from the existing access paths require careful consideration to ensure that their use is managed according the requirements of the code of practice.
What can you do to manage the challenges with privileged access?
The best way to address these challenges and prepare for the assessment of risk and improvement options is to approach the activity to build out the following:
- Access paths – these are the components used to provide both usual and break-glass/emergency access to maintain applications, systems and network devices (examples of which exist within figures 3-5 above). It’s important to consider the accounts which exist on the components and their privilege, especially on Unix/Unix-derivative systems.
- Roles and responsibilities – for the privileged accounts you have found when reviewing the access paths, do you know why they are there, who needs to access them, do they need the rights they have been given, are the passwords non-default and are the accounts assigned to individuals? It’s important that the accounts are measured against the contents of this article and the next one on third part admin access, but at least ensure that good password practice is followed here and that any shared/generic accounts are subject to risk assessment with controls implemented to manage them if there is no alternative.
- Failure scenarios – in order to determine when/where break-glass/emergency access is required, it is really important to determine the scenarios. These typically include degradation (where the functionality of on or more components of the access path aren’t working as expected), partial failure (where one or more of components have failed, requiring a bypass of the component), critical failure (where the integrity of the access path is compromised and requires bypass of the path).
Understanding the above will help build out where privileged access operates, if it is the managed effectively and how break-glass/emergency access is to be managed.
Summary
These requirements have grown from the original TSRs which have evolved into the technical guidance measures of the CoP, and are linked into the specific security measures within the Regulations, the key concepts and even Indicators of Good Practice (IGPs) from the relevant areas of the Cyber Assessment Framework (CAF).
The compliance debt from poor asset management, especially in networks built for ease of support, now requires addressing to effectively meet the challenges. This challenge isn’t just in legacy environments, but also within the myriad of open source components within Cloud native or Vendor-virtualised application architectures which are built for interoperability first and security second.
The credential boundaries implemented using Privileged Access Management (PAM) solutions work very well for defined access paths, but are often not able to manage (often proprietary) shadow access paths used by global support organisations, out of band access where the PAM solution might not be reachable, or to adapt quickly to scaling the existing defined access to maintain control In Cloud computing deployments or even emergency situations.
As ever, if you have any questions on this or need any help drop me a message.