1 / 24

Security Architecture and Analysis

Security Architecture and Analysis. Management of System Development and Implementation The System Development Process Issues and Risks Mitigation Strategies. Security Architecture Analysis: Course Roadmap. Lectures 1-3 (Linger)

jin
Download Presentation

Security Architecture and Analysis

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Security Architecture and Analysis • Management of System Development and Implementation • The System Development Process • Issues and Risks • Mitigation Strategies

  2. Security Architecture Analysis: Course Roadmap Lectures 1-3 (Linger) What: Methods for defining and reasoning about system architectures. Why: The architecture level is cost-effective and intellectually manageable for analysis and design of system security and survivability capabilities. Architecture Definition & Analysis Lecture 4-5 (Linger) What: Survivability analysis improves preservation of critical mission capabilities. Why: No amount of security can guarantee that systems will not be compromised; essential services and assets must be maintained. Survivable Network Analysis Lectures 8-9, 12-18, 21--22 (Longstaff) What: Analysis of vulnerabilities and methods for improving system security. Why: System security can be improved by a variety of techniques at the network, operating system, and application level. Security Architectures Lectures 27-28 (Linger) What: Technologies and processes for the development and testing life cycle. Why: Most security vulnerabilities are the result of poor development practices. From a security perspective, understanding how software was developed is as important as understanding what it does. Architecture Implementation & Validation Plus: Student team project in survivability analysis (Mead) Guest lectures on special topics

  3. The State-of-Art in Software Development • Nearly all software development projects exceed schedules and budgets, often by 100% or more • Most software development is ad hoc, craft-based • Most large-scale systems are never completed, collapsing under their own logical complexity • Most completed systems do not satisfy user needs • Most software problems are managerial, not technical

  4. Earlier Lessons • Requirements, specifications, and architecture are the places to get major decisions right • Security and survivability are two of several key architectural properties that must be considered together • Specify security and survivability functions up front and integrate them into the architecture; don’t try to add them on later • Treat intruders as users, specify their usage up front, and test for intrusion usage together with legitimate usage • Vulnerabilities can arise from poor software design, implementation, and testing

  5. The Software System Development Process Incremental Development Function specification Architecture Defn (COTS, legacy), Increment Plng Customer requirements Design and Verification Usage specification Deployment and operation Testing and Certification Project team Highly Incremental

  6. Function Specification • Translates informal functional requirements from users into a precise statement of what is to be developed • Will be used by developers as a “build to” specification and by testers as a “test oracle”

  7. Usage Specification • Translates informal usage requirements from users into a precise statement of how the system will be used (usage scenarios) • Will be used by developers as a check on functional capabilities they are developing • Will be used by testers to develop test cases (testing should emulate how the system will be used)

  8. Linger’s Law of Project Management “Half-way through a project, its better to have 50% of the system 100% complete (running) than to have 100% of the system 50% complete (not running)” • Nightmare scenario at project end 100% of a system is 90% complete (not running) Last 10% could take another 90% in effort • Key to success is incremental development

  9. Incremental Development • Never try to develop an entire system all at once, that is, in one cycle of development (build all components, put them together at end of project) • Instead, develop a system in increments that accumulate into the entire system and can be delivered to users for feedback and analysis • Each increment is a cycle of development • It is critical to divide a system into increments such that successive increments “plug in” to previous increments that are already running

  10. An Incremental Development Example Architecture Definition and Analysis Top-level Specifications System Requirements Customer/user Start Completed System Increment 1: top-level architecture implemented, one component reused, two stubs defined Increment 2: component changed from user feedback, stub replaced by new, reused and stub components Increment 3: stub replaced by new, reused, and stub components Increment 4: component changed from user feedback, final two stubs replaced by new and reused components Key: New Customer/user feedback Customer/user feedback Customer/user feedback Reused Stub Changed

  11. An IncrementalDevelopment Plan Requirements, function specification Increment planning Increment 1 Design/Verification Increment 2 Design/Verification Increment 3 Design/Verification Tasks Increment 4 Design/Verification Usage specification Increment Testing and Certification Incr 1statistics Incr 1-2 statistics Incr 1-3 statistics Incr 1-4 statistics Product Assessment and Process Improvement Time

  12. The “CityCorp” E-Commerce System • Develop: Prototype e-commerce system for Pittsburgh • Users: 500 merchants, 200,000 customers, 100 CityCorp personnel • Function: Present online catalogs and manage sales transactions • Architecture: Control center, network of servers and routers, Internet communications, security and authentication components • Your job: Manage development and implementation

  13. Requirements Objective • All system requirements are known, consistent, documented, and agreed to by the customer

  14. Requirements Risks and Mitigations?

  15. Architecture Objective • All major system components and their connections are defined, and required properties for security, survivability, performance, reliability, usability, etc., have gone through trade-off analysis and are satisfied

  16. Architecture Risks and Mitigations?

  17. Incremental Development Objective • Successive increments are defined that will plug into previous increments already running, and will accumulate into the final system

  18. Incremental Development Risks and Mitigations?

  19. CitiCorp Incremental Development Plan?

  20. Design Objective • Software is designed in conformance to the function specification and the architecture

  21. Design Risks and Mitigations?

  22. Project Team Objective • The team has the management, technical, and team operations capabilities to develop the required system

  23. Project Team Risks and Mitigations?

  24. The SEI Capability Maturity Model (CMM) • A defined software project management process • Five levels of process improvement • Essentially no technology content • A developer/vendor/supplier yardstick • Extensive commitment, investment, and adoption by user community

More Related