sign in sign up
<<
Home , Application security, Misuse case, Secure coding, Security, Security bug, Security testing

Assurance in the SDLC for the of Things

During the Internet of Things (IoT) Village held at the from security defects. This article describes the Do you have DEF CON security conference in August 2016, 47 assurance techniques and processes involved in something new vulnerabilities affecting 23 IoT devices from 21 securing such applications and provides guidance to say about manufacturers were disclosed.1 Among these 47 on implementation across the IoT environment. this article? vulnerabilities were -related vulnerabilities, Visit the Journal e.g., design flaws, hard-coded passwords, IoT Software Components pages of the ISACA® configuration secrets, cryptographic issues, and (www.isaca. common coding flaws, such as buffer overflows, Each IoT component has its own software. How org/journal), find the invalidated inputs and command injection. can there be assurance that, while running in a real article and click on environment, the component is not allowing malicious the Comments link to The software running on the devices, gateways, persons to hack the software and get access to the share your thoughts. mobile and data center applications, and the data and information collected by devices? Secure interfacing application program interfaces (APIs) life cycle (S-SDLC) is the from which the services are consumed should be answer to software security assurance. Figure 1 subjected to assurance to ensure they are free depicts typical IoT components.

Figure 1—Typical IoT Components

Mobile Device 1 Applications

Device 2

Gateway or Cloud and Controller Data Center Device 3 Node Spplications

Bluetooth, MQTT, Wi-Fi Physical Zigbee, 6LOWPAN, Zwave Maintenance Device n Wired, Wi-Fi, 3G/4G Wi-Fi, 3G/4G Serial, Optical Ports

Source: S. Subramanian and B. Swaminathan. Reprinted with permission.

Sivarama Subramanian, CISA Balaji Swaminathan M., CISA, CISSP Is principal security architect at Cognizant Is a security architect at Cognizant Technology Technology Solutions, where he is leading the Solutions, where he is managing the integrated integrated vulnerability assessment delivery vulnerability assessment delivery and research, and research, enabling new service rollouts enabling new service rollouts, and aligning and aligning new security trends with customer new security trends with customer needs. Subramanian can be reached at needs. Swaminathan can be reached at [email protected]. [email protected].

1 ISACA JOURNAL VOL 3 featurefeature

Security should be embedded into the development • Unsigned firmware—Forcing the devices to cycle of the IoT components—be they the device download firmware from unauthorized sources firmware, gateway source code, application source without validation code or API source code. Following a secure SDLC approach would Applications in a typical IoT environment might fall mitigate the common coding flaws and software into one of the following categories: vulnerabilities related to IoT components.

1. Device applications that reside on the nodes Secure SDLC Steps to Address and gateways, e.g., a node.js- or python-based Common Coding Flaws and application running on a smart energy meter Software Vulnerabilities 2. Controlling applications that control and regulate the IoT environment, e.g., web-based or non- The cost of fixing a varies depending web-based applications built on Java, Dot Net, on where it is discovered. If it is discovered in Perl or PHP, typically residing in the data center the production environment, the cost of fixing it or the mobile application , from would include the tangible costs of the developer where the devices can be controlled effort, tester effort, user effort and deployment effort, and the intangible cost of 3. Consuming applications that receive data from reputation and customer trust. If it is discovered the devices for further processing, e.g., web- or during the design phase, then it is very easy to non-web-based applications, typically residing correct the design flaw and introduce a security in the data center, that perform analytics on the measure during the development phase. The cost of received data fixing a defect postproduction is approximately four 2 4. Relay services that format and transfer data times more than fixing it in the development stage. between different components, e.g., APIs, web services that transport the data across devices, applications and other IoT components The cost of fixing a defect There are two categories of vulnerabilities related to postproduction is approximately software. Those are:

