 |
|
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
 |
|
|
|
|
|
Home > Domains > Operations IT > ARC Cyber Security Insights by Bob Mick
|
|
8/27/2010Except in the industrial communities, the Stuxnet excitement seems to be settling down. Oh sure, some are still reporting it as a crisis, but the patch is out, and we know how to prevent such things. The remaining interesting points are: The latest frenzy is about the DLL vulnerability (also called “binary planting” vulnerability. That is when malware manages to get their DLL loaded instead of the real one by placing the malicious DLL earlier on the Windows search path, such as in the “current directory”. Microsoft indicates that it is really not a vulnerability (it is supposed to work that way), and applications have been coded incorrectly. They are right but it is still a problem. Microsoft actually sees it the same way, and has provided a tool to help mitigate the problem. The behavior is not new, and is associated with searching the users current directory first for DLLs. However, there are several variations on this scenario. Some say it actually was a bad design decision, made a long time ago and one of the primary causes of what many called “DLL hell”. Different applications often installed different (obsolete) versions system DLLs and caused other applications to fail. The DLL vulnerability is a excellent example of how difficult cyber security is. We need to constantly re-think old decisions in a new insecure context. However, it is not reasonable to think that this is a winning strategy. Instead, we need to develop protections that assume vulnerabilities will always be there and stop them. We need more thinking like the concept behind application whitelisting. bmick@arcweb.com 8/25/2010
The investigation in to the Spanair flight 5022 crash in 2008 provides good example of how cyber security and safety are linked. Here is the situation (possibly paraphrased inaccurately – see other sources if you want the details):
- Onboard systems alert the pilot on unusual situation. In this case, it has to do with something like the pilot having the takeoff flaps in the wrong position.
- The onboard alarm failed (pilot heard nothing) and this failure was sent to the remote maintenance system. The maintenance systems should have logged the failure which would have kept the plane on the ground. Current reports point to the presence of a “Trojan” on the maintenance system that caused the maintenance system function to fail.
- The plane took off, the pilot reportedly made the mistake, the alarm failed again and the plane crashed.
The reason I mention this that it is absolutely critical that when computing systems are in the safety loop, the designers, implementers and testers must:
- Be highly aware of cyber attacks
- Include cyber security as a critical design point for all components
- Be aware of how to protect systems, communications, etc.
- Include security experts in design reviews
- Include security-focused test cases
- Possibly submit components and systems to testing by external groups
- Consider cyber security in all changes and updates
- etc.
It seems that too often this is not happening. Designers and developers of desktops, servers, distributed control systems, HMI (Human Machine Interfaces) and SCADA seem know that this is an issue (addressing it is another problem).
But I really worry about embedded systems, especially as safety systems migrate to “digital”. I seriously doubt that the embedded software development tool suppliers have security built in. And embedded systems developers have not worried about cyber security attacks because the perception is that they are not “popular targets” for attacks.
That perception is wrong. Any system made in large quantities is popular enough: On-board automotive systems, ATMs, … PLC’s, Unit controllers, smart grid metering systems, etc. are all “popular enough”. The hot topic in the industrial control system industries is how the Stuxnet attack places code in a PLC, which of course is a special purpose embedded system.
The point: If you are involved in any aspect of designing and building embedded systems – especially safety related - better make cyber security an important part of your processes now. The consequences of ignoring security considerations in some applications can be catastrophic.
Comments and question are welcome: bmick@arcweb.com 8/24/2010
We all know that a defense in depth strategy for Industrial Control Systems requires several security components and different technologies (among other things). Some components including firewalls, antivirus, identity management directories are commonly used today. Others, such as intrusion detection and protection (IDS and IPS), and application whitelisting are not commonly deployed today in control systems.
However, within the last year, some suppliers (Emerson Process Systems and Industrial Defender) started offering security solutions for systems that includes application whitelisting technologies, and the results are promising. Whitelisting is especially interesting today because one supplier, CoreTrace demonstrated that their whitelisting solution (Bouncer) stops the Stuxnet attack.
Other technologies such as some “Host Intrusion Prevention Software” (HIPS) from McAfee, also have the potential to stop such attacks and at least one supplier, Invensys, has recently started shipping HIPS to customers. (Note: The HIPS term is used to describe different technologies.)
We recently talked to the suppliers mentioned above, as well as one of Emerson’s customers who has been using Emerson’s whitelisting and patching offering for about a year (ARC clients can get the report here). The customer is very happy with the results – it reduces the need to update antivirus signatures immediately and reduces the effort needed for patching. The customer is about to deploy the solution more widely.
Of course, application whitelisting is not by itself a comprehensive ICS security solution, but it looks like it reduces the risk associated with 0-day vulnerabilities and reduces the effort needed to maximize security. Time for end users to give it a try, and more importantly for automation suppliers to determine what they need to do to support it. 7/20/2010
Well by now you have heard that a worm, Stuxnet, was recently publicized that specifically targets Industrial Control System (ICS) components from Siemens. The potential for virus and worms disrupting ICS performance has always been there, and of course most businesses have experienced incidents, disruptions, and such, at some level. What’s different is that this one includes code that takes advantage of an automation suppliers product implementation.
There are plenty of good pieces breaking all this down (here is a good one: http://news.cnet.com/8301-27080_3-20011159-245.html) and the story is still unfolding. But here is a quick summary:
- The attack is sophisticated, spreads through all kinds of systems – those running Siemens software or not. It hides itself causing the antivirus vendors difficulty. But solutions are bring tested.
- The exploit takes advantage of a Microsoft flaw. One only needs to browse the files (on a memory stick for example) and the virus is activated.
- It looks for Siemens ICS software, and attempts to collect configuration and other information – that which defines what the control system is doing, possibly including operating data.
- If it is successful at collecting something, it sends it to a server.
- It may have other capabilities – some have been suggested but there are no details.
- It was first discovered in early June, 2010, and has spread mostly (~90%) to India, Indonesia and Iran, according to Symantec. (I wonder what control systems Iran is using in their Nuclear programs?)
- It is still spreading.
I will offer just a couple of observations. We all knew that eventually someone would target ICS, and now we have an actual case – no more waiting and speculation about that.
1) This one does not appear to be causing safety problems, environmental problems, downtime or any of the other damage that we have used justify investment in security. But that was the developers choice. I can easily imaging the developer simply changing the ICS configuration – the attack framework is there. Possibly that was a planned second step?
2) This situation highlights how ineffective antivirus is at actually protecting ICS, yet it is needlessly required by regulations (there are exceptions). I am working on a piece about whitelisting technologies and wonder if that would have protected systems from this attack. The answer appears to be yes if execution from a removable drive was disabled.
3) Clearly we need better ways to detect and track targeted attacks much faster!. This is critical for finding the attackers and reducing risk. Yet we still have too many arguing that secrecy is the best strategy.
I am hoping that this situation is a game changer. 3/25/2010
The Department of Homeland Security is hosting their Industrial Control System Joint Working Group (ICSJWG) spring conference in San Antonio, Texas starting April 8. The conference has a strong agenda for those who want to learn more about securing control systems, and still offers plenty of opportunity for participants to help shape the groups objectives and activities. The conference is free and both end users and vendors with security responsibilities are advised to attend and contribute.
The ICSJWG is chaired by DHS’s Sean McGurk and Tim Roxy, and consists of six subgroups:
- Information Sharing – vulnerability, threat and incident reporting
- International – collaboration, information sharing and incident response
- Research & Development – existing and planned R&D needs for ICS
- Roadmap – cross-sector roadmap for managing cyber security risk management
- Vendor – information sharing and collaboration between vendors, end users and standards bodies
- Workforce Development – existing and new ICS security curriculum, certification programs, outreach programs
In the list above, I have added an indication of the focus for each subgroup to give you an idea of their scope. The details are still evolving for most subgroups and you have a chance to help shape their work by attending the conference and getting involved. ARC recently started participating in the Vendor Subgroup and Information Sharing Subgroup, and has found that participation is excellent and energy is high. Based on our perspective from these two subgroups, all the participants are security specialists and want to get something done. Of course, with diverse collaborative efforts such as these, the challenge is in getting agreement on the specific tasks, but work on tasks has already started. The ICSJWG is relatively new and another challenge is in managing some of the apparent overlaps between groups.
The April meeting starts with reports from each of the subgroups and this is certain to help crystallize plans, identify a few new issues and facilitate quick resolution in many cases - the people needed to resolve issues will be at the conference. When you look at the agenda you will notice that there are three separate tracks following the subgroups reports: Policy and Standards, Technology and Case Studies. For these tracks, DHS is putting an impressive list of security professionals on the podium, making it hard to decide which track to attend – better if your company can send two or three people. BTW: There is also an introduction to control systems security on the third day for those who are not experts.
The ICSJWG Conference promises to be a premiere event for securing ICS related critical infrastructure, and ARC recommends that you attend. You can find most of the information needed on the ICSJWG site, but if you have questions or comments do not hesitate: bmick@arcweb.com. 2/19/2010
By Robert Mick, ARC Advisory Group
ARC held its 2010 Forum last week (Feb 8-11) in Orlando, Florida with more cyber security content than ever before. This signifies a growing general interest in cyber security for ICS (Industrial Control Systems), and also a growing investment in cyber security research at ARC. However there were signs that the ICS security community is not growing sufficiently to match industry needs.
ARC security content was kicked off on Monday with a workshop designed to stimulate rethinking. We examined vulnerability and human factors research from Idaho National Labs and the role of automation vendors. A more detailed report can be viewed at ARC Cyber Security Insights.
Tuesday morning Marty Edward of DHS started the general session thinking about cyber security by recounting the history of control systems and how that opened the door to cyber attacks. Marty’s well received comments are summarized under Highlights from the ARC 2010 Orlando Forum General Session.
Tuesday afternoon included an entire track on ICS security, comprised of two sessions that addressed a few opportunities for improving ICS cyber security. The first session addressed the opportunities associated with the use of third party security services for ongoing operations, and the value of ICS device certification and testing. See Rethinking Cyber Security at ARC’s 2010 Forum – Opportunities.
The second session reviewed the Energy and Chemicals Industry Roadmaps for cyber security, and the opportunity of cross-industry sharing, and this can be viewed at Energy and Chemicals Industry Cyber Security.
All the above blogs and more may be found here.
If you are interested in participating in future ARC activities on cyber security, please let me know at Bob Mick. 2/18/2010
This is the third and final posting about Industrial Control System (ICS) cyber security topics at last week’s Forum in Orlando. The first posting discussed the Monday afternoon ICS Workshop and the second discussed the first session on Tuesday afternoon about Cyber Security Services and ICS Device Compliance and testing. This posting covers the second session on Tuesday afternoon, including the Cyber Security Roadmaps for the Energy and Chemical Industries.
We actually had two purposes in mind. We wanted an update on the roadmaps, but perhaps more important we wanted to explore the opportunity for cross industry collaboration and the benefits for lagging industries to gain from the leaders. The DHS specified critical infrastructure industries have already broken new ground and even some of those are ahead of others.
Each critical infrastructure industry has a corresponding US government agency, Sector Specific Agencies (SSA) that is responsible for the coordinating the development of their industry roadmap. The roadmaps are all about setting high level goals and monitoring progress toward them.
The Energy Industry was One of the First
Keith Stouffer of the National Institute of Standards and Technology (NIST) brought us up to date on the activities in the Energy Sector. The Energy Sector Roadmap was first developed in 2006 and they have recently been revising it in 2009 to reflect progress and set new goal. Much of the Energy industry standards work has been done within the North American Electric Reliability Corporation (NERC) as contained in the Critical Infrastructure Protection series (CIP-1 through CIP-9). These documents are relatively specific. For example, they require the use of antivirus software and testing. Revision 2 of these documents have been under development since 2008 and some have been approved. Work on Revision 4 is now underway. These standards are more than guidance documents and have related penalties for non-conformance. Theoretically, the penalties can be very large ($20,000 to $1,000,000 per day) for high risk, high severity situations, but Keith reports that the largest are very unlikely to be applied.

