OpenHorizon provides the ability to flexibly deploy edge workloads by providing its own orchestrating elements. As an edge service provider who uses OpenHorizon this provides immense flexibility in deploying and managing edge operations.
However, this flexibility comes at a tradeoff wherein the workloads deployed on edge might not necessarily be created by security savvy developers and might have vulnerability. The impact of such a vulnerability exploit can be immense since it can bring the edge to a halt, but more importantly, the attacker has the possibility of leveraging a security gap in one workload to target another workload on the same edge node since they are colocated. The edge workloads may contain sensitive data related to user and hence needs to be protected.
Furthermore, it is important for the edge administrators or service providers to have monitoring options for edge workloads. This could be needed further for compliance and regulatory purposes.
As an example, IEC 62443 standard defines following principles to be followed in the OT sector:
- Principle of least privilege: Provide edge node components and external interfaces only the required access and deny everything else.
- Defense in Depth: Multi layered defense techniques to delay or prevent a cyber attack in the industrial network
- Risk Analysis: Practice used to address risks related to production infrastructure, production capacity etc
OpenHorizon-AnyLog Integration.drawio original draw.io file for any modifications if needed.
Deployment Design
TODO
User Experience
Deployment UX
- Should we consider k8s mode of deployment or pure-containerized mode of deployment? KubeArmor works best with k8s mode of deployment and is the recommended mode. Having said that, the previous integration/demo/POC done with OH was in pure-containerized mode.
- How would the deployment of KubeArmor on the target edge node happen? Will it be deployed as a separate workload with its own control plane or will it be integrated into the same control plane as that of OH?
- There is a value in keeping KubeArmor and associated tooling decoupled from Anax and OH Management Hub. This would allow independent updates and essentially the security should be considered as one more addon from the service provider side of things.
- The real challenge here is how would OH framework allow extensions to be built to integrate third party tooling?
- Ship the hardening policies along with the KubeArmor installation.
Day2 Operations UX
- How would the policy add/delete/list/modify work?
- How would the recommended policies be shown to the user?
- How would the SIEM tools integrations be done and at what point?
- How would upgrade of KubeArmor be handled?
Use-cases to consider
<TODO: Every security use-case could have a corresponding set of tags that could indicate the fulfilled compliance control, or attack framework (for e.g., MITRE) control fulfilled.>
Observability & Monitoring use-cases
Security Event Monitoring:
- File Integrity Monitoring: Any changes to the systems folders should be monitored/audited.
- Reverse Shell execution
- Use of security sensitive primitives: setuid(), setguid(),chmod(),chown(),
- Updates to root certificates folder
- Use of
kubectl execto gain shell access in the pod - Privilege escalation attempted
- Monitor for external networks access
- Suspicious IP detection (for e.g. using Feodo Blocked IP List)
- Monitor for use of DGA (Domain Generation Algorithms) in the workload
Application Performance Monitoring:
- Excessive CPU usage: >90% of CPU used consistently for > 2 mins
- Excessive Memory usage: >80% of allocated memory used
- ...
Goals
- Install and run Open Horizon all-in-one, publish and deploy HomeAssistant and KubeArmor with test security policy
- Demonstrate how to monitor the listed events and access the results
Deliverables
- Documentation allowing anyone to replicate the results of the goals listed above
- Demo video showing the results
Components
- Open Horizon - to deliver and manage running workloads
- KubeArmor - to monitor and enforce security policy on host and workloads
- HomeAssistant - example service
Protection: Hardening use-cases
Node Hardening:
- Protect systems folders: Do not allow updates to kernel modules on the host.
- Prevent root certificates updates
Workload/Pod/Container Hardening:
- Protecting workload Secrets. Secrets could be injected in the workloads using volume mounts, environment vars, etc. Provide clear guidelines and specific tooling to secure such secrets.
- Protecting sensitive assets mounted using volume mount points
Protection: Enforcing principle of least privilege
- Network Segmentation and enforcing least privilege network access
- Enforce Process Whitelisting
- Enforce least permissive access to sensitive assets. All volume mount points can be considered sensitive assets.
- Enforce least permissive process based network control. Only allow certain set of processes to do network communication.
Protection: Enforcing Network Protection
- Enforce Ingress/Egress controls using CIDRSets, Domain names, Protocols/Ports
- Auto Discover Network Protection rules.
Workload Forensics
- Workload Process Monitoring
- Workload Sensitive Asset access
- External Network exposure for workloads
- Ability to query forensics details for a specified time duration from past X days.
Other Topics:
- Leveraging Confidential Computing for hardware based protections
charisse lu Security guidelines for workload creators - discussion
- How to extend Anax cli and integrate with karmor cli? Can we expect the user to have two clis? Does Anax cli offer pluggable interfaces?
- The policy add/delete/update/list should be handled through this cli.