Copyright © The OWASP Foundation Permission is granted to copy, distribute and/or modify this document under the terms of the OWASP License. The OWASP Foundation OWASP A Practical Security Architecture Framework Elliott Glazer Director, Security Architecture Depository Trust and Clearing Corporation

OWASP 2 Agenda  Architecture Layers and Key Processes  The Functional Architecture  The Technical Architecture and Overlays  Security Technology Lifecycle

OWASP 3 Information Security Architecture Layers and Key Processes  Information Security Architecture is driven by an Information Security Strategy and Principles. It is also critical the architecture support the Business Strategy:  Security Functional Architecture: the layout of key functions in security to be accomplished, which drives security requirements.  Security Technical Architecture: the solutions and standards to implement key functions, usually an overlay on top of the Functional Architecture. This is generally a definition of components, intended to be leveraged for reuse by organization, business, line of business or across the enterprise.  Security Reference Architecture: the implementation of Technical Architecture components into a strategy, platform, or particular complex solution set, to be used as a model for other, like needs. This is usually a set of components organized together.  Security Technology Lifecycle – the process of phasing in and out, technology and process solutions that improve the security environment. Six phases ranging from researching new solutions to exiting old and failing solutions are defined.  Security Program Implementation Planning – the process of identifying high level scheduling based on priority and available resources, for solutions defined in the Technical Architecture. Priority is generally established based on risk. The program also helps in the planning cycles for budgeting, as it will try to take a multiyear view. 2

OWASP 4 Information Security Architecture Processes Information Security Technical Architecture Information Security Functional Architecture Standards Rollout Process Security Technology Life Cycle Program Implementation Planning Process Security Program Process Security Baseline Configuration Management Technology Evaluation Process Exception Process Validate Progress Security Component Sponsorship Process Application Development Security Processes Reference Architecture Management Process 3

OWASP 5 Agenda  Architecture Layers and Key Processes  The Functional Architecture  The Technical Architecture and Overlays  Security Technology Lifecycle

OWASP 6 Information Security Functional Architecture AuthenticationAuthorization Access Controls Identity Management Confidentiality Logging and Event Management Threat and Vulnerability Management EducationOthers Functional Architecture defines the framework and scope of security required There are more functions than these. This is illustrative. 4

OWASP 7 Information Security Functional Architecture AuthenticationAuthorization Access Controls Identity Management Confidentiality Logging and Event Management Threat and Vulnerability Management EducationOthers The Functional Architecture often needs to be broken down into particular solutions, which overlay the highest level Functional layer. Single Factor Dual Factor Risk Based Mutual Authen The Technical Architecture builds on the Functional Architecture. 5

OWASP 8 Security Functions  Authentication  Authorization  Identity Management  Access Control  Confidentiality / Integrity / Encryption  Administration and Servicing  Business Continuation Planning  Disaster Recovery  Configuration Management  Change Management  Asset Management  Risk Management  Logging/Auditing/Tracing  Security Monitoring  Threat and Vulnerability Assessment  Education  Communication and Reporting  Compliance and Governance  Policy Management  Security Project Management This is the current list of security functions that must be covered to ensure good Information Security: 6

OWASP 9 Agenda  Architecture Layers and Key Processes  The Functional Architecture  The Technical Architecture and Overlays  Security Technology Lifecycle

OWASP 10 Security Environments  In addition, the Technical Architecture must account for each of the following environments:  Application Development  Solutions built by employees  Solutions built offshore  Solutions built by vendors as systems  Solutions built by vendors as services  Infrastructure  Internal requirements  External requirements  Vendor requirements

OWASP 11 Information Security Technical Architecture View  The Technical Architecture must account for the different technology environments required by the business solutions. This often translates into a platform centric view based on the operating system and hardware used for business solutions.  The information security technical architecture is designed to:  Identify point of departure (existing solutions) being used today  Identify point of next (where do we want to be and by when) for solutions to be used  Identify gaps in current solution sets  Provide solutions in products, in-house developed solutions, processes 8

