X-Frame-Options: DENY

IoT Security Initiative

Promoting Security

& Privacy In An IoT World


IoT Security Initiative

Promoting Security

& Privacy In An IoT World




The IoT Security Initiative provides comprehensive guidance and tools for ensuring that the right levels of security and privacy are instilled into created and deployed products, systems, and services.

The security controls and guidelines recommended here are based upon an understanding of overall threat and risk to the technology asset, and how this risk can be mitigated in both the direct system and broader solution context.

The IoT Security Initiative provides broad, high-level material - that is at the same time direct, specific and actionable - to practitioners in various roles of solution development, management, IT, and information security.



The IoT Security Initiative supports the needs of OEMs, Service Providers, Corporations, and Government.


End-to-End Architecture

End-to-End Architecture

end-to-end architecture


Below is a logical reference breakout for a robust M2M or IoT solution.  This diagram helps illustrate the core M2M/IoT technology system components that would make up a large solution.  It is not meant to be exacting or exhaustive.  It's purpose is to help set a common understanding for the primary threat and security surfaces common for M2M and IoT implementations.  Some implementations will make use of all of these components, while others only partial.  


M2M and IoT Technology Surface Logical Breakout



M2M & IoT Solutions support multiple industries

Devices, gateways, backend networks, and services which comprise M2M and IoT solutions can be found in a wide variety of both old and new industries.  Below is a representative example of some of the industries seeing substantial growth in the use of embedded systems and Internet services.  All of these solutions utilize various levels of device robustness; and require varying levels of security and privacy considerations as well.


M2M & IoT Connection Scenarios

There are a number of different connection scenarios possible for Machine-to-Machine and Internet-of-Things systems depending on the given solution.  The complete system must be considered for threats, vulnerabilities, and controls to ensure sufficient security.  And as much as a holistic security view is important, privacy aspects too must be considered along the entire flow of system data. 

Example M2M and IoT Connection Scenarios

Primary M2M and IoT Communications Applications


A Multitude of Bearer Options

Just as Machine-to-Machine or Internet-of-Things solutions can take many different forms of connectivity layout, so too can they use a wide range of communications technologies.  Each form can add different elements of threat and vulnerability into consideration.  Some technologies will have security features incorporated into them by design, and some will have no security capabilities at all.


Considering an End-to-End View

To ensure a secure solution, all systems, services, data, communications and protocols that make up the complete solution must be understood and assessed for threat posture, vulnerability elimination and mitigation, and adequate levels of security controls.


M2M and IoT Primary End-to-End System Components

Establishing a common understanding of the primary component categories that make up an IoT or M2M system establishes an anchor for being able to then better determine threat and risk for a solution; and then to identify the security controls needed across the entire system.

The diagram above breaks up a system solution into five primary categories for security consideration: three IoT/M2M device specific categories deployed "in the field," a Component category for the sub-elements that make up the systems, and a Cloud Network category for backend networked systems and services that are also often part of a solution.

On top of the categorization model, there is also a classification overlay for further identifying the type of device, and the way it has been designed to be deployed for operation.  This classification scheme not only provides a helpful, simple nomenclature for quickly understanding the type of device in the system, but will also allow for further stratification in the mapping of threat, risk, and recommended security controls based on operational considerations. 



Security Context

Security Context


security context

As we can see from the architecture section above, there are a wide range of potential technology solution scenarios to consider security for.  The IoT Security Initiative aims to take a holistic approach to providing security and privacy guidance by considering the complete system solution; from various classes of embedded devices, to the wide ranging systems and service operations in the data center.  In each and every case though, the principles and base context of applying security remains the same, as can be seen below.  Additional context and relationship models are also presented in the Determining Threat & Risk sections below.


Solution categories requiring security treatment

