Skip navigation
All People > Bryan Owen > Bryan Owen's Blog > 2017 > July
2017

Anti-virus has been declared dead many times.  Makers of AV engines themselves even say so.

 

Why?  Because AV is a feedback control. There is always some lag time as AV isn't really designed to protect patient zero. Modern viruses mutate on the fly and as a result traditional AV effectiveness is quite limited. 

 

Whitelisting approaches, like Applocker, emerged as the heir apparent to protect computers from malware. What a great idea! Enumerate what's known good on a machine and just block everything else.  No more feedback lag issue and performance is much more deterministic.

 

If you have yet to adopt whitelisting it's easy to get started. Start small, even the default path based rules are quite effective and flexible enough to accommodate normal changes that occur on a computer.  Still gun shy? Start in 'audit' mode and monitor the logs for unexpected warnings.

 

Deploy stronger rules as appropriate for more important systems.  See KB00994 for OSIsoft technical support guidance on Applocker.  Similarly we look forward to constructing a new KB for Device Guard as Windows Server 2016 deployment becomes more common. Please contact me if you have interest in exploring Device Guard in collaboration with OSIsoft.

 

While AV isn't as good as it once was, AV is reinventing itself. This article describes a new cloud based feedback loop for Windows Defender. 

Windows Defender Antivirus cloud protection service: Advanced real-time defense against never-before-seen malware – Wind…

Checking file hashes with the cloud is bound to make a difference. We'll want to see how this performs and of course there are interesting questions about blindly allowing any file to be uploaded to the cloud but the design change is full of good promise.

 

In closing, the future for Anti-Virus looks quite optimistic thanks to the cloud.  We may even see this approach pivot AV into a turnkey whitelisting solution.

This 'Coffee Break' scenario is all too likely today. Technical support and their remote monitoring system are heroes in this story!

https://www.reddit.com/r/talesfromtechsupport/comments/6ovy0h/how_the_coffeemachine_took_down_a_factories/

 

I also like the gentle reminder that control system networks are vulnerable to run of the mill malware for many reasons:

  • out of date platforms
  • fragile application software
  • regulatory burden and procedures
  • false sense of security in perimeter defenses

 

Fake news, or perhaps not, you can decide. Like most coffee break stories however, this one is just crazy enough to pause for a moment. Just how exposed are your systems?  The internet is increasingly accessible and enabling IoT.  Protecting control networks from the corporate network is hard enough.  Innocuous items like coffee makers, refrigerators, and televisions make this job even harder.

 

In the meantime you might appreciate insight from the OSIsoft User Conference panel discussion on security in your IoT networks.

Security in your IoT Networks - Panel Discussion

The revised NERC CIP-013 draft standards for Cyber Security Supply Chain Risk Management appear on course to meet FERC’s deadline.  However, FERC itself appears to be in transition with Acting Chair Cheryl LaFleur as the lone commissioner. Nominations for commissioners and confirmation dates are unclear at this time (as is climate for increased regulation).

 

LaFleur was the dissenting opinion on the commission’s decision to proceed to final rule last July. In reviewing comments associated with the CIP-013 second ballot it seems some of LaFleur’s concerns have come home to roost. “The Commission is issuing a general directive in the Final Rule, in the hope that the standards team will do what the Commission clearly could not do: translate general supply chain concerns into a clear, auditable, and enforceable standard within the framework of section 215 of the Federal Power Act.”

Clear? The standards drafting team has been asked to clarify terms as basic as “Vendor” and abstract as “System to System Remote Access”. For instance: When is a contractor a vendor? Should vendors of electronic access points, associated protected cyber assets, and requisite operating systems be in scope? Does system to system remote access include “read-only” access?  Is the intent to include all connections in and out of the NERC CIP-005-6 Electronic Security Perimeter?  Clarity on these topics is critical for us to provide services and develop products with system to system communication such as PI Connectors.

Auditable? CIP-013 interpretation depends largely on the Implementation Guidance document. However there is little assurance the separate document will be adopted by NERC and all regions. Furthermore, additional examples of acceptable evidence should be provided.  For instance, what is acceptable when there is no method available to verify the identity of the software source?

Enforceable? Enforceability of CIP-013 is a hot topic.  NERC CIP maven Tom Alrich’s Blog has featured several recent articles on this topic. Spoiler alert: ‘unenforceable’ is trending.

OSIsoft comments on the revised standard

The ‘NotPetya’ worm reminds us, again, that cyber security supply chain risk is real and can be particularly devastating.  In this case, the updater for M.E. Doc tax software, a popular and widely distributed package in Ukraine, sent the worm on its destructive mission.

Procurement aspects of CIP-013 are complex and flawed. Let’s face it, contract terms are far and away removed from critical grid operations thus, unlikely to drive change at a pace that is needed.  For the moment I believe FERC should drop CIP-013 and focus on clarifications in supply chain updates to Electronic Security Perimeters (CIP-005-6) and Configuration Change Management and Vulnerability Assessments (CIP-010-3).

FERC should seek additional outreach with the Industrial Control System ecosystem.  This effort should be part of a larger cross sector approach. Perhaps Mark Holman, PJM Interconnection says it best:

“In order for supply chain risks to be substantially mitigated it will require broader cross sector engagement, broad government engagement and a significant shift in how vendors and service providers deliver products and services.  Broader engagement is also required to ensure an equitable allocation of liabilities and costs.”

In the meantime, closing protection gaps in the security perimeter and bolstering change management to better address supply chain risk should be a priority across industry. We can best advance critical infrastructure protection objectives through collaboration. Part of that involves clear communication about software supply chain risk which is a focus of our Ethical Disclosure policy. Perhaps there is a silver lining for voluntary approaches!