Comment from Jake Brodsky
Time: September 17, 2007, 3:04 pm

Dale,a silent fix has no place in a control system, especially when you must use licensed operators to run the system.

It’s the operator’s and plant superintendent’s certification at stake. Not mine, not yours, not anyone elses. We are obligated to report all changes we make to a plant so that they’re aware of where we’re working, and what systems may behave differently.

Silent updates have no place anywhere in this scheme of things. Whatever solutions we may reach to update the control system, they must be validated. You can’t validate a silent fix.

This is one thing which I think ought to be legislated. There shall be no silent fixes on a plant. Operators are entitled to know who is doing what to the plant or distribution system at all times.

Comment from Ralph Langner
Time: September 17, 2007, 4:06 pm

Silent fix is what may be called “best practice” for today’s standards when it comes to vendors fixing vulnerabilities. So that’s that, as Forrest Gump used to say. There is a comparatively simple way of getting past this practice for asset owners: Use the goddamn Cyber Security Procurement Language from INL (or something similar) in your buying contracts. Liability is the only one piece in the puzzle that will change things in short term.

Comment from David
Time: September 18, 2007, 9:07 am

A good configuration management plan starts at procurement. At least have some language that states minimal security requirements (or perhaps open communication about security), and then move to requiring products to be certified by an external, trusted source before you will purchase them.

And this isn’t ground breaking new stuff, it should be industry standard/best practice.

“There is a comparatively simple way of getting past this practice for asset owners: Use the goddamn Cyber Security Procurement Language from INL (or something similar) in your buying contracts. Liability is the only one piece in the puzzle that will change things in short term.”

X2

David

Comment from David
Time: September 18, 2007, 9:19 am

Does the CIP standards address Service Level Agreements or Memorandums of Understanding?

A quick google didn’t return much.

This document, published back in 2002 has some of the basics for vendor management of interconnected systems.
http://csrc.nist.gov/publications/nistpubs/800-47/sp800-47.pdf

I’m sure the New CIP will address this…I must have just missed it in my quick search.

David

Comment from David
Time: September 19, 2007, 1:08 pm

So, I continued reading and was quite surprised to find out what was in the CIP documentation. There isn’t much that would help an asset owner stop the silent fix.

CIP-003-1 R6
This section discusses the configuration management plan.
And by my interpretation it seems like, in the case of the silent fix, the standard expects the asset owner to be vigilant in the application of security fixes.
Therefore, without further guidance for the management of the owner/vendor relationship, asset owners are expected to build relationships through which they gain all the necessary information needed to make informed configuration management changes.

Now, in CIP-004-1, a discussion of personnel, sheds some light on this silent fix issue.
It directs that contractor/vendor personnel with cyber access to critical cyber assets are required to “have an appropriate level of personnel risk assessment, training, and security awareness.”
Other then the ambiguous term, “appropriate level,” it looks like asset owners should be requiring software providers (who have cyber access to critical cyber assets) to exibit security awareness.
Section R3 requires a Personnel Risk Assessment. Perhaps this is an area where the asset owner can hold the vendor responsible for disclosing all security fixes. If their personnel are not demonstrating security awareness, and placing the asset owner at risk, then they could be held accountable for the repercussions of the silent fix.

CIP-005-1
This section identifies the controls for a secure perimeter. Here is the perfect spot for documenting the SLA (service level agreements) and MOU (memorandums of understanding) for interaction between vendors and asset owners…with the goal of preventing the silent fix.
Develop a procedural and political (through policy) security perimeter. Treat the “link” between the vendor and the asset owner as un-trusted…as if it were outside a firewall, and require that all interaction be governed by rules.
To have a section that discuses premier controls and fails to address third party interactions is vulnerable to attack…by design.

CIP-007-1 puts the onus back on the asset owner for testing security patches and making sure that they do not adversely affect security. It seems like an asset owner who is diligent in implementing its CIP-007-1 compliant process will catch silent fixes. Any change governed by CIP-003-1 R6 will result in a document that details the changes and the results of tests. It seems like tests would be expected to catch silent fixes.

It seems that stopping the silent fix is on the asset owner. There is no requirement to document and specify the “rules” for interacting securely with vendors. If a vendor is going to sneak in security fixes into upgrades or updates then the asset owner must look for them, express extreme dissatisfaction when they find them, and use their dollars (where ever possible) to force vendors to operate in a manor that does not place them in a compromising security position.

David