2 ms·

> Regulation and legislation is – and should be– a choice of last resort for solving problems in the digital age. However, externalities are sometimes best mana

by pnathan 11y ago

> 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.

xyzzy123 11y ago
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! See: e.g. https://blogs.oracle.com/darren/entry/fips_140_2_actively_harmful https://blogs.oracle.com/darren/entry/fips_140_2_actively_ha... for a discussion of some of the problems.

by pnathan 11y ago

xyzzy123 11y ago

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! See: e.g. https://blogs.oracle.com/darren/entry/fips_140_2_actively_harmful https://blogs.oracle.com/darren/entry/fips_140_2_actively_ha... for a discussion of some of the problems.