Our OSS/BSS manage some of the world’s most vital comms infrastructure. That makes them pretty important assets to protect from cyber-intrusion. Therefore security is a key, but often underestimated, component of any OSS/BSS project.
Let me start by saying I’m no security expert. However, I have worked with quite a few experts tasked with securing my OSS projects and picked up a few ideas along the way. I’ll share a few of those ideas in today’s post.
We look at:
- Security Trust Zones/Realms
- Restricting Access to OSS/BSS systems and data
- OSS/BSS Data Security
- Real-time Security Logging/Monitoring
- Patch Management
- Security Testing/Hardening
- Useful Security Standards
1. Security Trust Zones/Realms
For me, security starts with how you segment and segregate your network and related systems. The aim of segmentation/segregation is to restrict malicious access to sensitive data/systems. The diagram below shows a highly simplified three-realm design, starting at the bottom:
- The operator’s Active Network realm – the network that carries live customer traffic and is managed by the CSP/operator [Noting though, that these are possibly managed as virtual and/or leased entities rather than owned]. It comprises the routers, switches, muxes, etc that make up the network. As such, this zone needs to be highly secure. Customers connect to the Active Network at the edge of the organisation’s network, often via CPE (Customer Premises Equipment), NTU (Network Termination Units) or similar. Dedicated Network Operation Centre (NOC) operator terminals tend to connect inside the Active Network
- The operator’s Corporate/Enterprise realm – the network that houses the organisation’s corporate IT assets. This is where most corporate staff engage with core business services like desktop tools and so much more. If network operations staff need to connect to the Corporate / Enterprise realm but also reach into the Active Network realm, then an air-gap is usually established by the SCP between the two. This is bridged through technologies like Citrix, RDP (Remote Desktop Protocol) or similar
- The Cloud/Internet realm – the external networks/infrastructure utilised by the organisation that are outside the organisation’s direct control. This includes Internet services, which many corporate users rely on of course. However, it may also include some important components of your OSS/BSS stack if provided as public cloud services, an increasingly common software supply model these days
- You’ll also notice the all-important Security Control Points (SCP) like firewalls that provide segregation between the zones.
In all likelihood, your security trust model will contain more than three zones, but these should be the absolute minimum.
The Active Network should be segregated from the Corporate/Enterprise network so that it can continue to provide service to customers even if the connection between them is lost (or intentionally severed if a security breach is identified).
This is where things get interesting. The Active Network and our Network Management stack rely on Shared Services such as DNS (Domain Naming System), NTP (Network Time Protocol), Identity/Access Management, Anti-Virus and more. These tend to be housed in Corporate/Enterprise realms. If we want the Active Network to be able to operate in complete standalone mode then we need to provide special consideration to the shared services architectures.
Aside: Traditionally, we’ve focused on perimeter defence and authenticated users are granted authorised access to a broad collection of resources. We now see the trend towards more remote users and cloud-based assets outside the enterprise-owned boundary in our OSS architectures. There’s current debate around whether zero-trust architectures are required to segment more holistically – to restrict lateral movement within a network, assuming an attacker is already present on the network. The NIST ZTA draft discusses this emerging approach in more detail.
Once we have the security trust zones identified, we now have to determine where our OSS/BSS management stack resides within the zones. If we use the layers of the TMN Pyramid as a guide:
- The Network Element Layer (NEL) is the heart of the Active Network;
- The EMS/NMS (Element/Network Management Systems) will also usually reside within the Active Network;
- The OSS/BSS are interesting. They have to interface with the network and EMS/NMS. But they also usually have to interface with corporate systems like data warehouses, reporting tools, etc. They’re so critical to managing the Active Network, they need to be highly secure. That means they could be placed inside the Active Network realm or even have their own special Central Management realm. In other cases, different components of the OSS/BSS might be spread across different realms.
Note that we also have to consider the systems (e.g. user portals, asset management systems, etc. etc.) that our OSS/BSS need to interface to and where they reside in the trust model.
2. Restricting Access to OSS/BSS systems and data
We want to uniquely control who has access to what systems and data using our OSS/BSS stack.
The Security Trust model also impacts the architectures of Identity Management (Directory Services like Active Directory), User Access Management (UAM) and Privileged Access Management (PAM) solutions and how they control access to our OSS/BSS.
They serve three purposes:
- To provide fine-grained management of access to privileged/restricted data and systems within our OSS/BSS
- To simplify the administrative overhead of managing user access to our OSS/BSS by defining group-based user access policies
- To log the activities of individual users whilst they use the OSS/BSS and related systems/networks.
Most OSS/BSS allow user authentication via Directory Services these days. Most, but not all, also allow roles/privileges to be assigned via Directory Services. For example, RBAC (Role Based Access Control) is policy that is defined by our OSS/BSS applications. It controls what functions users/groups can perform via permission management. For central user administration purposes, it’s ideal that the Directory Service can pass role-based information to our OSS/BSS.
3. OSS/BSS Data Security
The first step in the data security process is to identify categories of data such as unclassified, confidential, secret, etc.
We then need to consider what security mechanisms need to be applied to each category. There are four main OSS/BSS data security considerations:
- Data Anonymisation/Privacy – is the process of removing/redacting/encrypting personally identifiable information from the data sets stored in our OSS/BSS (particularly the latter). Our solutions need to store personal data such as names, addresses, contact details, billing details, etc. We can use techniques to control the pervasiveness of access to that data. For example, we may use a tightly restricted system to store personal details as well as a non-identifiable code (e.g. LocationID or ServiceID) for use by our other more widely accessed tools (e.g. PNI/LNI)
- Encryption of data at rest – is the process of encrypting the large stores of data used by our OSS/BSS, whether a local database used by each application or in centralised data warehouses
- Encryption of data in transit – is the process of encrypting data as it transits between components within your OSS/BSS stack (and possibly beyond). Techniques such as VPNs and IPSec protocols can be used. As we increasingly see OSS / BSS built as web-based applications, we’re using encrypted connections (e.g. HTTPS, SSL, TLS, etc) to protect our data
- Physical security – is the process of restricting physical access to data stores (e.g. locked cabinets, facilities access management, etc). This isn’t always within our control as an OSS/BSS project team.
4. Real-time Security Logging/Monitoring
Ensure all systems in the management stack (OSS, BSS, NMS, EMS, the network, out-of-band management, etc.) are logging to a central SIEM (Security Information and Event Management) tool. Oh, and don’t do what I saw one big bank do – they had so many hits occurring just on their IPS/IDS tool that they just left it sitting in the corner unmonitored and in the too-hard basket. By having the tools, they’d ticked their compliance box, but there was no checkbox asking them to actually look at the results or respond to the incidents identified!!
5. Patch Management
Software patch management is theoretically one of the simplest security management techniques to implement. It ensures you have the latest, hopefully, most secure, version of all software.
OSS/BSS/Management stacks tend to have many, many different components. Not just at the obvious application level, but operating systems, third-party software (e.g. runtime environments, databases, application servers, message buses, antivirus software, syslog, etc.).
Patch management is often well maintained by IT teams within the Corporate/Enterprise trust zone discussed above. They have access to the Internet to download patches and tools to help push updates out. However, the Active Network zone shouldn’t have direct access to the Internet, so routine patch management could be easily overlooked and/or difficult to implement. Sometimes the software components reside on servers that are rarely logged into and patches can be easily overlooked.
The other problem is that OSS/BSS applications are often heavily customised, making it hard to follow a standard upgrade path. I’ve seen OSS/BSS that haven’t been patched for years, even with something as simple as Jave runtime environments, because it causes the OSS/BSS to fail.
6. Security Testing/Hardening
Your organisation probably already has standards and checklists in place to ensure that all of your IT assets are as secure as possible. Your OSS/BSS environments are just one of those assets. However, as the “manager of managers” of your Active Network, the OSS/BSS is probably more important to secure than most.
Your organisation might also insist that all applications, including the OSS/BSS, are built on a hardened Standard Operating Environment (SOE). However, some suppliers provide OSS/BSS as appliances, built on their own environments. These then have to go through a hardening process in alignment with your corporate IT standards.
If using a vendor-supplied off-the-shelf application, it will be quite common for it to have a default admin account on the application and database. This makes it easier for the system implementation team to navigate their way around the solution when building it. However, one of the first steps in a hardening process is to rename or disable these built-in accounts.
As “manager of managers,” your OSS/BSS‘s primary purpose is to collect (or request) information from a variety of sources. Some of these sources reside in the Active Network. Others reside in the Corporate Network or elsewhere. As such, careful consideration needs to be given to what Ports/Protocols are allowed. Some systems will come pre-configured with default/open settings. However, these should be restricted to necessary protocols only, including SNMP, HTTPS, SSH, FTPS and/or similar.
Speaking of SNMP, its original design was inherently insecure as it uses a primitive method of authentication. It uses clear-text community strings to secure access to the management plane. Only version 3 of SNMP (i.e. SNMPv3) has the ability to authenticate and encrypt payloads, so this should be used wherever possible. Some of you may have legacy device types that precede SNMPv3 though. Alert TA17-156A provides suggestions to minimise exposure to SNMP abuse.
Also, consider the environment on which you’re performing your security testing. As described in this post about OSS/BSS environments and test transitions, you’ll probably have multiple environments – PROD environments that are connected to the live Active Network devices and non-PROD environments that are connected to test lab devices and/or simulators. Where should you perform your penetration/security testing? Probably not on PROD, because you want to ensure the solution is already secure before letting it loose into Production. But you also want to ensure it’s the most PROD-like as possible. You could possibly use PRE-PROD (i.e. a state before a solution is cut-over to PROD) before it’s fully connected to the Active Network. Or, you could use the most PROD-like lower environment (e.g. Staging).
One other thing when conducting security tests and hardening – penetration testing often breaks things by injecting malicious code/data. Ensure you take a backup of any environment so you can roll-back to a working state after conducting your pen-tests.
7. Useful Security Standards
The following is a list of security standards that I’ve used in the past:
- NIST’s “Framework for Improving Critical Infrastructure Cybersecurity”
- PCI-DSS – the compliance framework for credit cards
- Cloud Security Alliance – Big Data Security and Privacy Handbook
- TSSR (Telecommunications Sector Security Reforms)
- The Australian Signals Directorate’s Essential 8
- The NIST Zero Trust Architecture (draft)
As I mentioned at the start, I’m far from being an expert in the field of network or data security. I’d love to get your feedback if I’m missing anything important!!