A common challenge in numerous companies is the mixture of security controls. This is due to the fact that organisations have historically deployed controls in response to a specific problem at a point in time. In bigger organisations this has often led to disparate controls applied throughout the environment with very little thought given to consolidation, cost effectiveness or standardisation. For this reason it is critical for all large enterprises to develop and implement an Enterprise Security Architecture (ESA) programme.
While this has now begun to change, this legacy challenge still remains. Owning and effectively utilising an ESA would allow the organisation to develop a standardised approach to implementing the correct control at the correct location while fulfilling one or a number of security drivers and in turn, the business objectives too.
In its simplest form, an ESA involves creating a medium to long term security plan based on the business and its objectives and then implementing an appropriate custom set of technical and non-technical controls for use throughout the ICT environment. Each control should be chosen based on its suitability to align to both the organisational goals and the overarching security drivers. As such, the organisation’s business goals should be the starting point for a set of security drivers.
Security drivers often include generic requirements such as the ability to enable business, scalability capabilities (both cost and platforms), usability, operational cost and commercial viability. More specific security control requirements might include cloud specific controls, vendor standardisation, integration requirements, engineering supportability and product life cycles.
In more detail, an ESA begins by documenting the organisation’s objectives, critical assets, any relevant business processes, structure and operating locations. This allows the Enterprise Security Architect to understand the business requirements before developing the security principles to be applied.
Documenting the appropriate and specific security principles for the organisation provides a list of high level rules to be followed when implementing any form of control within the environment. An example of this is the development of a public facing ecommerce application requiring an acceptable level of security to be applied prior to go-live. If the principles were previously approved and documented in an ESA framework, the time to implement the website and appropriate control items will be much shorter than if nothing was implemented or documented. It should be noted that the principles must include items such as the overarching information security and risk management frameworks in use as these often set the baseline for governance and assurance programmes which are critical to understanding the strategic direction of the ICT landscape.
To effectively support the business objectives, every aspect of the ICT landscape within the organisation can be categorised into a particular technical domain, these might include infrastructure, data, perimeter and identity management. Each of these domains should have an identified and accountable owner and an overarching administrative policy defining the appropriate usage of the assets within the domain. Lower level policies can be developed under the top level domain if necessary for those areas which require additional information. Policies should be written within a clearly defined scope and in plain easily understood language as these are aimed at communicating the contents to users, vendors and suppliers simply and effectively.
Only once a clearly defined security domain and policy framework has been developed and implemented should the appropriate technology controls be determined and deployed. As the business requirements and security principles have previously been clearly documented, all controls being considered must align to these without exception. If a single control does not meet the necessary parameters then a combination of controls may have to be implemented to maintain the security posture. Should an exception be required at this level then a valid business reason must be provided and the risk should be classified and handled through the appropriate process for treatment and sign off.
Another critical output of an Enterprise Security Architecture plan is a future looking customised roadmap for the organisation in-line with the documented understanding of the business and its objectives. To be truly effective, this must be developed with the full enterprise picture in mind so that all areas of improvement or development are taken into consideration.
This roadmap should be developed with agreement from the business and IT teams as their strategies will be critical inputs into the longer term plan and control choices for the domains. Care should be taken to develop it across an agreed upon and a realistic timeframe.
Any ESA plan requires an understanding of the current state and strategy of the enterprise and then utilising this information to develop a forward looking strategy and roadmap for improvement of the security landscape specifically designed for that organisation. While it is important to retain the plan, any changes to the organisation and its strategy or structure may require an update of the ESA plan to ensure that it remains relevant to the context. This will require ongoing monitoring of improvements to control maturity and the measurement of the return on investment that the business expects to achieve. Crucially, the plan must be reviewed at least annually as a “checkpoint” to ensure that it remains relevant in today’s fast changing information security landscape.
As part of the ESA plan you need to consider how your teams will operate any new controls once the service/solution has been deployed and commissioned. This will require some thought to which service team will own the day to day support and if any new processes will be needed. Resource overheads should also be validated well before the service is expected to be onboarded.
As important as the long term plan might be, it’s essential to communicate it via a change management process to all stakeholders both for transparency and to confirm that your efforts and purchases are aligned to a singular purpose. Without this you will have external teams questioning why you make some of your decisions and could increase push back against your choices. A well executed communications plan will minimise any security change fatigue and ease the implementation of your roadmap.
Bringing all of this together in a well thought out plan with stakeholders consulted and informed when required will ensure that you have top to bottom strategic alignment and approval. Consolidating the security improvement metrics and accurate reporting during the deployment and implementation phases and then including events from the service layer will allow you to prove the value of the investments from the bottom up.
In summary, this is an extremely simplified overview of applying enterprise architecture context to a security team or business but is meant as an introduction to enterprise security architecture at a high level. Building an ESA plan takes a significant amount of time and effort to do effectively.
If further security specific knowledge of EA is required, the SABSA framework is an excellent and detailed resource, or get in contact with our experts to find out more.
