Hacker News Reader

Comment by ranci | Hacker News Reader

"Critical systems" pretty vague, and could be used to describe any system that processes payments or other basic things we use.

It's fundamentally different from malpractice in my opinion. In health care malpractice has obvious pieces of data - we know who the doctor is, we know their credentials, we know what information they had and when they had it, we know what they decided, what they prescribed, what they said.

Software engineering is a team based endeavor. Who exactly is responsible for unrecognized vulnerabilities? Everyone? No one? One dude who everyone sorta thought handled security stuff? It's as clear as mud.

View on HN

>Who exactly is responsible for unrecognized vulnerabilities? Everyone? No one? One dude who everyone sorta thought handled security stuff? It's as clear as mud.

Security team with people who do it full time. Betting your security on the one dude who sorta did everything should be criminal.

Aka, not this: http://i.imgur.com/a7S95nG.jpg

>Who exactly is responsible for unrecognized vulnerabilities? Everyone? No one?

Here's a quote from Equifax's early release on the breach [0]:

Equifax said that, it had hired a cybersecurity firm to conduct a review to determine the scale of the invasion.

So, to your question, I'm going with "no one", at least internally.

It's beyond belief (well, not really anymore); but, not only do they not have security covered internally (criminal in itself), but they don't even appear to have a regularly engaged cybersecurity firm. They had to go out and hire one post facto.

[0] https://investor.equifax.com/news-and-events/news/2017/09-07...

What does professional even mean (from her past)? To me it means useless middle management that accomplishes nothing apart from moving numbers around to make them look good.

I always thought "professional" as the sole job description (i.e. not "professional X") was used as an euphemism for "prostitute", so I'm wondering why someone would put it on their resume like that. Did I just learn the word in the wrong context?

What if management doesn't hire a security team? What if management hires incompetent security team?

>What if management doesn't hire a security team?

That's clearly negligence.

>What if management hires incompetent security team?

That's harder to do because you have to establish competence, which has led to a bunch of hazing rituals via whiteboard for general software development and a lot of other insecurities. Being a security professional isn't regulated by law, so you can't check the law to determine if someone's competent. So who's opinion do you trust, and why do you trust their competence? An expert witness, maybe?

>What if management doesn't hire a security team?

"That's clearly negligence."

Great so you just made it illegal or impossible to create a start up, congratulations.

>Great so you just made it illegal or impossible to create a start up, congratulations.

All of this is under the context you'd be handling a lot of PII or sensitive information, in which case, yes, I don't want just any start up to work with PII without some kind of security team.

If you're handling sufficiently private data, then there shouldn't be a low barrier to entry. Starting a medical startup without the requisite expertise would be negligent; I don't see why certain classes of private information should be different.

Real engineers have a system in place for this. It's called "Professional Engineer" and it's managed by NCEES. There is no possible reason that practice cannot directly apply to software engineering, except for the cultural refusal of software engineers to take responsibility for anything.

In fact, there has been a Software Engineering PE exam since 2013. It's not surprising that you don't hear a lot about it because most of the topics on the test would make the average CS student groan (requirements, maintenance, software development lifecycle, etc)

https://ncees.org/ncees-introduces-pe-exam-for-software-engi...

Exam specs: https://ncees.org/wp-content/uploads/2015/07/SWE-Apr-2013.pd...

I think one of the problems is that it's just not societally necessary for 95% of software. If a game is shitty or an order entry system crashes occasionally, nobody dies. Nobody really even cares. Normal social and market mechanisms mean most software at least approaches adequacy.

In at least some of the areas where we really care about software quality (e.g., banking, medical devices) there are existing regulators who will fuck your shit up if you don't take certain aspects of quality seriously. Which is good, but I think it's part of why we don't have an industry-wide program.

Maybe we should take a lesson from Hammurabi:

"If a builder build a house for some one, and does not construct it properly, and the house which he built fall in and kill its owner, then that builder shall be put to death. If it kill the son of the owner the son of that builder shall be put to death." [1]

The occasional execution would probably make people much more serious about unit testing.

[1] http://mcadams.posc.mu.edu/txt/ah/Assyria/Hammurabi.html#Ham...

That would be acceptable if we were talking about buildings, a blue collar job. But if you try to apply it to a white collar executive you're going to run into social resistance of a great magnitude. White collar crime is a social norm and only very rarely even lightly punished. It is, to a degree, expected. White collar crime kills more people and does much more economic damage every year compared to street crime, but our society has established as a norm treating street crime harshly while turning a blind eye to white collar crime. If the builders company gave the builder substandard materials to build with and refused to supply him with the tools needed or the time needed, few will get behind the idea of executing the executive who got his shareholders a 0.1% bump in profitability that quarter through those cuts, no matter who it killed.

