Security Services Catalogue

Transcription

1 Project Charter for the development of a Security Services Catalogue Version 1.0 Prepared by Pascal de Koning, i-to-i May 27 th, 2014

2 Project Charter for Security Services Library Page 1 Table of Contents 1. Project Description Vision The function of a catalogue Project goals Relationships with other work ISO27001/ISO ISF Standard of Good Practice COBIT O-ISM O-ESA (Open Enterprise Security Architecture) OSA (Open Security Architecture) A Security Services Catalogue is not a Unified Control Objective Framework Deliverables, Ownership and Success Criteria Deliverables Project ownership and intellectual property (IP) Critical Success Factors Stakeholders Project chairman The Open Group The SABSA Institute The Open Security Architecture Working group members Communication plan Project Scope Assumptions and Dependencies Risks Resources Approval of the deliverables Planning Revision History Name Date Reason For Changes Version Pascal de Koning May 2 nd 2014 Initial version 0.1 Pascal de Koning May 27 th 2014 Reviewed by John Sherwood, Jim Hietala, Tobias Christen, John Sluiter, Lex Borger, Jason Kobes, Vicente Aceituno and Geoff Besco. 1.0

3 Project Charter for Security Services Library Page 2 1. Project Description The aim of the project is realize the community-driven development of a security service catalogue, so that it can be consumed by enterprise (security) architects. Reuse of and referral to existing material is encouraged. A readily available catalogue enables Enterprise (Security) Architects to quickly make a clear link between high level requirement and corresponding solution(s). The catalogue contains the organizations solutions memory and enables re-use. Without the catalogue and associated governance, the benefits of security architecture are only partly realized. It provides the mechanism for feedback from delivered systems and solutions to the architecture. The desire for a security services catalogue was expressed clearly at the SABSA world conference 2013, hosted at COSAC. SABSA offers a framework for Enterprise Security Architecture. It is owned by the SABSA Institute. The focus of SABSA is to realize a business-driven security architecture. At current, worldwide there more than 3000 people certified as SABSA architect. A lot of them have been working on the definition and inventory of the business drivers and business attributes. At this time, many practitioners are seeking ways to actually fill in the security functions at the logical layer. A current development is that security is integrated more and more into enterprise architectures. A mainstream enterprise architecture framework is TOGAF, owned by The Open Group. It describes an Architecture Development Method (ADM) that can be used to deliver an Enterprise Architecture. A security architecture framework that fits well with TOGAF is SABSA, owned by The SABSA Institute. At this moment the TNSPproject is running, which goal is to provide the integration of security into the Next version of TOGAF, using many SABSA ideas. Part of this is the development of practitioner guidance. This security-services-catalogue project will deliver a part of this TNSP-guidance Vision For security architects, the security services catalogue is a register that supports filling in the logical (aka functional) layer of the architecture with security controls. Unlike existing control frameworks that contain requirements, the security services catalogue describes security building blocks that actually deliver protection. This architecture approach enables smooth integration of information security in the enterprise architecture. The standardized approach contributes to the professionalization of the security management organization and facilitates a more efficient and cost effective way of working. One of the main advantages of the Security Services Catalogue is that it is a common terminology and reference framework for the domain of security management allowing better cooperation between the parties concerned.

4 Project Charter for Security Services Library Page The function of a catalogue To give an idea of the function of the catalogue, we use a historic source from a librarian. Charles Ammi Cutter made the first explicit statement regarding the objectives of a bibliographic system in his Rules for a Printed Dictionary Catalog in According to Cutter, those objectives were 1 to enable a person to find a book of which either (Identifying objective) the author the title the subject the category is known. 2. to show what the library has (Collocating objective) by a given author on a given subject in a given kind of literature 3. to assist in the choice of a book (Evaluating objective) as to its edition (bibliographically) as to its character (literary or topical) These objectives can still be recognized in more modern definitions and they also hold for the Security Services Catalogue, although in this case a book is replaced by a security service.

