Digital Bond's SCADA Security Portal

A Case Study in Not Fixing the Problem

Reid W — Fri, 24 Feb 2012 18:29:54 +0000

Shortly after Rubén’s vulnerability announcement concerning their Modicon Quantum line of controllers, Schneider Electric released updated firmware for their various controller’s Ethernet cards, as well as an advisory (I sarcastically love the combination of “we take security very seriously” and “hard-coded backdoor credentials”). The partial fixes are incorporated into version 5.01 of their firmware for our NOE 771 01 module, which was shown in Basecamp.

The fix is rather sad. It disables the Telnet and WindRiver debug service issues, but leaves backdoor accounts and an FTP server enabled. The WindRiver debug port is fairly well-known (Dillon Beresford wrote up some nifty documentation on automating WDB agent attacks, including showing how to remotely alter how a controller boots by using the service to overwrite the bootline). The WindRiver Telnet service is quite a bit less-known.

The telnet service is really a C interpreter. Fermi National Labs has a nifty intro to it here. Because Schneider left debugging symbols in the Quantum line of controllers, it’s incredibly easy to use the C shell: you get function names. You can type commands like ‘strlen(“foo”)’ and the shell will return 3. On systems which lack debugging symbols, you’re left having to reverse engineer the firmware to find the function location, and then calling the function by using the pointer. For example, suppose that the strlen() function was found to begin at offset 0x0016fc18 in the disassembly:

-> 0x0016fc18(“foo”)
value = 3 = 0×3

It’s pretty interesting because the command line is totally type-free C. You can treat any spot in memory as a function without having to cast it. Even if your target lacks debugging symbols, that’s okay: you can do assignments on the command-line to make your life easier and make your code cleaner. This works for both function names and your own declared variables:

-> foolen = 0x0016fc18(“foo”)
foolen = 0xa0c6b8: value = 3 = 0×3
-> foolen
foolen = 0xa0c6b8: value = 3 = 0×3
-> d 0xa0c6b8
00a0c6b0: 0000 0003 eeee eeee * ……*

You can use the Telnet console for a lot more evil things, too, of course. vxWorks includes a full bsd sockets library, meaning that you can write a C program to run as a port scanner from the telnet console. Kinda cool. The syntax is quite clunky on the Schneider…while the device has debugging symbols, you lack the ability to use C data structures by name. You have to do things the old-fashioned and painful way: make a socket structure in memory by malloc()’ing bytes, filling in the socket structure by hand, and then calling the C connect() function.

The upgraded firmware does remove the Telnet service. In my opinion, it’s not even worth upgrading the firmware yet though. While it does lower your risk ever-so-slightly, all that it really succeeds in doing is providing a false sense of security. An attacker that spends 20 minutes with the controller will learn that the firmware may be downgraded using the still-present FTP server and backdoors. The firmware image is simply a file that can be overwritten using FTP access. It also doesn’t fix the issues that our Metasploit module exploits, which just uses these two issues to grab user accounts for the system’s other services.

There are plenty of nice projects surrounding vxWorks now, including a vxWorks rootkit complete with a portscanner and other fun network penetrating tools. The HP rootkit was hand-coded in ARM assembler, but a port to PowerPC would be trivial. Schneider would be such an easy target because of their inclusion of debugging symbols with the firmware image. Very little reverse-engineering is needed to find the functions for changing a Quantum into a weapon.

Image by fireflythegreat

Friday News & Notes

Dale G Peterson — Fri, 24 Feb 2012 17:39:14 +0000

I blame the WSJ reporter for the ridiculous story, “The director of the National Security Agency has warned that the hacking group Anonymous could have the ability within the next year or two to bring about a limited power outage through a cyberattack”. Either the reporter miscast what the NSA Director said or was dumb enough to bite on the story. Anonymous could do it now if they chose to as could anyone with moderate to strong hacking skills, desire, time and the willingness to get in a lot of trouble for causing a regional or larger blackout.

