SCADA & IPS: And never the twain shall meet?
So Justin Weddington posted some comments in response to Landon’s blog entry on patch proxies that are blogworthy in and of themselves and are relevant to some soul searching we’ve doing here at Digital Bond about the level of detail that is appropriate to be released about SCADA Vulnerabilities that we might happen to discover.
As you know some of the IPS vendors are developing rules for SCADA protocols (ISS and Symantec are what ive seen). A relationship needs to be developed between the IPS vendors and the SCADA vendors to expand this to the “virtual patching”.
So after I cynically dismissed the possibility of SCADA vendors ever providing vulnerability information to IPS vendors, Justin asked:
Why not (I believe you but just want to know why)? Why are other software vendors working with them? What would change this? Its network based just like the blue lane solution. If someone posts the exploit on a mailing list and someone at one of the IDS vendors analysis teams picks it up and tests it against the software watching the network traffic they should be able to create a sig for it.
(So before diving in here, what I’m talking about below is IDS/IPS signatures that could be developed based on known implementation flaws, as opposed to the protocol abuse, meaning sending valid messages to a PLC or ICCP server or whatever to change some IO, restart a device, etc. — which characterize most of the Snort signatures we’ve developed up to this point.)
With only peripheral knowledge exploit/IPS signature development, I will give my take on this. But I know some of our readers are directly involved in such efforts either commercially or not, and hopefully they’ll correct me if I’ve got something wrong here.
- No such SCADA exploits are being posted to mailing lists and for reasons other than concern for national security. I’m curious but a non-denial of service vuln on a Sisco ICCP server with would be worth would be worth to an iDefense or ZDI or some other more questionable marketplace? How much would an un-auth exploit in OPCENUM.EXE be worth?
- Vendors screamed bloody murder (I’m exaggerating only slightly) when even the scant amount of details on the US-CERT LiveData ICCP Advisory came out back in May. We got questions from a IDS vendor or two asking for vulnerability details on this issue, which we did not provide. Perhaps we should have? In most (but not all) cases signature development usually follows disclosure. Release of a signature means some level of disclosure and in the best case, SCADA vendors only privately disclose vulns to their registered customers, not the wider security community which (as we all know, is full of bad hacker types). Oh and also IDS/IPS signature databases are often not private.
- Even on the IT side, impacted vendors do not work with security vendors, unless (perhaps) the security vendor (such as ISS in the case of a recent Sendmail vuln) discovered the vuln themselves. IDS/IPS vendors do not get enough information from vendor disclosures to develop meaningful signtures, so often they reverse-engineer patches or develop exploits by discovering the vulns themselves. So, if SCADA vendors start noticing that security vendors are building out SCADA testbeds to do the vuln/exploit research themselves for their products then that is a sign. But given the slow pace of security vendors even implementing IDS signatures (perhaps because of a shaky business case for even investing in SCADA Security products?) developed by Digital Bond, this seems an unlikely scenario. Plus, some security vendors that have an interest in the SCADA security market want to partner with SCADA vendors, not alienate them by disclosing a bunch of vulns in their products which is ultimately what releasing a bunch of new signatures/filter rules would be.
Need I say more?
Author: Matt Franz
Posted: September 10th, 2006 under IDS / IPS.
Comments: 4
Comments
Comment from Justin Weddington
Time: September 11, 2006, 4:31 pm
Never say Never =). You guys pushed ISS and when they put in some sigs all the other vendors came crawling in.
I think that all of this visibility is helping. Visibility is one thing needed before companies will start making the investment in security.
I am mixed on if you should release the vulnerability details to the IDS vendors. Partial disclosure can give an attacker a focus point for more investigation. Some attackers with varying motives may even have a scada test bed or two to play around with increasing the need for some type of control. But I just read your presentation on SCADA Vulnerability discovery and disclosure (Excellent) and it looks like the vendors released patches fairly quickly which is also another control. Releasing the exploit code can make fixing the issue a priority but could also do more harm. It’s a balancing act….
My vote is to keep working with CERT because it looks like its slowly promoting the need for scada security solutions. Are security vendors more or less likely to release signatures/filter rules if CERT publishes the vuln info?
Building the business case for scada investing in scada security products sounds like it may be a good business opportunity. This could come from many angles: scada vendors, scada customers and security solution providers through different avenues training, technical solutions, compliance, etc. It was a slow pace for security vendors to implement IDS signatures but eventually there was some progress.
Comment from Gray Ghost
Time: September 13, 2006, 11:09 pm
The SANS MS-ISAC project Cyber
Security Procurement Language for
Control Systems project has a
specific section on NIDS.
===
http://www.cscic.state.ny.us/msisac/scada/
3.2 Network Intrusion Detection
System
3.2.1 Basis
A Network Intrusion Detection
System (NIDS) is used to identify
unauthorized or abnormal network
traffic.
3.2.2 Procurement Language
Post contract award, the vendor
shall provide a configured
Network Intrusion Detection System
(NIDS) and/or provide the
information to configure a NIDS,
Also, after the contract is awarded,
for anomaly based NIDS, vendors
shall provide traffic profiles with
expected communications paths,
network traffic, and expected
utilization boundaries. Signature
based NIDS vendors shall provide
appropriate signatures.
===
We need to push the SCADA vendors
in the bid and acquisition process
and the support contract process
to develop a partnership with a
vendor (Digital Bond and Tenable/
Snort, Cisco, another vendor) and
to require the vendor to cooperate
with their selected partner
supporting testing and assessment
of vulnerabilities.
I would suggest somebody from the
Digital Bond organization to be a
part of this standards development.
They probably are not already are
involved. There is definitely room
for improvement in this standard.
This project as a whole, if the
buyers are on board can be a major
factor in the control systems
vendors marketing plans. If
nothing else, they will need to
have a partner to meet the checklist
the acquiring companies will be using.
Gray Ghost
Comment from Dale Peterson
Time: September 14, 2006, 10:18 am
Gray Ghost - the procurement language project has the potential to be a big help to the community, but it isn’t something anyone on the Digital Bond team is that excited about. We have to pick our spots with only so many hours in the day.
I think the example you give is one of the bad requirements that shows what can go wrong in that project. How do you measure if a vendor is compliant with that requirement? There is huge variance in signatures and anomaly detection.
The asset owners do need to push in RFP’s and better examples might be:
- time commitment to test a patch
- time commitment to modify product to work with a patch
- commitment to modify product as necessary to always work with a supported OS. Think how this would have helped with NT.
- certify use with anti-virus vendor
- certify use with HIPS vendor
Then there are the requirements needed that vendors don’t meet today such as authenticating the source and integrity of all data.
You are right that we should take a closer look at this effort and blog on it because it is an important project.
Comment from Anonymous
Time: September 14, 2006, 11:58 pm
Dale,
Thanks for the reply.
I also agree this particular standard is poorly written. The biggest problem will be that vendors select an IDS to meet a punchlist and pretty much never touch it again. Signatures files will not be tested leaving a potential that intrusion prevention type functionality will think it sees an attack and shut traffic down. How to make this a measurable standard I do not know.
The CIP standard does have some specific time requirements regarding testing of application patches, OS patches, and anti-virus signatures (though not NIDS signatures). Many customers will be insisting that the vendors test the patches and provide vendor approval. If not approved they will want documentation as to why not approved so that appropriate waiver documents can be filled out. Unfortunately, many customers will base installation only on vendor certification without their own testing. I have already had this discussion at one company.
The other areas you mention are all critical for security. We both could go on and on about what needs to be done and at least CIP is a start. I expect that ISA-99 is also a start though I have not read that standard yet.
Write a comment