The LEADing Practice Enterprise Security Standards

Transcription

1 The LEADing Practice Enterprise Standards Integrating Architecture and Enterprise Architecture Presenter: James Thomas LEAD Enterprise Architect at Knotion

2 Copyright note on Intellectual Capital: ALL RIGHTS RESERVED LEADing Practice ApS respects the intellectual property of others, and we ask others to do the same. All information and materials contained in the LEAD frameworks, methods and approaches with associated tools and templates, such as maps, matrices and models is Intellectual Capital (IC) and Intellectual Property (IP) of LEADing Practice ApS and limitations apply to the reuse of this IC/IP. The intellectual Property Rights (IPR) consists of information, knowledge, objects, artifacts, experience, insight and/or ideas, that are structured to enable reuse to deliver value creation and realization. The LEADing Practice ApS, often referred to as LEAD, intellectual capital is protected by law, including, but not limited to, internationally recognized United States and European Union IPR copyright law. Except as specifically indicated otherwise in writing, LEADing Practice ApS is the owner of the copyright in the entire LEAD Frameworks content (including images, text and look and feel attributes) and LEADing Practice ApS reserves all rights in that regard. Use or misuse of the IPR, the trademarks, service mark or logos is expressly prohibited and may violate country, federal and state law. LEADing Practice ApS is an open architecture and community open source standard and therefore provides open access to all deliverables for certified LEAD practitioners, thereby ensuring that modelling principles are applied correctly. A open architecture and open standard community has been set in place to encourage sharing, learning and reuse of information and thereby increase knowledge among LEAD community practitioners, and with this ultimately improvement of one s project, engagement and the LEAD development. Use of the LEAD frameworks, methods and approaches is restricted to certified LEAD community members in good practitioner standing, who are able to use these items solely for their non-commercial internal use. Legal access to the detail of LEAD will be provided to you with your membership. Members are prohibited from sharing the LEAD material in its entirety with other parties who are not members of LEAD community since the concepts and models are protected by intellectual property rights. Guidelines for LEAD community members using the IPR material As a LEAD member comes greater personal responsibility and the following intellectual property conditions apply: Can be used free of charge for LEAD certified practitioners. Cannot be share, copied or made available for non-community member, which are not LEAD certified practitioners. When using any materials, it must include a source notice either in an adjacent area or as a footnote to indicate the source. The source should be specified the following way : Source: A part of the LEAD Frameworks and possibly indicate the LEAD work product family, such as Part of LEAD Process Framework. Cannot be systematically given away do not download all our content and simply hand it over to other colleagues or clients that are not trained and certified. To ensure correct usage, any company usage of the LEAD material e.g. templates and tools has to be tailored and agreed upon by LEADing Practice ApS. LEADing Practice ApS may, in appropriate circumstances and at its discretion, terminate the access/accounts of users who infringe the intellectual property rights and pursue legal action. Guidelines for non-lead community members using the IPR material The following conditions apply to use of the LEAD Intellectual Property for non-community members: Can be used free of charge for lecturing and research at any University and Business School Material available at can be used in a non-commercial way for knowledge sharing. When using any materials, it must include a source should be specified the following way : Source: A part of the LEAD Frameworks and possibly indicate the LEAD work product family, such as Part of LEAD Process Framework. General guidelines that apply for all LEAD IPR material Any use of original texts, graphics, images, screen shots, and other materials from LEAD sources must be approved by LEADing Practice ApS. Any material cannot be generally distributed to colleagues, clients and or an undefined audience without written permission from LEADing Practice ApS. Cannot be altered or changed (the using company) in any way without explicit written permission from LEADing Practice ApS. In most cases, the LEADing Practice ApS acts as a distribution channel for the Publisher and Authors of the material provided. LEADing Practice ApS may, in appropriate circumstances of infringement of the intellectual property rights pursue legal action. For questions, please get in touch with us at [email protected].

3 Agenda Situation: is more critical than ever Complications: Focus areas and many options We need a holistic architecture methodology Integrating and Enterprise Architecture Applying LEADing Practices Reference Content Lessons Learned or Pitfalls Conclusion: Takeaways

4 Situation is becoming more critical than ever The number of exposures and high profile breaches are increasing Attacks are more sophisticated New opportunities bring new threats and vulnerabilities mobile, social, cloud, etc.. Many links in the chain are increasing the risk of a breach information supply chains

5 Analyze/Identify Existing Strategies Business Innovation & Transformation Enablement

6 is top concern in 2014 for state CIOs "It is significant that security has now risen to the number one priority on our top 10 list. As I presented in congressional testimony before the Committee on Homeland last week, cyber-attacks against state governments are growing in number and becoming increasingly sophisticated. has to be the top priority for all sectors. Clearly from our top 10 voting results, the state CIOs agree on this. - NASCIO President and Mississippi Chief Information Officer, Craig Orgeron In ranked order, the top 10 priorities for strategy, management processes and solutions are: Consolidation / Optimization Cloud services Project and portfolio management Strategic IT planning Budget and cost control Mobile services / mobility Shared services Interoperable nationwide public safety broadband network (FirstNet) Healthcare is top concern in 2014 for state CIOs - FierceCIO National Association of State Chief Information Officers, November 5, 2013

7 CIO Barometer CSC Nearly three-quarters of respondents said that more-effective management of IT security and cybersecurity is a priority for their 2014 IT budgets. When asked to identify the IT department s main contributions, more than 60 percent cited securing the business. And when it comes to major challenges facing their IT departments, nearly 80 percent cited the management of expanding IT security, making it their top challenge. As the world continues to revolve on a digital axis, IT security becomes more and more critical. Last year alone (2012), there were more than 2,500 separate incidents, exposing more than 250 million records. Copyright 2013 Computer Sciences Corporation - The CIO s New Role: Core Strategy Enabler, CIO Barometer 2013 Private and semi-public companies and public institutions with a minimum of 500 employees 681 managers were interviewed on five continents and in 18 countries. These managers represent the following target positions: CIO; IT director; IT manager

