[Cryptography] On New York's new "Cybersecurity Requirements for Financial Services Companies"

[Ray Dillinger]

On 03/01/2017 09:38 AM, Perry E. Metzger wrote:
> New York State's Department of Financial Services recently published
> its brand new regulation for banks, insurers and other similar
> companies entitled "Cybersecurity Requirements for Financial Services
> Companies":
> 
> http://www.dfs.ny.gov/legal/regulations/adoptions/rf23-nycrr-500_cybersecurity.pdf
> 

This is progress, but....

I feel like I'm pointing out the obvious here but most new attacks work
by doing things that security designers didn't think of.

Making active requirements to do specific things, no matter how helpful,
does not motivate people to think of new attacks and ways to block them.
They simply check off a tick-box, and often technically fulfill a
requirement even though they misunderstand or actively subvert the its
intent.

So I feel that a set of positively-expressed requirements actively
address only a fraction of the problem; the attacks we've already seen,
the methods for mitigating those attacks which we've already thought of.
 Further, it addresses those things only under the assumption that the
requirements are understood and implemented in a way that does not
subvert their effectiveness.

Motivating people to think of new attacks, to understand new attacks
when they start happening, to interpret requirements in ways that result
in effective security against known attacks, and to think of new ways to
effectively block known attacks, requires legal consequences that
penalizes the RESULTS of falling victim to those attacks.

IE, a set of requirements and best practices like this needs to be
accompanied by liability requirements that apply to the consequences of
attacks - regardless of whether the requirements are technically
followed. They don't need to be punitively large, but they need to be
sufficient to focus attention on at least getting the implementation
right.  They need to be sufficient to focus attention on promptly
understanding and blocking previously unknown attacks.

Consider a company that fulfills a requirement to encrypt the content of
its packets, and a requirement to NOT embed a decryption key in its
client so that it can be stripped out of the client software with a
debugger.  But does not understand the intent of requirement, or do not
face consequences for subverting its intent, so they then use a header
field to transmit the key with the packet, subject to masking using XOR
against a constant that can be stripped out of the client software with
a debugger.  It sounds ridiculous, but I've seen things equally idiotic....

				Bear


---
"A common mistake that people make in trying to design something
completely foolproof is underestimating the ingenuity of complete
fools." --Douglas Adams

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://www.metzdowd.com/pipermail/cryptography/attachments/20170301/383d0982/attachment.sig>