This week showed a good example of TippingPoint’s Zero Day Initiative (ZDI). Luigi Auriemma provided an ABB WebWare vulnerability to ZDI and got some money for it. The ZDI provided it to ABB who promptly developed a security patch. This week it was disclosed publicly.

More problems with pcAnywhere. Now pcAnywhere Nuke claims to crash a fully patched version of the product, and there may be more dangerous exploits coming. PcAnywhere is still widely used for ad hoc remote ICS access. A good reminder that every application and component on your ICS devices is part of the attack surface.

Tweet of the Week

@taosecurity asks "how often do you check to see if you're compromised?"-in our experience, 94% of orgs are notified by 3rd pty @Mandiant

22 Feb 2012 09:34 via TweetDeck ReplyRetweetFavorite

@GradyS

Grady Summers

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

Nothing this week — really

Critical Intelligence’s ICS Security Event Calendar Updates

ISA Using ANSI/ISA99 To Secure Your Control System, April 12 – 13 in Eindhoven, Netherlands
Oliver Kinross SCADA and Smart Grid Cyber Security Summit, April 26 – 27 in London, UK
ISA Using ANSI/ISA99 To Secure Your Control System, June 14 – 15 in Eindhoven, Netherlands

Critical Intelligence provides reports and other information products on Cyber Situational Awareness and Threat Intelligence services for Industrial Control System Owner/Operators, Vendors and Government stakeholders.

Image by anmar_

US Congress Trying to Deal With ICS Community Failures

Dale G Peterson — Wed, 22 Feb 2012 18:03:37 +0000

The fact that Congress has to deal with DCS and SCADA security for the critical infrastructure is another representation of failure by all in the ICS community, but in the US Government realm primarily by DHS as the responsible government agency.

Congress can’t be an expert in all fields and certainly not in something as arcane as control system security. It’s ridiculous that Congress and their staff have to try to determine how to solve this problem by crafting legislation. They should assign this and provide money to an agency who works the issue, and there is no evidence that the problem is DHS has failed due to lack of authority. To their credit, Congress sees little progress by the responsible agency in securing critical control systems and is trying to move the situation forward.

The best way to illustrate DHS’s failure is to look at the legislation itself, starting with the most damning evidence.

Prioritization and Focus – Sector Based Risk Assessment

Section 102 requires DHS to perform a sector by sector risk assessment “to determine which sectors pose the greatest immediate risk”. Sections 102 and 103 go into how this should be repeatable and ongoing.

Has this not be done yet by DHS? Shouldn’t DHS have handed the Committee the risk assessment report they have been doing repeatedly since they were founded? Shown how it has become more sophisticated and thorough over time. Show how it has driven the DHS programs. Show how they have measured success in terms of an improved security posture.

And I would hope they have a more than just an assessment as to what sectors should be prioritized. They should have:

a risk-based, tiered list of owner/operators in each sector (related to the crazy over reaction to a water pump in a small Illinois water utility)
a list of the key hardware and software technologies by sector, for example refineries use primarily Honeywell, Emerson and Yokogawa DCS. (related to the prioritization of ICS-CERT resources on key systems and applications rather than spending majority time with freeware HMI)
and possibly a list of the most important technical and administrative security controls missing in the top tier owner/operator systems

This prioritization requires making decisions such as a canal that provides the only water to a large, heavily populated region should receive a great deal of attention while a small, municipal owned water pump in Springfield, IL is handled by local authorities. It also requires the discipline to not jump on every vulnerability that can be tied to some control system function. Perhaps most of these should go through the normal US-CERT / CERT/CC process except for those in the key hardware and software list.

The main point is this prioritization is what any leader should do when given a task such as cyber security for the critical infrastructure. The fact that this has to be put in legislation is an embarrassment and failure.

Information Sharing

The USG has been trying a variety of private/public information sharing efforts over the last decade — PCSF, ICSJWG, ISAC’s, NESCO, … and now Cybersecurity Exchanges. The legislation is evidence that none have worked, although NESCO is still in play. It is unlikely that the government and community has only lacked the appropriate structure for information sharing. The problem is the government won’t share and almost all companies see no upside in sharing.

