One of the most famous software defects - Therac 25 - happened because of a transfer of medium. The software was embodied in a machine with physical controls, then the software was embodied in a machine with software controls only. The assumptions in each medium were very different. I wonder if something similar happened here.
I imagine the requirements document didn't say anything about the public internet.
I don't know much about the margins and volumes of this sort of industrial equipment, but, are they so low that nobody can hire a skilled team of software engineers to write proper code for this stuff?
The UX is always trash, the security is non-existent, the smart-components are always low-spec and low quality (displays?). Is adding £5, £10, £100 to the cost of a unit to do it right going to hurt _that_ much?
Genuinely, I don't understand. Surely one of these things costs at least 5 figures and are bought in multiples of tens or hundreds?
> That being said it doesn't need to be on the public internet, but it makes it a lot easier than setting up and managing a private network.
I'm sorry what? It's easier than setting up a portion of/separate LAN with no internet access? I mean, yes, in the strictest "lazy bastard" kind of way, sure. Can we not even ask that of businesses now?
Sure Bosch should've secured these things, that's a given and they should be rightly held to the fire to fix them. But also like... wifi routers have been a household staple piece of equipment since like.. 2008? Depending where you live? And we still can't ask business operators to do even the most basic due diligence in setting up their environment, or at the least, hiring someone who can?
This is like when you go to a restaurant and their access point is called Spectrum-Wifi-5G using WEP encryption with a password that's like, F8F023gX. Just well established that not a single fuck was given in doing this.
Have you ever worked in a manufacturing plant? Yes, the solution is TECHNICALLY very easy, but there's a bunch of gatekeepers that really slow things down.
The solution to the problem in front of you is always technically very easy and clear, but there are always a tremendous number of problems to be solved in a production manufacturing environment.
Not to mention how often things will effectively be set in stone once installed in the plant.
How many utterly mission critical e.g. CNC machines are run by a miraculously still functional Gateway desktop running Windows 98 Plus, camouflaged under a few decade's accumulation of rusty shavings from the nearby lathe?
and don't forget that sweet sweet usage data that they can use and/or sell for marketing purposes. Knowing exactly what the customers do with your tool and when is nice...
If it's a matter of tracking, it could still be done using a simple connector and some kind of base station. Presumably these things have batteries that need to be charged, so they need to be returned to some central location and connect by copper wires periodically one way or another. They don't need network connectivity to accomplish this.
The batteries connect to the charger, yes. The tool never does, and probably can't be physically plugged into anything for want of connectors.
And what difference would it make, anyway? In exchange for massively complicating every aspect of the monitoring and control tasks, you're just interposing the need to infect the battery firmware in order to pop the tool. Do you imagine the battery will be secure when the tool is not?
You make the battery a simple storage device. It can't be infected any more than a piece of paper can be infected. Even if someone can write crap to the battery the tool won't care, since it just needs to write simple information to it, not execute anything.
There are ways to solve the problem, it's just cheaper to make the tool an HTTP client and solve it on a server somewhere.
Aside from assuming the secure firmware on the tool - and now, too, on the battery! - whose absence you were trying to solve a couple of posts ago, this sounds like a solid approach.
You don't think perhaps that having a mass storage device available to the tool is going to encourage engineers to find uses for it?
Updating the tool firmware, say - especially since with OTA updates unavailable for reason of the tool being forbidden to incorporate a radio, there's no other way to update the tool's firmware, not without complicating its design to expose a port rugged enough to survive the hard-knocks life an industrial tool is guaranteed to lead.
You might argue that this isn't worse than the current state of play - which would be true, but irrelevant, because in order to justify the massive cost and complication of this proposed design, you need to be able to show that the result is to a comparable extent better. You have yet to do that, and I doubt it can be done at all.
I don't see why a torque wrench needs to receive firmware updates if it has no connectivity whatsoever. It's a wrench. It has to tighten nuts according to a torque value selected via the keyboard. What could an update possibly do to make it perform this one task better?
What are you on about? I'm arguing there were ways to solve the problem that didn't involve the tool connecting to the Internet. I don't need to show that my solution is better, because that has nothing to do with what I'm saying. And either way there's no "better" here. There's no objective measure of goodness. What's better to me and what's better to Bosch are not necessarily the same, and in fact they obviously aren't, as I never would have designed a tool this way, but then I don't have a tool manufacturing company.
from the article: "allows engineers to tighten bolts and other mechanical fastenings to precise torque levels that are critical for safety and reliability."
high precision factory gear in safety-critical applications seems like a reasonable use case to me.
The tightening is done by sensors inside the tool. That has nothing to do with any kind of tracking or with anything that happens across a network connection.
But tracking tool health in safety-critical applications (think bolt torque on an airplane door plug) could benefit from automated tracking. Generally this is solved by regular inspections and calibration, which is cheaper and avoids the security issue. There is some benefit to automated tracking and fault identification. Doing it on an air gapped network means you have to be on site to check status and errors, which seems reasonable to me.
And tracking tool health is something that precisely doesn't need to be done on a minute-by-minute basis. Doing it once at the end of every shift seems more than enough.
Sometimes these sort of screwdrivers can drive other processes (e.g. once it confirms that the screw is correctly affixed, send a message to the manufacturing system to tick off that 'task' as complete at this station, and prompt the operative to start the next assembly task - the piece cannot move to the next manufacturing process until the screwdriver has confirmed all bolts are affixed at the right settings).
And who guarantees such setup would be anymore secure or any better implemented? It would probably use some custom protocol that is much harder to test with as poorly written implementation...
Which is why we have air gapped OT networks. Critical systems like this shouldn’t even be reachable remotely. The slight convenience of remote troubleshooting isn’t worth it. Plus there are solutions out there to only temporarily and securely bridge the gap if it’s an absolute necessity.
You're talking about a several orders of magnitude difference in attack vector. Yes, a motivated nation-state actor willing to put literally ALL of their resources into attacking you will probably find a way to get it done whether through cyber-attack or just dropping a bomb on your head.
Air-gapping your OT network protects the average company from 99.99999% of threat actors. If you're attempting to create nuclear weapons and a western nation is trying to stop you, you're either going to be compromised or murdered. That doesn't mean Bob's metal stamping should put the IOT controllers for his steel presses onto the public internet.
You are making a logical fallacy here. Inserting a compromised USB drive into an industrial environment is harder than a remote attack, but it's still not particularly hard. Just because there is a noteworthy case of such an attack being mounted by one nation-state against another doesn't mean that a state actor is required to mount such an attack.
And how are you planning on getting a USB drive from Russia onto an air-gapped steel press in the US? It is several orders of magnitude more difficult to get malware onto an air-gapped network on the other side of the world that you know absolutely nothing about than to attack it when it's connected to the internet.
How are you reconning what actual PLCs Bob is using? How do you know what versions are on those controllers? How do you even know the address of someone who works in a position that has physical access to the OT network in the first place?
I'm not using a logical fallacy, you're pretending that Stuxnet is applicable to the average business and it just isn't for a dozen reasons I can think of and probably 2 dozen I can't.
Re-read what I wrote: Inserting a compromised USB drive into an industrial environment is harder than a remote attack, but it's still not particularly hard.
> And how are you planning on getting a USB drive from Russia onto an air-gapped steel press in the US?
Why does such an attack have to originate from Russia?
> you're pretending that Stuxnet is applicable to the average business
No, you have missed the point. Stuxnet shows that a USB attack can succeed even against a state actor. It does not show that a state actor is necessary to mount such an attack.
>Re-read what I wrote: Inserting a compromised USB drive into an industrial environment is harder than a remote attack, but it's still not particularly hard.
And you're basing this on what? All of the OT networks I deal with are physically secured. You're swiping a badge and being recorded before you get anywhere near the production floor.
>Why does such an attack have to originate from Russia?
Because someone in the US compromising an OT network with ransomware is going to prison for a LONNNNG with little to nothing to gain from it?
>No, you have missed the point. Stuxnet shows that a USB attack can succeed even against a state actor. It does not show that a state actor is necessary to mount such an attack.
Go ahead and link some of the OT environments you've seen compromised by USB drive in the US. I work in the industry, you're going to be searching a lonnnnnnnnnnnnnng time to produce more than about 2 and both the ones I'm aware of were insiders who were immediately caught.
My knowledge of what I could do as an employee if I were to go rogue.
> Because someone in the US compromising an OT network with ransomware is going to prison for a LONNNNG with little to nothing to gain from it?
If they were caught.
> Go ahead and link some of the OT environments you've seen compromised by USB drive in the US.
There aren't many, but it's not because it's a difficult attack to mount. It's because there is a lot of lower lying fruit. You don't have to outrun the bear.
Tracking that x number of fasteners were correctly tightened to correct tolerances makes lot of sense for manufacturer. And having automatic tool makes it lot less likely that someone just fills paper or computer with right number. Point really is that they can prove it was done.
And IIoT makes lot of sense. Having worked with such products. You can monitor remotely equipment and even do data analysis on the data to find patterns. A real use of machine learning.
Not that it doesn't mean there shouldn't be very limited connection from singular or few gateway devices. And all of the other stuff stopping devices from connecting to and from internet...
I don't think anyone is arguing that getting usage metrics from your tools in a professional setting is a big value add. The argument is that it requires internet connectivity, a heavyweight client, and third-party cloud services. If you just want to track basic metrics like torque and battery, stick an OpenTelemetry server on the wrench.
You're subscription only allows 250 bolt twists. If you would like to upgrade your subscription, please visit www.wescrewyousoyoucancontinuetoscrewbolts.com
There is good reason to only allow 250 twists - you need to recalibrate after that many twists, and this is expensive.
I don't know how many twists you are allowed, 250 seems a bit low. People can die if calibration procedures are not followed. If the manufacture says 250 twists, then you follow that 250 or you will lose millions in court.
People can die in many different cases - I think it should be up to the wrench owner to make this decision, and not the wrench seller (who collects money for calibrating wrenches).
> I think it should be up to the wrench owner to make this decision, and not the wrench seller (who collects money for calibrating wrenches).
That would depend on the accreditations involved, yeah? One would certainly hope that the manufacturer goes through a rigorous design and testing process to ensure that the recommended service/calibration interval is accurate and occurs before the tool wanders out of spec for whatever its intended task is.
As the end user you should presumably be able to reasonably adjust that service interval but it should require a similarly rigorous and documented process to determine how much more you can open it up, not just squinting at the wind and saying "eh they over-engineered it so I think we can get 30% more use out of before calibration"
That's where the accreditations and specs come in. If I'm torqueing down a new Ikea bookshelf, I really don't care. New tires at a chain shop? Middling, to the point that they don't over-ugga-dugga my lug nuts on and destroy the bolts. I'm gonna re-tighten them myself after a drive or two anyway. Bolts in a new airliner being tightened down at the plant? You bet I want that shit to be to-spec, and the tools, too.
Generally the wrench sell is the one who paid the engineers to figure out the details. By the time I as a buyer/owner do the analysis I'm 120% of the way to building my own wrench. That is it would be easier to design a wrench from scratch than to prove someone else's wrench has the wrong procedure. (when starting from scratch you choose known alloys with known properties, when buying you have to figure out what alloy they used before you can figure out the properties of it - this is not easy)
yeah, that's insane. i used to work in a pretty regulated industry and they would have all the calibrations done by the metrology department and every instrument would be tagged and made sure to be in compliance. you don't need some wrench manufacturer telling you to calibrate.
how does this help some guy in a shop somewhere that doesn't need strict calibration schedules and bought the wrench secondhand or even firsthand?
I’m pretty sure the main thread here about limited twists is a joke.
In saying that, there were devices with similar restrictions before any IoT existed. Smoke alarms, CO alarms, breathalysers are all devices I’ve seen with enforced lifetime and/or usage counts.
That plan includes (or at least should!) someone to come out and physically verify calibration traceable to NIST (or whatever your countries' equivalent).
> Because we need to track critical bolt rundowns (generically called fasteners) and tool condition.
Unpopular opinion: I'm not convinced we need internet connected wrenches for this. We may want or be excited about, e.g., monitoring torque with internet connected wrenches, but I'm not convinced we need them. This may be a scaling issue, related to being able to make things faster with less experience and oversight. I'm generally skeptical of the unintended consequences of scaling production like that, and it may be giving me a bias. But I stand by the statement that there is no fundamental requirement to make wrenches connect to the internet in order to manufacture sensitive equipment.
But there's real demand in the industry to use networked IoT devices wherever possible and harvest the data so you can do things like QC (hand an audit trail to your customer that all bolts have been tightened with the exactly right torque) or preventive maintenance.
No one wants to fall back to non-networked ways of manufacturing.
I don’t see how this is working. The QC audit will just testify that a bolt, somewhere, has been tightened. Or we need nuts with chips that communicate with the wrench and the part it’s fastening.
You'd also be logging time of tightening, location of the wrench (to some granularity), user of the wrench, and so on, and on the other side you'd be tracking the state of whatever it is you're building so you know where it is at all times and can cross-reference.
You also track who tightened the bolt when with which torque (could be wrong if the machine is defective and that is exactly what you want to be able to audit). Some machines are even able to tell in which spatial position they were used - kind of a micro-GPS. Some trials are running with AR glasses that show the position of a bolt to the operator and also log the actions.
I feel like we're at some weird technological historical point where we have IoT everywhere but we aren't passwordless yet. So we're polluting our world with IoT devices like this but they ship with "admin/password" as the default and expect someone with some technical knowledge to secure it, with the blessings of management who takes security seriously. In many organizations they have either one of these, or none of these. In people's homes, they have none of these.
No one would care about IoT wrenches if they forced some app-based auth with mfa. We only care because we can trivially exploit them.
Companies like Bosch shipping these things insecure by default is the real problem. Near everything embedded does snmp 'public' with write options and very few devices force strong passwords or passwordless or force mfa. The embedded space is a mess and where computers were pre-2000.
This it the classic "we invented cars before seatbelts and don't want to spend money on safety anyways," scenario.
Regulation here is badly needed. The market won't fix this itself. Bosch isn't really hurt by this stuff. They can just blame operators, the same way Boeing blames pilots or airlines when their Max's crash or fall apart in the sky. This is a classic perverse incentive of capitalism at play here and now that politics has moved towards idealizing a low-regulatory environment, we're only going to see more awful scenarios like this.
Having worked in manufacturing IT, I can tell you that the security of shop floor systems is an afterthought. A lot of the systems are German based, and they are set in their ways when it comes to IT, they find something that works and they use that for a long time. This is good for reliability, but bad for security, because there is a lack of patching/updating/security infrastructure.
this is something I initially thought was a stupid IoT device, but this connectivity actually makes sense - just not their implementation, which is inexcusable.
> Bosch officials emailed a statement that included the usual lines about security being a top priority.
This is my new benchmark for quality journalism: calling out half-arsed boilerplate press releases. This requires a journalist who genuinely understands the story, which is exceptionally rare outside of industry-specific journals.
I sat next to this guy at a security conference once and it took everything in me not to fanboy out and annoy the hell out of him with questions abput his work. This guy should be the standard for journalists.
Honestly, that would be the much more dangerous attack to a company that must meet torque specs for safety. You can throw out a torque wrench, recalling already produced products on the other hand...
"We've hacked your torque wrenches since adoption & changed the torque values to deceive your Quality Control on random random bolts on random aircraft. Pay us ransom to tell you which fasteners on which products were changed or recall them all."
Re-torquing every bolt on an aircraft would be ungodly expensive.
Pretty sure in this scenario they'd have to recall them all anyways, because regulators and the public would not trust hackers to accurately log and report every bolt they messed with.
I could easily imagine an email arriving at some public contact address "I'm in your wrenches, changing your torques, send 123 BTC to 45678 or else!" and some first level person just dismissing it incredulously, "yeah, right...", to the trash folder. Then when nice things do start to burn... not sure that I'd have the guts to remember if I was that first level person?
But when bit ignored that threat would be easy to deal with, just get some indicator beam type torque wrenches and occasionally check what the dial tells you about the point the trigger-type triggers.
That one has a computer too, just a more rudimentary one. And rather than entering the number automatically into the relevant records, it relies on the memory of the technician, which also may be error prone.
Also how does the internet connected torque wrench know what bolt it is being used on? If you have different bolts, it wouldn't know. If you have only a single bolt, you could just use a single setting.
And network-connected wrenches aren't necessarily internet connected either. Back when I worked on critical infrastructure, we had a lot of networked machines that we simply air-gapped from the internet.
> Also how does the internet connected torque wrench know what bolt it is being used on?
I don't think most of them do, although this has been a focus area of some augmented reality tools. In most cases now, this is a task the technician has to do, regardless of the wrench they are using.
And network-connected wrenches aren't necessarily internet connected either. Back when I worked on critical infrastructure, we had a lot of networked machines that we simply air-gapped from the internet.
What I linked isn't connected to a network at all, what is your point here?
In most cases now, this is a task the technician has to do, regardless of the wrench they are using.
Then how would a network connected torque wrench make sure that airplane bolts are tightened better than a digital torque wrench? I think you're losing track of the context of this thread.
> Then how would a network connected torque wrench make sure that airplane bolts are tightened better than a digital torque wrench?
It reduces the potential for human error by automating part of the process and therefore reducing cognitive load and human err.
> What I linked isn't connected to a network at all, what is your point here?
My point is that you can leverage the advantages of a network connected wrench while also mitigating concerns about internet connectivity by just configuring the network. You don't have to use a tool with fewer features.
That Amazon wrench has no control over the consistency of the torque applied by the user. The user can simply just tighten bolts to any value, at any speed, every single time it is used. The automated wrench does all of the work. The user presses the button and it torques exactly the same, to the spec, every time. Manual torque wrenches are easy to misuse. Multiply that by thousands of bolts and you have a decent probability that you have a couple of bolts that were manually tightened a little too far past the beep, or was torqued too fast and beeped before it was properly torqued.
Factories do not spend huge sums of money on automated tooling for no reason. Automation in factories decreases human err and increases the quality and speed of output.
The idea here isn't that there is some benefit in theory, it's that it isn't worth it due to the extra complexity.
Maybe you can set new values (although wouldn't that imply that everything before it was wrong and wouldn't people need to check each one to make sure they're right anyway?) but then you end up having people ransomwear your wrenches.
Broadly speaking, it is worth it. Tools that are used in factories look more and more like this all the time, and these modernized factories are producing more product at more consistent levels of quality.
Again, the ransomware issue is easily mitigated. Not only can software be fixed, the wrenches can be also kept airgapped.
Also it is worth noting that there isn't any ransomware in the wild for these wrenches. This was a research exercise.
To be clear, even though the scenario you described doesn't make sense as being any more efficient or accurate, your response is just "broadly speaking, it is worth it" without any actual information.
The data entry part? One of the most unreliable part of any process? Even assuming that the wrench does the data entry and then needs to be connected to upload it to some link via a connected wire, you are still going to need tons of network related gear. And you won't have direct, live feedback over the process. If the worker needs to manually enter the stats then it's just even worse
I think it's mostly for assembly lines where the same task is repeated. I'd guess you might even have a "process" of a set of bolts to do one after the other in a specific order (which is usually the case for engines for example) but I'm not sure if the connected wrench knows or handles that
How exactly does it reduce "the potential for human error" by effectively adding countless other humans responsible for writing the software and maintaining the rest of the infrastructure necessary for it to work?
All it's doing is shifting the blame away from the one who should actually be responsible for the work.
You are correct, that one doesn't have a computer. It doesn't have many features required by modern industrial processes, though. It isn't suitable for building safety-critical systems.
I can somewhat understand why these torque wrenches are smart. The screenshot of the software interface showed a flow diagram of the tightening process and it looks like you very precisely describe how the fastener is to be tightened. A normal torque wrench doesn't do that, it's just torque limited and it's up to the user to make sure it's set properly and that the fastener is installed properly. Many torque wrenches can still apply more torque if you keep pulling them. If you require a fastener to be installed exactly the same way every time and to the exact same torque, a smart torque wrench might be required. However, I feel like the wireless feature is not necessary. These wrenches could easily just be plugged into a computer instead that could modify the settings or update the calibration due date or firmware. Tool condition could be displayed on the device and any sort of condition limits could be set to disallow use of the wrench until it's been serviced.
and it's up to the user to make sure it's set properly and that the fastener is installed properly
...and with these "smart" wrenches, it's up to the software developers, network administrators, hardware manufacturers, etc. All of which have to do a good job.
People like talking about supply chain attacks these days. A mechanical torque wrench has a much smaller dependency graph and can be easily calibrated and checked with a simple weight and a lever, and can't be programmed to behave subtly different every 12th bolt. These, on the other hand...
> precise torque levels that are critical for safety and reliability
This is why the thing is networked. Easier, more reliable, to pull that data (and then verify it was complied with) automatically from the network. In the most precision kind of work of that kind some decades ago, every bolt and hole would have a little sticker/tag on it, and there would be double-and triple-checked lists.
And this is why the vulnerability is particularly alarming. An attacker who targeted and compromised a manufacturer using these could, I dunno, slightly alter all the bolts used on an airplane, in a very specific way, so it is prone to failure prematurely.
These sorts of vulnerabilities have the same sort of potential for economic/national targets in a sophisticated (probably state-backed) attack, similar to that one which destroyed all those centrifuges in Iran: https://en.wikipedia.org/wiki/Stuxnet
> An attacker who targeted and compromised a manufacturer using these could, I dunno, specifically and slightly alter all the bolts used on an airplane, in a very specific way, so it is prone to failure prematurely.
Stuxnet was a more-or-less unprecedented operation against an extremely high value target, and while there have been other attacks against OT since then they've been a lot less sophisticated. It seems reasonable to rate the likelihood of mass exploitation here as unlikely, in fact that seems like an overstatement to me.
If I was North Korea and I wanted to make a few BTC while simultaneously embarrassing North America production lines, this would be a great way to do it.
Okay, well it turned out that the entrepreneurial yuppies in question failed to deliver on "it will just automatically do everything for you, we can't even define what, just everything". Now back to paper and human chain of command. Or we can keep pretending until the world's nukes can be remotely controlled by random people on the internet, you do you.
I will never stop being amazed that producers of high-end networked IoT equipment do not hire a pen tester team for their products. It's brutally hard to get networked security right, so you should hire an external red team from time to time.
So I doubt the market will Provide here. But there is a strong case for regulators / insurance firms
- choose (at least one) small SoC, with hopefully solid open credentials
- Define that as the “floor” for IoT devices.
- run a minimal kernel on it, enough that anyone can easily extend
- provide ten years worth of security patches and updates
- provide helluva good test rig
The people who built this were wrench engineers not nginix hackers - if their wrench cost 7p per unit more (but so did all the completion) do they mind as long as “that’s the standard way”
123 comments
[ 1.5 ms ] story [ 211 ms ] threadI imagine the requirements document didn't say anything about the public internet.
The UX is always trash, the security is non-existent, the smart-components are always low-spec and low quality (displays?). Is adding £5, £10, £100 to the cost of a unit to do it right going to hurt _that_ much?
Genuinely, I don't understand. Surely one of these things costs at least 5 figures and are bought in multiples of tens or hundreds?
Split agency problem - the person who buys it is not the person who uses it. (I am not a fish - Seth Godin)
> nobody can hire a skilled team of software engineers to write proper code for this stuff?
You see a huge company from the outside. From the inside it's a small team[0] in a cost center[1] who are always overworked.
0. https://www.bitsaboutmoney.com/archive/the-long-shadow-of-ch...
1. https://swizec.com/blog/the-3-budgets/ ; https://news.ycombinator.com/item?id=38851051
Because we need to track critical bolt rundowns (generically called fasteners) and tool condition.
That being said it doesn't need to be on the public internet, but it makes it a lot easier than setting up and managing a private network.
I'm not defending putting this tool on the public internet, but its very normal to put all kinds of stuff on the network in a manufacturing plant.
I'm sorry what? It's easier than setting up a portion of/separate LAN with no internet access? I mean, yes, in the strictest "lazy bastard" kind of way, sure. Can we not even ask that of businesses now?
Sure Bosch should've secured these things, that's a given and they should be rightly held to the fire to fix them. But also like... wifi routers have been a household staple piece of equipment since like.. 2008? Depending where you live? And we still can't ask business operators to do even the most basic due diligence in setting up their environment, or at the least, hiring someone who can?
This is like when you go to a restaurant and their access point is called Spectrum-Wifi-5G using WEP encryption with a password that's like, F8F023gX. Just well established that not a single fuck was given in doing this.
Have you ever worked in a manufacturing plant? Yes, the solution is TECHNICALLY very easy, but there's a bunch of gatekeepers that really slow things down.
The solution to the problem in front of you is always technically very easy and clear, but there are always a tremendous number of problems to be solved in a production manufacturing environment.
It's always the incentives. Always.
How many utterly mission critical e.g. CNC machines are run by a miraculously still functional Gateway desktop running Windows 98 Plus, camouflaged under a few decade's accumulation of rusty shavings from the nearby lathe?
And what difference would it make, anyway? In exchange for massively complicating every aspect of the monitoring and control tasks, you're just interposing the need to infect the battery firmware in order to pop the tool. Do you imagine the battery will be secure when the tool is not?
There are ways to solve the problem, it's just cheaper to make the tool an HTTP client and solve it on a server somewhere.
Updating the tool firmware, say - especially since with OTA updates unavailable for reason of the tool being forbidden to incorporate a radio, there's no other way to update the tool's firmware, not without complicating its design to expose a port rugged enough to survive the hard-knocks life an industrial tool is guaranteed to lead.
You might argue that this isn't worse than the current state of play - which would be true, but irrelevant, because in order to justify the massive cost and complication of this proposed design, you need to be able to show that the result is to a comparable extent better. You have yet to do that, and I doubt it can be done at all.
What are you on about? I'm arguing there were ways to solve the problem that didn't involve the tool connecting to the Internet. I don't need to show that my solution is better, because that has nothing to do with what I'm saying. And either way there's no "better" here. There's no objective measure of goodness. What's better to me and what's better to Bosch are not necessarily the same, and in fact they obviously aren't, as I never would have designed a tool this way, but then I don't have a tool manufacturing company.
You charge it once per shift, and you need an update every minute.
The dumb problem exists because of very real limitations.
Sorry sales team, your customer is dumb.
---
The previous step must be completed successfully before proceeding to the next step. A system records this information for posterity.
high precision factory gear in safety-critical applications seems like a reasonable use case to me.
Sometimes these sort of screwdrivers can drive other processes (e.g. once it confirms that the screw is correctly affixed, send a message to the manufacturing system to tick off that 'task' as complete at this station, and prompt the operative to start the next assembly task - the piece cannot move to the next manufacturing process until the screwdriver has confirmed all bolts are affixed at the right settings).
Which is why compromised USB thumb drives are a thing.
https://en.wikipedia.org/wiki/Stuxnet
Air-gapping your OT network protects the average company from 99.99999% of threat actors. If you're attempting to create nuclear weapons and a western nation is trying to stop you, you're either going to be compromised or murdered. That doesn't mean Bob's metal stamping should put the IOT controllers for his steel presses onto the public internet.
How are you reconning what actual PLCs Bob is using? How do you know what versions are on those controllers? How do you even know the address of someone who works in a position that has physical access to the OT network in the first place?
I'm not using a logical fallacy, you're pretending that Stuxnet is applicable to the average business and it just isn't for a dozen reasons I can think of and probably 2 dozen I can't.
> And how are you planning on getting a USB drive from Russia onto an air-gapped steel press in the US?
Why does such an attack have to originate from Russia?
> you're pretending that Stuxnet is applicable to the average business
No, you have missed the point. Stuxnet shows that a USB attack can succeed even against a state actor. It does not show that a state actor is necessary to mount such an attack.
And you're basing this on what? All of the OT networks I deal with are physically secured. You're swiping a badge and being recorded before you get anywhere near the production floor.
>Why does such an attack have to originate from Russia?
Because someone in the US compromising an OT network with ransomware is going to prison for a LONNNNG with little to nothing to gain from it?
>No, you have missed the point. Stuxnet shows that a USB attack can succeed even against a state actor. It does not show that a state actor is necessary to mount such an attack.
Go ahead and link some of the OT environments you've seen compromised by USB drive in the US. I work in the industry, you're going to be searching a lonnnnnnnnnnnnnng time to produce more than about 2 and both the ones I'm aware of were insiders who were immediately caught.
My knowledge of what I could do as an employee if I were to go rogue.
> Because someone in the US compromising an OT network with ransomware is going to prison for a LONNNNG with little to nothing to gain from it?
If they were caught.
> Go ahead and link some of the OT environments you've seen compromised by USB drive in the US.
There aren't many, but it's not because it's a difficult attack to mount. It's because there is a lot of lower lying fruit. You don't have to outrun the bear.
Someone did this to Iran's centrifuge controllers.
And IIoT makes lot of sense. Having worked with such products. You can monitor remotely equipment and even do data analysis on the data to find patterns. A real use of machine learning.
Not that it doesn't mean there shouldn't be very limited connection from singular or few gateway devices. And all of the other stuff stopping devices from connecting to and from internet...
You're subscription only allows 250 bolt twists. If you would like to upgrade your subscription, please visit www.wescrewyousoyoucancontinuetoscrewbolts.com
Every time a bolt turns more than 90 degrees BoltTweet(tm) will let all your friends and family know JUST HOW MUCH YOU LOVE BOLTS.
I don't know how many twists you are allowed, 250 seems a bit low. People can die if calibration procedures are not followed. If the manufacture says 250 twists, then you follow that 250 or you will lose millions in court.
That would depend on the accreditations involved, yeah? One would certainly hope that the manufacturer goes through a rigorous design and testing process to ensure that the recommended service/calibration interval is accurate and occurs before the tool wanders out of spec for whatever its intended task is.
As the end user you should presumably be able to reasonably adjust that service interval but it should require a similarly rigorous and documented process to determine how much more you can open it up, not just squinting at the wind and saying "eh they over-engineered it so I think we can get 30% more use out of before calibration"
That's where the accreditations and specs come in. If I'm torqueing down a new Ikea bookshelf, I really don't care. New tires at a chain shop? Middling, to the point that they don't over-ugga-dugga my lug nuts on and destroy the bolts. I'm gonna re-tighten them myself after a drive or two anyway. Bolts in a new airliner being tightened down at the plant? You bet I want that shit to be to-spec, and the tools, too.
how does this help some guy in a shop somewhere that doesn't need strict calibration schedules and bought the wrench secondhand or even firsthand?
In saying that, there were devices with similar restrictions before any IoT existed. Smoke alarms, CO alarms, breathalysers are all devices I’ve seen with enforced lifetime and/or usage counts.
Unpopular opinion: I'm not convinced we need internet connected wrenches for this. We may want or be excited about, e.g., monitoring torque with internet connected wrenches, but I'm not convinced we need them. This may be a scaling issue, related to being able to make things faster with less experience and oversight. I'm generally skeptical of the unintended consequences of scaling production like that, and it may be giving me a bias. But I stand by the statement that there is no fundamental requirement to make wrenches connect to the internet in order to manufacture sensitive equipment.
But there's real demand in the industry to use networked IoT devices wherever possible and harvest the data so you can do things like QC (hand an audit trail to your customer that all bolts have been tightened with the exactly right torque) or preventive maintenance.
No one wants to fall back to non-networked ways of manufacturing.
No one would care about IoT wrenches if they forced some app-based auth with mfa. We only care because we can trivially exploit them.
Companies like Bosch shipping these things insecure by default is the real problem. Near everything embedded does snmp 'public' with write options and very few devices force strong passwords or passwordless or force mfa. The embedded space is a mess and where computers were pre-2000.
This it the classic "we invented cars before seatbelts and don't want to spend money on safety anyways," scenario.
Regulation here is badly needed. The market won't fix this itself. Bosch isn't really hurt by this stuff. They can just blame operators, the same way Boeing blames pilots or airlines when their Max's crash or fall apart in the sky. This is a classic perverse incentive of capitalism at play here and now that politics has moved towards idealizing a low-regulatory environment, we're only going to see more awful scenarios like this.
This is my new benchmark for quality journalism: calling out half-arsed boilerplate press releases. This requires a journalist who genuinely understands the story, which is exceptionally rare outside of industry-specific journals.
"We've hacked your torque wrenches since adoption & changed the torque values to deceive your Quality Control on random random bolts on random aircraft. Pay us ransom to tell you which fasteners on which products were changed or recall them all."
Re-torquing every bolt on an aircraft would be ungodly expensive.
But when bit ignored that threat would be easy to deal with, just get some indicator beam type torque wrenches and occasionally check what the dial tells you about the point the trigger-type triggers.
Except it's real. In many "smart" devices, including industrial wrenches, security is an afterthought.
I wonder if we would be better off making manufacturers legally liable for selling utterly insecure, accessible-in-the-open devices.
More complexity, more chances for things to go wrong. Combine that with Murphy's Law and this is what you get.
Also how does the internet connected torque wrench know what bolt it is being used on? If you have different bolts, it wouldn't know. If you have only a single bolt, you could just use a single setting.
> Also how does the internet connected torque wrench know what bolt it is being used on?
I don't think most of them do, although this has been a focus area of some augmented reality tools. In most cases now, this is a task the technician has to do, regardless of the wrench they are using.
What I linked isn't connected to a network at all, what is your point here?
In most cases now, this is a task the technician has to do, regardless of the wrench they are using.
Then how would a network connected torque wrench make sure that airplane bolts are tightened better than a digital torque wrench? I think you're losing track of the context of this thread.
It reduces the potential for human error by automating part of the process and therefore reducing cognitive load and human err.
> What I linked isn't connected to a network at all, what is your point here?
My point is that you can leverage the advantages of a network connected wrench while also mitigating concerns about internet connectivity by just configuring the network. You don't have to use a tool with fewer features.
What is it automating that a digital torque wrench doesn't?
My point is that you can leverage the advantages of a network connected wrench
What are the advantages?
Factories do not spend huge sums of money on automated tooling for no reason. Automation in factories decreases human err and increases the quality and speed of output.
Again, this isn't a network feature.
Automation in factories decreases human err and increases the quality and speed of output.
Right, this is something that has been done already without networking.
I find it strange that anyone would be confused about the benefits of distributing information over a network on this website.
If you think these features have no utility, then why are factories buying them?
Maybe you can set new values (although wouldn't that imply that everything before it was wrong and wouldn't people need to check each one to make sure they're right anyway?) but then you end up having people ransomwear your wrenches.
Again, the ransomware issue is easily mitigated. Not only can software be fixed, the wrenches can be also kept airgapped.
Also it is worth noting that there isn't any ransomware in the wild for these wrenches. This was a research exercise.
All it's doing is shifting the blame away from the one who should actually be responsible for the work.
No computer.
Not sure if that means there is an issue with it or whether people are just "borrowing" it.
...and with these "smart" wrenches, it's up to the software developers, network administrators, hardware manufacturers, etc. All of which have to do a good job.
People like talking about supply chain attacks these days. A mechanical torque wrench has a much smaller dependency graph and can be easily calibrated and checked with a simple weight and a lever, and can't be programmed to behave subtly different every 12th bolt. These, on the other hand...
Because I very much appreciate the fact that some of my tools will not break my wrist, like the old dumb high power tools like to do.
Yes, torque wrenches benefit a lot from a "computer".
Neither did the GP say anything about network.
This is why the thing is networked. Easier, more reliable, to pull that data (and then verify it was complied with) automatically from the network. In the most precision kind of work of that kind some decades ago, every bolt and hole would have a little sticker/tag on it, and there would be double-and triple-checked lists.
And this is why the vulnerability is particularly alarming. An attacker who targeted and compromised a manufacturer using these could, I dunno, slightly alter all the bolts used on an airplane, in a very specific way, so it is prone to failure prematurely.
These sorts of vulnerabilities have the same sort of potential for economic/national targets in a sophisticated (probably state-backed) attack, similar to that one which destroyed all those centrifuges in Iran: https://en.wikipedia.org/wiki/Stuxnet
Hmmm...
https://www.bbc.com/news/world-us-canada-67919436
Did we forget about STUXNET? This IS very hard to do, but NOT unlikely.
- choose (at least one) small SoC, with hopefully solid open credentials - Define that as the “floor” for IoT devices. - run a minimal kernel on it, enough that anyone can easily extend - provide ten years worth of security patches and updates - provide helluva good test rig
The people who built this were wrench engineers not nginix hackers - if their wrench cost 7p per unit more (but so did all the completion) do they mind as long as “that’s the standard way”
Or am I dreaming?
--Scotty
https://news.ycombinator.com/item?id=38939581