INTRODUCTION:
The Stuxnet malware was a wake-up call for embedded device security when it became public knowledge in 2010. Its sophistication and purpose made it clear that industrial control systems and the embedded systems used to control and monitor critical infrastructure were at risk. Machine to Machine (M2M) and Internet of Things (IoT) realities mean that more and more devices are being deployed and connected to each other. This connectivity is both the promise of IoT (data gathering, intelligent control, analytics, etc.) and its Achille’s heel. With ubiquitous connectivity comes security threats — the reason security has received such a high profile in recent discussions of IoT.
Relevant:
- The Real Story of Stuxnet
- FTC Report on Internet of Things Urges Companies to Adopt Best Practices to Address Consumer Privacy and Security Risks
- Security as a New Dimension in Embedded System Design
- A Four-Step Guide to Security Assurance for IoT Devices
Security-First Design
Security has not always been a primary concern for embedded devices — connectivity among devices was assumed to be local, and in the hands of trusted operators and devices. Stuxnet, however, quickly proved that even local access can’t be trusted, as it infected PCs and laptops that then infected programmable logic controllers (PLCs) that were connected via a local area network. Modern devices need to be connected to a network (and frequently the Internet), and these devices require more serious attention to security and applying security principles early in the development lifecycle.
Software Security in the Software Development Lifecycle
A security-first design approach means integrating security as a top priority in the software development lifecycle (SDLC). Developers and project managers can expect at least the following types of activities at these key stages:
Security processes superimposed over the software design lifecycle.
- Requirements stage: Once a system-wide threat assessment is available, the device threat surface can be understood. At the requirements stage, security-specific requirements can be introduced, along with known “abuse cases” (use cases that an attacker might follow) and a risk analysis. Security requirements, as listed below, are introduced and accounted for. This stage is critical because it is the point at which security becomes a known development project goal with the appropriate level of risk management, scheduling, and costing.
- Design and architecture: As candidate architectures become available, reviews must include security aspects, (where previously, they may not have). Assessing architecture in light of the known threat assessment and security requirements adds an additional dimension to this phase of development. At this stage, testing plans should be created that include security analyses that follow the perceived “abuse cases.”
- Code development: At the coding stage, following security guidelines and coding standards are critical. The use of automation tools such as static analysis are key to ensure that vulnerabilities are not introduced into the product. Testing and test automation that includes a security analysis are important at this stage.
- Integration and Test: As the system as a whole starts to take form, subsystem and system testing will find vulnerabilities before integration and deployment to the market. Automated penetration testing tools can be very helpful at this stage to uncover vulnerabilities that may not have been accounted for in earlier stages of development. Packaging and configuration of the end product for deployment is key at the final stages of this phase. Ensuring that the out-of-the-box product is as secure as possible prevents many of the security issues we see today in connected devices.
- Deployment and maintenance: When a product enters the market and starts wide deployment, security vulnerabilities become exponentially more costly to fix. A product designed with a security-first approach is less likely to end up with a security breach, but companies must be prepared to deal with security on an ongoing basis. Designing the product with the ability to update firmware and software is critical to addressing new-found issues expeditiously. However, as a product goes through maintenance and revision, security is an on going concern and new vulnerabilities and new threats need to fed back in to the system in an iterative approach.
Security Requirements
Securing an embedded device requires many considerations. Key examples of security requirements that might go above and beyond existing functional requirements are as follows:
- User authentication – validating user access and enforced privileges for different classes of users.
- Tamper resistance – preventing physical and software changes to the device that allow circumvention of security functions.
- Secure storage – ensuring stored data is protected from online and offline access, including techniques such as encrypted file storage and Digital Rights Management (DRM).
- Secure communications – keeping data-transfer secure but also preventing unwanted access through connected channels (network, USB, etc.). Although network connectivity is top of mind, other channels are vulnerable to attack.
- Reliability and availability – maintaining safe operation of the device in the face of on going attacks.
The Role of SAST tools in a security-first approach
Static Application Security Testing (SAST) tools like Grammatech’s CodeSonar provide critical support in the coding and integration phases of development. Ensuring continuous code quality, both in the development and maintenance phases, greatly reduces the costs and risks of security and quality issues in software. In particular, it provides some of the following benefits:
- Continuous source code quality and security assurance
- Tainted data detection and analysis
- Third-party code assessment
- Secure coding standard enforcement
I’ll go into more details on this in the third part of this blog series.
This is the first in a series of blogs about a four step process for quality and security assurance for IoT and M2M devices.
CONCLUSION:
In IoT and M2M systems, security must be designed-in and not added on, in order to avoid significant business risk and cost. A careful approach that includes understanding the attack surface of the device and using automated analyses, can greatly reduce this risk. Tools have an important role to play and Grammatech can help device developers build-in quality, security, and safety.
