<<

Securing the IoT

© 2015 LDRA Ltd 1 Characteristics of Secure Systems

Dependable • Executes predictably • 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 • Management

• Information Security for Power System Control IEC 62351 Operations (Smart Grids)

• Systems and . Replaced IEEE 12207 MIL-STD-498

• Security techniques – Message 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 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 - 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 : (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 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 – 2010; Stuxnet – 2014; Heartbleed

9 HeartBleed

Memory allocated in the line above adds + 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 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

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 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 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 • 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; . 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

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