Depending on the overall solution architecture, the following key categories should be considered, at minimum, when identifying attack surfaces, threat vectors, vulnerability categories, and what requires protection given the system solution.

  • Device/system provisioning architecture and process

  • User access control provisioning and process

  • Vendor/partner technology services & operations

  • End-to-end data flow

  • File transfer activity architecture and process

  • Storage & transfer of customer & sensitive data

  • Data privacy - internal and third parties

  • Device hardware and data retirement/de-provisioning  

  • Embedded device platform and configuration

  • Web applications and service API’s

  • Software code/binaries – device and server side

  • Network end-to-end connectivity: static/dynamic

  • Networking systems (layer2/3) platform & configuration

  • Backend server platform and configuration

  • Backend production service operations & management

  • Application server platform and configuration

  • Database server platform and configuration

What we should concern ourselves with

Given each solution operating environment and system asset, the attack surface, threat vectors, vulnerability categories, and the elements that need protecting should begin to be fully identified and understood.   This information and analysis forms the basis for system threat, vulnerability, and risk assessments; and then in determining necessary security controls.


Attack Surface

  • Physical Enclosure / Case
  • Power System / Energy Source
  • Board / Integrated Circuits / JTAG
  • RAM / ROM
  • Core Operating System & Services
  • Communication Protocol & Data
  • Data Storage (Logical & Physical)
  • Software / Firmware Update Mechanism
  • Provisioning & Management Interface
  • Authentication / Session / Encryption
  • Console & I/O Interfaces
  • Location & Timing Services
  • Development Framework / API
  • Test / Maintenance / Develoer Interface
  • BIOS / Boot Loader / Hypervisor
  • Applications / Libraries / Drivers / Runtimes
  • Web / Cloud Services Connections
  • User Interface
  • Communications Modules / Stacks / Links
  • Naming / Addressing / Routing
  • Logging & Backup
  • OEM & Supply Chain

Vulnerability Categories

  • Misconfiguration
  • Susceptible Protocol or Packet
  • Software Design or Coding Flaw
  • Susceptible Communication Transmission
  • Information Disclosure
  • Resource Consumption / Capacity / Lifespan
  • Susceptible Location or Proximity
  • Open or Weak Access Control
  • Social Engineered
  • Flawed Business Logic
  • Inappropriate / Unwarranted Trust
  • Susceptible Physical Control
  • Susceptible Side Channels

Threat Vectors

  • Physical Control
  • Physical Access
  • Physical / Electronic Destruction
  • Visual Acquisition
  • Code Execution
  • Network Access
  • Cryptanalysis
  • Decryption
  • Data Parsing
  • Data / File Read / Write
  • Code Decompialtion
  • Electronic Component Decompliation
  • Code Access
  • Code / Data Injection
  • Application execution
  • File manipulation / modification
  • Communication Connection
  • Communication Transmission
  • Protocol Manipulation
  • Electronics Emanation
  • Login Access
  • Physical I/O Connection
  • User Communications

Needing Protection

  • Cryptographic key
  • PIN / Password Credentials
  • Intellectual Property
  • Sensitive Information
  • User Personal Data
  • Location & Biometric Information
  • System / Service Architecture Information
  • System / Service Component Information
  • System / Application Code
  • System / Service Operational Information
  • System / Service Operational Availability
  • System / Service Operational Integrity
  • Brand Integrity
  • User / Public Health & Safety




Hacking a system, network, or environment is similar to conducting an offensive operation: perform reconnaissance of the target, compromise the target, and leverage the compromised target to increase your gains against additional targets as needed.

While the model below is a simplified view of the steps involved in hacking, it helps illustrate the primary components involved, and how they relate to the three main phases: Reconnaissance, Compromise, and Leverage.

It is very important to consider the hacking process, attacker modus operandi (methods, tools, and tactics), and common indicators of compromise for the given systems and environments when identifying and implementing necessary security controls, and testing their effectiveness.








Determining Threat & Risk

Determining Threat & Risk

Determining threat & Risk



Having a clear understanding of terminology and their interrelationships can go a long way towards everyone being able to work together in a common dialog and on a common approach.

The asset in this sense is the computing system; be that an embedded IoT or M2M device, a wearable, a gateway on a factory floor, or a virtual server - on a physical server - out in a cloud datacenter.