8 Data Breach Trends Data Breach QuickView - An Executive s Guide to 2013: Data Breach Trends Sponsored by: Risk Based ; Open Foundation February 2014

9 Cyberrisk in banking: A review of the key industry threats and responses ahead September 2013 Both technologies and threats are evolving Mobile devices and applications are primary examples of the balance between greater efficiency and new kinds of cyberrisks Awareness remains low 30% rate limited customer awareness as a key challenge Preparedness for cyberrisks remains patchy Less than one in four banks believe their internal resources are highly prepared Trust trumps financial losses Banks are only spending just enough on cybersecurity to make customers trust them A lack of cooperation is hindering progress Because many banks are typically only financially liable when their own systems are compromised, there is little incentive for them to cooperate with other stakeholders when it comes to cybersecurity. Response strategies are evolving A shift in thinking: from trying to prevent all risks, to instead trying to identify key weaknesses The quantitative findings presented in this report come from a survey of 250 respondents in financial services, with 55 percent in retail banking and 45 percent in commercial banking, conducted by Longitude Research September 2013.

10 Complication Many initiatives working on improving the Enterprise Risk and Information landscape The market is already flooded with too many checklists has traditionally been the realm of Techies Enterprise Risk Management is being driven from a business perspective, while IT is still tool -focused Where to start with so many options?

11 So many options... Calder-Moir IT Governance Framework CobiT King III ISC2 BoK (CISSP) IT-Grundschutz STIGs (US Govt Guidelines) TickIT (Software Development) FIPS200 SSE-CMM O-ISM3 SABSA OSA FEAF FAIR COSO GAIT OCTAVE NIST SP FISMA (FIPS199, FIPS200, SP800-30,37,39,53,53A,60) ISO (ISMS) ISO (Controls) ISO (ISMS Implementation, Processes) ISO (Measures & Measurement) ISO (ISec. Risk Management) ISO ( Techniques) ISO (ISMS Auditing) ISO (ISM Controls Auditing) ISO (Governance of information security) ISF ITIL NIST SP800 (Series) Sarbanes-Oxley (SOX) Basel I, II, III PCI-DSS

12 Need for a holistic methodology IT has to evolve: information TECHNOLOGY INFORMATION technology BUSINESS SECURITY / ENTERPRISE SECURITY Enterprise Risk models are essential can t be an afterthought any more has to be architected-in from the start Identify the most sensitive areas of the business, the most likely threats, and a holistic defence strategy - an architecture of technology and processes - designed specifically to protect the business

13 Architecture to date some examples Enterprise Architecture Frameworks FEAF DoDAF TOGAF Architecture Frameworks Federal Enterprise Architecture and Privacy Profile (FEA-SPP) Open Architecture (OSA) Sherwood Applied Business Architecture (SABSA) Are these attempts sufficient?

14 FEAF

15 DoDAF

16 TOGAF

17 FEA-SPP Framework

18 OSA Taxonomy

19 SABSA Model 19

20 SABSA Operational Risk Model

21 Attempts to Integrate Architecture and Enterprise Architecture

22 TOGAF and SABSA

23 Some Challenges

24 Applying LEADing practices Overview of the LEADing Practice Reference Framework

25 Objective of Reference Framework What is the LEADing Practice Reference Framework? The LEADing Practice Reference Framework is based on a collection of best and leading practice Modelling and Architecture disciplines. The Reference Framework is the essential starting point with guiding principles for any practitioner working with and around aspects. It provides a structural concept around strategic definitions e.g. wants, needs, identification, goals, issues and problems. Therefore the Reference Framework is a basis of reference content to analyze, appraise, approximate, assess and capture a Objects and or artifacts idea, design, plan, scheme and structure in order to understand the underlying concept, thought, view, vision as well as perspective. Why is it used? The purpose of the Reference Framework is to define how to organize and structure the viewpoints and objects associated with Modelling and Architecture. The Reference Framework serves as guiding principles to establish a common practice for creating, interpreting, analyzing and using objects within a particular domain and/or layers of an enterprise or an organization. Using the Reference Framework is done through a set of principles e.g. how and where can the Objects be related (and where not). The Reference Framework can be used with the 6 LEAD methods and 4 LEAD approaches that are all integrated with each other and with supporting maps, matrices and models.

26 Enterprise Modelling and Enterprise Architecture an integrated part of the LEADing Practice Frameworks, Method and Approaches Enterprise Modelling is the abstract representation, description and definition of a structure. It is the discipline of representing and replicating the area that is being modelled to have a simplified representation of the real enterprise business. Then it sculptures and forms and designs/redesigns the specific area that is being modelled to improve its performance. Examples of Enterprise Modelling Service Model renewal Optimization Improvement Business Model Value management Performance management Measurements Rules Modelling Knowledge Management Information Modelling Decision Modelling Reporting Strategy Management Governance Modelling ITIL COBIT BPM Notations Val IT

27 Enterprise Architecture an integrated part of the LEADing Practice Frameworks, Method and Approaches Enterprise Architecture: The organization, administration of conceptual, logical and physical relationships and connectivity of specific objects and artifacts to each other (and the environment) in order to understand complexity and manage structure to enable transformation, performance or value. Example of Enterprise Architecture Business Architecture Architecture Value Architecture Data Architecture Information Architecture Cloud Architecture Solution Architecture Application Architecture Platform Architecture Infrastructure Architecture Technology Architecture Service-Oriented Architecture

28 Identification of common objects within Enterprise Modelling and Enterprise Architecture Strategy Resources Goals Competencies Critical Success Factors (CSFs) Requirements PPIs Business Functions/Tasks Business Services SLA Tasks Events KPIs SPIs Data Components Data Entities Data Service Data Objects Appl. Functions Appl. Feature Application Service Infrastructure Devices Application Components Infrastructure Services Platform Service Platform device Infrastructure Components Platform Components

