Security & Privacy Considerations in Internet of Things

1 Introduction Today in the Digital world, the Internet of things (IoT) explodes upbeating Moore’s law. Within few quarters we are going to have few millions devices converted many billions of devices which may potentially grow to trillions by 2020. These billion and trillions of devices would be instrumenting and controlling the real world through various sizes of software’s and different services, to augment them and to make our lives easier and potentially transforming and dictating us on how do we live, work and play.

Yes, welcome to the home of IoT – unmaintained, insecure tiny Billions and Trillions of interconnected devices interacting and leveraging advanced analytics and predictive algorithms to ensure better service quality. Thought it can provide innovative opportunity in areas like Smart City, Smart Energy, Smart Agriculture, Retail, E-Health to build multi scale products with its exponential benefits, it also comes with the lingering possibility of large scale exploitation of the system leading to potential economic, technological, and societal damages.

2 Criticality of Security and Privacy in IoT

IoT is making sure that world around us is hooked to each and every other things / devices, which will allow efficiencies of exquisite degree. For an example, in smart agriculture we can reduce the power consumption by watering the plants / crops only when the bio sensors implanted in the soil alarms for water needs, this saves water, power and increase the crops yield. IoT Sensors will also allow you and your physician to track your blood chemistry, Insulin level for diabetics and digestion in real time on E-Health systems.

But if these connected systems are hacked where mostly privacy is also involved, people can hack your movement across city roads, provide false alarms at your home and also can make your E-Health systems like insulin pumps, glucose monitors and pacemakers to work differently denying life critical real events causing physiological damages to the wearer or users of such devices.

The tiny devices that makes most of the IoT Systems is a world of heterogeneous embedded devices that intersect with the enterprise network exacerbating huge amount of user data and events creating the possibility of new service and product lines can cause physical, physiological damage thorugh stealth and persistent online attacks

Security and Privacy experts were stunned on the attack that was reported to had happened between 23rd Dec 2013 and 6th Jan 2014 where more than 100,000 Smart TVs, Refrigerator, and other smart household appliances compromised by hackers to send out 750,000 malicious spam emails typically sent in bursts of 100,000, three times per day, targeting Enterprises and individuals worldwide. This first home appliance ‘botnet’ – an hack which involves computers that appear to be functioning normally but are secretly controlled by cyber criminals are the network mesh of many tiny devices that are poorly protected and consumers have virtually no way to detect or fix infections when they do occur. Enterprises that provided services using IoT may find distributed attacks increasing as more and more of these devices come online and attackers find additional ways to exploit them.

3 How IoT is structured

Though there are many layers that can be derived into this ecosystem on various use cases, we can collate them as..

1) Sensing Nodes: Senses data and has ability to collect them 2) Local Processing Nodes - Layers of local embedded processing capability (local embedded processing nodes) 3) Connectivity Nodes - Wired and/or wireless communication capability () 4) Services Nodes - Software to automate tasks and enable new classes of services 5) Solution Nodes – Domain specific solutions that would directly interact with end users.

4 Challenges posed by growing IoT Ecosystem The exponential growth of the devices and endpoints in the IoT ecosystem has resulted into a variety of

challenges being posed in front of the researchers such as:

1. Things / Device Ecosystem Diversity With a host of new ecosystems and tons of existing ones appearing every day, consistency of host devices is a big challenge.

2. Device Internet Bandwidth (Consumption Constraint) Although IPv6 addresses the exhaustion problem of IPv4, the transition time and complexity are still on higher side.

3. Devices Threats Devices that are installed can be Cloned, replaced, Modified or stolen, as mostly they are placed in remote locations or affect the humans physiologically for certain behavior.

4. Information security and privacy With a surge in the number of devices participating in handling sensitive information, privacy enhancing technologies (PET) must form the core of any IoT design.

5. Data Integrity/Access Control

With data travelling across diverse devices, it is important to establish the contextual integrity of data

6. Breakdown immunity With a breakdown potentially affecting millions of people, fallback mechanisms must be developed for damage control

7. Establishing object trust/traceability Since the data flows through multiple checkpoints and inter-device boundaries, it may be difficult to trust and trace a specific part of data