Personally, I doubt that information sharing would have a significant impact on improving ICS security. However, it appears that the DHS and the USG believe it is important, and thus it must be considered a failure.

If DHS believed information sharing was important they should find a way to push important and useful information outside their walls (such as those vendor eyes only assessment reports and that information “senior government officials” have leaked about purported international incidents). The group that wants information sharing the most has to be first, and put the most information out there. DHS could then have some minimal reporting requirements to get the information a la the old BCIT incident database.

Admittedly there may be some small points in the legislation in terms of relieving some of the legal and regulatory risk to the disclosure.

—- Logical Segway —-

An open question for loyal blog readers – what can DHS point to as successes over the last ten years? Here is my list:

Red / Blue ICS Security Training Class (current)
Initial Beginner and Intermediate ICS Security Training (until 2009, now redundant and dated)
PCSF Annual Conference (until 2008, the best information sharing effort to date)

Mixed

Co-funded SCADA and DCS security assessments at INL (This is a tough call. On one hand it is a massive failure because many of the most serious insecure by design issues have been not been addressed and NOT HIGHLIGHTED by DHS/INL — fighting Basecamp rant here. On the other hand I have vendor friends I trust who have praised the assessments and said the INL team found important vulns that they fixed. The biggest objection I have for this effort is the USG vastly underplayed their hand and got little value for the money. They allowed INL’s CREDA to rule the day even though they were providing money.)

It’s an amazingly small record for the dollars and time spent. Listen to DHS testify about the accomplishments in Congress. The accomplishments are thin and transactional. No government organization is going to win in the US being transactional without severe focus because the numbers don’t work.

How do you reward an organization that has significantly underperformed over the past ten years? Evidently, and regrettably, by giving them a lot more tasks and responsibilities.

That said Congress deserves praise for tackling this. They see very little improvement and recognize the seriousness of the problem. Legislation is their only recourse.

Enough rambling and ranting for now. Interested in hearing any comments.

Image by dbaron

S4 Video: German Smart Meter Gateway Protection Profile

Dale G Peterson — Tue, 21 Feb 2012 18:31:50 +0000

Stephan Beirer of GAI Netconsult briefs the S4 audience on the Smart Meter Gateway Protection Profile being developed in Germany. The effort was funded by the German Government and developed by utilities, vendors and consultants.

(Note – last ten minutes are audio only)

For those new to the Common Criteria, Stephan provides some information on a Protection Profile – including the Security Functional Requirements and Security Assurance Requirements. He then discusses the key points in the Protection Profile. Some of the essential threats considered:

an attacker (local or remote) tries to gain access to the metering data or smart meter configuration/firmware
an attacker may try to intercept meter data or configuration/firmware during data transmission
an attacker may try to gain control of the gateway, meter or controllable local system

The Protection Profile is written to EAL4+. This is actually quite ambitious with EAL4 requiring security assurance requirements during the development process, meaning existing products cannot reach this. The + indicates there are two additional requirements: flaw reporting requirements and vulnerability assessments.

What Should You Do … Part 4 – Gov & Stds Orgs

Dale G Peterson — Tue, 21 Feb 2012 14:58:37 +0000

Project Basecamp highlights the fragility and insecurity in most PLC’s and provides tools so anyone can demonstrate and prove it. There should be no doubt that after ten years the ICS community needs to deal with this, but how?

Part 1 covered what Asset Owners should do with new projects.

Part 2 covered what Asset Owners should do with already deployed projects.

Part 3 covered what vendors should do.

This article finishes the series with what Government and Standards Organizations should do.

Government Organizations

I’m going to focus on the US Government, but much of this applies to governments around the world. In the US, the government is not responsible for securing the private critical infrastructure — at least not yet. So they cannot be directly blamed for the lack of progress over the last ten years.

