Hacker News Reader

Comment by dlnovell | Hacker News Reader

I worked for Hospira last year on the Plum A+ and 360 infusion pumps but not the PCA. I'm a little surprised such a blatant security hole wasn't caught, considering the magnitude of the regulatory environment we worked under. I'd never worked in that kind of environment before, and I left shortly after a successfully defended audit of our software development and tracking process and systems. (Although how successful is the development and tracking process if a year later this "bug" comes out?) My guess is that because we were beaten over the head day in and day out focusing on "if this software delivers the wrong medication the patient is probably going to die", and "if you make a mistake in the development process and in change tracking we can lose the ability to make these devices" that the idea of defending against malicious intent was de-emphasized/overlooked.

View on HN

Question unrelated to the stupidity of supporting telnet as protocol on these devices- Did you guys use formal verification techniques? http://en.wikipedia.org/wiki/Formal_verification

If some one would explain the down-voting to me, I'd love to understand... honestly

1. My question was unrelated to the poor decision the OPs former employer made to use telnet.

2. Formal verification the the gold standard in correctness often used for can't fail things like missiles and satellites.

If I had to guess I would say it relates to the opinion of some engineers that formal verification is only possible in relatively simple systems, and even then only as a mathematical curiosity. As true or not as that may be, the current 'collective wisdom' is more oriented towards automated testing than formal verification, and anything contrary to the popular view gets some natural resistance.

"Beware of bugs in the above code; I have only proved it correct, not tried it." — Donald Knuth

There are no hard rules but this seems a little gratuitous: "Question unrelated to the stupidity of supporting telnet as protocol on these devices"

Probably your tone. Half your post is you telling them they're stupid, and the other half is a patronizing link to very well-known concepts (implying they'd be stupid not to use them, except there are reasons why very few people actually do). It can read like the average know-it-all post plus gratuitous insults.

>Half your post is you telling them they're stupid

No I was saying my question was unrelated to a stupid decision their former employer made....

>and the other half is a patronizing link to very well-known concepts

The link was NOT for the benefit of the OP to whom I was asking a question, it was for reader here that might not know what I was referring too in the question.

> I was saying my question was unrelated to a stupid decision their former employer made

"Former employers" don't usually make decisions in a vacuum -- chances are that engineers were involved at some point, and if it wasn't OP maybe it was a colleague or even a friend. Engineers are as lazy as anyone else, and telnet is an easy protocol to support. Also "let's not talk about my opinion of X" is just a passive-aggressive way of stating your opinion without accepting a possible critique of it, which in itself is off-putting. If you really didn't want to talk about the subject, you wouldn't have mentioned it right away. The only safe use of "let's not talk about X" is as a way to move on after a topic has been discussed and agreement could not be reached.

> The link was NOT for the benefit of the OP to whom I was asking a question, it was for reader

that might as well be, but 1) both OP and HN readers will likely be familiar with the concept and/or can google it themselves, and 2) playing to the peanut gallery is patronizing in itself.

Note I'm not criticizing your positions, I'm just describing how your tone might come across as patronizing. And that's more than enough meta for a week, I think :)

If you have references showing that formal methods are used for missiles and satellites, I would love to see them. [I work on formal methods tools and I am currently working on a usecase from the space industry, but that one is not documented yet.]

I have heard about this from two sources:

1. Papers/case studies the master's of software engineering directory at my university provided while I was in grad. I can try to dig up some of these later if you are interested.

2. Friends who either worked on satellites or airpcraft

Formal verification would not help if the formal or informal design specs called for unauthenticated telnet. It would prove that the entire stack was bullet-proof against memory violations and mathematically pure, and that it would with 100% certainty allow untrusted users to access administrative functions.

>Formal verification would not help if the formal or informal design specs called for unauthenticated telnet

This is why I qualified by question saying such.

This is most likely the problem - the number of cases where patients die from drug delivery mistakes is probably in thousands if not tens of thousands. The cases where someone deliberately administers a dose, via a machine are likely to be zero (because I have not heard of them)

So any cost benefit or risk analysis is going to worry about the drug.

If you require certification of software by some standard, companies will build software that passes the certification standard.

But in my experience, the assumption that a security, quality, or whatever certification process correlates with actually secure, high quality, etc software does not have a lot backing it.

There's a big difference between dotting the i's and crossing the t's according to ISO-9001, and actually caring about software quality, and it seems like the standards make it harder to actually care and actually focus on delivering a good product.

It sounds similar to the idea of teachers "teaching to the test", as opposed to providing an all round education and critical thinking ability.

Reply on news.ycombinator.com