'Incompetent Developers' Blamed For NZ Patient Privacy Breach of COVID-19 Vaccine Booking Systems (stuff.co.nz) 54
An anonymous reader writes: The New Zealand Ministry of Health has launched a "sweeping review" of the nation's COVID vaccine-booking system, after a data breach led to exposure of personal information for more than 700 patients. A whistleblower reported over the weekend that they could access information about other patients, which was "readily accessible within the public-facing code of the website" -- apparently hard coded.
As a response, the Ministry of Health has ordered a review of all systems made by the developer, Valentia Technologies, which also makes software used by the Ambulance service, many GP practices, and the managed isolation and quarantine system. "It is not a coding error. It is incompetence. The developer who developed this is incompetent ... This is basic stuff," said the man who spotted the booking system problem.
"The source code of the website, flagged a few concerning features, including someone's name, and an NHI number hard coded into the website, for what reason? I don't know," he said. "We could see everyone's details. We skimmed through, we didn't look at names, but their names, dates of birth, NHI numbers for those who entered them, contact details, where they were getting their vaccinations, what time they were vaccinated."
He said it appeared that Canterbury DHB had used a modified internal system to create the booking system. "You can tell by the source code, this was never meant to be a public facing website. This was only for people to use on like iPads, in doctors' surgeries, it was not supposed to be for this."
As a response, the Ministry of Health has ordered a review of all systems made by the developer, Valentia Technologies, which also makes software used by the Ambulance service, many GP practices, and the managed isolation and quarantine system. "It is not a coding error. It is incompetence. The developer who developed this is incompetent ... This is basic stuff," said the man who spotted the booking system problem.
"The source code of the website, flagged a few concerning features, including someone's name, and an NHI number hard coded into the website, for what reason? I don't know," he said. "We could see everyone's details. We skimmed through, we didn't look at names, but their names, dates of birth, NHI numbers for those who entered them, contact details, where they were getting their vaccinations, what time they were vaccinated."
He said it appeared that Canterbury DHB had used a modified internal system to create the booking system. "You can tell by the source code, this was never meant to be a public facing website. This was only for people to use on like iPads, in doctors' surgeries, it was not supposed to be for this."
I this is the norm (Score:5, Insightful)
Agreed (Score:5, Insightful)
Part of what I do is training devs to do code review, and I do some security reviews myself. Code sucks. Most code is pretty much crap.
A couple of weeks ago I attended a sales demo of an expensive system that's supposed to look for security problems in source code (static analysis). It's one of the most-used commercial static analysis tools. I looked at the remediation suggestions (fixes) for three of the problems they demoed. Of the three, one was half wrong and the other two were fully wrong. So even the tool that's supposed to teach programmers the right way to do things itself scored 17%.
It doesn't have to be this way. When building things other than software systems, we have a process that works for specifying a design that is correct, a design that will meet the requirements. That process is called "engineering". The process of engineering is notable by its use of well-established principles, such as formulas for calculating load-bearing strength, in order to specify a design that will meet requirements. There is no reason software systems can't be engineered, just like other constructions are.
Re: (Score:3)
but agile and devops!
and who cares about the whole test cycle and stuff anyways, we fix things to fast to care. And who cares about long term stability we want impressive features and stuff management can brag to upper management about.
Re: (Score:2)
Re: (Score:3)
May I ask the name of the the tool? There are good ones out there but they are pricey and require quite a time investment. Coverity is amazing, and SonarQube is less powerful but super easy to integrate into a CI system. I dismissed Fortify on Demand when it flagged every use of the word "key" as possible security problem. With Coverity, it is fun to watch a skeptical developer start with "Oh, that's not really a problem because the tool doesn't know that..." then 5 minutes later go "Oh we need to fix t
Re: (Score:2)
Re: (Score:3)
Veracode is the one that had bad recommendations. :)
Their rep said they focus most of their energy on integrations.
It shows. It looks like they do a good job integrating with a lot of different stuff. It's just that they make it easy to integrate their poor quality product with all of your other systems.
From your post, it sounds like Coverity may be the one we should look at. Personally I'd go open source but my boss tends to prefer to pay for a well-supported product.
In our case, sast is new to our devs
Re: (Score:3)
There are a few reasons... (Score:3)
There is no reason software systems can't be engineered, just like other constructions are.
The primary reason they aren't is money, which is also the secondary reason. And the tertiary. I worked in a place that did software development that way. Gather all the requirements. Then define exactly what the software does so you can figure out what things are required that weren't written down. Then, having spent 1 or 2 years iterating this process (for anything non-trivial)to lock down all the requirements,
Engineering isn't a synonym for monolithic (Score:2)
It seems to me you described a a process that developed a large system as one big monolithic thing, rather than iteratively building modules or functions (aka agile).
That has little to do with the difference between engineering a module vs sloppily throwing something together that seems like it kinda mostly works, most of the time.
Come to think of it, most of the software projects have been a process of build, release, release, build, release, build, release. They've also been engineered to one degree or an
Re: (Score:2)
Engineering has nothing to do with security.
I can assure you the World Trade Center was perfectly engineered and all the load bearing strength calculations were right.
But engineering could not save them against someone crashing planes into the side of the buildings. Engineering cannot save your padlock from being open by raking it, or stop you from being assaulted just outside of your perfeclty good house with an electric fence.
Engineering will produce whatever you ask for (Score:2)
Engineering is a process that designs things to actually meet the requirements. (And not waste a lot of time and money doing things that aren't necessarily in order to meet the requirements). If reliability aka security is part of the requirements, engineering for a robust system will give you a design for a robust system.
> Engineering cannot save your padlock from being open by raking it
Funny you mention that; I used to be a locksmith.
Try raking a Masterlock #3. You'll probably find that it's pretty e
Re: (Score:2)
googling medeco lock vulnerability says that they can be opened in 30 seconds
they are probably very secure, but you have to keep updating your -physical- lock if you are very lucky, and your padlock provider decides to keep up with the security community
and god help you if you put the padlock on a fence and someone jumps over the fence. all that engineering for nothing
problem with engineering is that you have to list the requirements BEFOREHAND; if someone comes up with a new way of raking your padlock, all
Re: (Score:2)
Re: (Score:2)
It's shitty to put all the responsibility for this on developers. They can't really stop management from doing shortcuts like; "let's reuse the inhouse solution we made for another client".
I work with security reviews, secure coding education and pen.testing. Developers are rarely the problem, they want to produce good solutions and are happy to get help doing that. But you need support from management and the organisation in order for
Re: (Score:2)
There is a key difference. It took me a long time working as a software developer to realize this difference.
Engineering in other fields is driven by standards. 90% of engineers in other fields basically apply well known solutions. Regular engineers aren't out there building a new kind of experimental bridge for example. There are bridge standards and a few variables they might play around with.
I'm exaggerating this for impact, so please understand I am not in any way downplaying the job of regular enginee
Re: (Score:2)
> For example, this is a basic appointment booking website. Let's be frank. This is not a new amazing design. This is a well solved problem by so many companies, both in the cloud and enterprise deployments.
Exactly. Fairly early in my career, I was taking various jobs programming all different kinds of web sites. Stores selling various things, where you could search by different parameters, porn sites, mailing list sites ...
I just lied to you. I said "programming all different kinds of web sites". That
Re: (Score:2)
So why aren't you rich?
One of my former neighbors became (perhaps briefly) very wealthy by founding a company that automated building e-commerce websites for people.
Re: (Score:2)
> So why aren't you rich?
What makes you think I'm not? :)
I would be about 20X as rich if I had done a few things better in running my companies.
Re: I this is the norm (Score:2)
Hehe. I went to China a couple of years back, and when I was coming home, I was doing my damndest to check into my flight at the airport in Shanghai. I kept poking the screen to type in my confirmation code, but it would not do it. It took me a few minutes of making sure I wasn't posing my mind before I realized that while every on-screen keyboard I've ever encountered in the US allows a tap anywhere on the bounding box of the key to count, the one in China required a tap directly on the glyph inside the ke
Re: (Score:2)
Re: I this is the norm (Score:2)
It was a standard 15 or 17 inch screen, same as here. With large gaps between the keys. And tiny glyphs inside them.
Re: (Score:2)
The problem is that there is almost no way to know how to do build something the right way. Today's tech stack is a gospel from Google, Facebook, Amazon and if it is web-based it is mostly Google. And Google keeps changing it so that everyone is always catching-up.
You can't read the books because by the time a book comes out the tech is already dated. You can't read it online because there is hardly any documentation anymore (again, thanks to Google).
The current tech world is designed to make sure intellige
Re: (Score:2)
Re: (Score:2)
AWS/Cloud is pretty much required if you are out building largescale stuff.
Re: (Score:2)
Re: (Score:2)
It is a requirement if you are giving an interview dumbass.
Re: (Score:2)
Dude you are retarded. Why don't you go drink several gallons of coffee and see a therapist while you are at it, and THEN read what what I aid.
Re: (Score:2)
Login so I can plonk you henceforth. It is pretty obvious you have no fucking clue of the market.
Let me know when your acid trip ends and we can look at what actually is said together.
Re: (Score:1)
and with an NHI number I can bill the govment (Score:1)
and with an NHI number I can bill the govment for fake doctor servers at least the patient get's an zero bill.
Re: Yawn. (Score:3)
Only as good as the people hiring (Score:5, Insightful)
Yes, there can but shitty developers but the developer is just doing their best. The real question is who hired this person and why? Is HR actually completely clueless when it comes to hiring developers? Fire HR and find someone who can vet developers. Was it management who moved an inexperienced developer to a critical role? Fire management for being complete boobs.
This person clearly wasn't qualified for the position so the question is, who the fuck put an unqualified developer in that position?
Re: (Score:2, Insightful)
Re: (Score:3)
This person clearly wasn't qualified for the position so the question is, who the fuck put an unqualified developer in that position?
(Training Instructor at the Six-Minute-Code-For-Dummies Institute) "I don't know what you're talking about. My graduates are of the highest caliber.."
Re: (Score:2)
Also, money. They're probably too cheap to get good developers.
Re: (Score:2)
That, and project management pushing to get things done as fast as possible:
Human Error ?!? (Score:2)
Institutional Problems (Score:4, Interesting)
This is just another management failure, but I'm not confident anything will change.
Re:Institutional Problems (Score:4, Informative)
Rule #1 of coding quick and dirty systems : (Score:3)
Never every assume your quicky implementation won't become the production deployment. I've seen it happen many times.
There's the first quicky version that worked and persuaded management to go forward with the application development.
Then there's the real application. It doesn't work yet, it's late and the external vendors are playing hardball with the pricing.
I've seen this happen on my own stuff. A wrote proof-of-concept code for a thing. The plan was to outsource the real thing to someone else.
Plan A: Sign with vendor X
Plan B: Sign with vendor Y
Plan C: We're screwed and need to buy some servers and put the quicky code online.
Now this was not an online tamagochi game. It was a CA - A certificate authority. It's a good thing I didn't assume I didn't need to do security due dilligence on the original code.
Re: (Score:2)
Never every assume your quicky implementation won't become the production deployment. I've seen it happen many times.
So true.
Me: That concludes my demo. Keep in mind this is proof of concept. It can't stand up to load and lacks proper security.
Manager: Let's use this. No need to expend more resources on it.
Copy Paste (Score:3)
who is to blame (Score:3)
Who is to blame if you hired developers and no security experts to train them how to code defensively. Or to advise project managers on how to add threat modeling to your development process.
I guess it's just unavoidable. We'll throw our hands up and let the same damn thing happen the thousandth time in a row. Can't be helped.
Government no smarter than average consumer (Score:2)
Never meant to be public? Come on, really? Unless this was meant to run on an air-gapped machine, zero-trust security approach should apply - everything outside of your own process is untrusted, sensitive data needs to be protected, configuration and calibration data needs to be authenticated and possibly encrypted, etc, etc. .
Of course, I suspect the problem is the government official making the choice based on cost. When looking at:
$2M - working booking system
$30M - looks the same as the $2M option, but u
Re: (Score:2)
In-game skins == pay for "something new"
Security patch == pay for your error (same as cars recalls... free of charge because it's a manufacturing error)
Nope. Shitty management and bad planning. (Score:4, Insightful)
Don't blame your incompetence in leadership and software project planning on your underpaid and overworked junior coding n00bs.
Incompetent Developers (Score:3)
Great. Now our HR department will be looking for candidates with 5 years experience working with Incompetent.
And yet politicians want everyone to code (Score:2)
Oddly enough, dumbass politicians seem to think that coding requires no intelligence or skill or education. Maybe coal miners and pipeline workers can become doctors or lawyers too.