Security Service Orchestration Function for CSP Interoperability

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current security orchestration and management systems lack standardized interfaces for interoperability, leading to unstable and costly security management in communication service provider (CSP) networks, with static and ambiguous Service Level Agreements (SLAs) that do not account for dynamic security requirements or real-time monitoring and compliance verification.

Innovation Solution

A security service orchestration function (SSOF) that enables standardized security service level agreements (S-SLAs) between CSPs, allowing for dynamic negotiation and monitoring of security capabilities, converting S-SLA requests into unified offers, and merging security attributes into a common baseline template for consistent compliance reporting.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Adaptability or versatility

If vendor-specific non-standard interfaces are used for security management, then implementation flexibility is improved, but interoperability deteriorates

Engineering Contradiction:
Improveimplementation flexibilityVSAvoidinteroperability
Core Design Contradiction:
Adaptability or versatilityVSReliability

Solution Approach 1:

The patent introduces a universal security orchestration interface that can work across different vendor systems. The security service level agreement (S-SLA) framework defines standardized interaction protocols that enable multiple security management functions to operate through a common interface, allowing the system to be universally applicable while maintaining vendor-specific implementation capabilities.

Inventive Principle:
Principle #6Universality (Multi-functionality)

Solution Approach 2:

The patent employs an intermediary security orchestration function that mediates between vendor-specific security systems and the standardized management interface. This intermediary layer translates between proprietary interfaces and the standardized S-SLA framework, enabling interoperability without forcing vendors to abandon their specialized implementations.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Device complexity

If static SLA definitions are used for security agreements, then agreement simplicity is improved, but dynamic security requirement fulfillment deteriorates

Engineering Contradiction:
Improveagreement simplicityVSAvoiddynamic security requirement fulfillment
Core Design Contradiction:
Device complexityVSAdaptability or versatility

Solution Approach 1:

The patent transforms static SLA definitions into dynamic S-SLAs that can adapt to changing security requirements. The framework includes mechanisms for real-time monitoring, automated negotiation, and dynamic adjustment of security service levels, allowing agreements to evolve in response to emerging threats and changing business needs while maintaining structured governance.

Inventive Principle:
Principle #15Dynamics

Solution Approach 2:

The patent enables dynamic modification of security service level parameters during the agreement lifecycle. The S-SLA framework defines adjustable parameters such as security metrics, compliance thresholds, and service levels that can be modified through automated negotiation processes, allowing the agreement to adapt to changing requirements without requiring complete renegotiation.

Inventive Principle:
Principle #35Parameter changes

3Loss of energy

If self-assessments and yearly audits are used for security conformance, then evaluation cost is reduced, but real-time compliance monitoring deteriorates

Engineering Contradiction:
Improveevaluation costVSAvoidreal-time compliance monitoring
Core Design Contradiction:
Loss of energyVSLoss of time

Solution Approach 1:

The patent replaces periodic audits with continuous automated compliance monitoring. The S-SLA framework establishes ongoing verification processes that continuously assess security conformance through automated measurements and reporting, eliminating the gaps between yearly audits and providing real-time visibility into compliance status without requiring constant manual intervention.

Inventive Principle:
Principle #20Continuity of useful action

Solution Approach 2:

The patent implements feedback mechanisms that provide real-time information on security compliance status. The automated monitoring system continuously collects security metrics, compares them against S-SLA requirements, and provides feedback to relevant parties, enabling immediate detection and response to compliance deviations while maintaining cost-effective operation through automation.

Inventive Principle:
Principle #23Feedback

4Device complexity

If security is unconnected from network functions, then network function independence is improved, but security orchestration capability deteriorates

Engineering Contradiction:
Improvenetwork function independenceVSAvoidsecurity orchestration capability
Core Design Contradiction:
Device complexityVSExtent of automation

Solution Approach 1:

The patent segments security orchestration into independent modular functions that can operate autonomously while maintaining coordinated interaction. The S-SLA framework defines discrete security service functions that can be independently implemented and managed, allowing network functions to remain independent while enabling automated security orchestration through standardized interfaces and coordination protocols.

Inventive Principle:
Principle #1Segmentation

Data Source

PatentUS20240314171A1Security service orchestration function between communication service providers
Publication Date: 2024.09.19 TELEFONAKTIEBOLAGET LM ERICSSON (PUBL)
  • US20240314171A1 patent drawing
  • US20240314171A1 patent drawing
  • US20240314171A1 patent drawing

AI summary

A method implemented by a security service orchestration function (SSOF) in a communication infrastructure, that includes a plurality of communication service providers (CSPs), for orchestration of a security service level agreement (S-SLA) includes receiving a S-SLA request, by a CSP, from one or more other CSPs. Each S-SLA request includes a plurality of requirements. The method also includes converting each S-SLA request into a consistent and unified S-SLA offerable to each other CSP. The consistent and unified S-SLA includes security attributes that the CSP is capable of providing the other CSPs. The method also includes offering the consistent and unified S-SLA to each other CSP that submitted the S-SLA request. The method further includes receiving a response from each other CSP. The response from each other CSP includes an acknowledgement or a decline of the consistent and unified S-SLA including a non-repudiation signature of acknowledgement or declining.