architecture definition & analysis survivable network analysis security architectures security...

ArchitectureDefinition &Analysis

SurvivableNetworkAnalysis

Security Architectures

Security Architecture and Analysis: Course Roadmap

Architecture DevelopmentManagement

Session 1 (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.

Session 2, 3a (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.

Sessions 4, 6, 7. 9, 11 (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.

Session 13 (Linger)What: Architecture development with COTS componentsWhy: Most security vulnerabilities are the result of poor system development and acquisition practices. From a security perspective, good practices and management methods are critically important.

Plus:• Student team project in survivability analysis (Mead)• Guest lectures on special topics• Student presentations

Security Architecture and Analysis: Session 2a

• Topics:

• Session 1 Review

• Architecture Life Cycle, Work Products, and Processes

Session 1 Review

REVIEW: Architecture Defined

An information system architecture

• is a specification for development of a system

• composed of hardware and software components and connectors

• whose external behavior satisfies the enterprise mission and business requirements

Enterprise mission andbusiness requirements

System architecture

System development

System operation

Validate Design

Validate

Design

REVIEW: Concepts of System Architectures

• Architectures are comprised of components and connectors:

• Components (Computation)Hardware:

Workstations, servers, mainframes, printers, sensors, actuators, …Software:

Operating systems, data base systems, middleware, browsers, applications, utilities, firewalls, ...

• Connectors (Communication)Hardware:

Communication links: routers, switches, public telephone network, leased lines, virtual private networks, …

Software:Communication protocols: TCP/IP, SNMP, HTTP, FTP …, Linkageconventions: procedure calls, remote procedure calls, thread initiation, ...

REVIEW: Concepts of System Architectures

Architecture properties:

• Functional propertiesMust satisfy domain-specific functional requirementsand specifications

• Non-functional properties (the “ilities”)Must satisfy performance, availability, reliability, safety, security, survivability, maintainability, usability, manageability, … properties

Architecture trade-offs:

• Properties can conflict

• Trade-offs seek optimal combinations of properties based on cost/benefit analysis

REVIEW: Architectural Styles

Example: A Bank ATM SystemStyle: Hierarchical, client server, layered

ATM ATM ATM ATM... ATM ATM ATM ATM... ATM ATM ATM ATM...

Server Server...

Mainframe

Server

Users

Users

Users

...

Presentation/User Interface Layer

Infrastructure/ CommunicationsLayer

Domain/Enterprise Logic/ Data Layer

PresentationBusiness Rules

Data Access

DBMS

Fat ClientTwo Tiers

Desktop:

Server(s):

PresentationBusiness Rules

Data AccessDBMS

Plump ClientTwo Tiers

Presentation

Thin ClientMulti-tier

Ultra-Thin ClientMulti-tier

Browser

Business RulesData Access

DBMS

Business RulesData Access

DBMS

REVIEW: Architectural Styles

Gartner’s Two-Tier and Multi-Tier Enterprise Architectures:

REVIEW: Architecture Impact of COTS Products

• Long historyStarted with environment support

Operating systems, data bases, language processors, …Moving up the food chain

Specialized applications, middleware, network services, ...

• Most architectures today are “assembled” from COTS productsDomain-specific vendorsBend business processes to match software capabilities“Glue code” ties incompatible products together

COTS characteristics:• Ties your system capability and evolution to vendors• Cost savings possible, but risks must be managed• Functionality and security are what vendor says they are

Actual capabilities may differ• Source code usually not available• Knowledge of quality and reliability difficult to acquire• Acceptance testing and configuration management are critical

REVIEW: An Architecture Framework

Architecture Best Practices:

Enterprise modeling and requirements specification

Application analysis and design

Data analysis and design

System integration

Network analysis and design

Incremental system development

Enabling Technologies:

Computing & comm. components

Microsoft technologies

JAVA technologies

Web technologies

XML technologies

Security technologies

Architecture patterns

Development methods and tools

Domain Architectures:

EAI architectures

E-commerce architectures

Directory architectures

System management architectures

Middleware architectures

Industry standard architectures

Client Environment:

Client relations, people, and culture

Enterprise architectures, business models, workflows, & legacy systems

Functional, non-functional, & usage requirements and constraints

Processes for Developing

Tools for Developing

Framework for Developing

Goals for Developing

Architecture Fundamentals:

Architecture role and life cycle

Architecture representation and reasoning

Architecture processes and work products

Architecture analysis and design

Architecture modeling and validation

Architecture patterns and properties

COTS evaluation and integration

Ability to Develop

Marketplace Environment:

Partners and alliances

COTS and component products

Service and consultation offerings

User groups and standards

Parts for Developing

System Environment: enterprise architecture, business models, system usage and evolution

External Behavior View (System Specification):

User tasks and workflows

Function and information

Stimulus/response behavior

Data and Software View (Logical Infrastructure):

Middleware and applications

Databases and storage systems

Operating systems

Hardware and Network View (Physical Infrastructure):

Computing hardware: servers, mainframes, PCs,mass storage, …

Networks, wired & wireless: media, devices, topology, protocols

System Requirements: function, and properties of reliability, performance, scalability, security, usability, cost, …

SYSTEM ARCHITECTURE

REVIEW: Box Structure Reasoning for Components

• Box Structures

A systematic model for component analysis and design

Five fundamental component characteristics: “BURST”

Boundary: What is inside and what is outside?Users: Who are the users?Responses: What is the set of possible responses? Stimuli: What is the set of possible stimuli?Transactions: What are the possible mappings from stimuli to

responses?

Three fundamental component representations:

Black box: Component behavior based on history of useState Box: Component behavior based on retained dataClear box: Component behavior based on procedure (another

course!)

• The example of black box behavior: A hand calculator

REVIEW: Box Structure Reasoning for Components: Black Boxes

• The black box of a component in diagram form

Stimulus (S) Response (R)

Stimulus Stimulus history Response

716 5 7165

716C 5 5

• Black box behavior depends on more than the current stimulus, it also depends on the history of use

Transition function of a black box description (stimulus history, stimulus) (response)

• Opens up a black box to reveal retained data; allows reasoning about the state

• Transition function of a state box description

(stimulus, current state) --> (response, new state)

REVIEW: Box Structure Reasoning for Components: State Boxes

• The state box of a component in diagram form

Stimulus (S) Response (R)

state

trans

REVIEW: Compositional Reasoning for Networks

A Bank ATM System


Server Server...

Mainframe

Server

Users

Users

...

Presentation/User Interface Layer

Infrastructure/ CommunicationsLayer

Domain/Enterprise Logic/ Data Layer


• What happens from viewpoint of ATM user submitting a transaction?

ATM Server Mainframe Server ATM

[User] o [ATM] o [server] o [mainframe] o [server] o [ATM] o [User]

“o” is composition operator“[, ]” denote the transition function of the componentNote that each use of a component is in the composition

• Component compositions are also known as architecture traces

• ATM Security: Composition with wrong pin number (U for user)

ATM Server ATM Server ATM Server ATM

Tryagain

wrongpin

Tryagain

wrongpin

Accessdenied

User User

U U U U U U U U


• Another pin number composition

ATM Server ATM Server ATM Server ATM

wrongpin

Tryagain

wrongpin

Tryagain

rightpin

Accessdenied

Server ATM

Accessgranted

wrongpin

• Compositional reasoning is concerned with the net effect of all the components in a composition

• Net effect means the overall change

From the stimuli to the first component

To the response from the last component

U U U U U U U U

U U U


When you buy gas at a pump with a speedpass, what is a possible architecture trace of your transaction?

? pumppumpUser User

Despite the fact that thousands of users may be accessing the system at the same time, the system is designed to maintain the compositional integrity of the architecture traces of all the users. It appears to you as though you are the only user.


• Many systems are designed to preserve composition and isolate asynchronous behavior• Bank system preserves independence of transactions based on account numbers • In general, systems are designed for compositional operations

A Bank ATM System


Server Server...

Mainframe

Server

Users

Users

...

Architecture Life Cycle, Work Products, and Processes

Architecture Fundamentals

Architecture Practices

Client Environment: enterprise arch. legacy systems initial requirements

Marketplace Environment

Domain Architectures

Enabling Technologies

INPUTS

Architecture Life Cycle: Inputs

• If it exists and is current– May define business models– May define IT infrastructure– May define evolutionary objectives– May provide guidance for architecture development

• If it exists and is not current– Opportunity to update– Guidance is suspect

Perspective

Know the status of enterprise architecture definition

Analyze existing enterprise architecture IT infrastructure

Evaluate requirements wrt existing infrastructure

Architecture Life Cycle: Inputs: Enterprise Architecture Def’n

• Legacy reuse and integration– Data, software, and networks involved– Potential major costs or savings – Impacts architecture, development, & deployment

• Many alternatives possible– Wrapping, rewriting, transforming, rehosting, …

• Decision making– Legacy systems are often difficult to modernize – Assessment of legacy capabilities is crucial – Business valuation of legacy assets

is crucial– New uses for old data– Business case, cost/benefit analysis

Perspective

Analyze legacy capabilities wrt client requirements

Understand evolution plans for legacy assets

Treat legacy integration on a par with new components

Architect for firm future uses of legacy elements

Architecture Life Cycle: Inputs: Legacy systems

• Often not fully known by client– Effective requirements discovery is essential– Enterprise and business models are the basis

• Functional requirements– User tasks and workflows– System services and transactions– Use cases are a popular method

• Usage requirements– User types and roles– Usage patterns and traffic levels

• Non-functional (property) requirements– Reliability, performance, scalability,

security, survivability, usability, cost, …

Perspective

Never architect against presumed requirements

Avoid late-life-cycle requirements surprises

Iterate requirements definition with clients

Involve all client roles and stakeholders

Treat requirements as an architecture entry condition

Develop prototypes to elicit requirements from clients

Establish requirements baselines to manage change and prevent scope creep

Architecture Life Cycle: Inputs: Initial Requirements

• Partners and alliances – Partnering can reduce costs and spread risk

• COTS products– Extensive, comprehensive capabilities available

– Vendor capability and track record can be issues – Product function and quality can be issues– Trend to standard, integrated solutions

• User groups and standards– Provide experience benchmark,

enable interoperability

Perspective

Capitalize on alliance strategies and agreements

Perform due diligence assessments of vendors

Evaluate function and quality of COTS products

Reconcile COTS capabilities with client requirements

Recognize COTS selections tie clients to supply chains

Capitalize on accepted standards, avoid others

Architecture Life Cycle: Inputs: Marketplace Environment

• EAI architectures – Data-, application-, portal-, process-oriented, …– XML, middleware, RPCs, message brokers, …– Packages: SAP, PeopleSoft, BizTalk, …

• E-commerce architectures– B2C, B2B, B2G, G2C…– Content, payments, orders, fulfillment, … – Security, trust, privacy, QoS…– Packages, ISPs, …

• Industry standard architectures

Perspective

Capitalize on applicable domain architectures

Maintain knowledge of evolving domain methods

Architecture Life Cycle: Inputs: Domain Architectures

• Computation & communication hardware– Processing power and bandwidth – Intel, Cisco, … – Hardware in continual evolution

• Integration environments– Applications, middleware, operating systems, … – Microsoft, Sun, Oracle, …– Environments in continual evolution

• Integration enablers– HTML, XML, security, … – Enablers in continual evolution

Perspective

Maintain knowledge of evolving technologies

Where possible, build on existing client environments

Recognize enabler selections tie clients to supply chains

Architect for component and environment evolution

Architecture Life Cycle: Inputs: Enabling Technologies







Final Requirements

Prototypes & Models

Architecture Design

Architecture Provisioning

Architecture Validation

Vendor Agreements

Development Plan

INPUTS WORK PRODUCTS

Architecture Life Cycle: Work Products

• Discovery and reconciliation– Requirements analysis with client– User experience with prototypes – User needs vs. product capabilities

• Requirements trade-offs– Optimal non-functional property mix – Functional trade-offs:

• Goal is no project impact – Customer understands trade-offs– Customer agrees to requirements baseline – Schedule and budget remain intact

Perspective

Challenge and confirm key requirements

Find any under-represented stakeholders

Review property trade-offs with client

The baseline plus controlled changes are the final reqs.

It doesn’t matter how well the wrong system is built

Cost

Benefit

High

High

Low

Low

No Go

Discuss Go

Discuss

Architecture Life Cycle: Work Products: Final Requirements

• Prototype goals– Requirements elicitation and finalization– Proof of concept

• Model goals– Simulation, prediction of system performance – Proof of concept

• Prototyping and Modeling– Key risk management strategies– Can be a phase in multi-phase project Perspective

Target prototypes to specific questions and objectives

Evolving prototypes into products can be very risky

Model results are only as good as model fidelity

Model results are only as good as model inputs

Match modeling effort to project stakes

Architecture Life Cycle: Work Products: Prototypes & Models

• Architecture is the integrating foundation of the project– A complete abstraction of the final system– Defers details without losing them– Development and usage become envisionable– Basis for reasoning, discussions, and decisions

• Satisfies client needs– Functional and non-functional requirements– Traceability of requirements into architecture is important

• Prescribes system development– Architecture should leave nothing out at

its level of abstraction– Development should refine, not

invent, architecture

Perspective

Get all the guidance, advice, and review you can find

Simple and straightforward solutions are best

Use what is known to work -- capitalize on similar projects

Architecture Life Cycle: Work Products: Architecture Design I

• Architecture defines– External behavior design (system specification)

• User tasks and workflows• Stimulus/response behavior

– Data and software design (logical infrastructure)• Retained state, application software, …• Middleware, operating systems, databases, …• Partitioning of function and data in an architectural style

– Hardware and network design (physical infrastructure)• Servers, mainframes, PCs, … • Media, devices, topology, protocols, …

– Non-functional properties• Property definitions • How properties are satisfied

– User skills and training

Architecture Life Cycle: Work Products: Architecture Design II

• Provide specifications for every component– Function– Usage – Non-functional properties

• Provide source for every component– As-is or modified legacy or COTS– As-is or modified partner product– Enabling environment or technology– New development– ISP, ASP, …– Various combinations

Perspective

Select sources based on component specifications

Satisfy cost objectives

Define level of effort for component provisioning

Carefully weigh benefits of buy vs. build

Develop components as a last resort

Architecture Life Cycle: Work Products: Provisioning

• Validate architecture functionality– Every required user function must be present– All functions must operate harmoniously

• Validate non-functional properties– Every required property must be satisfied– All properties must co-exist harmoniously

• Validation processes– Verify “as-designed” against “as-specified”– Many methods may be employed– Team inspections are a key technique

Perspective

Treat validation as a distinct task

Apply validation entry and exit conditions

Ensure artifacts are in shape for validation

Validate conformance of artifacts to specifications

Document evidence for conformance

Iterate validation and rework until artifacts pass

Use validation defect rates to manage quality

Architecture Life Cycle: Work Products: Validation

• Architecture is a driver of vendor agreements– Incorporates vendor components– Basis for development plan– Defines component deliverables

• Provisioning strategies• Requirements and specifications

– Defines service deliverables • Scope and QoS• Staffing and skills

Perspective

Define deliverables for vendor agreements

Perform due diligence on vendor capabilities

Define checkpoints for assessing vendor progress

Define testable acceptance criteria for deliverables

Define implications of acceptance failure

Manage risk with plan B for critical components

Architecture Life Cycle: Work Products: Vendor Agreements

• Defines development environment– Enabling technologies– Development and testing processes

• Defines development steps– Incremental development is essential– Stepwise completion of system parts– Client feedback from early increments– Tasks and schedules

Perspective

Define environment early to drive staffing and training

Define steps so that system accumulates into final form

Be prepared for development feedback to architecture

Evaluate early increments wrt required properties

Architecture Life Cycle: Work Products: Development Plan







Final Requirements

Prototypes & Models

Architecture Design



Vendor Agreements

Development Plan

INPUTS WORK PRODUCTSITERATIVE ARCHITECTURE DEVELOPMENT

Ent. Arch., Legacy, Reqs., Market, Domain, Enablers

Env. and Steps

Analysis

Devel. Planning Schedule

Mgmt. PlanPlanning

(Architecture Development)

Architecture Life Cycle: Arch. Development

• Embedded within project schedule– Supports project dependencies

• Entry conditions (rarely satisfied) – Stable and complete requirements– Availability of appropriate staff and resources

• Exit condition– Architecture work products are complete and validated

Perspective

Failure to meet schedule is a non-starter

Surface schedule-impacting problems early

Work at level of abstraction compatible with schedule

Architecture Life Cycle: Arch. Development: Schedule

• Defines work products– Project-specific architecture artifacts

• Defines tasks– Activities that will produce the work products

• Defines internal schedules and resources– Task sequencing and resource allocation

• Defines risks and mitigations– Key risks and uncertainties– Actions for recognition and control

Perspective

Plan is a sequencing of tasks plus risk management

Define tasks to accumulate into work products

Use the plan to manage the architecture work

Track actual vs. predicted performance

Discovery/experimentation tasks can reduce risk

Architecture Life Cycle: Arch. Development: Management Plan

• Understand the client and resources– Client problem

• Enterprise architecture and business models• Legacy systems• Requirements• From present operations to envisioned future operations

– Potential resources• Marketplace offerings• Domain architectures• Enabling technologies

• A project-long activity– May require experimentation, training– Document understandings for decision-making

Perspective

Never stop learning about the problem and resources

Architecture Life Cycle: Arch. Development: Analysis

• Define development environment• Define development and testing steps

Perspective

Consult with developers to arrive at a consensus plan

Consult with customers on staging of deliverables

Architecture Life Cycle: Arch. Development: Development Planning







Final Requirements

Prototypes & Models

Architecture Design



Vendor Agreements

Development Plan

INPUTS WORK PRODUCTSITERATIVE ARCHITECTURE DEVELOPMENT

External Behavior

Data & Software

Hardware & Network

Design RefineRefine

RefineDesign

Design

Ent. Arch., Legacy, Reqs., Market, Domain, Enablers

Env. and Steps

Validation Checkpoint

Analysis

Inspection

…

Devel. Planning

Iterations

Schedule

Mgmt. PlanPlanning

Architecture Life Cycle: Arch. Development: Design Activities

• External behavior design maps requirements into specifications• External behavior design plus network traffic, etc., drives data

and software design• Data and software design plus network traffic, geography, etc.,

drives hardware and network design• Non-functional requirements drive everything• System evolution requirements drive everything

Perspective

Refinement process allows divide, connect, and conquer strategy

Refinement helps maintain intellectual control

Refinements can be verified wrt their specifications

Can’t design the top without knowing the bottom

Last intellectual pass is top down

Architecture Life Cycle: Arch. Development: The Refinement Process

• The first idea is rarely the best idea• Iteration drives evaluation and improvement• Iteration permits systematic convergence to a solution• Iteration has desirable properties similar to requirements

change control• Iterations document design decisions

Perspective

Use iteration to achieve informed agreement

Use iteration to uncover gaps and misunderstandings

Continually challenge assumptions and decisions

Architecture Life Cycle: Arch: Development: The Iteration Process

architecture definition & analysis survivable network analysis security architectures security...

Documents