.st0{fill:#FFFFFF;}

Red Teaming Applications for UAS Developers 

Red teaming is a lot more versatile than you would imagine. While it’s often recognized as a way to test and analyze in situ security systems, it can also be employed in a number of other ways. I’ll highlight a few areas where red teaming can be used to solve business and technical problems you may encounter in the UAS or counter-UAS industry. In this article, I’ll focus on UAS developers.

Believe it or not, red teaming can be done at the very beginning of the solution life cycle. Red teaming, in a way, is just contrarian thinking. So, having someone play devil’s advocate or possibly a potential competitor before you even start designing the product may expose problems before they get large and costly. A red team can challenge your basic assumptions about the market, the competition, as well as key components like the concept of operation and technical requirements. Now, red teaming can also be conducted later in the product life cycle, but the value will decrease with time and there is probably a point where it’s not worth the effort.

***

You are working on a new UAS, but the potential launch customer has not been helpful defining requirements. They, like so many other end users, don’t quite know how to fully apply a UAS yet. “You’re the expert, get us a drone that works,” they say. So, how do you meet the unknown expectations of the customer while also making sure the competition doesn’t slip in with a better solution? One answer is to form one or more red teams that look at alternatives to your design. The red team will start from scratch with the concept of operation and requirements. Now, there’s a good chance an external or very well trained internal team will be able to extract more information from the customer as they are typically better at “interrogating” people. Then throw in some competition research and engineering, and they will be on their way to a few alternate designs or an alternate analysis of your design, depending how you framed the engagement. Either way, you should be able to get a good idea of where your design stands on value to the customer and position relative to potential competitors. If you are not over delivering on value, you need to get back to work on the design.

***

A UAS is a flying embedded system. So, cyber security is just as applicable to UAS as it is to a corporate network. But, why do you need to even worry about hard security, especially for consumer drones? Well that’s what red teaming is for. The red team’s job is to play a bad guy and go beyond the basic safety concepts that should already be in your designs. For example, instead of just looking at how your control system handles datalink or GNSS RF interference, the red team will look at what happens if the inference was intentional.  What are the vulnerabilities?  How can they be exploited? Then, as the developer, it is up to you to manage the risks. The risk of someone crashing a consumer multirotor out of spite is a lot different from someone commandeering a delivery UAS for some nefarious purpose. And the vulnerability that allows for commandeering is something you don’t want to find out about with hundreds of units in the field.

***

Let’s say you are not an airframe developer, but you provide an end-to-end data solution such as 3D mapping. This data may be very valuable to an adversary, particularly in a government or commercial setting. How do you know your product or service is secure? Sure, you can follow industry best practices, but how good are these practices for this application and is your design team following them properly?  Then there’s the potential issue of overcoming pride or tunnel vision to identify vulnerabilities in their own work. A red team doesn’t care about pride or tunnel vision, in fact they will try to exploit it. They are going to ruthlessly look at every aspect of your solution, from the sensor to the end user. When it’s done and the vulnerabilities are addressed according to your risk mitigation philosophy, you can be more confident is security assurances give to your customers. And again, this is done in the development phase long before a customer lays hands on the product. With people’s focus on data breaches these days, could you afford being responsible for one?

 In the next article I’ll discuss red teaming counter-UAS developers.

related posts: