Hacker News Reader

Comment by jefffoster | Hacker News Reader

I wonder if this'll (or something like it) be the tipping point for governments to introduce more regulations for software? We already have regulations like PCI-DSS for dealing with payment card, maybe this'll end up with regulations for dealing with security?

The conclusion suggests better specification, better testing and more resilient architectures are the strategies that could make a difference. Perhaps software engineering will have to agree on a set of "best" practices that make security problems less likely to occur?

(typos)

View on HN

Regulations in software tend to encourage compliance theater rather than delivering the spirit of their intent in my experience. It isn't that difficult to conform to regulations technically with an awful and careless implementation, and I've seen it happen many times. It is "best effort", in part because it is obscenely onerous or impossible to ensure some properties in a strict sense.

Best practices also drift over time and vary with context. A challenge is that there are very old, very large code bases where as a practical matter will never be modernized because it is tantamount to a rewrite, with all of the bug creation and cost implied.

Robust software is definitely possible today even in languages like C++, but the development process for software that rarely fails isn't that compatible with the popular "fast iteration" development model nor the current computer science skills of most software engineers.

All of this is true, which is why effective policy interventions would punish bad outcomes, not prescribe methodology.

Make bad software expensive and software quality will eventually increase.

Bad software is already expensive. This is just poorly understood.

It's simply not fair to non-specialists to expect them to have a working knowledge of how cost works in software.

Fines and vulnerability to class actions make the costs far more visible (and increase it besides). If non-specialists routinely make bad decisions because they don't understand how cost works, then the solution is to make the cost of bad software dead obvious.

They did before and it worked until they made it unwork:

http://lukemuehlhauser.com/wp-content/uploads/Bell-Looking-B...

I wrote a post on Schneier's blog describing a few ways security evaluation has been done plus how I would do it:

https://www.schneier.com/blog/archives/2014/04/friday_squid_...

My model can be used for regulations or liability. Another proposal I had was enforcing a minimum amount of assurance activities proven to knock out defects. Likely a subset of techniques in this post:

https://news.ycombinator.com/item?id=10734477

Note that U.S. government has already given prior guidance on robust software that mentioned some of those with specific tools. A number of companies in safety-critical are doing things like formal specifications for precise requirements, review of various items in lifecycle, automated generation of tests covering every path, and implementation in Ada/SPARK to knock out classes of errors there. There's also tools like Softbound+CETS plus minor modifications to processors that make most classes of errors or attack impossible. So, it's not theoretical so much as something practical that many avoid for convenience or extra profit. ;)

I can definitely see more standards and certifications coming to pass, which then later distill down to one or two primary certifications that everybody aspires to get. Currently there are multiple privacy/security standards (PCI, HIPPA, FERPA, etc). We'll probably have to get more opinions from more sensitive-data industries, and then for them all to find the common ground.

But how would we incentivize businesses properly to be [WHATEVER] compliant, and pay for the regular security scans? Social proof / public shame hasn't worked yet, despite MANY high profile examples. We may have to impose some sort of carrot/stick combo that says: "If your infrastructure consists of N# of networked devices, you must meet these standards. If you fail to, and get caught in a data breach (like what happens with PCI), fines that could put you out of business get levied. Additionally, if you show proof of your security certification every year, you get a tax break."

Regulatory enforcement.

Even though PCI DSS is enforced by a private regulatory body, it still carries weight. HIPAA has HHS which does investigate and lead to corrective action. Both of these bodies scare the crap out of a lot of companies. I've worked in both sectors (banking/credit, healthcare) and the fear is palpable.

If the CFPB had the ability to enforce regulatory requirements for handling of PII you bet your ass companies would fall in line. Nobody wants trouble with the feds.

These regulations have done a lot of good, but there's sometimes the way in which they seem to devolve into checklists (not to stigmatize checklists, which are valuable tools!), often without corresponding understanding and capability.

I've seen that particularly in the way that PCI rules led people to get certificates and turn on HTTPS, without knowing what a certificate, private key, public key, TLS, or HTTPS were or what they were for. While I prefer that to the alternative of no HTTPS at all -- which is probably what we would have seen without the rules! -- it's still a bit disappointing and concerning that for so many organizations it only got to the "have to satisfy PCI rules by doing this weird arbitrary thing" stage.

The U.S. Federal Government already has [NIST-800-53](https://en.wikipedia.org/wiki/NIST_Special_Publication_800-5...) (for software), and [FedRAMP](https://en.wikipedia.org/wiki/FedRAMP) (for cloud infrastructures). The regulations and certifications are there, it's a matter of implementing them properly in a way that actually ensures real-world security, not just that there's a huge, 200-300 pg. document somewhere describing a secure state of an application.

But this is what OpenControl is meant to solve. https://github.com/opencontrol/

> "best" practices

I'd rather a professional guild makes the call on what other capital-E Engineering disciplines call, the state of the art, is. We do have something like that, a document published under the IEEE called SWEBOK [0]... but it needs greater industry adoption and a the establishment of a profession that governs our ethics, IMHO. Presently it's nice to know but my employer pretty much dictates what corners I will cut and what mistakes are acceptable, etc. Since there's no liability involved and no actuaries adjusting the insurance rates based on our technology and process choices my employer doesn't have an immediate dollar-figure that gives consequence to those risky decisions.

[0] https://en.wikipedia.org/wiki/Software_Engineering_Body_of_K...

Reply on news.ycombinator.com