Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Endpoint

10/19/2015
11:00 AM
Lev Lesokhin
Lev Lesokhin
Commentary
Connect Directly
Twitter
LinkedIn
RSS
E-Mail vvv
50%
50%

Secure Software Development in the IoT: 5 Golden Rules

The evolving threat landscape doesn't merely expose developers to new problems. It exposes them to old problems that they need to address sooner, faster, and more frequently.

Smart hardware is only as good as its software. Manufacturers have known for a long time that putting "glitchy" software on-board devices is asking for trouble. We’ve seen countless examples of violations of good coding and architectural practices that cause an application to be less reliable and less secure.

In the Internet of Things, this can be downright dangerous. If the smart device is a light switch that turns on when you enter the room, badly written code might result in a stubbed toe. But if it’s a "smart" smoke alarm, fire sprinkler system, or a pacemaker (which can typically contain up to 100,000 lines of code), human lives may be on the line.

The evolution of the landscape is not really creating new problems. Rather, it is exposing developers to problems and capabilities of which they are already well-aware -- at least in some circles. For example, enterprise and web developers are very familiar with the need for robust security against local and remote attacks. The notion of input validation as a first line of defense is well accepted in connected systems today. But IoT development is expanding the scope of those concerns in that embedded, device, and mobile developers now need to start considering security challenges such as input validation during development because it will be too costly to redesign onboard systems to include these defenses after they have been shipped.

In the IoT ecosystem, first-to-market is a competitive driver, and developers will be under further pressure to get products released. However, this could mean sacrificing quality and dependability for speed -- already an issue in many software-intensive environments today. Despite developers’ best intentions, management is always looking for short cuts. Third-party components help offload some of the burden, but in the IoT, with more complexities and upkeep, components will need to be maintained and updated to address problems, like security vulnerabilities, much faster. To meet those demands, developers need to institute several “golden rules for IoT”:

Rule #1: Make proper code review and repeat testing a priority. Manufacturers will need to communicate this message to development teams and call for stricter software quality measures. One bad miscommunication between an application, a sensor and a hardware device can cause systemic failure. 

Rule #2: Software assurance is more critical than ever. Continuous deployment in the connected world will be business-as-usual. Updates will occur non-stop and will often be pushed, perhaps multiple times a day. If the software isn’t continuously monitored and the code evaluated, this almost certainly guarantees failure.

Rule #3: Management must take responsibility for software risk. One way to evaluate issues like reliability, security, or performance at a high level is through analytics that loop business leaders into where the vulnerabilities lie, in order to protect customers and meet the company’s fiduciary responsibility to shareholders. Another way is through benchmarking. Knowing the baseline starting point and comparing it to industry performance provides fact-based insight.

Rule #4: Up the game for structural quality analysis. For some enterprise IT developers, this might be a familiar environment, especially if they are running mission-critical systems, like a utilities provider or a bank. But, ordinary app and device software developers could suddenly find themselves needing to take much more rigid precautions, such as the same degree of structural quality analysis and code review required by software engineers for airline autopilot systems.

Rule #5: Make software quality and security education a priority. We all need to evangelize the fact that security vulnerabilities caused by poor coding or system architectural decisions can be some of the most expensive problems to correct.

A significant standards initiative surrounding quality will provide manufacturers and IT departments with a consistent way to measure the quality of their software. The Object Management Group recently approved a set of global standards proposed by the Consortium for IT Software Quality (CISQ) that would help companies quantify and meet specific goals for software quality. CISQ’s measurement standards include security, reliability, performance, and maintainability. This will allow businesses to certify the quality of their codebases and IoT networks.

By its nature, size, and complexity, software is almost impossible to completely protect from disruptions and breaches. In the IoT, those complexities will expand. Understanding the importance of a secure architecture foundation and insisting that developers comply with industry standards will be the first line of defense. After that, you’re on your own. 

Lev Lesokhin is executive vice president of strategy for CAST. He is responsible for market development, strategy, thought leadership and product marketing worldwide. He has a passion for making customers successful, building the ecosystem, and advancing the state of the art ... View Full Bio
Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
Florida Town Pays $600K to Ransomware Operators
Curtis Franklin Jr., Senior Editor at Dark Reading,  6/20/2019
Pledges to Not Pay Ransomware Hit Reality
Robert Lemos, Contributing Writer,  6/21/2019
AWS CISO Talks Risk Reduction, Development, Recruitment
Kelly Sheridan, Staff Editor, Dark Reading,  6/25/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
Building and Managing an IT Security Operations Program
As cyber threats grow, many organizations are building security operations centers (SOCs) to improve their defenses. In this Tech Digest you will learn tips on how to get the most out of a SOC in your organization - and what to do if you can't afford to build one.
Flash Poll
The State of IT Operations and Cybersecurity Operations
The State of IT Operations and Cybersecurity Operations
Your enterprise's cyber risk may depend upon the relationship between the IT team and the security team. Heres some insight on what's working and what isn't in the data center.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2019-1619
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to bypass authentication and execute arbitrary actions with administrative privileges on an affected device. The vulnerability is due to improper session ...
CVE-2019-1620
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to upload arbitrary files on an affected device. The vulnerability is due to incorrect permission settings in affected DCNM software. An attacker could ex...
CVE-2019-1621
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to gain access to sensitive files on an affected device. The vulnerability is due to incorrect permissions settings on affected DCNM software. An attacker...
CVE-2019-1622
PUBLISHED: 2019-06-27
A vulnerability in the web-based management interface of Cisco Data Center Network Manager (DCNM) could allow an unauthenticated, remote attacker to retrieve sensitive information from an affected device. The vulnerability is due to improper access controls for certain URLs on affected DCNM software...
CVE-2019-10133
PUBLISHED: 2019-06-26
A flaw was found in Moodle before 3.7, 3.6.4, 3.5.6, 3.4.9 and 3.1.18. The form to upload cohorts contained a redirect field, which was not restricted to internal URLs.