Across the entire UK telecoms industry, effort is well under way to meet the Telecoms Security Act within the published compliance timeframes. To safeguard against security threats, telecom providers are obligated by law to implement best practices and employ measures to prevent attacks throughout all activities for their network's planning, development, deployment, operation, and administration. In addition, operators need to prevent unauthorised access and manipulation of their network and data.
Author:
Pete Maan
CyberArk Guardian
Principal Consultant at CyberIAM
Along with a comprehensive and robust implementation of Privileged Access Management toolset and service, IT Service Management policies and procedures will be important for overall adherence to the TSA mandated measures. Beyond the management of accounts and identities used for privileged access to support a telecom provider’s Management Plane, integration of Privileged Access Management tooling with ITSM ticketing systems will be required to support the secure administration practices covered by the measures; public telecom providers must take measures to make sure that any privileged access is authorised, time-limited, and correlated with a particular ticket for a particular reason.
Most PAM solutions offer integration with ticketing systems as a standard configuration, and it is a commonly implemented feature across most customers, particularly in regulated industries. For logging and monitoring purposes a link to the specific ticket that necessitated the use of privileged access helps to explain why a particular login occurred, building a story of privileged activity, aiding security analysts to effectively triage security events and identify anomalous activity; access logs must be routinely reviewed by providers, who should also compare the information to other access records and ticketed activities.
Download Our White Paper
Learn more about navigating TSA and the imperative of identity and access governance in a comprehensive guide written by one of our expert principal consultants.
Ticketing Integration Requirements
There are only four measures within the TSA code of practice which mention the aspect of tickets for privileged access making a good focal point for a brief discussion for a blog such as this. These measures also illustrate how the topic of ticketed access in relation to privilege use underpins the complete access lifecycle for administrative access to devices covered by the TSA measures, as well as highlighting additional considerations for privileged access provisioning, session control and access revocation.
The official wording of the individual measures pertinent to today’s blog are:
- Privileged access shall be temporary, time-bounded and based on a ticket associated with a specific purpose. Administrators shall not be able to grant themselves privileged access to the network
- While open, tickets shall be updated daily as a record of why privileged access granted to a user remains required and shall be closed once privileged access is no longer required
- Privileged access shall be automatically revoked once the ticket is closed
- Providers shall regularly review access logs and correlate this data with other access records and ticketed activity
It is expected for providers to ensure that their procedures involving privileged access have been implemented to meet every requirement of each of these measures. As is common across all measures contained in the TSA Code of Practice, there is no advice on how the measures should be addressed; interpretation of the requirements and the best way to meet them is at the discretion of each provider.
Different services, systems and solutions in place at different providers may predicate how the measures are implemented, likewise the capabilities of any products being used may require certain configurations depending on the capabilities of any products in use.
Let us look at a workflow for temporary, time-bound access based on a ticket for a particular purpose, in this example there is an access requirement from an engineer who needs temporary access to a server or device in the management plane of a provider’s public network to perform some maintenance activities.
Example Workflow:
- Ticket Creation: The engineer submits a request in the provider’s ITSM tool, specifying the purpose of the access request and duration the access is required for
- Request Approval: The request is sent to a defined approver for review, with approval of the request generating a ticket in the ITSM solution
- Access Workflow: The PAM system grants access after validation of the approved ticket and allows the engineer to commence a privileged session with a predefined expiration time
- Access Logging: All actions taken during the privileged session are logged and activity is recorded by the PAM solution
- Access Revocation: Once the time limit is reached, the PAM system automatically revokes access, ending any privileged session
- Review: Post-maintenance activity, request, session activity and logs are reviewed to ensure proper usage
Different providers or architects will approach the workflow in different ways, but in this example the requirement for temporary access based on a ticket is met through the integration with a ticketing system itself; the engineer in the example has no standing access to the server to which they require access, and the created ticket provides the mechanism for them to gain temporary access via the Privileged Access Management solution, the PAM tool in this case has capability to enforce time bound sessions. Likewise, the engineer is unable to grant themselves access to the network as there is also a requirement to use an approval workflow to create the ticket used to gain the privileged access.
Based on the existing, tactical, or anticipated strategic capabilities available within their environments, architects, and subject matter experts, in both the PAM and ITSM disciplines across a provider, should align on the requirements to be able to deliver the outcome required to meet the TSA measures.
The combination of ITSM principles, PAM capabilities, and business processes is essential for establishing a robust framework that supports the procedures used to acquire privileged access to the public network of the provider.
Access Revocation
Whilst most PAM solutions offer integration with ticketing systems and approval workflows, access revocation must be given more attention. Timebound access can be accomplished in two ways: first, by enforcing a maximum session duration for the privileged session itself, such as allowing a session to an end system to be established for only a specified amount of time before it is automatically logged off; second, through the utilisation of any approved timeframe that may be present on the ITSM ticket, which the ticketing integration process between PAM solution and ITSM can validate. Using this type of configuration, the required session can only be established during a specified time window and will only be allowed for a set duration.
A missing piece of the puzzle for the topic of access revocation is contained in the requirement that privileged access shall be automatically revoked once the ticket is closed. Obviously any ticketing integration process should not allow a closed ticket to pass a validation process, so no new connections will be able to be established using the details of a ticket which is already closed, but what about sessions which are already established; should this requirement be interpreted to mean that a privileged access session using the details of a ticket should be terminated once the status of the ticket is set to a closed state?
Validation of ticket status when a PAM tool is integrated with ITSM occurs during the workflow to gain access to a privileged account when commencing a session managed by the PAM tool. Ongoing validation of the ticket status throughout the duration of any privileged session is not a feature of a standard ticket validation process; once access to an account is granted via the PAM tool, the validation process is complete. To understand if the status of a ticket has changed during an ongoing session some custom development must be considered.
To enact a session termination if a ticket status is changed to a closed state, if the process cannot be initiated from the PAM tool, should it be initiated from the ITSM tool? Within the bounds of the TSA measures it is not desirable to a telecoms provider to allow control of a high trust security function, such as a PAM tool, from a lower trust system such as an ITSM ticketing solution. Controlling a high trust system from a low trust system involves implementation of security measures and controls to mitigate all identified inherent risks, with a goal of ensuring that the security of the high trust system is not inadvertently compromised via interactions from the lower trust system.
Using APIs available from both the PAM and ITSM tools, development of a middleware solution can be considered to enable secure interaction and PAM session termination capabilities based on ITSM ticket state. By incorporating the middleware into the network using isolation and segmentation, a provider would be able to control interaction of PAM tooling using data retrieved from ITSM, while ensuring the solution was appropriately authenticated and configured with appropriate authorisation to query ITSM and control the PAM tooling and thus able to act as an intermediary layer.
In simple form, an overview of how such an intermediary middleware solution could be configured to function is described in the following example.
Middleware Workflow:
- Session Enumeration: solution collects active session data from the PAM tool and builds a list of active sessions and the details of the ticket ID used to obtain authorisation to open the session
- Query Ticket State: each ticket associated with any active session currently open via the PAM tool is queried to validate its status; if the ticket is open no action is required
- Session Termination: if a ticket from the previous step is found to be closed then for each associated session, using available APIs of the PAM tool, a session termination is enacted
- Ticket Update: where a session is terminated, the middleware could add detail of the termination activity as an update to the related ticket to embellish the audit detail for the privileged activity and timeline
- Repeat: working on a scheduled basis, the middleware would regularly repeat the process, enumerating sessions, querying tickets, terminating sessions and handling errors as required
Adopting a middleware approach as described above maintains segregation between ITSM and PAM, and where the middleware is built and installed in an appropriate part of the providers network enables control of the PAM tooling to support the session termination conditions mandated by the TSA measures.
Providers have the option to incorporate session terminations directly into their ITSM services, but they must make sure that ITSM is sufficiently safeguarded to prevent any potential compromise or misuse of the ITSM solution from negatively impacting the use of PAM sessions for necessary and routine production network maintenance.
Operational Considerations
Introduction of such configurations as described so far can introduce operational overhead for end users and PAM administrators alike, especially if ticketing integration is not implemented or actively in use currently.
End users can be particularly resistant to the notion of having an additional hoop to jump through to gain the access they require to do their job, even with the requirement stipulated in the TSA measures. When faced with a requirement to have a valid ticket ID to provide to gain privileged access, end users may try and work around the requirement by having a long-standing generic ticket open for some time so that they can re-use the same ticket ID repeatedly. While the measures do allow for a ticket to remain open, they also require a daily update with the reason the ticket is being kept open. This is a ITSM process point and beyond any integration between the ITSM ticketing systems and PAM tooling.
Where a provider is not already using a ticketing integration to control access to privileged accounts, it is possible that operational teams or processes are identified which are not already represented in the ITSM tooling. Additional effort will be required to create entities in ITSM to enable teams to be able to meet ticketed access requirements.
While most PAM tools do already offer out of the box integration with ITSM ticketing solutions, there may be version dependencies or support for only some specific ITSM systems. Additional development could be required to complete an integration with the required features.
If considering development and adoption of a middleware type solution to control session termination activity when a ticket is closed, it is required to be able to associate a session ID in the PAM tool with the linked ticket ID in the ITSM tool. If it is not possible to query the PAM tool for an associated ticket ID, it could be considered to customise the ticket validation process to update the ITSM ticket with details of the PAM session, allowing a link between session and ticket to be established and later used to understand what session IDs should be terminated.
If considering development and adoption of a middleware type solution to control session termination activity when a ticket is closed, it is required to be able to associate a session ID in the PAM tool with the linked ticket ID in the ITSM tool. If it is not possible to query the PAM tool for an associated ticket ID, it could be considered to customise the ticket validation process to update the ITSM ticket with details of the PAM session, allowing a link between session and ticket to be established and later used to understand what session IDs should be terminated.
Considering that only four individual measures from the TSA Code of Practice mention use of tickets for privileged access, and this remains a relatively high-level blog post, you can appreciate the depth of detail it is possible to go when considering exactly how to put in place the configurations and controls required to meet all of the requirements contained in the published guidance for TSA.
The capability of the technologies in play at a provider must be evaluated and configured appropriately and converged with processes to support requirements around access and operations. Depending on what technologies are in place and what skills are held in-house the journey toward compliance with the measures may be simpler for some providers than it is for others.
Building a robust access workflow around critical network infrastructure is an important facet of the TSA measures and is likely to be more restrictive than what engineers and technical resources are currently accustomed to; strong communication and socialisation of what is being implemented, why it is being implemented and when users will have to adopt new ways of working will aide transition toward new ways of working. Transformation will be met with some resistance, so preparing the messaging around the compliance activities should not be overlooked. Early engagement with key technical resources can also help develop workable processes fit for your operational teams and identify champions who can support implementation initiatives.
Whatever stage you are at on your compliance journey, CyberIAM can help. We already work with a number of Tier 1 UK telecom providers on TSR topics as trusted advisors in the PAM and IAM space and understand the many aspects providers must consider when designing how best to address the measures, and the resource constraints faced with many ongoing initiatives running in parallel. From design and implementation to development and onboarding, our teams have in demand skills and the industry best practice knowledge to help you bolster you approach to meeting your ongoing obligations for the Telecoms Security Requirements.
Download our CSA Brochure
Download our brochure now for detailed information on how our Current State Assessment can identify the areas of your business needing improvement, bringing you towards TSA compliance and protecting your business.
Download our White Paper
Learn more about navigating TSA and the imperative of identity and access governance in a comprehensive guide written by one of our expert principal consultants.