8. Data reuse The data in an IoT network travels across multiple device boundaries which raises the possibility of it being used outside of the intended authorization

9. User maneuverability With a large amount of user data shared for the IoT services of a provider, data migration would be a Challenge

10. Loss of human control As technology develops, more predictive algorithms will result in autonomous operation of systems which would subsequently make human intervention difficult

11. Legal operability As multinational organizations provide geographically dispersed data and information services, compliance of local/national/international laws may be a hurdle

Apart from the above parameters, IoT operates on low cost innovative solutions, primarily runs on variety of cheap sensors that is used to monitor everything. Technology advancements and increased computing power, plus declining hardware costs and free software tools widely available on the Internet have contributed to an increased number of security risks.

Though there are relatively many blocks that needs to be addressed and prioritized, Privacy and Security are seen as the key technical blocks needed.

5 Why IoT Security and Privacy are Difficult? Firmware / Software

o Mostly customized OS resides and so no best security controls in place. o They are independent and can be modified or attacked easily at all levels – firmware, OS,

middleware, o Raw firmware or data between lines can be decompiled to extract credentials as they are in

remote locations

o Can be exhausted that means denial of service’s Communication

o Lots of Wi-Fi, BTH or Zigbee based devices in IOT sending information in parallel o Eavesdropping o Man-in-the-middle attacks o Rerouting traffic o Theft of bandwidth

Physical insecurity – Mostly Devices or Things are placed in remote locations where there is no physical control or possession. E.g., sensors placed in public locations, or in buildings with lots of people nearby or Soil sensors in Agriculture.

Constrained devices – devices units are constrained to enforce security controls or do heavy-weight cryptography as they have less power, bandwidth and memory

No clear standard and no geo / Global regulations. Mostly there are no “best practice” solution as most of them are ADHOC.

Highly mesh network devices / things means that we have possibility of ‘weakest link. This might be the entry point to any hackers

As there are many contributors like people, hardware, software, systems, businesses, and more, the solutions to a problem doesn’t just contrained to a module, rather to the entire system

When exposed to internet, we might have classic web threats to deal with – XSS, CSRF, content injection, etc

Product designers think security functionality costs more by time to develop, market and so is inconvenient for an example buying sensors and constrained devices with encryption coprocessors is expensive and hard.

6 Implementation Failures in IoT Products As most of the IoT related products flood in market are from startup’s that has innovative concepts, but lack in time and budget they wish to override product lifecycle. Below is the list of commonly found failures which are usually seen in most of the IoT products. Though certain enterprises have a hard guidelines, few of these are overridden there due to common framework usage both on Hardware’s and Software’s.

Unencrypted Storage of Customer Data Hardcoded Web Service Credentials Passive Customer Sign up for 3rd Party Services unencrypted Local Video Streaming \Information Leakage Poor Password Security Nemours Network Services Failure to properly implement HTTP Digesy Long Life (Clear Text) API tokens Open Internet proxy Lack of Authentication of Customer Data Poor Mobile Security Generic ODM firmware Clear-Text API calls Passive Wi-Fi recon File Deletion control broken hard corded OS credentials

7 Security Solution Considerations for IoT Security at both the Device and Network levels are critical to the operation of IoT. The same intelligence that enables devices to perform their tasks must also enable them to recognize and counteract threats. Fortunately as the components in this ecosystem is not in need of any revolutionary security testing approach, but rather an evolution of measures that have proven successful in IT networks, hardware devices, middle layers, adapted to the challenges of IoT and to the constraints of connected devices. Instead of searching for a solution that does not yet exist, or proposing a revolutionary approach to security, we should focus on identifying and delivering the current state-of-the-art IT security controls, optimized to address extremely complex IoT Ecosystem.

The above pictures helps us to understand various blocks that helps to acquire, process, analyze and monitor the data / events within the ecosystem at various levels. But for better understanding, we wish these blocks are categorized to various pillars to display the impact of the security breaches that can happen at each pillar and ways towards mitigation.

These pillars translate to:

1. Transport Security: To provide the appropriate level of identification, privacy, and integrity to network communication.

2. Storage Security: Provides appropriate level of protection to persistent data held on the device or within the system.

