Software Safety Keynote EuroSPI 2016

I was honored this week to have the opportunity to present a keynote session at EuroSPI 2016. The title of my presentation was “Software Safety and Security Through Standards” and I discussed one of my favorite soapboxes. That is the idea that software development is often less disciplined than it should be, but it doesn’t have to be. We can and should develop software as an engineering discipline.

One of the key ways to start down this path is to implement coding standards properly. Too many are trying to use coding standards late in the process as a way to find bugs, rather than a way to flag improper methods of coding early on. While the former is cool, the latter is far more valuable.

The adage that “you can’t test quality in a product” is well known, but for some reason in software we think that you can indeed test quality into an application. The same goes for application security, perhaps even doubly so.

In order to break out of the current cycle of code, deploy, fix, redeploy we have to start doing things differently. We have to build a more mature software development process and static code analysis is the way to build upon the body of knowledge and best practices available.

Slides are below. Let me know if you have comments, questions, suggestions. And thanks to everyone at EuroSPI and ASQ for putting on a great conference and allowing me to participate. These are great organizations to get involved with if you’re serious about software quality. I encourage you to check them out.

Keynote at EuroAsiaSPI2 2016 Conference

If you’re going to be in Europe in September, I’ll be speaking at the EuroAsiaSPI2 2016 conference in Graz, Austria on September 15th.

EuroAsiaSPI2 is also known as European & Asian System, Software & Service Process Improvement & Innovation. The EuroAsiaSPI² conference presents and discusses results from systems, software and services process improvement and innovation or SPI projects in industry and research, focusing on the gained benefits and the criteria for success. This year’s event is the 21st of a series of conferences to which international researchers and professionals contribute their lessons learned and share their knowledge as they work towards the next higher level of software management professionalism.

I’ll be speaking on Software Safety and Security through Standards

Abstract:
Software has moved from the desktop in just about everything we touch. From smart thermostats to infusion pumps to cars software is pervasive and growing. These so-called “things” from the Internet-of-Things are increasingly carrying more logic and with it a larger risk of failure. Many of these devices are using in safety critical areas such as medical and automotive where they have a particular potential for bodily harm.

Most companies that have been building devices rightly view current software development as an almost insane group of cowboys and chaos. But there is hope, software CAN and MUST be treated an engineering practice. Coding standards move us from the build, fail, fix cycle back into a design, build, deliver cycle with high quality, safety, and security.

As it turns out, these same standards also provide benefits in the areas of cybersecurity, doing double duty. We will explore how standards help us move from finding bugs to building more robust software, how to prevent problems in the first place by proper coding, and how to leverage the efforts of others by using common accepted industry standards such as MISRA to achieve this goal.

To attend you can register here.

Understanding Open Source Licenses

Open source projects come with a wide variety of license types. Some of them even conflict with each other. They include things like restrictions against commercial use, a requirement to distribute the source code, proper attribution, and more. If you’re using several different open source projects, it becomes an administrative headache to make sure you’re in compliance with the various licenses involved. Some projects even have multiple license choices and you need to understand which of the license you should choose and which you can ignore.

In order to minimize the risk and the effort to enforce compliance, it’s worth looking at the license associated with an open source project before adopting it. Some of the pitfalls include:

Pitfalls

Ambiguity: Some licenses can be ambiguous because they are drafted without benefit of professional legal advice. Make certain the terms fit the conditions necessary to your business. Just because a lawyer didn’t draft them doesn’t mean you can’t seek legal advice before using a project, so do it. This sounds like a lot more work than it actually is, because you don’t have to review every type of software license for every project you’re coding. You only have to review every license type that you want to use. Once you’ve accepted for example the MIT license (currently the most popular open source license) you’re ready for all projects that use open source components with that license.

Jurisdiction: Some licenses have a jurisdiction that may be inconvenient – for example if they software is governed by EU laws and you’re an American company this can be problematic if legal issues arise, whether around intellectual property or liability. In some cases, some licenses have omitted jurisdiction info leaving you open to challenges in venues that may be costly or difficult for your business.