The US Government does however have tremendous influence on the conversation and what C-level executives feel they need to pay attention. For the past ten years, INL and the other labs under contract to the US Government have performed security assessments of most of the major DCS and SCADA systems. They have known that the PLC’s and field devices were fragile and insecure. They were unsuccessful in making any progress in this area, as was everyone else in the community. An argument for keeping the problem quiet so the bad guys don’t know about it was reasonable, albeit a mistake with 20-20 hindsight.

This is now over. Stuxnet and Beresford were eye openers to anyone, including the bad guys, looking. Project Basecamp took it the next step by providing easy proof of concept tools to exploit PLC’s. There is no reason for the INL/DHS/USG to be reticent any more.

Which is why the latest ICS-CERT Alert is so unfortunate. It appropriately covers the risk of PLC attacks (Basecamp and others) and Shodan type searches. But nowhere does it actually address the root cause, fragile and insecure PLC’s and other field devices. When is the US Government going to come out and say these are a significant risk and that critical infrastructure Asset Owners should be working on a near term plan (1 to 3 years) to replace them?

As Chris Jager tweeted, perhaps an ICS-CERT Alert is not the place for a major policy change. Wherever they choose to announce this obvious conclusion, it is time. If the US Government, who is supposedly the expert in all things ICS security, refuses to state this as a necessary and urgent step, it is much easier for a C-level executive to continue inaction. They can point to there efforts to follow the ICS-CERT alerts and DHS guidance, and still ignore the PLC problem.

DHS and other government agencies are political arms with political skills. How about flexing those political muscles and get the vendors a bit of heat? When you think of all the Congressional hearings and Presidential edicts, it is always pointed at the Asset Owners. It’s not hard to generate heat at a Senate hearing:

Mr. Vendor, how is it possible that your state of the art PLC that you are selling today for use in power plants, pipelines and chemical plants, that costs 10x more than a laptop computer, doesn’t even have basic security features that prevent an attacker from shutting down the critical infrastructure by sending the simple message ‘turn off’? Why does my ATM card, home PC and smartphone have more security than your product? …

I’m leery of any comprehensive security bill, regulation, or any other programmatic effort by the US Government being effective. The results to date don’t engender confidence to accomplish even simple tasks and goals. But putting out statements and generating heat is achievable, and actually something that Washington DC does well. It may be a bigger help than the other items in Senate 2105, DHS programs on information sharing or even repeating elsewhere published information in ICS-CERT Alerts.

Standards Organizations

In the first edition of this “What Should You Do” series, the obvious question of what security controls should be in PLC’s arose. Regrettably we are not able to point to a good standard or open process guideline document for recommended or required technical security controls in a PLC. Similarly there is no document like this for an HMI, Historian, EWS, SCADA/DCS Server, ICCP Server, Communications Server, … If you know of any efforts please put them in the comments or contact me directly.

This obvious point escaped me until I needed to find one. Most of the standards and guideline efforts to date have focused on broader security program issues, and this makes sense because technical controls on a component are not sufficient. In the correct assessment that administrative controls and system wide issues are important, the need for component level technical specifications seems to have been lost.

One or more standards organizations should jump on this missing part and create Technical Security Requirements for XXX Device standards or guideline documents.

There are some documents out there now for PLC’s:

ISASecure’s Embedded Device Security Assurance (EDSA) requirement documents and certification program are the best out there today. They actually cover the Functional Requirements, Communications Robustness and Vendor Software Development Lifecycle. Strictly speaking they were not created by a standards body or open process. This doesn’t particularly bother me, but some in the industry give them less credence.
IEEE P1686 covered security of IED’s in substations, but the requirements were very minimal.
Our Field Device Protection Profile written for NIST’s PCSRF and the Plain English Equivalent. Note this is an older document and should be used as reference only.

Image by

What Should You Do … Part 3 – PLC Vendors

Dale G Peterson — Mon, 20 Feb 2012 16:48:54 +0000