1. An insecure web interface, which could allow some four times more than fixing it in of the following common attacks to take place: the development stage. • Injection attacks—Malicious execution of scripts, queries, system-level commands injected to apps IoT software assurance is the level of confidence • Unprotected secrets—Cleartext/unencrypted and trust that software is free from vulnerabilities configuration secrets, keys and passwords (either intentionally designed into the software or accidentally inserted at any time during its life cycle) • Privilege escalation—Elevating user privileges and the software functions in the intended manner. and user impersonation Security assurance for IoT applications can be best 2. Insecure software/firmware that allows malicious achieved through the adoption of a defense-in-depth users to change the software or compromise the strategy, which, in turn, warrants having a secure device, which can be used as a BOT (software SDLC practice (figure )2 in place. The principal robot) device. The following are some common intent is to build security within the life cycle of attacks: these applications from ground zero that potentially • Firmware corruption—Sending malicious and gradually reduces the flaws in security, design, firmware that could improperly format the implementation and deployment. Proper adherence device logic or install a to such assurance best practices will result in applications devoid of vulnerabilities that might have

ISACA JOURNAL VOL 3 2 Figure 2—A Secure SDLC

eureet rteture et tea a a eeet et eet tate e

Bring our need Derive Develop Secure Perform Environment Performance for security in security design coding dynamic hardening of continuous SDLC requirements guidelines trainings during application assessment as per policy development security Performance Security Identify teams’ testing of penetration Patch and awareness security reviews testing configuration sessions compliance modeling managment Incorporation requirements Use of of security (SOX, PCI DSS, Security checklists Threat and log in all phases HIPAA, GLBA) architecture and monitoring of the and guidelines life cycle design Incident review Performance of static application

Source: S. Subramanian and B. Swaminathan. Reprinted with permission.

been introduced accidentally or intentionally at any • Category by development type—The category point of time in their life cycle. by development type depends on where the software/API was developed, e.g., in-house Inception and Requirements development, vendor/partner development, commercial/commercial off-the-shelf or open Effective of the components source. This is also vital in deriving the security involved is a critical focus area because a typical governance and policies with which to adhere for IoT environment is spread widely, both physically each of these types. (with numerous devices) and logically (with multiple technologies and applications). This effective • Category by application type—The category management can be achieved only with a proper by application type depends on where the inventory of what is to be managed, such as: software or the API resides, e.g., device (nodes or gateways), cloud/data center servers, mobile or desktops. This would dictate the guidelines, checklists, security configuration Awareness sessions on application applicable to each of the application types in line security, threats and recent breaches with the security policies.

have to be conducted early in the life The S-SDLC control gates, such as design review/ cycle and on a regular basis to impart threat modeling in the design phase or static testing in the development the necessity of enforcing security in phase, have to be mandated. The entire SDLC cycle has to be monitored and managed for continuous the applications at all stages in the improvement in delivering rapid-yet-secure software life cycle. to production. Such managed solutions are vital to ease the security assurance process and are highly recommended.

3 ISACA JOURNAL VOL 3 Depending on the levels perceived for the Figure 3—Industry-specific Threats applications, the control gates can be derived. Incremental and rapid deployments require Industry Threats oversight throughout the development life cycle Automotive Human safety, unauthorized until operation, especially in the case of enhancing control of self-driving vehicles, global positioning via DevOps, along with a well-defined acceptance system (GPS) use criterion from a security standpoint. Health care Medical data theft, manipulation of medical Awareness sessions on application security, threats devices (e.g., pacemaker, and recent breaches have to be conducted early in blood pressure monitor, the life cycle and on a regular basis to impart the defibrillators) that could necessity of enforcing security in the applications at malfunction and pose a threat to patients’ lives all stages in the life cycle. Energy Power theft, unauthorized metering data calibration, Design Phase grid shutdown During the design phase, the architecture and Consumer electronics Electronic appliance design of the IoT solution would be reviewed using malfunction that could lead to threats on a consumer’s threat modeling techniques. Threat actors and life or unauthorized device possible threat scenarios should be enumerated consumption for each of the IoT components. For example, Source: S. Subramanian and B. Swaminathan. Reprinted with permission. a threat scenario could be a possible data integrity issue due to a lack of The controls that need to be built into the IoT controls in the device. After the enumeration of applications and the APIs are: threats, countermeasures can be ranked and recommended. • Input validation—Handling input data from users, apps and services

