Skip to content

Instantly share code, notes, and snippets.

@revmischa
Created June 13, 2017 02:42
Show Gist options
  • Star 0 You must be signed in to star a gist
  • Fork 0 You must be signed in to fork a gist
  • Save revmischa/709d3bfe9b48084a8a0de81413a58c53 to your computer and use it in GitHub Desktop.
Save revmischa/709d3bfe9b48084a8a0de81413a58c53 to your computer and use it in GitHub Desktop.
Open IoT Security Certification Draft

Level I - Basic

Network

Software/Firmware

  • No default username/password
    • Devices must not ship with a well-known username and/or password
      • Unless the password must be changed on first use No backdoor passwords in firmware. This can be dumped and reversed and published.
  • Each client or model should have a certificate issued from a vendor-controlled CA to control access
  • No credentials stored in firmware besides certificate
    • No non-unique API keys per-device. Storing non-unique private keys or API credentials on a device is unnecessary.
  • Each device should have a unique ID that is generated at manufacture time
    • Optionally via a formula provided to the manufacturer
    • Keep registry of existing devices and activated devices if possible
  • Remote updates or expiration date
    • Device must be remotely updateable when security patches need to be issued
      OR
    • Device must cease functioning after five years since last update
  • Require firmware updates to be signed by manufacturer to prevent drive-by updates
  • Basic prevention of brute-force login attacks if applicable

Hardware Nice To Have Features

  • TPM for secret storage and boot
  • Tamper sensors
  • Hardware scoped to minimum requirements for operation
  • Physical reset to factory settings
  • Event stream of device telemetry to cloud
  • rfkill; physical switch to disable radios

Level II - Audit

Additional level of customized auditing and certification that a certifying company can perform for clients that desire a more comprehensive review.

Policy Documentation / Review

  • Help drafting a security policy document for internal or compliance purposes.
  • Define current security posture and review deficiencies from final goals.

Disaster Recovery / Business Continuity

  • Ensure your critical business operations are recoverable after catastrophe.
  • Be prepared to handle problems immediately. Define an incident response plan.

Static Analysis

  • Valgrind static analysis for common programmer mistakes
  • llvm clang advanced C compiler with support for run-time safety instrumentation
  • If initiating long socket connection to server, keep-alive needed to prevent automatic socket closure by routers etc
  • If using open-source project code, the projects should be maintained to provide security updates
  • If using software components from a propriatary vendor should have a maintainence contract
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment