On 12/10/16 17:10, Dean Coclin via Public wrote:
> [First Data] Depending of the severity of the vulnerability First Data would
> deactivate the device(s).  
> If the vulnerability does not carry severe risk, we would attempt to contact
> the merchant(s) and/or vendors and drive them to replace the POS system.  

And that's what you are doing in this case. Presumably either you rate
the risk of using SHA-1 as low and therefore didn't pull out all the
stops, or this process would take up to eighteen months even for a major
security problem in a terminal type or technology. The latter is a very
scary prospect; the former suggests First Data could have done more to
avoid being in the situation you're in now, even without the benefit of

> Where we own control we can proactively force updates to capable devices
> and/or communicate with our clients to obtain the necessary updates by the
> deadline.
>  Where we do not have control, we can notify the POS vendor and client of
> the compliance deadline and deactivate those who do not comply.

In order to do that, your systems must be able to tell the identity of
the software running on the connecting device - the equivalent of a
browser's User Agent string. If you couldn't, and were unable to map
that information to a list of vulnerable devices, then you wouldn't know
which devices to deactivate in this scenario.

This seems at odds with what you seem to be claiming, which is that you
don't know much/anything about many of the devices connecting to your
network. Either you can refuse transactions from known-insecure ones, or
you can't.

Public mailing list

Reply via email to