The standard approach for threat modeling using • Authentication—Identifying and verifying users the STRIDE and DREAD models is as follows: and traffic

• STRIDE—Threat categorization considering • —Enforcing for all spoofing, tampering, repudiation, information requests to the application disclosure, denial of service and elevation of • Configuration management—Securing privileges configuration data and metadata, console access • DREAD—Threat ranking attributes considering • and privacy—Security of sensitive discoverability, reproducibility, exploitation, and confidential data, such as protected health affected users and damage potential information or other personally identifiable This method will suffice for reviewing the IoT information architecture, with an additional threat focus on of the devices. Common threats • Session management—Safely initiating, handling applicable to physical security are device theft, and terminating an application’s sessions device cloning and unauthorized physical access. • Cryptography—Using strong , hashing The primary difference in the standard threat and key exchange algorithms, digital certificates model analysis and design reviews is the and signatures application of knowledge of industry-specific threats. Figure 3 shows some of these unique • Exception management—Safe handling of industry threats. application exceptions

ISACA JOURNAL VOL 3 4 • Auditing and logging—Recording all events with should also be trained on embedded systems required attributes for accountability programming, or embedded systems programmers used to design the apps that specifically sit on the • Communication security—Securing traffic to devices/hardware. Such apps can either be and from the application full-fledged or enhancements to existing apps. • Availability—Safe handling of loads on the applications

The output of design review and threat modeling Continuous activities should enforce the incorporation of only standard and authorized frameworks, modules, integration of APIs and design specifications, e.g., Spring security best Security for access control or AES 256 and above for encryption. This ensures a secure baseline is practices, tools and built into the design, which will flow through the assessments to aid in SDLC, thus greatly reducing the number of security defects in later phases. Unauthorized or unverified continuous delivery frameworks or APIs that are pulled from public repositories should be avoided. Should there be a must be practiced business need for the usage of such modules, the and implemented following steps should be completed: with automation. • Enumerate if there are any known vulnerabilities and exploits associated with the codebase.

• Ensure only the updated version is used.

• Thoroughly analyze the code and fix the In addition to the standard vulnerabilities and insecure vulnerabilities (development phase). coding practices in the common programming languages (e.g., Java, J2EE, PHP, .NET), hardware- Security design solutions for the perceived and specific code and code governing the embedded standard threats have to be carefully weighed and systems (Embedded /C++) should be inspected provided based on multiple factors, e.g., use cases based on the secure coding standards mentioned involved, input and output, application type and previously. Custom vulnerability signatures and test technology, and device specifications. Educating cases can also be developed depending on the the application architects and developers on nature of the logic implemented, APIs and libraries secure design guidelines and incorporating these that lie on the devices that govern the underlying guidelines into the design will also greatly improve hardware, persistent and nonpersistent storage, the security baseline. firmware life cycle, coding techniques, and defects that reside in open sources. Development Phase Awareness should also be imparted to the During the development phase, whether it is Agile developers on the IoT attack and threat surfaces, or waterfall development, secure coding training because the software they are expected to based on the Open Web Application Security develop is supposed to interact with real-world Project (OWASP) Top 103 or Top 9,4 SANS Top objects. Their software integrated development 25,5 or CERT principles6 should be imparted to all environments (IDEs) should be enabled with secure the developers and has to be enforced at regular code review plugins to do security checks during intervals to stay abreast of the latest developments the checkout time. An independent security analyst against new attacks and threats. Developers could review the stable code for any of the security

