As security architects, we are always challenged with relating business problems, threats, and agile IT to build security without hampering user experience and at the same time secure the crown jewels from lurking cybercriminals.

Every CISO might dream of “to have a single screen which tells you how your organization current security posture looks like, which are the risk associated with business-critical assets, which are the security incidents identified, what is the impact of these incidents, what are the priorities for these incidents and what is the current status of these incidents. How the security posture has improved over time and how the lessons learned are getting incorporated into policies and processes to improve the efficiency of security staff”. These inputs will make CISO’s life less stressful and CISO will have answers to most of the tough questions he needs to answer related to cybersecurity investments.

Most of these things can be achieved, if you build a Security Operation Centre (SOC) by following the architecture methodology which provides the guidance and tools to manage the entire life cycle of your SOC, this SOC is either owned by your organization or used by Managed Security Service Providers (MSSP), you need to have right architecting tools.

When it comes to Security Architecture, there are two architecture methodology normally considered one is SABSA (Sherwood Applied Business Security Architecture), and another more popular as enterprise architecture development i.e. TOGAF (The Open Group Architecture Framework). I prefer SABSA while capturing the business context, business requirements, and answering questions like what needs to be done and what impacts it will have if not done and how it will be done. When it comes to develop and manage SOC architecture I prefer to use the TOGAF Architecture Development Methodology (ADM). The advantage is it gets easily integrated with overall enterprise architecture (SABSA has provided integration with TOGAF) and readily accepted by the enterprise architect teams.

In this article, we will discuss each of the TOGAF ADM phases with respect to the SOC architecture point of view.

Why TOGAF Architecture Development Method?

Enterprise Architecture and Security Architecture is all about aligning business systems and supporting information systems to realize business objectives in an effective and efficient manner. The architecture includes processes, people, technology, and in case of security policies aligned with compliance requirements. Many times, cybersecurity is considered a separate discipline and gets isolated from the business processes and Enterprise Architecture.

A Security Architecture is both a driver and enabler of secure, safe, resilient, and reliable behavior, as well as addressing risk areas throughout the enterprise. However, Security Architecture does not exist in isolation. As part of the enterprise, it builds on enterprise information that is already available in the Enterprise Architecture, and it produces information that influences the Enterprise Architecture. This is why a close integration of Security Architecture in the Enterprise Architecture is beneficial. In the end, doing it right the first time saves costs and increases effectiveness compared to bolting on security afterward. To achieve this, Security Architects and Enterprise Architects need to speak the same language.

The following diagram depicts TOGAF ADM, which captures information required to gather the business requirements, develop solution and project plans, manage projects, operational requirements that need to be part of the architecture.

TOGAF ADM to Design the SOC Architecture

It is important to understand the business plans and vision before building the SOC as the SOC architecture, technology and process can accommodate future business changes without impacting the existing architecture and in line with the organization’s Enterprise Architecture.

TOGAF based SOC architecture development framework is very useful to identify business requirements, regulatory compliance requirements, organization’s enterprise architecture (IT Infrastructure, technology, and Applications), and current security architecture and policies. This approach helps to develop SOC architecture in line with business-specific requirements and customer-specific IT risk vectors. This also helps with defining the areas which are most important to reduce the risks and improve security posture.

The following diagram depicts the Phases and activities conducted during SOC Architecture development and maintenance.

Preliminary Phase: This phase is important to define the Mission statement and Vision for SOC. This Vision should be in line with the organization’s business vision to accommodate future security requirements. It is also important to know geographical locations need to be covered as a part of SOC scope to define the regulatory, land of law requirements. Activities that need to be performed as a part of this phase should make sure to get executive management support and sponsorship for the SOC build project. The architect team needs to understand the Organization’s structure and identify the stakeholders whose support is important for making the SOC building project successful.

Phase A – Architecture Vision: This phase is important in terms of defining the SOC architecture vision and road map in line with risk priorities identified as a part of risk assessment and business impact analysis results and regulatory requirements, policy compliance requirements. In this phase, Industry-specific emerging threats data need to be captured. This phase defines the foundation on which the SOC architecture will be built. Also, the architect team needs to identify and define necessary SOC build related management sign-off and milestones.

“A man who does not plan long ahead will find trouble at his door.” ― Confucius, Chinese philosopher

