Well, to make the same point in more sober fashion, here we see an important boundary condition of the security problem. Somebody has to build and maintain these systems. Ultimately, the privilege necessary to do that is the same privilege necessary to defeat any security measures they might embody. That's the state of ultimate guardianship. And then we must ask, as Juvenal did a couple of millennia ago, who is to guard the guardians?
The answer, though imperfect, is as good as anything we can devise for other responsible functions. The senior system manager reports to a director or officer who - if they're any good at their job - mediates between the requirements of the organization and those raised by the system manager. It is, without question, a trust relationship, but it's constantly being informed and refreshed through working experience. It's not blind trust. If there's something wrong with this component we call the "senior system administrator" here is where that would normally be detected.
The Terry Childs incident is a recent example where the relationship itself was broken. This would be a failure of senior management. And who watches them?
Indeed. And Multics was developed in the same spirit of open research into operating system design. A lot of great ideas came out of it, including the use of a high level implementation language, the hierarchical filesystem, and the ring model of security. Most of all, when I think of Multics, I think of it providing a set of abstract operating system services, in contrast to other operating systems of the day which were essentially used to sell hardware and to lock customers into that hardware. Historically, Multics was the first step. Unix is derivative, though of course it has since embodied many new ideas and many elegant implementations of existing ideas.
But even more significantly, computer science departments could easily and inexpensively get their hands on a Unix distro tape. Unix was relatively easy to build on supported hardware, and to port to new hardware. Unix thus became the environment of choice for computer science research. Unix was prosaic; Multics remained exotic.
"The embrace of open-source technology by governments may result in... domestic alternatives that would provide secret back-door access"
Oh really? And how exactly is that going to work, given that open source is by definition not secret?
(I get that in a complex code base it may be possible to insert malicious code. But this is true of any code base, hardly a defining characteristic of open source.)
No, the essential insight is that it's not about raw capability but ease of use. The web brought a radical change in ease of use. Social media likewise improve ease of use - though nowhere near as radically, at least worthy of mass interest.
But apart from first-mover advantage and the networking effect, there is nothing exclusive to Facebook that can hold mass interest over the long term. It's nice to have Facebook, but thanks to its history of questionable ethics I have no loyalty to it. You're right that there are other forces at work. People are inclined to become bored and to move on. All it needs is for something sufficiently better to come along.
Hmm. Your incapacity to recognize these things - which will be geared toward their quality of life, not yours - may say more about you than it does about them. Just a thought.
Ow. I don't know any place where algebra and geometry are taught in elementary school, but I certainly can't imagine how anyone could graduate from high school without having routinely exercised this level of math skill along the way.
But is innumeracy the real problem with science education at the university level? I think it goes deeper still. People evidently lack reasoning skills. TFA suggests they lack reasoning skills about science in particular, but I think it's more correct to say that we're failing to teach, and exercise, reasoning skills in general. Of course math education is compromised as well, but it's an effect, not the primary cause.
Far from being just about science or math, reasoning affects everything. Nobody can usefully emerge from a liberal arts education, much less do good science, without formal reasoning skills. How can you compare Kant to Locke, say, if you can't coherently defend your argument?
The material isn't hard to grasp. The essential ideas can be taught at the elementary school level (as indeed, sometimes, they are.) But they're not then something to be put on a shelf and taken down only for special occasions. That, I think, is where our mistake fundamentally lies. Our powers of reason have to be encouraged and exercised at every opportunity. It's not something to be done selectively, but comprehensively, until checking the validity of every argument - including our own internal arguments - becomes reflexive. Then we're in a real position to make sense of the world, whether we're looking at a mathematical derivation or an experimental methodology or a political campaign or a legal defense or an engineering blueprint.
At the moment, about the only real bastion of logical rigor is mathematics. I can see why, on that basis, you'd identify math education as the answer to the issue, but respectfully I hold that it's a special case. It's an interesting case, no doubt about that.
That's really interesting. So there's something going on at the Creation Museum which permits an understanding of natural processes impossible anywhere else?
Because otherwise, why would you insist that someone has to go there in order to "consider the evidence"? Surely the evidence is all around us. If there are observations or experiments to be validated, they can be made anywhere. It doesn't require a pilgrimage to some special place.
Years ago, an acquaintance of mine - a rather whimsical person, given to lateral thinking - read about this "placebo effect" and got an idea.
He had a pharmacist make up some sugar pills and package them nicely. He then took them for minor ailments such as muscle pain and indigestion. He said they were effective more often than not. But the best part, he said, was no side effects. He was pretty pleased about that.
Whenever I travel, I make a point of visiting whatever restaurants are locally regarded as outstanding. I like to call it "culinary espionage". Some of the high points of my life have come out of those experiences, and I always come away with knowledge to inspire my own cooking.
And then there are all those encounters at random, for example stopping at some little tea shop in a tiny village in Scotland one day on a motorcycle trip. It's not the sort of thing I'd seek out at home, but it was a cold bright day and I got to warm up as well as flirt with the staff before I was on my way again. Scones and cream. I didn't learn a thing about cuisine but it sure was fun.
It makes me wonder what people use in place of inductive reasoning.
It's extraordinarily unlikely that the entire computing industry would have evaporated if McDonald's - I mean Microsoft - hadn't come along and created a monopoly for itself. Something else, quite possibly something more open and diverse, and ultimately far more consensual and modular, would have developed instead.
Microsoft gave us Embrace and Extend, deliberate violations of modularity, ruthless crushing of viable competitors, careless disregard of industry practices for security, and a systematic dumbing down of capabilities just as the industry most critically needed to explore those capabilities. It taught a whole industry how to prolong customer pain for profit. I'd say that its net effect, so far is, to have held back progress by at least ten years compared to where we'd be without it.
McDonald's would be more like Microsoft if it systematically set out to compromise the supply chain for the entire restaurant industry. I suppose we should be thankful for small mercies. Imagine going to a fine restaurant and finding nothing but burgers and fries on the menu. Sorry, we can't get the ingredients for coq au vin any more. Sorry, no wine list. Would you like a soft drink instead? Sorry about the cutlery. We had to throw out our fine silverware because it wasn't compatible any longer.
With rare exceptions, there's no reason why a Unix application cannot be installed just fine in userspace. Install it in your home directory. Done. Problem solved.
If a particular application doesn't install properly where you tell it to, that's the fault of the application, not the operating system. And it can be fixed.
"Operating systems today are centered on the idea that applications can be trusted to modify the system, and that users can be trusted to install applications that are trustworthy," says Google VP Sundar Pichai.
Well, that's a pretty fundamental misstatement. In fact most operating systems today - and for the past 30 or 40 years or more - do not allow any entity without elevated privilege to modify the system or install applications.
The glaring exception is Microsoft Windows, and I agree with you that it uses a terrible security model. It violates software engineering principles that go back to the early days of timeshared systems. Back in the days when Bill Gates was answering his own emails, I asked him about this very issue. He told me "customers aren't asking for it". I said, "I'm a customer, and I'm asking." He did not reply.
Most operating systems today are derived from Unix, if not literally then philosophically, which in turn uses a simplified implementation of Multics security rings. Unless a particular derivative has been deliberately engineered to make system files world-writeable, an ordinary user is not going to be able to touch them.
I'm not debating whether such derivatives are a good idea. I'm saying that Sundar Pichai is talking nonsense to suggest that this is some kind of universal problem from which Google has to save us.
So let's talk sense instead. Ignore the red flags being waved about the innate danger of applications. There is innate danger in all kinds of things. In Unix, for example, there's nothing to prevent me from typing a single shell command that accidentally deletes all my files. That's bad luck for me, but unless I want to be denied access to the most basic kind of expressive power, it can happen. I can shoot myself in the foot.
Put that shell command in a script and call it an application. I give you the application, and now you can shoot yourself in the foot with it. Is this the least bit surprising? It's not architecturally different than if you wrote it yourself and then forgot what it did. Who ever said that you should trust a mysterious black box to fulfil any claimed behavior?
So sandbox it, if you can't trust it. We've been heading in that direction for some considerable time. The fact that Microsoft is late to the party is not, in my view, grounds for cancelling the party. Even if Google says that it's hosting an even better party down the street. Maybe it is, maybe it isn't. To me, that's just another empty claim.
It's a sad fact that most people who will want to borrow tools from your lab will not have any concept of returning them, much less of signing them out. I managed a robotics research lab for 12 years, so I know something about how this works.
It's extremely frustrating to someone in the middle of an elaborate assembly or repair project to reach for an essential tool and discover that it has walked away with some unknown person.
Therefore you pretty much have to keep tool cabinets locked, particularly the ones where the more popular hand tools are stored. Invest in cabinets with lots of separately-keyed doors and drawers. Always buy essential hand tools in pairs, and keep the backup set somewhere else.
It also doesn't hurt to keep an open bin in the lab for storing cheap multibit drivers and the like. Buy lots of these, and restock as necessary. That way, people who drop by the lab to borrow something and never return it will go away happy, without causing frustration for your legitimate lab users. It's good politics, as well as allowing you to run an effective lab for the people who really need it.
I think I remember seeing this done at the Vancouver Aquarium about forty years ago. They used small neon lamps, which could be coupled directly to the tank voltage without burning out. It was an elegant approach, requiring few components. Neon lamps work equally well with AC or DC. The eel isn't being stimulated to discharge lethal amounts of electricity, but even small muscle movements will occasionally produce enough voltage to make the lamps flicker.
I've wondered how well LED lamps could be adapted for this purpose. It's too bad that the article is so short on details. LEDs operate at around 2 or 3 volts. You could arrange a hundred of them in series, I suppose. Also, unlike 40 years ago, voltage regulators are widely available as inexpensive ICs. If you powered them from the eel, they could in turn drive the LEDs. There is then no requirement to divide a high voltage among a large number of LEDs. A few would do just as well. With capacitors for current storage, it might even be possible to run the LEDs continuously.
P.S. Alan Turing was gay, as we know now. We all learned of his enormous contributions to computer science, but when I was an undergrad it was never mentioned that the British government crushed him anyway.
Evidently then, highly accomplished and rational people can be in favor of hallucinogens. Not that I ever doubted it, but it's always nice to have evidence.
Hah! It's fundamental computer science, and its use is ubiquitous. It's the equivalent of Watson and Crick's discovery of the helical structure of DNA, which we learn about in elementary school.
You want to celebrate the history of ring theory, now that would qualify as nerdly.
Far ahead of Microsoft by 1985, Xerox had produced an entire family of D-machines based on Interlisp, there were graphical workstations being commercialized out of MIT with Lisp running in microcode, and in the world of mainstream computing Sun Microsystems was producing graphical workstations running Unix and the X Window System.
These platforms weren't providing some crappy pretense at a windowing system. Except for degrees of eye candy, these were as capable as anything we're using today. Microsoft came along and said "hey, look at this great crap we want to sell you". And people bought it. Not on merit, but they bought it.
One useful consequence of the Stuxnet Trojan is to provide a concrete example of how SCADA networks can be exploited. Knowing the details of how Stuxnet works can inform you of how to perform a comparable variety of penetration tests on your own network.
You will then have a measure of how vulnerable your network is to Stuxnet in particular. It's only a circumstantial indicator of how vulnerable your network is generally, which is why I'm not in favor of pen testing except as part of a more comprehensive security initiative. But it can be politically useful at the outset to have some pen testing results to share with management, and politically useful at the conclusion to show that something was measurably improved.
Protective measures directed against Stuxnet alone will not improve your security in general, but if you develop very good general security processes, you should observe that they effectively protect against Stuxnet among others. Security is hard because you can't prove the nonexistence of vulnerabilities. But you can certainly put measures in place, and you can test their effectiveness against known threats.
As an example, you've seen advice here to put some kind of strong isolation between your corporate network and your SCADA network. The extreme example is to have no connection of any kind, whether through firewalls or bastion hosts or whatever, between the networks.
That's good advice. You'd be crazy to ignore it. But you'd also be crazy to believe it sufficient. Stuxnet is a Trojan Horse. Among other strategies for getting onto your SCADA network, it rides on USB sticks. Your network could be completely isolated and yet it would be still vulnerable to attack. A slightly more sophisticated variant of Stuxnet would actively try to build a connection from your SCADA network outward. Since most network design is not geared to protecting against access from within, and since systems on your SCADA network have to be maintained at least occasionally, chances are that the network will be compromised.
So, it's no joke. This is a tough problem, and probably the toughest part is protecting against inside workers from defeating your security measures for the sake of convenience. Get professional help with this, and if I were you I wouldn't trust a single security contractor to get it all right. When you write up your RFP, do it in such a way that it doesn't bind you to selecting one winning bid.
With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.
Most people make a clear distinction between personal use (an activity which is entirely legal in jurisdictions such as mine) and business models based on systematic use of others' work without permission or compensation.
Evidently you don't make that distinction, hence your tendency to treat the two issues as one and then claim that everyone else is being hypocritical.
I draw your attention to the old science-fiction film, "The Day the Earth Stood Still".
There, a representative of an alien civilization caused all nonessential services on Earth to stop, as a demonstration of their political will to bring an end to the nuclear arms race. This was Step One. If we didn't agree to comply within a certain time limit, the aliens would proceed to the more pyrotechnic and messier Step Two.
An "internet kill switch" is not as final as Step Two. It's more like Step One with the bit about "nonessential" removed.
Slashdot Mirror
http://www.youtube.com/watch?v=rX7wtNOkuHo
Well, to make the same point in more sober fashion, here we see an important boundary condition of the security problem. Somebody has to build and maintain these systems. Ultimately, the privilege necessary to do that is the same privilege necessary to defeat any security measures they might embody. That's the state of ultimate guardianship. And then we must ask, as Juvenal did a couple of millennia ago, who is to guard the guardians?
The answer, though imperfect, is as good as anything we can devise for other responsible functions. The senior system manager reports to a director or officer who - if they're any good at their job - mediates between the requirements of the organization and those raised by the system manager. It is, without question, a trust relationship, but it's constantly being informed and refreshed through working experience. It's not blind trust. If there's something wrong with this component we call the "senior system administrator" here is where that would normally be detected.
The Terry Childs incident is a recent example where the relationship itself was broken. This would be a failure of senior management. And who watches them?
Indeed. And Multics was developed in the same spirit of open research into operating system design. A lot of great ideas came out of it, including the use of a high level implementation language, the hierarchical filesystem, and the ring model of security. Most of all, when I think of Multics, I think of it providing a set of abstract operating system services, in contrast to other operating systems of the day which were essentially used to sell hardware and to lock customers into that hardware. Historically, Multics was the first step. Unix is derivative, though of course it has since embodied many new ideas and many elegant implementations of existing ideas.
But even more significantly, computer science departments could easily and inexpensively get their hands on a Unix distro tape. Unix was relatively easy to build on supported hardware, and to port to new hardware. Unix thus became the environment of choice for computer science research. Unix was prosaic; Multics remained exotic.
"The embrace of open-source technology by governments may result in ... domestic alternatives that would provide secret back-door access"
Oh really? And how exactly is that going to work, given that open source is by definition not secret?
(I get that in a complex code base it may be possible to insert malicious code. But this is true of any code base, hardly a defining characteristic of open source.)
You forgot to mention FTP.
No, the essential insight is that it's not about raw capability but ease of use. The web brought a radical change in ease of use. Social media likewise improve ease of use - though nowhere near as radically, at least worthy of mass interest.
But apart from first-mover advantage and the networking effect, there is nothing exclusive to Facebook that can hold mass interest over the long term. It's nice to have Facebook, but thanks to its history of questionable ethics I have no loyalty to it. You're right that there are other forces at work. People are inclined to become bored and to move on. All it needs is for something sufficiently better to come along.
Hmm. Your incapacity to recognize these things - which will be geared toward their quality of life, not yours - may say more about you than it does about them. Just a thought.
Ow. I don't know any place where algebra and geometry are taught in elementary school, but I certainly can't imagine how anyone could graduate from high school without having routinely exercised this level of math skill along the way.
But is innumeracy the real problem with science education at the university level? I think it goes deeper still. People evidently lack reasoning skills. TFA suggests they lack reasoning skills about science in particular, but I think it's more correct to say that we're failing to teach, and exercise, reasoning skills in general. Of course math education is compromised as well, but it's an effect, not the primary cause.
Far from being just about science or math, reasoning affects everything. Nobody can usefully emerge from a liberal arts education, much less do good science, without formal reasoning skills. How can you compare Kant to Locke, say, if you can't coherently defend your argument?
The material isn't hard to grasp. The essential ideas can be taught at the elementary school level (as indeed, sometimes, they are.) But they're not then something to be put on a shelf and taken down only for special occasions. That, I think, is where our mistake fundamentally lies. Our powers of reason have to be encouraged and exercised at every opportunity. It's not something to be done selectively, but comprehensively, until checking the validity of every argument - including our own internal arguments - becomes reflexive. Then we're in a real position to make sense of the world, whether we're looking at a mathematical derivation or an experimental methodology or a political campaign or a legal defense or an engineering blueprint.
At the moment, about the only real bastion of logical rigor is mathematics. I can see why, on that basis, you'd identify math education as the answer to the issue, but respectfully I hold that it's a special case. It's an interesting case, no doubt about that.
That's really interesting. So there's something going on at the Creation Museum which permits an understanding of natural processes impossible anywhere else?
Because otherwise, why would you insist that someone has to go there in order to "consider the evidence"? Surely the evidence is all around us. If there are observations or experiments to be validated, they can be made anywhere. It doesn't require a pilgrimage to some special place.
Years ago, an acquaintance of mine - a rather whimsical person, given to lateral thinking - read about this "placebo effect" and got an idea.
He had a pharmacist make up some sugar pills and package them nicely. He then took them for minor ailments such as muscle pain and indigestion. He said they were effective more often than not. But the best part, he said, was no side effects. He was pretty pleased about that.
Hear hear!
Whenever I travel, I make a point of visiting whatever restaurants are locally regarded as outstanding. I like to call it "culinary espionage". Some of the high points of my life have come out of those experiences, and I always come away with knowledge to inspire my own cooking.
And then there are all those encounters at random, for example stopping at some little tea shop in a tiny village in Scotland one day on a motorcycle trip. It's not the sort of thing I'd seek out at home, but it was a cold bright day and I got to warm up as well as flirt with the staff before I was on my way again. Scones and cream. I didn't learn a thing about cuisine but it sure was fun.
Let me see if I understand this. You had entire cities without any restaurants at all before McDonald's came along? That's amazing.
It makes me wonder what people use in place of inductive reasoning.
It's extraordinarily unlikely that the entire computing industry would have evaporated if McDonald's - I mean Microsoft - hadn't come along and created a monopoly for itself. Something else, quite possibly something more open and diverse, and ultimately far more consensual and modular, would have developed instead.
Microsoft gave us Embrace and Extend, deliberate violations of modularity, ruthless crushing of viable competitors, careless disregard of industry practices for security, and a systematic dumbing down of capabilities just as the industry most critically needed to explore those capabilities. It taught a whole industry how to prolong customer pain for profit. I'd say that its net effect, so far is, to have held back progress by at least ten years compared to where we'd be without it.
McDonald's would be more like Microsoft if it systematically set out to compromise the supply chain for the entire restaurant industry. I suppose we should be thankful for small mercies. Imagine going to a fine restaurant and finding nothing but burgers and fries on the menu. Sorry, we can't get the ingredients for coq au vin any more. Sorry, no wine list. Would you like a soft drink instead? Sorry about the cutlery. We had to throw out our fine silverware because it wasn't compatible any longer.
Look, I'm not an American, I'm just looking over the fence and respectfully trying to make sense of what I'm seeing. But that's just obscene.
Yes, exactly!
With rare exceptions, there's no reason why a Unix application cannot be installed just fine in userspace. Install it in your home directory. Done. Problem solved.
If a particular application doesn't install properly where you tell it to, that's the fault of the application, not the operating system. And it can be fixed.
"Operating systems today are centered on the idea that applications can be trusted to modify the system, and that users can be trusted to install applications that are trustworthy," says Google VP Sundar Pichai.
Well, that's a pretty fundamental misstatement. In fact most operating systems today - and for the past 30 or 40 years or more - do not allow any entity without elevated privilege to modify the system or install applications.
The glaring exception is Microsoft Windows, and I agree with you that it uses a terrible security model. It violates software engineering principles that go back to the early days of timeshared systems. Back in the days when Bill Gates was answering his own emails, I asked him about this very issue. He told me "customers aren't asking for it". I said, "I'm a customer, and I'm asking." He did not reply.
Most operating systems today are derived from Unix, if not literally then philosophically, which in turn uses a simplified implementation of Multics security rings. Unless a particular derivative has been deliberately engineered to make system files world-writeable, an ordinary user is not going to be able to touch them.
I'm not debating whether such derivatives are a good idea. I'm saying that Sundar Pichai is talking nonsense to suggest that this is some kind of universal problem from which Google has to save us.
So let's talk sense instead. Ignore the red flags being waved about the innate danger of applications. There is innate danger in all kinds of things. In Unix, for example, there's nothing to prevent me from typing a single shell command that accidentally deletes all my files. That's bad luck for me, but unless I want to be denied access to the most basic kind of expressive power, it can happen. I can shoot myself in the foot.
Put that shell command in a script and call it an application. I give you the application, and now you can shoot yourself in the foot with it. Is this the least bit surprising? It's not architecturally different than if you wrote it yourself and then forgot what it did. Who ever said that you should trust a mysterious black box to fulfil any claimed behavior?
So sandbox it, if you can't trust it. We've been heading in that direction for some considerable time. The fact that Microsoft is late to the party is not, in my view, grounds for cancelling the party. Even if Google says that it's hosting an even better party down the street. Maybe it is, maybe it isn't. To me, that's just another empty claim.
It's a sad fact that most people who will want to borrow tools from your lab will not have any concept of returning them, much less of signing them out. I managed a robotics research lab for 12 years, so I know something about how this works.
It's extremely frustrating to someone in the middle of an elaborate assembly or repair project to reach for an essential tool and discover that it has walked away with some unknown person.
Therefore you pretty much have to keep tool cabinets locked, particularly the ones where the more popular hand tools are stored. Invest in cabinets with lots of separately-keyed doors and drawers. Always buy essential hand tools in pairs, and keep the backup set somewhere else.
It also doesn't hurt to keep an open bin in the lab for storing cheap multibit drivers and the like. Buy lots of these, and restock as necessary. That way, people who drop by the lab to borrow something and never return it will go away happy, without causing frustration for your legitimate lab users. It's good politics, as well as allowing you to run an effective lab for the people who really need it.
I think I remember seeing this done at the Vancouver Aquarium about forty years ago. They used small neon lamps, which could be coupled directly to the tank voltage without burning out. It was an elegant approach, requiring few components. Neon lamps work equally well with AC or DC. The eel isn't being stimulated to discharge lethal amounts of electricity, but even small muscle movements will occasionally produce enough voltage to make the lamps flicker.
I've wondered how well LED lamps could be adapted for this purpose. It's too bad that the article is so short on details. LEDs operate at around 2 or 3 volts. You could arrange a hundred of them in series, I suppose. Also, unlike 40 years ago, voltage regulators are widely available as inexpensive ICs. If you powered them from the eel, they could in turn drive the LEDs. There is then no requirement to divide a high voltage among a large number of LEDs. A few would do just as well. With capacitors for current storage, it might even be possible to run the LEDs continuously.
P.S. Alan Turing was gay, as we know now. We all learned of his enormous contributions to computer science, but when I was an undergrad it was never mentioned that the British government crushed him anyway.
Evidently then, highly accomplished and rational people can be in favor of hallucinogens. Not that I ever doubted it, but it's always nice to have evidence.
Hah! It's fundamental computer science, and its use is ubiquitous. It's the equivalent of Watson and Crick's discovery of the helical structure of DNA, which we learn about in elementary school.
You want to celebrate the history of ring theory, now that would qualify as nerdly.
Far ahead of Microsoft by 1985, Xerox had produced an entire family of D-machines based on Interlisp, there were graphical workstations being commercialized out of MIT with Lisp running in microcode, and in the world of mainstream computing Sun Microsystems was producing graphical workstations running Unix and the X Window System.
These platforms weren't providing some crappy pretense at a windowing system. Except for degrees of eye candy, these were as capable as anything we're using today. Microsoft came along and said "hey, look at this great crap we want to sell you". And people bought it. Not on merit, but they bought it.
One useful consequence of the Stuxnet Trojan is to provide a concrete example of how SCADA networks can be exploited. Knowing the details of how Stuxnet works can inform you of how to perform a comparable variety of penetration tests on your own network.
You will then have a measure of how vulnerable your network is to Stuxnet in particular. It's only a circumstantial indicator of how vulnerable your network is generally, which is why I'm not in favor of pen testing except as part of a more comprehensive security initiative. But it can be politically useful at the outset to have some pen testing results to share with management, and politically useful at the conclusion to show that something was measurably improved.
Protective measures directed against Stuxnet alone will not improve your security in general, but if you develop very good general security processes, you should observe that they effectively protect against Stuxnet among others. Security is hard because you can't prove the nonexistence of vulnerabilities. But you can certainly put measures in place, and you can test their effectiveness against known threats.
As an example, you've seen advice here to put some kind of strong isolation between your corporate network and your SCADA network. The extreme example is to have no connection of any kind, whether through firewalls or bastion hosts or whatever, between the networks.
That's good advice. You'd be crazy to ignore it. But you'd also be crazy to believe it sufficient. Stuxnet is a Trojan Horse. Among other strategies for getting onto your SCADA network, it rides on USB sticks. Your network could be completely isolated and yet it would be still vulnerable to attack. A slightly more sophisticated variant of Stuxnet would actively try to build a connection from your SCADA network outward. Since most network design is not geared to protecting against access from within, and since systems on your SCADA network have to be maintained at least occasionally, chances are that the network will be compromised.
So, it's no joke. This is a tough problem, and probably the toughest part is protecting against inside workers from defeating your security measures for the sake of convenience. Get professional help with this, and if I were you I wouldn't trust a single security contractor to get it all right. When you write up your RFP, do it in such a way that it doesn't bind you to selecting one winning bid.
With rare exceptions, all network protocols require two-way traffic. So this idea of a "data diode" is not possible to implement in practice. People who claim otherwise are trying to sell you snake oil.
Not at all.
Most people make a clear distinction between personal use (an activity which is entirely legal in jurisdictions such as mine) and business models based on systematic use of others' work without permission or compensation.
Evidently you don't make that distinction, hence your tendency to treat the two issues as one and then claim that everyone else is being hypocritical.
"Most corrupt department" was the hardest fought competition this whole decade.
Hmm. Well, at least there was competition, wasn't there? I mean, surely somewhere an RFP was issued for that.
I draw your attention to the old science-fiction film, "The Day the Earth Stood Still".
There, a representative of an alien civilization caused all nonessential services on Earth to stop, as a demonstration of their political will to bring an end to the nuclear arms race. This was Step One. If we didn't agree to comply within a certain time limit, the aliens would proceed to the more pyrotechnic and messier Step Two.
An "internet kill switch" is not as final as Step Two. It's more like Step One with the bit about "nonessential" removed.