There was an interesting Twitversation last night that was
started by my
Tweet on the failure of ICS-CERT to acknowledge the researcher, Blake, who
was responsible for the vulnerability disclosures that were the basis for the
two latest ICS-CERT alerts. You can see the entire conversation by viewing Adam Crain’s Tweet.
This is a perennial discussion in the ICS security community and I would like
to take this opportunity to explain my point of view on the topic.
Uncoordinated
Disclosures
First let me start off by clearly stating that I think the most
effective (from the user’s perspective) form of vulnerability disclosure is a
coordinated disclosure through ICS-CERT. This way the vendor has a chance to
correct/mitigate the vulnerability before it becomes publicly available. I
prefer the disclosure through ICS-CERT over direct disclosure through the
vendor because ICS-CERT has a policy of publicly
disclosing the vulnerability within 45-days if the vendor “is unresponsive,
or will not establish a reasonable timeframe for remediation”.
Public disclosures of a control system vulnerability before
the vendor has a chance to see/fix the vulnerability are generally a bad thing
for the control system user community. It allows a much wider range of
potential attackers to take pot shots at our devices. It is not, however, the
worst option from a user perspective. That would be the sale of the vulnerability
on the black/grey market to someone who would announce the vulnerability by
actually using it to attack a live control system.
Encouraging Security
Researchers
Because there will always be security vulnerabilities in any
complex piece of software/firmware/hardware the ICS community needs to
encourage independent security researchers to continue to look for new and innovative
ways to compromise such systems. It is only through discovery and disclosure
that these security holes will be discovered. In an era where it has become obvious
that cyber-warfare is not only possible, but likely, it is obvious that the
community is better served by public disclosure/repair policies than by
allowing black-market sales to attackers.
As vendors get more proficient at making their products more
secure, it will be harder and more expensive for researchers to find new
vulnerabilities. We will find fewer and fewer researchers who will be willing
to take on the vulnerability search just out of love of a challenge. They will
need to have some sort of recompense for their expenses at the very least.
We have already seen a number of attempts made to turn
security research into commercial enterprises, some with more success than
others. All of these have some sort of draw backs as seen from the wider user
perspective in that there is no guarantee that the discovered vulnerabilities
are going to get directly back to the vendor so that corrective actions can be
taken to eliminate the vulnerability. Lacking an effective bug-bounty program
we are going to see even more of these attempts at grey-hat research
organizations.
Independent Researchers
The age of the independent researcher as the main source of
vulnerability discoveries has passed. That doesn’t mean, however, that they
have disappeared from the landscape. There will always be the independent who
loves to try his skills against corporate computing. This will also continue to
be the breeding ground for young researchers who are trying to establish
reputations that will ensure their access to jobs with the more formal research
community.
The ICS community needs to encourage these independent researchers
to move into the larger community. This cannot be achieved by ignoring their
accomplishments. Failure to provide public recognition of the efforts will
drive them to the black-hat community that thrives on notoriety or into the
hands of the black-marketeers that will financially reward them for their
efforts.
Intellectual Property
Protection
As an independent blogger, I have a great deal in common
with the independent security researcher. I write this blog because of a love
for the industry and the challenge of changing society. The only compensation
that I receive for this work (and there are lots of hours put into this, just
ask my wife) is the recognition of my efforts and the knowledge that in some small
way I am making a difference.
It is important to me that my ideas are shared, but it is
also important that my work is acknowledged when it is shared. Most people,
when they quote my ideas will give credit either to this blog or to me
personally; that is all I ask. However, when someone quotes my work without
giving me credit, they are stealing my work. They are misappropriating my
intellectual property.
This is what ICS-CERT is doing when they publish a
vulnerability discovered by an independent researcher yet fail to disclose
either who that researcher is or from where they obtained the information. Just
because they are a government agency does not make that misappropriation any
less real or any less costly to the researcher. In fact, it can be argued that
misappropriation by a government agency is even worse because it gives the
appearance that such theft is socially acceptable or even legal.
Change the Policy
ICS-CERT needs to change their policy on disclosing the
identity of independent researchers who publicly disclose ICS vulnerabilities
without coordinating that disclosure with either ICS-CERT or the vendor. They
are not going to stop such disclosures by failing to recognize their sources,
they will only drive them firmly into the opposing camp and ensure that the
zero day vulnerability will become public only when it is used as a weapon.
Needless to say, I will continue to give credit where it is due
whenever I can discover who was behind the initial disclosure.
1 comment:
Researchers are looking for credit for creative work. I get it. And I want to see them receive that applause for their work. But there is a huge elephant in the room that you and many others do not address.
Most researchers think this is about some form of street cred and teaching the vendors a lesson. It isn't. Vendors are an extremely small part of this endeavor. The really big risks belong to the end users: the utilities. Even if a patch becomes available overnight, there are still periods of time (middle of summer and middle of winter) when utilities are not able to pull critical equipment from service long enough to properly test a patch.
But why don't we just spray a patch like Microsoft and Adobe do? I have the battle scars to show exactly why you don't do that. If you think a blown patch is bad for an office system, try a SCADA system or a plant ICS. Furthermore, I have experience from two patches that in themselves were benign, but acting together resulted in a very frightening situation.
The only circumstance where I might risk such a drastic measure is if there were a known attack underway and I knew for certain that we are vulnerable. Even so, few are staffed to handle something that drastic. We don't have bandwidth of that magnitude to push patches to the field devices. Our networks were designed for independence from other infrastructure, resiliency, and reliability; not bandwidth.
The problem with the rip-and-replace philosophy is that it ignores the ultimate end device. It is like talking about ripping and replacing an autopilot in an airliner while the aircraft is in flight. All we utilities are asking for is to land so that we can safely deploy and test.
If you want to get to a state where rip-and-replace is feasible at any time, you'd need to build a much more expensive distribution system with tremendous redundancies that no ratepayer would be willing to foot the bill for.
To give you a sense of scale, it would be like proposing a second Billion dollar distribution system so that we can conveniently update a few $800 controllers. It ain't gonna happen. Instead, we'll probably use less automation, and put more operators in pickup trucks. We'll have them spend more time driving to each site to make adjustments rather than risk putting this stuff on a network of any sort.
Utilities can not respond to every egotistical researcher who seeks to gain notoriety overnight. Yes, such black hats and dark grey hats exist. If utilities were to staff to a degree that we could handle such toxic disclosure behavior, we would limit the use of automation, reliability and quality would suffer, and rates would go up.
This issue of disclosure and giving credit is about you and me, and the infrastructure we depend on. This is about personal responsibility. If you want to give credit to someone who doesn't comprehend the ramifications of his discovery, that is your right. But I see this as giving immediate gratification to one person in lieu of community security. If we refuse to give them the public accolades they seek, researchers will be less tempted to use black or grey hat disclosure policies.
All that said, I want to acknowledge and thank Adam Crain and Chris Sistrunk for their work and for setting a very thoughtful and considerate example of discovery, disclosure, and discretion. And further, I agree with Adam; I think ICS-CERT does have a reasonable policy.
One thing I would change is the 45 day public disclosure deadline. It needs to be tweaked to acknowledge what season we're in. It could be less in the late summer/early fall and late winter/early spring seasons, but it probably needs to be more during the early summer and early winter months.
(Note: These are my opinions only, and may not reflect those of the DNP Users Group)
Jake Brodsky
Post a Comment