29 Enterprise Modelling and Enterprise Architecture is an integrated part of the LEADing Practice Frameworks, Methods and Approaches

30 Enterprise Modelling and Enterprise Architecture is an integrated part of the LEADing Practice Reference Framework Rule Engine Compliance Rules Business Rule Goal Logical Design Conceptual Context Complexity Reporting Decision Table Object Connections Physical Execution Decision Table Measurements Business Measurements Optimization Area Groups Steps Activity Artifacts Performance Information Knowledge Management Efficiency Effectiveness

31 Working with Enterprise Modelling and Enterprise Architecture through the LEAD Objects In the LEAD object modelling principles, a LEAD object refers to a specific, specialized object that is used by the Decomposition & Composition principles within the LEADing Practice Frameworks, LEADing Practice Methods and LEADing Practice Approaches. In terms of the LEAD Way of Working within Modelling and Architecture using the LEAD meta objects and the classification* of any of the general LEAD objects, which are categorized** in the following 17 object groups: Requirement & Goal Rules Services Owner Flow Application Platform Media Channel Business Competency Object (categorization) Roles Measurement Data Infrastructure Compliance *Classify = to assemble by order **Categorize = to divide into groups

32 The LEADing Practice Reference Framework Structural Way of Working

33 The Structural Way Through The Layers 33

34 Modelling and Architecture through working with the LEAD Objects The purpose of LEAD Object modelling is to: Decompose the Objects into the smallest parts that can, should and needs to be modelled, and then compose the Objects entities before building them (through mapping, simulation and scenarios). Visualize and clarify Object relationships with the LEAD artifacts by using maps, matrices and models (alternative representation of information). Reduce and/or enhance complexity of Modelling and Architecture principles applying the decomposition and composition method or modelling it through the architectural layers (Layered Architecture Method). Adding Requirements Communicate Value to the customers throughout the entire LifeCycle. Blueprinting and Implementation.

35 The LEADing Practice Reference Framework Decomposition & Composition

36 The LEADing Practice AGILE Concept The LEADing Practice AGILE Concept has been created in order to describe the requirement relationship between the LEAD Way of Thinking, Way of Working and Way of Modelling with both objects and domains within the Business, Application and Technology Layers of the LEADing Practice Reference Frameworks using interrogatives (what, who, why, etc.) and behavior (conceptual, logical, physical, etc.).

37 Some Basics around the Interrogatives used within the LEAD AGILE Concept Interrogative Context Meaning Whence Source Pertaining to source, origin, foundation or cause Who Personal/actor used to identify a particular person or persons involved Why Reason Pertaining to the motivation or reason What Context Pertaining to identity, nature, or value of a object or matter Where Location Location, place or area Whether Options Choosing between alternatives and/or options How Manner Pertaining to manner, method or way When Time Pertaining to time or timing

38

39 The LEAD Way of Thinking around Architecture and Modelling The LEADing Practice Way of Thinking around Architecture and Modelling disciplines, is the essential starting point that creates the guiding principles. Providing a structural concept around strategic definitions e.g. wants, needs, value identification, goals, issues and problems. The way of thinking postulates what ought to be with the right value abstraction level that can analyze, appraise, approximate, assess and capture Objects and/or artifacts idea, design, plan, scheme and structure in order to understand the underlying concept, thought, view, vision as well as perspective, philosophy and belief.

40 Objective of the LEADing Practice Reference Framework - How is it used Relation to Strategy Understand business model security drivers Outline goals Identify performance and value opportunities Capture value and performance expectations and drivers Align value drivers to business strategy Define innovation and transformation Define Transformation potential Develop and formalize change potential Focus Area Analyze business strategy and the relation Identify requirements to security Focus on value issues and Identify internal and external security drivers (competitive forces) weaknesses cluster Develop standards Ensure measurements (across business areas) Apply continuous improvements Ensure strategic reporting and decision flow strategy development Value Based design through the layers Business model linked to Develop competitive and differentiated advantage Business Transformation & Innovation Enablement (BITE) related to security aspects

41 LEADing Practice Maps A LEAD Map is an accurate list and representation of the decomposed and/or composed Objects. A LEAD Map is often in the form of a list that can be in a simple row as well as a catalog, and has the purpose of building an inventory or index list of the Objects that are to be either decomposed and/or composed in the different LEAD Layers (business, application and technology).

42 LEADing Practice Maps: Forces & Drivers (FD) Map Forces & Drivers External Driver/Forces For Why specification: Internal Driver/Forces For Where specification: Business, Service, Role, Technology, etc.

43 LEADing Practice Maps: Requirement (Rq) Map Requirement Who/Whom specification e.g. Stakeholder/Owner Where specification e.g. Layer, Objects, Area (, service, data, infrastructure) etc What specification: High Level Requirements What specification: Detailed Requirements

44 LEADing Practice Maps: Measurement & Reporting (MR) Map What/which specification: Where specification: Who/whom specification: Measuremen t & Reporting Objective (CSF, plan, forecast, budget) Performance Indicator (Strategic/Tactical /Operational) Service Measurements (Service Level Agreements) Process Measurements (PPI) Reporting System Reports

45 LEADing Practice Maps: Information (I) Map Information What/which specification: Object (Business, Information or Data) Data Entity How specification: Data Compliance (Including security) Who/whom specification: Business Owner Reporting

46 LEADing Practice Maps: Rule (Ru) Map Securit y Rule Business Rules Service Tier Service Rules What/which specification: Process Rules Gateways Business Object Information Object How specification: Business Compliance

47 LEADing Practice Maps: Process (P) Map What specification: Who/Whose specification: Process Business Process Area Process Groups Business process Process Steps Process Activities Stakeholder involved Process Owner Managers involved Roles/Resourc es involved

48 LEADing Practice Maps: Process Measurement Map Process Measurement Name Definition Rationale Dimension Application Function/Task

49 LEADing Practice Maps: Process Compliance Map Process Process Compliance Process Rule Process Description Process Rationale

