Subscribe to SMARTCOM

Complete your email address and details below to receive the SMARTCOM newsletter.

Please leave this field empty.



By clicking ‘Subscribe’, you are consenting to the terms of use and privacy policy.

Subscribe to SMARTCOM

7 Steps for Developing a Robust and Resilient Security Architecture |

Public Safety
7 Steps for Developing a Robust and Resilient Security Architecture

As cybercrimes continue to increase both in volume and velocity your agency needs to be assured that the infrastructure and products you use have built-in security. Whether it’s a radio, dispatch console or infrastructure component; designing a secure architecture – from the ground up – is paramount to ensuring that your mission-critical voice and data is safeguarded. In designing secure communication systems and products there are seven steps that, if diligently followed, will result in a robust and resilient security architecture

  • Understand the threats

A threat is a force, organisation (terrorist group, foreign government, crime organisations, 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 organisation 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 or her 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 achieve, 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, why. Then you need to examine and note the various ways an attacker could gain access to those assets.

  • Understand the vulnerabilities

A vulnerability is a weakness in a product or system that can be exploited by threats to gain unauthorised access to an information asset. Vulnerabilities are the weak links that allow defences to be circumvented; giving an attacker access to your mission-critical voice and data communications.

Many organisations will rely on patching cycles to mitigate some of the most common vulnerabilities but studies continue to show that the speed and agility of hackers can out-manoeuvre such techniques in the form of zero-day attacks. In 2014, there was an all-time high of 24 discovered zero-day vulnerabilities. Most notably was “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, then to create focused, layered defences that limit the damage if a vulnerability is exploited. Often vulnerabilities are the result of design flaws, making patching cycles necessary. However, often they are the result of the misuse of a legitimate feature.

It is also important to understand dependencies and interactions between the vulnerabilities. I have found a layered defence or a defence 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.

  • Understand your 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 aClarus Research Group survey, 35 per cent of respondents reported that budget constraints were the biggest threat to their IT infrastructure, while 17 per cent said that cyberattacks were the biggest threat. Another 22 per cent of respondents volunteered that all options offered on the survey – budget constraints, cyberattacks, limited bandwidth, technology limitations, and legal requirements – are collectively considered the greatest threat to organisations. These constraints will inevitably get in the way of a “clean” solution. Nonetheless, these messy things define your space into which your secure solution must fit. Theoretical security is fine for the classroom. Applied security is what you need in the field.

  • 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.

  • Always question your assumptions

The step most often neglected in any development process is 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.

  • 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 standardise 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.

  • Do all the steps all the time

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.

Watch a video on ASTRO 25 security here.

By Tom Mihm, chief security architect for secure products group, Motorola Solutions