IoT Security Initiative
Promoting Security
& Privacy In An IoT World
IoT Security Initiative
Promoting Security
& Privacy In An IoT World
OPEN SECURITY KNOWLEDGE
FOR COMPLETE SOLUTIONS: END-TO-END
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.
AVAILABLE SECURITY GUIDANCE
Cybersecurity Principles of IoT
Security Design Best Practices
Device Security Level Agreement
** Product Security Pre-Launch Checklist
** Cybersecurity Health-Check: Network & Cloud
** Cybersecurity Health-Check: Product Development
COMING
Cybersecurity Health-Check: Embedded Device
Cybersecurity Health-Check: User Privacy
Supporting 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 system technology components that would make up a large IoT or M2M solution end-to-end. It is not meant to be exacting or exhaustive. Its purpose is to help set a common understanding for the primary threat and security surfaces common for IoT and M2M implementations. Some implementations will make use of all of these components, while others only partial.
All elements making up a solution's design must be considered for threat, vulnerability, and risk. Then the subsequent types and amount of security applied to each section must be determined, applied, and maintained over time.
IoT & m2m 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.
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.
different 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 End-to-End
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.
classifying the iot system elements
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.
Understanding Security Context
Understanding Security Context
understanding 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.
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.
System Attack Surface
|
|
Vulnerability Categories
|
|
Threat Vectors
|
|
Needing Protection
|
|
hacking as a process
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.
System security context
Ultimately, there is the type of asset that makes up a product or service - a standalone system or user - which will have an inventory of attack surface items associated with it given its inherent technologies and operating properties. This attack surface will have threats, vulnerabilities, and security controls associated with it in an overlapping manner. Both attacker and defender are trying to solve for these elements based on their conflicting goals. As the defender, the goal is to consider the possible threats, identify known or potential vulnerabilities, and apply security controls in an adequate manner to protect the system and operations. See the Applying a Spectrum of Controls graphic below in the Deploying IoT Securely section for more on security control types to consider.
Cybersecurity Threats
Cybersecurity Threats
cybersecurity threats
Understanding the landscape of possible threats end-to-end is a critical step in defending system security and operational integrity of the solutions components.
Once all of the asset components in a solution are identified and understood, the attack surface of each can then be enumerated. These asset elements are all potential entry points into the trust-chain of the overall solution; and each of the many attack surface points provides a potential entry into the privileged, protected state of the asset given the goals and objectives of an attacker.
Below is a depiction of the most predominant asset types, system attack surfaces, and corresponding threat types. It is not an all-encompassing listing, but it is one of the most comprehensive.
Security Risk & Responsibility
Security Risk & Responsibility
security Risk & responsibility
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 - or 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.
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.
if YOU MAKE IT - YOU SUPPORT IT - YOU ARE ACCOUNTABLE
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.
Rating Device Security
Rating Device Security
Device security rating system
The Device Security Rating System (DSRS) is a method of evaluating the threat and risk posture of devices that are commonly used for the Internet of Things (IoT), Machine to Machine (M2M), and Industrial Control Systems (ICS) markets. The uniqueness of the model is that it takes a system-attack-surface approach that is relevant to the technologies used in IoT devices and the threats faced on today’s Internet. It also establishes a common language and scale for categorizing devices potentially facing threats and risk. The model is designed to help manufacturers apply baseline security controls on the basis of system threat and risk scoring methodology. Get the model's full description and template in the PDF document.
DSRS WHITEPAPER
The first section and step of the model is for rating system data and related device usage. This section begins to draw out the importance of the device data handled on the device and poses this in a straightforward manner. Step 1 takes inventory of the sensors and the device’s important input and output (I/O).
Beginning with the review of the Direct System Sensor I/O is meant to get the evaluator thinking about which input and output capabilities are part of the device’s design. Then, primary data categories are discussed in terms of the device’s direct collection or handling of a given type of data.
Once data security and privacy have been determined, the next step is to determine the extent to which the device may be targeted by an attacker once it is operating. This section includes questions about how the device communicates and operates according to the technical aspects of its known or planned capabilities and robustness. These specific questions are presented to help address the relatively opportunistic side of system attacks (on the basis of the attack surface) and then potential implications for the area network and Internet if the device is repurposed for denial of service activities.
Once the Data Security and Privacy and the Targeting and Threat sections have been completed, the final evaluation step is to determine the System Operational Use Criticality. Put simply, this section is meant to illuminate the perceived criticality of the device in its planned, likely, or known operational state.
Like Section 1, Section 3 has two steps: determining the primary industry and operational use class and establishing the criticality of use. As the title of the section suggests, the first step is identifying the primary industry or operational use class that the device is manufactured for and/or operating in at the time of rating. The second portion of Section 3 establishes the criticality of the device’s operational use.
Once all three previous sections have been scored and rated, the final task of the Device Security Rating System is to determine the overall security controls level on the basis of the ratings from the other three sections. The possible levels are 1, 2, and 3; security controls level 3 represents the most recommended security, and security controls level 1 represents the least recommended security.
In the Section/Step 4 table, the rating combinations are intended to facilitate the choice of a security controls level based on a blending of the threat and risk determined by the model. The three security levels could then each be paired with a recommended security controls baseline.
Once all four sections have been completed and the final rating level determined, the DSRS rating can be communicated easily through the first letter of each rating and the level number:
DSRS:[Data Rating][Targeting Rating][Criticality Rating]:[Security Controls Level]
For example, if a device’s Section 1 rating was Low, Section 2 was Medium, and Section 3 was Medium, then the final Security Controls Level would be 2, according to Section 4. Using the format above, this device rating would be shown as: DSRS: LMM:2
Get the model's full description and template in the PDF document.
16 Pillars of IoT Cybersecurity
16 Pillars of IoT Cybersecurity
16 pillars of iot cybersecurity
Once the threats, vulnerabilities, and risk are identified and understood, the task of applying adequate security controls to the systems and operations of a solution comes into play. To help establish a security framework to guide the security of IoT or any other cyber system, the IoT Security Initiative has created The 16 Pillars of IoT Cybersecurity. These 16 pillars should be used as the supporting framework in ensuring adequate security controls are broadly applied as a baseline. Though theses 16 pillars can apply to both the device side and the cloud-services side of the IoT solution, they are primarily intended to support the device side of the IoT solution. Hence, the 16 pillars also form the basis for our Device Security level Agreement (Device-SLA).
Deploying IoT Securely
Deploying IoT Securely
deploying Iot securely
ARBIL SECURITY PROCESS MODEL
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.
SECURING THE SOLUTION
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.