Download presentation
Presentation is loading. Please wait.
1
Security Working Group
2017 Oct 10 Weekly Meeting
2
2017 Oct 10 Security Working Group Meeting Agenda
Review of Security Updates Provided at Barcelona Inbound Connection Manager Firewall (Priority #1) Key Management API (Priority #2) System Management David Ferriera (ForgeRock) update progress on definition of requirements and search for open source candidates James White (Dell)/Steve Osselton (IOTech) Clean up and donation of Dell Fuse Security Service Riaz Zolfonoon (RSA) update progress definition of REST API Internal container to container security API (Priority #3) Starter-set of APIs to kick start Security API James White/Steve Osselton Next action – James and Steve to propose API post Barcelona release
3
Weekly Meeting
4
California Release – Near Term Security Goal
Protected communication (inbound and outbound) over the public internet on north bound interface OAuth 2.0 methods PKI certificate methods Mutually authenticated TLS Key Management API Inbound Connection Manager (Firewall) Overall plan - Provide well defined API interfaces for security services with basic implementation right out of the box Allow commercial partners to supply enhanced features and services using the same API interface with drop in replacements
5
Security Functionality Requirements Fuse Arch.
6
Security Micro Service High Level Architecture Environment
Hardware OS Specific Platform EdgeX Platform Security Function X Secure Boot RoT
7
Security Micro Service High Level Architecture Function
Security Function X API interface to rest of EdgeX platform API interface to Platform Secure Elements Simple SW Secure Element Implementation Out of Scope -Shim interface per deployment Shim will interface with OS provide secure elements or hardware secure elements of the hardware platform (TPM) Function API EdgeX System API Platform Secure Elements Simple SW Secure Elements Implementation Shim interface (Out of scope) OR OS or HW Secure Elements
8
EdgeX Security High Level Architecture Services
Data Protection Identity and Access Operational Security DAR Encrypted Storage DIT Encrypted Comms Access Management (Least Privilege) Administration Local and Remote Security Monitoring Audit Key Management Data Protection Policy Authentication Identity and Access Policy SW Update Management Attestation Identity Management Chain of Trust Operational Security Policy Guidelines Inbound Connection Manager Firewall Secure Auto-configuration Privacy
9
Review Barcelona Security Discussion
10
Security Working Group David Ferriera, Forgerock
API Proxy Security Working Group David Ferriera, Forgerock
11
EdgeX Foundry Inbound Point of Security
Secure Proxy Authentication Security Service
12
API Security Pattern Features Open Source Options Boundary Protection
Namespace/Port aggregation Deployment flexibility Local or centralized authentication options URL only versioning – allows for running multiple versions at once Open Source Options Tinyproxy lighttpd Apache – mod_proxy Nginx
13
Authentication/Authorization
EdgeX Foundry Security Pattern Secure Proxy Auth Module Authentication/Authorization Service Metadata Command Steps Receive all API requests at the proxy Translate request and determine destination (REGEX fun) Perform authentication (if required) Perform authorization (if required) If the above is successful, pass to destination
14
Discussion topics Riaz Zolfonoon (RSA)
Key Manager API Discussion topics Riaz Zolfonoon (RSA)
15
Proposed Approach Closely follow KMIP* REST API
Key management microservice Simple REST api for common services (subset of KMIP interface) Optionally, KMIP interface will be available for advanced apps (as value-add) REST API Keep it simple Core key management API Basic key generation and retrieval Encryption/Signing API Encrypt, Decrypt, MAC, Sign, Verify * OASIS Key Management Interoperability Protoco
16
Key Management API Core API Keys Create Symmetric Key
Create Asymmetric Key Get Key Delete/Shred Key Secrets Register Secret Get Secret Certificates Register Certificate Get Certificate Secure Channel TLS with mutual auth is required for all access to Key Mgmt Svc
17
Open Questions Keys CA Encrypt/Signing Services
Key Store and Retrieval is needed by other EdgeX microservices Create and update key attributes Register keys (import keys created outside of service) Should we allow all keys or only certain keys to be passed out to other microservices? How and what are the usage cases? CA Internal CA (simple out of the box implementation) [ Step 1] External CA (provide the ability to connect to Ext CA via same API) [Step 2] Certificate status queries via OCSP Encrypt/Signing Services As part of key mgmt svc or a separate service Encrypt/Decrypt MAC Sign/Verify
18
EdgeX System Management
Salim AbiEzzi
19
Summary Provision, monitor & manage an edge system with connected devices to insure its proper function. Scale, security and reliability are key. Facilitate ecosystem formation by defining common cross vendor building blocks.
20
Scope Provisioning Infrastructure telemetry
Bootstrap On board devices Inventory Infrastructure telemetry Infrastructure notification/alerts Configuration and software updates
21
Topics Edge system secure auto-configuration Managed Objects
Mgmt Agent to Managed Object API Mgmt Agent to Mgmt Service API
22
Secure Auto Configuration OOB
Edge devices have no UI console Provisioning at large numbers while requiring manual steps is expensive Opportunity for EdgeX to define steps for secure auto-config out of the box Possibility to simplify external config server by using internal DNS This could be first option to try before reverting to external server Concern about privacy if it is known which customer is deploying which gateways Possibility to accomplish this with a shared secret if breached, this compromises all devices
23
Secure Auto Configuration OOB
config server 1- GW manufacturing 2 - customer purchases N GWs GW ID1 GW PubK1 GW PrivK1 Config server sURL sPubK ID1 – customer cURL & cPubK … ID1 - PubK1 … sURL GW ownership list sPubK 5 - obtain customer cURL & cPubK 6 – connect w/ customer server; e.g., IoTC Defining multiple approaches EDM: automated device registration via DNS SRV Record & DHCP Option Tags Shared secret Privacy concern 3 - deployment ID1 - PubK1 ID1 PubK1 PrivK1 Config server sURL sPubK cPubK cURL 4 - obtain IP address 7 - SFTP bootstrap package PubK TLS connection
24
Edge Function Microservices Mgmt Agent DB Mgmt Service Connected Devices Edge System Managed Object
25
Managed Object Name: UUID
Type: [connected device, microservice, edge system] Properties as key-value pairs: [k1=v1, k2=v2, …] e.g.: make, model, serial number, time in service Metrics: [(name, units, interval, precision, accuracy, functionID), …] Actions: [(name, functionID, [name: parameter type, …]), …] Alerts: MO-UUID, metric name, value that caused alert
26
Mgmt Agent to Managed Object API
Register managed object Put metric value Perform action Define alert Trigger alert Set property Append property Get property Get all properties
27
Mgmt Agent to Mgmt Service API
Perform action Update managed object Put file Execute Remote terminal Get property Get all properties
28
Inventory Connected devices
Interrogate device metadata database for connected devices Notification of a device connection or removal Aggregation device (e.g., RPi aggregating data from sensors) Edge system K-Vs: e.g., OS version, system software, hardware ID. Metrics: e.g., CPU, IOPS, memory, storage Microservices List: name, version
29
Examples Heart beat as metric Ping as action
Notification of battery charge, connection state Notification of edge system compute resource concerns
30
Examples of Configuration through Actions
Firewall settings NAT traversal Change SSH port Wifi passcode Certificate revocation Installing new certificate
31
Software Updates Three types: #1 is in scope Is #2 in scope?
Microservices Connected devices Edge device OS #1 is in scope Is #2 in scope? #3 is out of scope; however: Could be orchestrated Need to shut down microservices, apply update and resume Update might require root privilege and/or a reboot
32
Power Management Restart or shutdown Remote restart or shutdown
Might be required by system software updates Remote restart or shutdown E.g., Wake on LAN Energy saving
33
EdgeX for Fog Computing
Using EdgeX microservices on multi computing tiers between [edge and cloud[ East-west communication Failover Load balancing Kubernetes for orchestration
34
Application Lifecycle Management
35
Role Based Access Control
36
End Review of Barcelona
37
Platform Secure Elements
Inbound Connection Manager Firewall (Priority #1) EdgeX Security High Level Function David Ferriera - Technical Lead Actions to define requirements and search for open source candidates James White (Dell)/Dell Team Clean up and donation of Dell Fuse Security Service Work to begin post Barcelona Inbound Connection Manager Firewall Functions API EdgeX System API Platform Secure Elements
38
Priority #1 Inbound Connection Manager Firewall
Priority #1 Inbound Connection Manager Firewall Implement the Fuse Security Service The EdgeX Security WG identified a high priority the Face to Face Inbound Connection Manager (Firewall) Protected communications of north bound interface Dell began a security microservice that implemented functionality similar to the Inbound Connection Manager A firewall/proxy type service that protects the north side interface The implementation was prototyped but not completed and placed into Fuse due to infrastructure needs to be determined (keystore, firewall, etc.) Proposal #1 Post Barcelona, prioritize the work of one of our implementation teams to complete this implementation for California Puts a strawman in place for the security working groups #1 priority Will also require picking/using some open source infrastructure to further complete the implementation This will assist in other security implementation efforts (or show weaknesses that need to be corrected) Firewall, keystore, etc. Details on the next slide
39
Dell Fuse Security Service
North Side Client Dell Fuse Security Service Firewall Firewall/OS configuration prevents direct access to any microservice All requests for EdgeX go through single external security service address/port Clients authenticate with Security Service URI path parameters indicate internal service request Security Service uses Registry Service & MongoDB (or alternate) to look up mappings from external URI to internal URI. Security service authenticates/authorizes request before passing to target service Responses are also relayed back through security service (service acts as a proxy) Requires some infrastructure choices Used some Dell technology in Fuse implementation Use of open source infrastructure would be used for EdgeX Identity Broker Security Service Security DB
40
Key Management (Priority #2) EdgeX Security High Level Function
Riaz Zolfonnon - Technical Lead Actions to define requirements for REST API and search for open source candidates Key Management Containerize Key Vault Later someone would need to connect this to other OS services and hardware RoT Need to design a REST EdgeX API to these services PKCS #11 services? Functions API EdgeX System API Platform Secure Elements
41
Platform Secure Elements
Internal Microservice Security Protocol (Priority #3) EdgeX Security High Level Function James White (Dell)/Steve Osselton (IOTech) Next action – James and Steve to propose API post Barcelona release Internal Microservice Security Protocol ?? Functions API EdgeX System API Platform Secure Elements
42
Priority #3 Implement an internal microservice communication security protocol
Several security APIs around service communications already exist OMG’s DDS Security API ( OWASP REST Security API ( JWT ( Proposal #2 Allow two EdgeX/industry architects to provide a survey of the options and recommendation for implementation to the security WG Again use the security implementation team to implement the APIs throughout EdgeX services for California While not as high a priority, allow EdgeX security to be improved via some standard API set (not requiring wheel re-invention) Allows Security Working Group to react/consider a design/architecture versus starting from scratch and work from requirements all the way to implementation Help to identify additional infrastructure needs abstract the implementation to allow other future implementations provide more secure services as a reference implementation
43
Access Management EdgeX Security High Level Function
OAuth2.0 Roles Resource Owner Client Resource Server Authorization Server Functions API EdgeX System API Platform Secure Elements
44
Authentication methods EdgeX Security High Level Function
X.509 PKI Smart device Username and password Dumb device – Service Plugin OAuth2.0 (Authorization Protocol not authentication method) SSH - Key and Account/User Customer required external Authentication Method PKI Elliptic Curve Methods ECDSA 128, 256 Usage Cases North bound (1st Priority) X.509 PKI South bound East/West Built in simple service for out of the box authentication Need authentication method for secure connection to EdgeX microservices. Microservices within a single container may not need to authenticate. OAuth2.0 is recommended since it support internal and external Access to HW Platform Key Store Functions API EdgeX System API Platform Secure Elements
45
Identity Management EdgeX Security High Level Function
Enroll/deactivate PKI Certificates –Smart device Dumb device - Service Agent Public PKI ID authorized to update White list CRL (certificate revocation list) Identity Usage Cases Operator/User Client Cloud Service Device/End point Internal EdgeX Identities Functions API EdgeX System API Platform Secure Elements
46
Identity and Access Policy EdgeX Security High Level Function
Identities Operator/User Client Cloud Service Device/End point Internal EdgeX Identities Usage Cases Northbound (1st priority) Southbound East/West (EdgeX node-to-node distributed) Administrative Access for each identity Read and/or Write Controls for devices Parameter level Admin control API for remote admin Publish Controls Conditional access policy (internal network, external network) Encryption requirements for communications to all identities and publishing paths Functions API EdgeX System API Platform Secure Elements
47
Platform Secure Elements
Data In Transit (DIT) Encrypted Comms EdgeX Security High Level Function DIT Encrypted Comms Connection mode encryption TLS (being implemented as part of Barcelona along with MQTTS) Missing from current work effort in client export? This is an issue. Should be included in Sprint framework but needs to be turned on. DTLS (future) Payload encryption Symmetric (AES-128, 256) Needed when end-to-end confidentiality is required Usage Cases Northbound (1st priority) Southbound East/West (EdgeX node-to-node distributed) Administrative Secure Auto-configruation Internal connections encryption is optional External connections encryption is required Confidentiality Integrity Possible to East-West Protected Connection via OAuth 2.0 (Distributed EdgeX) Functions API EdgeX System API Platform Secure Elements
48
DAR Encrypted Storage EdgeX Security High Level Function
Confidentiality Integrity Usage Cases Northbound (1st priority) Southbound East/West (EdgeX node-to-node distributed) Functions API EdgeX System API Platform Secure Elements
49
Data At Rest (DAR) Policy EdgeX Security High Level Function
What to encrypt Encryption method Identity Usage Cases Operator/User Client Cloud Service Device/End point Internal EdgeX Identities Functions API EdgeX System API Platform Secure Elements
50
Operational Security Policy EdgeX Security High Level Function
Inbound Connection Manager Firewall Policy DIT Policy SW Update Management Policy Audit Policy Attestation Policy (gateway, southbound devices) Secure Auto-config Policy Functions API EdgeX System API Platform Secure Elements
51
Software Update Management EdgeX Security High Level Function
In Scope EdgeX Microservices (internally or externally (OS)) EdgeX can play an orchestration role for Platform under EdgeX (OS) when allowed. Future South bound connected devices Method Validation of update signature PKI Certificates –Smart device Dumb device - Service Agent Functions API EdgeX System API Platform Secure Elements
52
Security Monitoring EdgeX Security High Level Function
Alerts Anomaly detection Intrusion detection Functions API EdgeX System API Platform Secure Elements
53
Audit EdgeX Security High Level Function
Log security events Signing and anti-tamper protections Functions API EdgeX System API Platform Secure Elements
54
Attestation EdgeX Security High Level Function
Attestation gateway Measurement for chain of trust Measurement of boot images Measurement of control and configuration Future Attestation southbound device Functions API EdgeX System API Platform Secure Elements
55
Chain of Trust EdgeX Security High Level Function
What so measure How to measure Attestation measurement signing Functions API EdgeX System API Platform Secure Elements
56
Privacy EdgeX Security High Level Function
Needs to be taken into consideration Consumer Health Care (HIPA) EU Requirements Functions API EdgeX System API Platform Secure Elements
57
Hardware Platform Required Security Functionality EdgeX Security High Level Architecture
HW TEE Secure Update Key Store Digital Signature Algorithm TRNG Attestation/Trusted Boot Secure Boot
58
Platform Secure Elements
HW TEE (Trusted Execution Environment) EdgeX Security High Level Function HW TEE (Trusted Execution Environment) Required in platform to protect and isolate security sensitive values Functions API EdgeX System API Platform Secure Elements
59
Key Store EdgeX Security High Level Function
Required in platform to protect stored keys Functions API EdgeX System API Platform Secure Elements
60
RNG (Random Number Generator) EdgeX Security High Level Function
TRNG (True Random Number Generator) DRNG (Deterministic RNG) Functions API EdgeX System API Platform Secure Elements
61
Secure Boot EdgeX Security High Level Function
Signature validation at each boot level Integrity checks at each boot level Connection into chain of trust in EdgeX System will only boot of integrity checks pass Functions API EdgeX System API Platform Secure Elements
62
Digital Signature Algorithm EdgeX Security High Level Function
ECDSA Functions API EdgeX System API Platform Secure Elements
63
Attestation/Trusted Boot EdgeX Security High Level Function
Measurement of each boot level Connection into attestation in EdgeX Trusted Boot Measurement and reporting of attestation vector. System always boots. Functions API EdgeX System API Platform Secure Elements
64
EdgeX Security High Level Architecture Open Questions
Out of Scope - Provide guidance on how security features can/should be tested
65
Proposed Northbound Security Objectives
Client, Distribution and Services Access Parameter level read/write Streaming data permissions ( publish/subscribe) Administration & Permissions Management Remote Administration Access Permission management interface Differentiation of local vs remote access Clients & services operating “behind the firewall” Applications and services located on public Internet Flexibility Enable companies to enforce internal security policies Flexible key management methods Certificate Authority, PKI, Blockchain Flexible support of security and access technologies PKI, SSL, OAuth
66
EdgeX Northbound Connection Example Use Case
EdgeX Gateway Connection is initiated from EdgeX to Cloud Set up a mutually authenticated TLS connection using x.509 methods Certificate Handling Provisioning, renewal, Use OS certificate store and services Required to use export service to obtain a connection Policy service Who can talk to who, read, write, connection type Initial settings of EdgeX to configure Cloud connection
67
Proposed Northbound Access Permissions Topology
68
Past Security Agreements
“Fuse microservices to enforce access control, authentication, and authorization (AAA).” – Also needs to support smart end points to cloud (AAA) Needs to support tunneled and encrypted sensor data to the cloud – Gateway in pass through mode only. Specifies Gateway administrator provisions devices. Should also allow for smart devices to connect to cloud in pass through mode. “Rely on installation-unique credentials for protecting access to any of the Fuse repositories.” – Add support for Smart end points support (certificate, authentication, integrity, optional encryption) “Documentation provided with Fuse should strongly recommend that implementers expose HTTPS only.” – Needs to require TLS 2.0 or higher, down grade to unsecure modes should be flagged as insecure by EdgeX. “For those subscribers of MQTT data, there is no ability to protect sensitive data in transit” – This statement is in error. Typical protection is provided by a TLS layer that MQTT is tunneled through. Mangement Use Cases “EdgeX Administrator updates software” – This is only the EdgeX software upgrade and not end devices. Needs to support upgrade of devices from cloud to device in pass through mode to support various vendor methods. Control Use Cases “EdgeX published all data” – Need to change to allow for smart devices to publishing data directly to cloud.
Similar presentations
© 2025 SlidePlayer.com. Inc.
All rights reserved.