Best Practices for Applying Standards to Your Product Development

DornerWorks
2 years ago
Categories: Blog
Tags: cybersecurity, Product Development, standards

An essential part of the software development lifecycle consists of integrating best practices and compliance standards throughout the development of a system. Identifying the proper standards and understanding their impact is essential to building a stable, compliant, and secure system. The consequence of not integrating standards into your system means unsecure products will be released. For example, researchers discovered a vulnerability in an Insulin pump which opened the door for cybercriminal to issue the wrong dosage to the patient. Most likely this could have been avoided by integrating some cybersecurity standards in the evaluation of these devices. This example highlights the main goal of integrating compliance into the development process which is to ensure the security and integrity of the systems that are being developed.

Consequences of Non-Compliance

The costs of non-compliance are real millions of dollars and loss of company reputation being some of the consequences. The diagram below shows the impacts and effects to noncompliance. As the amount of quality issues or non-compliance increases there is significant effects to the share price.

Some Common Standards

There are many standards that exist but for the purpose of this article we will explore some of the common ones that affect embedded systems, internet of things (IoT), and medical data. Typically, these standards have a governing body that sets the rules and hears comments when developing and revisions are made. For example, the National Science Institute of Standards and Technology (NIST) is a US government agency that outlines “standards, and technology in ways that enhance economic security and improve our quality of life.”

Many standards are regulatory in nature and serve a specific role in how data, security principles, and is usually used by industry or government to mandate how data is stored. Other standards or frameworks outline how data should be stored and promote best practices in how data maturity could be achieved.

Some Common Medical Standards

For the medical industry some common Standards include:

ISO 9001:2015 – “Quality Management System: Requirements” — the underpinning of everything our Quality Process is built on
ISO 13485:2016 – “Medical Devices: Quality Management Systems: Requirements for regulatory purposes” — Defines the Quality Management System requirement for Medical Devices
IEC 60601-1:2005+AMD1:2012AMD2:2020 – “Medical electrical equipment – Part 1: General requirements for basic safety and essential performance” (and Family – for various specific aspects of Electrical Design) — Provides requirement for producing safe hardware for Medical Devices
IEC 62304:2006 + AMD1:2015 – “Medical device software: Software life cycle processes” – Provides requirements for the Software Development Life Cycle for performing risk-based Development of Medical Devices for Safety and Security
ISO 14971:2019 – “Medical Devices: Application of risk management to medical devices” Defines how to perform full Life Cycle Safety Risk Management for Medical Devices
AAMI TIR57:2016: “Principles for medical device security” – defines a synergistic process parallel to 14971 for performing Security Risk Management for Medical Devices
Content of Premarket Submissions for Management of Cybersecurity in Medical Devices, 10/2018 Draft Guidance
Post market Management of Cybersecurity in Medical Devices, 12/2016, Final Guidance
HIPAA “establishes national standards to protect individuals’ medical records and other individually identifiable health information”

Some Common IoT Standards

For the IoT industry some common Standards include:

Some Common Embedded Systems Standards

There are several Standards that would overlap with IoT and Medical systems but others that deal with embedded devices including:

NIST 800-57 specifically in how to deploy encryption keys to devices
NIST 800-71 Recommendations for Key Establishment Using Symmetric Block Ciphers
NIST SP 800-131A Transitioning the Use of Cryptographic Algorithms and Key Lengths

Selecting a Standard

It is important to choose a standard that not only may offer guidance on the development of the system but also covers all the regulatory checkboxes. There also may be overlap in a project that requires several Standards to be used as in a health-related embedded system device. For example, you may develop a product that supports secure boot and stores personal health information thereby necessitating serval standards to be used including RSA-4096 and HIPAA.
We have identified some questions to help this process including:

What are the customer’s requirements?
What types of data will be used?
What is mandated by regulatory bodies?
What other best practices exist to guide the proper development of the system?

Using these questions, determine what standards should be chosen to apply to the project. Another factor to consider in Medical is that most standards are “Recognized Consensus Standards.” Using a RCS can make your regulatory pathway easier, but if you claim to adhere to it, any failure to comply may make your entire submission suspect. Choose carefully!

It is also important to determine what impacts that standard will make to the development process. If any of these standards change during development or after the development of the system, it is important to outline how you deal with those changes and adjust as necessary.

Integrating Standards into Development

Because of their impact to the development of a system it is necessary to ensure significant time is spent on reading the framework to understand the implications and process maturity of those standards. Reading a framework may often be monotonous but with a proper understanding it also be rewarding. We suggest a few steps to make this process go well.

We suggest a 4-part integration phase of compliance as shown in the following chart.

The first thing we suggest is to identify the product requirements for the system being developed and how it relates to specific standards. This can be a very time-consuming process as you don’t just what to comply you also need to remember the long-term impacts of any changes that are made, and you want to think of how you can exceed those compliance requirements.

The second step is to identify the standard and how to meet the standard. This will take understanding the context, terminology, and reasoning behind a standard it can be helpful to listen to webinars, conferences, and audio clips relating to the standard you are learning. For example, having an underlying knowledge of authentication and encryption principles helps to understand the motivation behind some of these requirements. You don’t need to be the field leading expert but understanding the common protocols and how they work to secure software/data helps to wade through the documentation.

This information gathering step will give you foundation and knowledge to start asking questions from industry forums and other organizations about how a standard relates to the process and code you are integrating. There is a high likelihood that other people have asked related questions and it is helpful to reach out to people that were going through similar framework development.

The third step is to integrate this throughout the development lifecycle. Integration that occurs immediately is a good place to start. For example, if the AES encryption used to develop the software on the device is required to be 256 bit or larger this is essential to build into the requirements of the project. Many of the NIST 800.X* Standards require forms of FIPS validated encryption technology and it is vital that hardware is chosen that aligns with these Standards.

More mature software development lifecycles may build in continuous integration that checks for these practices at every stage in the process. It can be helpful to build in automated processes that identify how a system compares to a standard. For example, building scripts that check for the encryption keys or security of a code helps automate the process or using industry tools to check for compliance to a framework. A suggested frameworks is the Red Hat DevSecOps Framework (diagram below)

This framework builds in compliance throughout the process and may be helpful to adopt in a development process.

A final step to this process is responding to changes in the compliance standards and identifying how they related to system changes. As standards often change this is a continual process. Staying up to date with the latest publications is equally as important as developing a product with the flexibility to adjust some of the requirements called out in the documentation. For example, if encryption protocols only use one type of mechanism to deploy encryption, then that product is likely to become obsolete and require more development.

Conclusion

The goal of integrating compliance into the development process is to ensure the security and integrity of the systems that are being developed. Keeping this the focus and understanding why we apply a standard instead of thinking of standards as a checkbox we should see standards as guideposts that help us keep systems safe.

DornerWorks engineers Dan Rittersdorf and Michael Doran contributed to this blog.

Visit Our Site