Enterprise Security Modeling and Analysis with TOGAF®, ArchiMate® and SABSA

6,963 views

Published on

At Standard Insurance, a diversified financial services company, we are modeling and analyzing role-based access control (RBAC) to uncover residual risks and develop mitigation strategies. We use TOGAF and ArchiMate as our core EA methodology, and are introducing elements of SABSA, which is focused on enterprise security architecture and service management. We will present views of RBAC based on TOGAF, ArchiMate and SABSA concepts and show how we use these three paradigms to justify and explain systematic, scalable and transparent access control.

Delivered at July 2011 Open Group Austin Conference

Published in: Technology
1 Comment
18 Likes
Statistics
Notes
No Downloads
Views
Total views
6,963
On SlideShare
0
From Embeds
0
Number of Embeds
58
Actions
Shares
0
Downloads
0
Comments
1
Likes
18
Embeds 0
No embeds

No notes for slide
  • This is a rapid-fire presentation with lots of detail. You may not retain all of it the first time through. Afterwards, I encourage you to review the slides—email me for a copy with speaker notes–and speaker notes and email me with any questions. Note that the information in this presentation about The Standard’s systems and processes are simplified examples that may or may not reflect our current or future states.
  • InsuranceLife, Accidental Death and Dismemberment, Disability, Dental, Vision and AnnuitiesRetirement plansPublic and private-sectorDefined benefit (pension) and defined contributionVisit www.standard.com
  • In both diagrams, the Manager business role aggregates a number of system-specific roles. In the All-Too-Typical state, these relationships may seem arbitrary, but in the Desired State the relationships are clear. ArchiMate concepts and relationships are in italics.All-Too-Typical StateBusiness roles are not always defined consistently across organizationsBusiness roles have varying relationships with system rolesIndividual initiative is required to enforce many routine role transitionsBusiness-driven access control rule changes often require significant investigation and manual workDesired StateBusiness roles are clearly defined in a companywide context System roles clearly correspond to business rolesBusiness role changes trigger timely and accurate system role changesAuthorized administrators can alter access control policies quickly, efficiently, reliably and verifiably.
  • For our purposes, a visual modeling language for enterprise architecture allows the creation of unambiguous diagrams that fulfill the requirements of our chosen paradigms. Only ArchiMate includes such a language, for which we will demonstrate its applicability to expressing selected TOGAF and SABSA deliverables.SABSA contains just development procedures, verbal descriptions of relevant content and examples, but not explicit viewpoint definitionsTOGAF contains verbal descriptions of catalogs, matrices and diagramsArchiMate contains both verbal descriptions of diagrams and explicit meta-diagrams and examples
  • The SABSA Matrix has six rows, and only the top two are shown here.
  • This presentation includes examples of diagrams listed in boldface.
  • RBAC resulted in $6 billion in US economic benefits from 2002-2009, according to 2010 economic analysis commissioned by US NIST, from which this diagram was adaptedThe RBAC value chain is a series of processesthat each have a number of rolesassigned to them. The “Theory and Standards Development” process is associated with four goals. The final “Incorporation and Usage…” process is associated with three kinds of value identified in the NIST-sponsored analysis.
  • Here we use the ArchiMate 2.0 draft Motivation Extension to illustrate stakeholders and their concerns, along with assessments and requirements related to those concerns. Nesting of symbols is used here to show aggregation. ArchiMate concepts and relationships are in italics.
  • Nested organizations modeled as business actors are assigned to collaborations with each other and with external roles, This justifies RBAC by illustrating the complexity and criticality of shared activities across organizations.Nesting of symbols is used here to show composition. ArchiMate concepts and relationships are in italics.
  • This diagram shows how a number of lines of business use a variety of applications for different business functions. It contains example data only.
  • The RBAC System Support application functions are associated with the Session Creation event, which triggers an Access Check event. These events are a part of a longer sequence that begins with an access request and ends, assuming the request is allowed, with authorized access. The session is associated with an Active Role Set data object. Each user business actor aggregates an active role set for each session in progress, and is associated with all of the events. The Administrator business actor is assigned to the “Manage User, Role and Permission Relationships" business function. The RBAC Administration application function is used by “Manage User…”, and data flows from RBAC Administration to RBAC System Support. ArchiMate concepts and relationships are in italics.
  • RBAC for Target Applications is a product that aggregates a number of business services and application services, is associated with a number of infrastructure services, and delivers value in the form of security, scalability, agility and transparency. Each type of service is aggregated by a group. ArchiMate concepts and relationships are in italics.
  • Both the RBAC Administration and RBAC Systems Support application functions aggregate a number of more specialized applicationfunctions, which in turn access a number of data objects. The Session data object aggregates a number of roles and an authenticated user identity, and also contains (composition relationship) the Active Role Set. Two of the application functions at the top of the diagram share a constraint, and the Manage Role Hierarchy application function is associated with a requirement.The application functions, requirement, constraint and objects that are not required by all RBAC levels have numbers in parentheses to indicate where they are required.ArchiMate concepts and relationships are in italics.
  • The presenter has delivered this material to TheStandard’s information security director, who requested additional sessions with his staff.
  • Enterprise Security Modeling and Analysis with TOGAF®, ArchiMate® and SABSA

    1. 1. July 19, 2011<br />Modeling RBAC with SABSA, TOGAF and ArchiMateCreating a Foundation for Understanding and Action<br />Iver Band, CISSP - Open Group Conference, Austin, Texas<br />
    2. 2. About The Standard<br />The RBAC standard<br />Modeling motivations and objectives <br />Framework analysis and comparison <br />Modeling approach<br />Diagrams that justify and explain RBAC<br />Conclusion<br />References<br />Agenda<br />July 17, 2011<br />2<br />Thanks to Kevin Graham, CISSP and enterprise security architect at The Standard, for his partnership in this work<br />
    3. 3. Financial services company<br />Founded in 1906<br />Our purpose: <br />To help people achieve financial security so they can confidently pursue their dreams<br />Expertise:<br />Group Life & Disability Insurance<br />Individual Disability Insurance<br />Retirement Plans<br />Individual Annuities<br />Commercial Mortgages<br />Headquarters in Portland, OR<br />3,100 Employees<br />3<br />The Standard<br />July 17, 2011<br />
    4. 4. 4<br />IT at The Standard<br />July 17, 2011<br />
    5. 5. 5<br />Typical Access Control Challenges<br />July 17, 2011<br />Portal<br />SharePoint<br />Mainframe<br />Oracle<br />Business<br />Applications<br />ActiveDirectory<br />UNIX<br />LAN <br />Share<br />SQL<br /> Server<br />HR/Benefits<br />Remote<br /><ul><li>Fragmented identities, systems and processes
    6. 6. Insufficient understanding of identity and access management best practices
    7. 7. Inadequate visibility of access control mechanisms, changes and outcomes</li></li></ul><li>A widely implemented mechanism for protecting system resources standardized by ANSI INCITS 359-2004<br />Relies on user authentication, which in turn relies on identity management<br />Defines and applies relationships between<br />Users −often human, but can also be systems<br />Roles −job functions defined for an organization<br />Permissions −organizational consent to perform specific operations<br />Ensures that each user can execute only those operations authorized through roles that are both assigned to that user and activated for that user’s session<br />Common alternatives include<br />Mandatory Access Control (MAC) − administrators manage permissions based on the classification and category of each object and user<br />Discretionary Access Control (DAC)−users manage permissions for the objects they own<br />6<br />What is Role-Based Access Control (RBAC)?<br />July 17, 2011<br />
    8. 8. Four standard and cumulative levels<br />(1) Core, (2) Hierarchical, (3) Constrained, (4) Symmetric<br />All levels support<br />Restriction of user permissions to those acquired through roles<br />Many-to-many user-role and role-permission assignment<br />Review of user-role assignments<br />Simultaneous user access to permissions of multiple roles<br />Level 2 adds variants with differing hierarchy support<br />Support for an arbitrary partial order (reflexive, transitive, anti-symmetric)<br />Any restriction on the structure of the role hierarchy, for example:<br />Tree or inverted tree, limited inheritance or activation, depth limits<br />Level 3 adds separation of duty (SOD) support<br />Level 4 adds permission-role review with performance comparable to user-role review<br />7<br />RBAC Concepts<br />July 17, 2011<br />
    9. 9. Business drivers<br />Increase the efficiency, agility and transparency of access control <br />Support strategic requirements for enterprise-wide and federated identity and access management<br />IT drivers<br />Increase RBAC understanding of both IT and key user personnel<br />Derive greater value from existing identity management investments and justify further investment<br />Support identity and access management for enterprise initiatives such as CRM and Contact Center<br />Reduce administrative burden on IT by making access control comprehensible to the broader business community<br />Demonstrate relevance of TOGAF and ArchiMate to security architecture<br />8<br />RBAC Modeling and Knowledge Transfer Motivations<br />July 17, 2011<br />
    10. 10. Desired State<br />9<br />Well-Designed RBAC Is Easy to Understand<br />July 17, 2011<br />All-Too-Typical State<br />Local roles aligned with system context <br />Local roles aligned with business context <br />
    11. 11. This effort is not fundamentally about technology<br />It is about getting people to think differently about access control<br />Change behavior immediately and measurably<br />Systems and access administration requests and configurations<br />Lay the groundwork for successful investments in identity and access management solutions<br />It requires two types of communication to a range of business and IT stakeholders<br />Justification:Demonstrate the need for systematic access control<br />Explanation: Explain how RBAC works and how it satisfies the need<br />10<br />Modeling Objectives<br />July 17, 2011<br />
    12. 12. 11<br />How Can Our Chosen Frameworks Help?<br />July 17, 2011<br />
    13. 13. 12<br />TOGAF and SABSA Have Comparable Methods for our Purposes<br />July 17, 2011<br />SABSA Lifecycle<br />TOGAF ADM<br />
    14. 14. 13<br />Contextual and Conceptual Architecture are Organized Differently in Each Paradigm<br />July 17, 2011<br />ArchiMate2.0 DraftCore and Extensions<br />SABSAModel for Security Architecture<br />TOGAF Version 9Full Content Metamodel<br />Contextual<br />ServiceMgmt<br />Principles, Vision, Requirements<br />Extensions<br /><ul><li>Motivation
    15. 15. Governance
    16. 16. Process
    17. 17. Data
    18. 18. Services
    19. 19. Infrastructure Consolidation</li></ul>Business<br />Motivation<br />Conceptual<br />Business<br />Application<br />Logical<br />Information Systems<br />Technology<br />Physical<br />Technology<br />Implementation and Migration<br />Component<br />Realization<br />
    20. 20. Select cells from SABSA Matrix for RBAC justificationand explanation<br />Strength:Comprehensive treatment of enterprise security architecture<br />Select best fitting TOGAF catalogs, matrices and diagram types<br />Strength: Comprehensive treatment of enterprise architecture (EA)<br />Select best fitting ArchiMate diagram types<br />Strength:General EA visual modeling language with broad coverage of TOGAF, particularly in the 2.0 draft specification<br />Adapt viewpoints as necessary to express SABSA objectives<br />Create catalogs and matrices<br />Straightforward based on TOGAF 9 guidance<br />This presentation will instead focus on diagrams<br />Create ArchiMate diagrams based on selected TOGAF and ArchiMate viewpoints<br />14<br />Our Modeling Approach Leverages Strengths of Each Standard<br />July 17, 2011<br />
    21. 21. 15<br />The Top Two Rows of the SABSA Matrix Have Relevant Content<br />July 17, 2011<br />Explain RBAC<br />Justify RBAC<br />
    22. 22. Each Selected SABSA Matrix Cell Corresponds to Multiple TOGAF and ArchiMate Viewpoints<br />
    23. 23. 17<br />TOGAF Value Chain Diagram<br />Justify RBAC<br />Explain RBAC<br />RBAC resulted in $6 billion in US economic benefits from 2002-2009, according to 2010 economic analysis commissioned by US NIST, from which this diagram was adapted<br />
    24. 24. 18<br />Justify RBAC<br />ArchiMate Motivation Diagram<br />July 17, 2011<br />
    25. 25. 19<br />Justify RBAC<br />ArchiMate Actor Cooperation Diagram<br />July 17, 2011<br />
    26. 26. 20<br />Justify RBAC<br />ArchiMate Landscape Map<br />July 17, 2011<br />Enterprise <br />CRM Application<br />Mortgage Solution<br />Plan Admin <br />App<br />Policy Admin App<br />Hosted Advisor Work-bench <br />Hosted Vertical Industry Solution <br />Claims App A<br />Document Mgmt System B<br />Document Mgmt System A<br />
    27. 27. 21<br />TOGAF Solution Concept Diagram<br />July 17, 2011<br />Explain RBAC<br />
    28. 28. 22<br />ArchiMate Product Diagram<br />July 17, 2011<br />Justify RBAC<br />Explain RBAC<br />
    29. 29. 23<br />Review: RBAC Levels<br />July 17, 2011<br />
    30. 30. 24<br />Explain RBAC<br />ArchiMate Application Behavior View <br />July 17, 2011<br />
    31. 31. TOGAF, ArchiMate and SABSA each provide broad and deep value for enterprise architects, regardless of their specialty<br />Integrating these three paradigms today requires significant effort, since they cover much but not all of the same ground, often with similar but not strictly equivalent concepts<br />Fortunately, there are Open Group efforts underway to integrate<br />TOGAF and SABSA<br />The TOGAF and ArchiMate content frameworks<br />Architects can use RBAC to improve the effectiveness, scalability, transparency and agility of access control<br />Architects can use SABSA, TOGAF and ArchiMate <br />To model, portray and analyze planned or actual RBAC solutions<br />As a rigorous foundation for a wide range of stakeholder communications<br />25<br />Conclusion<br />July 17, 2011<br />
    32. 32. The NIST Model for Role-Based Access Control: Towards a Unified Standard <br />http://csrc.nist.gov/groups/SNS/rbac/documents/towards-std.pdf<br />ANSI INCITS 359-2004 Information Technology Role-Based Access Control<br />http://www.techstreet.com/standards/incits/359_2004?product_id=1151353<br />Sherwood Applied Business Security Architecture (SABSA) <br />http://www.sabsa.org/publications.aspx<br />Executive White Paper on Enterprise Security Architecture<br />Enterprise Security Architecture: A Business-Driven Approach <br />TOGAF 9 standard online<br />http://pubs.opengroup.org/architecture/togaf9-doc/arch<br />ArchiMate Version 1.0 standard online<br />http://www.opengroup.org/archimate/index.htm<br />Economic Benefits of Role-Based Access Control <br />http://csrc.nist.gov/groups/SNS/rbac/documents/20101219_RBAC2_Final_Report.pdf<br />Speaker contact:Iver.Band@standard.com<br />26<br />References<br />July 17, 2011<br />

    ×