Just look at Toyotas "unintended acceleration" case. If their firmware engineers had access to static analysis tools (a few grand for a license), the bug would have been pointed out to them immediately. Instead, Toyota hired inexperienced engineers, deprived them of appropriate tooling, and pushed the cars out to the marketplace where they killed people. The result? Toyota was cleared of any wrongdoing. They're computers. They're too complicated. No one can know how they work.

Yeah, far too much executive crime gets to a "who could have known" resolution when they certainly should have known. Or a "few bad apples" resolution when the system the executives designed created and rewarded bad apples.

I would love to see that change. Right now, though, we're in a big wave of "inequality is great", which I think strongly contributes to this problem. Let's hope that wave crashes, letting us start to hold executives and managers accountable.

I agree in part, but I think there are a few things about this scenario that highlight the problems with software. First is its extreme mutability: you can endlessly patch it, and often have to when vulnerabilities or flaws are discovered. Unfortunately this tends to lower the bar for a first release. Second, if you want to be cost-effective you must leverage many existing components of mostly unknown providence and quality. Finally the security aspect is extremely difficult because both the cost and risk of mounting an attack are extremely low.

> First is its extreme mutability: you can endlessly patch it, and often have to when vulnerabilities or flaws are discovered.

Sometimes, instead of patching, the software should be decommissioned. Search in the news for planes which were grounded when serious flaws are found.

> Second, if you want to be cost-effective you must leverage many existing components of mostly unknown providence and quality.

There're different components for different kinds of requirements. You won't use components for two story buildings, to build a skyscraper.

> Finally the security aspect is extremely difficult because both the cost and risk of mounting an attack are extremely low.

If the risks are high, systems shouldn't be deployed. There's a reason we don't allow people to have machine guns for self defense.

This concept is really not at all portable to software, especially security. It's a tempting analogy, but an invalid one.

No, it's not even an analogy. The precise methods and regulations are almost directly transferable. People are doing it. It works.

It just needs to be industry-wide.

No, it doesn't work at all.

While I agree, how do you apply software engineering practices in a field where a good chunk of the workforce doesn't have formal computer science education?

The same way real engineers work: classroom training in formal engineering, followed by years of experience under an accredited engineer in the field. There is testing at each transition to weed out the skaters.

Software engineers don't need to be computer scientists, in the same way civil engineers don't need to be materials scientists.

There is a bootstrap process, and even in other industries not all engineers are PEs... but all projects are reviewed and stamped by PEs.

Even if the whole workforce had formal computer science degrees, most of us still wouldn't have formal engineering education. The CS programs turn out computer scientists, not professional engineers.

And even if they did have formal engineering education and formal CS degrees and formal whatever most(all?) would still be incapable of writing/designing/implementing bulletproof code.

We have literally centuries of history in engineering in the physical sciences to use as an example.

This industry resists because it's filled with CS folks who either can't or won't believe that there is anything more to engineering than data structures and algorithms trivia.

The management who told the developers "we need this done by tomorrow, figure something out or it won't be good for you"

>The management who told the developers "we need this done by tomorrow, figure something out or it won't be good for you"

Imagine, that management tells their lawyers, we need to do it tomorrow, figure something out? Most likely, lawyers will either refuse to do the work, or will report the management to law enforcement.

truth!

Structural engineers have to deal with these sorts of issues. They do not build a bridge and say "this bridge is safe." They build it and say "this bridge will function within X, Y, and Z parameters for A number of years if maintained in this way" and similar things. They're dealing with a system which is known to not be totally invulnerable. They do it through comprehensive testing, scientific methods, and, above all, through trusting those technical concerns to the total exclusion of business goals. If it is 90% cheaper to use a weaker concrete, they do not substitute it in and cross their fingers. And if the CEO goes behind their back and does the substitution, or he refuses to provide them with the expensive physical simulation software necessary to do their job, or he ignores safety concerns raised by his engineers, that CEO goes to prison and the company is usually destroyed. This is starkly different from technology companies where suggesting such practices is basically asking them to completely restructure their entire organization fundamentally.

How does this work in civil engineering or construction in general. It is also a team based endeavor. The way I understand it only engineers or management needs to go through certification. Basically people who direct the project.

Reply on news.ycombinator.com