Secure Sidecar Container Network Isolation

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current software deployment methods do not adequately separate and secure third-party libraries from application code, leading to risks of data breaches and undetectable malicious code, as existing security scanning tools cannot identify obfuscated backdoors or intentional security holes.

Innovation Solution

The approach involves splitting a software application into separate containers at deployment time, with one container hosting the owned application code and others hosting third-party libraries, using secure sidecar containers that restrict network access and allow only specified communication, thereby isolating libraries and preventing malicious activity.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Ease of operation

If third-party libraries are placed in the same container as application code, then deployment simplicity is maintained, but security risks increase due to inability to isolate malicious code

Engineering Contradiction:
Improvedeployment simplicityVSAvoidsecurity risks from malicious code
Core Design Contradiction:
Ease of operationVSObject-affected harmful factors

Solution Approach 1:

The patent divides the deployment container into multiple isolated network segments: a trusted application code container and untrusted library containers. The application code resides in its own container while third-party libraries are placed in separate containers with restricted network access. This segmentation allows simple deployment of all components while physically isolating potential malicious code from the application, resolving the contradiction between deployment simplicity and security.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces a service mesh proxy as an intermediary component between the application code and third-party libraries. This proxy controls and monitors all network traffic, allowing legitimate communication while blocking malicious outbound calls. The intermediary enables both simple deployment (all components can be deployed together) and security (the proxy filters harmful traffic), resolving the contradiction by adding a mediating layer.

Inventive Principle:
Principle #24Intermediary (Mediator)

2Measurement precision

If security scanning is performed on libraries, then detection of known vulnerabilities is improved, but detection of obfuscated backdoors remains ineffective

Engineering Contradiction:
Improvevulnerability detection accuracyVSAvoidobfuscated backdoors
Core Design Contradiction:
Measurement precisionVSObject-affected harmful factors

Solution Approach 1:

The patent applies security scanning as a preliminary action during the deployment process, before the application goes into production. While this improves detection of known vulnerabilities, the patent acknowledges its limitation against obfuscated backdoors. The resolution comes from combining this preliminary scanning with runtime network isolation and monitoring, creating a layered approach where preliminary scanning catches known issues and runtime controls prevent unknown threats.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent converts the potential harm of undetectable backdoors into a benefit by using network isolation and monitoring. Even if a backdoor cannot be detected by scanning, its malicious network traffic can be identified and blocked by the service mesh proxy. The inability to detect the backdoor directly becomes irrelevant because the behavioral patterns of malicious code are visible and controllable at the network level.

Inventive Principle:
Principle #22Blessing in disguise (Convert harm into benefit)

3Object-affected harmful factors

If libraries are isolated in separate containers, then security is improved by blocking malicious activity, but system complexity increases

Engineering Contradiction:
Improvemalicious code preventionVSAvoidcontainer architecture complexity
Core Design Contradiction:
Object-affected harmful factorsVSDevice complexity

Solution Approach 1:

The patent employs a service mesh proxy that performs multiple functions: it routes traffic between containers, monitors network communications, enforces security policies, and provides observability. This single multi-functional component handles the complexity of managing isolated containers, making the system easier to operate despite the increased architectural complexity. The universal proxy resolves the contradiction by consolidating multiple management functions into one component.

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

Solution Approach 2:

The service mesh proxy automatically manages the isolated container architecture without requiring manual intervention for each security decision. It self-configures network policies, automatically monitors traffic patterns, and enforces isolation rules. This self-service capability reduces the operational burden despite the complex container architecture, resolving the contradiction between security isolation and system complexity.

Inventive Principle:
Principle #25Self-service

4Object-affected harmful factors

If network access is restricted for library containers, then prevention of data breaches is improved, but legitimate communication may be blocked

Engineering Contradiction:
Improvedata breach preventionVSAvoidlegitimate communication
Core Design Contradiction:
Object-affected harmful factorsVSEase of operation

Solution Approach 1:

The service mesh proxy implements feedback mechanisms by monitoring network traffic patterns and using this information to dynamically adjust security policies. It learns from observed communication patterns to distinguish between legitimate and malicious traffic. This feedback loop allows the system to maintain strict network restrictions while automatically permitting legitimate communication, resolving the contradiction between data breach prevention and legitimate communication.

Inventive Principle:
Principle #23Feedback

Data Source

PatentUS20240330031A1Secure sidecar container
Publication Date: 2024.10.03 SAP SE
  • US20240330031A1 patent drawing
  • US20240330031A1 patent drawing
  • US20240330031A1 patent drawing

AI summary

A secure side car (SSC) manager reads development artifacts and an application configuration file. Stubs and skeletons are created for inter-process communication between a main application and one or more SSC library containers, the stubs and skeletons based on SSC configurations specified in the application configuration file. Main application code is compiled for the main application. An application container image is created for the main application and a SSC image for each of the one or more SSC library containers. An application container corresponding to the application container image and a SSC library container corresponding to each SSC image or each of the one or more SSC library containers is deployed. A service mesh proxy, which controls network access for libraries within each SSC library container, is configured.