50 LEADing Practice Maps: Service (Se) Map What specification Who/Whose specification Service Service Area Service Group Business Service Service Channel Stakeholder Involved Service Owner Manager Involved Role/Resourc e Involved

51 LEADing Practice Maps: Application (A) Map Component Whence specification: Version number Logical/Physical Component Application Module What/Which specification: Application Function Application Feature Application Task

52 LEADing Practice Maps: Application Service (AS) Map What/Which : What : Where : Who : Whose : Why : Application Service Application Service Service Description Business Service Service Provider Service Consumer Service Owner Service Requirement

53 LEADing Practice Maps: System Measurement & Reporting (AM) Map What/Which specification: Measurement Measurement Name Measurement Definition Rationale Dimension Application Function/System Report

54 LEADing Practice Maps: Application Screen (Asc) Map Screen What/Which specification: Who/Whom specification: Screen Name Screen Description Application Service Application Task Input or Output Application Role

55 LEADing Practice Maps: Application Role (ARo) Map Role Who/Whom specification: What/Which specification: Application Role Role Description Rationale

56 LEADing Practice Maps: Application Rule (AR) Map Rule What/Which specification: Application Rule Rule Description Rationale Nature

57 LEADing Practice Maps: Application Rule (AR) Map Compliance Application Compliance What/Which specification: Application Rule Compliance Description Rationale

58 LEADing Practice Maps: Application Goal & Requirement Map What/Which specification: Who/Whom specification: Goal/Require ment Objective Expectation Requirement, Specification or Assumption Details Business Process Application Component Application Function or Application Service Stakeholder

59 LEADing Practice Maps: Data (D) Map What/which specification: Who is involved: Where is it used: Data Data Component Data Object (information/ data) Data Entity Data Type Data Service Data Owner Data Users Data Channel Channel

60 LEADing Practice Maps: Data Rule (DR) Map What/Which What Where Whose Why Rule Data Rule Data Rule Description Data Compliance Data Rule Owner Data Rule Rationale

61 LEADing Practice Maps: Platform (PL) Map What/Which Who is involved: Where Platfor m Logical/Physical Component Device Function Service Owner Users Channel Media

62 LEADing Practice Maps: Platform Service (PLS) Map What/which Where Whose Who Why Platform Serv Service ice Name Platform Service Business Descripti Service on Applicati on Service Applicati on Function Data Service Infrastruc ture Service Service Flow Data Flow Service Provider Service Owner Service Consume r Service Require ment

63 LEADing Practice Maps: Platform Rule (PLR) Map What/Which What Where Whose Why Rule Platform Rule Platform Rule Description Platform Compliance Platform Rule Owner Platform Rule Rationale

64 LEADing Practice Maps: Platform Distribution (PLD) Map What/Which What Where Whose Why Distributi on Platform Distribution Name Logical Application Component Platform Distribution Description Platform Service Platform Distribution Owner Platform Distribution Requirement

65 LEADing Practice Maps: Infrastructure (IF) Map What/Which specification: Who is involved: Where is it used: Infrastructure Logical/Physical Component Device Function Feature Service Owner Users Channel

66 LEADing Practice Maps: Infrastructure Rules (IFR) Map What/Which What Where Whose Why Rule Infrastructure Rule Infrastructure Rule Description Infrastructure Rule Compliance Infrastructure Rule Owner Infrastructure Rule Rationale

67

68 LEAD Requirement Management Method - Conceptual Description Why Stakeholder (ST) Matrix What in terms of security context e.g. Performance/Val ue Expectation Why specification e.g. Goal/Reason How - specification e.g. Expected areas What in terms of security context e.g. Performance/Val ue Expectation Why specification e.g. Goal/Reason How - specification e.g. Expected areas Who security specification: Stakehol der Stakeholder Who - in terms of security ownership: Stakeholder (Business Unit) Stakeholder (Department) Stakeholder (Operational Manager) Where specification: Business Area or Technology Area, etc. Business/Tec hnology Area Business Area Technology Area

69 The concept of the LEAD Requirement Management Reference Method

70 LEAD Requirement Management Method-Conceptual Context: Example of how to link the What to the Why in the Business Competency Object Group What (Objects) Business Competency Organizational Construct/Design Resources and security aspects Why (Value Expectation) Revenue Model Service Model Cost Model Performance Model Value Model Operating Model Develop the organizational competencies X X Slim line and optimize the Organizational Compliance Construct X X Redesign the organizational business areas according to security construct and compliance aspects X (X) X Improve balance between buy and lease security forces (X) X Reduce organizational complexity (X) X X Integrate and standardize business functions and service X (X) Better resource and skills security performance X X Improve security management skills of staff (X) X Improve ability to attract security talents (X) X Optimize security resources (X) X X Capabilities Cross Organizational development and optimization (X) X X Select which and activity can be integrated or standardized X X Choose the aspects and events that have direct customer and supplier interaction (X) X X X Improve integration of business Securities across partner networks X X X Identify the management for better reporting and decision making X X Services Classify the main 's for optimization (X) X X Categorize the supporting 's for possible standardization and cost cutting X (X) X (X) High Importants X = Targeted Align pricing with service strategies according to revenue stream X X Medium Importants (X) = XSecondary target Low Importants

71

72 The LEADing Practice Reference Framework Business Decomposition & Composition

73

74 LEAD Requirement Management Method-Conceptual Description and Relations: Relating the Stakeholder Needs and Wants to the Objects and Layers

75 Applying the Objects to the Layers using the Decomposition & Composition Method (example: )

76 LEAD Requirement Management Method - Conceptual Description Why Requirement Matrix Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technol ogy) Requirem ent Who/Whom specification e.g. Stakeholder/Owner Where specification e.g. Layer, Objects, Area (, service, data, infrastructure) etc What specification: High Level Requirements What specification: Detailed Requirements Which expectation specification e.g. Value/Performance Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technol ogy) Which expectation specification e.g. Value/Performance