Keith also introduced us to the NIST plan for Smart Grid. This is a three phase plan that started in 2009 and extends through 2010 with planned efforts beyond that. One of the important NIST activities is the development of the NIST Interoperability Framework (see picture) that ranges from business requirements to compliance and testing. As you might expect there is considerable interest in Smart Grid activity and participation is high – over 300 participants in seven working groups.
The Chemical Sector
Eric Cosman of The Dow Chemical Company brought us up to speed on the the Chemical Sector roadmap and activities. A majority of the Chemical Sector security activity tales place around standards within ISA, ISO and IEC, guidance and advocacy within the ICSJWG (ICS Joint Working Group) and regulations within the Responsible Care and CFATS (Chemical Facility Anti-Terrorism Standards) programs. 
Chemical companies have been involved in improving security for many years, including defining standards for the industry. Typically twenty or so major chemical companies participate in activities. Initially, security work was done within CIDX, an industry organization that has now merged into other organizations. Their security deliverables move to ChemITC several years ago. The DHS Chemical SSA is responsible for the Industry roadmap and work has leveraged the Energy Industry work wherever possible. The Roadmap document is available online. For 2010 the Roadmap focus is implementation oriented.
Observations
The Energy and Chemicals industries cyber security activities are relatively mature and participation is high. But most of the participation has been larger companies and one objective is to increase participation of mid-size and smaller companies – security issues are similar and the risk is often the same. This is a scaling challenge for DHS.
Non-critical Infrastructure Industries have been pretty much left to deal with cyber security on a voluntary bases. However, you should be aware that the list of critical infrastructure industries can grow and broaden in scope as government feels that it is necessary. The list started with 17 categories and a new one was added a couple of years ago. It is likely that new industries will not have as much time as the ground breakers to get up to speed, and all industries should be tracking standards and regulations in the critical infrastructure industries. It is also a good test of your cyber security strategy.
Actions
The critical infrastructure industries are on track to be well monitored relative to cyber security. But we need to finds ways to increase involvement of other companies. Mid-size companies will be a special challenge and different approaches are needed to be effective.
This is the second posting about Industrial Control System (ICS) cyber security topics discussed at last week's ARC Forum in Orlando. The first posting discussed the ICS Security Workshop on Monday Feb 8. On Tuesday, we spend another entire afternoon exploring three promising opportunities in ICS Cyber Security. The afternoon was broken into two sessions. The first session addressed the use of third party security services and the certification of ICS devices. This posting is about the first session. Session 2, Energy and Chemical Industry Roadmaps will be covered in another posting.
Using Third Party Security Services for ICS
Several types of third party security services are available, including security assessments, system design, implementation, managing infrastructure, and others. Most services are project oriented and used commonly. However, it appears that services for ongoing ICS operations are underused relative to the value they offer. DuPont has been using third party services since 2002 for managing some of their process control network (PCN) firewalls, and we asked Tom Good of DuPont to present their perspective to us.
DuPont wanted to achieve a step change in ICS security in 2002 and looked for third party security service provider with ICS experience, rather than wait until DuPont had built the necessary skills and processes internally. In 2002, DuPont engaged the expertise of Industrial Defender who initially helped shape DuPont’s firewall segmentation architecture and strategy. The first benefit was that it lowered their initial implementation cost. There were several other ongoing benefits, such as bring automated tools for monitoring and managing firewalls, and providing a discipline for change management, backups and emergency responses. One key result was achieving 24/7 support under a formal service level agreement. Importantly, DuPont and Industrial Defender developed a partnership approach with a co-management strategy that included sharing of expertise and ideas. Industrial Defender is now managing about 150 DuPont firewalls in process control networks across 90 sites, and DuPont is refreshing their installed firewalls.
ICS Device Certification and Testing
Industrial control systems are the last line of defense against intrusions, but legacy systems were not designed with security in mind. Even today, many control system components have not been thoroughly tested for vulnerabilities. Furthermore, attacks change and new vulnerabilities are discovered all the time. With this in mind, one opportunity for improving security is to develop formal security requirements with certification testing. ExxonMobil developed an Industrial Automation and Control (IACS) security vision, including a “secure by design” goal, and we asked Johan Nye of ExxonMobil to tell us how compliance testing fits within that vision.
Johan first pointed out that not all ICS vulnerabilities are within the devices themselves. Frequently, the systems do not adequately define roles, give admin privileges to operators, use passwords that cannot be changed online, and come with unused services enabled. It is also common to protect the user interface but provide no protection for ICS servers. One of the reasons for all this is the lack of guidance for automation systems vendors. Standards and compliance testing are one solution that will not only give vendors guidance but also will enable an independent verification process, specifically designed for ICS. A key strength to this approach is that the process of developing standards and processes can utilize the best security expertise across the industry rather than each buy defining vendor requirements independently.
Panel Discussion
After their presentations, Tom and Johan joined a panel discussion with three other industry experts: Andrew Ginter of Industrial Defender, Eric Byers of Byers Security, and Tyler Williams of Wurldtech Security Technologies. Andrew added his experience-based perspective on security services and other IC security elements offered by his company; Eric, relatively new in the role of product vendor, discussed the history of compliance and testing; and Tyler talked about how WST has been helping secure ICS components while the industry waits for standards to be developed. The panel also discussed issues such as why security services for ongoing operations were not more widely adopted, alternative to standards based compliance and testing processes, and who should bear the burden of testing.
Observations
I came away from the session believing more strongly that outsourcing security services, especially for ongoing activities, has great potential for improving the security of ICS systems. Cyber security is getting increasingly complex, requiring higher levels of training to keep up. It is difficult to imagine manufacturing, utilities and other such facilities being able to internally maintain highly trained security staff on multiple sites, and be vigilant 24/7 to monitor and react to problems.
The strongest case for certification and testing of ICS components appears to be in providing consistent expectations to ICS vendors. But inevitably, there is a danger that some will believe that certification assures security. On the contrary, device level security measures must be surrounded by several other security measures and processes. There is also a danger testing requirements may need to be broader and more dynamic than standards bodies are able to achieve with working groups staffed largely with volunteers. Certainly thorough testing will improve the security of ICS components and systems, and both vendors and end users are on a path to do so, mostly stimulated by the success safety systems that addressed similar issues several years ago. But it is only one piece of the very dynamic ICS security puzzle.
Actions
All of the session speakers, panel members and most of the session attendees have been contributing to ICS security communities for several years. They are true security experts and this enabled Forum discussions to start at a relatively advance level. However, other owner-operators and end users are experiencing ISC security issues and can gain substantially by increasing their involvement in industry activities. We intend to shape ARC ICS security research to help grow this community. If you can participate in any way in future activities, please let me know bmick@arcweb.com. 2/17/2010
ARC held our 2010 Forum last week (Feb 8-11) with more cyber security content than ever before. This signifies a growing general interest in cyber security for ICS (Industrial Control Systems), and also a growing investment in cyber security research at ARC. However there were signs that the ICS security community is not growing sufficiently to match industry needs. This is the first of a serious of postings capturing what happened in Orlando.
Rethinking ICS Cyber Security Does Not Mean Starting Over
Our "Rethinking" theme was intended to give reason to pause briefly, think about the fundamentals, consider the current state of ICS security and explore opportunities for accelerating progress. It does not mean starting over, but may mean rebalancing investments in time and budget.
To facilitate re-thinking we invited several industry cyber security leaders to present, participate in panel discussions, and participate in a workshop. Here is a summary of the workshop that was conducted on Feb 8th.
Workshop Strategy
Our workshop strategy was to explore a few security fundamentals, and we invited Miles McQueen of Idaho National Labs to present two of his basic research areas: the nature of vulnerabilities and human factors. Some participants were a little apprehensive about mixing academic research with a largely tactical audience. They were pleasantly surprised when the combination proved to be very productive for the audience as well as for Miles. There were at least three impromptu follow up meetings at the Forum.
The second part of the workshop was led by Ernie Rakaczky of Invensys Operations Management (IOM). Ernie had not spoken in any of our security sessions previously, and we asked him to present the automation supplier perspective, more than an Invensys perspective. Ernie has contributed in many key ICS security activities in collaboration with his competitors for many years, making him well suited for the challenge. He bravely presented his views to them, as well as the end user participants, for consideration, discussion and debate – and there was plenty.
Workshop Observations
I will offer a few of my observations:
- It would be difficult to listen to Miles' discussion of human factors and not get a heightened appreciation for the importance of considering human vulnerabilities in ICS security strategies. More must be done and it was not debatable.
- My second observation was that the role of automation suppliers in achieving secure systems is not well defined and certainly expectations are not consistent. This clearly was a debatable issue, and consumed a good part of the open discussion period.
- Finally, we did not intend to discuss incident reporting and vulnerability disclosure, but the topic came up and it is clear that these will continue to be hotly debated for some time to come.
Actions
The purpose of the workshop was to help participants think differently about ICS cyber security and this is hard to measure. My take is that the format worked, but participants ranged from companies looking for ways to strengthen their security programs to industry security experts. Consequently, everyone left with something different. For those of you that attended, let us know what you think: bmick@arcweb.com
From an ARC perspective, we feel that all of the items above deserve more visibility and we intend to invest in additional research and publications for all three over 2010.
My next posting will be about the Forum's Security Track. 1/27/2010
While I do not intend to post every attack and intrusion, it is important to look at some incidents when enough information is disclosed to learn something. A recent story posted Jan 25, 2010 by Mark Clayton of The Monitor about attacks (in 2008) on large oil companies is worth discussing because it reinforces a few important lessons.
First, this is about espionage not impacting operations or triggering physical damage of some sort. The attackers were trying to acquire information about oil fields that cost the oil companies a lot of money to develop.
Second, the attack was targeted at executive. The strategy was to take advantage of the fact that executives usually have free access to critical business information. After all, it is hard to tell a senior executive that he/she cannot be trusted with company information. The lesson is to limit access to information based on exposure and risk, not on executive authority.
Next, the story references an unspecified source that indicated that the methods used "do not work like a normal virus" - "clever" and "tenacious" is the only description provided. The story also reports "a major foreign intelligence agency has taken control of major portions of their network", referring to the oil companies. This suggests that our commercial antivirus tools may not be capable of detecting or completely removing the intruding software – it gives the term "spyware" new meaning. The lesson is that many attacks have no obvious results and are invisible to users. There is a clear need for highly trained security professionals that are constantly monitoring a broader range of IT system activity to detect and investigate anything out of the ordinary. It will be more and more difficult to balance privacy needs and security.
One pressing question is how this super spyware got into the oil companies. As usually it appears to have been simple. The story describes how spyware was released in one oil company when an executive clicked on a link in a fake email that appeared to be coming from a peer ("spear-phishing"). The lesson here is that big and bad things can happen even from simple mistakes. There are far too many opportunities for these and the only solution is severely limit access to important information, limiting not only the people but also the time that information can be accessed. Not just time of day, but also make it temporary, and under document specific access controls. This in itself is not an easy solution, if only because of the large and difficult task of classifying a large volume of documents.
There are several other good points for discussion in Mark's story, but I want to end with a problem that seems obvious. Businesses will not disclose information about cyber security incidents. In some cases, the US FBI even seems to discover the problem before the company? Since the FBI is involved, it appears that we are dependent on the FBI to investigate incidents, and disseminate lessons and actions to other businesses so that they can avoid the same problem. I am not so confident that the FBI sees this as their role, which is a problem to be sorted out – at least for further investigation.
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
|
|
 Bob is a Technology Analyst at ARC and writes about Cyber Security - among other topics. He has participated in CIDX and ISA security standardization activities and presented on the topic on several occasions, including ARC Forums, client user conferences and Web casts. His current research is on security services and emerging security concepts and technologies. You can contact Bob at bmick@arcweb.com or comment on the blogs directly.
 |
