Structured Complexity - better security models to reduce risk

Andreas Dannert

President of ISACA Melbourne Chapter

Information Security gets more complex by the minute. The number of options increase every year with new technologies becoming available. Organisations have options like outsourcing, insourcing, offshoring, virtualising, with BYOD (Bring Your Own Device) and without, and many more. On top of these options comes choice of technologies and more.

A well performing organisation takes advantage of these options and combines them in a way that matches their business model best. In return, such organisations can reduce their costs and increase their productivity. They also gain more flexibility and the ability to react to change faster than their competition.

With these options and changing environments come new risks. Each fine tuning of processes to manage information efficiently in an organisation has an impact on the underlying information processing framework. These changes lead to different vulnerabilities and hence to different risks. How can an organisation easily address these risks without every time undergoing a major rework of their security model? I believe the answer to this problem is utilising structures or patterns, similar to nature. We often find simple structures in nature creating highly complex systems on the outside. Take patterns in nature for example http://en.wikipedia.org/wiki/Patterns_in_nature. The patterns in themselves can be very simple, but create beautiful and complex looking plants, animals or structures.

I think that simple, well defined structures, allow organisations to address information security and associated risks in a similar fashion. We need to simplify the underlying structure of our security models. As a result we should see security models emerge that can not only be managed much more easily, but that are also adaptable to new business models without the need of first re-organising the existing model.

A lot of organisations seem to have highly complex security models with little to no structure. This leads to a situation where we can hardly evaluate the effectiveness of the model. Furthermore, proofing that these models are complete in a sense that they address all risks, is nearly impossible.

A good security model needs to be able to be evaluated and, ideally, even mathematically validated. To achieve this it needs to be well structured and be clearly linked to what the business requires. Taking a step back, this firstly requires clearly articulated business objectives linked to a business strategy. This strategy is then used to define business requirements and an appropriate enterprise architecture can be designed. Once we have this master plan we can start building our enterprise security architecture. I would argue that this can be done for any size of organisation, but is not necessarily always required to the same level of detail.

Once we have the overall master plan and enterprise architecture, an organisation should identify three components, prior to designing a derived enterprise security architecture:

  • Assets,
  • Risk appetite, and
  • Type of protections to apply to assets.

 

Organisational assets shall be defined as any part of an organisation required to do business. To me these parts are people, goods, information and processes. All organisations utilise them, but in different ratios, based on the type of organisation. These assets generally need to be protected against threats impacting one or more of the following core security attributes: confidentiality, integrity and availability. These attributes do not only apply to information, but people and processes as well.

The level of an organisation’s risk appetite is then defining how much of an organisation’s resources go into ensuring their assets confidentiality, integrity and availability. If one wants to further improve on this model we would have to include the effectiveness of the implementation of the resulting security model, which is highly dependent on choosing the most appropriate security metrics. Once again, organisations often seem to neglect to link these metrics to their business requirements. An obvious example for the wrong metrics would be measuring data breaches on information assets that are in the public domain anyway. However, the integrity of the same information might be crucial. This would then further impact the amount of resources to be spend on securing organisations assets.

In my view, the problem often starts with organisations not being able to clearly identify the parameters, like business requirements and assets, to define a security model. Hence organisations make it hard to clearly structure a viable approach in defining a well-structured security model. A simple question like what are your organisational assets often cannot be answered. In fact, often organisations cannot even list all the IT infrastructure they possess and might not even be able to validate all computing equipment connected to their internal network. In return, the resulting security models might not utilise the correct controls, get overly complex and cater for scenarios that are not even relevant. In short, the structure to address complex security frameworks is missing.

I am not implying though that having all the correct answers to building a good security model is easy. Organisations should, however, have traceability between the business requirements and the resulting security model and have a clear structure. This is essential for two reasons. First of all, it allows identification of required changes based on failures in the model. Security breaches are usually possible due to one of three reasons: An issue with the model itself, a poorly implemented model, or an attacker with more resources available then the defender. Secondly, a well-structured security model is important to adjust a perfectly working security model to organisational change. These changes can be subtle, like changing business requirements or dramatic, like an organisation would experience due to a merger or acquisition for example.

In summary, if an organisation’s security model is too hard to comprehend, it might not be because of the complexity of the information security, but because the model is poorly defined. Such models are hard to validate and most likely create additional risks. Simplifying its underlying structure, not its overall complexity, can dramatically improve an organisations security stance in my view.
 

This article is brought to you by Enex TestLab, content directors for CSO Australia.

Tags: information security, security models, Risk appetite, business requirement

Show Comments