Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Database Security
Authentication
Mobile
Privacy
Compliance
Identity & Access Management
Security Monitoring
Advanced Threats
Insider Threats
Vulnerability Management
Comments
Large Electric Utilities Earn High Security Scores
Threaded  |  Newest First  |  Oldest First
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
5/29/2014 | 9:49:23 PM
Disruption Cause for Low and High Security
I think a very important piece to this article is why the lower level systems for utilities have small levels of securty.

"fear of disrupting the power supply or manufacturing process"

It is for this exact same reason that the perimeter needs to be so strong. Internally, fear of disrupting the power supply represents a critical concern. This is why it is not tampered with, don't want to knock out functionality by mistake. The disruption would detrimental to a mass amount of people.

In turn, imagine if a utilities company was exploited. The effect could be extremely detrimental to the public. Its funny to think about that the reason internal security is minimal is the precise reason as to why external security needs to be strong.
Bprince
50%
50%
Bprince,
 User Rank: Ninja
5/30/2014 | 10:57:46 AM
Re: Disruption Cause for Low and High Security
I agree. Compensating measures have to be taken to keep those older systems safe. That's why strong perimeter security is important. Honestly, I just think there isn't much more that  can be done to secure some of these systems other than reduce their connectivity to the Internet as much as possible, but that can hurt business productivity.  Happy to see the utilities scoring so high on this.

BP
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
5/30/2014 | 11:23:46 AM
Re: Disruption Cause for Low and High Security
I agree. I think we need to remember as InfoSec Professionals that there is a functionality principle that needs to be adhered to. What good is data security if your own trusted entities can't access it.

This is why security is strongest and most efficient when ingrained at the start of product development. And hopefully with the many regulations in place for different types of institutions vendors will take that into consideration.
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
 User Rank: Strategist
5/30/2014 | 1:19:35 PM
Re: Disruption Cause for Low and High Security
Agreed, @RyanSepe. The problem with many of these older ICS/SCADA systems is that they are old and predate the security threats we face today. Many were built for the pre-Internet days, so it's a legacy problem, too. 
Sara Peters
50%
50%
Sara Peters,
 User Rank: Author
6/2/2014 | 9:32:50 AM
Re: Disruption Cause for Low and High Security
@RyanSepe  "What good is data security if your own trusted entities can't access it. This is why security is strongest and most efficient when ingrained at the start of product development."  Couldn't agree more!


The trouble, of course, is that utilities -- for good reason -- aren't keen on updating their software, so even if we start building software that's got security beautifully baked in, they're unlikely to start using it.


 
RetiredUser
50%
50%
RetiredUser,
 User Rank: Ninja
5/30/2014 | 1:26:03 PM
Re: Disruption Cause for Low and High Security
I felt the same way as @RyanSepe but after researching and reading a couple excellent articles on the topic [1][2].

Some takeaways (assuming patches can be installed without shutting down the process) include:


  • "In a landmark study of the patches for post-release bugs in OS software, Yin et al showed that between 14.8% and 24.4% of all fixes are incorrect and directly impact the end user. And if that's not bad enough, 43% of these faulty 'fixes' resulted in crashes, hangs, data corruption or additional security problems."
  • "...patches don't always solve the security issues they were designed to address. According to Kevin Hemsley, a member of the Industrial Control Systems Cyber Emergency Response Team (ICS-CERT), in 2011, ICS-CERT saw a 60% failure rate in patches fixing the reported vulnerability in control system products."
  • "Most patches require the shutdown and restart of the manufacturing process. Some can also break or remove functionality previously relied on by the control system. For example, one of the vulnerabilities the Stuxnet worm exploited was a hardcoded password in Siemens' WinCC SQL database."
  • The patching process often requires staff with special skills to be available; resources aren't always on-hand or budget doesn't allow for them.
  • "At the SCADA Security Scientific Symposium (S4) in January 2012, Sean McBride noted that less than half of the 364 public vulnerabilities recorded at ICS-CERT had patches available at that time."

[1] https://www.tofinosecurity.com/blog/scada-security-welcome-patching-treadmill

