1

Security Architecture and Analysis

• Management of System Development and Implementation – The System Development Process– Issues and Risks– Mitigation Strategies

2

ArchitectureDefinition &Analysis

SurvivableNetworkAnalysis

Security Architectures

Security Architecture Analysis: Course Roadmap

ArchitectureImplementation& 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

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

Customerrequirements

Usagespecification

Architecture Defn(COTS, legacy), Increment Plng

Design andVerification

Testing and Certification

Functionspecification

Deployment and operation

Incremental Development

Highly Incremental Project team

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

New

Customer/user

SystemRequirements

ArchitectureDefinition 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/userfeedback

Customer/userfeedback

Customer/userfeedback

Stub

Reused

Changed

Key:

Completed System

Start

An Incremental Development Example

11

Increment 1Design/Verification

Increment 3Design/Verification

Increment 4Design/Verification

Requirements, function specification

Usage specification

Tasks

Time

Increment Testing and Certification

Incr 1statistics

Increment planning

Increment 2Design/Verification

Incr 1-2 statistics Incr 1-3 statistics Incr 1-4 statistics

Product Assessment and Process Improvement

An IncrementalDevelopment Plan

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