| |
Post navigation
Editor’s Note: The Practical SCADA Security Blog has a very special blog contributor this week – Mr. Santa Claus, owner and operator of a very large toy manufacturing facility at the North Pole. This is a very busy time of year for Mr. Claus, so we would like to extend a big thank-you to him for sharing his cyber security story with our readers. We would also like to thank him for having the courage to publicly share details of an SCADA/ICS security event that occurred at his facility.
Mr. Santa Claus’ Security Report
I don’t normally write blogs, and I especially don’t write security blogs – I am far too busy managing my toy manufacturing, packaging and shipping operation at the North Pole. But last year we had a serious security event in our workshop that really shook me, Mrs. Claus and the elves up. It also made me realize that anyone with a critical automation system needs to take security seriously. I decided to share our story so other people can learn from our mistakes. Read more »
Editor’s Note: This article was provided by Erik Schweigert, embedded systems developer.
Last week Eric Byres addressed the difference between SCADA, ICS and other jargon in our industry. This week I am going to address a question I am often asked “Why are industrial networks so hard to secure?” This is a big topic, so today I will address only “Why are PLCs so Insecure?”
The History of PLCs
Historically speaking, PLCs (programmable logic controllers) have been around since the early 1960s. The PLC started to be used shortly after the microprocessor was invented, as it allowed companies to replace the racks of relays that had previously performed industrial control. These panels of relays were difficult to modify, were hard to maintain and were a challenge to diagnose if a problem arose. Fixing a set of relays is a difficult task, especially since failures had the annoying tendency to happen at 3am!
Before PLCs racks of relays, like the ones shown above (circa 1965), controlled industrial automation systems. Source: XL Technology Systems. Read more »
This is an excerpt from the Think Forward blog by Ernie Hayden at verizonbusiness.com.
In a move that may be helpful for critical infrastructure asset owners, on July 23 the Industrial Control Systems Joint Working Group (ICSJWG) published a new document on a framework for disclosing Industrial Control System (ICS) vulnerabilities.
Common Industrial Control System Vulnerability Framework
Industrial Control Systems Joint Working Group (ICSJWG), which was established by the U.S. Department of Homeland Security Control Systems Security Program, published the document – Common Industrial Control System Vulnerability Framework. The document was developed with the intention of providing consensus-based guidance to vendors and system integrators in helping them create ICS vulnerability disclosure policies. Read more »
This is an excerpt from the Practical SCADA Security blog at Tofino Security.
Last week I discussed how security experts and ICS / SCADA vendors are giving up on the dream of the air gap as a viable security solution for the modern control system. Unfortunately, it is still all too easy to believe your control system is isolated.
Recently I had a very enlightening conversation with a control engineer who thought his system was air gapped. Read more »
Last week I updated my air gap blog from 2011. I noted some companies (like Siemens) no longer mention air gaps. Then to keep things balanced, I added new examples of consultants that support the air gap theory. In particular, I selected this quote from Paul Ferguson at Trend Micro:
“I’ve written about SCADA issues in the past, but one issue that I’ve consistently tried to emphasize is that critical control systems should never, ever interact nor interconnect with Internet systems in any way, shape, or form. There’s a good reason for this, and it’s always been referred to as the “Air Gap” Principle.” Read more »
Editor’s Note: This is an excerpt from the Practical SCADA Security blog at Tofino Security.
In last week’s blog, Professor Paul Dorey recently presented a paper about the seven important lessons the IT world has learned in managing Advanced Persistent Threats (APTs). In this article, I will discuss lessons #2, #3 and #4, and how to apply these lessons to ICS and SCADA security.
APTs have been discussed in some depth in previous blogs, so if you aren’t familiar with the concept (or need a review) check out Part #1 of this series. If you want real world examples of APTs, especially ones that have impacted the energy and chemical industries, browse some of my previous blogs on Nitro, Night Dragon and Duqu. Read more »
Recently a very complex worm called Flame has been discovered attacking companies in the Middle East, and it is an excellent example of what security experts call an Advanced Persistent Threat (APT). Figuring out how to defend against APTs is a major focus in the IT security world.
Now while Flame was busy attacking the Middle East, I was in Abu Dhabi at the International Cyber Security Forum for Energy and Utilities, listening to a talk by Paul Dorey called “Advanced Persistent Threats – A Real Problem with Real Solutions” (you can download his presentation at the end of this article). Paul’s talk focused on security for the IT industry, but there were important lessons on managing attacks in the ICS / SCADA world. I will focus on one of those lessons in today’s blog. Read more »
The discovery of the Flame malware last week focused the cyber security world on the sophisticated strikes targeting energy companies in the Middle East. Although Flame’s goal was espionage rather than damaging operations as Stuxnet did, it has been seen as one more indication that the industrial world is now in the bull’s eye of clever attackers.
On the heels of Flame coverage, this week David Sanger, the Pulitzer Prize winning Washington correspondent for The New York Times, released his new book “Confront and Conceal: Obama’s Secret Wars and Surprising Use of American Power“. Up to now, many writers speculated that the U.S. and Israel collaborated on Stuxnet. This book does not speculate; it builds a strong circumstantial case that these two countries did indeed create and launch Stuxnet against Iran. Read more »
Post navigation
|
|