77 Layered Architecture method: Architecture The main principle behind the Leading Enterprise Architecture Development (LEAD) concept, and what makes it differ from other traditional Enterprise Architecture frameworks, is the fact that it does not only work in domains, but across layers (business, application and technology) within multiple domains through using the decomposition and composition method to integrate effortlessly across the different layers when interlinking the different modelling principles. As shown in the below example, each layer s Objects are defined by the specific layers requirements, the capability of the object, the resources, tasks and. The functions that a layer provides can be seen as the layer s services since a layer provides a set of functions and tasks and thereby services to its upper layer. In turn, the upper layer uses the lower layer s services (functionality and tasks) to achieve its own functions (services). The n th layer (+1 and/or 1) can therefore be seen as a service requester or provider since it ether gives input or uses the services provided by its lower layer.

78 Layered Architecture method: Architecture The LEAD layered method is built upon the concept of interlinking the objects that are within and work across the layers. While the layers and their specific objects may/will have different modelling principles, they do still have correlations, relationships and/or connections with other layers and these need to be related/connected in the right way: The Business Layer describes the objects within the Business layer e.g. the Business Goals, Business Requirements and Business Competencies are linked to Business Securities, Business Services and business workflow. The Application Layer describes the deliverables within the application, date and Information Architecture. The maps, matrices and models depicts how Data Goals, Data Flow & Service, Data Requirements and Data Components are linked to Application Goals, Information Flow & Service, Application Requirements and Application Flow & Component. The Technology Layer describes the deliverables within the platform and infrastructure areas. The maps, matrices and models depicts how Platform Goals, Platform Flow & Service, Platform Requirements and Platform Components are linked to Infrastructure Goal, Infrastructure Flow & Service, Infrastructure Requirements and Infrastructure Component.

79 Applying Layered Architecture principles to services Modelling Principle view (advanced)

80 LEAD Requirement Management Method-Conceptual Description and Relations: example of High Level Requirements related to the objects and layers

81 LEAD Requirement Management Method- Logical Concrete: Example of detailed Requirements related to the objects and layers

82

83

84 The LEAD Way of Working around Concepts The LEADing Practice Way of Working around Concepts is critical discipline of translating both strategic planning and effective execution. Structure the arrangement of effort and work, by translating the Way of Thinking into a structural approach of working. The Way of Working around Concepts organizes, classifies, aligns, arranges, quantifies, recommends and selects objects and or artifacts in the systemized and categorized way they need to be de-composed or composed together.

85 Way of Working around Modelling and Architecture: Tactical Tasks Modelling and Architecture Tasks & Services Analyze Modelling and Architecture CAN, WANT and SHOULD do scenarios Analyze and benchmark relevant strategies Identify pain chain and goal chain Define innovation and transformation need Identify and develop relevant strategic business objectives (SBOs) and critical success factors (CSFs) Define expectations and drivers Develop guidelines and measurements Ensure reporting and decision flow Identify non-core competencies for cost cutting Map core differentiating and core competitive competencies for the model of ones organization Develop strategic policies and guidelines

86 LEAD Requirement Management Method- Logical Specifications: Requirements related to the objects and layers What (Performance Expectation) (Value Expectation) High Level High Level Choices

87 LEAD Requirement Management Method- Logical Specifications: using Maturity Reference Method to identify Gaps and Development potential There are a lot of different maturity approaches on the market, the most known is CMM and CMMI, however the narrow focus makes these maturity models and approaches limited to real essential architecture and business improvement (e.g. cross business effectiveness and efficiency). A maturity model can be described as a structured collection of elements that describe certain aspects of maturity in an organization. A maturity model may provide, for example: a place to start; the benefit of a community s prior experiences; a common language and a shared vision; a basis for prioritizing actions; and a way to define what improvement means for your organization. A maturity model can also be used as a benchmark for comparison and as an aid to understanding. They are an essential part to assess status and identify improvement opportunities, and in particular maturity models, can help organizations assessing their current way of working in a structured way to implement changes and improvements, has become essential.

88 LEAD Requirement Management Method- Logical Specifications: using Maturity Reference Method to identify Gaps and Development potential

89 LEAD Requirement Management Method- Logical Specifications: using Maturity Reference Method to identify Gaps and Development potential Lessons Learned: Ease of Implementation & ROI Curve

90 LEAD Requirement Management Method- Logical Specifications: using Maturity Reference Method to identify Gaps and Development potential Lessons Learned: Stay Agile, use the relevant LEAD Objects

91 LEAD Requirement Management Method- Logical Specifications: Maturity Development based on the specific Object Maturity

92

93 The LEAD Way of Working around Matrices A LEAD Matrix is a representation that accurately shows the relationship between specific decomposed and composed LEAD Objects. The core idea of a matrix is that it typically consists of aspects of one idea each in a list of row, another idea as a set of columns and a third as the cross product between the rows and columns. This allows the LEAD Matrix to relate the unfamiliar to the familiar objects in the different layers (composition) usually through the form of a diagram, a table or a chart (e.g. rows and columns), thereby outlining direct connection points and showing a common pattern of the LEAD Objects. This enables the practitioner to do fully integrated Modelling across all architectural layers e.g. business, application and/or technology.

94 LEADing Practice Matrices: Forces & Drivers (FD) Matrix External Driver/Forces For Internal Driver/Forces For Business, Service, Role, Technology, etc. Who/Whom specification e.g. Stakeholder/Owner involved Why driver specification e.g. Driver Which aspects involved specification e.g. Competency/Process/Service Who/Whom specification e.g. Stakeholder/Owner involved Why driver specification e.g. Driver Which aspects involved specification e.g. Competency/Process/Service Who/Whom specification e.g. Stakeholder/Owner involved Why driver specification e.g. Driver Which aspects involved specification e.g. Competency/Process/Service

