Tag Archives: drone

Developing counter-drone technologies not so easy

1 Reply

It’s not easy countering drones.

As fast as the drone industry is growing with hobbyist and commercial drone counts in the low millions by 2021, some anticipate that the counter-drone industry will be even larger with a combined annual growth rate of almost 26% between 2017 and 2021.  Increasing the challenge, because of the multitude of factors involved in drone deployments and the many places of interest where drones can be deployed, whether individually or en masse, there are a surprisingly large number of scenarios to consider when developing and deploying counter-drone technologies and that in turn makes development and deployment of counter-drone technology particularly difficult.

There are obvious concerns amongst commercial, private, and government entities around risk stemming from drone use (to include property loss, privacy, injury, and potentially death) — such as drones over flying nuclear plants in France, drones snooping in the Olympics in Rio, drones with cameras outside 26th floor high rise apartments in Seattle, and many others. The challenge is that there are so many factors and so many interdependencies between those factors, that it can be hard to establish a shared conceptual framework around counter-drone approaches to even have a discussion about the concerns.

Already, many different approaches to counter-drone strategies

The broad and varied approaches of counter-drone technologies already on the market speak to the diversity of potential drone deployments and the areas in which they will operate – and which ostensibly there is a desire to be countered. For example, DroneShield’s DroneGun uses a rifle-like radio frequency jammer. Skywall uses a shoulder-fired drone-capturing net. The US Air Force is trying out net-filled shotgun shells by SkyNet and Malou Tech offers drone-nets-drone technology. And the US Navy and Marine Corps bring it on home with laser, aka directed energy, anti-drone approaches. The approaches are wide-ranging and I think we’ll continue to see even more evolution and many more companies in the space.

One approach for considering counter-drone systems

An approach discussed here splits out variables/attributes in drone deployments and operation from the variables/attributes of the operating area and what it contains into two separate sets of factors. This provides a broad base for conceptualizing counter-drone considerations. These two sets of factors are:

1. drone deployment attributes and
2. drone operating area attributes

In turn, each set of factors also has its own multiplicity of factors and interdependencies between them.

counter-drone sets of factors071017

many factors to consider in counter-drone systems development

 

Drone deployment attributes

When considering how to counter drones, there are many factors that contribute to any particular drone deployment. A few of them are:

  • Mass – How much does the drone weigh?
  • Altitude – Is there a characteristic altitude of the deployment?
    • < 50 feet?
    • 50 – 200 feet?
    • above 200 feet?
    • varies?
  • Potential Energy (PE)
    • derives from mass & altitude
  • Velocity
    • Is there a characteristic speed of the drone(s)
      • 5 mph?
      • 5 – 20 mph?
      • > 20 mph?
      • Varies?
  • Kinetic Energy (KE)
    • derives from velocity and mass of drone
    • rotor rotation also contributes to KE
  • Volume – What is the size of the drone?
    • cross-section?
    • diameter across opposing rotor tips?
  • Cardinality
    • Is it just one drone?
    • 2 – 25 drones?
    • 25 or more drones?
  • Behavior >1 drone
    • is the behavior coordinated?
    • are they operating independently?
    • sporadic?
  • Intent – Is the operator intent:
    • malicious?
    • benign?
    • negligent?
    • operator-impaired?
  • What is the payload of the drone?
    • nothing?
    • camera?
    • explosive
    • radiological?/chemical?
    • combination?

Effects of factor interdependencies (aka Potential Energy can become Kinetic Energy)

As discussed, these factors can have substantial interdependencies between them as well. One of the interdependencies that is the most basic and seems to be often forgotten in conversation is that any drone with any altitude has Potential Energy. Regardless of motors, batteries, wind, payload, etc — just the fact that a mass (drone) has been raised to an altitude, it now has Potential Energy. The larger the mass and the higher the altitude, the more Potential Energy is converted to downward directed Kinetic Energy if a drone stops flying – for whatever reason. This may be important to anyone in the path of the dead drone’s earth-seeking trajectory.

city2

Drone operating area attributes

The other part of the equation is what is the drone’s operating area? What are those things on the ground (or in the air) that have value? This could be the value that one puts on their individual privacy, to the value a corporation puts on a production facility, the value a city puts on a power substation, or the value of 50 people watching a little league game or 50,000 people watching an NFL game. Some operating area attributes/variables include:

stadium2

 

  • Does/do the drone(s) fly over a population?
    • Population size – 10’s, 100’s, 1000’s, more?
    • Density
      • rural
      • city
      • high density congregation (eg professional sports game, parade, concert, ..)
      • does the population density change, eg high when ball games & low when not
    • Does/do drone(s) fly over/near critical infrastructure?
      • power
      • water –  dams, reservoirs, …
      • gas
      • sewer
      • nuclear
    • Does/do drone(s) fly over/near schools, churches, hospitals …
    • Does/do drone(s) fly in area of critical radio spectrum?
      • broadcast
      • police, fire
      • aviation, marine
      • military

    ci2

    Counter-drone Combinatorics

    So let’s take a combination and create a constraint domain to illustrate the point.  Where there is a broad range or spectrum of possibilities for a particular attribute, I break them down into three arbitrarily chosen sub-ranges. This will allow us to make the numbers smaller and a little more manageable and yet still see how the number of possibilities to consider can become quite large. You can, of course, break them down into whatever sub-ranges you would like and into as many sub-ranges as you would like.

    the number of scenarios can scale quickly

    the number of scenarios can scale quickly

    Some counter-drone systems will naturally address multiple scenarios. However, to be effective and competitive in a rapidly growing market, the counter-drone systems developer has many flight profiles and many operating area profiles to consider.

    Another factor in counter-drone technology development is the legal aspect. Examples include laws regarding national aviation system navigational system protection, individual state law, and civil lawsuits. This will likely be a substantially evolving landscape as drone technologies evolve and damaging events occur with real loss.

    Dynamic landscape

    When considering the factors involved in developing or evaluating counter-drone technologies, one approach that can be helpful is to think about both the characteristics of the drone (or drones) potential flight as well as the area in which the flight will occur and what’s valuable in that space.

    With rapidly evolving and distribution of drone technologies, rapidly evolving counter-drone technological approaches, increased public awareness, and changes in local, state, and federal laws, I think investment, development, and deployment of counter-drone technology will continue to be a very dynamic realm.