Part 1 covered what Asset Owners should do with new projects.

Part 2 covered what Asset Owners should do with already deployed projects.

This Part 3 covers what PLC vendors should do.

Tomorrow the final part will cover what governments and standards organizations should do.

PLC Vendors

Eric Byres and others have written that it is not solely the vendors fault since they are in the business to sell product and make money. They will provide customers with what Asset Owners will pay for, and to date this has not been security. Our hope is that Project Basecamp will be a catalyst that will have large numbers of Asset Owners demanding a robust and secure PLC.

Security should actually be a boon for PLC vendors because Asset Owners will need to replace existing PLC’s much sooner than they normally would. Someday, hopefully soon, a smart VP in a PLC vendor will wake up and say we have a big upside opportunity here. Individual vendors cannot be individually blamed for the current situation because almost all have the same problem. What is required is an option for their customers to move forward if they care about process availability and integrity. The lack of a credible plan by most vendors, even three years out, is very depressing. Siemens has no announced plan, neither does Schneider or Rockwell. These three vendors alone have a massive installed base in the critical infrastructure.

So what should a vendor do?

Figure out if the current products have a future in a world that requires a robust and secure PLC.
If the software, hardware and architecture support upgrade, define the security controls that will be offered, when they will be available, what the cost is, and how the upgrade will occur. It may be a phased upgrade with tiers of security controls available over time. The Asset Owners can then decide when and if to upgrade.
If a new product is required, hello GE, define the security controls in the new product, when it will be available, and what the cost is. The security bar is higher if an Asset Owner is going to retire a PLC made obsolete by security early. I would highly encourage a threat model be developed to drive the security control design.
Document and implement your security development lifecycle (SDL). Customers and prospects will want to see the documentation and proof that is actually being followed.
Insure the SDL includes fuzz testing for communication stack robustness.
Consider submitting the product to ISASecure testing at Level 2. It’s by far the best PLC certification to date.

It’s all basic, right? Time to get started. We would be pleased to publicize any vendors efforts to add security to their field devices.

We need to provide another article on threat modeling and required and recommended PLC security controls, but at this point we are at zero with PLC security so substantial near term improvement in product capabilities shouldn’t wait until the entire ICS community agrees on every security control required in a PLC.

The most important item for vendors is to have a credible security plan moving forward, be straightforward about what it is, and implement it.

Image by MShades

Friday News & Notes

Dale G Peterson — Fri, 17 Feb 2012 17:30:34 +0000

Project Basecamp tools was a big story, but we have covered that thoroughly on this site.

The other big stories, at least in the US, are happening in Washington DC. The Senate Cybersecurity Act of 2012 came was introduced by a bipartisan group of Senators. Homeland Security Television has a great, one-page at a glance summary. You can watch the Senate Testimony here. From CNN’s summary: “private companies that control such “critical infrastructures” would be identified the Department of Homeland Security and each individual company would be required to secure their own networks from cyberattack, and then “self-certify” in an effort to show the U.S. government it had complied. DHS would have the opportunity to spot check companies, and failure to secure could lead to civilian penalties.”

Not so fast though, Senator McCain and seven other senators plan to introduce a competing bill that gives NSA the power to work domestically for the first time to stop cybersecurity threats. Sen. McCain also questioned providing additional power and responsibilities to DHS and the burden on the private sector of these regulations … so maybe it is not a done deal.

President Obama also released a proposed budget for next year that provided some clues. Patrick Coyle dug into the details and found on page 2118 of the budget rationale that ICS-CERT would increase from 9 to 12 full time employees in this budget. Other than small details like that, the budget related to ICS security remained about flat.

Dutch researchers showed how water control systems in the Netherlands could be hacked and maliciously operated to flood the Netherlands with water and wastewater. It sounded a lot like the Australian wastewater hack until you release how important water control is to the large areas that are below sea level. The impact of an ICS attack here would be huge.