95 LEADing Practice Matrices: Requirement (Rq) Matrix Requirem ent Who/Whom specification e.g. Stakeholder/Owner Where specification e.g. Layer, Objects, Area (process, service, data, infrastructure) etc What specification: High Level Requirements What specification: Detailed Requirements Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technolo gy) Which expectation specification e.g. Value/Performance Why, in terms of reason security specification e.g. Motivation and Drivers for Whither specification e.g. Goal & Objectives (Business/Application/Technolo gy) Which expectation specification e.g. Value/Performance

96 LEADing Practice Matrices: Strategy (S) Matrix What in terms of security context specification e.g. Strategy Where- security specification e.g. Business Area, Groups, Applications, Technology, etc How- security specification e.g. Customers, finance, operations & risk Why in terms of security reason specification e.g. Reason and Drivers for change Who - area or security strategy specification e.g. owner Whither in terms of security goal specification Who/Whom specification e.g. Stakeholder and resources involved Why in terms of security reason specification e.g. Reason and Drivers for change Who - area or security strategy specification e.g. owner Whither in terms of security goal specification Who/Whom specification e.g. Stakeholder and resources involved

97 LEADing Practice Matrices: Measurement & Reporting (MR) Matrix Ownership (Whom is the owner of the measurements and reporting) Requirement (What are the requirements for measuring and reporting results) Business Area & Group (What business area and group does the measurement and reporting belong to) Service Area & Group (What service area and group does the measurement and reporting belong to) Process Area & Group (What process area and group does the measurement and reporting belong to) Measurement & Reporting What/which specification: Where specification: Who/whom specification: Objective (CSF, plan, forecast, budget) Performance Indicator (Strategic/Tacti cal/operational ) Service Measurements (Service Level Agreements) Process Measurements (PPI) Reporting System Reports

98 LEADing Practice Matrices: Cost (Co) Matrix What/which specification: Where specification: Where specification: LEADing Practice Cost Matrix Cost Cost Cutting Strategy (Strategic Business Objective) Cost Cutting Objective (CSF, plan, forecast, budget) Cost Cutting Performance Indicator (Strategic/Tacti cal/operational ) Business Compete ncy Area Business Compete ncy Group Location/ place Stakehol der involved Busines s Unit Owner Area Owner/M anager Business Area & Group (Which business area and group are involved) Service Area & Group (Which service area and group are involved) Business Process (Which business process are involved) Roles (Which business roles are involved)

99 LEADing Practice Matrices: Information (I) Matrix Requirement (What requirements exist involving information) Business Rules (Which business rules relate to the information) Business Compliance (What does the information have to comply with) Requirement (What requirements exist involving information) Business Rules (Which business rules relate to the information) Business Compliance (What does the information have to comply with) Information What/which specification: Object (Business, Information or Data) Data Entity How specification: Data Compliance (Including security) Who/whom specification: Business Owner Reporting

100 LEADing Practice Matrices: Rule (Ru) Matrix What/which specification: How specificati on: Rule Business Rules Service Tier Service Rules Process Rules Gateways Business Object Informatio n Object Business Complianc e Requirement (What is the requirement to the rule) Business Service (Which business service does the rule apply to) Application Service (Which application service does the rule apply to) Business Process Management Notations (BPMN) (which processes are involved)

101 LEADing Practice Matrices: Media (Me) Matrix Where specification: Media Business Channel Business Media Service Channel Requirement (What is the requirement to the media) Goal (What is the goal of the media) Application Channel (Which application is involved) Data Channel (Which data is involved) Platform Channel (Which platform is involved) Infrastructure Channel (Which infrastructure is involved) Requirement (What is the requirement to the media) Goal (What is the goal of the media) Application Channel (Which application is involved) Data Channel (Which data is involved) Platform Channel (Which platform is involved) Infrastructure Channel (Which infrastructure is involved)

102 LEADing Practice Matrices: Process (P) Matrix Whither (option) specification e.g. Events, gateways and measures (manual/automated) Where, in terms of level e.g. Strategic/Tactical/Opera tional How, specification in terms of manner e.g. management, main or supporting Why in terms of reason of behavior e.g. Rules and compliance aspects Whither in terms of goal specification e.g. goals, plans, requirements etc Proc ess Business Process Area What specification: Process Groups Business process Process Steps Process Activities Stakehold er involved Who/Whose specification: Process Owner Managers involved Roles/Resou rces involved

103 LEADing Practice Matrices: Service (Se) Matrix Whether (option) specification e.g. Service nature (simple, generic, complex) Where, in terms of level e.g. Strategic/Tactical/Operatio nal How, specification in terms of manner e.g. management, main or supporting Why in terms of reason of behavior e.g. Rules and compliance aspects Whither in terms of goal specification e.g. goals, plans, requirements etc Which Service measurements, reporting, channels are involved Servi ce Service Area What specification Service Group Business Service Service Channel Stakeholder Involved Who/Whose specification Service Owner Manager Involved Role/Resou rce Involved

104 LEADing Practice Matrices: Application (A) Matrix What/Which specification: Application Service, <Application Service Name, >1 <Application Service Name, >5 <Application Service Name, >6 <Application Service Name, >7 <Application Service Name, >8 Application Requirements (High Level/Detailed) Physical Application Component Version number Application Modules Application Features Application Function Application Tasks Application Tasks

105 LEADing Practice Matrices: Application Role (ARo) Matrix Application Role, <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> <Application Role Name> Role Who/Whom specification: <Business Role, > What/Which specification: <Application Task, > <Application Service, > Who/Whom specification: <Business Role, > What/Which specification: <Application Task, > <Application Service, >

106 LEADing Practice Matrices: Application Rule (AR) Matrix Application Rule, Rule <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Application Rule Name> <Business Rule, > What/Which specification: <Application Function, > <Business Rule, > <Application Function, >

107 LEADing Practice Matrices: Application Compliance Matrix Application Compliance, <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> <Application Compliance Name> Compliance <Application Rule, > What/Which specification: <Application Service, > <System Measurement, > Who/Whom specification: <System Owner, >