Phase B – Business Architecture: In this phase, the availability and business continuity requirements for the SOC architecture components are identified. The industry and organization-specific use cases for Security monitoring are defined. At the time of defining these use cases, the risk appetite and security posture of the organization need to be taken into consideration. The Security policies are analyzed for the validity and applicability current and future state of business and need to be taken as an input for defining the next architecture definition phases. The applicable best practices and guidelines are identified and will be used in the next phases.

Phase C – Information Systems Architecture: The existing applications, platforms that need to be integrated with SOC are identified in this phase. The use cases defined in the above phase are applied to these applications and platforms and assessment will be performed for the requirements for execution/integration of those use cases. Analysis of the modification customization requirements needs to be identified. The requirements list for modification/customization is prepared.

Phase D – Technology and Process Architecture: In this phase, the SOC technology framework is defined. To identify which technology components need to be added, an assessment of existing tools and technology needs to be performed, this may include the security controls, service management tools, performance monitoring, and management tools, etc. The feasibility of the modifications/customizations identified in the above phase will be performed along with asset/application owners and the application management team. The output of this assessment needs to be incorporated in defining the road map for implementation.

The new tools and technologies that are identified, are included in requirements specification documents (including features, capacity, performance, etc.).

In this phase perform the analysis of processes followed for security incident management, risk assessment, operation management, etc., and identify the gaps. These gaps need to be included as a part of Phase F mitigation planning

The inputs for the inflight project need to be considered while identifying the opportunities and new/additional tools deployment requirements.

Phase E – Opportunities & Solutions: Cybersecurity Architect needs to work with existing teams who are performing security, IT Infrastructure operations, Applications management to define the projects and prioritizing the same.

In this phase, the focus is on integrating business requirements, legal and regulatory requirements and risk assessment, and business impact analysis results to prioritize the projects.

At the end of this phase, the project definitions with technical priorities are identified. The technology deployment and process enhancement road map will be the result of this phase

Requirements Management: While executing all the above phases, capture the requirements from the business, regulatory, legal, technology, processes, audits, etc., Track of all these requirements and mapping with the execution phase with a particular requirement to be addressed, will be documented. This helps to make sure that all the requirements are addressed during the architecture development and project execution.

Phase F – Migration Planning: The PMO office need to be set up as a part of this phase. Also, the architect team needs to identify the impact of deploying SOC technology components in the existing DC and DR environment. The prerequisites are identified and conveyed to the respective stakeholders in the organization. The changes that need to be done for integration with service management, availability, and performance management tools will be discussed and conveyed to the respective stakeholders in the organization. The secure connectivity requirements for SOC operations to identified IT Operation center are identified and validated with current connectivity.  

The processes, service desk, and other operational requirements also need to be identified. The plan for making these things available to the operations team will be defined.

SOC tools deployment project plan will be developed as a part of this phase. The resource required for the deployment needs to be identified.

Phase G: Implementation Governance: The actual deployment needs to be done by the identified project team. The security architect team provides governance support for these deployment projects. 

The security architect validates tools implementation methods and procedures to make sure that tools are getting deployed and configured as per the architecture artifacts. The security architect will also confirm that the required details for service delivery and maintenance are captured and deposited in the architecture repository.

Phase H: Architecture Change Management: The threat environment, technological developments, digital transformation, and maintenance or increasing the customer’s satisfaction leads to business application changes e.g. going for SaaS instead of hosted applications and well IT infrastructure changes like migration to cloud. The regulatory requirements for data protection and privacy are getting more and more stringent. To keep up with this the SOC architecture needs to assess the coverage of the new environment for security perspective and effectiveness of the existing tools and technologies to comply with the organization’s security policies and applicable regulatory requirements.

Apart this from the changes in security policies, changing regulatory compliance requirements organization needs to make changes in their security configurations, tools, etc. These changes need to be assessed for the impact on the entire infrastructure, the risk to be assessed. These activities are part of SOC architecture validation on regular basis.

Any major changes in the business environment and/IT infrastructure invokes the entire SOC architecture assessment and validation.

Conclusion

Let us conclude this article with quote from former US president,

“You can always amend a big plan, but you can never expand a little one. I don’t believe in little plans. I believe in plans big enough to meet a situation which we can’t possibly foresee now.” ― Harry S. Truman, former U.S. President

TOGAF gives cybersecurity architects the methodology, tools, and guidance to look into future plans of business and develop the security architecture that covers the big picture but also means to keep it up to date as the business requirements change in the future.