Security Strategy and Architecture
Today’s information professionals and their clients are confronted with a rapidly changing landscape of new and emerging technologies, customer demands, legal and regulatory burdens, as well as increased cyber threats and attacks on corporate data, customer information and trade secrets. H2 provides organisations with a flexible approach both to address the changing threat landscape and to meet their regulatory requirements and business goals. Our approach is comprehensive and enables our clients to be consistent in balancing effective cyber-security risk management with efficient achievement of business objectives.
Key to determining a cyber security strategy is a detailed risk analysis which includes a view of the impact of breaches in security on the business.
This will inform the selection, deployment and management of Appropriate, Affordable and Accreditable controls.
Appropriate in the sense that controls need to support rather than hinder business process as well as being capable of achieving their goals.
Affordable may seem self-explanatory, however in the context of cyber security controls and overall budgetary constraints, return on investment is as important as cost effectiveness.
Accreditation to agreed cyber security standards – of which there are many, is crucial for such any organisation.
Being able to provide a trail of evidence which demonstrates on going compliance to selected standards is essential in times of crisis
Having carried out a risk assessment, or examined and corroborated an existing risk assessment, it is then necessary to come up with a risk treatment plan, that is a plan which either eliminates or reduces risk to an acceptable level by applying security controls which may be procedural in nature rather than technical, but will almost certainly involve both. This in turn informs the Security Architecture Design which must dovetail with the other technical designs of the system. It is essential in fact to begin this design at the first logical design stage to ensure that security is in built from the start. To attempt to retrofit security is fraught with problems and will almost certainly result in failure.
H2 applies this approach to all services and project streams relevant to a project, aligned with ISO27001, with the specific aim of ensuring that the architecture fundamentally ensures consistency and integrity and that cost-effective risk management is maintained.
By presenting a hierarchical view of the architecture it ensures that the governance requirements and their underlying security objectives are applied across other such related architectural frameworks. This view is further enhanced with a mapping of the countermeasure set onto the conceptual view of security applied. This mapping was further expanded to include the totality of security enforcing functions (SEF's) and could then be traced back to the original risk assessments.
The Level 0 Security Framework provideds the following complementary benefits:
Describes the high-level alignment of the risk assessments to the SEF’s.
Promotes a consistency of security architecture across the project streams to avoid gaps or overlays in controls applied or the use of inappropriate controls that are not commensurate with the risks identified.
Promotes re-use where services and architecture are common to all project streams.
To further enhance this conceptual view, the Security Architecture provides a high-level logical view and context of the security requirements and SEF placement for the various project streams. This should be underpinned by an ISMS which includes the security policies and objectives that must be applied consistently across the organisation. It logically depicts the end-to-end design of the functional components for all project streams and documents the selection of pragmatic and cost-effective controls to manage the Confidentiality, Integrity and Availability of information and assets and protection of staff and resources, with traceability back to the initial risk assessments.
This approach enables H2 to take a more risk managed approach to security architecture design, moving away from the bastion view of security, making it possible to look at each component of the system individually and assess risk and mitigation, as well as the dependencies, and interoperability.
All controls, whether technical or organisational should be determined as a result of the risk and business impact assessments.
Technical countermeasures should conform to the requirements of the associated risk treatment plan and the overall Security Architecture Framework. This IA Framework provides context to the policy, strategy, requirements and governance required within the program.
Using this methodology we are able to produce a ‘defence in depth’ security architecture which satisfies the risk appetite of the client and provides the relevant countermeasures identified to satisfy the risk assessment and risk treatment plan, by combining new technologies with the more conventional technologies we can design solutions which are innovative and effective.
In order to successfully do this, we must be able to understand the system, in terms of:
The business drivers
As an organisation we work very much in partnership with the system suppliers. However, that does not mean that we can abdicate responsibility of the business focus to them. On the contrary, they will want H2 to produce cost estimates in line with the security architecture and the counter measures being proposed.
Organisational culture is very important and can vary hugely between organisations. Solutions that run counter to an organisations culture are unlikely to be adopted, no matter how sensible they are. It is an important to ensure that we recognise this and put forward suitable solutions that take that into consideration.
Sound planning is the cornerstone of sound design and as mentioned earlier, communication is core to success. Misunderstandings, leading to confusion will result without it. These are key components of our skill set, if we do not communicate effectively then our ideas and recommendations will not be understood by the client, who consequently, will not buy into them.
The business drivers
what applications to be used
what their role is within the system
what functions they bring to the system
whether any of those functions have an explicitly security oriented role
how the components work
hardware and build standards, virualisation etc
the vulnerable points of the system
the threat to the system
duplication; whether components are duplicating functions, possibly leading to increased vulnerability