This presentation provides the need for an IoT Security Assessment Framework that IEEE ComSoc potentially can undertake the development.

1. Syam Madanapalli | Chair IEEE P1931.1 - The Roof Computing | June 27, 2020
IoT Security Assessment Framework
A data driven approach for the businesses
1

2. Complex & uncomprehended
The businesses should know
• What they are deploying
• A checklist for a calculated risk
• Potential attack surface
• Risk vs bene
fi
ts
IoT Security
Constrained
Devices
Big Scale
Tech Illiterates
Lack of UI, challenging to
design & con
fi
gure,
update, and prone to
errors
Applications & devices
are personal, and
involves humans &
physical world
Variety of devices,
protocols, &
applications
Big Impact
Safety & economic
risks, loss of
privacy and
business
interruptions
2

3. Typical IoT Network Segments
Typical networking technologies and corresponding security protocols
3
Cloud
PAN WAN
LAN Internet
IPSec Tunnel IPSec Tunnel
WiFi/
Ethernet
BB/LTE/MPLS
BLE,
802.15.4,
WiFi
SSP
Edge Router Apps
OTAE
CoAP/UDP/DTLS/IPv6

4. IoT Security Assessment Framework
The proposal
The assessment framework standard will
provide
• A way for the industry to assess IoT
applications consisting of IoT devices and
Edge
• A checklist for devices and edge
• Necessary and su
ffi
cient conditions
• A scoring mechanisms
• Enable decision making
• Data driven analytics for security assessment
A set guidelines for the
device vendors and
application developers
A method for evaluating the
IoT applications for security
needs
Self assessment/IEEE
certi
fi
cation
4

5. Existing/Ongoing Standards/Work ...
@IEEE-SA
• Healthcare Device Security Assurance Working Group (EMB/Stds Com/
HDSecWG)
• Standard for Wireless Diabetes Device Security Assurance: Product
Security Evaluation Program
• This standard de
fi
nes a framework for a connected electronic product
security evaluation program
P2621.1
P2733
• Clinical IoT Data and Device Interoperability with TIPPSS (EMB/Stds Com/
Clinical IoT DDI with TIPPSS)
• Standard for Clinical Internet of Things (IoT) Data and Device
Interoperability with TIPPSS - Trust, Identity, Privacy, Protection, Safety,
Security
• This standard establishes the framework with TIPPSS principles (Trust,
Identity, Privacy, Protection, Safety, Security) for Clinical Internet of Things
(IoT) data and device validation and interoperability.
5

6. Existing/Ongoing Standards/Work
Outside IEEE
• GSMA IoT Security Guidelines and Assessment
• Provides recommendations for the secure design, development and
deployment of IoT services
• OneM2M, IoT Alliance Australia, Trusted Connectivity Alliance
GSMA
IoTSF
• IoT Security Foundation - A not-for-pro
fi
t organization
• Provides advice and framework for IoT Security
• Has over 100 members, including ARM, NXP, Microchip, Samsung,
Vodafone, Qualcomm
6
ETSI EN 303 645
• IoT Security requirements for Consumer Devices
• Under development
• A potential candidate to collaborate

7. Other Established Standards/Compliance Guidelines
These will in
fl
uence the development of any new security standards
Information technology — Security techniques — Evaluation
criteria for IT security
ISO/IEC 15408
GDPR
Regulation on the protection of natural persons with regard to
the processing of personal data and on the free movement of
such data, and repealing Directive 95/46/EC (Data Protection
Directive)
HIPAA
The Health Insurance Portability and Accountability Act of
1996
PCI DSS Payment Card Industry Data Security Standard
7
IEEE Standard for an Architectural Framework for the Internet
of Things
IEEE 2413

8. IoT Security Requirements
The capabilities of the end devices should be considered for security assessment
Characteristic Class 0 Class 1 Class 2
RAM, ROM < 10KB, 100KB ~ 10KB, 100KB ~ 50KB, 250KB
Internet No IP CoAP IPv6, HIP
Cryptography Over the air
Symmetric
cryptography
PKI based
Protection One level up
Assisted at one level
up
Self and services at
one level up
Interface IoT Services
Security Provisioning
and Services
Security Services
Applications
Only for trusted
environments
Battery powered
under the Roof
Mains powered &
standalone devices
8

9. The Need for a New Standard
Data driven; Easy to understand and to be used by Business users
• Training, scaling, reducing costs and making
IoT deployments more secure
• Device capabilities based approach
• De
fi
ning Necessary and Su
ffi
cient conditions
• Scoring/grading mechanism
• Easy to interpret checklist and summary for
for weighing risk vs. bene
fi
ts and decision
making
• Data driven approach (applying ML/AI for
assessment)
• Self assessment/IEEE certi
fi
cation
9

10. 5C
Five Criteria

11. Broad Market Potential
A standards project authorized by IEEE 802 shall have a broad market potential. Speci
fi
cally, it
shall have the potential for:
11
• Broad sets of applicability
• IoT being adopted almost all business sectors, including residential and government
use. And security and privacy is the number one concern while considering an IoT
application. Hence the output of this project will have broad set of applicability.
• Multiple vendors and numerous users
• The number of devices that would be connected to the Internet is estimated to be in
tens of billions in the near future.
• Balanced costs (LAN versus attached stations)
• This project reduces the cost of IoT applications deployment by providing a repeatable
approach for security assessment and reduces the need for special skilled personnel.

12. Compatibility
IEEE 802 LMSC de
fi
nes a family of standards. All standards should be in conformance: IEEE Std
802, IEEE 802.1D, and IEEE 802.1Q. If any variances in conformance emerge, they shall be
thoroughly disclosed and reviewed with IEEE 802.1 Working Group. In order to demonstrate
compatibility with this criterion, the Five Criteria statement must answer the following questions.
12
A. Does the PAR mandate that the standard shall comply with IEEE Std 802,
IEEE Std 802.1D and IEEE Std 802.1Q?
• No. However, the standard would use the IEEE 802 standards.
B. If not, how will the Working Group ensure that the resulting draft standard is
compliant, or if not, receives appropriate review from the IEEE 802.1 Working
Group?
• Not applicable.

13. Distinct Identity
Each IEEE 802 standard shall have a distinct identity. To achieve this, each authorized project
shall be:
13
• Substantially di
ff
erent from other IEEE 802 standards
• This standard is not related to IEEE 802 standards.
• One unique solution per problem (not two solutions to a problem)
• There is no standard within IEEE that provides this capability.
• Easy for the document reader to select the relevant speci
fi
cation
• Yes, this project will de
fi
ne an assessment framework for deploying IoT
applications based on best practices for security and privacy.

14. Technical Feasibility
For a project to be authorized, it shall be able to show its technical feasibility. At a minimum, the
proposed project shall show:
14
• Demonstrated system feasibility
• Security assessment is typically prerequisite for any connected applications in the enterprise,
however the approach is proprietary.
• Proven technology, reasonable testing
• Not applicable.
• Con
fi
dence in reliability
• This standard will not reduce any existing system reliability.
• Coexistence of IEEE 802 LMSC wireless standards specifying devices for unlicensed operation.
• Not applicable.

15. Economic Feasibility
For a project to be authorized, it shall be able to show economic feasibility (so far as can
reasonably be estimated) for its intended applications. At a minimum, the proposed project shall
show:
15
• Known cost factors, reliable data
• This project will not introduce any new costs, rather will help in reducing
the cost of connected application deployment and maintenance.
• Reasonable cost for performance
• The benefit of security assessment will outweigh the cost of
assessment.
• Consideration of installation costs
• Not applicable.

16. Questions & Suggestions
16