[2] http://www.tofinosecurity.com/blog/patching-scada-and-ics-security-good-bad-and-ugly
Marilyn Cohodas
50%
50%
Marilyn Cohodas,
 User Rank: Strategist
5/30/2014 | 1:54:26 PM
Re: Disruption Cause for Low and High Security
Thanks for the info @ christianabryant. But honestly, the data you cite doesn't inspire a lot of confidence...
RyanSepe
50%
50%
RyanSepe,
 User Rank: Ninja
5/30/2014 | 5:15:38 PM
Re: Disruption Cause for Low and High Security
The first three bullets seem to advocate not patching while the others provide data as to why patching should occur.

But this is why risk analysis is so important. There is no absolute answer but what makes the most sense to you. Is the risk of patching acceptable versus the consequence of not patching?/Is the risk of patching acceptable versus the possiblitly of system shutdown during patch? I would say whichever merits the highest risk in the scenario above, this does not site other factors that should be taken into account, should be the option not taken. Thoughts?
jweiss950
50%
50%
jweiss950,
 User Rank: Apprentice
6/2/2014 | 8:04:58 PM
The comments and conclusions do not apply to control systems.
What makes a utility different than a commercial business are the industrial control systems that monitor and control the generation, transmission, or distribution of electricity (or water or natural gas). However, this article was written from an IT focus with little knowledge of control systems. Consequently, the statements and conclusions about security and resources may be relevant to the business IT systems in a utility but they are NOT relevant to the control systems. The comments on control systems seem to focus on patching as if that is the only or biggest problem - it is not. I encourage the readers to learn more about control system cyber security. I have written a book on the subject – Protecting Industrial Control Systems from Electronic Threats or you can view my lecture to a Masters class at Stanford - https://www.youtube.com/watch?v=S3Yyv53dZ5A

Joe Weiss
Kelly Jackson Higgins
50%
50%
Kelly Jackson Higgins,
 User Rank: Strategist
6/3/2014 | 3:54:01 PM
Re: The comments and conclusions do not apply to control systems.
If I'm following you, Joe, BitSight's report and analysis doesn't dispute that control systems themselves are notoriously security-deficient. This report was based on data gathered from malware attacks on networked systems of the large electric utilities. 
jweiss950
50%
50%
jweiss950,
 User Rank: Apprentice
6/3/2014 | 10:56:27 PM
Re: The comments and conclusions do not apply to control systems.
The mission of an electric utility is to generate, transmit, and/or distribute electricity. The means of doing that is with control systems.  Business IT systems are necessary for front-office business operations but not for the core mission of the utility. Unless you don't care if the lights are on, how can you make any conclusions on the security of an electric utility when you are not even looking at the control systems?  Moreover, since control systems are often networked systems, excluding them means the scope of the project was incomplete.

Joe Weiss


COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/2/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
The Threat from the Internet—and What Your Organization Can Do About It
The Threat from the Internet—and What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-9498
PUBLISHED: 2020-07-02
Apache Guacamole 1.1.0 and older may mishandle pointers involved inprocessing data received via RDP static virtual channels. If a userconnects to a malicious or compromised RDP server, a series ofspecially-crafted PDUs could result in memory corruption, possiblyallowing arbitrary code to be executed...
CVE-2020-3282
PUBLISHED: 2020-07-02
A vulnerability in the web-based management interface of Cisco Unified Communications Manager, Cisco Unified Communications Manager Session Management Edition, Cisco Unified Communications Manager IM & Presence Service, and Cisco Unity Connection could allow an unauthenticated, remote attack...
CVE-2020-5909
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, when users run the command displayed in NGINX Controller user interface (UI) to fetch the agent installer, the server TLS certificate is not verified.
CVE-2020-5910
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the Neural Autonomic Transport System (NATS) messaging services in use by the NGINX Controller do not require any form of authentication, so any successful connection would be authorized.
CVE-2020-5911
PUBLISHED: 2020-07-02
In versions 3.0.0-3.5.0, 2.0.0-2.9.0, and 1.0.1, the NGINX Controller installer starts the download of Kubernetes packages from an HTTP URL On Debian/Ubuntu system.