Security Working Group 2017 Nov 29 Weekly Meeting

Security Working Group 2017 Nov 29 Weekly Meeting edgexfoundry. org | @edgexfoundry

2017 Nov 29 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 • Inbound Connection Manager Firewall (Priority #1) • David Ferriera (Forge. Rock) update progress on definition of requirements and search for open source candidates • Key Management API (Priority #2) • 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 edgexfoundry. org | @edgexfoundry

Weekly Meeting edgexfoundry. org | @edgexfoundry

Security Functionality Requirements Fuse Arch. edgexfoundry. org | @edgexfoundry

Security Micro Service High Level Architecture Environment Hardware OS Specific Platform Edge. X Platform Security Function X Secure Boot edgexfoundry. org | @edgexfoundry Ro. T

Security Micro Service High Level Architecture Function Security Function X • • API interface to rest of Edge. X 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) API Platform Secure Elements Simple SW Secure Elements Implementation edgexfoundry. org | @edgexfoundry API Edge. X System Function OR Shim interface (Out of scope) OS or HW Secure Elements

Edge. X Security High Level Architecture Services Data Protection DAR Encrypted Storage DIT Encrypted Comms Key Management Data Protection Policy Identity and Access Management (Least Privilege) Administration Local and Remote Security Monitoring Audit Authentication Identity and Access Policy SW Update Management Attestation Chain of Trust Operational Security Policy Identity Management Guidelines Privacy edgexfoundry. org | @edgexfoundry Operational Security Inbound Connection Manager Firewall Secure Autoconfiguration

Security Working Group Priorities • Priority #1 - Inbound Connection Manager Firewall • Priority #2 - Key Management • Priority #3 - Internal Micro service Security Protocol edgexfoundry. org | @edgexfoundry

Pick Next 3 High Priorities • Access Management • Authentication • Identity Management edgexfoundry. org | @edgexfoundry

