New ODA guides help DSPs design security into IT systems and assess risks
5G deployment increases exposure to cyberattacks, and digital service providers' IT systems are not immune to the threats. Two new, important pieces of work from the TM Forum Open Digital Architecture project aim to help operators assess and contain the risks by designing security and privacy into support systems.
Dave Milham
03 Jul 2019
New ODA guides help DSPs design security into IT systems and assess risks
Every day there are new stories about the potential danger of 5G increasing exposure to cyberattacks, and digital service providers’ (DSPs’) IT systems are not immune to such security threats. Two new, important pieces of work from the TM Forum Open Digital Architecture (ODA) project aim to help operators assess and contain the risks by designing security and privacy into support systems.
ODA is a new technology architecture and set of best practices for delivering Agile, next-generation operational and business support systems (OSS/BSS). It is part of the TM Forum Open Digital Framework, which is an interactive, continuously evolving collection of tools, knowledge and standards that give CSPs an end-to-end migration path from legacy systems to modular, cloud-native IT components.
ODA applies DevOps practices to network operations, which helps DSPs increase automation, improve flexibility and reduce costs. However, using Agile methodology also increases the attack surface compared to traditional OSS/BSS, so new approaches are needed to contain security risks and comply with the EU’s General Data Protection Regulation (GDPR) requirements.
As part of TM Forum Release 19, two new ODA Information Guides have been completed and are now available for members to review. Once they’ve been approved by members, the guides will be available for everyone to download. They cover a full enterprise lifecycle vision for security and governance, and offer a detailed set of methods for enterprise risk assessment which are suitable for DevSecOps automation:
ODA Governance and Security Vision (IG1186) is a business-level view of the security concepts and requirements for security, which adapts best practices from many organizations (in particular, the Open Group and SABSA® Security additions to TOGAF) and applies them specifically to the ODA Lifecycle. The ODA Lifecycle, which is outlined in IG1166, covers four points of view within DSP organizations: business, functional/information systems architecture, technical architecture, and implementation and deployment architecture. This guide also sets out the roadmap of additional security requirements and future work – including the need for assessing the impact of telecom regulation and other requirements such as GDPR.
The ODA team began its work on security at Action Week in Lisbon in February, focusing on enterprise risk assessment of the ODA Functional Architecture (ODAFA), which provides a high-level overview of functions that relate to the capabilities of a digital business or enterprise (see graphic below). The team also considered security consequences of adopting cloud-native ODA implementations.
This was followed by a workshop in the historic Hanseatic League City of Hamburg, which was hosted by Oracle and supported by Vodafone and Huawei. Representatives from blockchain specialist Clear and security consultancy HardenStance also contributed.
Several salient points emerged from the workshop and the subsequent development of the ODA guidebooks:
Security must be designed in – all the ODA Lifecycle viewpoints must address relevant security requirements and threats. The initial focus is on information systems architecture and implementation viewpoints. This requires formal enterprise risk assessment of the operations and information exposed, mitigation mechanisms and setting policies for implementing Open APIs.
Cloud-nativeagility – this is achieved by assembling configurations of run-time components, each containing collections of ODA functions exposed by Open APIs. Review of several Kubernetes implementation examples and best practices showed the importance of cloud operating principles, especially when moving from virtual machine (VM) to container-based models.
DevSecOps opportunity – the speed of digital business adds to security threats and requires new security approaches. Previously the borders between development and operational deployment were an important security and privacy defence, especially against insider attacks, but they also introduce delay. Moving to DevSecOps allows security practitioners, to operate and contribute value without introducing friction into innovation cycles. For ODA solutions using DevSecOps, the main security decisions are made by implementation and development teams since deployment becomes a completely automated process. Hence operational security requirements and enforcement become a part of development, and implementation decisions and are informed by the enterprise risk assessment of ODA functions and their collection into components. As operators adopt virtualization, there isn’t a stable physical boundary – software is being scaled and moved dynamically, so it’s not feasible to set up a static set of software and audit it as it could change a few seconds later. This means that operators must get security sorted in the implementation templates which automatically deploy code.
Enhancing ODAFA – ODAFA currently focuses on operational processes needed for Agile OSS/BSS. As with the TM Forum Business Process Framework (eTOM), there are additional enterprise function definitions needed which include security management together with associated governance/policy functions. The ODA security proposal extends ODAFA to support ODA security and governance functional areas and enhances ODA Intelligence functions to support security management.
Assessing enterprise risk
The workshop also identified three key tools for enterprise risk assessment, which are discussed in detail in the risk assessment guide:
An overall risk assessment method using STRIDE+P – covering spoofing, tampering, repudiation, information disclosure, denial of service and elevation of privileges, and extended with added dimension for privacy violation to focus on rights protection, this provides a systematic and objective way of assessing risk in the extended ODAFA.
Risk assessment scoring– based on a combination of the likelihood of a risk and the consequences of the risk occurring, this provides a way to measure of the strength of mechanisms for implementing risk reduction.
Trust boundaries – the concept of shared responsibility is widely used in the cloud context (for example Amazon Web Services and Azure). Trust boundaries help to define where there is shared responsibility within DSPs and between them and their ecosystems partners. Trust boundaries start at a top level in the ODAFA and evolve into component trust boundaries in the implementation, for which shared responsibility and trust is needed between the users of data and those providing it.
What’s next?
TM Forum members are planning the next phase of work on ODA security. The team meets weekly on a conference call, and the next face-to-face meeting will take place at Action Week in Dallas in September. If you would like to get involved, please contact me directly via dmilham@tmforum.org.