1 / 20

Autonomous Security

Autonomous Security. Deep Dive. May 21, 2019. Self-Sovereign Security for Machines. Our conversation today will be centered on:. Internet security is necessary not sufficient for IoT Security is not possible without identity Devices divided into hierarchy of controllers and controlled

miracle
Download Presentation

Autonomous Security

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Autonomous Security Deep Dive May 21, 2019

  2. Self-Sovereign Security for Machines Our conversation today will be centered on: • Internet security is necessary not sufficient for IoT • Security is not possible without identity • Devices divided into hierarchy of controllers and controlled • Data ownership not an issue when anonymized • Access rights and control more important than ownership • RBAC and ABAC both needed to control IAM for machines • Securing hardware, software, data and communication • Abstraction of NXM’s embedded end to end encryption

  3. 1. Internet Security ≠ IoT Security Secure email might be a better model • Two decades ago Blackberry secured the emails with 3DES • BES and BIS where the system components, PIN was identifier • Blackberry as the first C-IoT (Cellular IoT) • Secure manufacturing was essential in making it all work

  4. 2. Identity is Essential in Security Replacing physical PIN with self defined identity • PIN to PIN messaging becoming Blackberry messenger • This could be a model for P2P communication using identity • Trust and data integrity are the two by-products of DSA • Firmware could be customized based on identity and time • Identity and PKI should be loosely coupled but 1-1 and any time • Discrete dissemination of identity could result in PAN for device • DLT would allow good behavior and act as control plane • Identity recovery would allow for life time identity

  5. 3. Hierarchical Control RBAC based on a single administrator graph • Devices are self-governing meaning they are the final arbitrator • Graph of connection means that the first peer would be the admin • Peer admin is complementary to system admin not replacing • Reversing the paradigm of ownership H2M, M2M in 4 phases: • Centralized Identity • Federated Identity • User-Centric Identity • Self-Sovereign Identity

  6. 4. Access and Control not Ownership Removing PII from data • Ownership is an issue when PII is mixed with the data • It is also an issue if pattern matching and data machine learning leak PII • Who does the connected car data belong to? • The shared ownership makes application of data rights difficult • IAM for machines could allow for access rights RBAC and ABAC • The best model would be publish and subscribe for stakeholders • Allows fine grain control if the data is encrypted, public, private, protected • Machine administrator can control/sell extended access rights to data

  7. 5. Attribute Based Access Control Data context can eliminate a lot of AI computation • NameSpace doing a lot of heavy work here as main context • Machine identity does not mean a single mission for the machine • P2P in the control plane implementation • User plane triple blind implementation for data dissemination • Approximate geographic area pre defined in the control plane • MQTT path aggregation predefined by definition and unlimited • Manual definition allowing for automated machine control • NameSpace allows ownership of the NameSpace by organization

  8. 6. Role Based Access Control Mainly in the control plane • Originally two roles defined admin and user for individuals • Groups, stakeholders and consortium access control under NXM • Identity and key management all done through the blockchain • Immutable nature of blockchain allows for auditing over time • Four types of implementation are possible: • NXM system • IBM Hyperledger white lable • Kubernetes, Docker, Hashicorp private instances • Distributed decentralized consortium with others using Min/Max

  9. 7. Single Methodology For securing hardware, software, data, communication • Machine security needs hardware security • Secure boot, secure update using firmware CI/CD per identity • Application level security relying on kernel space separation • Data is E2E encrypted, communication over secure channels • Inventory of things will allow for batches/lots treated differently • Identity would be more reliable over time  Concrete ID • Convenience trumps security • Complexity is the enemy of trust

  10. 8. NXM Automotive Router

  11. Onboarding Preparation is the main key to eliminate complexity

  12. In Keeping with Other Standards Regulations are coming

  13. UK Code of Practice Code of practice for consumer IoT security

  14. What is the direction for IoT implementations? Internet of secure things or a secure cloud of things? 20 years ago, the internet was a technical issue with some political implications. Today, it is a political issue with many technical components.

  15. CUPS Control User Plane Separation • Control Plane: Device Onboarding, Device Management, Roles & Attribute Based Access • User Plane: Application Data, Sensor Data, Aggregated Data, Meta data, Analysis • Peer to Peer: Control Plane Role & Attribute Based Access Controls (P2P, RBAC, ABAC) • Triple Blind: User Plane data dissemination model for: device – broker – user encryption • MQTT: Message Queuing Telemetry Transport in publish and subscribe (pub-sub) data model • NameSpace: Systematic data-model description for configuring telematics in the user plane • Services: Pre-configured data-model segmentation for data by NameSpace definition • Path: MQTT path abstraction used to send device data to the broker for consumption

  16. CUPS in 5G LTE as inspiration Used as a model for CUPS in Cellular Internet of Things (CIoT) Layer 3 Layer 1 Layer 2 CP 25.321 – MAC 25.322 – RLC RRC Physical Layer Control Plane UP BMC User Plane Broadcast FDD PDCP Packet Switched TDD Circuit Switched

  17. CUPS using DLT for IoT Simpler model than LTE implementation Layer 2 Layer 3 Layer 1 CP IP overlay MAC Physical Layer Control Plane DLT RF UP User Plane Wire MQTT Pub-Sub

  18. EE2EE Embedded End to End Encryption in a Cloud Infrastructure • Encryption for:Secure boot/update of firmware, application, data and communication • Encrypted during: Transmission, storage, viewing and processing in/to/via the cloud/fog • Encrypted only: For the devices that have been registered in the system and in inventory • Encrypted at: Late onboarding stage when the device is for the first time connected • Encrypted with: Agile Crypto – to enable resetting the encryption and repurposing the IoT • Encryption key: Managed by the digital ledger with Private key never leaving the IoT • Encryption strength: Defining one-way hierarchy for security from carrier grade to consumer • Encryption implementation: Defining access level using both roles and attributes

  19. Bifurcation of Data CID is the only link for full and complete view of data • Delimitation of the control plane interactions by behavior • Anonymized data access without sacrificing control • Delegated control based on rules similar to MUD • Late onboarding similar to Intel SDO • Device management similar to ARM Pelion • Has the advantages of re-purposing, admin extension of roles • Agile crypto allows for changes over-time • Quake makes it Quantum-safe

  20. Questions

More Related