3. Software Platform Security and Implementation: Select and implement platforms and supporting technologies that provide a robust and layered environment upon which to build the solution easily and quickly.

4. Functionality Security and Implementation: Implement functionality using a technology stack and tools which enable it to be done so in a secure fashion.

5. Logging, Auditability, and Forensics Enablement: Concrete sources of logs from low-level and high-level software components which facilitate investigation of misuse.

6. Sustainability and Upgradeability: features which facilitate the ability to securely upgrade devices when vulnerabilities are discovered after release.

7. Hardware Platform Security: ensuring the hardware platform provides the required security features. 8. Managing and Monitoring: ensuring that IoT devices can be securely managed and monitored.

The following table summarizes the security threats we identified above and the potential point of vulnerabilities at different layers of the communication stack. We also include related RFCs that include a threat model that might apply to the IoTs.

Manufacturing Installation / Commissioning Operation

Things Model Device Cloning Substitution Privacy threat Extraction of security params

Application Layer RFC2818, RFC4016 RFC2818, Firmware replacement

Transport Layer Eavesdropping Man-in-the-middle RFC4919, RFC5713, RFC3833, RFC3756

Eavesdropping Man-in-the-middle

Network Layer RFC4919, DoS attack Routing attack RFC3833

Physical Layer DoS attack

This above table emphasize that we need to consider security at all layers and pillars of the ecosystem. To make sure we have complete coverage of the security and Privacy in IoT, we believe that we should start early and it should be part of the entire product lifecycle starting form ideation to maintenance while the product sustains in the market for many years.

In the following section we outline for implementers the types of cyber-security-supporting decisions and activities that it is recommended should occur during the different product lifecycle phases. The purpose of this is to provide practical advice and guidance to help ensure cyber-security is both presented and considered throughout the development of the product, while also providing technical considerations for implementers.

Below we would be discussing on how we can travel through this product lifecycle on its various phases and we would be outlining Security mechanisms that needs to be considered and decisions that needs to be done at that level that would help the product developers and Quality Engineering experts.

7.1 Phase 1: Concept Design, Market Analysis, Competitive Analysis, and Research This phase would be the most crucial phase as it will provide very high-level inputs on the overall product and the security considerations to be done and its viability. We would perform

1. Analyze on the product market, geo specific regulatory, legislative, physiological privacy and security insight and research.

2. Understand the other competitor’s products on the security and privacy capability and market differentiators and make sure those implementations also make our product viable to sell.

7.2 Phase 2: Requirements and Stories 1. Provide high-level market and technical cyber-security requirements and stories. 2. Review other requirements to identify potential security risks and exposures, understanding they may be

acknowledged and accepted and the risk born due to overriding factors.

7.3 Phase 3: Design, Architecture and Technology Stack Selection This phase involves multiple components like Hardware, Firmware for those specific hardware’s and Product specific Software with middleware interfaces. Product Managers has to decide on the Design considerations for hardware and software mode, but equally Functional Requirement and its architecture should be able to adapt the Geo Specific and Product Specific Security and Privacy needs for today and future needs. Below are certain brief description that needs to be used to make decision in this phase.

7.3.1 Hardware

1. Verify if the Device / Things has Trusted or verified Boot option

2. Hardware Accelerated Cryptography needs to be considered, which might reduce the Software dependency and related risk

3. Privilege levels, rings or domains needs to be defined and used 4. Trusted execution on the secured memory for the firmware. 5. Access needs to be verified on DMA – Direct Memory Access, IO – Input Output pins and Bus Lines for

their restrained access to others and secured data 6. JTAG / SPI / I2C kind of interfaces needs to be secured as there is a high possibility of Sniffing and

Modifications 7. Firmware update methodology needs to be curtained for all possibility of secured installation and

modifications 8. Impacts on Configurations and Calibrations when carried out through external components needs to be

understood 9. Secure erase and wear levelling test case needs to be created at all memory and external interfaces 10. Verify if Anti-tamper / tamper detection evidence indicators is enabled and meets the security testing

requirements 11. Verify if Wireless / RF components inherit the security risks that are identified 12. Production hardware schematic review and verification 13. There should be no additional articatacts either in hardware, software modules including the operating

