UK TSA Regulations: SOC Teams, Get Ready!

Hey Telco Security Ninjas,

The UK Telecommunications Security Act (TSA) compliance is coming and SecOPs teams will play a more prominent role in ensuring a resilient mobile network and keeping our 5G connections stable. First of all, thank you for your passion for cybersecurity and your hard work. You have a very important purpose and mission for the country's resilience.

With the rollout of UK TSA regulations, numerous departments and business stakeholders involved in digital services will come to rely on the support and service of the SecOps team. The scope of coverage and needed operating model will expand, requiring proactive preparation by the teams involved.

In this post, we will

1. look at a brief overview of TSA - for more in-depth information read this blog
2. review top SOC requirements extracted from the Code of Practice
3. take a look at a practical, end-to-end operational SIEM use case

Tier 1 Provider Concerns about TSA: Tight Timelines and Additional Costs

During the TSA consultation process, tier 1 providers raised concerns regarding additional costs and tight timelines for implementation. Another raised issue was the possibility of an impact on 5G rollouts and beyond.

So what specific requirements does the legislation place on SOC teams? What practices may already be in place at your organization and what adjustments need to be made? Let's do a sanity and hygiene check. But first some good news. SOC teams are most likely to receive attention, funding, and support from management and business stakeholders as non-compliance could result in hefty fines.

SOC Teams, Get Ready for a GAP Analysis

The faster and more efficient the validation process for the necessary measures run, the lower the cost and friction for all stakeholders involved. This is great news for Splunk customers and our platform approach. As adaption is simple, and if specific assets are not currently monitored, adding coverage is a seamless process. Moreover, it provides an opportunity to assess the feasibility of standardizing on Splunk Enterprise Security and making progress toward mature Standard Operating Procedures (SOPs) with the support of Splunk SOAR capabilities.

The bad news is that this project requires collaboration with many different teams.

Measures Affecting the SOC Team

We reviewed the Code of Practice and extracted what we believe are the most crucial measures for you as a SOC team to validate. Please let us know if we missed any measures that are of utmost importance to you!

SOC Capabilities and Services Established:

• Is our SOC tooling hosted in the UK?

• Do we have the key staff to operate the SOC from the UK for a month, without relying on any offshore/nearshore capabilities?

• Can we safely operate our service for up to a month securely if borders are physically closed and international network connections are down?

• Is the scope of our SOC changing in terms of digital systems, services, and applications that need to be monitored?

• Do we have to adjust to new SLA times? What would be the impact?

• Are we collecting the right log data for threat hunting?

• Do we have a process in place to share threat intelligence with other UK telco providers?

• Do we have admin activities monitored and linked to change tickets to conduct investigations quickly and accurately and create a “storyline”?

• Do our SIEM users log in with multi-factor authentication?

• Do we have a list of tools used for real-time monitoring of our network or service?

  • Do any of our tools in the SOC fall into this?
  • Do we monitor that these tools only store data in the UK or/and have we assessed the risk of storing audit logs outside the UK?
  • Do we monitor that these tools cannot be accessed from TSA-listed countries that pose a security risk to the UK public telco network?
  • Do we monitor that the data is not misused or attackers don’t gain access?

Does the SOC Provide Security Monitoring for the Following:

• element managers; virtualization orchestrators; management systems (e.g. jump boxes); security functions (e.g. firewalls at the edge of a security zone); root authentication services (e.g. active directories - ADs); multi-factor authentication services; security gateways (e.g. supporting the management plane); audit and monitoring systems (including network quality monitoring of speech and data); operational support systems
• Break-glass user accounts should be should be in place for emergency access outside of change windows. However, when these are used, alerts must be raised, circumstances investigated and all activity logs reviewed after an emergency.
• Physical and logical interfaces between networks operating at different trust levels and between groups of network functions (e.g. core networks and access networks) must be monitored.
• Providers must regularly review access logs and correlate this data with other access records and ticketed activity.
• Network changes that could affect network security must be reported to those monitoring the network. Monitoring processes must be maintained and modified if necessary
• Network-based and host-based sensors must be deployed and run throughout networks to capture traffic to support security analysis.
• Access events to network devices must be captured. Unauthorized access attempts are to be considered a security event.
• Network device configurations must be regularly and automatically captured and reviewed to detect unexpected changes.

