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

2. 2 Architecture Definition & Analysis Survivable Network Analysis Security Architectures Security Architecture Analysis: Course Roadmap Architecture Implementation & Validation 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. 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. 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. 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. Plus: Student team project in survivability analysis (Mead) Guest lectures on special topics

3. 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. 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. 5 The Software System Development Process Customer requirements Usage specification Architecture Defn (COTS, legacy), Increment Plng Design and Verification Testing and Certification Function specification Deployment and operation Incremental Development Highly Incremental Project team

6. 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. 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. 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. 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. 10 New Customer/user System Requirements Architecture Definition and Analysis Top-level Specifications 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 Customer/user feedback Customer/user feedback Customer/user feedback Stub Reused Changed Key: Completed System Start An Incremental Development Example

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

12. 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. 13 Requirements Objective All system requirements are known, consistent, documented, and agreed to by the customer

14. 14 Requirements Risks and Mitigations?

15. 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. 16 Architecture Risks and Mitigations?

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

18. 18 Incremental Development Risks and Mitigations?

19. 19 CitiCorp Incremental Development Plan?

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

21. 21 Design Risks and Mitigations?

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

23. 23 Project Team Risks and Mitigations?

24. 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