system, its core security properties and features, and its configuration, should be verified as being in line with the security requirements and no additional artefacts present.

7.3.2 Software

a. Programming language selection - Understanding the security considerations for the language can ensure they are accommodated in architecture, development, and testing.

b. Developer tooling should facilitate secure coding, implementation of defensive techniques and leveraging of operating system defenses.

c. Plan to use modern compilers with security options turned on, and IDEs and CI systems that can perform static code analysis.

d. Ensure the development frameworks selected enhance security rather than detract. These can include web frameworks that will reduce common vulnerability classes or native language frameworks that address common memory corruption vulnerability classes.

e. Select a modern operating system or platform that provides defence-in-depth properties, including but not limited to ASLR, non-executable memory, process segregation, and sandboxing.

f. Plan on how updates to third-party libraries will be tracked and integrated on an ongoing basis as security vulnerabilities are discovered.

g. Leveraging compiler, operating system, and platform security features

7.3.3 Functional Requirement Design and Architecture

1. Installation and customization - potentially opens up devices or systems to attack upon initiation. 2. Connectivity authentication. Consider how will the connectivity be authenticated, where the credentials

will be stored and how easily credentials can transplanted to another device. 3. Data Communications – decide on communication would occur in line with the desired privacy and

integrity requirements 4. Man-in-middle and similar attacks needs to be mitigated and tested. 5. Define encryption requirements for storage and transport. Also decide on how keys will be generated,

stored and transmitted. 6. Hashing requirements for the products needs to be defined 7. Performance overhead due to CPU, Memory, External Interfaces, Wireless and battery impact needs ot

be considered. 8. Data Integrity requirements f will influence the design and cost of the product by right selection of

software and hardware. 9. Ability to identify the device and users when cloning and similar attacks happens. 10. Non-repudiation – Understand if transactions or requests from the device or user need to be non-

repudiable. 11. Data destruction on a devices needs to be devised for standard operation or in the case of compromise

or loss? 12. Define the Authentication levels, Data, functionality Network Services that needs ot be exposed and

hidden 13. Do these services require an authorization model as well as authentication? 14. Service interaction – Define the secured services interaction model, elevated access abstraction,

identifying the service before interacting on sensitive information 15. Define how Device wil be remotely Managed securdly 16. Check how the Vendor Support needs to be enabled for various backdoors Services , it should be

advertised, secured, and optionally be disabled by the user to enhance security. 17. Define the product upgradation model in a secure and scalable fashion to address future security

vulnerabilities or other bugs that require a software fix. 18. Logging and auditing should be enabled. 19. Backup, restore and Recoverability functionalities at all levels including firmware needs to be defined

with its impact.

7.3.4 Phase 4: Implementation

During this phase we should consider the below pointers too 1. Adherence to secure programming guidelines. 2. Platform lockdown early on in the development lifecycle. 3. Use of agreed developer tooling in defensive configurations.

4. Static code analysis performed as close to development as possible. 5. Ensuring latest versions which resolve known security issues of third party libraries and components are

used. 6. Production of positive and negative unit and functional test cases.

7.3.5 Phase 5: Verification and Testing

a) Production hardware schematic review and verification. b) Base platform analysis. c) Network traffic analysis. d) Interface analysis. e) Interface security analysis. f) Verification of functional security requirements. g) Verification of functional security design and architecture requirements. h) Trust boundary review, functionality assessment and fault injection. i) Side channel attack defense verification. j) Targeted security focused code reviews. k) End to end functional security assessment or product penetration test.

7.3.6 Phase 6: Product Security Sustainment and Maintenance

Sustainment is one of the most overlooked phases and encompasses a whole set of policies, procedures, and technical activities. A product sustainment plan typically needs to be able to:

a. Receive and process reports of security issues from external parties. b. Proactively monitor for reports of security issues in third-party components used and work with

development to integrate as appropriate c. Regularly liaise with vendors of components used to identify if further releases have occurred that

address security issues. d. Maintain a capability that can triage, resolve, test, ship, and distribute patches for security issues

identified. e. Have a plan in place for worse case scenarios such as product recall or widespread repair.

