SANS Attack
I tried to let this one pass, but failed … From today’s opening paragraph in the SANS newsbite:
SCADA security issues are no longer theoretical. At the SCADA Security Summit last week, asset owners spoke publicly (for the first time) about actual security breaches in water treatment plants and power distribution systems. It is time for NERC and FERC to refocus their rules to fix the actual problems or admit they cannot, and get out of the way.
I know SANS is a big dog in security, but even big dogs shouldn’t lob ad hominem attacks like this. This newsbyte gets emailed to 1000’s of people inside and out of the SCADA world. What are examples of NERC CIP requirements that wouldn’t fix actual problems? What would SANS have NERC eliminate as a requirement? As I read the NERC standards they define a solid information security program. Are they perfect? No. For example there are not requirements to protect information sent between two electronic security perimeters, but it is hard to imagine any bulk electric entity meeting the requirements and not substantially improving their security posture.
Is the timetable a bit longer than I would like to see? Yes. And I’ve blogged before that I’m concerned about the rigor and independence of the audits.
Why focus on electric? NERC CIP is one of the only true SCADA security standards documents with requirements that can be audited. What about oil & gas, water, chemical, transportation?
If there is detail and substance behind that “fix or get out of the way comment”, I’d be very interested to hear it. And by the way, there was little detail at the Summit on any breaches and that level of detail is not new or especially helpful.
So after all this complaining here is my suggestion for SANS. SCADA engineers and other SCADA professionals need to build their basic IT security skills (just like IT security needs to understand SCADA). SANS has a lot of courseware in this area, and could be a big help in accelerating the community on this learning curve. This may just be promoting the Security Essentials course to the SCADA community, or perhaps a slightly modified course with more applicable examples for the community.
UPDATE - a retraction of sorts from SANS NewsBites:
–SCADA Security: Authoritative Commentary from a Utility Security Professional
By Michael Assante, Idaho National Laboratory and previously CISO, American Electric PowerElectric sector utilities and organizations have been working hard to understand and address the risks associated with critical systems. It is too easy to criticize or draw conclusions if you are an observer and not participating in the process. The NERC standards drafting team had to deal with complex challenges but their knowledge of technology, security, and utility operations were instrumental in laying a strong foundation and achieving the first step forward. The foundation they built spans the diverse range of existing technology and security by setting a starting point for all organizations interconnected to the electric system. Building upon this foundation has already begun with additional efforts to improve the security of current and future technology. One important example is the control system security procurement language project. It is a partnership among asset owners, control system vendors, researchers and government officials in multiple countries. It is attempting to contribute meaningfully to the work being done across all control system dependent industries. Many of the entities working to implement the electric sector cyber security standards have made important contributions to the procurement project.
The cyber security problem is large enough that no single effort can effectively address the risk we face. As a member of the procurement project, I am challenging everyone to participate and build upon existing and important work to further enhance the security of our critical infrastructures.
[Editor's Note (Paller): A few days ago I called into question the value of the work done on the NERC cybersecurity standards. Mr. Assante is much more engaged in the electrical industry than I am; he gets the last word.]
Author: Dale Peterson
Posted: October 7th, 2006 under NERC CIP, SANS.
Comments: 7
Comments
Comment from WATER SCADA SYSTEM ENGINEER
Time: October 4, 2006, 2:22 am
HI Dale,
Don’t take it all too much to heart SANS is trying to raise awareness involvement and interest in the community.
This is difficult as there is very little new public material to use and everyone is trying to get the message out without giving away any cards.
The truth is everyone does have to eat, The commercial realities are still there and at times they all get a little blury one way or the other.
Keep up the good work and don’t let it get you down
I got really cranky about some of the statements in a previous newsbyte because of the quality of the disclosure but the intent is good?
WATER SCADA SYSTEM ENGINEER
Comment from Anonymous
Time: October 4, 2006, 9:21 am
I would also like to know what caused SANS to make this kind of attack.
I’m not pleased with SANS at the moment.
Comment from Anonymous
Time: October 4, 2006, 12:13 pm
” I would also like to know what caused SANS to make this kind of attack.”
How else do you start to position yourself as the “Go To” organization that will provide you with all the knowledge and tools that you will need to secure your SCADA/PCS/DCS, etc. etc. The NERC CIP Standards are not perfect nor all encompassing, however, in some cases something is better than nothing. It should also be stated that NERC has been working on these standards for years (1200, 1300)and they are being developed by industry members. SANS should leave the FUD (fear uncertainty doubt) out of their marketing arsenal and focus on providing useful and applicable security training.
I am tired of hearing about what’s wrong. Stopping pointing out the obvious. Provide me with some solutions and please don’t tell me that it exist in this “little box”. There is no silver bullet!
Comment from Jake Brodsky
Time: October 5, 2006, 9:26 am
Teaching IT about SCADA would be a major cultural shift for them, just as teaching SCADA integrators and engineers about IT security is a monumental undertaking.
You’re right in that we need some cross pollination of skills. I disagree that we should expect typical IT departments to be effective help for SCADA system managers. The mindsets are completely orthogonal from one another.
In IT, everyone tries to centralize security features for ease of management. In SCADA we distribute as much as we can to the field. In IT, we sacrifice performance for compatibility. In SCADA we sacrifice compatibility for performance. In IT, security is all about the computer in the box, in SCADA it’s all about securing the network.
I could go on like this. The bottom line is that if you look in the toolboxes of someone who works on aircraft and someone who works on boats, you’ll find a lot of very common tools and techniques. However, just because they use the same sorts of tools, materials, and techniques doesn’t mean they should be working for each other’s clients.
I sure wouldn’t set sail on a yacht maintained by an aircraft mechanic, and I know you wouldn’t want to go flying in an aircraft maintained by a boat mechanic. In other words, SANS can rant all they want. I doubt it’s possible that they’ll be any more effective to FERC or NERC, and it’s quite probable that they’ll make things much worse.
This is the clue stick I think we need to hit them over the head with…
Comment from Gas SCADA System Analyst
Time: October 5, 2006, 12:20 pm
A wise man told me that what needs to happen is that the large set of people with all the traditional IT security expertise need to stop trying to become instant SCADA security experts and perform a reality check on their recommendations for improving SCADA security. The people who can perform this reality check is within the much smaller set of operational SCADA system managers & security experts. IMHO, please leave your corporate/organizational/personal agendas at the door since our group goal should be the identification of all real & confirmed threats to SCADA and then determine the most prudent things we can do to protect these systems based on that threat analysis.
Oh and from this moment on security needs to be built in everywhere from the field transducer to the Plant/SCADA operator workstation in the control centers and the entire path in between.
Comment from Gray Ghost
Time: October 7, 2006, 10:41 pm
The IT Security team’s job is often to protect the data and the business process. Manufacturing places the priority on the physical process and the computers are a tool within the process. As a result, less attention is paid to the traditional IT security function and more emphasis has been placed on running and optimizing the process for reliability (availability).
What is currently missing is the people that know and understand security within the engineering and operations discipline. IT security departments and SANS understands how to secure the device and the network against attacks. They have no idea what is required to keep manufacturing operational and safe. The IT and SCADA definitions of integrity and availability/reliability are completely different.
Plants and engineering departments need to bring in the IT security folks as advisors to provide technical security expertise for the computer systems. They cannot just hand over the SCADA security to IT without significant impact on the reliability and safety. They also need the engineering and software professionals at the SCADA/DCS/PLC/Historian… vendors to provide the basic CIP tools minimally including:
- Backup and Restore
- Host and Network Intrusion Detection
- Secure authentication across multiple devices (not one logon per box) with provisions for emergency access if the authentication servers are down.
- Anti-Virus/Anti-Malware
- Tested vulnerability assessment tools that will not crash SCADA services
- Support of third party consolidated logging appliances
- Automated change detection and logging for control systems programs and parameters
Real success will occur when organizations change from a security/compliance department model (which SANS and IT are very good at) to developing a security culture within the company. This culture will require the population to understand why security is important and have appropriate experts available.
This security culture applies equally to manufacturing systems or protecting against release of personal information by call center agents. Appropriate engineers and managers within the company will need:
- Enough basic knowledge to ask the right questions
- Enough cultural support for security to feel required to ask the questions
- Enough management support to implement the answers whether it is procedure or product
Comment from CNI operator
Time: October 16, 2006, 11:50 am
Seems to me that this debate is headed back to the old IT v’s SCADA/DCS argument.
I think we’ve all done this debate one too many times.
IMHO, both IT and the control community has to work together recognising that each has skills/understanding/knowledge/experience/etc.
I think its nonsense to dismiss either group as having no valuable input.
Write a comment