Enterprise architecture and cybersecurity are closely related and interdependent. Cybersecurity is a critical aspect of enterprise architecture as it involves protecting an organisation’s information and technology assets from unauthorised access, theft, or damage. An effective enterprise architecture that includes cybersecurity considerations can help ensure the security, confidentiality, and integrity of an organisation’s information and technology assets.
Some ways that enterprise architecture is impacted by cybersecurity include:
- Risk assessment: An enterprise architecture must include a risk assessment to identify potential threats and vulnerabilities to an organisation’s information and technology assets. Cybersecurity threats must be considered during this process to ensure that appropriate controls are in place to mitigate these risks.
- Security controls: Enterprise architecture should include the implementation of security controls to protect an organisation’s information and technology assets from cybersecurity threats. These controls may include access controls, firewalls, intrusion detection and prevention systems, and encryption.
- Compliance: Enterprise architecture must comply with relevant cybersecurity regulations, such as the General Data Protection Regulation (GDPR), the Health Insurance Portability and Accountability Act (HIPAA), or the Payment Card Industry Data Security Standard (PCI DSS). Compliance with these regulations may require specific security controls or security practices.
- Incident response: An enterprise architecture must include an incident response plan to address cybersecurity incidents that may occur. This plan should define roles and responsibilities, procedures for reporting and investigating incidents, and steps to contain and remediate incidents.
Overall, an effective enterprise architecture must include cybersecurity considerations to protect an organisation’s information and technology assets from cybersecurity threats. The enterprise architecture should be designed to provide a secure, resilient, and reliable foundation for an organisation’s operations, and cybersecurity is a critical component of this foundation.
In all EA projects, a security architect must have a toolbox setup during the preliminary phase (TOGAF ADM) to assess the client’s assets so that a clear, suitable and realistic security level can be applied to them.
Without a repeatable and transparent Asset Security Classification Method and model, the architect has absolutely no idea what protection level should be applied to the assets that will be impacted by the core scope of the EA project. The same goes for the assets evaluated during soft scope assessment, that could be impacted by the EA project delivery. Generally, the business architect will have mapped the relevant assets somehow through the information and capability mapping, which inform the EA team about the necessary critical information and target required to achieve the value proposition for the client.
This exercise that must be often repeated at regular internal to stay complete and correct is not trivial and a process needs to be part of the EA team Architecture Governance framework to ensure all partaking parties are properly trained to use it. The WBISCT ASCM©* contains such straightforward processes that enable the EA team (not just the SecArch). In a step by step sequence of assessments and best practices, governed by a clear and precise diagram, the EA team can ask the right questions to the client so that no asset is left unattended and therefore without assessment.
The security asset classification once established in TOGAF’s Phase A, generally, allows the team to correctly evaluate the risks and most achievable approach to delivery the intended target. Such process must be easy and fast enough to follow so as not to necessarily delay the decision to proceed with the EA project branding and endorsement by the EA sponsoring authority.
There will be times when the EA capability will deem itself (via the EA governance role) not suited to undertake such a project because the security preparedness is simply not mature enough for the risk to be mitigated to a residual level acceptable by the EA sponsor, for instance. A decision must then be made whether the EA team “shop setup” should be reviewed to increase its capability (not to be confused with its capacity) to undertake such a project. This is when a request for re-architecture change will be placed upon the team by the sponsor, to reform or transform itself to be able to accept such project in the future.
When a project falls within the scope of the EA team Request for Architecture contract, then the SecArch will have the responsibility to ensure that all EA team members, Solution resources and PMO are aware of the specific security requirements for the project to be deemed safe enough and therefore successfully accepted by the client, before, during and after its implementation as planned during the migration planning phase… Note that it is each architect and specialist’s responsibility to ensure that their part of the design or proposed solution is secure enough by referring to the architecture requirement specifications (ARS) artefact that must clearly show what security aspect is mandatory, wished for or to be mindful of (MoSCoW method and waiting room concept). Any issue with this process would most likely lead to a “No Go” flag raised by the EA role and a review would then have to take place via a Business Scenario first then if needed an escalation to the sponsor and client to assess the validity of the solution, design or entire EA project.
In essence, the success of a security requirements aspects of an EA project will greatly depend upon the security integration of both artefacts and processes chosen or recommended by the SecArch to adopt, and their understanding and acceptance by the EA team. If those are not clear or followed properly, then the EA project will experience greater risks of time-wasting reiterations, scope and cost creep, misunderstandings during design and implementation hand-overs or simply to be abandoned by the client because of risk appetite mismatch.
All those concepts and processes are clearly explained during our architecture (5 courses to choose from), SIRF and Securing EA projects courses. All those WBISCT delivered courses have hands on, real life practical components that will ensure your full understanding and correct implementation in your projects.
* The WBISCT ASCM© is defined in details in the SIRF and the Securing EA projects courses.