7.4 Security Threats and Impacts Though there are many threats for an IoT system and may be specific to a system or to an environment, below is

the short list that needs to be considered as part of the IoT product lifecycle helping product designers, testers

and implementers. These threats don’t have the Risks that the events may occur however would help the

developers and the Security Testing Team to consider and plan ahead with appropriate risk analysis done for that

specific product.

Threat Description Impact

Compromise on Device and Its Data

Compromise of the device or its data, either partially or entirely locally, through either hardware or software means.

External security boundary is breached.

Privilege escalation

Increase in access, either locally or remotely, breaching a security boundary.

Degradation or failure of a security boundary leading to an increased level of access either on a temporary or permanent basis.

Impersonation Impersonation of a trusted entity. Degradation or failure of a security boundary leading to an increased level of access either on a temporary or permanent basis.

Persistence Persistent access is obtained post-compromise through configuration

Integrity of the platform or the external security boundary enforcement is no longer effective.

modification or hardware / software manipulation.

Denial of service Service is lost, either partially or entirely, on a temporary or a permanent basis.

Degradation in availability or functionality.

Traffic interception or modification

Network traffic of any type can be intercepted, or modified.

Underlying trust in the integrity and privacy of the data traversing the network can no longer be guaranteed.

Stored data access or modification

Persistent data is read or modified. Underlying trust in the integrity and privacy of the persisted data can no longer be guaranteed.

7.5 IoT Security Testing – Best Practices Below are the few pointers that may be product or device independent. But they are needs to be considered while devising a plan for testing

i. Verify if the device identity is tracked all through its device lifecycle a. Check if the devices registers themselves b. Check if this process happens during every boot and within a pre-set frequency.

ii. Always verify / keep track of the device behavior a. Cross check with the product requirement document on the device specifics and its variable

information b. Check it on the server side and confirm if the devices are hacked or spoofed.

iii. Check if the product has the ability to block compromised devices. Any device needs to be blocked for tehir activity with the followings.

a. Only the devices in the list should have access control b. Product should be able to filter any unauthorized Protocols and undefined packages c. It should have ability to jam or ignore the Signals from devices, if needed or as needed in the

product d. Should have options to unplug the power by Users / Support Enggineers e. On the device, or a specialized device

iv. We need to consider that low-power or cheaper devices cannot encrypt data using standard encryption techniques or thorugh in-built hardware encryptions due to less memory and might drain battery fast.

v. Check if there are any unencrypted data stored within the product. a. Check if the devices accessible publically or protected with encryption b. Verify if teh data being non-encryopted, then it should have ability to send it to next availble

module and encryption has to be done there to store data safely. vi. Verify if the unencrypted data are sent over long distances.

vii. If data are sent long distance, verify if there are local ‘gateway’ or a powerfull local device to encrypt it on behalf of dumb devices

viii. Verify if the we have shadow encryption & data mangling strategies in case of any failures. a. Check if the devices / compornnts are Signed b. Check if the Ciphers – a secret way to write code, hashes & arithmetic algorithms are

implemeneted to hide the data / content ix. Verify if the entire product has the smart devices, communiocate with the defined handshake protocols

and use only the reliable communication mechanism like WiFi, RF etc x. Verify if the penerations can be done on your things through Spying

a. Always test by Intercepting the communication between your ‘things’ b. Verify the communications & detect if there are any anomalies

xi. Audit if there are Physical canaries applied though ‘social control’ amongst devices

xii. Verify if the devices report that other devices are talking to them inappropriately xiii. Validate that there are no execution / updates from the untrusted source or users like firmware or

software updates. xiv. Validate if the firware are digitally signed and tamperproof. xv. Validate if unlocking a single device risks only that device’s data

xvi. Validate if Physical access to the devices are taken care during implementations / installations xvii. Validate if Virtual Access are prevented by not opening the inbound ports, designed without ’listeners’ or

‘servers’ on the devices and only ‘workers’ or ‘agents’ and remote queues with outbound connections are only used.

xviii. Validate Virtual tampering is also disabled.

