> Regulation and legislation is – and should be– a choice of last resort for solving problems in the digital age. However, externalities are sometimes best managed via regulatory intervention. (Consider global climate change as one example.) Just as the federal government sets a minimum standard for motor vehicles on public highways (functional brakes, turn signals etc.), perhaps it is time to start discussing a standard of hygiene for the computing devices traveling our digital highways.
And this is, coincidentally, being proposed by Symmantec, who is a totally disinterested observer who wouldn't benefit at all from this restrictive legislation.
Part of the problem with regulations is that regulators often don't have the tools they need, resulting in wasteful and needless compliance work that leaves systems less secure than they were before.
Regulations are generally OK where they dictate personnel or procedural requirements but often extremely problematic where they intersect with technical matters.
An example would be cryptography in the HIPAA security rule. The only crypto standard regulators had in their toolbox was FIPS 140-2 (I believe it's a recommendation, not a requirement). Sadly, FIPS is a total footgun.
Many organisations however (sometimes under misleading advice from compliance paper pushers who do not know anything about security) then interpret FIPS 140-2 compliance or certification as a requirement for vendors.
Well, what's the problem? FIPS-140-2 is absolutely toxic to software. Trying to run systems in FIPS mode weakens them and breaks a lot of compatibility. Also, technically, you're not allowed to patch the crypto routines after certification!
Why aren't the people who fail to secure their computers liable for the damage they cause if their computer is used in an attack? This should be covered by common law, why does this need regulation?
5 comments
[ 2.8 ms ] story [ 24.8 ms ] threadAnd this is, coincidentally, being proposed by Symmantec, who is a totally disinterested observer who wouldn't benefit at all from this restrictive legislation.
Regulations are generally OK where they dictate personnel or procedural requirements but often extremely problematic where they intersect with technical matters.
An example would be cryptography in the HIPAA security rule. The only crypto standard regulators had in their toolbox was FIPS 140-2 (I believe it's a recommendation, not a requirement). Sadly, FIPS is a total footgun.
Many organisations however (sometimes under misleading advice from compliance paper pushers who do not know anything about security) then interpret FIPS 140-2 compliance or certification as a requirement for vendors.
Well, what's the problem? FIPS-140-2 is absolutely toxic to software. Trying to run systems in FIPS mode weakens them and breaks a lot of compatibility. Also, technically, you're not allowed to patch the crypto routines after certification!
See: e.g. https://blogs.oracle.com/darren/entry/fips_140_2_actively_ha... for a discussion of some of the problems.
If I left a toolbox that contained lockpicks at the sidewalk, am I liable for a thief stealing the lockpicks and breaking into another house?
This guy is suggesting that computers should be legally required to have spyware on them.
No thank you.