I've had a lot more questions recently about how to develop LabVIEW systems for secure environments. I put together this guide to summarize the existing resources and best practices for developing secure LabVIEW-based systems.
Here are a few resources to help your team develop secure LabVIEW applications for US Government projects.
Projects delivered to a US Government agency, and particularly Department of Defense or Department of Energy projects, must be awarded Authority to Operate, or ATO. Part of this process is a security review according to the Risk Management Framework process.
In this process, a security assessor will determine which requirements apply and evaluate how well those requirements are met. For projects that handle Controlled Unclassified Information (CUI), the requirements are described in NIST 800-171. For projects that connect to the Federal Network, the more detailed NIST 800-53 requirements apply. These are passed to companies as a clause for Federal contracts.
Both of these documents include the need to develop software according to a secure development process. NIST 800-218 describes a secure software development framework (SSDF) that must be adhered to.
All of these guidelines are written from an Information Technology (IT) perspective. Operational Technology (OT) systems have different needs, and NIST published NIST 800-82 to explain the differences between IT and OT systems and what considerations must be different for OT systems to provide safety and continuity which is different from IT systems.
LabVIEW code should be developed following a SSDF. A LabVIEW development team, like any other software development team, needs to review SSDF to determine how to apply this within the team’s existing processes.
Part of SSDF is the need to apply scanning during the development process. Scanning reviews code for coding practices that introduce risk and the use of components with exploitable vulnerabilities. These risks and vulnerabilities are captured as Common Weaknesses and Common Vulnerabilities.
As graphical code, most existing scanning tools do not properly scan LabVIEW code. A graphical scanning tool has been developed by JKI and is available as J-Crawler. For more information about J-Crawler, contact hunter.smith@jki.net. A presentation about this tool is available at https://www.youtube.com/watch?v=_N7Hk5nNBNc.
Alternatively, teams can use VI Analyzer (included with LabVIEW) to scan LabVIEW code for poor code quality, and add manual code reviews that look for common weaknesses. This has is accepted by some security assessors.
To help teams meet these security requirements, NI has prepared documentation to help teams develop secure LabVIEW code, and configure the deployed LabVIEW tools into the most secure configuration.
- LabVIEW Secure Code Development.pdf - This document is available from steve.summers@ni.com and attached to this post. This is an overview of tools in LabVIEW that support secure code development and how to use them.
- LabVIEW RTE Documentation.pdf – This document is available from steve.summers@ni.com and attached to this post. It reviews each of the 1,600 controls in NIST 800-53 to identify if the control applies to LabVIEW, and if so if it is met by the LabVIEW run-time engine or if the end user must apply configuration settings to meet the requirement.
- LabVIEW Secure Configuration.pdf – This document is available from steve.summers@ni.com and attached to this post. It lists all of the settings available to improve the security of a LabVIEW installation.
- LabVIEW RTE 2024 Install Analysis.pdf – This document is available from steve.summers@ni.com and attached to this post. It compares the state of a computer before and after installing the run-time engine. It is useful to see what components are installed and what services are started.
- LabVIEW SBOM – This is available under NDA from NI. Contact steve.summers@ni.com to start this process. This lists all of the components that install with LabVIEW, and all of the components used in the LabVIEW source code, including open source and 3rd party components. This is provided in CycloneDX format. Standard tools can ingest this format and compare the components to known component vulnerabilities to identify risks that must be mitigated by the software team.
Additional resources are available online at the Test System Security Forum. This site captures conversations about secure LabVIEW development, with additional presentations on secure development resources and practices. Some important posts from this forum include:
For more information about this topic, reach out to steve.summers@ni.com (Aerospace & Defense Security Lead) or security@ni.com (NI's security team).
