As cybercrimes continue to increase both in volume and velocity your agency needs to be assured that the infrastructure and products you use have security built in. Whether it’s a radio, dispatch console or infrastructure component; designing a secure network architecture, from the ground up, is paramount to ensure that your mission critical voice and data is safeguarded. In my 30+ years of designing secure communication systems and products I have found that there are seven steps, that if diligently followed will result in a robust and resilient information & network security architecture:
1. Understand the threats
A threat is a force, organization (terrorist group, foreign government, crime organizations, or hacktivists) or person (hackers and insiders within your agency) that seeks to exploit a vulnerability in order to obtain, compromise, or destroy an information asset. When trying to understand the threats that you and your organization face you first need to think about the motivation behind the threats. Motivation is about asset value and means. An attacker is far more motivated to try to obtain a public safety agency administrator’s password that could give him access to a local police department’s database of confidential information than stealing the password to a single police officer’s database login. However, if stealing the password of a police officer is easier for an attacker to do, the threat to the officer’s password may be greater in spite of its lower asset value. Understanding the threats means you need to identify all of the data assets handled by the system, the value of those assets, who would be motivated to steal or disable those assets and most importantly understand why. Then you need to examine and note the various ways an attacker could gain access to those assets.
2. Understand network vulnerabilities
A vulnerability is a weakness in a product or system that can be exploited by threats to gain unauthorized access to an information asset. Vulnerabilities are the “weak links” that allow defenses to be circumvented; giving an attacker access to your mission critical voice and data communications. You only need to monitor the Common Vulnerability and Exposure list to realize just how vulnerable your devices and systems are. Many organizations will rely on “patching” cycles to mitigate some of the most common vulnerabilities but as studies continue to show that the speed and agility of hackers which can out maneuver such techniques in the form of zero day attacks. 2014 had an all-time high of 24 discovered zero-day vulnerabilities. Most notably the “Heartbleed”, where attackers moved in to exploit vulnerabilities much faster than vendors could create and roll out patches. The key to effectively mitigating vulnerabilities is to first understand what causes them and next to create a focused, layered defenses that limits the damage if a vulnerability is exploited. Often vulnerabilities are the result of design flaws, making patching cycles necessary. However many times they are the result of the misuse of a legitimate features. It is also important to understand dependencies and interactions between the vulnerabilities. I have found a layered defense or a defense in depth is quite effective at blocking or limiting damage from exploited vulnerabilities. For example, SE for Android is very effective at enforcing mandatory access control on device resources as long as the linux kernel underlying the Android OS is not compromised. This means you may need an additional security layer that protects the kernel depending on your anticipated threat profile.
3. Understand network constraints
Operational constraints are all too often overlooked or ignored by security architects who would rather invent an interesting solution than address the real problem at hand. According to a Clarus Research Group survey, “35 percent of respondents said budget constraints were the biggest threat to their IT infrastructure, 17 percent said that cyber attacks were the biggest threat, and 22 percent of respondents volunteered that all options offered on the survey from budget constraints, cyberattacks, limited bandwidth, technology limitations, and legal requirements are collectively considered the greatest threat to organizations. These constraints will inevitably get in the way of a “clean” solution. Nonetheless, these messy things define your space that your secure solution must fit into. Theoretical security is fine for the classroom. Applied security is what you need in the field.
4. Understand the value of what could be at risk
The first three steps result in a “context” for the data assets. In this fourth step you need to assign a “value” to each data asset by examining, in context, the consequences if the asset is stolen, modified or deleted. The greater the consequence, the higher the asset value. You then combine the asset values with their associated threats, vulnerabilities and constraints to produce a set of relative risk values. The greater the risk the greater the need for protection. This final risk model should then drive your security architecture toward a solution that is both balanced and effective.
5. Always question your assumptions
The step most often neglected in any development process is the one where all underlying assumptions are identified and validated. The effectiveness of any solution, especially a security solution, is directly dependent on the validity of the underlying assumptions. You must explicitly identify, examine, validate or correct all of your underlying assumptions about threats, vulnerabilities, risks and constraints if you want to eliminate oversight mistakes, identify any holes in the underlying logical architecture and establish a precise value to any residual risk.
6. Use what works
I am a strong believer in using design patterns. A design pattern is a “standard” or commonly used solution that works for a recurring or common design problem. Design patterns are used in many different fields of engineering, architecture and the trades. A simple example of a security design pattern is a shared secret used to enable symmetric encryption or authentication. Security design patterns should be used as often as possible in any solution simply because they work. Even the National Security Agency has endorsed security design patterns over proprietary solutions with their recent switch to standardize security algorithms and protocols to protect classified information. Bottom line; use as many security design patterns in your solution as you can because you know they work.
7. Do all the steps all the time
Many years ago in my junior engineering days a wise senior engineer by the name of Pete Lehey shared with me what he called “Lehey’s First Law of Systems Engineering” – it was: “You do all the steps all the time.” Another way to state Lehey’s First Law is – When developing a world class security solution there are no short cuts. You will always have the pressure and temptation to skip a step or shortcut the process in the interest of time, money or both. I have found without exception that you don’t skip steps, you only change their order. Sooner or later every step needs to be performed – it’s only a question of how much more it will cost to perform the step later than sooner.
To learn more about Motorola product security, visit www.motorolasolutions.com/astro or watch a video on ASTRO 25 security here.
