InfoSec EA Strategy Draft March 2015 Danny Ilic

Security Enterprise Architecture

Organise the Architecture Effort by Considering Key Inputs The Architectural Effort is Organised by considering the following as input Business Requirements/Objectives, as documented and approved Environmental Trends Legislation ICT Strategy Emerging opportunities New innovations Risk Threat landscape COBIT Control objective OSCARS Policy Board Policy Implementation procedures ISO Policy Technology Reference Model (as is)

Organise the Architecture Effort sample It is important to formally organise the effort by giving consideration to those things that will have an influence on the architecture. These influences we must consider as input into the architecture that it can be explained outside of the architecture that it is justifiable in the real world Architecture is a plan for the future, so the architecture must understand what it needs to enable, support or deliver in the future. To understand what the future may look like for CLIENT, a few important things must be considered.

Organise the Architecture Effort sample Business Strategy, intent and requirements: Security architecture must be there to support the business, where it sees itself in a year, three years, or five years from now. The shorter the time frame, the more detailed the architecture needs to be. This is important for two reasons: firstly the architecture is usable in the organisation secondly that the architecture would have the support of the organisation Much or the analysis for this has been done in the “EA Business Principles 2009” This document must be considered, each point analysed to understand what business could expect of Security Architecture.

Organise the Architecture Effort sample Environmental Trends: Security is influenced a great deal by environmental aspects, (some of which can be found in the CLIENT ICT Strategy) which can be described by: Legislation within the financial services sector; regulations coming through the union and even from foreign states, such as Sarbanes Oxley. Events in the public eye, such as the losses of personal information, that have ever increasing press coverage Emerging business opportunities New innovations such as Cloud or Mobile computing

Organise the Architecture Effort sample Operational Risk gives great insight into the weaknesses of the current or as-is architecture. Consider the threat landscape and residual risk CLIENT have a mature discipline, draw on OSCARS, COBIT If a risk is accepted then we do not worry about it in Architecture If the risk needs to be mitigated it must be considered. By way of example two scenarios manifest: Numerous risks of a similar nature may exist, e.g. such as those risks we are seeing with Identity & Access Management. In this scenario a strategic architectural solution must be sought for the short to medium term. One or a handful of similar risks may exist together with environmental trends (as discussed above) driving interest, then a strategic architectural solution must be sought for the medium to long term e.g. emerging risks such as an individual has cracked a particular encryption algorithm, somewhere in the world.

Organise the Architecture Effort sample Policy: In every organisation, to function in an organised state rules exist. These rules are formalised through policy and have a direct impact on Information Security Need to be articulated in architecture so that solutions are compliant to these rules. In CLIENT there are three categories of policies that we want to review as input to this architecture: Board Policy, Implementation Procedures, ISO Policy.

Organise the Architecture Effort sample Technology Reference Architecture: This is the as is architecture as defined in the physical layer of this architecture

Security Architecture Framework The Framework is a layered architecture model that allows for different levels of detail, at each level it is usable, comprising of: Contextual Architecture Conceptual Architecture Logical Architecture Physical Architecture Each of the architecture layers is considered from three different views: Business View Information View Technology View

Security Architecture Framework Process Driven Security Architecture The thread is important to follow Defined from top to bottom and from left to right Establish the “Viewpoint” Start

Security Architecture Framework Security Architecture framework as is a Process Driven Security Services Framework The Architecture is lead by business process and is designed to support the business through services and SLA’s Information Security is a business imperative and not a technology “thing” Technology is the enabler and makes life easier When things go wrong manual business procedures keep the information flowing Through people, processes and technology, protect information based on risk In the Architecture we consider three pillars, these being: Business – which looks at architecture as a process, the tasks of people Information – which looks at the value or importance of information, ensure that information is more accessible without compromising integrity Technology – which looks at security mechanisms and objects to enable the business processes, only where technology creates efficiencies. The architecture is layered allowing for representation or views of an effective plan for information security It means that the architecture becomes usable at any level in any state of maturity This allows for a reduction in time for effectiveness, giving the architects the ability to focus efforts on those architecture functions that will need to be implemented in the short term.

Security Architecture Framework

Contextual Architecture This Architecture describes the business context of Information Security, through: Common Requirements (What) Security Vision (Where) Goals (Why) Objectives (How) Governance (Whom) Business Time Lines (When)

Contextual Architecture This Architecture describes the business context of Information Security This layer of the architecture is specifically designed to drive security as a function of business This architecture must relate to business people Some important rules when documenting this architecture layer: Ideally a business sponsor for security architecture must be identified and take an active role in evangelising this architecture. No acronyms, at all, use business language in writing the architecture. All descriptions, points and ideas documented must relate back to a function of business. Limit the number of themes within this architecture layer; preferably keep it down to three. Extend the themes, but keep it simple, do not over document at this level. Use pictures if possible, but nothing technical.

