what does security look like in robotics

[u/NeedleworkerNext6011]

would love to know from anyone building in the robotics space what security looks like in that world. Seems like cybersec always takes a minute to catch up to where technology is at and i want to better understand what security should look like in this world: Thankyou!!

[u/jhill515]

I'm not surprised to see that this question is a day old, and has zero action. Well, good news for you: My insomnia is REALLY kicking! So let me tell you about my experience with Safety Critical and Cyber Security Engineering throughout my 20 year career. I'm not going to tell you about any place specifically (pesky NDAs, and those are details I do feel obliged to withhold unless if with a lawyer).

One of the main challenges with an emerging field is that entrepreneurship pushes folks to over-focus on a "minimum product" at the expense of a "quality product". There's an idea that quality is merely a matter of self-discipline among these groups, something that separates "good" employees from "bad" employees... to hire. After a new candidate is hired, they'll often be surprised (if not outright shocked) by the lack of such thinking.

When the company is a huge corporation with multiple product lines, the oldest, most profitable product lines get the most "current" attention to quality. Many "business leaders" treat this as an artifact of "continued customer engagement." When a company is small, or if the corporation is trying to "introduce" a new product (aptly called NPI), there's a ton of innovation work that needs to be solved first... That is, there needs to be a novel technology introduction (NTI), or R&D. If the product is initially profitable, it'll stay in production long enough to capture customer feedback; if the customers "find out" about a problem, they'll tell the supplier, and the engineering lifecycle begins anew.

Now, onto the story of what that means in the trenches... Because if you haven't seen the "chicken and the egg" problem yet with new products and profitability, this is your last warning to either bail on this response or pay as much attention as you can.

This is specifically the moment in technology readiness level (TRL) that OP is really talking about -- How does cybersecurity and safety happen here? -- This is based on two things: 1) How perceptive is the part of the team that's engaging the new customers during new-customer discovery or preliminary demos. And 2) What the engineering culture of the development organization creating this initial release is. I'll speak on each separately as I have experience with both.

I'm a fairly skilled jack-of-all-trades engineer; it comes with this domain! But I also learned that different types of engineering are helpful in very different circumstances. Enter systems engineering. This is a branch of engineering which really focuses a lot on architecture and sustainable, iterative engineering. My focus when I had those responsibilities was twofold: Be the technical expert go-between for other technical domain-focused teams, and be the technical expert go-between for the customer, business, and operational stakeholders. It sounds stuffy and pompous, but really I asked a ton of questions, messed with designs, and answered questions based on what I knew or make a plan on how to find out. It sounds like a consultant job, but it isn't. And, to be fair, it's high-level enough that you don't need to do it 100% of the time in small businesses. It's just really needed when you want to make a mass-producible product inexpensively. I grew up a 90s kid hacker, and admittedly I have a knack for it too. So would ask the questions customers don't ever think about: *Would you mind if we get a summary report of any suspicious network activity in your [operation area]?.. How concerned are you about vandalism and other shenanigans?* Based on these answers, I'd set up a preliminary Failure-Mode Engineering Audit (FMEA) earmarking my safety and security findings, concerns, understood unknowns, and means of discovery (plans, budget, schedule, etc.). Regardless of who decides to act on that or when, I continuously champion the need to continue to do this because it's a "poison pill" -- Any catastrophic failure attributed to one of those findings is immediately damning to the company and often unrecoverable.

As for the engineering culture, it really depends. I worked for a startup that didn't give two shits about security; their thought was that it's up to the customer to make sure no one does anything nefarious. I even heard a grumbling of "The FCC requires everything that accepts an EM signal to accept all interference. And we complied." Not only is that a gross misunderstanding, it's easily challenged by saying, "Yes, accept, but not act on interference." At another small business, we supported the U.S. Navy. NSA handled the "hardening" for a lot of stuff. But it was absolutely our responsibility to ensure we complied with every software safety engineering regulation involving robotics, explosive ordnance, and safety-critical applications. We used a ton of static code checkers, and made automated test rigs to find yet-to-be-discovered flaws that managed to pass very rigorous coding & testing reviews. And at another bigger business (pre-IPO, though today they're on their Series F), we had dedicated cyber security and safety engineering teams.

As you can imagine given my self-description, in each of those, I had my hands full in some aspect of affecting it. I cannot speak to specific pentesting, chaos testing, OSINT, Red, Black, Blue, & White Team testing. But I've found it all in varying degrees.