Joel Langill joined the growing number of ICS security training options in announcing his new 5-day training course Understanding and Securing Industrial Control Systems. He also announced a 1-day introductory course. Joel is the former Infosec Institute teacher so it will be interesting to see who takes over that class. Now with a full field of private sector courses will DHS/INL finally admit they are competing with industry, which they are prohibited from doing, and stop their basic and intermediate training?

Travis Goodspeed has been wardriving around Knoxville, Tennessee looking for Zigbee, 802.15.4 access points with his mobile kit. He took some pictures that are worth a look. 802.15.4 is the basis of many DCS wireless systems including WirelessHART and ISA100, although those protocols do add security at layer 3.

Tweet of the Week

Successful human tests for first wirelessly controlled drug-delivery chip http://t.co/axfimG4o LALALALA

16 Feb 2012 23:24 via TweetDeck ReplyRetweetFavorite

@reversemode

Ruben Santamarta

Don’t forget to subscribe to this blog RSS feed and follow @digitalbond.com on twitter.

Worth Reading Articles

Two articles on our Feb 14 release of Project Basecamp tools: Paul Roberts of Threatpost’s Bloody Valentine and ICS-CERT’s related alert.
CNN article: Senators Spar Over Cybersecurity
EET Article: Best Practices – Improving Embedded Operating System Security DP Note – This is from the Wind River / VxWorks people so very applicable to the ICS space.
Tenable Blog on integrating Nessus results with Metasploit: Nessus 5 Making My Pentesting Easier

Critical Intelligence’s ICS Security Event Calendar Updates

Western Power Delivery Automation Conference Security Presentations, Mar 29 – 30 in Spokane, Washington
CERIAS Information Security Symposium SCADA and Security Panel, Apr 3 in W. Lafayette, Indiana

Image by Luigi Lombardi

S4 Video – The Great Debate

Dale G Peterson — Fri, 17 Feb 2012 15:36:39 +0000

This year’s S4 Great Debate Topic – Anti-Virus and Monthly Security Patching Should Be Abandoned in SCADA and DCS. Billy Rios spends 5-minutes taking the con-position (that AV and Security Patching should not be abandoned) and Michael Toecker then takes the opposite, pro-position. Both were tasked with making the compelling argument, whether they believed it or not.

Then we throw it open for the S4 attendees to fight it out. There is great participation and varying opinions from the attendees in this one hour video.

Almost all of the attendees felt that anti-virus and security patching should not be abandoned. They should be retained. Although there were significantly varying degrees of how realistic it was, the protection it provided, the risks to the system and how frequently it should be done.

Let me prod loyal listeners to think a bit about the issue with some questions.

Anti-virus has been proven to be highly ineffective at stopping an attacker who wants to circumvent it. They just modify the malware to avoid the signatures and heuristics. At what point do you drop an ineffective security control?
Application whitelisting is becoming popular and will soon be a must have. How many controls will we layer on top of one another? If a control can never be deprecated, it will become a large list over the years. And at what point do we worry about the increased attack surface? (Note that Digital Bond has actually used anti-virus software vulns to gain access in assessments, when you think of the anti-virus software age and design cycle it is the ideal software to attack)
How valuable is incomplete security patching? If you only patch Microsoft, it may stop some automated malware, but it won’t stop an attacker who will compromise an Oracle, Symantec, backup program or some other missing patch.
How valuable is delayed security patching? If you are patching quarterly, then that means about two-thirds of the time you have exploitable vulnerabilities. Someone who knows the likely ICS security patching cycle would just try the most current exploits.

I’m hoping some day we can stop using anti-virus, at least on every workstation or server. We are not there yet, and my insurance company would object to that recommendation. Any IT or ICS security type in a company would likely lose their job recommending this. That said, I think we need to evaluate the effectiveness and effort of these and other measures.

For next year our goal is to find a topic that generates almost a 50/50 disagreement on the basic premise. We’re open to suggestions.

Product Review Part II – Industrial Defender ASM Online Demo

Dale G Peterson — Thu, 16 Feb 2012 20:27:17 +0000