5 ISACA JOURNAL VOL 3 flaws mentioned previously, unauthorized access to security assessments to be performed can be secrets and secret-key session issues. decided accordingly. Some typical assessments that have to be performed include: For rapid and incremental deployments, exercising formal control gates (as in traditional waterfall • Vulnerability assessment or dynamic models) might not be practically feasible. Continuous application security testing (DAST)—Ensure integration of security best practices, tools and the input and traffic to/from the application is assessments to aid in continuous delivery must thoroughly tested to enumerate the vulnerabilities be practiced and implemented with automation. In that are prevalent as dictated by standards such other words, continuous development is and should as OWASP (Web Top 10,7 IoT Top 10,8 Mobile always be accompanied by continuous automated Top 10,9 thick client), Web Application Security assessments to ensure that all software and API Consortium (WASC)10 and SANS Top 25.11 These changes are security-vetted and only a signed-off have to be performed on all of the following build is propagated to the next phase. Failed builds applications used in the IoT environment: should be automatically fed back for remediating – Web apps vulnerabilities. – Mobile apps – Device apps Assessing a software or API can be more effectively – Thick clients achieved when the source code is available, as it – Web services and APIs (plain and can be directly inspected for vulnerabilities. When representational state transfer) blackbox products, whose design and source code are not available, are used only a standard vulnerability assessment can be performed on the apps or APIs in the test phase. Nonstandard open Assessing a source software and APIs that are leveraged from public repositories should be given due attention, as software or API can specified in the design phase. Since such software be more effectively and APIs might not have undergone a secure development, they should be thoroughly examined achieved when for known and custom vulnerabilities. This the source code examination should use tools that are specialized in identifying vulnerabilities in open-source software. is available, as it

While the requirements serve as user stories (in can be directly Agile modes), developers can leverage the plugins inspected for and tools that integrate with the build servers (e.g., Jenkins, Bamboo) and conduct assessments on vulnerabilities. the fly based on check-ins. Test cases and the vulnerabilities list should be continuously revised and fed back to the cycle, and the cycle should move to the next phases based on the acceptance criteria. The same mode of continuous delivery • Reverse engineering and debugging—Reverse enhanced via continuous assessments can be the applications from their binaries; interpret any leveraged for the testing phase as well. hidden logic, controls and secrets; and repack to their original state after bypassing and Testing Phase altering the hidden logic. This will be more applicable to mobile apps and device apps, Depending on the type of IoT application and the where much of the application logic and controls APIs in place, the necessity for and the type of are housed.

ISACA JOURNAL VOL 3 6 As with every SDLC phase, the testing phase when the applications are signed off by functionality associated with the applications should consist of and performance testing. More logical and business the assessment activities pertaining to the physical use cases must be targeted manually in parallel. endpoints (e.g., sensors and nodes). The standard approach for security testing is detailed in figure 4. Physical risk could range between any extremes depending on the use cases involved. Some The test environment should be scalable enough to sample abuse cases are: account for the data generation and aggregation to be fed to and consumed by these applications to • Bypassing device enrollment and registration mimic the real world. The live environment where the • Cloning and stealing devices apps and devices will be deployed is widespread and will receive data from many endpoints. • Simulating physical movements to bypass sensors and actuators It is worth noting that security testing for an • Abusing protocols, e.g., ZigBee, Z-wave, IoT environment does not stop just with the 6LoWPAN applications. The scope is as broad as the number of components involved, e.g., sensors, actuators, Depending on the use cases or the functional gateways and the underlying infrastructure. Key flows perceived for each device and application, target areas should include: the vulnerability test cases should be designed • Smart devices—Device disassembly and review, as appropriate. The test methodology should memory extraction, attacks on buses and consider all use cases pertaining to the complete through physical ports IoT environment, and every such use case should • Firmware—Static and dynamic analysis, have one or more (security test case) reversing, malicious firmware injection and signing associated with it. • Communication—Traffic analysis, protocol Wherever possible, vulnerability test cases and test decoding and fuzzing, packet replays, and scripts have to be initiated via automation, as and cryptographic attacks

Figure 4—Security Testing Approach

Study of devices Identification of Application and environment relevant hacks use-case analysis

Preparation of Identification of Derivation of test assessment applicable tools cases (automation methodology and manual)

Setup of test environent Test execution Reporting

Integration With Application Release Cycle

Source: S. Subramanian and B. Swaminathan. Reprinted with permission.

