PCSF Wrap-Up
PCSF finished up on Thursday morning with some group activities led by Brian Mason and Joann Byres. We worked at tables on evaluating the solutions discussed at the event. What we thought was of value and what was missing. Then these results were presented to all of the attendees. I missed most of the table summary presentations, but when I came back there still was a large crowd.
The formal event ended Thursday morning with Perry Pederson of DHS announcing there will be another PCSF annual meeting in 2008 and DHS’s support for PCSF.
The DHS CSSP training courses were continuing on Thursday and Friday as were the IEC TC65/WG10 meetings. LOGIIC and other groups were taking advantage of the harmonic convergence to meet as well.
A few final thoughts:
- It was a great group of attendees. Unlike most industry events that have been diminishing in size and energy, this was an uptick for PCSF. If the PCSF annual meeting becomes DHS’s premier event in this space this growth is likely to continue. I think DHS’s official and unofficial sponsorship of other events like the SANS Summits, KEMA, etc. diluted the impact of PCSF and contributed to conference fatigue.
- The program had the right mix of sessions and breaks and a good environment for side discussions. The ability to meet and talk to a large number of vendors, asset owners, industry guru’s, government, writers and other organizations all in one trip is a huge plus.
- The Day 2 Solutions tracks were by far the best part of the program for me. I heard numerous attendees ‘complain’ that two or three solutions they wanted to see were being presented at the same time on different tracks. That is a sign of some strong content, and as an event planner it is a good problem to have.
- Most of the solutions were either newly released, still in beta, or still in the lab. So the community is still in the early stages, and there will be a lot of solutions that do not make it. However these solutions are an important step past the awareness building and hand-wringing stages.
- The Interest Group / Working Group sessions on the afternoon of Day One were the lowlight for me. The PCSF members have not made much progress through these groups, including the Control System SEM Working Group I have chaired. There are lots of good thoughts and intentions at these meetings, but these get overcome by events when attendees go home - - at least to date.
Great job by the Event Design Team and the Noblis crew in handling all of the logistics. After putting on S4 I have a new found appreciation for how many details are involved in doing something like this. Next year I’m petitioning for press credentials.
Author: Dale Peterson
Posted: March 9th, 2007 under PCSF.
Comments: 6
Comments
Comment from Ron Southworth
Time: March 10, 2007, 3:40 am
Hi Dale,
Thanks for filing in the gaps with the PCSF meeting, much appreciated.
I can understand your frustration in hearing the disharmony between IT and Process engineering is still being mentioned in presentations and conferences.
In defense of this issue continually being highlighted may I say that until people in IT support roles start to reach a similar point of enlightenment as yourself and others this sort of opportunity for improvement is still going to be mentioned. I have just returned from providing some training for mainly resources / energy sector participants and if anything the gap is widening not narrowing.
The common thing I heard occurring is that the control systems are being compromised in security terms simply so that IT people can remain tied to their desk and monitor and manage their systems, totally abandoning the concepts of defense in depth and without a hint of risk analysis being considered.
Further most disturbing is the trend in a decrease in availability of safety systems and process control systems in the order of 5 to 10 percent as a result.
The challenge is in raising awareness and understanding and accountability in many cases of the IT people involved, the IT culture in general is still very much oriented towards desktop systems support with the people just not getting the consequences of the way that they are conducting themselves. Until this continues to happen the issue is going to be raised.
Many thanks once again and have a most excellent day.
Comment from Matt Franz
Time: March 11, 2007, 9:40 pm
Ron,
I imagine your critique of “IT/desktop culture” and the need to get performance and other data from large numbers of systems and therefor install agents to monitor/manage every device, application, host, etc. (many which are quite insecure on multiple levels and therefore undermine the security of what is being monitored/managed and the entire infrastructure) would resonate with many folks “in IT” that have high standards for security whether run the network infrastructure, security infrastructure, or maintain business critical applications.
However, what I still find problematic after all these years is folks that continuing to uphold the false dichotomy between “control systems” and “IT” and I think many folks that perpetuate the IT vs. “SCADA/Operations/Control Systems debate” tend to equate Desktop with IT, when many “IT Environments” have equally high requirements for data/network/application integrity and availabilty as “control systems.” Of course, the physical consquences of compromise/failure (safety, loss of life, loss of service, etc.) are different but the impact on business may not be.
Futhermore, I could be wrong, but I doubt Joe’s song-and-dance on the topic has changed much since I first heard it in Vancouver in July ‘03. And if not, I think Dale would be right on target to say “enough already.”
Comment from Dale Peterson
Time: March 11, 2007, 10:48 pm
Clearly the cultural clash between IT and Operations has not been solved everywhere, but there are many success stories.
Some IT Departments are dedicating resources to Operations that sit with Operations. They learn the language, culture and quickly become part of Operations. You know it works when they tell the IT Department why it won’t work in Operations.
Other Operations groups have hired their own IT staff or outsourced resources. And of course some are still struggling.
I’m sure there is still a need for education on the differences for those new to the issue. My point was the crowd at PCSF is years beyond needing to be told about these differences. Matt is right - - it is the same as what we heard years ago. It is like another indepth explanation of the Australian wastewater hack.
The meat of that talk was on how SP800-53 is being enhanced or adapted for control systems. A much more interesting topic.
Comment from Jake Brodsky
Time: March 12, 2007, 7:34 am
Matt, Dale, and Ron, I too tire of the IT versus Operations argument. Whether the resources are handled by IT, engineering, or operations is almost irrelevant.
What is relevant is the fact that such systems use lots of embedded components where upgrades are not easy. Another fact is that they operate in a real time networks and OS environments –unlike most IT networks and OS products.
No matter who has the Process Control ball, they’ll have a lot of learning to do so that they can cover the other two sides of this three legged operation. In our company, we created a separate group under Engineering to do all these things. However, our group could live under other divisions of the company just as easily.
The key is to understand that these systems are unique and that the people who work on them are doing a job that is unlike the other jobs in the common experience that most companies have. What galls me are the legions of hungry IT folk who see new territory to make all sorts of policy on, and who think of this as “just another app.” IT’S NOT JUST ANOTHER APP! It’s not just another engineering project either. And it sure isn’t just an extension of the instrumentation techs you often find in Operations divisions. But you don’t usually see the latter two groups attempting to project their ignorance all over a SCADA system.
Far too many assume that IT is the only leg in this game. It isn’t. Just ask any controls engineer. Just ask any instrumentation technician. This is the front line that gets called the minute the hair on the back of a senior operator’s neck begins to rise. Where the problem ends up largely depends on how much crossover capability the Process Control Group has in to other areas of the process.
Until this fact becomes well known and understood in the halls of executive management, I’ll keep ranting about this subject. Joe Weiss isn’t wrong to say the things he’s saying. He merely hasn’t widened the scope far enough.
Comment from Ron Southworth
Time: March 13, 2007, 12:24 am
Hello Dale, Matt & Jake,
I think we can all agree the issue is one of organisational or career culture and having a firm apreciation for operational needs. I suppose the point is that operationally these issues still are impacting and it is not a side issue as much as we all may be sick of hearing about it. To make a positive change or difference we need to devise ideas / methods to bridge this gap. Any tips, techniques etc as to how we can promote this are always most welcome.
As you say of more interest would have been Joe’s discussion on SP800-53 and it’s application to control systems. I look forward to seeing the presentations once they are released on the site.
Many thanks and have a great day.
Comment from Ralph Langner
Time: March 13, 2007, 8:05 am
Jake, good comment. For my part, I have come to believe that the IT/process control gap is not so much due to different skills and knowledge but largely due to psychology, culture, and asymetric power leverage of the respective departments in the organization. I have to add though that I am often stunned by the sheer ignorance of IT folks. When the matter hits the fan, it’s some other guys that get hit…
Write a comment