In Part II reviewed Industrial Defender’s Automation Systems Manager (ASM) based on interview and some limited detail documents. Today I had the opportunity to get an online demo of the ASM interface and ask a lot of questions for just over an hour. You can see in the diagram below that the ASM has a number of software applications, more than can be covered in an hour, but here are my thoughts pro and con.

Asset Management

ASM really begins with the Asset Management module. Minimal information is entered into the ASM, and then the ASM gets the rest of the information through either agent, Industrial Defenders IT and ICS agents, or agentless technology, such as WMI for Windows systems. Information on the ports, services, software, users, etc. are all pulled into the ASM where it can be monitored for change and used for other purposes, such as the security patching program.

What about assets that are not entered into the ASM? An ARP Watch feature on either the Network IDS sensor or ASA collector appliance looks for any MAC or IP addresses not in the ASM and generates an alert that an unknown device is on the network.

North American electric utilities probably already understand the NERC CIP value this ports, services, user information can provide from a compliance standpoint, but it is valuable for any sector’s security monitoring and management. Alerts can be generated when new ports, services or software are on a system (and yes they have ways to deal with dynamic ports and services that start and stop).

The Asset Management module has the information and management component of patch management, but it does not actually apply any patches. Assets can be put into groups, and there should be some thought put into the groups. You can have OS groups, device type groups (eg HMI, EWS, Historian, PLC, router), or anything else you can think of. Your groups will affect the security patch management workflow because the ASM user needs to designate what new patches apply to the groups.

One of the most interesting futures is the capability to import security patch information from the ICS vendors. For example, GE or Siemens could provide a list of the approved and required OS, database, and ABB security patches tested and approved for deployment in a file that the ASM could import and then apply to the appropriate assets. The ASM user would then see all the security patches that need to be applied by working with the asset through the agent or agentless connection.

Configuration Change Management

Read the title carefully. This module does not provide the ability to change the configuration of a firewall, router or ICS device. Rather it provides the ability to identify changes.

A simple example — the IT Department has the skills to manage the Control Center / Enterprise firewall, but the Operations Group is worried that changes will be made without their approval. ASM could identify and generate an alert for all firewall changes. This is not a replacement for a Tripwire-type product, but it can identify changes in any configuration file.

They even have some change management support for field devices such as the ABB Harmony Controller. The ASM can generate an alert when the Project File or Firmware has changed. This is only available for a limited number of field devices today.

Event Management

This is a classic Industrial Defender capability as a SCADA SIEM vendor. They can get data from a variety of file logs, their ICS agents, security products such as HIDS/HIPS or any other information source.

For example you could get a running total of the packets blocked by the firewall, HIDS alerts, virus activity, …

Dashboard / GUI

This is where the real win is possible. SCADA and DCS are used to looking at displays and having set actions when certain alerts are raised. The standard dashboard is easily understood, visual, and has a lot of items an asset owner should monitor. Even better it is highly configurable. I asked a number of “can I do this” questions and the answer is yes.

The key will be someone understanding the system, the risks, what alerts should be displayed and what actions they should drive. It seems very possible that an operator could monitor the ASM with instructions to connect certain security or subject matter experts if various alerts occur at all or if others exceed a threshold.

Summary

The big question is what does ASM provide that similar IT products do not? And second, how important are the deficiencies, such as no security configuration or patch deployment?

Industrial Defender does offer agents for ICS components so they can get data that their IT competitors cannot. Similarly their partnerships with ABB, GE and others should make adding ICS specific intelligence and features easier than the IT product counterparts. Still I would say from a product standpoint alone the differences may not be enough, and the IT product counterparts have man-decades or man-centuries more engineering time in the product today and in the future that lead to a more full featured product outside of the ICS specifics.

Industrial Defender’s experience and domain knowledge may be more important in deploying and supporting the systems. They speak the SCADA and DCS language. They know what is critical in the network. They understand how operators and engineers in the field work. This is important in any sector, but perhaps even more important in the very conservative ICS sector. The ICS-specific access may be more important than the ICS product features.