All system assets will have some level of vulnerability across a wide spectrum of possible attack surface.   And while much of a system's possible vulnerabilities can be determined, much will remain unknown and hidden. The objective is to eliminate as much vulnerability and mitigate as much potential threat as reasonably possible during system design, development, and implementation phases.  But it does not make sense to to try and remove all vulnerability based on all possible threat.  Things such as threat likelihood and impact, given known or potential vulnerability, along with in place security controls must be considered.  Then too of course, costs required in time and resources to establish levels and degrees of protection must also be taken into account.


Balancing Threat, Risk and Security in IoT and M2M


Implementing the right levels of security is always a balancing act

As data or system criticality goes up, the tolerance for attack from the business (the OEM and/or end-user) goes down.  Conversely, as criticality goes down, attack tolerance goes up.

As the perception of threat, and the criticality of a system and its data go up, so too does the need for greater levels of security controls.


multiple parties often have responsibility for adequate security

Different types of companies create their products and services relative to a number of different business arrangements.  These varying business arrangements obligate the partners contractually to certain technology, business, and financial terms.  The security obligations of a product should be understood, agreed upon, and included into these agreements at the beginning.  The closer a company is to the actual creation of the product or service, the greater their obligation to ensure that adequate secure design, secure development, and subsequent secure operation is going into it.  The relationship between business partners involved in the financing, creation, and ultimate release of the product correlates to this security obligation scale also. 

Product Security Responsibility in IoT and M2M



Specify and design the system, plan the Bill of Materials (BoM), and plan your release - all with the threat, the risk and the security needs in mind.  If you directly build or have a product or service built for you, then you have the security responsibility.  

If a heightened security posture is deemed necessary, then specify early and plan the BoM accordingly.  The more threat modeling, security requirements development, and security review and testing that is done throughout the development lifecycle, the better off your product and company will find itself.


Deploying IoT Securely

Deploying IoT Securely

deploying Iot securely



The Asset and Risk Based InfoSec Lifecycle (ARBIL) model is a representation of an information security lifecycle that can work for any organization needing to implement a security plan and risk management strategy for its information technology resources and associated operational systems.  The context of this lifecycle revolves around the protection of assets and the management of risk, threats, and vulnerabilities.  

Outer Wheel:

The outer circle of the ARBIL diagram comprises the overall security process, both operational and managerial.  Moving separately from the inner circle, but still working closely with it, the outer circle is vital to the quality and consistency of an organization’s information security plan and risk management program. 

Inner Wheel:

The inner circle of the ARBIL wheel comprises action-oriented safeguards and controls.  Like the outer circle, the inner circle takes in information from the other circle’s functions, and also feeds information back to it.

Remember that both wheels are a continuous process.  Keeping the activities continuously refreshed with new and updated information, and performing the functions, will ensure a strong information security program.


IoT, M2M and IIoT systems can comprise a broad range of technology and communications capabilities.  They also may involve multiple OEMs and/or Service Provider partners, and various computing environments. 

When considering what types and how best to apply security controls to a solution, it is important to consider three key elements:

  • The use of security controls throughout the development lifecycle.

  • The use of various types of controls in a layered, defense-in-depth approach.

  • To view the system solution holistically from end-to-end, but still remain technology-asset-centric.


The diagram above shows just a few example security controls across the various categories to be considered.  This is by no means an exhaustive listing, but should help illustrate the interrelationships involved.

testing the solution

Keep in mind that, depending on risk level for your product and service, varying levels of security testing, both pre and post launch, should be done.  And if you and your team are not well versed in these security activities relative to the technologies in question, then utilize third parties for augmenting and validating your security efforts.  This cannot be stressed enough.  There are individuals and firms who specialize in these security measures and testing of these various systems, technologies, and environments.  Even if you have skilled, internal security teams, if components of the solution are high risk, then consider augmenting with outside services that can bring in fresh views and approaches.  This can also have the added benefit of helping to improve the skills of your own internal resources.