|
|
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
Knowing that you have right security information for your software and systems in Operations can be difficult. Most of you have several suppliers, making it time consuming and sites can change quickly. It would be nice if all suppliers had at least some consistent top level content structure, but there are no industry guidelines to support this.
We would like to develop a set of simple guidelines that will help suppliers provide something common. We begin by finding and examining existing supplier security sites, and have started a list below. So far there is no consistency and many suppliers (not listed) seem to have no public security sites! If you have additional or better links, please send them to me at bmick@arcweb.com. |
|
| Quick View | | javascript:CoveoShowQuickViewForListItem('{ListId}', {ItemId}) | 0x0 | 0x0 | List | 101 | 2147483647 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XsnLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | FileType | xsn | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.2 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.3 | 255 | | Edit in Browser | /_layouts/images/icxddoc.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/formserver.aspx?XmlLocation={ItemUrl}&OpenIn=Browser | 0x0 | 0x1 | ProgId | InfoPath.Document.4 | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsx | 255 | | View in Web Browser | /_layouts/images/ichtmxls.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&DefaultItemOpen=1 | 0x0 | 0x1 | FileType | xlsb | 255 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsx | 256 | | Snapshot in Excel | /_layouts/images/ewr134.gif | /Domains/Manufacturing_IT/Cyber-Security/_layouts/xlviewer.aspx?listguid={ListId}&itemid={ItemId}&Snapshot=1 | 0x0 | 0x1 | FileType | xlsb | 256 |
|
|
|
|
|
|
|