Unintended open source: Some licenses such as the GPL require that all derivative works have the same restrictions as they do, meaning that you can be forced to open source your project if you use them. If you’re working on proprietary software this isn’t a viable option.

Patentability: While not all licenses conflict with traditional intellectual property rights such as patents, some of them do. If intellectual property (IP) is important to your business make sure the software licenses you use don’t restrict your rights.

Copyright: There was a court case a few years back over whether or not the owner of an open source project can enforce their rights against someone who uses their project. On appeal it was determined that they can. In other words, violating an open source license can be legally actionable in the United Sates – see Jacobsen v. Katzer.

License Types

Below are examples of some of the most common open source licenses in use. More detail can be found at https://opensource.org/licenses and advice on the different types of licenses can be found at http://choosealicense.com.

GNU GPL: Comes in many versions, currently GPLv3. This is called a “copyleft” to differentiate it from “copyright”. Using this license means that you must share the source code to your own work using the project under the same terms as the original project, for example making your own code available. Includes an express grant of patent rights from the contributors. Used by Bash and GIMP. This works well if your own project doesn’t get distributed, or if you don’t mind open-sourcing your own work.

GNU LGPL: Similar to GPL above, but makes a distinction between “based on” and “uses” to determine whether or not you have to share your own source code. “Uses” means you don’t have to share the code while “based on” means that you must.

Apache: Comes in multiple versions – currently v2.0. It’s a permissive license that lets you do pretty much whatever you want with the code as long as you don’t hold the contributors liable and provide attribution. Also contains an express grant of patent rights from the contributors. Used by Android and Apache.

MIT: Simple license that lets you do anything you want with the code. The only limitations are that you must provide attribution and you cannot hold the project or contributors liable. Currently very popular, used by jQuery and Rails.

Summary

In summary, vibrant active open source projects with reasonable licenses that are compatible with your business can be a great asset. Take the time before committing to a project to make sure that its licensing will work for you.

Hacking: Medical Devices

Hospital buildingYou have control over your own body, right? Well, scary scenarios in the healthcare industry are increasing in awareness. In the past, with the growth of technology, hacking was just for computers, but now it is expanding to other devices including medical ones. This is not technically “cyber crime”, but can easily turn into it when it falls into the wrong hands so I’m going to cover it anyways.

Internet of Things (IoT): “refers to scenarios where network connectivity and computing capability extends to objects, sensors and everyday items not normally considered computers, allowing these devices to generate, exchange and consume data with minimal human intervention. There is, however, no single, universal definition” (Internet Society, 2015).

The IoT is an important aspect in the healthcare industry (recently the term Internet of Healthcare Things IoHT was coined by medical field personnel). Examples include; heart rate monitors, pacemakers, medicine drips, MRI, etc. all that connect to the Internet and record information. As most of us know, objects that are connected to the Internet or have computer-type technology can be hacked. One example of this was two men in Austria hacked their morphine pump while admitted to the hospital to boost the dosage (Sarvestani, 2014). This resulted in one going into respiratory arrest and both men becoming addicted to morphine (Sarvestani, 2014). They were able to achieve this by retrieving the machine’s control codes online, this information typically can be found in the device manuals that are online for user reference.Hospira LifeCare PCA pump

A more streamlined, dangerous version of the morphine pump hack is what is known as MEDJACK. MEDJACK is a “medical device hijack” (Carman, 2015). How is this done? Don’t these hospitals have firewalls and preventative measures for stuff like this? Yes and no. While the network itself and it’s computers are protected with firewall and other security the devices themselves are not secured. According to Ashley Carman at SC Magazine “attackers maneuver though healthcare systems’ main networks by initially exploiting outdated and unpatched medical devices, such as an X-ray scanner or blood gas analyzer. They build backdoors into the systems through these internet-connected devices” (2015).

