Weekly Meeting 2018 Jan 24 Security

2018 Jan 24 Security Working Group Meeting Agenda Review of Orlando Face-to-Face Security Related Decision and Actions

Security Functionality Requirements Fuse Arch.

Security Micro Service High Level Architecture Environment Hardware OS Specific Platform EdgeX Platform Security Function X Secure Boot RoT

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

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

Security Working Group Priorities Priority #1 - Inbound Connection Manager Priority #2 - Key Management Priority #3 – Authentication (Inbound)

Pick Next 3 High Priorities Access Management Internal Micro service Security Protocol Identity Management

Proposed Security Roadmap Delhi Continue enhancing services from the California release (key, authn, authz, proxy) Chain of Trust - Abstraction layer for pluggable 3rd party components Attestation - Abstraction layer for pluggable 3rd party components Audit - Security event logging Device Security - Onboarding, connectivity Integration with Systems Management Security Monitoring - Provide foundation for 3rd party visibility & monitoring (e.g. SIEM) Integrated public CA support - Provide abstraction for access to 3rd party CAs Security Architecture Chain of Trust 3rd Party Attestation 3rd Party Audit David Southbound Device Security Security Monitoring 3rd Party (based on enhanced Audit/Logging) Integrated CA 3rd Party

Security Services Approach Use existing open source capability where available At least as a “reference implementation” Aligned with EdgeX licensing Ex: Hashicorp’s Vault for storing tokens, passwords, certificates, API keys, etc Allow 3rd parties to replace or augment with their own capability 3rd party could contribute this back to open source 3rd party could be offered as proprietary add-on/value-add to EdgeX Ex: RSA provides replacement key store that works with EdgeX and replaces Hashicorp’s Vault Allow 3rd parties to add on top Ex: ForgeRock offers Identity Edge Controller to augment EdgeX security services

Actions and Next Steps Develop High Level Arch and Usage Cases

Security/ System Management Overlaps

Areas of System Management & Security Overlap Tutorial in both direction/whiteboarding For California Release System Management Agent & API - requires Authentication and Access API to stop services, set configuration, etc. requires AAA User requirements & how much AAA will we need (especially if it is a closed/non-connected gateway)? Use of system management APIs - how are they used by security Should Security service follow the same model between individual micro services and a “management system” visa via the Agent Use of alerts back to security services Security of north bound connection Systement management agent would ride that to communicate with 3rd party sys management systems Post California Inter-service communications Where do we need more customer/user inputs/requirements Bootstrapping securely Attestation/root of trust software updates/security updates/secure auto configuration whiteboarding & details may be after / outside of TSC meetings

Security California Release A OS reverse proxy will be selected and integrated to EdgeX Integrate with AAA service (see below) The implementation will offer both OAUTH and Basic Auth options Use of the network layer to protect access I.e. no changes to existing micro services at this time Currently looking at Traefik for dev/test and possibly NginX for prod This will be for HTTP/S only (meaning security for MQTT and other protocols will not yet be provided) An open source Authentication and Authorization server (s). (E.G., Keycloak, Dex, Hydra, …) will be selected and integrated to EdgeX Prod deployment models will require integration with centralized AAA.  Initial solution will be to integrate with reverse proxy Data Protection Services via HashiCorps’s Vault will be integrated with EdgeX This will provide Key Management, Certificate Services, Encryption API abstraction to allow 3rd party implementation/extensions Some additional research/work needs to be finalized for California around license, external CA support, local crypto library, bootstrap provisioning, local secure store for bootstrap credentials, unattended startup For the California release, the goal is to accomplish implementation without rework of the micro service APIs, with the possible exception of export services

Security Roadmap (beyond California) The existing Security Roadmap still generally stands and serves to outline future work More requirements need to captured from customers to sharpen the roadmap going forward (task for the Security WG) For example, the current roadmap is focused on securing the EdgeX “gateway” and remains the priority In the future (perhaps by Delhi) a roadmap around securing EdgeX’s devices will be outlined This may include research and considerations around specific technology like enrollment over secure transport (EST) Additionally, input from IIC, OpenFog and other IoT related consortia will be mined for both security requirements and EdgeX security roadmap items

Deemed Not in scope of EdgeX Security monitoring network management secure boot/trusted boot/HRT platform attestation (share measurements of trusted boot measures) security below the interface level (see red arrow)

Actions and Next Steps Develop Usage Cases to clarify needs

Inbound Connection Manager Firewall (Priority #1) Discussion topics Technical Lead: David Ferriera (Forgerock)

Platform Secure Elements Inbound Connection Manager Firewall (Priority #1) EdgeX Security High Level Function David Ferriera - Technical Lead Completed - Actions to define requirements and search for open source candidates Integrate reverse proxy Inbound Connection Manager Firewall Functions API EdgeX System API Platform Secure Elements

Inbound Secure Reverse Proxy Inbound secure reverse proxy service - Security (David Ferriera - Forgerock) California release deliverables: Select and integrate at least one OS reverse proxy. Integrate with AAA service Use of the network layer to protect access I.e. no changes to existing micro services at this time Currently looking at Traefik (native user/passwork support only) for dev/test and possibly NginX for prod Concern: Size of proposed containers are large. Evaluating alternative simper solutions. May need to write our own code. Assumption: HTTP/S only Inbound Secure Reverse Proxy

AAA service - Security (David Ferriera - Forgerock) California release deliverable: Select and integrate an open source Authentication and Authorization server (s). (E.G., Keycloak, Dex, Hydra, …) Primarily for dev/test deployment models Prod deployment models will almost always require integration with centralized AAA. Initial solution will be to integrate with reverse proxy Concern: Keycloak is 700 Mbyte container Evaluating alternative simpler solution. May need to write our own code Access Management (Least Privilege) Authentication Assumption: API protection only, (Authentication and Oauth 2) Supporting two modes: Simple Username/Password file and Oauth2

Actions and Next Steps David F. and Tony Espy to looking into smaller code size alternatives

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

California Release - Security (Riaz Zolfonoon - RSA) Data Protection Services Key Management, Certificate Services, Encryption API abstraction to allow 3rd party implementation/extensions Open source to be used: HashiCorp’s Vault Areas need additional work License review (MPL 2.0) External CA support Local crypto library Bootstrap provisioning Local secure store for bootstrap credentials Unattended startup

Objectives Simple REST API for basic Data Protection (DP) services Key Management Certificate Services Encryption Provide an implementation of the DP API Ideally, adopt an existing open source options Pluggable Modules Third parties should be able to replace or extend all or portions of the API implementation as value-add with no negative impact on the clients (e.g. add hardware-based key store).

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

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.

Platform Secure Elements Internal Microservice Security Protocol (Priority #3) EdgeX Security High Level Function On Hold Internal Micro service Security Protocol ?? Functions API EdgeX System API Platform Secure Elements

Other Priority Items Volunteer Please!!

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Proposed Northbound Access Permissions Topology

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.