7 ISACA JOURNAL VOL 3 • Infrastructure (deployment phase)— Just as APIs and applications undergo a secure Vulnerability assessment, penetration testing SDLC, manufacturers should ensure that these and hardening devices are subjected to secure development life cycle from device circuit designing, assembling and setup, to rolling out to customers.

Early in the Unwanted logical and physical ports should be turned off in such devices and servers, and physical inception phases, security procedures should be tightly employed to detect and prevent against attacks such as device/ a centralized sensor theft, tampering and unauthorized access. management and All such attempts should be monitored, alerted, monitoring solution logged and defended effectively. is imperative For leveraging cloud-based services (especially in the case of ), where the apps to track the IoT are exposed as services and APIs, customers should work with the service providers for obtaining the environment and its assessment and audit results of the apps and the components. infrastructure being relied upon to provide assurance.

Standard vulnerability assessment and penetration testing have to be conducted on all the IoT Deployment Phase environment components, especially the servers hosting the applications and APIs to identify While a majority of off-device apps adhere to the and mitigate the vulnerabilities pertaining to the common environment hardening guidelines and operating system and platform that could lead to a are subjected to penetration testing, on-device compromise. Real-world penetration testing should apps require special considerations for a secure also focus on serving load traffic to the devices and deployment. the applications.

Device manufacturers should comply with security Operations and Steady State guidelines mandated by the respective industry consortium groups (e.g., Institute of Electrical Early in the inception phases, a centralized and Electronics Engineers [IEEE] for energy, US management and monitoring solution is imperative Food and Drug Administration [FDA] for medical to track the IoT environment and its components devices, Society of Automotive Engineers [SAE] (applications, devices, sensors). for automotive devices, Consumer Electronics Association [CEA] for consumer electronic Automation of vulnerability, patch and configuration devices). Common devices prevalent in the management must be exercised. Every single industries are: application and node must be subjected to continuous monitoring to aid in automated threat • Energy —Smart grid, smart meters, relays, and attack detection and response, which will fuel programmable logic controllers (PLCs) additional confidence in security assurance. In • Medical devices—Smart pacemakers, defibrillators addition, continuous vulnerability assessments, penetration testing and security maintenance have • Automotive—Smart or driverless vehicles to be carried out to cope with the ever-increasing • Consumer electronics—Smart home appliances attacks and threats, and defended accordingly.

ISACA JOURNAL VOL 3 8 Business Use Case addressed before moving to the next phase. The A typical vehicle parking system consisting of mobile applications were also reverse-engineered device and upstream applications underwent to disassemble and debug them to enumerate security assurance via secure SDLC. The high-level vulnerabilities pertaining to data storage security, IoT architecture is depicted in figure 5. access control and sensitive secrets.

The device sensors identify the availability of a The gateway and cloud servers holding the parking spot by detecting the electromagnetic field application tiers underwent network penetration created by a vehicle’s presence or absence. These testing, and configuration hardening was conducted devices feed the parking data to a local gateway on the gateway and cloud servers hosting the through the data bus wired from them, and then the application tiers to identify and prevent the gateway communicates with the customer’s cloud vulnerabilities in the platforms and operating systems. applications. From the cloud, users can pull, query and reserve the parking spot by using mobile apps. In addition, physical penetration testing was also Applications that were subjected to security performed, e.g., tricking the sensors, cloning or assurance are: impersonating sensors, and tampering with the 1. Device applications—D1, D2, D3, D4 hardware. Abuse cases were designed based on the business rules laid out by the customer and 2. Node.js-based thick clients—Managing the electromagnetic sensors attached to them executed as appropriate in the testing phase.

3. Gateway application—Java logic The following are the number of security defects 4. Cloud application—Java/J2EE web and mobile enumerated in the respective SDLC stages: 5. Mobile apps—Android and iOS apps • Design: 41 • Development: 26 All of the aforementioned applications were subjected to secure SDLC, and vulnerabilities • Test: 17 identified in each stage in the life cycle were • Deployment: 11

Figure 5—Smart Parking System

Local Gateway Cloud Application and Dashboard