Contextual Architecture – Common Requirements Must be defined from the business Answer for the business “what is security architecture going to plan” Gather information from the business as to what they are intending to do in the future Interpreted into specific architecture requirements Do not regurgitate what business says, interpret it! Once all the requirements are documented then organised them into logical groupings, then rewrite as one requirement. Frome these organised requirements, group further to create themes Ideally you want seven themes. The three most important themes need to be highlighted as the core message to senior and executive management.

Contextual Architecture – Vision A Vision statement outlines what the organization wants to be, or how it wants the world in which it operates to be It concentrates on the future It is a source of inspiration It provides clear decision-making criteria The question you need to be answering in the minds of business is “where will security architecture take us” The security vision is a statement; it is not more than one paragraph. It is the one primary thing that supports the themes identified in the previous section An advantage of having a vision statement is that it creates value for those who get exposed to the it

Contextual Architecture – Vision A Vision statement defines the purpose for being in existence A Vision should describe what will be achieved in the wider sphere if the organization and others are successful in achieving their individual missions Features of an effective vision statement include: Clarity and lack of ambiguity Vivid and clear picture Description of a bright future Memorable and engaging wording Realistic aspirations Alignment with organizational values and culture To become really effective, the security vision statement must (the theory states) become assimilated into the security organisation’s culture...

Contextual Architecture – Goals & Objectives Goals are a series of strategic statements that describe a future state of what must be achieved in time. Objectives are a series of strategic statements that describe how the future state is to be achieved. Goals once documented should give the architecture purpose Take the themes defined in the common requirements section above and describe what needs to be done to achieve each of the themes Tip: start each goal with the word – will. The goals should be a list of bullet points, short but descriptive. The goals must be described in the future tense. Take the themes defined in the common requirements section above and describe how each of the themes will be achieved Tip: start each objective with the words – to or by. The objectives should be a list of bullet points, short but descriptive. The objectives must describe the journey.

Contextual Architecture – Governance In this section, who is responsible for what in security, must described Place information security on the board’s agenda Identify information security leaders, hold them accountable and ensure support for them Ensure the effectiveness of the corporation’s information security policy through review and approval Assign information security to a key committee and ensure adequate support for that committee Identify the functions for Information Security Define the security organisation structure, from the top down Make sure that every function that is involved in security is described Document clear roles and responsibilities for each function It is most important for each functional head to accept their roles and their responsibilities.

Contextual Architecture – Business Time Line The business time line must describe at a high level when architecture events are to be realised In the minds of business the answer to “when” their business objectives will be supported, must be answered In defining the business timelines focus on the goals and objectives as described above, create three timelines: Short term, the next 12 months: in detail what of the goals and objectives need to be achieved and when. Medium term, the second and third years: high-level descriptors what goals and objectives need to be achieved and when. Long term, the fourth and fifth years: concept descriptors what goals and objectives need to be achieved and when.

Conceptual Architecture This Architecture describes the concepts planned for Information Security, through: Services Framework Control Objectives (How to mitigate Risk) Business: Maturity Model (Measuring Progress) Process Inventory (List of Critical Processes) Information: Requirements Classification (Effect on Architecture) Domain Models (Impact on Domains) Technology Trust level Definitions Conceptual Technology Models

Conceptual Architecture The Conceptual Architecture describes the concepts planned Designed to articulate the concepts derived from the contextual architecture A concept is an abstract idea, a corresponding representation that is written or explained in an image The conceptual architecture is not a detailed plan Articulated from the themes as identified in the Contextual Architecture Only what is planned for the next three years must be discussed in this section

Conceptual Architecture – Services Architecture The security services framework is an assembling or collection of security processes, technologies and even personnel In practice this framework must be able to describe the collection of things that CLIENT want to do, in order to operationally secure its information assets These services are things that are to be planned and derived from the contextual architecture Some typical services: Identity and access management Data storage security Network security Cryptography Malicious code Audit and reporting

Conceptual Architecture – Services Architecture Caution: These services are not and should not be derived from a typical list, services must reflect the desires of the business Depending on what CLIENT is trying to achieve will determine how these services need to be structured. For each service that is named, it must have at least: A description of the service A diagram that explains the service as a concept (high level) [see example 1 in attachments] A list of functional mechanisms that would form part of the service A list of processes that need to be defined in the service A list of key people: owner, sponsor, security architecture lead, project or programme manager (if available) Remember these services must only include services for the next three years, and only specific detailed definitions for the next year.

Conceptual Architecture – Services Architecture sample