Asset owners who have handled the SCADASEC 101 and are looking to improve their security posture further should take a look at this product, particularly if they have ICS products that ID has specific agent or other modules for.

Image by Industrial Defender

ODVA Responds To Project Basecamp

Dale G Peterson — Thu, 16 Feb 2012 18:47:27 +0000

ODVA, the organization in charge of the EtherNet/IP protocol responds to the Project Basecamp Metasploit module and payloads that take advantage of the protocol’s lack of authentication to reboot or completed stop the device. It basically says yes this is true because EtherNet/IP is “an open protocol”, and you should follow ICS-CERT and ODVA guidance on good security practices to stop the bad guys from getting to an EtherNet/IP device.

On one hand it is unrealistic to expect a membership based organization to have a quick response to any news. They discuss the possibility to “work with its members to evaluate potential security enhancements to the specification that can address these and other emerging risks”. On the other hand, it is very embarrassing that they have known the Basecamp and many other attacks are possible on this “open protocol” for years and have chosen to do literally nothing. One of the goals of Basecamp is to finally start the process of security PLC’s and other field devices, so you will hear nothing but praise from us if they use this opportunity to quickly start and expeditiously work to add security options to the protocol.

Dear ODVA members,

You may be aware that today a security consulting firm called Digital Bond released plug-in modules for the Metasploit Framework that expose specific security vulnerabilities in industrial control systems using EtherNet/IP™. ODVA is responding to this issue, and below you will find information that we will be providing to industry as a first step.

If you receive any inquiries related to this issue, please feel free to contact me directly on kvoss@odva.org.

Best regards,

Katherine Voss

Executive Director

ODVA, Inc.
********************

Today, Digital Bond released plug-in modules for the Metasploit Framework that expose specific security vulnerabilities in industrial control systems using EtherNet/IP™.

EtherNet/IP was engineered as an open protocol with the express intent to improve interconnectivity and the integration of industrial control products from multiple vendors. As a result, the potential exists that certain protocol attributes can be mis-applied in a way that can disrupt operation and affect availability of products in an EtherNet/IP system. These types of vulnerabilities and potential attacks on open protocols are not unique to EtherNet/IP; nonetheless ODVA shares in the particular concerns raised by this event because of EtherNet/IP’s widespread use in critical industrial control systems and other mission critical applications.

We live in a new era in industrial automation – one where the need for greater connectivity and information integration between network systems leads to new risks and threats to industrial control systems connected to business systems and the Internet.

The response from the industry should be threefold. ODVA, as the steward of the EtherNet/IP open network specification, will work with its members to evaluate potential security enhancements to the specification that can address these and other emerging risks. Vendors designing products that use EtherNet/IP can help ensure that products follow good design practices and are hardened against common security vulnerabilities. Equally important, end users and machine builders must do their part in adopting security programs that include policies and training of those who come in contact with the system design. Users also should work with their vendors to determine if their control system assets are affected, as the Metasploit modules do not impact all EtherNet/IP devices or system configurations.

ODVA recommends that all industrial control systems employ sound security practices that include layered security and defense-in-depth strategies in the network design. Specific measures such as industrial firewalls, strong authentication, intrusion detection/intrusion prevention systems and end-point security software such as antivirus and antimalware software should also be used to help reduce security risks to industrial control systems.

ODVA remains committed to evolving as the needs of the industry change. For additional background on the importance of industrial security and how to help enhance security in EtherNet/IP systems visit: http://www.odva.org/Portals/0/Library/Publications_Numbered/PUB00269R0_ODVA_Securing_EtherNetIP_Networks.pdf.

ODVA also advises its members to remain informed regarding security recommendations from such bodies as the US Department of Homeland Security – ICS CERT. Links to ICS-CERT recommendations can be found at http://www.us-cert.gov/control_systems/ics-cert/.

Image by Rajiv Patel