...

Our objective is to demonstrate the 5G SBP Use Case - Remote Attestation Use Case 1- IoT Device Security and Authentication, where SEDIMENT RA Verifier and an example Relying Party application are containerized and deployed with KubeArmor providing visibility and protection policies. Initially the result of attestation is to used to control access to the an example application.  In the future, this may be replaced by a third parry different application, or the attestation may be used to control network access through integration with the 5G ONAP AMF.  The onboarding of the device to be attested is outside the purview of this use case, and a separate use case will address that concern.

...

Remote Attestation Topology

** XXX: integrate both diagrams into a single view **

Image Removed

Note: In Phase 1, we will target only the Gateway security and not work on the device side of things.

Systems Requirements

** XXX: state this for verifier, app server, and device separately **

...

Image Added

SEDIMENT System Requirements

• Ubuntu 20.04 docker containers for verifier, relying party,  app server, and prover (surrogate test device)
• Memory: 8 GB
• CPU: 4 VCPUs

• Arch: x86_64

CPU: 4 vcpus

Memory: 8 GB

...

• Networking:  The following TCP ports needs to be open for the corresponding containers

...

• • Relying Party: 22 (SSH), 8000 and 8101

...

• • • must be able to open connection to 8001

  • Verifier: 22 (SSH), 8100, and 8050 (HTTP GUI)

    • must be able to open connections to 8000

  • Application Server:

...

• • 22 (SSH), 8001, and 8051 (HTTP GUI)

  • Device: 22 (SSH)

    • must be able to open connections to 8000 and 8100

** XXX: use open-source tools such as drawio and include sources if possible **

Image Removed

External Access: ssh access to the node would be required

SEDIMENT System Requirements

• Ubuntu 20.04 docker container for replying party, verifier and app server
• Memory: 8 GB
• CPU: 4 cores

KubeArmor System Requirements

• CPU: 100m (millicore) 100m = 1/10th of a vcpu (ref)
• Memory: 100Mi 150Mi (ref)
• karmor cli connects to kubearmor on port TCP/32767.

Deployment Mode

SEDIMENT Deployment Mode

** XXX: discuss each of the three parties **

...

For initial testing, SEDIMENT project will prepare four Docker containers: 

1. SEDIMENT RA Verifier, to be protected using KubeArmor 
2. SEDIMENT RA Relying Party, to be protected using KubeArmor
3. Example application server (to be updated to accept camera feeds from an attested device)
4. A surrogate for the device to be attested (to be later replaced by an actual camera device with SEDIMENT prover)

KubeArmor Deployment Mode

• Deployed in systemd mode
• Discovery Engine provides visibility into app behaviour and runs as host process.

Security use-cases to target with KubeArmor

1. Visibility into SEDIMENT application behavior
1. Identify the process forking behavior of the application
2. Identify sensitive asset access of SEDIMENT
3. Identify network access required by SEDIMENT
2. Protection policies for Gateway deploying SEDIMENT Verifier.
1. Process Whitelisting: Do not allow processes to execute within SEDIMENT container outside of the given spec.
2. Network Access: Only allow SEDIMENT binaries to use the network primitives
3. Check SEDIMENT configuration files and create a security net around SEDIMENT’s sensitive assets.
4. Use host hardening policies to protect host.

Tasks/Action Items

•  25 Apr 2023 Ganesh Venkatraman , what is the status of current IBM environment/solution in Kaloom?
  
  
•  Document proposed observability capabilities. Define observability capabilites/use case