Another way that this is done is through a tool known as Shodan that is “used to scan open ports on the internet is often used by security researchers to uncover critical exposed infrastructure that should be better protected” (Murdock, 2016). According to a Kaspersky researcher in Jason Murdock’s article “[Shodan] can find out about the hardware and software connected [to the internet] and if you know, for example, what feedback an MRI or laser or cardiology device gives when you connect to its port, you can go to Shodan and find hundreds of these devices and if you know a vulnerability you can hack all of them” (2016).

istan medical mannequinUnfortunately, it gets worse. Pacemakers, including ones that are fully installed, are now on the list of hackable equipment. Students at University of South Alabama hacked into iStan, a simulated human being device (Storm, 2015). IStan has “internal robotics that mimic human cardiovascular, respiratory and neurological systems. When iStan bleeds, his blood pressure, heart rate and other clinical signs change automatically.” iStan, which is used by USA’s College of Nursing, breaths, bleeds from two locations, cries, secretes bodily fluids, speaks, groans, wheezes, gags, gasps, coughs and mumbles” (Storm, 2015) allowing it to fully respond as a human being. These students hacked into the iStan and were able to launch a brute force attack and denial of service (DoS) attacks which interfered with the devices ability to function, which in turn “killed” iStan (Storm, 2015). Another source discussing pacemaker hacking is Tarun Wadhwa on Forbes. Wadhwa discussed how pacemakers are vulnerable:

“Implanted devices have been around for decades, but only in the last few years have these devices become virtually accessible.  While they allow for doctors to collect valuable data, many of these devices were distributed without any type of encryption or defensive mechanisms in place.  Unlike a regular electronic device that can be loaded with new firmware, medical devices are embedded inside the body and require surgery for “full” updates.  One of the greatest constraints to adding additional security features is the very limited amount of battery power available” (2012)

Thankfully though, there has been no recorded incident of intended harm to another individual (and a very small amount of incidents of harm to oneself) through medical device hacking. The basics? If you can, do some research into the devices being used in your hospital room to see what vulnerabilities are available on the web (through how-to’s, videos, device manuals, etc.) and if at all possible, stay healthy to avoid the hospital- I wish this for everyone!

(THIS POST IS NOT INTENDED TO INDUCE FEAR, ANGER, OR ANY OTHER EMOTION TOWARDS MEDICAL PERSONNEL, STAFF, HOSPITALS, IT STAFF, EQUIPMENT DEVELOPMENT, OR OTHER GROUP OF INDIVIDUALS HANDLING, PRODUCING, USING, UPDATING, OR INVOLVED IN MEDICAL DEVICES)

[Editors note: Maybe it SHOULD though… induce fear that is. -The Code Curmudgeon]

References:

Carman, A. (2014, June 4). ‘MEDJACK’ tactic allows cyber criminals to enter healthcare networks undetected. SC Magazine. Retrieved from http://www.scmagazine.com/trapx-profiles-medjack-threat/article/418811/

Internet Society. (2015, October). The Internet of Things: An overview. InternetSociety.org. Retrieved from https://www.internetsociety.org/sites/default/files/ISOC-IoT-Overview-20151014_0.pdf

Murdock, J. (2016, February 15). How a security researcher easily hacked a hospital and its medical devices. International Business Times. Retrieved from http://www.ibtimes.co.uk/ho w-security-researcher-easily-hacked-hospital-its-medical-devices-1544002

Sarvestani, A. (2014, August 15). Hospital patient hacks his own morphine pump. MassDevice.com On Call. Retrieved from http://www.massdevice.com/hospital-patient-hacks-his-own-morphine-pump-massdevicecom-call/

Storm, D. (2015, September 8). Researchers hack a pacemaker, kill a man(nequin). Computer World. Retrieved from http://www.computerworld.com/article/2981527/cybercri me-hacking/researchers-hack-a-pacemaker-kill-a-man-nequin.html

Wadhwa, T. (2012, December 6). Yes, you can hack a pacemaker (and other medical devices too). Forbes. Retrieved from http://www.forbes.com/sites/singularity/2012/12/06/yes-you-can-hack-a-pacemaker-and-other-medical-devices-too/#5ab6b78313e0

Ranting about Software, Security and Tech