Test System Security

cancel
Showing results for 
Search instead for 
Did you mean: 

Security relevant VI Analyzer tests

Hello security friends,

 

I'm reviewing our default set of VI Analyzer tests and was wondering which tests could help to find potential security issues. It's known (at least in this forum) that static code analysis can help to improve cybersecurity, but for what exactly should I test?

 

Is someone already using VIA to find security issues and can give me a list or some tips, which tests are relevant? Or even share a VIA configuration with relevant test?

 

Thanks for your help 🙂

0 Kudos
Message 1 of 5
(145 Views)

This is a really good question, thanks for posting.

 

Most security regulations require that teams perform static analysis. But they do not specifically define static analysis, and they often include manual analysis as an option. So the generic version of your question is, what should we look for in a static analysis?

 

A couple of years ago, I spent time asking security teams about this question. Most of them directed me to either the top 25 CWE database (CWE - CWE-1387: Weaknesses in the 2022 CWE Top 25 Most Dangerous Software Weaknesses (4.16)), or the top 10 OWASP (OWASP Desktop App Security Top 10 | OWASP Foundation). A static analysis should look at these issues, at least. 

 

I put together the attached document analyzing each of these top 25 and top 10 issues, and how they relate to LabVIEW. I tried to include comments on how we might look for these weaknesses and how VI Analyzer might be configured to look for it.

 

We have not pursued this further. I'm not a VI Analyzer expert so I don't really know where the limits are of what VIA could actually find. But I'll put this here. If any of you put together a VIA profile, please let us know about it.

 

There is a good VIA community: VI Analyzer Enthusiasts - NI Community

 

There are two other options to consider. Tim Cannon created an open source tool that does basic static code analysis in LabVIEW. You can hear him talk about it in the post mentioned here: Security Tools for LabVIEW - TSS Oct 2024 - NI Community

 

And JKI has a full-featured static code analysis tool for LabVIEW called J-Crawler. Hunter reviewed it here: J-Crawler for LabVIEW Static Analysis - TSS Oct 2024 - NI Community

 

This is a critical area for LabVIEW developers, so if you have experiences that can help please comment here!

0 Kudos
Message 2 of 5
(130 Views)

Thanks for the helpful hints. I will take this as a starting point to build a security related VIA configuration and will post the results.

0 Kudos
Message 3 of 5
(119 Views)

Here are some security relevant VI analyzer tests. Rather than deeming whether a VI is safe or not, it just detects whether the functions are used or not and marks the test as a failure if used. That is meant to force the inspector to manually inspect the code. For example, if a transmission protocol such as Bluetooth, UDP, TCP, datasockets, etc are used, then it will mark as a failure making sure that someone manually inspects the code to ensure that either the data being transmitted is non-sensitive or that encryption/decryption is being applied outside of those functions. 

 

For the Hardcoded DB Credentials test, it checks if constants are connected to the username and password fields and marks them as a failure if they are there. 

 

For the OS Injection test, it checks if a constant is wired to command line input on system exec. If it does, it marks it as a pass. If not, that means it's either a control (could be passed in as a subvi) or is being manipulated through string manipulation functions, in which case it is asked that you manually inspect to ensure that an OS injection cannot occur or that inputs are properly being sanitized/checked.

 

In our use case, we are not using the VI analyzer UI to run these tests. We have a seperate static security testing GUI we've created, that runs only certain security VI analyzer tests. From here, we can run these and see which VIs fail. From the GUI, we can then just open up the VI in question. Lastly, we can certify that the code meets certain security requirements and rather than outputting the VI analyzer results, we are generating our own results programmatically. That way we don't report a whole ton of failures when there aren't actually security issues.

 

Feel free to modify these tests to suit your own needs as well. 

Message 4 of 5
(79 Views)

Actually, missed a couple of test. Here are some more protocols to be checked.

Message 5 of 5
(73 Views)