108 LEADing Practice Matrices: Data (D) Matrix Business Service (which business service does the data service collaborate with) Application Service (which application service does the data service collaborate with) Application Task (which application task uses the data) Data Requirement (what business requirement does the data have to meet) Data Goal (to what end or purpose is the data required) Data Rule (what rule governs the data) Data Compliance (in what way does the data have to comply) Data What/which specification: Who is involved: Where is it used: Physical Data Object Data Application (information Data Entity Data Service Data User Channel Media Component /data) Owner

109 LEADing Practice Matrices: Data Rule (DR) Matrix What specification: Data Rule Data Rule Data Rule Data Rule Business Rule (which business rule does the data rule have to adhere to) Service Rule (which service rule does the data rule have to adhere to) Application Rule (which application rule does the data rule have to adhere to) Platform Rule (which platform rule does the data rule have to adhere to) Data Compliance (what does the data rule have to comply with)

110 LEADing Practice Matrices: Platform (PL) Matrix Platform Requirement (what business requirement does the platform have to meet) Platform Goal (to what end or purpose is the platform required) Platform Rule (what rule governs the platform) Platform Compliance (in what way does the platform have to comply) Platform Requirement (what business requirement does the platform have to meet) Platform Goal (to what end or purpose is the platform required) Platform Rule (what rule governs the platform) Platform Compliance (in what way does the platform have to comply) Platfo rm Logical/Phy sical Component What specification: Device Function Service Who is involved: Owner Users Where specification: Channel Media

111 LEADing Practice Matrices: Platform Service (PLS) Matrix Business Service (which business service uses the platform service) Application Service (which application service uses the platform service) Application Task (which application task uses the platform service) Data Service (which data service is supported by the platform service) Infrastructure Service (which infrastructure service supports the platform service) Service Flow (which service flow is the platform service a part of) Platform Service Platform Service Platform Service What specification: Platform Platform Service Service Platform Service Platform Service Platform Service

112 LEADing Practice Matrices: Platform Distribution (PLD) Matrix What specification: Platform Distribution Platform Distribution Platform Distribution Platform Distribution Platform Distribution Requirement (what business requirement does the platform distribution have to meet) Platform Distribution Goal (to what end or purpose is the platform distribution required) Platform Distribution Rule (what rule governs the platform distribution) Platform Distribution Compliance (in what way does the platform distribution have to comply)

113 LEADing Practice Matrices: Infrastructure Service (IFS) Matrix Business Service (which business service does the infrastructure service collaborate with) Platform Service (which platform service collaborates with the infrastructure service) Service Flow (which service flow is the infrastructure service a part of) Business Service (which business service does the infrastructure service collaborate with) Platform Service (which platform service collaborates with the infrastructure service) Service Flow (which service flow is the infrastructure service a part of) Infrastructur e Service Infrastructur e Service Infrastructur e Service What specification: Infrastructur Infrastructur e Service e Service Infrastructur e Service Infrastructur e Service Infrastructur e Service

114 LEADing Practice Matrices: Infrastructure Rule (IFR) Matrix Business Rule (which business rule does the infrastructure rule have to adhere to) Platform Rule (which platform rule does the infrastructure rule have to adhere to) Infrastructure Compliance (what does the infrastructure rule have to comply with) Business Rule (which business rule does the infrastructure rule have to adhere to) Platform Rule (which platform rule does the infrastructure rule have to adhere to) Infrastructure Compliance (what does the infrastructure rule have to comply with) Infrastructure Rule What specification: Infrastructure Rule Infrastructure Rule Infrastructure Rule

115

116 LEADing Practice Application Models Example of how Application relates to Rules

117 LEADing Practice Architecture Layer Example of how security aspects are related through the layers

118 LEADing Practice Architecture Layer Example of how security aspects are related through the layers Examples of an application security (application software ) that are being used by an organization

119 LEADing Practice Application Models Example of how Application relates to Business Roles In this example, it is shown where application security aspects are related to the system services of the Application Layer. The Presentation Services (Portal and Web) and Web (delivery channel) services has a Webmaster (application role) associated with it while the & Privacy Management service has a Systems Specialist (another application role) associated with it.

120 LEADing Practice Application Models Examples of how data services is being delivered to the organization from within the Information Architecture design Metadata Domain Defined as data about the data. Metadata security are the security aspects that are applied the characteristics of each piece of corporate data asset and other entities.

121 LEADing Practice Application Models Examples of how data services is being delivered to the organization from within the Information Architecture design Master Data Refers to the security aspects applied to data describing the core business entities, such as customer or product data.

122 LEADing Practice Application Models Examples of how data services is being delivered to the organization from within the Information Architecture design Operational Data The security aspects applied to the transactional data capturing data, which is derived from business transactions.

123 LEAD Requirement Management Method- Logical Concrete: Architecture: Solution Build Decisions (Object Relations) (BITE) (Architecture Decision)

124 LEAD Requirement Management Method- Logical Concrete: Architecture: Solution Build Decisions

125

126

127 LEAD Requirement Management Method- Physical Completion: Structural Way of Implementation

128 The LEADing Practice Reference Framework Structural Way of Implementation

129

130

131 The Way of Requirement Governance: Conceptual Context

132 The LEADing Practice Reference Framework The Way of Governance: Logical Design The logical design of governance involves setting standards and priorities for the various relevant innovation and/or transformation efforts and their phases from analysis, build, design, implementation, run/monitoring and continuous improvement. A part of this is identifying governance stakeholders and defining the right experts and architects involved within the various projects. The ultimate goal of both business governance and governance is to control an organization s defined strategies, goals and create/realize maximum value while mitigating risk. As a part of the continuous improvement concept the governance steps includes the establishment of links between the various teams like governance managers, change and architectural boards, program management office, the service delivery management (business units) and the continuous improvement standards. Their goal is among others to share -improvement and standards. governance is the logical design that ensures an important link to value identification, value creation and value realization. Relating both the successes and shortcomings of an organization s operational execution of the performance and value drivers defined in ones organization and applied throughout the lifecycle.