Conceptual Architecture – Control Objectives CLIENT is at an advantage in that it is a mature user of the COBIT risk framework. SABSA too has the controls defined in depth Regardless of what framework is used, in this section the focus is on those controls that are planned for within the services framework, i.e. whatever is planned for in the next 3 year cycle. The purpose of this section is to explain to the users of the architecture (designers, implementers and operational managers) the controls that must be focused on Copy and paste those controls that are relevant, review, correct and reference the relevant service

Conceptual Architecture – Maturity Model The business focus of conceptual security architecture is to describe those things that are important to business Architecture in an evolving and pliable plan that is in constant change as the plan moves in to production and the “to be” becomes the “as is.” A maturity modelling tool is a powerful instrument to measure and manage progress from where CLIENT is to where CLIENT wants to be Rather than reinventing and creating a new model, Gartner recommends the use of an existing maturity model

Conceptual Architecture – Maturity Model sample

Conceptual Architecture – Maturity Model sample

Conceptual Architecture – Process Inventory The business focus of conceptual security architecture is to describe those things that are important to business The process invent is a list of processes that are important to business Consider each of the security services and control objectives Identify what processes would be required to enable the service or control List the processes by name, with a short description of the process

Conceptual Architecture – Information Requirements The information focus is to describe those things that are important to information protection “Information Classification & Ownership Implementation Procedure” input in this section Identify and document specific requirements associated with the security services and control objectives Reference the requirements to the Standards Appendix tables in the CLIENT “Information Classification & Ownership Implementation Procedure,” found on pages 19 through 23

Conceptual Architecture – Information Classification The information focus is to describe those things that are important to information protection “Information Classification & Ownership Implementation Procedure” input in this section Information Classification is well documented in CLIENT in the “Information Classification & Ownership Implementation Procedure,” Document the effects of the requirements, reference the effects to the information requirements

Conceptual Architecture – Domain Models The information focus is to describe those things that are important to information protection “Information Classification & Ownership Implementation Procedure” input in this section Domain models, a conceptual model of a system, describes entities and their relationships Created in order to document the key concepts Identifies the relationships among all major entities within the system Identifies important methods and attributes

Conceptual Architecture – Domain Models The domain model provides a structural view of the system A collection of business processes, people and technology that protect a logical environment Based on the Business Impact Level (BIL) Those areas (where) described that contain information up to a specific security level Examples could include such things as The Internet, Back Office, Front Office, Customer, etc. Describes and constrains the system scope

Conceptual Architecture – Domain Models Effectively used to validate the understanding of security among various stakeholders Communication tool and a focusing point between technical and business teams Describe with the services and control objectives Consider the specific impact within each domain around the information classification level applied Document the connection rules between domains

Conceptual Architecture – Trust Level Definitions The technology focus is to describe those things that are important to IT Trust level enables different levels of security In defining the trust levels the domain models, services and control objectives need to be considered Conceivable that there are more trust levels than domains Trust levels are defined to be enabled by technology

Conceptual Architecture – Trust Level Definitions Defined based on entity relationships The hierarchy described numerically or through words Where a high level of trust is in place then a low level of control is required Define the conditions of trust, such as internal relationship or agreements in place Define the technology controls required to secure the relationship between different trust levels

Conceptual Architecture – Trust Level Definitions Example, Refer: Gartner for IT Leaders Tool Sample — Enterprise Information Security Architecture Trust Model

Conceptual Architecture – Technology Models The technology focus is to describe those things that are important to IT Defined by a decomposition of the service into components, responsibilities and interconnections Intent is to direct attention at an appropriate decomposition of the system - not detailed Vehicle for communicating the architecture to non-technical audiences

Conceptual Architecture – Technology Models Describe the technology used to enable or support the security services Describes the security mechanisms and grouping Define visual representation Explain the components in words, what each component is, what the responsibilities of each component are Identify the nature of the connections between the components

Conceptual Architecture – Technology Models sample

Conceptual Architecture – Technology Models sample

Logical Architecture This Architecture describes the logical plan for Information Security, through: Business Security Processes Services Processes Functional Processes Information Information Controls Information Processes SLA Model Technology Trust Model Technical Models

Logical Architecture Describes a level of detail associated with the intent of security, as an organised plan Logic derived from the contextual and conceptual architectures Useful way to think through and refine the responsibilities and interfaces of components Articulated from Contextual and Conceptual Architecture as explained in the section above Only what is planned for the next year should be documented in this section.

Logical Architecture – Process Definition Focus is to describe the processes Unlike static objects, business processes are semi-repetitive sequences of events Events are often widely distributed in time and space, with ambiguous boundaries Describing a business process requires an approach that is sensitive to these aspects Business Processes exist in various levels Processes must be designed consistently, as a series of business process diagrams with supporting information on each task

