Security Architecture - From Zero to Hero: Part 1
Security architecture refers to a unified security design that addresses requirements and potential risks involved in a certain scenario or environment. It also specifies when and where to apply security controls.
Traditionally, and to the pain of security and technical teams alike, security tends to be bolted-on to any new solution. Changes, usually “urgent”, require that security controls are placed ad-hoc on a company’s estate, in order to meet the requirements of a particular project. Budget constraints and short timelines are usually quoted as the reason why a more holistic approach can’t be taken that would suit the security needs of the organisation, as a whole, in the long term.
The result of this?
You end up with a mismatch of tools and processes, which are a nightmare to monitor.
Security architecture will be the cornerstone of all subsequent solution implementations, whether cloud or on-prem, so getting it right first time, or as close to right as possible, will make for a more stable, more secure and more manageable estate, where change can happen quickly and with minimum adverse effect to performance and functionality.
Although security architecture will not be the same in every organisation, the factors to consider as input for shaping it, usually are:
Business requirements is an item that is often overlooked, however my golden rule for some time has been “security is there to enable the business”. There is no point in implementing great security controls if they cause the business to fail.
Enterprise architecture is another contributing factor, as a security architecture should align with the overall enterprise architecture. In most organisations, one would more than likely be in place, but potentially undocumented. It may be challenging to have something in writing if the organisation is not known for its good documentation, but it is imperative that you get that.
Both the business requirements and the technology architecture are items for which you’ll need to liaise with other business units, technology and otherwise.
Laws and regulations: GDPR, PCI-DSS, SOX etc. – these can vary widely depending on your country of operation
Standards and certitications: SOC2, ISO, NIST
Alignment with ISMS: Ideally your ISMS framework is implemented in a way that aligns with your chosen standard (e.g. ISO 27001). If not, it’s time you review and update your ISMS. At the end of the day, your ISMS is the FULL SET of policies, standards, and technical and physical controls that protect the CIA of your company’s information.
A lot of these will dictate your chosen security architecture framework: SABSA, TOGAF, Zachman, DoDAF (DOD architecture framework). That is if you go for one. Though open frameworks are considered “tried and tested”, what they do is they provide a guideline for planning and designing your security architecture. It does not necessarily mean you need to follow one in order for your architecture to be successful, and all-encompassing. Exposure to various security disciplines, a good head on your shoulders, genuine interest in security and hours spent on research, will probably have the same effect.