1. Security Working Group
2017 Oct 25
Weekly Meeting

2. 2017 Oct 25 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. Security Working Group Priorities
Priority #1 - Inbound Connection Manager Firewall
Priority #2 - Key Management
Priority #3 - Internal Microservice Security Protocol

10. Security for Individual Micro Services
Security Working Group
Technical Lead: Rodney Hess

11. Security Needs Communicating with other micro services
Communicating with the “outside”
Acquiring one’s configuration

12. Security for Individual Micro Services
Language specific
Built-in to a off-the-shelf OS release
Built-in to a security-enhanced OS release
3rd-party security components to a off-the-shelf OS release

13. Rough Architecture Java specific EdgeXSecurityManager API
Wrapper around KeyFactory and TrustFactory
A.k.a. key store and trust store

14. Discussion Notes
The Security WG delivers should be expanded to include a EdgeX Micro Service Security Manager (MSSM) element that should be common and built into every EdgeX micro service.
The MSSM should maintain a private key (Join Key) internally to authenticate and join the EdgeX platform.
The MSSM should use the join key to initially establish the connection to the Security Service.
The Security Service should assign a ephemeral key or Oauth token after authentication. The join key shall only be used for initial establishment of connection from the micro service to the Security Service.
The Security Service should have the policy and controls about what other micro services can connect, encryption requirements, etc. The Security Service will be the gate keeper for all inter-micro service connections.

15. Next Steps
Review Discussion Notes and Conclusions.

16. 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

17. 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

18. 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

19. Next Steps ??

20. Inbound Connection Manager
Security Working Group
Technical Lead: David Ferriera, Forgerock

21. EdgeX Foundry Inbound Point of Security
Secure Proxy
Authentication Security Service

22. 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

23. 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

24. Next Steps ??

25. 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

26. Discussion topics Technical Lead: Riaz Zolfonoon (RSA)
Key Manager API
Discussion topics
Technical Lead: Riaz Zolfonoon (RSA)

27. 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

28. 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

29. 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

30. Next Steps ??

31. 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

32. 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

33. Next Steps ??

34. Other Priority Items Volunteer Please!!

35. 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

36. 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

37. 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

38. 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

39. 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

40. 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

41. 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

42. 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

43. 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

44. Security Monitoring EdgeX Security High Level Function
Alerts
Anomaly detection
Intrusion detection
Functions
API EdgeX System
API
Platform Secure Elements

45. Audit EdgeX Security High Level Function
Log security events
Signing and anti-tamper protections
Functions
API EdgeX System
API
Platform Secure Elements

46. 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

47. 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

48. 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

49. Hardware Platform Required Security Functionality EdgeX Security High Level ArchitectureHW
TEE
Secure Update
Key Store
Digital Signature Algorithm
TRNG
Attestation/Trusted Boot
Secure Boot

50. 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

51. Key Store EdgeX Security High Level Function
Required in platform to protect stored keys
Functions
API EdgeX System
API
Platform Secure Elements

52. 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

53. 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

54. Digital Signature Algorithm EdgeX Security High Level Function
ECDSA
Functions
API EdgeX System
API
Platform Secure Elements

55. 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

56. EdgeX Security High Level Architecture Open Questions
Out of Scope - Provide guidance on how security features can/should be tested

57. 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

58. 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

59. Proposed Northbound Access Permissions Topology

60. 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.