Wired Wi-Fi, 3G, 4G GSM

Source: S. Subramanian and B. Swaminathan. Reprinted with permission.

9 ISACA JOURNAL VOL 3 The following are typical data for cost per defect ranges12 (in US dollars):

• Requirements: $250

• Design: $500

• Coding, testing and implementation: $1,250

• Post-release: $5,000

Total cost incurred in defect fixing: (41 flaws*$250) +([26 flaws+17 flaws+11 flaws]*$1,250) = $77,750.

Had the apps not been subjected to secure SDLC, all the defects would have propagated to the final build and would have accumulated in the production: • Total number of defects: 41+26+17+11 = 95

• Total cost that would have been incurred for post- production fixes: 95 defects*$5,000 = $475,000

Total cost savings reached: $475,000 – $77,750 = $397,250 frameworks, standards and APIs should be used, and In other words, the cost that would have been due care exercised on open-source components. To incurred for fixing defects postproduction would be counter the most recent vulnerabilities and threats, approximately five times the cost incurred for fixing continuous assessments, threat monitoring and the defects in individual SDLC phases. Note that security patching must be conducted once the the previous amounts are an approximate indicator IoT devices, applications and APIs are exposed to on the costs involved and not the actual figures. production. Having security embedded in the IoT development cycle ensures that known security Conclusion issues are fixed and new ones prevented with the most effective measures, thus providing security Security assurance for IoT applications and APIs assurance for end users. has to be embedded throughout every stage of the SDLC and must be continuous. It is critical Endnotes to maintain a proper inventory and configuration of all the application components building up the 1 Dark Reading, “IoT Village at DEF CON IoT environment. Security oversight or verification 24 Uncovers Extensive Security Flaws in must be part of the requirements stage. Proactive Connected Devices,” press release, measures such as training sessions and usage 16 September 2016, www.darkreading.com/ of security standards, guidelines and checklists attacks-breaches/iot-village-at-def-con- have to be mandated in all applicable stages, and 24-uncovers-extensive-security-flaws-in- validation measures are achieved by performing connected-devices/d/d-id/1326928 reviews and assessments in all stages. 2 Jones, C.; Metrics: Three Harmful Metrics and Two Helpful Metrics, Security assessment tools should be integrated Project Performance International, 6 June into the development and quality assurance cycles 2012, www.ppi-int.com/systems-engineering/ to trigger assessments on the fly and, wherever free%20resources/Software%20Quality%20 possible, employ automation. Only authorized Metrics%20Capers%20Jones%20120607.pdf

ISACA JOURNAL VOL 3 10 3 Open Web Application Security Project, Top 10 7 Op cit, OWASP Top 10 2013-Top 10 2013-Top 10, https://www.owasp.org/index. 8 Open Web Application Security Project, php/Top_10_2013-Top_10 OWASP Internet of Things Project, 4 Open Web Application Security Project, https://www.owasp.org/index.php/OWASP_ The OWASP Code Review Top 9, Internet_of_Things_Project# https://www.owasp.org/index.php/The_Owasp_ tab=IoT_Vulnerabilities Code_Review_Top_9 9 Open Web Application Security Project, Mobile 5 Martin, B.; M. Brown; A. Paller; D. Kirby; 2011 Top 10 2016-Top 10, https://www.owasp.org/ CWE/SANS Top 25 Most Dangerous Software index.php/Mobile_Top_10_2016-Top_10 Errors, The MITRE Corporation, 13 September 10 Web Application Security Consortium, “The 2011, http://cwe.mitre.org/top25/ WASC Threat Classification v2.0,” Threat 6 Confluence, SEI CERT Coding Standards, Classification Wiki, http://projects.webappsec. Institute at Carnegie org/w/page/13246978/Threat%20Classification Mellon University, Pittsburgh, Pennsylvania, 11 Op cit, Martin USA, https://www.securecoding.cert. 12 Op cit, Jones org/confluence/display/seccode/ SEI+CERT+Coding+Standards

11 ISACA JOURNAL VOL 3