Securing the IoT
© 2015 LDRA Ltd 1 Characteristics of Secure Systems
Dependable • Executes predictably Dependability • Operates correctly Trustworthiness Trustworthiness Survivability • Minimal vulnerabilities that can be exploited • No malicious logic Survivability • Resists or tolerates known Secure and novel attacks Software • Quick recovery
Survivability Software Dependability Trustworthiness (Resilience) Security
2 Standards/Organizations
• Common Criteria for Information Technology Common Criteria Security Evaluation
IEC 62443 • Industrial Network and System Security
ISO 27001 • Information Security Management
• Information Security for Power System Control IEC 62351 Operations (Smart Grids)
• Systems and software engineering. Replaced IEEE 12207 MIL-STD-498
• Security techniques – Message Authentication ISO/IEC 9797-1 Codes
3 Standards/Organizations
• Computer Emergency Response Team (CERT C CERT and CERT Java)
CWE/CVE • Common Weakness Enumeration
OWASP • Open Web Application Security Project
• Defense Information Assurance Certification and DIACAP Accreditation Process • Information assurance DOD
• National Institue of Standards and Bodies NIST • Risk management framework
Common Criteria • Information Technology Security Evaluation
4 Global Market Revenue, USD 140 Billion in 2012 – 214 Billion by 2020
Source: Grand View Research - Embedded System Market Analysis And Segment Forecasts To 2020 5 Embedded System Market Dynamics
Technology Trends • Steady growth of devices connected to IP networks • Continued miniaturization of silicon chips, coupled with decreasing prices of components • Wearable wireless sensors as well as in-body sensors are expected to witness increased demand over the next six years
Buyer Trends Regulatory Trends • Demand for consumer electronics • Considerable regulatory initiatives for expected to continue increasing, smart grid development, which is particularly in developing markets expected to drive embedded system adoption • Mitigation of security risks due to high • Energy efficiency directives, degree of connectivity is essential for particularly in Europe and North America market growth Embedded Governmental Oversight System Market
Source: Grand View Research - Embedded System Market Analysis And Segment Forecasts To 2020 6 Technology Roadmap: The Internet of Things Software agents and advanced sensor fusion
T Miniaturisation, power efficient electronics, and Tele operation and telepresence: Ability e available spectrum Physical- c to monitor and control distant objects World Web h n Ability of devices located indoors to receive geolocation signals o Locating people and everyday objects l Ubiquitous Positioning o Cost reduction leading to diffusion into g 2ndwave of applications Surveillance, security, healthcare, transport, y food safety, document management Vertical-Market Applications Demand for R expedited e logistics RFID tags for facilitating routing, Supply-Chain Helpers a inventorying, and loss prevention c h
2000 2010 2020 Source: SRI Consulting Business Intelligence 7 IEEE 12207
Secure by Design: (6.4.2.4 d) • Architect, designed, and implemented to protect itself and the information it processes • Resist attacks Secure by Default: (6.4.2.3) • Design to assume security flows are present • Default state promotes security Secure in Deployment: (6.4.2.5) • Deployed to be administered correctly and securely • Securely deploy updates Communications: (6.6) • End user and developer channels to discover vulnerabilities
8 Software Security Exploits in the Wild
• Prior to Windows proliferation: – 1971; Creeper Virus – 1987; Jerusalem Virus – 1988; Morris Worm • Post Windows proliferation: – 1995; Concept Virus – 2000; ILOVEYOU worm – 2002; Beast Trojan Horse – 2010; Stuxnet – 2014; Heartbleed
9 HeartBleed
Memory allocated in the line above adds payload + padding, the latter being user controlled
Omission of a length check allowed attackers to force the OpenSSL server to read arbitrary memory locations.
OpenSSL is used by several hundred thousand widely tested websites
Illustrates the importance of authentication of third party software
10 Pervasive Problems • Input Validation • Buffer Overflows • Data Type Overflows SQL Injection • Errors and Exceptions
11 Smart Grid
• Host of new devices such as smart meters entering the market • Code is often unsecure • Smart meters are often a gateway to data concentrators that aggregate meter data • Breaches include monitoring power usages by burglars • ISO/IEC 61850 edition 2 defines communication protocol for exchanging messages between nodes of a power grid
12 Consumer Products
• Machine to Machine (M2M) devices such as RFID tags, sensors, and growing complexity and automation pose new challenges
• Leverages commercial off the shelf (COTS) software and networking technologies (Wi-Fi, ZigBee, 4G, LTE, WiMax) and associated risks and vulnerabilities
13 Automotive
• Very large rapidly changing code bases, dramatic increases in infotainment code and difficult to avoid security flaws
• Increasingly connected, V2V communication, autonomous driving, steer by wire
• Layers of third party software and systems must be integrated and authenticated
• Weakness in Bluetooth stack for instance can result in intruder’s access to the CAN bus which can effect driving behavior dramatically
• Need for layered in-vehicle security to isolate risk and promote reusability 14 Industrial
• ICS-CERT
• Network security monitoring
• Importance of publishing Zero-Day Vulnerabilities and encouraging security updates (i.e.. Rockwell Automation)
• NIST 800-82 Guide to Industrial Control Systems Security focuses on SCADA, DCS, and PLCs
15 Medical Devices
• Content of Premarket Submissions for Management of Cybersecurity in Medical Devices (issued on Oct 2, 2014)
• Recommends IEC 80001-2-2 and IEC 62443
• Rapid growth of the number of devices, network technologies, and amount of software
16 Understanding Quality and Security
Software Software Security quality
Reliability Security Safety Security Processes Processes Critical Critical
Thinking Safety vs Security • Does the application perform reliably as designed? • Is the application resistant to external attacks Failing Functionality vs Attack Surface 17 Applicability in Embedded Systems
Security Risk Assessment Drives Priorities • Acceptable risk • Value of the asset • Level of protection • Capabilities of the adversary Tried and Tested Practices • Understand security analysis and penetration • Harden and assess an environment • Role-based access in an embedded environment • Understand networking related vulnerabilities • Ongoing security vulnerabilities Variety within the Embedded Space
18 Tracking Security Vulnerabilities & Exposures
• CVE database Repositories • NIST National Vulnerability Database of • Open Source Vulnerability Database Information • SANS Institutes’ Top 20 list • OWASP Top 10
Repositories • CERT C coding standard • CWE database of • ISO/IEC JTC1/SC22/WG14 C Secure Weaknesses Coding Rules study group
19 Typical Decomposition within DOORS
20 Traceability Throughout the Lifecycle
Traceability from high system requirements through lower level requirements, code, and tests ensures that requirements are properly implemented and verified Essential for reliability and ensures security requirements are properly implemented and verified
21 Developing, Executing, and Reviewing Tests
22 Returning Data Back to DOORS
23 Applying Secure Coding Standards
Requirements Design Implementation Unit Test System Test Deployment
Pre-empt security and reliability issues early when its much cheaper
Reduce cost of verification early in the process by developing more verifiable software
Focus on higher order issues on peer reviews
Consistent coding style and form across teams
Apply coding standard both at the developers desktop and prior to peer reviews
24 CERT - Computer Emergency Response Team CERT analysed • Project through Carnegie Mellon more than 1000 University vulnerabilities
Addresses • S/W that is being developed vulnerability of • S/W already deployed
• Easily avoided defects Primary cause • Common programming errors
• Uniform set of rules and guidelines Follow the • Determined by requirement of project and organisation Standard • Programmers familiarity or preference doesn't matter
25 CERT C Example
• MEM30-C - Do not access freed memory
Non compliant code : for (p = head; p != NULL; p = p->next) free(p);
Compliant Solution : for (p = head; p != NULL; p = q) { q = p->next; free(p); } head = NULL;
26 Risk Assessment for Rule MEM30-C • Reading memory that has already been freed can lead to abnormal program termination and denial- of-service attacks • Writing memory that has already been freed can lead to the execution of arbitrary code with the permissions of the vulnerable process – Severity – High – Likelihood – Likely – Remediation Cost – Medium
27 EXP34-C. Ensure a Null Pointer is Not Dereferenced
Non compliant Code Example: Ensure a null pointer is not de- size_t size = strlen(input_str)+1; referenced str = (char *) malloc(size); memcpy(str, input_str, size); /* ... */ free(str); str = NULL;
Compliant Solution: size_t size = strlen(input_str)+1; Dereferencing a null pointer str = (char *) malloc(size); results in undefined behavior, if (str == NULL) { typically abnormal program /* Handle Allocation Error */ termination. In some situations, } however, dereferencing a null memcpy(str, input_str, size); pointer can lead to the /* ... */ execution of arbitrary code free(str); str = NULL; 28 What is Undefined/ Unspecified Behaviour?
Code Result
Compiler is allowed int a = 5; to assume that short *b = &a; modification of a short will not affect *b = 6; an int even when they are the same printf( a ); size, so printf( a ) could print “5” or “6”
29 Another Example:
Code Result
uint16_t a; Depends on the size uint16_t b; of int used by the uint32_t c; compiler. If it is 16- uint32_t x; bit, then there may be loss of granularity x = a + b + c; for a + b
30 Array Bounds Exceeded
Code Result
Depending on the int32_t a[ 10 ]; uint32_t i; runtime environment (OS, etc), this will for ( i = 0; i < 20; ++i ) result in an { exception or a[ i ] = 0; } overwrite unrelated memory.
31 ISO/IEC JTC1/SC22/WG14 C Secure Coding Rules
WG-14 ISO group responsible for the definition of the C programming language
The CERT C/WG 14 Secure Coding Standard as a measure of software security
Secure C Annex for the next ISO C standard
• The rules are targeted at security issues • There is a requirement to produce rules which are tool checkable and reduce false positives • Based on CERT C, MISRA C:2004 and CWE
Automating compliance to CERT C/WG 14 using analysis tools
32 Automating Secure Standards Adherence
33 MITRE CWE and CVE
CWE Drivers MITRE not-for-Profit organization runs multiple Federally funded R&D Centers Co-sponsored by Cybersecurity and Communications
Common Community developed dictionary of software weakness types Weakness Enumeration Provides a unified measurable set of software weaknesses
Gives a standard for software tools and services target for software security Foundation for understanding and management of weaknesses related to design and architecture
source: https://cwe.mitre.org/ 34 CWE Architecture, Risk Mitigation to Coding Standards
35 36 What is Structural Coverage?
• How effectively did tests exercise code? • Exercised, entry points, statements, branches, Measurement compound conditionals, execution paths of Test • Systems requirement reliability levels up with one defect per 109 operating hours Effectiveness • Metric that helps determine when a system is adequately tested
• DO-178 B/C DO-278(A) for Commercial/Defense Structural avionics and ground systems • IEC 61508 for industrial controls Coverage is • ISO 26262 for automotive often • IEC 62304 for medical devices • EN 50128 for rail mandated • Company based standards (in-house)
37 Types of Coverage
Depending on the SIL or DAL level and functional safety standard being followed, coverage requirements and required methodology varies
• Statement Coverage • Branch Decision Coverage • Modified Condition / Decision Coverage (MC/DC) • Data Coupling and Control Coupling Coverage • Object Code Coverage • Linear Code Sequence And Jump Coverage – Test Path (LCSAJ)
38 Visualising Structural Coverage
Statement and Branch Coverage as Viewed Within a Flowgraph 39 Visualising Structural Coverage
40 Modified Condition / Decision Coverage
MC/DC is a coverage measurement for multiple condition decisions. It does not require every possible combination to be executed
If n is the number of conditions, then a minimum of n + 1 combinations are required to achieve 100% coverage, as opposed to 2n total combinations
This only really comes into its own for 4 or more conditions as the number of combinations increases exponentially
Conditions MC/DC BCCC Combinations Combinations 2 3 4 4 5 16 12 13 4096 20 21 1048576
41 CWE Structural Coverage
42 Test Effectiveness and Software Security
Requirements Design Implementation Unit Test System Test Deployment
Requirements based testing is necessary to ensure security • Structural coverage lets us know if the software has been tested (Test Effectiveness) • Structural coverage against requirements based test expose poor requirements, test, and implementation • Different levels of coverage • Statement, Branch, MC/DC • Integration with targets 43 Robustness Testing
44 Robustness Testing Practices
45 Building Your Secure IoT Products
Selecting the correct standard
• Ensuring industry credibility • Utilising existing industry expertise in identifying known security vulnerabilities around specific technologies and industries
Building security into each stage of the lifecycle
• Authoring, implementing, and verifying security requirements • Utilising static and dynamic analysis, much like the way quality/reliability is added in functional safety standards • Applying secure coding standards Continuing good security practices through deployment and incremental releases
46 Questions & Answers
47 For further information:
www.ldra.com [email protected]
@ldra_technology LDRA Software Technology LDRA Limited
48