Does Our SIEM Architecture Align with TSA Requirements?

• Logs should be processed and analyzed in near real-time (in any case within 5 minutes) and generate security-relevant events.
• How long do we keep our log data? Do we have the facility to keep logs for 13 months?
• Systems that collect and process logging and auditing data are treated as network supervisory functions.
• The integrity of the logging data must be protected and every change must be reported and attributed. Have we implemented data integrity/hashing for our logs?
• All actions related to stored logging or monitoring data (such as copying, deleting, modifying, or viewing) must be traceable back to an individual user
• Logging datasets must be synchronized using common time sources so that separate datasets can be correlated in different ways.
• Logging data is intended to be enriched with other network knowledge and data. In order to successfully analyze logging data, it must be used in conjunction with knowledge of the provider's network as well as other relevant data necessary to understand log entries.
• Logs need to be associated with specific network devices or services.
• Do you get an alert if a data source stops logging?
• Have you set up a policy on NTP synchronization for our logging infrastructure?

In Practice: A SIEM Monitoring Use Case

Requirement:

Regulation 6 establishes the requirement to monitor and analyze access to security-critical functions of the public electronic communications network in order to be able to identify security risks at an early stage and investigate the root cause. Records must be kept secure for at least 13 months.

The Security Code of Practice describes many best practices for network and host-based monitoring as well as effective analyzes and operations within a SOC.

5.19 describes that a "story” must be to be created e.g. a session audit trail. “Monitoring data should link administrative actions to network administrators and onto tickets.” Because the TSA has a strong focus on the risk of third-party administrators of MSPs due to the supply chain hacking activity of the “APT10”, this is a perfect use case to set up monitoring and automate with your SIEM.

Scenario:

It is crucial to implement a procedural level change management process across all of the organization's most critical applications. The most common approach is to use the ticketing systems to document upcoming system maintenance activities and define the 5 W’s: Who, What, When, Where, and Why.

Security monitoring is greatly simplified by correlating change tickets with audit trails and activities. Changes made outside of the designated change windows can be treated as potentially malicious activities or anomalies, while changes made within the specified time window can be treated as “acceptable” or “trustworthy”. Depending on the risk appetite, trusted changes may also be subject to review.

Let’s decode this with an example. Let's assume a change management ticket in ServiceNow contains the following:

Peter comes from a third-party MSP. It’s organizationally specified that he uses the telco’s Citrix service as an admin hop client to connect to the telco’s backend infrastructure.

Data Needs

• Authentication data of the 2FA System Peter/the MSP uses
• Citrix Logon and Session Information Audit Data
• Audit data from the command line and file transfer activity from/to the Citrix session
• Network communication from the Citrix service to the 5G critical equipment
• Audit trail data of system changes and admin authentications of the 5G device
• Ticketing/change management data containing the 5W's in a standardized, normalized, reusable format.

Correlations:

Multiple security correlation searches can now be set up, such as:

• Detection of third-party admin activities outside the change window (attackers may not be aware of the change window).
• Detection of traffic from admin hop stations to critical equipment for which no changes are planned (attackers may not know which systems are affected by the change).
• Unauthorized logins and even modifications to 5G devices outside of change windows (attacker may not be aware of the jump boxes from where the changes have to be made).

Since we are not bothered by a malicious administrator (insider threat) in this scenario, but rather we are concerned that a malicious foreign actor has stolen an administrator's identity, we must contact that administrator within a set timeframe.

• Option A: You have a SOC Analyst who contacts the administrator to validate if it was her/his action, document it, and close the matter or further escalate it if it’s a genuine account takeover for further forensic investigations, disabling that user account, resetting credentials, additional investigations on systems touched etc.
• Option B: You go big and automate it. Either via a SOAR tool that can, for example, automatically contact you via a trusted channel and collect feedback/input from the employee/administrator or you hand it over with a detailed description to the Service Desk IT Team to follow up. Depending on your risk appetite and organizational situation.

This example establishes a minimum set of guard rails for monitoring with a very low false positive rate. Establishing an organizational change process is the foundation that this standardized process avoids reviewing individual security alerts without context and makes follow-up tedious for the SOC team.

Hope you enjoyed this blog where we connected regulation requirements with real-world operations.

Happy Splunking,

Matthias