What’s interesting about the Florida water system hack is that we heard about it
krebsonsecurity.com
krebsonsecurity.com
Most municipal infrastructure automation is run by SCADA systems. SCADA systems are designed to be closed ecosystems by default, which means they don't have access to the internet. Cables are run and point to point connections are made to transport these signals. If you've seen a big shiny aluminum box on the side of the road, that's a SCADA system.
Consumer demand has changed a lot since SCADA was first thought up. These days people want to be able to log into a portal and see their billed water usage by the day. Cities want to be able to turn off a meter remotely at the click of a button rather than rolling a truck. They want pressure loss, contaminate, and fault detection. They'd like to balance pressure in the water system dynamically. They want to perform detailed reports on total water loss, which means instrumenting pumps, retrieving telemetry data, auditing that data against every home usage, identifying faults, and producing a report out of it. All of these things don't work very well with closed ecosystems as they generally require a certain amount of external information. In response, cities have either crafted their own devices because they don't have the money to hire an integrator to design and produce them a device that will survive extreme weather conditions, be fault tolerant, make minimal use of power, and employ standard security measures or they hire an integrator. Even certain integrators can do shotty work.
The takeaway from this isn't that SCADA is bad or the infrastructure version of "the sky is falling!". It's that we desperately need to be thinking about how different generations of systems can be modularized and be built upon to minimize cost while maximizing security, capability growth, and reliability.
For the folks talking about "who tests what", I don't know what I can talk about in regards to specific programs but I feel confident that I can say that the FBI tracks this vigorously and works with companies that work in public infrastructure.
Aside from the technical limitations of some of these platforms there's a cultural issue. Controls engineers aren't trained in Infosec. The software and device manufacturers are developing better products, but I don't feel like there's a "secure by default" initiative. It still takes skills on the part of the installer.
I still see a huge lack of consideration for security in the people actually installing gear (at least in the small-to-medium sized manufacturing companies and small municipalities I work around). The biggest concerns are making sure vendor's support personnel can troubleshoot remotely because frequently the on-site personnel have limited skills. That's how we end up with TeamViewer, VNC forwarded thru routers, etc.
That's an excellent call-out. City salaries will almost never employ the type and level of personnel to do anything beyond maintaining the status quo typically.
Even if you had the funds to employ highly trained engineers, most sites couldn't give them enough work to keep their skills sharp.
For instance, most SCADA and IT vendors can do a lot better than (probably not patched) Windows 7 with TeamViewer. However, there's two prevailing attitudes that interfere:
1. We're not big like Boston or New York, therefore we're not going to be targeted and are fine, nobody cares to harm us.
2. When you have a working SCADA system, nobody wants to run updates or make security policy changes when that might lead to not having a working SCADA system. Security vulnerability remains the constant invisible bogeyman, you never know if you did enough until it's too late.
If enough events keep occurring (and why would we suspect they won't), this attitude will HAVE?? to change. Kids will learn about it, and do it for the lulz. The city of Dallas had its tornado sirens hacked, and at least in the local areas, it brought some attention to the subject. Eventually, the bored teenagers in the small towns are going to do it just because.
Not just locally. If you're trying to mess up an industrial system to see it mentioned in the local newspaper few days later, you may just pick a random system from Shodan, note its location, and check their local newspaper.
It still lets you remotely monitor systems, but if you want to adjust the operation of the critical infrastructure you have to physically go there and do it in person. People often complain that this is inefficient, but if your own workers are unable to remotely affect a system then neither can an attacker - given the consequences of an attacker compromising a critical infrastructure I think the inconvenience is a fair price to pay.
[1] for those unfamiliar, this is typically implemented using two computers connected via fibreoptic cable, such that there are only transmitters (lasers) on one side and only receivers (photodiodes) on the other side. Thus the information can physically only travel in one direction. The computers at each end handle conversion from connection-oriented protocols (e.g. TCP) to connectionless (e.g. UDP) while maintaining reliability.
I wonder what if any cyber security requirements are imposed by their insurance companies.
"How 30 Lines of Code Blew Up a 27-Ton Generator: A secret experiment in 2007 proved that hackers could devastate power grid equipment beyond repair—with a file no bigger than a gif": https://www.wired.com/story/how-30-lines-of-code-blew-up-27-...
YouTube video of demonstration: https://youtu.be/LM8kLaJ2NDU
This is actually the other way around. Insurance is a moral hazard. If you're paying for the insurance anyway then taking steps to reduce the insurance company's risk rather than your own is throwing money down the drain.
Meanwhile the insurance company as a third party has less control over your actions than your own company and is less able to make efficient trade offs, so any requirements they impose tend to be either ineffective or unnecessarily burdensome or both.
The problem is that publicly traded or municipal utility companies have pretty much the same problem where the employees/managers don't pay personally for damage and the people who do are too diffuse or far away to understand their exposure well enough to mitigate it.
Until there’s no insurance company that quantifies the damages and makes a quote to insure it, it’s all “Snowden cranks waving arms” nonsense.
Once that is in place a new excel sheet magically blips onscreen and big maneuvers begin to minimize that premium and comply to the minimum standards the insurance will not classify as negligence.
But then what? You pay the premium. Then you comply with whatever "make sure your Linux servers have antivirus" rules the insurance company comes up with. Then you stop doing anything that costs a penny more than that because the risk is now on the insurance company, which makes the problem worse. And when everybody does that, everybody's premiums go up.
One of my colleagues preaches - for the case of fire/damage etc insurance - to get a quote; do everything they require (as these are almost always things that have or would have saved them payment before, e.g. keeping beige boxes above floor level and under a desk - which mostly mitigates water damage from both floor flooding and ceiling leaks). And after they would insure you, once it is clear they are confident they have positive expectation from insuring you (and they know what they are doing) - that’s the time to reevaluate if you want an external insurer, or your own piggy bank.
With respect to hacking, this advice is less applicable, however.
I’m not saying there aren’t other mechanisms to pervert this model, but as a first approximation this is how’s it supposed to work: as long as the operator is forced to buy insurance, and there’s no way for the insurance to get off the hook, parties are forced to develop a credible risk assessment and mitigation.
Then, if there is a claim, the insurance company investigates whether you followed the rules, finds that you didn't, and denies the claim. The insurance company doesn't go bankrupt and doesn't care that this happened. But most of the time there isn't a claim so nobody on either side actually notices that this is happening.
Is a vpn secure?
If Tesla can update the software in a fleet of vehicles remotely why can’t I update the software in a power plant?
Arguably it should not be up to the owner entity as to the security requirements they need to meet. At least down here in Australia we're in the process of legislative reforms that significantly expand both the scope of critical infrastructure (most of which is privately owned) and the responsibilities and requirements of critical infrastructure operators (in terms of risk management, security plans, mandatory reporting, etc.)
>Is a vpn secure?
Teamviewer (which I understand was the vector used in the water system breach) or a VPN that hasn't passed the extensive testing required of secure cryptographic devices is not acceptable.
IF the industrial control systems were treated as a classified information system, were linked using an approved and properly managed [1] secure cryptographic device (on both sides e.g. back to a secure control centre, not to your house so you can work from bed), and generally had the rest of the protective elements (e.g. requiring personnel working on it to hold a SECRET or equivalent clearance proportionate with the value of the system) in place, that might be OK. But otherwise my position remains the same - it should not be remotely controllable via the internet.
>If Tesla can update the software in a fleet of vehicles remotely why can’t I update the software in a power plant?
That might brick some cars on-board computers or "only" kill perhaps a few dozen people before people caught on and it was recalled - still tragic, but small in the grand scheme of things. Critical infrastructure is called that because if it goes wrong it can harm or kill people on a vast scale, so it should be held to far higher standards.
[1] e.g. keymat issued by whatever your equivalent to the NSA is e.g. our Australian Signals Directorate, and otherwise verified to be secure.
Can you recommend any VPNs that are up to the required standard for critical infrastructure?
Although since the power plants I work on would struggle to kill even one person and damaging them would only cause financial hardship for the owner or an insignificant exceedanve of environmental regulations, so they must not be critical.
It is small, lightweight, reliable and does what it is meant to do. It uses existing, trusted network tech in the right ways and due to the low complexity you reading the source code is an realistic option.
But there are userspace implementations and I guess it's should be doable to make them talk to a hardware device.
It's pretty low risk AFAIK, generally cars infotainment and CAN bus are isolated, and I understand Tesla vehicles can't update while driving. Who knows, I'm not familiar with their architecture, but I'm not too worried about it.
There are attacks but IIRC they rely on GPS spoofing, or tricking machine vision to cause the vehicle to swerve or accelerate, you can't just drive someone off a cliff over 4G (at least without implanting hardware into the car).
>Can you recommend any VPNs that are up to the required standard for critical infrastructure?
Approved devices vary by country, but this list is a decent example: https://www.ia.nato.int/niapc/Category/IP-Encryption_25
Unfortunately it's hard to provide info when these kinds of products are not generally available for purchase outside of the defence community, and the user manuals and related documentation are themselves restricted. But generally speaking if it's acceptable for use with classified info then it should be adequate protection for critical infrastructure.
>Although since the power plants I work on would struggle to kill even one person and damaging them would only cause financial hardship for the owner or an insignificant exceedanve of environmental regulations, so they must not be critical.
They might be relatively harmless in isolation, but it could be really harmful if an attacker could compromise a dozen of these small plants and disable or destroy them at the same time so there's less reserve capacity in the grid to pick up the slack when you launch your main attack. You don't even need to have that big of an impact on industry or what have you, just causing a blackout on a hot day and killing a bunch of elderly people via heatstroke would whip people into a panic.
Or perhaps an attacker would compromise one plant and use it as a vector to attack someone like you next time you connect, gain a pivot point via your workstation to set up a persistent backdoor and steal confidential documents and email so they know your schedules and organisational weaknesses, steal your VPN credentials and attack multiple power plants at once when it suits them, etc.
>They might be relatively harmless in isolation, but it could be really harmful if an attacker could compromise a dozen of these small plants and disable or destroy them at the same time so there's less reserve capacity in the grid to pick up the slack when you launch your main attack.
I suppose it depends on what is considered a small power plant. I would say anything less than 20MW is small, greater than 30 MW is medium, and greater than 100 MW is large. Simultaneously tripping a dozen 20 MW power plants would result in a loss of 240 MW of generation, about the same as 2 large units. There is 258,000 MW of nameplate generation on the western north american grid and a peak load of about 150,000 MW. The link below [0] shows that transmission level operators are looking at 1000's of MW of lost generation to have a measurable impact on the grid but losing that amount of generation causes operational headaches and not automatically an outage.
[0]: https://www.wecc.org/Reliability/2013-10%20WECC%20JSIS%20-%2...
https://www.homeaffairs.gov.au/reports-and-publications/subm...
https://www.aph.gov.au/Parliamentary_Business/Bills_Legislat...
The CI cybersecurity reforms are part of the overall 2020 cybersecurity strategy (https://www.homeaffairs.gov.au/about-us/our-portfolios/cyber...), there's a lot of changes happening in the sector at the moment. If you have an interest in cybersecurity now would be a good time to grab some certifications and be ready to jump on board, as there's expected to be a big demand for cybersecurity professionals over the next few years to support these initiatives.
This looks like a decent summary of the proposed changes: https://www.ashurst.com/en/news-and-insights/legal-updates/m...
OTA updates to car firmware is widely considered to be a stupidly irresponsible idea. I don't think we should justify doing risky things by pointing at other people doing risky things, who only get away with that because of clout and regulatory wheels turning slowly.
On one hand, it opens the door to hacking, pushing a malicious update, etc (stuxnet much?). On the other hand, if it is never updated, then we will end up with a zombie network consisting of lightbulbs, fridges, and teapots (yes!)
Edit: sorry I could not resist adding teapots (HTML error 418)
OTA updates, and car security in general, is a joke it's so bad.
Teslas are great cars in many ways, but cybersecurity is not one of those ways if you go by pentest reports. I stopped at listing five below, but there are quite a few more out there.
https://www.forbes.com/sites/leemathews/2020/11/23/researche...
https://www.forbes.com/sites/daveywinder/2020/02/19/hackers-...
https://electrek.co/2020/06/10/tesla-hacker-unlocks-performa...
https://www.zdnet.com/article/tesla-car-hacked-at-pwn2own-co...
https://insideevs.com/news/356769/video-tesla-model-3-hacked...
If the machines are killing people sometimes that is probably a whole other level of risk and I agree not something I would want to touch remotely.
Don't power plants have all kinds of potentially dangerous mechanical systems under computer control? Overpressure on a fuel line causing the pipe to burst and fill the building with natural gas, things like that?
This sounds like turning "an attacker may destroy power generation infrastructure and maybe kill people" problem into "an attacker may repeatedly DoS the power generation systems, likely damage it, and still probably cause loss of life by second-order effects". Doesn't feel all that different.
To use an analogy: it's like saying that attackers accessing the company servers remotely aren't a problem, because the best they can do is to keep them in a reboot loop...
Of course it depends on the size and location of the power plant, but there are many more small plants that can go offline without causing any significant effect to the grid than there are large ones, and the large ones probably have the resources to be manned 24/7 either on site or from a remote site over a dedicated and thereby secure fibre link.
One take-away from this thread is that not all infrastructure is 'critical'.
One is life and death, another is lost revenue for a power plant.
Down in the analogue world, random overpressures, voltage spikes, simple mechanical fatigure, etc happen all the time, so you're going to have to deal. I've written reports on why, regardless of what a sensor said, a simple static beam made of nonflammable materials neither a) spontaneously combusted, b) broke Clausius's principle and moved heat from a cold body to a hotter body. But we still checked.
However, I don't trust systems to remain as robust as initially designed, after decades of undergoing constant pressure to reduce costs, make things more (fiscally) efficient, "cut out fat", etc.
Ever had to start maintaining a codebase after the greybeard who made it retired? Did you have any documentation to go off of? Anyone remaining in the company regard it as anything other than a production critical black box?
Now imagine that codebase is an industrial process, with 20 years of growth, add-ons, changes. Probably some mismatching control systems, and god only knows if the as-builts or red line plans for the additions are all correct or rectified with each other..
Maybe, for example, a mechanic tired of trouble shooting an issue replaces the 9th blown burst disc in a row with one he just cut from the mud flap on his shop truck. NBD, the system was only running 5% over pressure anyway and he wants to go home.
Later, this overpressure state backs up through the system and overheats a pump which, considering that it is pumping liquid explosives, isn't ideal. Maybe this trips a temperature sensor and the jury rigged burst disc is discovered. Maybe it doesn't, or the sensor was bypassed or silenced, and the pump explodes.
I'm rambling, but this is a real world example. My point is that these various factors: designed safety monitors like sensors or fail-safes play hand in hand with over-engineered systems as well as the security of the control systems. Any one part of the system should not be allowed to lapse or be less secure with the idea that another level of the system will catch the problem before it becomes life endangering.
Didn't go well for the jenny. (Though a turbine might have fared better)
Wait, isn't that a bit over-dramatic? I mean sure, that's true of nuclear systems. But I mean, my home thermostat? My car's smart key system?
As for the thermostat - it's winter below freezing and a hacker turns your heat off during the night. Sure someone might wake up, and it would have to be very cold for you to freeze, but if you have someone old or a child then it could be life threatening. Depending on the heater it might be able to make it cause a fire.
Many car's smart key system is on the same network in the car as everything else, including the brakes. Read more in https://money.cnn.com/2014/08/01/technology/security/most-ha...
So no, it's not being overly dramatic to categorize any SCADA system as a weapons platform. It might be, as they say, 'an abundance of caution', but I am fine with erring on that side than erring the other way.
Three Mile Island can be viewed as caused because one gauge was not being tracked correctly (where it was supposed to be was being tracked, not where it actually was). What if remote access was enabled on systems in a nuclear power plant, so that people didn't have to drive all the way there? A hacker might manage to replicate some version of Three Mile Island. I can hear the 'but it's secured' response from some already, but any system that can be accessed can be hacked, given enough time and resources.
The key thing people should realize is that cybersecurity does not prevent hacking, it attempts to delay it until a real person can take corrective action to protect the system. This is why you have defense in depth and rings of security. Essentially, it is a door lock. The better the lock, the more skilled class of thief it will dissuade by being 'too hard to bother'. A skilled thief who has state of the art lock picks, or is willing to use a door ram, is not going to be deterred by even the best of locks (think organized crime or state actor hackers here). But if our imaginary door only opens one way no matter what, to let people out, and can physically never let people in - then even the greatest thief is SOL. That is the purpose of a data diode.
The other other concern, and it's not minor, is that any time you start measuring safety in terms of cost effectiveness you are putting a value on human life. It is saying that is is cheaper to pay the settlements and/or fines resulting from deaths due to insufficient safety precautions than it is to make it safe to begin with.
plant < diode < internet
you could control it but not get any feedback. I meant
plant > diode > internet
so you could monitor it but not control it from the internet.
It’s not a nuclear power plant. There’s no crack team of snipers to kill anything that gets too close to the fence. Physically these places are certainly not wide open, but neither are the fences, doors, and locks any more intense than what’s on the local high school.
Same isn't true for physical security.
I have not personnaly worked in industrial environment, but from people I know, security wise, it is very scary at some places. Here is one such example of a "smart guy":
The IT crew of a factory have a sane policy of deny all traffic, except some well thought out rules.
A supplier would like to open a remote connection for maintenance of the equipment. Since the process for opening some traffic for a short duration is so convoluted, they finally install a 3G card inside the equipment (without telling their customer, and they even make it a habit for future install) so that they can do maintenance whenever they want.
The IT crew still thinks all is safe from outside...
Did someone in this story report it to the company management? This sounds like a clear lawsuit (or at the very least, contract termination) waiting to happen, and one that would scare other vendors away from such "clever" workarounds.
Oh, I don't doubt that :).
> the supplier was marketing its solutions as secure
... but I very much doubt the truth of that marketing :).
I think it's still a ticking liability timebomb. At some point some external auditor will discover the backdoor to the plant and heads will roll.
My fallback approach is, to insist on machines incapable of self-destruction and Whole System BackUps. Its easier & cheaper, to unplug, replace some spare-parts, reinstall some acronis images and go. Sad world, but real world
I find this hard to believe. In this modern world of connected convenience, I’d say what I want from the water company is 99.99999% safe water and 0.00001% real time billing. The idea that you would sacrifice the former for the latter is ridiculous.
Nothing in your comment makes me think SCADA is bad, it just makes me think connecting it to the internet is dumb.
You are the consumer. You want pure water. That I believe. The people buying the SCADA system want to be able to look at a dashboard while staying at home in their slippers during COVID-19. Worse yet, the SCADA system might have already been bought some time ago -- as is very common -- and adding "Hey I want to look at this from home!" might have happened a decade after the purchase.
> What we want from water is safety.
This is a different subject altogether.
That said, the kind of pressure and pump monitoring systems I mentioned are all part of keeping water safe.
The real negative impact of meter reading isn’t the lack of the online billing, it’s that the water company might not be able to bill as often and might have to sometimes bill on estimates, so people can get saddled with surprise bills
- I don’t believe the two are actually related but if I believed that setting up a payment website required introducing huge security vulnerabilities, I’d rather mail a check. And I hate mailing checks.
- As for the sellers viewing the water companies as their customers: I agree; that makes sense. But the water companies are public utilities and if they’re putting their own convenience over the safety of residents, it should be addressed with regulation.
This has been done since the dawn of water management. Manual meter reading is the source of most errors in a system. SCADA systems generally don't get directly tied in with meter management and billing, but they are required somewhere in many processes. Sorry if I didn't make that clear.
> I don’t believe the two are actually related but if I believed that setting up a payment website required introducing huge security vulnerabilities, I’d rather mail a check. And I hate mailing checks.
It doesn't. What I said is about how these things happen. It doesn't mean the only way to achieve a "smart city" is via TeamViewer. Outfitting your system with devices designed with the SCADA security model in mind has proven to work.
> But the water companies are public utilities and if they’re putting their own convenience over the safety of residents, it should be addressed with regulation.
I'd caution you against routinely arriving at maximalist interpretations. This has very little to do with convenience and more to do with efficiency, safety, and resource management which makes your water cheaper, safer, and less likely to be lost.
there's lots of safe ways to export data from a secured/highly controlled system in a manner designed for one way information flow. even if it's as simple as putting data in a pipe-delimited CSV in a cron job.
first get the data out of the secured system's boundaries, nothing sensitive, and then do whatever is needed to present it to customers in a friendly web GUI.
I've had hundreds of plant engineers and SCADA operators tell me that their systems were "not connected to anything" and every single one of them was wrong.
Whether it's an old 2400 baud modem on a spare port on the RTU or "serial" comms being multiplexed across IP or MPLS networks or the unlicensed TeamViewer install for vendor support, there is always a "well except ..."
Sometimes they don't even craft devices, even shoddy devices would be better than other options some take. Sometimes it's just a matter of someone in the muni saying 'hey, we can fix this, let's put this on a password protected wireless network'. Sometimes it's not even password protected.
Sometimes it's not the muni, but the vendor, who decides for remote management and puts the device on the internet.
I agree with the other poster who said they thought data diode was the way to go. Make it so the companies and munis can get data, but cannot send data to the devices unless they are physically on site. Of course, that means the site has to be secured - a lot of times security through obscurity is relied on by putting in remote locales, fake locales, etc. This also includes securing the device - it should detect tampering and default to a 'tampered state' if tampered, one that is encoded at manufacturing so it cannot be changed. While I'm on it, I would love to start seeing TPM 2 chip and Sel4 OS a mandated minimal requirement for all SCADA devices. The cost would go through the roof - strike that, the atmosphere - but it is so necessary.
At her request I sat in on a meeting with their vendor to ask some stupid questions (but less stupid than what the commissioners would have asked) about their proposal for updating the control systems.
Some crazy things discovered:
* it's all windows, all the time. I don't know why but I find this disturbing, but apparently all the drivers for these systems only work on windows. I guess Linux is only just starting to penetrate this market.
* yes, remote access is a thing (even in the old system), especially in this case where the plant it under 20 feet of snow half the year. They claim the system can only monitor things, not control things, but I wonder how locked down that really is. Security is via a VPN.
* the vendor at play here seems to be a tiny shop of a few people that basically serve a few dozen sewer treatment plants in the area. They deal with replacing the hardware and programming these interfaces in.. kind of a crazy local cottage industry I just wasn't really aware of.
Having a background in web services / unix left me pretty unprepared to really do much more than ask some stupid questions around security / obsolescence, but the vendor had reasonable answers to my concerns. Just a very different world than what we think about every day.
If it's just a touchscreen or hardware buttons, you may need a key to open a panel where the keyboard/mouse are, or to bring your own keyboard/mouse, in order to navigate the Windows part of the interface to fix the problem.
Obviously if it's intended to be networked to existing desktops for control over a LAN, the client software will be Windows, but even then you hope the server isn't.
Outside our tech bubble working on Unix is still perceived as hollywood-style hacking of the bank and folks really have no clue, unless its done in GUI just like... you guessed it, Windows. Folks wouldn't even touch it.
Windows is an awful choice for any system that must be reliable. I know, because the industrial control system at my workplace used to be windows, and cost us mega bucks every year in down time. Now it's Linux, and we haven't had ANY downtime in over two years.
All this to say, Windows isn't the worst thing ever necessarily, and ideally you want a system that's purpose built and only does what is required with the least amount of code/systems possible.
Also I would guess whether we hear about it or not is more likely to be a political decision. Can the news be leveraged for whatever change we want to see? Or is it too embarrassing and works against us? Sometimes it doesn't need hiding, so then we find out. (Cynical, I know.)
10+ years ago I used to do demonstrations of this specific attack for govt and other critical infrastructure owners. In our demo, we had a two small vats of coloured "chemicals," with pumps controlled by a bank of PLCs, an HMI and a network of a bunch of vulnerable VMs. We would walk people through how to exploit trivial web vulnerabilities that would get them to the HMI and cause the pumps to reverse and cause a chemical spill from the vats. The look on their faces when they caused a vat to overflow themselves with very little skill, was their "scared-straight" moment.
It was 90's, even 80's level hacking. There is no way the managers didn't know this was possible and likely. They're only acting surprised. What this really looks like to me is a test run for something more coordinated and worse.
Not sure what kind of filters protect against this kind of thing, but a pH sensor with an alarm might mitigate the family level risk somewhat.
What if there are 100 attacks per year, with a 99% success rate?
I don't get what you are asking.
Any large adversary would compile a huge number of ways to disable infrastructure, then use them all at once, rather than one at a time.
Sure but it might keep out all the people who don't know what they are doing. Like some clueless junky.
Classifying someone as a “junky” adopts a cruel and unrealistic worldview blaming the victim and absolving a number of powerful actors of their role in contributing to addiction on mass scale.
What about those who were recreational drug users that went down a dark and dangerous path? Presumably in this case it's fair to put the blame on them. Yeah, maybe they had issues with their parents and maybe they had some other problems. But nobody put a gun to their head. They made a bad choice and paid the price. That's how life is.
You can't absolve personal responsibility either.
What about the rev users who didn’t go down the dark path?
This precisely is the difference of having genetic predisposition to addiction, trauma etc.
No, it’s not a choice more than obesity / food addiction is.
If you’re interested in expanding your thinking see the work of Gabor Mate.
Maybe. Or maybe just the culmination of a series of bad choices.
> No, it’s not a choice more than obesity / food addiction is.
That's a choice. Nobody is making you buy the potato chips and cheesecake. Nobody is holding you back from the gym. It might annoy a lot of very fat Americans, but you've got effectively the same DNA as everyone else - but they're not as fat. It's a cultural thing and a choice.
Yes I know I'm glossing over some nuance here, but personal responsibility remains. Ignoring that seems like just resigning yourself to be blown wherever the wind takes you.
Take responsibility for your decisions, take a good honest look at where you are, what you don't like about that, make a plan to change that, and then execute it.
I think I'm familiar with the consensus views. What am I saying that you feel is unjustified?
I agree that obesity/food addiction and drug addiction are both on a similar level, but to me they both sound like a choice.
Mostly because if we decide to apply the same standard you use for qualifying whether something is a choice or not, then literally nothing is a choice.
A man who physically abuses his wife and children? Not a choice, he is doing it simply because he had some experiences in his life that made him that way or he is just simply genetically predisposed. Someone cheats on their partner? Not their choice, they were predisposed to do it or their partner was just not making them happy enough. Harvey Weinstein? Not his choice, he was just a victim of his own circumstance who was also genetically predisposed to do what he did.
You get the idea, but I honestly do not believe that most of those things are anything but choices, unless we decide to pretend we believe in predetermination and complete lack of free will. In which case, I would agree with you, those decisions were not choices, because choices don't exist in the context of belief in predetermination.
Mind you, I am not saying there are no circumstances in which those situations would not be a choice. There are indeed some scenarios like that. However, and that's purely subjective based on my personal observations, those scenarios are a minority.
I don't think it is a binary choice vs. not choice. If speaking frankly, I do believe that any of those things discussed feature both a choice component and a predisposition component. The proportion of each of those two components varies heavily based on a person and a situation.
However, even with this in mind, it is difficult to say that the choice component is ever at zero.
We can discuss to which degree humans have a choice in their actions, because it is definitely debatable, since they all agree on the ground truth that there is always some degree of choice. But that discussion cannot coexist with a belief in total predetermination, since that removes any ground truth completely.
Addiction Is a Brain Disease, and It Matters: https://science.sciencemag.org/content/278/5335/45
Maybe the goal isn't to make every single facility 100% secure to all threats, but it's totally defeatist to say that we couldn't somewhat increase the actual security of many systems. VPNs alone would provide a great first line of defense, and even for a government-run utility, the barrier to installation is very low there.
I have a fair level of skepticism around security theatre, too, but I think it's unfairly cynical to suggest that we don't have a goal of making ourselves more secure.
https://en.wikipedia.org/wiki/Kerckhoffs's_principle
In addition to assuming the adversary knows how everything is designed (as opposed to security-by-obscurity) there should also be an assumption that security is obtained through real implementations, not theatre.
What happens when everyone in my street buys the same security system? Seems like we all just spent a lot of money buying something that now offers us no benefit.
Short of purchasing a honeypot property with (seemingly) no security system and going full Home Alone on the inside of it, it seems like you're going to need actual security at some point.
At least for the home example, you're usually better off reducing the factors that would make a break-in happen in the first place rather than trying to win an arms race against a determined attacker; there are high trust societies where people don't bother locking their doors and people don't get burgled. But obviously the threat model is different than a utility.
You mean men with guns stationed 24/7? There is no "actual security" against determined burglars available on the market for regular people. There's delaying action (e.g. laminated glass), noise making and deterrence (cameras). Each can be worked around.
This is also a general point on security: there's no perfect security, there's only adequate security - where "adequate" means it costs the attacker more to breach it than they can expect to profit. From this view, appearance of security is almost as good as actual security measures - you make security look expensive to breach, which achieves the same effect, as long as nobody is willing to call your bluff.
Its all fun and games until somebody wants to kill people and they suddenly can.
(This is also thought to be the reason "Florida Man" is a thing: https://www.oxygen.com/florida-man-murders/crime-news/why-ar...)
Shouldn't the system notice when the "knobs are turned up too hi" and disallow that?
Well, Um, these water plants are build to very rigorous webscale cyberstandards: They’ve got to have a ON/OFF switch. We used a bounded model checker to show nothing bad could happen in a maximum number of transitions.
What’s the maximum number of transitions?
Oh,… one, I suppose.
Confirmations to ensure setting is entered accurately and logging of changing of settings and by whom are good ideas though.
Are you quite confident that is how engineering works?
For example, a well engineered plane allows the pilots to control the fuel flow to engines, but also does not allow pilots to dump fuel into the passenger compartment. Much engineering goes into, how to isolate the toxic chemicals of fuel or other fluids/gases away from the passenger compartment. So you have freedom, but you also have constraints.
Likewise, a well engineered plane probably should allow pilots to fly the plane according to their needs, rather than overriding their inputs as they fight to point the nose up while the plane decides that no you really want the nose down right now. Of course the pilots should've disengaged MCAS, but in a crisis it's bad engineering to force operators to remember which unhelpful/murderous system needs to be disabled in order to avoid catastrophe. The system took too much agency away from the operators, and violated the principle as espoused by that comment you're quoting.
In this specific case I imagine the plant wasn’t physically capable of dosing at that rate - and there should be alarms if the outgoing water is outside the desired operating parameters.
The UI will be designed for people who know 11,100 ppm is a stupid level, so it's probably light on fancy error messages.
You might as well ask why Google has a setting where I can type "' SELECT * FROM NSA_SECRETS;--" into the search box.
Therein lies the problem: assuming your users will never be malicious or make mistakes.
Note also that you can type whatever the hell you want in a google search box. I could type "launch all nuclear forces at Russia", but that isn't going to actually happen.
I agree with this.
I imagine that we will find out that the attacker was indeed someone who was given access (at some point in time) and not an attacker from the internet
What was shocking was that I had to explain to the lead engineer the "never trust the client" security concept. A few hours later he found a major exploit.
I suspect that there are many small software companies with similar problems.
1) have the computer running this stuff on a network which faces the internet 2) install teamviewer on it
I mean.. what did they expect?
Yes, obviously - or perhaps not, to some - no designer of the physical plant in their right mind would consciously spec the ability to raise levels so high so quickly. The thinky box can ask for whatever it wants but that don't make it so.
That said, for that sort of town it should only require a tonne or so per hour NaOH to raise to that level. Which is throughput you can get from any generic .
Depends on the tank size, and how much NaOH is in reserve, I can see one of the outcomes being "yo, why's the hydroxide tank empty?". Or "customers reporting funny tasting [but not harmful] water". I'm not convinced that dangerous levels were impossible, however, and I was expecting to be.
https://arstechnica.com/information-technology/2021/02/breac...
Couldn't the involved staff be jailed if they tried to conceal it?
Where I live, things are very nice and it’s maybe fairly unique to my exact county.
But if you are referring to overall infra like highways or something- I don’t share the sentiment it’s in anyway a problem where we live.
Im not plugged into interstate trade or things like that. So maybe I’m not totally aware of the problem. But it hasn’t seemed locally problematic.
Edit: downvote, really? I’m trying to know more about crumbling infrastructure.
tl;dr the USA earns a D- in infra.
The D- is a bogus rating meant to increase spending, not improve value.
https://www.strongtowns.org/journal/2011/12/12/best-of-blog-...
https://usa.streetsblog.org/2013/03/20/is-the-asce-failing-t...
You probably could find better ones without much effort, as I also didnt use a ton to find mine in the first place - I was just referring to a document that was pulled up when the bridge collapsed in my home town.
If you want to quibble about specifics sure, but that's different than the parent's "I dont know what the conversation is about"
This is a good summary from a neutral source: https://www.cfr.org/backgrounder/state-us-infrastructure
Much of that report focuses on things like traffic congestion and delayed flights from busy airports:
> According to Petroski, the delays caused by traffic congestion alone cost the economy over $120 billion per year.
Ironically, the abrupt shift to remote work and work-from-home due to COVID has significantly reduced traffic burdens in many cities.
I'm all for improving infrastructure where necessary, such as the ~10% of bridges that are structurally deficient or improving access to cheap broadband. I'm not enthusiastic about rallying cries to encourage more car traffic, though.
SCADA is an offline ecosystem by design because the innards of the system are mostly just signals flying around. There's no encryption or IAM in place to defend against bad actors. More recently the cities want their municipal infrastructure that runs on SCADA to integrate nicely with other information systems to either retrieve data which is useful for generating reports, like the delta between water pumped and water served which indicates total loss. The other use case is to perform actions. If I know there's a fire on one side of the city that is a four alarm fire, which will put pressure on service lines as multiple firetrucks begin to demand water, I can decrease pressure on one section while increasing pressure on another. You could perceivably do this in an automated fashion, but there's no such capability in any SCADA systems I know of. Hence, municipalities end up finding integrators who will build them custom devices to interface with their systems.
So, this is less an "aging infrastructure" problem and more "new capability demand".
You can't just hack Teamviewer.
Possible by a national actor, not from a script kiddie.
National actor is obviously not going to change to a value that sounds dangerous but will be quickly found and does nothing.
So it's a insider job, I'd wouldn't rule out someone sat on a keyboard. I'd even put it out there perhaps no one remoted in.