5 Project Charter for Security Services Library Page Project goals The project goals are: 1. To bring security services within the realm of enterprise architects, by using the concepts of TOGAF and SABSA to give shape to the Security Services Catalogue. This catalogue enables communication and cooperation between technical and business oriented security professionals. 2. To fill in the Security Services Catalogue, a unified set of security services that can be used by enterprise security architects. There are some useable sets available, so this goal is more about selecting or combining existing sets of services. A project principle is to make use of existing good work if available. The workgroup will: i. look at existing security control libraries, and engage with the one(s) that are useable. For example OSA or O-ISM3. ii. give guidance on the selection of security services for a given enterprise, for example by giving services a priority rating or implementation impact rating. 3. To add a how-to component to the logical layer of the SABSA framework, based on work already done by Pascal de Koning and John Sherwood on a methodology for achieving this. This work is known as the trusted architecture concept. 4. To develop TOGAF practitioner guidance on the benefits and usage of a security services catalogue. This is positioned as TOGAF Part 2 Practitioner guidance and will be offered to the TNSP project. 5. To establish a process that maintains the catalogue for years to come. A process by which a set of roles and responsibilities are applied for who shall have authority for including materials in the repository, who shall apply quality control, who shall operate and maintain the repository and who shall have access to use the materials stored. 6. To give life to an international community of enterprise security architects, boosting the exchange of knowledge and improving the personal networks of participants, and bringing together both the TOGAF and the SABSA communities in a common purpose Relationships with other work ISO27001/ISO27002 ISO27002 is a set of control objectives that support the implementation of an Information Security Management System (ISMS) as described in ISO It is a widely accepted standard. Although not meant to be so, the ISO27002 is often used as a checklist. The latest version is published in 2013, following up the 2005 version. The time it takes before it is updated means per definition that ISO27002 cannot cope with emerging threats and ICT developments. The price is about 300,- euro for both. ISO s model gets in the way of freely distributing this work. In this project we ll just use it as a source of inspiration but not literally take it over.

6 Project Charter for Security Services Library Page ISF Standard of Good Practice The ISF Standard of Good Practice is a best practice that is updated yearly. It addresses both a way to approach information security as well as a set of control objectives to implement security. This set of control objectives is at the same abstraction layer as foreseen for the SRA. The price is about 3.000,- euro. ISF only distributes its deliverables among members, which means that the information cannot be shared freely (it s not open source). This business model might be inhibiting cooperation, although also at ISF members are now looking at security architectures and SABSA, so this might bring possibilities in the future COBIT COBIT has a very strong controls library in three layers, but its focus is on IT governance. It plays a useful part of the whole picture O-ISM3 The O-ISM3 model (Open Information Security Management Maturity Model) of The Open Group breaks information security management down into a comprehensive but manageable number of processes, with specifically relevant security control(s) being identified within each process as an essential subset of that process. The section in O- ISM3 that describes the security processes is relevant for this project O-ESA (Open Enterprise Security Architecture) O-ESA defines a policy-driven security architecture with the aim to automate access control and other (network-related) security measures. It covers the governance of the rule sets, the technical design of the controls and the operational processes. O-ESA is a technique-focused security architecture, in SABSA-terms it would be placed on the logical and physical layer. It could be used as a source for some technical controls OSA (Open Security Architecture) OSA, OSA is a library of security controls that are applied to standard situations in security patterns. This is visualized by easy to understand graphs. OSA is open source, driven by a small community and open for comments and support. The library exists of about 170 controls (based on NIST SP800-53) seems to be very usable. A very strong aspect of OSA is the visualization of security patterns. Resources for creating these visualizations are already available and it contains a lot of existing material that can be used as examples. The community is small (with three core members) but willing to support this project.