8 Data Privacy in IoT IoT ecosystem is built on TRUST, across three important areas - Industry, System and End User. While System Trust may be related largely with technological advancements and the implementation of the “privacy enhancing techniques”, the Industry and User Trust can only be cultivated by the right mix of involvement of the consumer, private and regulatory bodies across geo’s.

We have two major policy frameworks today defined by European Union Commission and United States Federal Trade Commission that revolve around legal regulation, self-regulation, government regulation, international agreements, Global / regional issues, User behavior in that Geo and many more. While testing, QEA organizatin has to consider about the debvices and its deploymnet location and adherence to respective regulations of that geo.

8.1 Regulations through European Union Commission It aims to issue a legislation which aims at a regional framework before applying it on a global level making the whole system functional. EU laid down few actions that include:

Governance implementation Privacy monitoring and personal data protection IoT infrastructure of utmost importance Standardization of IoT technologies Public and private sector cooperation Institutional awareness International dialogues

Test Startgy for this EU legistation should focus on

1) Validating if the Users are enabled with “Right-to-know” aspect where users will know what data is collected and users should have the option to deactivate tags if needed.

2) Validate if the product has “Prohibition” enabled, which prohibits certain behavior if the public / User community dislikes it.

3) Validate for “IT-security” rules that would protect application from unwanted reading and rewriting. 4) Validate “Utilization” policy that ensures information available in scenarios where it might be

required. 5) Validate “Task-force” policy that researches on legal challenges and resolution for the same

Highlights of EU legistation that needs considerations

a) Address many aspects but does not consider the merits of self-regulatory models and industry standardization. b) Ensures that the principles of verticality, ubiquity and technicity can be taken into account. c) Only applicable for member States in Europe and not globally d) Attest that privacy and data protection problems in the field of the IoT are taken seriously

8.2 Regulations through United States Federal Trade Commission This regulation is around the recommendation to implement a Consumer Privacy Bill based on the Fair Information Practice Principles (FIPP) along with a framework to assess how different scenarios in the regulation would apply to different businesses. In the same report, the FTC highlighted five key points of consideration for government policymaking efforts in the future years for all Digital Technologies including IoT

a) Do Not Track: Noting the efforts by Digital Advertising Alliance (DAA), browsers (e.g. Mozilla) and W3C consortium in helping the consumer with opt-out options, the commission reiterated its support to the above stakeholders.

b) Mobile: The commission planned on working with companies providing mobile services on creating succinct and clear messages for the customers for better transparency.

c) Data Brokers: The commission called on data brokers who collate and use consumer information to create a centralized platform with ease of access of information for the consumers on how their information is being used.

d) Language Platform Providers: Large platforms like ISPs actively track consumers‟ online activities and must be enlightened for addressing privacy concerns.

e) Self-Regulation: Sector-specific regulatory codes and ensuring the compliance of these codes.

During this policy framework discussions, it was stressed for need of developing a context-aware system inclusive of the culture, demographics and user perceptions for data use to supplement the privacy and security of consumer data in an interconnected world and increase the acceptability of IoT. Also the framework should comply with the followings

Products should comply with common framework unless they handle only limited amount of data that are not Sensitive and not shared with any third parties

Products should be designed to work with all best practices that are followed with existing Privacy and Security statutes.

These regulations applies to online and Offline data too. The regulations should be followed for all data that is reasonably linkable to specific Customer, Computer or

device. Products must Provide Reasonable Security for Consumer Data. Companies Should Limit Their Collection of Data. Companies Should Implement Reasonable Data Retention and Disposal Policies. Companies should maintain reasonable accuracy of consumers’ data Companies should maintain comprehensive data management procedures throughout the life cycle of their

products and services. Overall any IoT product that is developed and shipped across geo’s should follow the below charter to make sure they are sustainable and sellable.

8.3 IoT Privacy Testing – Best Practices • Verify if the Geo specific privacy laws are adhered across the product components.

• Verify if the Product catlogue and product User Interafces, makes users aware of the data collected and if teh conset of users are received and validated.

• Validate if the Data profiling is done as per the product requirement as each user or the things attached are differnt for every scenario.

• Validate if the personally identifiable information (PII) is handled as defined in the product requirment.

• Validate if the Geo Specific product has / adheres to that spefic geo’s / local privacy laws for example US and EU provacy lawa has many conflicts. So Test Plan and test Cases neededs to be different.

