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 hindsight. > 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. Gerv _______________________________________________ Public mailing list [email protected] https://cabforum.org/mailman/listinfo/public