133 The Way of Requirement Governance : Logical Design

134 The Requirement Management Lifecycle

135 Conclusion (Takeways)

136 The LEAD Reference Framework: How it all is combined 138

137 Information & Information Privacy We take a brief look at the current issues surrounding Information and Information Privacy. First, we consider why we need to ensure Information and Information Privacy is covered by business information, and then we look at the potential areas in which information could be seen to be under risk in a typical enterprise information scenario. Today, we see a number of trends around the security aspects of business systems: Across the globe there has been a growing number of attacks on major enterprises with (internal inspired) threats still high. Business infrastructures, such as utility networks for water or electricity, are increasingly equipped with sensors to capture information. The information is used, for example, to predict peak consumptions. The Cloud Computing delivery model requires new means to federate identities across internal and external systems to protect data from unauthorized access. Regulatory compliance pressures around the world across all industries demand strict enforcement of data access and Information Privacy. Access by partners to internal systems is ever increasing as the new trends to distributed solutions and cooperation across business boundaries take place. As systems design leads to more consolidated data sets (around core enterprise-wide DW and MDM capabilities), the opportunity to hack one s critical resource can actually increase.

138 Information There are many areas in which we must address Information in our business. The figure on the following slide illustrates these areas to define business services required around security, to define the IT related security services, and to help set policies around how to manage these differing areas, specifically: Business Services Defined as security aspects of the business that must be specified, owned, and managed for successful and secure operations of an enterprise. These are driven by regulatory concerns, partnerships, competitive influences, and more. IT Services Form the core technical components that must be designed and deployed around our Data Domains Types to deliver the security functions as defined in the Business Services layer. This means that the IT Services layer is responsible for addressing how the business security services are physically deployed. Policy Management Defined as a set of policies and principles that ensure that the Business Services are managed in a consistent manner with IT. Therefore, the Policy Management links the business-related and IT-related security services together.

139 The Three Business Layer Pillars of Information

140 Business Services Compliance & Reporting Services Measure the performance of the business and IT systems against the metrics established by the business. This uses audited and other information regarding overall system activity to compare actual system behaviors against expected system behavior. Identity & Access Services Manage the creation and deletion of user identities across the enterprise. Often, they also ensure self-management of that identity after it is created. Data Protection, Privacy, and Disclosure Control Services Deal with the protection of data across all five domains. The control points of these services are areas such as publishing a privacy policy, managing user consent to these policies, capturing user preferences around how to be contacted, and reporting on who has accessed what information. Trust Management Services Manage the identification of trusted relationships between various differing entities within a business; for example, relationships among user ID s, security domains, or different applications. A set of well managed business rules is defined that permits the related entities to transfer information and do business together. Non-Repudiation Services Ensure that any two parties involved in a transfer of data between each other cannot falsely deny that the communication has taken place. Note that it does not protect the data itself but does ensure that the two parties involved have received and sent the data and cannot refute this claim. Secure Systems & Network Services Cover areas such as intrusion detection, operating system security, malware detection, and patch management processes.

141 IT Services Identity Services Usually, Identity Services must be able to manage the core function associated with storing and managing information around organizational entities, such as user, a role or user groups. This information is stored in some form of repository such as an LDAP directory. There might be multiple repositories within the enterprise, and these might need synchronizing through provisioning policies to ensure that identity information is consistent across the enterprise. Authentication Services Authenticating the users within the enterprise is done through Authentication Services. These services could support multiple different approaches such as user name and password, hardware token based, or even biometric solutions to authenticate an individual based on fingerprinting or retinal pattern recognition. Authorization Services After any authentication service, generally, an authorization service follows. This service determines if the user is authorized to perform the requested operation on the target resource. To allow authenticated users to perform tasks for which they have been authorized, there must be policies in place that describe the authorization decision for the appropriate authenticated service. Audit Services For example, to meet certain compliance requirements or to perform incident analysis, audit trails must be available to show who accessed what and when. Audit Services maintain logs of critical activities. Typical examples of logged activity can be login failures, unauthorized attempts to access systems, modification of security and identity policies, and so on.

142 IT Services Integrity Services This service group attempts to monitor traffic intra- and inter-enterprisewide to identify if data has been maliciously altered in some manner. Typically cryptographic techniques such as message integrity codes, authentication codes, and digital signatures are used. Confidentiality Services They are applied to prevent disclosure of sensitive information traveling through untrusted communication networks, widely used over the Web. Even if a user is authenticated and authorized, the data requested must still be protected as it moves across systems boundaries.

143 Policy Management Policy Administration Services They maintain changes to security policies over the lifetime of the application. The policies need to be described in terms that make sense to the underlying architecture. For example, if used in an SOA context, then the policy Metadata should contain information about the services used and other information like the strength of encryption. Policy Distribution & Transformation Services They distribute policies defining access to the applications or services themselves to the places where they are enforced. The policies themselves can be deployed using known standards such as WS-Policy or WS- Policy, so that the service or requestor can enable the security using its own local techniques. Policy Decision & Enforcement Services They are logically connected to Policy Enforcement Points (PEP), which admin users use to update security requirements. The PEP s in turn rely on Policy Deployment Points (PDP) or nodes to physically administer the policies across the enterprise. Challenges of multiple PDP s and PEP s are that different entities might administer them and coordination can become difficult. A central decision function that oversees these functions can sometimes assist greatly. Monitoring & Reporting Services This function ensures the business can take the business policies and map them down to the IT services and report successfully on the degree of compliance by the IT Services deployed. It is necessary to keep track of current policies, historic policies, and compliance assessments against corporate policies. Traceability from the corporate policies down to the mechanism utilized to achieve those policies is critical to this function. Changes should be tightly controlled, access to them traced through reporting and monitoring, and audit trails supplied at any point in the process.

144 Questions? James Thomas EA Thought LEADer Knotion Consulting For more information:

145 147