• Check the product if any personalized data are stored, Processed or sent that are not part of the Product Requirement

• Validate the product does not deviate from the Trust on which it is built, like on Data Collections, Authentications, reliability of communications etc.

• Validate if the context of data collection resides on the devices or cloud. Ideally a great product should have it on cloud / middle layer.

9 Quality Engineering Considerations in IoT: We understand that IoT ecosystem is nothing but the combination of various elements that combine together to

represent a product. Though mostly of the elements in this ecosystem are created for other purposes, they can be

customized for a specific products and so the entire product has to go-though the individual system testing and also

the System Integration testing aggressively.

Though we can go-though various regulations and best practices we wish Quality Engineering and Assurance team to

consider Structured Testing Approach and Consistent Testing Methodology based on industry-wide best practices

like OSSTMM, OWASP, WASC. Recently “OWASP” has specifically formulated Internet of Things top 10 project site

that has been created to assist vendors with securing their products.

These best practices, standard Security and Privacy testing techniques, combined with manual testing along with the

use of automated tools should be leveraged where ever possible. Devices and their components should be additionally

assessed based on these OWASP Internet of Things Top 10 list and the specific vulnerabilities associated with each top

10 category.

The OWASP Internet of Things Top 10 - 2014 is as follows:

• I1 Insecure Web Interface

• I2 Insufficient Authentication/Authorization

• I3 Insecure Network Services

• I4 Lack of Transport Encryption

• I5 Privacy Concerns

• I6 Insecure Cloud Interface

• I7 Insecure Mobile Interface

• I8 Insufficient Security Configurability

• I9 Insecure Software/Firmware

• I10 Poor Physical Security

10 References http://www.gartner.com/newsroom/id/2636073

https://www.gov.uk/government/publications/end-user-devices-security-guidance-general-security-recommendations/end-user-devices-security-guidance-general-security-recommendations

https://www.microsoft.com/security/sdl

http://www.ftc.gov/sites/default/files/documents/reports/federal-trade-commission-report-protecting-consumer-privacy-era-rapid-change-recommendations/120326privacyreport.pdf

The Open Web Application Security Project (OWASP): https://www.owasp.org/index.php/Main_Page

European Union: IoT Privacy, Data Protection, Information Security Fact Sheet: http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=1753

http://en.wikipedia.org/wiki/Data_Protection_Directive

http://www8.hp.com/h20195/V2/GetPDF.aspx/4AA5-4759ENW.pdf

https://www.owasp.org/index.php/OWASP_Internet_of_Things_Top_Ten_Project

http://h30499.www3.hp.com/hpeb/attachments/hpeb/application-security-fortify-on-demand/189/1/HP_IoT_Research_Study.pdf

http://www.techvibes.com/blog/from-m2m-to-the-internet-of-things-viewpoints-from-europe-2011-07-07

http://www.iot-a.eu/public/news/internet-of-things-holds-promise-but-sparks-privacy-concerns

http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=1753

http://en.wikipedia.org/wiki/Secure_by_default https://www.cesg.gov.uk/publications/Documents/platforms_secure_by_default.pdf

http://ec.europa.eu/information_society/newsroom/cf/dae/document.cfm?doc_id=1753

http://www.ftc.gov/sites/default/files/documents/reports/federal-trade-commission-report-protecting-consumer-privacy-era-rapid-change-recommendations/120326privacyreport.pdf

11 About the Author

Somasundaram Jambunathan, Associate Director, Cognizant Technology Solutions

Somasundaram (Soma) comes with fifteen years of relevant IT experience spanning across multiplatform development and testing

for embedded and mobile applications. At Cognizant, Soma leads the Mobile Testing Center of Excellence and is also heads the

Research and Development Unit that focuses on building various Testing Tools for Mobile and Connected Devices. Soma’s

expertise spans across areas including implementing cutting edge mobile applications like seamless mobility client, push-to-talk,

Mobile multimedia apps. With his forte in development of automation frameworks and testing process for mobile testing for

marquee clients, Soma has built a pool of mobile Developers and test consultants with an array of innovative service offerings in

a short span of time.