Inbound Connection Manager Firewall (Priority #1) Edge. X Security High Level Function David Ferriera - Technical Lead • Actions to define requirements and search for open source candidates • Inbound Connection Manager Firewall API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Priority #1 Inbound Connection Manager Firewall Implement the Fuse Security Service • The Edge. X Security WG identified a high priority need @ 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 edgexfoundry. org | @edgexfoundry

North Side Client Dell Fuse Security Service Firewall • Firewall/OS configuration prevents direct access to any microservice • All requests for Edge. X 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 & Mongo. DB (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 Edge. X edgexfoundry. org | @edgexfoundry Security Service Identity Broker Security DB

Inbound Connection Manager Security Working Group Technical Lead: David Ferriera, Forgerock edgexfoundry. org | @edgexfoundry

Edge. X Foundry Inbound Point of Security Authentication Security Service Secure Proxy edgexfoundry. org | @edgexfoundry

API Security Pattern Features • • • 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 edgexfoundry. org | @edgexfoundry

Edge. X Foundry Security Pattern Secure Proxy Metadata http: //localhost: 48081/api/v 1//device/id/{id} Steps • • • https: //your. hostname/api/v 1/device/{id}/command/{commandid} Auth Module http: //localhost: 48082/api/v 1/device/{id}/command/{commandid} 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 edgexfoundry. org | @edgexfoundry Authentication/Authorization Service Command https: //your. hostname/api/v 1/device/id/{id}

Inbound Connection Manager Firewall Next Steps • David is building a matrix of features and functionality for the proposed 4 proxies. • Target matrix date is last week of Nov. edgexfoundry. org | @edgexfoundry

Key Management (Priority #2) Edge. X 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 Ro. T Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • Need to design a REST Edge. X API to these services • PKCS #11 services?

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

Objectives • Simple REST API for basic Data Protection (DP) services • • • Key Management Certificate Services Encryption • Provide an implementation of the DP API • The 3 rd parties should be allowed to replace all or portions of the implementation with a more sophisticated implementation (value-add) edgexfoundry. org | @edgexfoundry

Requirements • Key Management • Create, Read, Update (attributes), Delete • Store (external keys) and support policy-based key export • Support for symmetric and asymmetric keys • CA • Simple Out-of-the-box self-signed CA • Support external CAs • Certificate status queries (OCSP) • Encryption • Encrypt/Decrypt • Sign/Verify edgexfoundry. org | @edgexfoundry • MAC

Requirements • API • As a minimum, DP service should provide a REST API. • Other API styles for DP services are beyond the scope of this project • All API interactions must happen over a secure HTTP connection. • Client and server must be mutually authenticated. • Client • The client credential must be stored securely. • Server • The server should be implemented as a microservice, consistent with Edgex overall architecture and design. edgexfoundry. org | @edgexfoundry

Milestones • Proposal to WG by Nov 30 th • Review completed by Dec 31 st • Proposal to TSC on January 16, 2018 (@f 2 f) edgexfoundry. org | @edgexfoundry

Open Source Packages Considered • Confidant • Docker Secrets • Hashicorp Vault • Key. Whiz • Kubernetes Secrets edgexfoundry. org | @edgexfoundry

Evaluation Results • Add eval results and proposed selection… edgexfoundry. org | @edgexfoundry

Confidant

• Dependency on AWS KMS edgexfoundry. org | @edgexfoundry

Docker Secrets

• Requires Docker Swarm • At this time, Edgex has not decided on a clustering solution. • Therefore it is premature to select this option. edgexfoundry. org | @edgexfoundry

Hashicorp Vault

Hashicorp Vault Features Need to validate the impl • Simple REST API • • Logical CRUD API calls can be interpreted by implementation as necessary API calls execute over mutually authenticated secure channel. • Secure Secret Storage • • Stores database credentials, API keys, Access Tokens Extensible for other types of secrets • Dynamic Secrets • • Generating AWS access keys for a period of time and then discard Extensible for other forms of dynamic credentials • Data Protection • Offload data encryption/signing responsibilities from developers and instead perform centrally • Access Control • On first access by a machine or human user, the client is authenticated using internal or external auth backend. A token is created which contains user access rights according to applicable policy. The token is used on subsequent calls and access control is performed accordingly. • Policies • Every action in Vault has a corresponding path. Policies provide a declarative way to grant or forbid access to certain paths and operations in Vault. Policies are deny by default. • Revocation • Leasing and Renewal • High availability • Multi-server deployment mode (primary: secondary (1: N))

Hashicorp Vault Architecture • Client/Server Model with REST API • Untrusted durable storage backend • Stored data encrypted/decrypted by server • Encryption Key is protected by Master Key • Master Key is split (Shamir’s secret sharing – def=3/5) • Secret Backend: manages secrets • Auth Backend: authenticates clients • Client token issued on first auth • Extensible to support different auth methods • All operations audited • Each line in the audit log is a JSON object. • Logs to file/syslog/socket. Data values are hashed. • Key Rotation • Rekey: new master key (splitting params may change) • Rotation: change the encryption key used to protect data written to the storage backend. • Replication • 1: N - Primary (read/write) and Secondary (read/forward-write) Need to validate the impl

Hashicorp Vault Threat Model Need to validate the impl Following threats are protected against: • Eavesdropping on any Vault communication. • Client communication with Vault is secured from eavesdropping as well as communication from Vault to its storage backend. Communication with external systems (e. g. external auth via LDAP) also must occur over secure channel. • Tampering with data at rest or in transit. • Data transfer is over secure channel. Data at rest is encrypted. • Access to data or controls without authentication or authorization. • All access is checked for auth. N and auth. Z according to policy. • Access to data or controls without accountability. • If audit logging is enabled, all requests and responses are logged before the client receives any secret material. The data in the request and the data in the response (including secrets and authentication tokens) will be hashed with a salt using HMAC-SHA 256. • Confidentiality of stored secrets. • All data at rest (in storage backend) is encrypted. • Availability of secret material in the face of failure. • Vault supports running in a highly available configuration to avoid loss of availability.

Hashicorp Vault Threat Model Following threats are NOT protected against: • Protecting against arbitrary control of the storage backend. • An attacker that can perform arbitrary operations against the storage backend can undermine security in any number of ways that are difficult or impossible to protect against. • As an example, an attacker could delete or corrupt all the contents of the storage backend causing total data loss for Vault. • The ability to control reads would allow an attacker to snapshot in a well-known state and rollback state changes if that would be beneficial to them. • Protecting against the leakage of the existence of secret material. • An attacker than gains direct access to the storage backend can determine the existence of secret material, even though the data is encrypted. • Protecting against memory analysis of a running Vault.

Hashicorp Vault API - Overview • Simple REST Interface • • • Read/Write/Delete All API routes are prefixed with /v 1/ current version TLS transport is assumed, however it can be turned off via config All operations require client token. Token is sent as the X-Vault-Token HTTP header Token is retrieved by authenticating to login endpoint on auth backend • Sample Read • /v 1/secret/foo: Read value for key foo at secret/ mount path: curl -H "X-Vault-Token: f 3 b 09679 -3001 -009 d-2 b 80 -9 c 306 ab 81 aa 6" -X GET http: //127. 0. 0. 1: 8200/v 1/secret/? list=true • Sample Write • /v 1/secret/foo: Write value bar for secret foo (current POST and PUT are synonyms) curl -H "X-Vault-Token: f 3 b 09679 -3001 -009 d-2 b 80 -9 c 306 ab 81 aa 6" -H "Content-Type: application/json" -X POST -d '{"value": "bar"}' http: //127. 0. 0. 1: 8200/v 1/secret/foo

Hashicorp Vault API - Authenication • Auth Backends • • • Every API operation requires a client token Client token is retrieved from aut. H backends Each aut. H backend will have one or more unauthenticated login endpoints These endpoints are specific to each auth backend. Login endpoints for auth backends that generate an identity will be sent down via JSON By default, auth backends are mounted to auth/<type> (e. g. auth/userpass, auth/ldap) • Available auth backends: • Google Cloud, Kubernetes, Git. Hub, LDAP, • MFA, Okta, RADIUS, TLS Certificates, • Tokens, Username & Password • Sample Auth Request curl http: //127. 0. 0. 1: 8200/v 1/auth/userpass/login/mitchellh -d '{ "password": "foo" }' { "lease_id": "", "renewable": false, "lease_duration": 0, "data": null, "auth": { "client_token": "c 4 f 280 f 6 fdb 2 -18 eb-89 d 3 -589 e 2 e 834 cdb", "policies": [ "admins" ], "metadata": { "username": "mitchellh" }, "lease_duration": 0, "renewable": false } }

Hashicorp Vault ? ? add brief intro to other essential features…. • PKI • Concepts: https: //www. vaultproject. io/docs/secrets/pki/index. html • API: https: //www. vaultproject. io/api/secret/pki/index. html • Transit • Concepts : https: //www. vaultproject. io/docs/secrets/transit/index. html • API : https: //www. vaultproject. io/api/secret/transit/index. html

Hashicorp Vault Pros & Cons Pros Comments Platform agnostic Supports multiple OSs with no dependency on specific technologies such as containers, orchestration tools, etc. Dynamic credentials Ability to create/acquire credentials dynamically (as for aws, Consul, …) is a desirable feature for Edgex. Extensible backends Enables 3’rd party value-add enhancements for cases such as custom authentication, TPM support, etc. Comprehensive documentation Support for lease and renewal Cons Unprotected Client credentials Comments Out of the box, Vault does not offer support for client protecting its creds.

Keywhiz

• TBD edgexfoundry. org | @edgexfoundry

Kubernetes Secrets

• Requires Kubernetes • At this time, Edgex has not decided on an orchestration tool. • Initial evaluation indicates that secrets are tightly integrated with the rest of the K 8 s. Separating the secrets impl from rest of the system seems challenging. • Therefore it is premature at this time to select this option. edgexfoundry. org | @edgexfoundry

Proposed Approach • Closely follow KMIP* • 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

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

Open Questions • Keys • • Key Store and Retrieval is needed by other Edge. X 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

Key Management API Next Steps • Riaz is building a matrix of features and functionality for Key Management options. • Target matrix date is last week of Nov. edgexfoundry. org | @edgexfoundry

Internal Microservice Security Protocol (Priority #3) Edge. X Security High Level Function James White (Dell)/Steve Osselton (IOTech) • Next action – James and Steve to propose API post Barcelona release • Target to have this complete prior to January Face-to-Face • Internal Micro service Security Protocol • ? ? API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Priority #3 Implement an internal microservice communication security protocol • Several security APIs around service communications already exist • OMG’s DDS Security API (http: //www. omg. org/spec/DDS-SECURITY/1. 0/) • OWASP REST Security API (https: //www. owasp. org/index. php/REST_Security_Cheat_Sheet) • JWT (https: //jwt. io/introduction/) • Proposal #2 • Allow two Edge. X/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 Edge. X services for California • While not as high a priority, allow Edge. X 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 edgexfoundry. org | @edgexfoundry

Internal Microservice Security Protocol Next Steps • Jim White and Steve Osselton are building a matrix of tools, features and functionality. • Target matrix date is last week of Nov. edgexfoundry. org | @edgexfoundry

Security for Individual Micro Services Security Working Group Technical Lead: Rodney Hess edgexfoundry. org | @edgexfoundry

Security Needs • Communicating with other micro services • Communicating with the “outside” • Acquiring one’s configuration edgexfoundry. org | @edgexfoundry

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

Rough Architecture • • Java specific Edge. XSecurity. Manager API Wrapper around Key. Factory and Trust. Factory • A. k. a. key store and trust store edgexfoundry. org | @edgexfoundry

Discussion Notes • The Security WG delivers should be expanded to include a Edge. X Micro Service Security Manager (MSSM) element that should be common and built into every Edge. X micro service. • The MSSM should maintain a private key (Join Key) internally to authenticate and join the Edge. X 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. edgexfoundry. org | @edgexfoundry

Security for Individual Micro Services Next Steps • Review Discussion Notes and Conclusions. edgexfoundry. org | @edgexfoundry

Other Priority Items Volunteer Please!! edgexfoundry. org | @edgexfoundry

Access Management Edge. X Security High Level Function • Access Management • OAuth 2. 0 Roles Resource Owner Client Resource Server Authorization Server Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • •

Authentication methods Edge. X Security High Level Function • Authentication methods • • X. 509 PKI Smart device Username and password Dumb device – Service Plugin OAuth 2. 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 (1 st Priority) • • Username and password X. 509 PKI South bound East/West Functions • Built in simple service for out of the box authentication • Need authentication method for secure connection to Edge. X microservices. • • Microservices within a single container may not need to authenticate. OAuth 2. 0 is recommended since it support internal and external • Access to HW Platform Key Store edgexfoundry. org | @edgexfoundry API Platform Secure Elements API Edge. X System •

Identity Management Edge. X Security High Level Function • Identity Management 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 Edge. X Identities edgexfoundry. org | @edgexfoundry Functions API Platform Secure Elements API Edge. X System • • •

Identity and Access Policy Edge. X Security High Level Function • Identity and Access Policy • Identities • • • Operator/User Client Cloud Service Device/End point Internal Edge. X Identities • Usage Cases Northbound (1 st priority) Southbound East/West (Edge. X node-to-node distributed) Administrative • Access for each identity • • • Functions 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 edgexfoundry. org | @edgexfoundry API Platform Secure Elements API Edge. X System • •

Data In Transit (DIT) Encrypted Comms Edge. X 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 • • Northbound (1 st priority) Southbound East/West (Edge. X node-to-node distributed) Administrative • Secure Auto-configruation Functions • Internal connections encryption is optional • External connections encryption is required • Confidentiality • Integrity • Possible to East-West Protected Connection via OAuth 2. 0 (Distributed Edge. X) edgexfoundry. org | @edgexfoundry API Platform Secure Elements API Edge. X System • Usage Cases

DAR Encrypted Storage Edge. X Security High Level Function • Northbound (1 st priority) • Southbound • East/West (Edge. X node-to-node distributed) Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • DAR Encrypted Storage • Confidentiality • Integrity • Usage Cases

Data At Rest (DAR) Policy Edge. X Security High Level Function • DAR Policy • What to encrypt • Encryption method • Identity Usage Cases Operator/User Client Cloud Service Device/End point Internal Edge. X Identities edgexfoundry. org | @edgexfoundry Functions API Platform Secure Elements API Edge. X System • • •

Operational Security Policy Edge. X Security High Level Function • Operational Security Policy edgexfoundry. org | @edgexfoundry Functions API Platform Secure Elements API Edge. X System • Inbound Connection Manager Firewall Policy • DIT Policy • SW Update Management Policy • Audit Policy • Attestation Policy (gateway, southbound devices) • Secure Auto-config Policy

Software Update Management Edge. X Security High Level Function • Software Update Management • In Scope • Edge. X Microservices (internally or externally (OS)) • Edge. X can play an orchestration role for Platform under Edge. X (OS) when allowed. • South bound connected devices Functions • Method • Validation of update signature • PKI Certificates –Smart device • Dumb device - Service Agent edgexfoundry. org | @edgexfoundry API Platform Secure Elements API Edge. X System • Future

Security Monitoring Edge. X Security High Level Function • Security Monitoring Alerts Anomaly detection Intrusion detection Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • •

Audit Edge. X Security High Level Function • Audit • Log security events • Signing and anti-tamper protections API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Attestation Edge. X Security High Level Function • Attestation gateway • Measurement for chain of trust • Measurement of boot images • Measurement of control and configuration Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • Future Attestation southbound device

Chain of Trust Edge. X Security High Level Function • Chain of Trust • What so measure • How to measure • Attestation measurement signing API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Privacy Edge. X Security High Level Function • Privacy • Needs to be taken into consideration • Consumer • Health Care (HIPA) • EU Requirements API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Hardware Platform Required Security Functionality Edge. X Security High Level Architecture HW TEE Secure Update Key Store Digital Signature Algorithm TRNG Attestation/Tru sted Boot Secure Boot edgexfoundry. org | @edgexfoundry

HW TEE (Trusted Execution Environment) Edge. X Security High Level Function • HW TEE (Trusted Execution Environment) • Required in platform to protect and isolate security sensitive values API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Key Store Edge. X Security High Level Function • Key Store • Required in platform to protect stored keys API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

RNG (Random Number Generator) Edge. X Security High Level Function • RNG (Random Number Generator) • TRNG (True Random Number Generator) • DRNG (Deterministic RNG) API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Secure Boot Edge. X Security High Level Function • Secure Boot Signature validation at each boot level Integrity checks at each boot level Connection into chain of trust in Edge. X System will only boot of integrity checks pass Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • •

Digital Signature Algorithm Edge. X Security High Level Function • Digital Signature Algorithm • ECDSA API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System Functions

Attestation/Trusted Boot Edge. X Security High Level Function • Attestation • Measurement of each boot level • Connection into attestation in Edge. X • Trusted Boot Functions API Platform Secure Elements edgexfoundry. org | @edgexfoundry API Edge. X System • Measurement and reporting of attestation vector. System always boots.

Edge. X Security High Level Architecture Open Questions • Out of Scope - Provide guidance on how security features can/should be tested edgexfoundry. org | @edgexfoundry

Proposed Northbound Security Objectives • Client, Distribution and Services Access ○ ○ • Administration & Permissions Management ○ ○ • Remote Administration Access Permission management interface Differentiation of local vs remote access ○ ○ • Parameter level read/write Streaming data permissions ( publish/subscribe) 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

Edge. X Northbound Connection Example Use Case • • Edge. X Gateway Connection is initiated from Edge. X 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 Edge. X to configure Cloud connection edgexfoundry. org | @edgexfoundry

Proposed Northbound Access Permissions Topology

Past Security Agreements 1. 2. 3. 4. 5. 6. 7. 8. “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 Edge. X. “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 “Edge. X Administrator updates software” – This is only the Edge. X 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 “Edge. X published all data” – Need to change to allow for smart devices to publishing data directly to cloud. edgexfoundry. org | @edgexfoundry