7 Project Charter for Security Services Library Page A Security Services Catalogue is not a Unified Control Objective Framework A Unified Control Framework is a set of control objectives. Commonly these are mapped to specific control frameworks, such as ISO Examples of sources for controls (or mappings) are: Unified Compliance Framework ( This is a for profit venture, not open source. The Cloud Security Alliance s Cloud Controls Matrix, which seeks to map security controls from different compliance regulations and industry standards The BITS Shared Assessments Program SIG/AUP. The specification of control objectives is not the goal of this project. The security services catalogue does not contain control objectives, but is a set of measures. They are functional (logical) security building blocks that will be implemented different at different environments. They offer protection and their implementation can be given a maturity rating. Ergo, it is a service delivering protection, not a requirement for protection.

8 Project Charter for Security Services Library Page 7 2. Deliverables, Ownership and Success Criteria The working group will deliver a coherent set of documents that together define the security services catalogue and enable the usage of this catalogue from different framework perspectives Deliverables 1. Security Services Catalogue definition A data dictionary, containing definition of service control, measure, security service, security pattern. Maybe there are already some Glossaries around that can be referred to (e.g. SABSA, O-ISM3, OSA). The OSA taxonomy is displayed below as an example SABSA practitioner guidance An architecture model that defines Security Services Catalogue in a SABSA context. This already exists (as Trusted Architecture concept, see further on in this document) and needs only refinement and publication. Guidance on the usage of the Security Services Catalogue 3. TOGAF practitioner guidance An architecture model that defines the Security Services Catalogue in a TOGAF context. Guidance on the usage of the Security Services Catalogue 4. Security Services Catalogue creation Referral to several source libraries Composition of a security landscape. The landscape helps structuring and finding the security services. In fact, we might use multiple landscapes to characterize and group them, e.g. role in in-depth-defense strategy, multi-tier strategy, etc.

9 Project Charter for Security Services Library Page 8 One example of a landscape is given below, and OSA also offers one at Patterns describing the coherence of security services from a security domain perspective (such as Identity & Access Management). This supports strategy: insight in and selection of the services. Patterns describing the application of security services from an ICT-capability perspective (such as how to secure a web application). This supports implementation of the services. Mapping of security services to common control frameworks, in a way that helps the practitioner make his/her own choice. There s more than one way to do it, but this is how your peers do it. 5. A maintenance process for the Security Services Catalogue 6. A flourishing community of Security Architects It will also establish a basis for future development and continuous improvement, under the auspices of the working group Project ownership and intellectual property (IP) The Security Services Catalogue workgroup is established as a joint initiative of The SABSA Institute and The Open Group Security Forum. The deliverables will be a piece of IP jointly owned between The Open Group and The SABSA Institute, with exception of: SABSA Practitioner guidance: This will be IP of The SABSA Institute.

10 Project Charter for Security Services Library Page 9 TOGAF Practitioner guidance: This will be IP of The Open Group. Security Services Catalogue: This will be IP of The SABSA Institute. There are on-going discussions between The Open Group and The SABSA Institute about the nature of a partnership between the two organisations and the possible linking of the certification of Security Architects under the auspices of the training and certification programmes of both governing bodies Critical Success Factors Adoption of the work as practitioner guidance by the TOGAF TNSP project. The participants of this project include TNSP key players, this assures that the product is in line with TNSP concepts and that acceptance will not be an issue. Buy-in from SABSA security practitioners. Communication is key in here. Social media (LinkedIn groups, twitter) will be used to inform a broad community on the project proceedings and ask for participation. At the SABSA World conferences this project will be on the agenda. Permission and/or cooperation of owners of control libraries that are to be used. To avoid issues with IP, the Security Services Catalogue will only refer to existing work and not copy it in. This way, practitioners know where to get more information but also know that that material is licensed in some way.

11 Project Charter for Security Services Library Page Stakeholders The project board consists of the project chairman, The SABSA Institute chief architect, and The Open Group Security Forum director Project chairman Pascal de Koning Co-chair of TOGAF Next Security Project Cyber security consultant at i-to-i The Open Group The Open Group will provide facilities for information sharing and conference calls. We can use their Webex facilities to host the meetings. There is also the possibility to use the Security Forum LinkedIn site and a Twitter account. Moreover, the expectation is that there are numerous members in the Security Forum and Architecture Forum who will have keen interest in this project once initiated. The Open Group Security Forum Director: Jim Hietala j.hietala@opengroup.org 3.3. The SABSA Institute The SABSA Institute will commit to this project and stimulate SABSA practitioners to contribute to and make use of the deliverables. The SABSA group on LinkedIn will also be used for this purpose. Soon as The SABSA Institute becomes fully operational, its web site and social media integration will also be available, and it will be a partner in the governance of the working group. Chief Architect: John Sherwood john.sherwood@sabsa.org 3.4. The Open Security Architecture The Open Security Architecture community, represented by Tobias Christen, is willing to pass on experience in security architecture Working group members Working group members are qualified security architects, such as SABSA practitioners.

12 Project Charter for Security Services Library Page 11 What is the reward for working group members? useful knowledge that can be applied in your own work environment challenging questions network opportunities an increased sense of humor the listing of your name as contributor/reviewer in publications the opportunity to work with an international community of security experts a good feeling about having been part of a project that made a difference in the way the world addresses security Communication plan The communication plan is to ensure that the project wins and maintains support across the boards and the community of security architecture practitioners. The following communications are foreseen: Project proceedings o Quarterly the working group will report proceedings to the TOG Security Forum, the TOGAF Next Security Project (TNSP) steering group and The SABSA Institute Board. o At an incidental basis, the working group will present its proceedings and results at the TOG conference and at the SABSA World conference at COSAC. This way, people that are interested are able to join the discussion and contribute to the project. o Quarterly, the project proceedings are briefly communicated through the SABSA and TOG LinkedIn groups. Operational meetings: o On a regular basis (e.g. monthly) there will be a conference call with the project members Workshops and presentations o Every working group member will receive invitation to SABSA World conference at COSAC. These must be seen as important information exchange sessions. Participants will pay the regular conference fee. o Every working group member will receive invitation to The Open Group conference, including an outline of the agenda regarding the working group activities. Participants will pay the regular conference fee. Deliverables: o Publishing the deliverables on the official Open Group and SABSA websites. If applicable, this is only on member-areas (see section about Intellectual Property). o sending publication notifications to SABSA and TOG list members and the LinkedIn groups o Writing a blog on TOG and TSI websites. o Offering the TOGAF practitioner guidance to TOGAF Next, so it can be included in Next Version of TOGAF.Vision For security architects, the security services catalogue is a register that supports filling in the logical (aka functional) layer of the architecture with security controls. Unlike existing control frameworks that contain requirements, the security services catalogue describes security building blocks that actually deliver protection. This architecture approach enables smooth integration of information security in the enterprise architecture.

13 Project Charter for Security Services Library Page Project Scope Scope in SABSA perspective: The scope is limited to the logical layer of the SABSA architecture framework. See Trusted Architecture concept below. The scope of this project is the Logical Services Catalogue. `

14 Project Charter for Security Services Library Page 13 Scope in TOGAF perspective High-level conceptual building blocks H. Architect ure A. Architect ure B. Business Architect G. Implement ation Requirem ents Managem ent C. Informati on Architecture Building Blocks F. Migrati on E. Opportuni ties D. Technolo gy Solution Building Blocks In TOGAF perspective, the focus is on Architecture Building Blocks. The TOGAF Architecture Content Framework classifies building blocks into two types: Architecture building blocks Solution building blocks. Architecture Building Blocks (ABBs) are defined in phases A, B, C, and D of the Architecture Development Method. ABBs can be viewed in the Architecture Continuum. They can range from generic Foundation Architecture ABB s to Organization Specific ABB s. They help to guide the formation of Solution Building Blocks (SBBs). Architecture Building Blocks: Capture architecture requirements; e.g., business, data, application, and technology requirements Direct and guide the development of SBBs ABB specifications include the following as a minimum: Functional and nonfunctional requirements including security capability and manageability Interfaces needed Interoperability relationship with other building blocks Dependencies with relation to other building blocks Mapping to business/organizational principles, policies, constraints and requirements Note: these TOGAF definitions are not rock-solid and likely to change in the near future.

15 Project Charter for Security Services Library Page 14 Scope in Open Security Architecture perspective The Open Security Architecture delivers a control database as well as a visualization method for patterns. A pattern describes how security should be implemented in a given ICT environment. The pattern approach is a useful extension to the SABSA logical layer and is part of this project. Patterns can be used to: Better understand the components within a security building block Better communicate how to apply security to a given environment Out of Scope: - The physical design, implementation and operation of the services.

16 Project Charter for Security Services Library Page Assumptions and Dependencies The project elaborates on deliverables from the TNSP project at The Open Group. It is assumed that the anchor points as described in TOGAF Next Part One are available. This project delivers Part 2 guidance, so to some degree it has to align to the overall TOGAF timeline. 6. Risks There is a lot of overlap and confusion in the terms control and service. This is why a dictionary needs proper attention. Often, volunteers are only available or committed for a short period of time. Therefore, it is best to divide the work in small chunks that can be accomplished in short time. 7. Resources There is no direct financial funding for this project. 8. Approval of the deliverables The Open Group approval procedures for White Papers is clearly defined, and will be managed by the nominated Open Group staff member from either of the participating Architecture Forum or Security Forum. One white paper will be presented as practitioner guidance as part of the TNSP-project. The procedure to obtain approval from the SABSA Institute will be handed over by John Sherwood. He s also responsible for this procedure being executed. This applies to the SABSA guidance. The content of the Security Services Catalogue will have a true democratic basis. The community guides the individual choices, there is no final editor. This governance process will be set up by The SABSA Institute.

17 Project Charter for Security Services Library Page Planning Q o Finalize project charter Q o Set direction at SABSA World Conference, Naas, Republic of Ireland (September 2014) Kick-off. Presentation TNSP-work, anchor points and positioning of this work as practitioner guidance Presentation Security Services Catalogue concept and Trusted Architecture model. Presentation Open Security Architecture work. Presentation O-ISM3 model Workshop: Decide on a format for the Security Services Catalog o A format for the catalog will be proposed, discussed and improved where necessary. Select suitable existing control sets, based on experience of attendees o We will exchange suggestions for control sets that might be useful. Create a first version of the Security Services Catalog. o We ll use an approach that allows everyone to contribute. All contributions are welcome. There will be structuring of the material based on group wisdom, but not on consensus. This will result in a practical take-away for every participant. Q o Write Security Services Catalogue definition o Create or adopt Security Services Catalogue landscape o Present at The Open Group conference, London, October 20-21, 2014 Q o Write SABSA practitioner guidance Q o Write TOGAF practitioner guidance o Present at The Open Group conference, Madrid, Spain, April 20-23, 2015 Q o Create and publish first version of Security Services Catalogue Q o Set up maintenance process for the Security Services Catalogue