A Great Supply Chain Security Forum

In this post from early October, I mentioned (toward the end of the post) a conference I’d just attended outside of Washington DC, called the Software and Supply Chain Assurance Forum (SSCA for short). It’s a free quarterly two-day conference sponsored by NIST, the Department of Defense, the Department of Homeland Security and the Government Services Agency (GSA). It is organized by MITRE Corporation and is always held at MITRE’s offices in McLean, Virginia. I intended to write a post soon thereafter providing all the details you need to get on their mailing list, both in order to hear about future conferences and for general information about supply chain security.

Well, “soon” has proved to be a month and a half, as I got diverted by other things, especially FERC’s approval of CIP-013. But yesterday I received an email announcing their next forum December 18-19, and I decided I really need to write this post now, since some of you may want to attend it (which I can’t do this time, although I will try to attend as often as possible in the future. BTW, there’s no webcast or recording – you have to attend in person).

I asked Bob Martin of MITRE, one of the organizers, to provide a short description of the forum and its history. To be honest, I thought this was probably some effort that had just started a few years ago, when I first heard a lot of talk about supply chain security. As you’ll see, I was quite wrong on that. Face it: the Feds were doing supply chain security long before a lot of us even heard of it. Here’s what Bob said:

“The Software and Supply Chain Assurance started in 2004 as the Software Assurance Forum and Working Groups, a free, DoD-focused public engagement effort to bring together the community on the myriad issues surrounding Software Assurance. The following year it became a joint effort of DHS and DoD, with a continued focus on engagement with industry, academia, and government, and was re-established as part of the Cross-Sector Cyber Security Working Group (CSCSWG) under auspices of the Critical Infrastructure Partnership Advisory Council (CIPAC).

During the first decade, the Forum had an emphasis on working groups to accumulate and promulgate best practices on the Software Assurance aspects of Technology, Processes, Education, and Acquisition. In 2008, the co-sponsoring partnership expanded to include NIST. Then in 2014, GSA joined as the fourth co-sponsor and the Forum refocused to more directly include Supply Chain issues, including renaming itself the Software and Supply Chain Assurance (SSCA) Forum.”

I do want to point out that, although the SSCA clearly started out with almost all Federal government employees and contractors as members, it now includes a significant industry contingent. And the discussions aren’t usually on specific government topics, but supply chain security in general. Here are the topics for the December meeting: the DHS Task Force on supply chain security, software security, software testing, software identification, software certification, international supply chain risk management efforts, updates to US Federal Government policies, and more.

You can sign up for the December meeting here. If you’re a non-US citizen or green card holder, you need to sign up by 12/4. If you’re a US citizen or green card holder, you have until 12/11. And if you want to get on the mailing list, drop an email to Bob Martin at ramartin@mitre.org.

Here are some interesting things I learned from the September meeting. They’re just in the order of the presentations where they were stated. Note that, even when I use quotation marks, I can’t vouch that this is a verbatim transcription of what was said.  

NIST:

CSF R1.1 has a supply chain focus.

800-53 R5 has a map to the CSF, as well as to 800-161 (the supply chain security framework).

800-37 addresses Enterprise Risk Management.

The Open Group:

The O-TTPS cyber security standard is for suppliers. It’s available as a certification.

DoE:

The CITRICS program is testing ICS components for security.

FERC:

Rhonda Dunfee of FERC pointed out that CIP-010 R1.6 just deals with software security patches, not firmware (even though CIP-013 R1.2.5 can be interpreted as applying to firmware as well as software patches).

Unknown:

“Many organizations fear the auditor more than the attacker.” (how true!)

“Software quality defects are really security defects, although the converse is not necessarily true. Quality and security defects are usually dealt with in separate efforts, although it would be better if that weren’t true.”

“If you talk to a CEO about risk, they’ll assure you they have that covered. What they usually mean is financial risk. If you talk to them specifically about operational risk (including cyber), they’ll give you a blank stare.”

Edna Conway of Cisco (a well-known supply chain security expert, and fun to listen to):

“Quality and security aren’t achieved through contract language….If you are dealing with your vendor in a courtroom, you’ve failed.” (how true that is! For my first post on this idea – there will be further posts, I can assure you – go here. There is a follow-up to that post here)

Office of the Director of National Intelligence (this was the best presentation, IMHO):

·         “The hard part in supply chain security is getting all the right people together, not the actual measures.”

·         A good tabletop exercise: What are factors that would make you say no or yes to a new business relationship?

·         “When it comes to SCS, there is no ‘easy’ button: ‘Just tell me what I need to do.’”

·         The Kaspersky threat has been known for a long time. The ODNI talked with supply chain people and warned them of this. But at the time they didn’t have evidence of malfeasance, so many government organizations (and private ones) signed up with Kaspersky anyway.

·         You can’t trade off advantages in cost or schedule for security performance.

·         SCS can’t be a compliance checklist approach; there must be risk mgmt. (how true this is! This is the point of the multiple posts – such as this one - that I’ve written on why CIP-013 R1.1 is the heart of the standard, while R1.2 is just a sideshow, although a mandatory one)

·         4 pillars of supply chain: cost, schedule, performance and security

·         “Security should be like quality. It should be expected all of the time.”

·         “It is not at all inevitable that added security increases cost.”

Howard Gugel, NERC (who spoke on CIP-013):

(in response to a question of whether CIP-013 addresses security risks from custom-developed software) “Those risks are covered in other CIP requirements, notably CIP-010 R3, the Vulnerability Assessment requirement.” I disagree with this, since having an every-15-month VA isn’t the same as having regular patches from a vendor, as new vulnerabilities are identified. This is one of the many risks that should be addressed – for those entities to which it’s applicable – in R1.1. But I haven’t heard NERC say much at all about R1.1 – the focus in everything I’ve heard has been R1.2, and on using contract language to comply with R1.2. IMHO, both of these emphases miss the whole point of the standard.

NCCIC (DHS):

Someone from NCCIC discussed the Russia attacks (about which I wrote a whole bunch of posts this summer, starting with this one), and pointed out that most of the entities compromised were small. This is all well and good, but that certainly wasn’t the tenor of the presentations they gave, even though perhaps they never explicitly said otherwise. It sounded like major utilities had been compromised, and it was just going to take one nod from Vladimir Putin to send the whole US into darkness. That was certainly the tenor of the major news articles, and I haven’t heard of DHS issuing any public (or private) apology for misleading the press on this matter.

This person also seemed to make yet another attempt to try to make sense of those contradictory briefings –as well as what was put out on the subject early this year – by saying that DHS just didn’t understand the difference between “vendors” and “utilities”. I believe we’re now on at least Version 5 of the ongoing saga “What DHS really meant in those briefings”. Unfortunately, this latest explanation is no more consistent with the actual statements than are any of the previous ones. I hope to do a post, summarizing what I understand of this sorry tale, in December.

Any opinions expressed in this blog post are strictly mine and are not necessarily shared by any of the clients of Tom Alrich LLC.

If you would like to comment on what you have read here, I would love to hear from you. Please email me at tom@tomalrich.com. Please keep in mind that if you’re a NERC entity, Tom Alrich LLC can help you with NERC CIP issues or challenges like what is discussed in this post – especially on compliance with CIP-013. We also work with security product or service vendors that need help articulating their message to the power industry. To discuss this, you can email me at the same address.