Creating initial IoT risk categories

Leave a reply

With the onslaught of new IoT systems and devices as well as existing old school IoT-ish systems such as HVAC, we all know that this is risk that needs to be assessed and managed. However, some of it is so new that we don’t really know where to start. We don’t have a broadly understood language to discuss, categorize, and classify new IoT systems. There has to be at least some rough categorization if there is going to be any attempt to manage risk brought to our organizations by evolving and rapidly growing numbers of IoT systems and devices.

Whence it came — using provenance to create IoT risk buckets

One approach to an initial categorization to IoT systems and devices can be to identify where those IoT systems are coming from. How do they show up in your offices, buildings, and corporate/institutional spaces? How did they get there?

Some IoT just 'walks on' to corporate and institutional spaces while other IoT systems are purchased via different mechanisms

Some IoT just ‘walks on’ to corporate and institutional spaces while other IoT systems are purchased via different mechanisms

While trying to categorize IoT systems and devices by function, features, behavior, etc is a logical approach, it can be difficult to do in practice because so many new and varied IoT systems, devices, and applications are constantly showing up on our networks. Categorization and classification with this more traditional method can be a moving target, at least for now. Also, this approach can lead us down a rabbit hole looking for a perfect (and complex) taxonomy that would take a long time to develop, would likely be poorly understood, and probably largely not agreed upon. It reminds me of some older large websites that might have had perfect, library-like taxonomies but where 90% of the pages were never accessed.  The website’s taxonomy might have been awesome, but no one cared.  In fact, that perfect taxonomy might have actually diminished usability.

To begin the process of managing IoT risk now, we need some categorization now so that we have some buckets of risk to work with. This doesn’t mean that efforts to develop other classification schemes should be abandoned, but rather that categorizing IoT risk by source, aka the-way-it-got-here, is an approach that we can work with now.

Size matters

The manner in which businesses or institutions purchase IoT devices and systems typically varies with size of the organization. Smaller organizations will likely have fewer purchasing mechanisms than larger organizations. For example a small company might write a check or use a company credit card to purchase a simple IoT-based security system. Where as a larger organization might have a person or purchasing department that handles many purchases, uses purchase orders and invoicing, and probably has some purchasing policies and criteria and is used to purchase an HVAC system, for example.  And yet an even bigger organization or government might have a central planning office that makes recommendations for new buildings or large scale building or community asset modifications. Larger organizations probably have all of these.

Regardless of how many purchasing options an organization has, using purchasing options to create categorized buckets of risk for IoT devices and systems could be a helpful way to go.

Walk-On-IoT — bring it, wear it, or fly it to work

One thing that all organizations have in common is that they all have “walk-on-IoT”. By the walk-on-IoT category, I mean IoT systems purchased or acquired by an individual on their own and that they then bring to work. Whether it is FitBit devices, drones, robotics, consumer networked video cameras, or others, these are devices that a person can purchase at BestBuy, Target, Amazon, or even their local drugstore and bring directly to their corporate or institutional work place.

Other potential source-based IoT risk categories

Some other potential source-based IoT risk categorizations might be:

  • IoT devices/systems purchased with a company credit card
  • IoT devices/systems purchased via a company’s central purchasing/contracting group
  • IoT devices/systems recommended in the course of planning for major building modifications or new buildings (eg, in the case of large businesses and cities)
Identifying where an IoT system or device came from as a basis for initial IoT risk categorization

Identifying where an IoT system or device came from as a basis for initial IoT risk categorization

With these categories, we can start to ask some high level risk questions within each category. For example, is it even possible to feasibly manage this risk? If this risk is unmitigated, what is the impact? For example, can I really manage FitBit devices that walk on to my network? Probably not easily. More importantly, do I really care if FitBit users use their devices on my networks?  Maybe not.

Conversely, because of privacy issues and other concerns, I might indeed care about how an enterprise-wide biometric building access system is selected, installed, commissioned, and supported over its lifetime. Furthermore, this risk probably is manageable with thoughtful institutional safeguards.

Source-based categories can lend themselves to unique risk mitigation approaches

Finally, sourced-based IoT risk categorization can also provide some natural mitigation approaches. For example, purchases via central purchasing can provide the opportunity to see a purchase request (prior to actual purchase) and then provide guidance on the selection of the IoT system, help identify resources for secure implementation, as well as help develop long term support plans for the IoT system. While less involved, IoT purchases via corporate credit card have records amenable for review so that an organization can get an estimation of number and variety of types of IoT devices and systems arriving in the enterprise. This can help with ongoing mitigation and support services planning.

Source-based categories for IoT system risk analysis and management for the enterprise can be a place to start. It is not the end-all by any stretch. As more IoT systems and devices enter our enterprises, we will learn more about their short and long term effects as well as emergent effects between IoT systems. From this we can continue to evolve categories and approaches, but if we need a place to start now, source-based risk categories are not a bad idea.