10 ms·
It's time to have a mandatory certification for people who develop critical systems. After such certification, you can consider such an implementation a malprac
by solomatov 9y ago
It's time to have a mandatory certification for people who develop critical systems. After such certification, you can consider such an implementation a malpractice, and sue them for it (of course the penalty is paid by the insurance company which sold the malpractice insurance).
Doctors, lawyers, and many other professions have such system, why can't we have it as well?
- ben_jones 9y agoDevelopers don't control budgets and deadlines at large companies, management does. So what does this "certified" individual do when he's given a project without resources allocated for proper security auditing? Does he intentionally get fired for refusing the assignment? That works if he has bountiful savings, no mortgage, no kids. Surely no unethical contracting company will pick up the job after he leaves...
- rhizome 9y agoIf only there were more software jobs out there, then they wouldn't be hemmed in so intractably.
- ranci 9y agoNice red herring
- peoplewindow 9y agoFinding another software job is insufficient. You need to find one that gives its employees the time and space they say need regardless of other competitive or financial pressures. Not so easy.
- geofft 9y agosomething something software developers need a union something
- mikeash 9y agoHow does it work with lawyers or engineers?
- rhizome 9y agoAs licensed professionals, they work under the knowledge that there are practices and outcomes that can cause them to lose their licenses.
- noobermin 9y agoOnce again, may be it is time for such a thing to exist for software engineers who aren't web devs.
- rhizome 9y agoIt's been suggested, but AFAIK some find fundamental aspects of software development to make it hard if not impossible for it to ever be True Engineering. I'm pulling this out of my back pocket on a Saturday evening, so Google for more, but there are arguments on both sides that go back some years. Heck, google "is software development engineering" and you'll find long Quora threads on the topic.
- peoplewindow 9y ago"who aren't web devs"? Why throw that in? This breach occurred through a hacked website, as do so many others.
- emodendroket 9y agoThat doesn't really seem comparable.
- mikeash 9y agoWhy not? The proposal was to license software engineers (at least for "critical" systems) the same way as those.
- bspn 9y ago> Developers don't control budgets and deadlines at large companies, management does. True, but that's why good organizations almost always have technical people on the management team who advocate for the technical arm of the company and ensure that it is appropriately resourced.
- KyeRussell 9y agoSeems very beside the point. Equifax obviously isn't a good company.
- avip 9y agoI may agree, but Equifax is by no reasonable definition "a critical system".
- Orangeair 9y agoTell that to people who are denied loans thanks to credit reporting agencies.
- jdale27 9y agoThere are levels of "criticality". Credit monitoring is in a different category from, say, spacecraft or nuclear power plants. But if a security breach can lead easily to identity theft, and therefore to a catastrophic compromise of one's financial stability, that should require some higher level of mandatory certification.
- vlunkr 9y agoI don't know what definition of "critical" we're going with, but the fact that they have the SSN of basically every American makes them an important weak point.
- SubiculumCode 9y agoIt is really time to move past SSNs
- ranci 9y ago"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.
- eberkund 9y agoThe management who told the developers "we need this done by tomorrow, figure something out or it won't be good for you"
- ranci 9y agotruth!
- solomatov 9y ago>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.
- stonogo 9y agoReal 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.
- avenoir 9y agoWhile 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?
- emodendroket 9y agoThat's not what's needed. I guarantee you if the companies responsible for these leaks and their executives faced real penalties with teeth things would get better, licensure scheme or no.
- anigbrowl 9y agoMaybe it is, but that's also just a way of trying to push the costs onto the low-level employees. the attitudinal problem here is with the senior management and shareholders, who are the actual responsible parties. If they really cared they'd have established such a certification or announced an intention to adhere to some existing standard.
- adekok 9y agoLike PCI compliance? Ask people who've gone through that process how rigorous it is...
- paulddraper 9y agoIt's rigorous, but in all the wrong ways. At $DAY_JOB our security falls into two buckets (1) PCI and (2) stuff that keeps us secure. IDK if it's possible to have a widely accepted security standard that isn't checking nonsensical and out-of-date boxes.
- unscaled 9y agoWell, it could be worse: 1) Stuff that keeps you insecure (a.k.a ISO 27001 ISMS stuff) 2) Stuff that somewhat helps, but is covered by fluff (a.k.a. PCI-DSS) 3) Stuff that actually keeps you secure. PCI-DSS at least gives you a sledgehammer to convince lazy low-level managers to dump ciphers like RC4 and encrypt some of their data. It's not utopia, and it does err on the side of perpetuating banks' infatuation with 3DES too much, but I saw getting good stuff done by using it as an excuse. You still need to have a competent security team of course, but it helps them not being ignored. Well, sometimes.
- paulddraper 9y agoPCI is why we have weak passwords that we have to reinvent every 90 days.
- katzgrau 9y agoThe sheer scale is incomparable. Comparing a doctor's mistake during a surgery doesn't quite compare to losing the data of 147 million. "Critical systems" developers would need astronomically expensive insurance to even exist, and therefore prohibitively high salaries. I personally believe there should be some measure of a corporate death penalty to emphasize the responsibility involved though.
- freeone3000 9y agoIf the risk to such a thing failing is so large, this seems a point against your argument. We MUST be able to reduce the risk of such systems failing, and do so provably. If we cannot reduce the cost, we must reduce the risk, such that the calculation makes the system affordable again.
- deleted 9y ago[deleted]
- solomatov 9y ago>The sheer scale is incomparable. Comparing a doctor's mistake during a surgery doesn't quite compare to losing the data of 147 million. Then, companies shouldn't have such a high concentration of risks in one place. The problem wouldn't be such a disaster if just SSN wasn't enough to get a loan. For example, if we had a password in addition to SSN (stored in a hashed form), the problem would be much less severe.
- wpietri 9y agoI'm not a big fan of most tech certification efforts. They mainly document attendance at classes and/or ability to regurgitate trivia. They also tend to reward formality instead of quality, and slow progress. Consider, for example, if we'd had this sort of certification 10 years ago. It'd likely be filled with waterfall-style process requirements. Those don't actually increase safety; they just look impressive. I'd be happier to see licensing and accountability. But it would have to have significant teeth. E.g., companies can't build systems of type X without somebody licensed. If there are problems with the system, then the person with the license faces personal fines and risk of suspension or loss of license. That would be less bad than certification, but it could still substantially slow industry progress if the licensing review board had a conservative tilt to it. Of course, the real problem with most places is not engineers not knowing. It's with managers who push for things to happen despite what engineers advise. Licensing could sort of fix that, in that it could force engineers to act like professionals and refuse to do negligent work. But it still lets shitty managers off the hook. So what I'd really like to see is a regulatory apparatus for PII. In the same way that the EPA comes after you for a toxics spill, an agency would come after you for a data spill. They investigate, they report, they impose massive fines when they think it's warranted. And when they do ream a company for negligent management of data, executives at all the peer companies get scared and listen to the engineers for a while.
- otakucode 9y agoWe certainly can have such a thing, and exactly that has been discussed for well over a decade (probably much longer, but I'm only so old) in the ACM, among other organizations. It's a difficult issue. Creating a set of standards and a certification process has a lot of pitfalls. Failing to create such a process has a lot of pitfalls. Knowingly choosing to step into one set of pitfalls over another is never a comfortable choice and people are generally very bad at it until something really, really bad happens that gives a large number of people enough irrational fear of one option to push them toward the other (and they will rabidly and aggressively oppose any discussion of acknowledging or compensating for the pitfalls they're moving toward in that case - they feel entitled to a 'clean' option and they will demand you pretend the option they're going for is that). Rather than compare it to doctors, lawyers, etc, I would compare it to structural and civil engineers. Those are the sorts of regulations we require. If a CEO of a construction company ignores warnings given by one of his structural engineers while building a bridge, that CEO is held responsible for criminal negligence and he is put in a prison for a long time. The same needs to happen for technology company management who cut the development timeline, deprive developers of adequate tools and work environment, and who hire inexperienced development staff simply because they're cheap. Would you like to drive across a bridge if you knew the company operated the way tech companies operate? Viewing their engineers as a cost center to be reduced, as little more than spoiled typists whose technical concerns are always viewed as unimportant in the face of business goals, crammed into office spaces proven by over 1000 studies to damage productivity, and constantly pressured to rush through everything in defiance of basic biological fact that human beings are not capable of extended periods of mental exertion especially in the face of constant interruption? Would it make you more or less confident in that bridge if there were court precedent for companies resulting in peoples deaths being let off without punishment with such practices? That's the situation we're in.
- mdip 9y agoThe best and most legendary developers still make mistakes that cause this kind of thing. And certified or not, all developers run into deadlines that result in production of imperfect code (and that word is key -- code has to be perfect ... always ... if that's your only defense). While writing secure code using best practices is a big part of the security equation, any company that stops there will be pwned. The most oft-used illustration in securing systems is "the onion". You need to layer on protections, from firewalls (both traditional and application layer), to solid access control to simply making sure that systems are configured properly (just hit up any SSL testing site and pop in just about every non-tech business' main web page - might as well just make the result page static with a big letter "F"). Heck, even technologies like ASLR/DEP are an extra layer. The goal is to make an attacker have more than a few hurdles to hop[0] in order to breach and to ensure that if you are breached, the value of what is exfiltrated is either worthless (i.e. properly hashed passwords) or detected and stopped before it's all gone (partial breaches aren't awesome, but it's easier to explain 1% of your data being leaked than it is to explain all of it being leaked). [0] I've always liked that sarcastic advice of "If you and your friend encounter a bear ... run ... you needn't out run the bear, you only need outrun your friend". If you make things difficult enough, your attacker might move on to another target. And hopefully, if they succeeded in breaching part of the defenses, someone will discover it before they return and shore up what wasn't "perfect".
- wdr1 9y agoVarious tech industries do have it. https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Security_Standard https://en.wikipedia.org/wiki/Payment_Card_Industry_Data_Sec...