Logical Architecture – Process Definition There are five principles in Process Engineering: Flexibility, the complexity of problem situations in business means it is necessary to offer dynamic process formulation Joint teaming, change can be facilitated, but not delivered, by architecture Work toward strategic objectives, any improvement project must depart from the strategic objectives as described above Knowledge management and transfer, knowledge must be transferred, maintained and developed Delivering value, results of change must be linked to business success, defined by measurable outcomes Detailed processes and supporting organisational structure need to be in place Referencing each task to the function of architecture is important

Logical Architecture – Process Definition Security Processes Specific business processes supporting the conceptual security models need to be documented Services Processes The operational business processes that would support the administrators and support staff, it is recommended that the ITIL Security Management framework be used Functional Processes Non-technical, used to describe the process that handles information exchange between logical components Model real life business objects Prescribes how business objects interact with one another Enforces the routes and the methods by which business objects are accessed and updated

Logical Architecture – Process Definition Example, Refer: Security Process Tool Kit

Logical Architecture – Information Controls The information focus is to describe those things that are important in relation to how information must be managed Based on the domain models Best described in reference architecture Proven solution for extending on domains Provides a common vocabulary with which to discuss implementations

Logical Architecture – Information Controls Take the domain models and the control objectives List the controls required for each of the domain models Describe the function of each control in relation to the domain Describe the interfaces and or interaction between the controls These controls are handed over to the technical design teams for inclusion in projects

Logical Architecture – Information Controls sample

Logical Architecture – Information Processes The information focus is to describe those things that are important in relation to how information must be managed Describe the information flows within the technical models (as described below) Best described in the form of flow diagrams Consider how information moves from one place to the next Describe how for the particular flows the information is secured The information is given to the implementation teams to design the data models

Logical Architecture – Information Processes

Logical Architecture – Information Processes

Logical Architecture – SLA Models The information focus is to describe those things that are important in relation to how information must be managed Derived to establish SLA’s - base on ITIL Security Management. Modelling is an approach that can be used to express information in a structure, defined by rules. For every process, identify the rules that govern the tasks Consider the information or data that is protected Identify rules that can be linked to key performance Indicators Example is: within a process task, the classification of that information could require high availability; KPI will be Availability; the rule would therefore be: system must have 98% availability 24by7by365. This information is handed off to the operational team

Logical Architecture – Trust Models The technology focus is to describe those things that are important to IT Developed to establish guiding principles for the effective implementation of technology Modelling is an approach that can be used to express systems in a structure that is defined rules. Used for the interpretation of meaning of domain models and trust definitions

Logical Architecture – Trust Models For every technology Trust definition and domain model, defined in the conceptual architecture: Identify the list of rules that govern the component Rules must consider the technology objects that would support the component Identify rules that can be linked to KPI’s Example: with a component describing Web Access Management, KPI could be 100% of web applications; the rule would be: all web-based applications must use the Web Access Management technology of choice. This information must be given to the development and implementation

Logical Architecture – Technical Models The technology focus is to describe those things that are important to IT Defined by a decomposition of the conceptual models into technical diagrams and the responsibilities of each technology object Integrations between technology objects identified and defined a layered interface model The following are the most common layers when designing a software build: User Interface Layer Application Layer Business or Domain Layer Infrastructure Layer

Logical Architecture – Technical Models The intent of the logical architecture model is to build the system without delving into the details of technical config. It provides a useful vehicle translating the architecture for the technology implementation teams Must describe the technical interfaces, decomposed into the build layers Describes the security objects and how the objects are grouped to support the security concepts and services Define the logical architecture models in a diagram Explain the object and layers in words, what each object is, what the responsibilities of each object are Identify the nature of the connections between the objects and layers, where applicable

Logical Architecture – Technical Models sample

Logical Architecture – Technical Models sample

Physical Architecture This Architecture is the physical environment as owned and managed by engineering and operational team's Business Organisational Design Information Security Information Design Information Classification Register Technology As-is Technology Reference Model

The CLIENT Security Architecture Model The Architecture Model is a Process Driven Security Services Framework The Architecture is Layered allowing for representation or views for: Business Information Technology

Information Security Architecture Change Through Project Life Cycle Impact on projects influenced and driven by security architecture Opportunities & Solutions Gap Analysis HLSR Change to Business Applications ISP2 Planning Project Management Change Management Implementation Governance Sec Architecture Representation in sponsorship meeting, IT & RPC Architecture Change Management Change Recorded in the As-is Model Impact of Change considered as input for review of architecture Architecture Change Management Implementation Governance Change to Business Applications Opportunities and Solutions

Relationship Between Information Security & Security Architecture Board Policy Supersedes ISO Policy and Implementation Procedures all of which are inputs to an effective Information Security Architecture As a result of the Security Architecture, considered an output, are the Generic Standards and the Technical Standards

Architecture time lines sample

Danny Ilic Principal Consultant dejan.ilic@wipro.com