OWASP 12 Analysis View FunctionSub FunctionUnixMainframeVMSAS400WindowsLAN or Network Remote Access Authentication Authorization ID Management Access Control Integrity/ Confidentiality/ Encryption Administration and Servicing Business Continuation Planning Disaster Recovery Configuration Management Change Management Asset Management Risk Management Logging/ Auditing/ Tracing Security Monitoring Threat and Vulnerability Assessment Education Communication and Reporting Compliance and Governance Policy Management Security Project Management This view provides definition of what solutions are being used for each sub function, on each critical platform or environment. There usually are at least 2 views: - The Point of Departure – describes what solutions are standard or in place at this moment in time. - The Point of Next – is usually set to a 12 month window and is the vision of where things will be at the end of that time period. -The Point of Arrival – sometimes the POA is used and coincides with the long term vision for the Security Program. As that vision changes, so does the POA. 9

OWASP 13 Information Security Program Implementation View  The Program Implementation View is designed to:  Organize work efforts to close security gaps into cohesive release plans  Ensure communication of security needs, gaps and the timeframes solutions are needed within  Help with annual budget planning  Ensure communication of security priorities 10

OWASP 14 Analysis View FunctionSub Function1H082H081H092H091H102H10Gaps Authentication Authorization ID Management Access Control Integrity/ Confidentiality/ Encryption Administration and Servicing Business Continuation Planning Disaster Recovery Configuration Management Change Management Asset Management Risk Management Logging/ Auditing/ Tracing Security Monitoring Threat and Vulnerability Assessment Education Communication and Reporting Compliance and Governance Policy Management Security Project Management This view is oriented to timing of when an objective is to be met or a gap filled. Each box identifies the specific goal to be accomplished by that time. 11

OWASP 15 Agenda  Architecture Layers and Key Processes  The Functional (Application) Architecture  The Technical Architecture and Overlays  Security Technology Lifecycle

OWASP 16 Information Security Technology Life Cycle  The Technology Life Cycle is designed to:  ensure a structured method is used to evaluate solutions  ensure a structured method is used to prepare rollout of solutions  ensure standardization of solutions across the enterprise  ensure easy determination of tools to use and how  ensure old tools are eliminated from the environment  There are 6 classifications used for this:  R+D  PreInvest  Invest  Maintain  DisInvest  Exit 12

OWASP 17 Analysis View This is the same overlay as all the other Technical Architecture views and comes directly from the Functional Architecture This is the same overlay as all the other Technical Architecture views and comes directly from the Functional Architecture. This category is filled with products that should be in a Tech Evaluation Process. This category generally leads to products moving to INVEST, and drives the overall uplift process of solutions. Products determined to be ready for INVEST must be aligned with Development and Operational groups in terms of their readiness to absorb Products in this category have been determined appropriate for company usage, and are being readied by Development and Operational groups for rollout and productization. Education, training, security configurations, establishment of any controls and governance needs occur during this time period. Generally products will be in this category for 3 months, to complete this cycle, but it will vary based on the complexity of the rollout. Project Plans may be required to complete such rollouts, and at a minimum, a checklist is reviewed to ensure all items have been completed, which includes at a minimum, the above These solutions are the core solutiosn for the enterprise. Items found in this category are meant to be the standard solutions for the enterprise. If there is no solution that matches the functional needs in this category, look to the Maintain category for the solution These products continue to meet the needs of the enterprise, and may continue to be used. Products in this space however, may soon be replaced by other solutions, so users should be aware these may change soon, which means they may move to DISINVEST. The decision to move to DISINVEST will be made with senior leadership such as the CISO and CIO or a Security Committee. Solutions in Invest have priority and should be used as the primary solution, before using these solutions. If a service or application is already using these Maintain solutions, it is not intended to drive migration to any INVEST solution however. Maintain solutions are good, valuable solutions, worthy of continued investment. Convergence and simplification strategies however, may show that INVEST solutions will take preference over these, over time These products have been determined not to be effective anymore and should be replaced. A product in this space should be migrated from within 18 – 24 months of first being determined in this space. All users and usage should be migrated within this time. Security standards must be updated during this time to reflect any changes also. After this time expires, a decision will be made to push these solutions into EXIT by senior leadership such as the CISO and CIO or a Security Committee. Exceptions are required to expand or continue to invest in these solutions, as migration should be occurring, not additional spend on these solutions These products are out of compliance. No exceptions are allowed for them. They should be gone already. They create significant security risks if they remain. Any such products or groups using such products are reported to both senior leadership and Audit FunctionSub Function R+DPre InvestInvestMaintainDisInvestExit 13

OWASP 18 Questions?