The mission of this group is to bring together utility professionals in the power industry who are in the thick of the digital utility transformation. 

Question

How important are the following items to determine the trustworthiness of a software package, before installation?

Richard Brooks's picture
Co-Founder and Lead Software Engineer Reliable Energy Analytics LLC

Successful developer of Energy Industry B2B and Cyber security standards at North American Energy Standards Board (NAESB) (www.naesb.org) since 1995; ANSI Meritorious Service Award Recipient;...

  • Member since 2018
  • 1,062 items added with 429,065 views

Using this scale, please answer the questions below:

5 = critically important/MUST HAVE

4 = important/SHOULD HAVE

3 = Not sure

2 = May not be important/MAY HAVE

1 = not important at all/NOT REQUIRED

  1. Identification of the original software source supplier/licensor:
  2. Verification of a digital signature applied to a software package:
  3. The ability to verify the trust relationship between the software supplier and the code signer, during digital signature validation:

Thanks for participating.

Your access to Member Features is limited.

Best Answer

Having been exposed to innumerable cybercrimes of late, especially during this unfortunate pandemic phase, it is of utmost importance to satisfy the source (supplier/Licensor); digital signature to the software (although common citizens cannot comprehend).  The simple feature currently available for right and wrong https –‘locked and unlocked sign’ could attract user’s trust prior to application. If the IT professionals could develop a simple tip like the one I mentioned, it would be highly appreciated.  I somehow cannot accept the fact that the Fraudsters are more intelligent than IT professionals who could plug some of these loopholes to safeguard the interest of users. There is no denial that IT has simplified many jobs through simple apps and I am sure they would come up with the right one for ‘Fraudsters’ as well.   The recent good news is that Cybercrime cops have saved Rs. 48 crores ( 1 Crore is roughly 140,000 US $) from fraudsters.  The moment one senses fraud, he has to immediately lodge a complaint with Cybercrime (Cybercrime Incident Report).  The complainant gets back the money with CIR converted to FIR to be submitted to the concerned bank.  

This needs to be treated at number 5-critically important.

Richard Brooks's picture
Richard Brooks on Jun 4, 2021

Thank you for your insights. FYI: I have received confirmation from the CAB Forum code signing work group that current software supply chain code signing and verification practices are unable to verify an authorized signer  - software supplier relationship on  a signed software package: CAB Forum confirmation email

Many thanks to the Energy Central Community for sharing your thoughts and insights regarding this very important matter.

Now, we can shift our focus to "finding solutions" per the recommendation from the CAB Forum:

As for the status quo – there’s not really something the CA industry can do right now but there’s acknowledgement that this is a real problem and innovation for finding a solution to the problem would be encouraged.

I look forward to working with the EC community on finding a solution.

Identification of the original software source supplier/licensor: 5

Verification of a digital signature applied to a software package: 5

The ability to verify the trust relationship between the software supplier and the code signer, during digital signature validation: 3

I've received a surprising amount of push-back from people claiming that this is not a real concern, stating that a digital signature on software is "good enough" to establish trust and I'm just spreading FUD. I disagree, this is like saying that an Executive Order signed by anyone other than President Biden "is good enough" and are just as enforceable as an EO signed by the President. My signature on an Executive Order does not make it valid. The same is true for a software package that is singed by anyone except the authorized signing party - either the source supplier or a verifiable "proxy" authorized by the source supplier. Any other digital signature on a software package should be rejected as illegitimate. A reliable verification mechanism is needed so that customers can verify the trust relationship between a software supplier and digital signer on a software package during digital signature validation. I agree with the conclusion and recommendations of the highly credible experts in the CAB Forum.

Thanks to all those that took the time to offer their viewpoint.

Roger Arnold's picture
Roger Arnold on Jun 6, 2021

Digital signatures are necessary but not sufficient. A verified signature does not prove that a software component is soundly designed, well implemented, and free of bugs. It needs to carry a certified log of design reviews, testing, and performance in the field. It needs a pedigree.

 

Richard Brooks's picture
Richard Brooks on Jun 7, 2021

I agree, Roger. You raise excellent points. I'm hoping we can go after the low hanging fruits first, like the ability for a SW customer to verify the trust relationship between an original software source supplier and a signing party during digital signature verification. The guidance for customer regarding digital signature verification on software is not just poor, it borders on negligence, IMO. Here's an excerpt from a NIST White Paper on software verification procedures:

3.4 Verifiers
Verifiers are responsible for validating the signature and any certificates and time stamps used by the signers. The verifiers also manage any trust anchors that are used to validate certificates. Either the signer or an independent party may be responsible for the verification component.

 

Validate signatures: The verifier must be able to validate the signature and determine that the public key associated with the signature can be chained back to an authorized signer. Note that in some cases, there will be no CA, and the public key determines authorization.

I have not found any specific guidance from an authoritative party, e.g. NIST, DHS, et al, advising a software customer on the proper method to verify the trust relationship between a software source supplier and software signing party during digital signature verification on software- which everyone seems to agree is an important step!

I encourage anyone that can point to to "HOW TO" guidance on this point to please post it here as a reply. Thank you.

For Q 1: 5

For Q2: 4

For Q3: 4

If you made this a forced choice, where only one answer could be used, I would make it:

Q1: 5

Q2: 3

Q3: 4

Alan

Richard Brooks's picture
Richard Brooks on Jun 5, 2021

Thank you.

I think the real question is upstream of questions 1-3: Question 0. -- What is the software/protocol? For example, IEEE2030.5 is a grid communications protocol adopted by the State of California for solar inverters, energy storage, and soon EV/grid communications to comply with Rule 21. It may have many developers for marketing purposes, but the underlying protocol has gone through extensive cyber testing (reportedly) and has a team dedicated to cyber security. That would seem to be an important question for other software packages.

Richard Brooks's picture
Richard Brooks on Jun 5, 2021

Thank you.

Identification of the original software source supplier/licensor:5

Verification of a digital signature applied to a software package:5

The ability to verify the trust relationship between the software supplier and the code signer, during digital signature validation:5

Richard Brooks's picture
Richard Brooks on Jun 2, 2021

Thanks for your insights.

Very important (5), of course.

 

And in addition to the software identity, device and data identity are the next security challenges which need to be mastered. Is it my grid IoT device whom I am talking to or receiving information from or some hacker that pretends to be the device? We therefore should work to create trusted device, data and software ecosystems in energy. This will be key to securely manage the ongoing decentralization of our energy system.

Richard Brooks's picture
Richard Brooks on Jun 2, 2021

Thanks - totally agree.

It's 5 (Critically important/ MUST HAVE) for all three questions, especially for OT applications used in Grid control. Utilities usually employ a third party cybersecurity risk advisory team to conduct an audit of vendor's development process, code verification steps and where the actual work is performed. The entire software development and verification cycle shall be regularly auditable by utilities. It's typical for OT applications like SCADA, OMS and ADMS to be developed and maintained in multiple development centers when major release is involved.

Richard Brooks's picture
Richard Brooks on Jun 2, 2021

Thanks for sharing your insights - I agree.

Identification of the original software source supplier/licensor: 5*

Verification of a digital signature applied to a software package: 5*

The ability to verify the trust relationship between the software supplier and the code signer, during digital signature validation: 5*

* Assumes I have no prior experience with the original software source supplier/licensor, and that the software will require installation (can't be run as an independent application). If neither of the above is true, only the first would be critically important.

Richard Brooks's picture
Richard Brooks on Jun 2, 2021

Thanks, Bob. I agree - and that is the most common scenario, people download SW from the Internet and will install it blindly - without knowing the real supplier, or the risks that exist in the SW, e.g. vulnerabilities and malware.

Bob Meinetz's picture
Bob Meinetz on Jun 7, 2021

Richard, reading through some of the responses I agree that people are too cavalier about verifying the source of their software. But there seems to be a mystique about SW security that is largely unwarranted.

The SolarWinds attack, and the compromise of 18,000 of the company's customers' accounts, was made possible by a single oversight - a ridiculously-simple password.

The latest spate of ransomware attacks are all the result of security holes in Microsoft Exchange Server.
 

Three simple protections:

1) Only permit pseudo-random passwords with at least 10 characters

2) Don't accept attachments with any email on a LAN

3) Don't use Microsoft software

are safeguards that security professionals have recommended for over a decade. IMO anyone who fails to conform, in 2021, is asking for it.

 

Tap Into The Experience of the Network

One of the great things about our industry is our willingness to share knowledge and experience.

The Energy Central Q&A platform allows you to easily tap into the experience of thousands of your colleagues in utilities.

When you need advice, have a tough problem or just need other viewpoints, post a question. Your question will go out to our network of industry professionals and experts. If it is sensitive, you can post anonymously.