Tips for improving cyber-security strategy

‘Hacktivists’, ‘advanced persistent threat’ and ‘cyber-security’ are all parts of today’s information security lexicon. The hope is such terms will create a reaction in people: one that will help counter the threats we are increasingly aware of as a result of recent cyber attacks. The danger is these words will be written off as hype, which will lessen the reaction.

These threats can only be effectively countered by going back to first principles and considering all phases in a system’s life, and all levels of abstraction in the meaning of the word ‘system’. This necessitates a change in the way we develop systems: one that puts security at the heart of every stage of a project.

Many of the systems operating today have been developed to meet functional requirements and have had security retrofitted after their release, or by virtue of context. By considering system security from first principles and managing security in each phase of system life, the result will far exceed any effect that can be achieved by retrofitting.

The system view
Systems, in the most abstract sense, are entities or components that do things to inputs to create outputs. The entities have structure, behaviour and – most importantly from a security perspective – interconnectivity. The transfer function (the behaviour) can be linear or non-linear, based on memory and parameters. Behaviour can be random or chaotic.

The system and the transfer function characterising it can be stable or unstable.
An invoicing system for a business is a system that can be vulnerable. An engine management system controlling a car or aeroplane is a system that can be vulnerable. A control system for an industrial production line is a system that can be vulnerable. An IT system forming the business system for a company is a system that can be vulnerable.

While the last example is in the classical domain of the cyber-evangelist, all these examples have inputs and outputs – they therefore communicate. By meddling with the inputs in an unauthorised way, an unexpected effect may be created at the output. Equally, meddling with the transfer function or component itself may create an unexpected output.

By instilling security into the complete development process, systems implementers can attain massive security gains for little or no additional cost

Welcome to the entirety of the problem space of the cyber-security practitioner. To put it another way, interfering with the ‘fly by wire’ electronics on a passenger airliner is a cyber issue just as exfiltration of company secrets by a state-sponsored attacker is.

The development view
Systems implementers are so focused on meeting the functional requirements specifications that non-functional issues often do not receive the same degree of scrutiny. By instilling security into the complete development process, systems implementers can attain massive security gains for little or no additional cost.

Classic systems engineering doctrine contributes a great deal to the rigour that can be applied in the development phase of a system. This in turn will contribute to increased assurance in the end system or product.

Taking cyber-security strategy to the next level
Following on from that, assume the entity a developer’s subsystem is communicating with is Dr Evil masquerading as the expected end system. Therefore, design strong authentication into the system. The assurance around this authentication should be appropriate to the damage that can be done by someone masquerading.

When calling subordinates functions (particularly in software) make sure error-handling fabric is plumbed in appropriately such that, when errors occur, the incident responders have a fighting chance of deducing what went wrong and addressing the issues.

If the firmware of the execution fabrics has features that aid security, use them. This means features such as watchdog timers, power conditioning circuits and high assurance reset hold circuits. These all help mitigate execution code locking up. This may seem obvious, but there are many products on the market that have in-built watchdog timers whose software locks regularly.

Think about the overall logic (i.e. execution) of what the system is trying to do. Weigh up the advantages and disadvantages of using polled vs interrupt driven execution for certain aspects of system architecture. Make sure development occurs within the framework of an appropriate development methodology. The prime focus is on getting a system to market in a maintainable manner that meets client requirements (i.e. attains client satisfaction, which is the focus of quality management). Many of the controls in this context are appropriate to information security and can be read across.

Make use of security standards as appropriate (ISO 2700x et al). These are mature, peer-reviewed documents that achieve good coverage across the piece. However, beware consultants bearing checklists; the value of these standards is you actually think about your business in the context of security and therefore the countermeasures that result. This means, when in the final stages of risk mitigation, security barriers can be put in place to mitigate specific residual risks.

Minimise risk with built-in mitigation 
If a system is released onto the market with little or no consideration to the points above, no firewall or security barrier is going to make risk manageable. Conversely, a well-engineered system may not need additional controls as sufficient mitigation may have occurred in the development phase to make operational risk manageable.

The issues raised are very similar to those that have long been discussed in the context of safety systems. It is important to increase the penetration of this understanding into the security engineering space. This will lead to systems that are not only secure, but are also robust and resilient.