Download 2a Sept 5 - Andrew.cmu.edu

Security Architecture and Analysis: Course Roadmap
Architecture
Definition &
Analysis
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.
Survivable
Network
Analysis
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.
Security
Architectures
Architecture
Development
Management
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 components
Why: 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 and
business requirements
Design
System
operation
Validate
Design
System
architecture
System
development
Validate
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 …, Linkage
conventions: procedure calls, remote procedure calls, thread
initiation, ...
REVIEW: Concepts of System Architectures
Architecture properties:
• Functional properties
Must satisfy domain-specific functional requirements
and 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 System
Style: Hierarchical, client server, layered
Domain/Enterprise
Logic/ Data Layer
Users
U
s
e
r
s
Mainframe
...
Infrastructure/
Communications
Layer
Presentation/
User Interface
Layer
ATM
Server
ATM
ATM ... ATM
Server
ATM
ATM
ATM ... ATM
Users
...
Server
ATM
ATM
ATM ... ATM
REVIEW: Architectural Styles
Gartner’s Two-Tier and Multi-Tier Enterprise Architectures:
Fat Client
Two Tiers
Desktop:
Presentation
Business Rules
Data Access
Server(s):
DBMS
Plump Client
Two Tiers
Presentation
Business Rules
Data Access
DBMS
Thin Client
Multi-tier
Presentation
Ultra-Thin Client
Multi-tier
Browser
Business Rules
Data Access
Business Rules
Data Access
DBMS
DBMS
REVIEW: Architecture Impact of COTS Products
• Long history
Started 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 products
Domain-specific vendors
Bend 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
SYSTEM ARCHITECTURE
Architecture Fundamentals:
System Environment: enterprise architecture,
business models, system usage and evolution
Architecture role and life cycle
Architecture representation and
reasoning
Architecture processes and work
products
Ability to
Develop
Marketplace Environment:
Parts for
Developing
COTS and component products
System Requirements: function, and
properties of reliability, performance,
scalability, security, usability, cost, …
Service and consultation offerings
User groups and standards
External Behavior View (System
Specification):
Architecture analysis and design
Architecture modeling and validation
Domain Architectures:
User tasks and workflows
Architecture patterns and properties
Function and information
COTS evaluation and integration
Stimulus/response behavior
Framework for EAI architectures
Developing
E-commerce architectures
Directory architectures
Architecture Best Practices:
Enterprise modeling and
requirements specification
Application analysis and design
System management architectures
Processes for
Developing
Data and Software View (Logical
Infrastructure):
Middleware architectures
Middleware and applications
Industry standard architectures
Data analysis and design
Databases and storage systems
System integration
Operating systems
Enabling Technologies:
Computing & comm. components
Network analysis and design
Incremental system development
Client Environment:
Client relations, people, and culture
Enterprise architectures, business
models, workflows, & legacy systems
Functional, non-functional, & usage
requirements and constraints
Partners and alliances
Hardware and Network View
(Physical Infrastructure):
Goals for
Developing
Tools for
Developing
Microsoft technologies
JAVA technologies
Computing hardware: servers,
mainframes, PCs,mass storage, …
Web technologies
Networks, wired & wireless: media,
devices, topology, protocols
Security technologies
XML technologies
Architecture patterns
Development methods and tools
REVIEW: Box Structure Reasoning for Components
• Box Structures
A systematic model for component analysis and design
Five fundamental component characteristics: “BURST”
Boundary:
Users:
Responses:
Stimuli:
Transactions:
What is inside and what is outside?
Who are the users?
What is the set of possible responses?
What is the set of possible stimuli?
What are the possible mappings from stimuli to
responses?
Three fundamental component representations:
Black box:
State Box:
Clear box:
Component behavior based on history of use
Component behavior based on retained data
Component behavior based on procedure (another
course!)
REVIEW: Box Structure Reasoning for Components: Black Boxes
• The black box of a component in diagram form
Stimulus (S)
Response (R)
• The example of black box behavior: A hand calculator
Stimulus history
Stimulus
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)
REVIEW: Box Structure Reasoning for Components: State Boxes
• The state box of a component in diagram form
state
Stimulus (S)
trans
Response (R)
• 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: Compositional Reasoning for Networks
A Bank ATM System
Domain/Enterprise
Logic/ Data Layer
Users
Mainframe
...
Infrastructure/
Communications
Layer
Presentation/
User Interface
Layer
ATM
Server
ATM
ATM ... ATM
Server
ATM
ATM
ATM ... ATM
Users
...
Server
ATM
ATM
ATM ... ATM
REVIEW: Compositional Reasoning for Networks
• What happens from viewpoint of ATM user submitting a transaction?
User
ATM
Server
Mainframe
Server
ATM
User
[User] o [ATM] o [server] o [mainframe] o [server] o [ATM] o [User]
“o” is composition operator
“[, ]” denote the transition function of the component
Note 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)
U
ATM
U
Server
U
Try
again
ATM U
wrong
pin
Server
U
Try
again
ATM U
wrong
pin
Server
U
ATM
Access
denied
U
REVIEW: Compositional Reasoning for Networks
• Another pin number composition
U
Server
right
pin
U ATM U
wrong
pin
Server
U
Try
again
ATM U
wrong
pin
Server
U
Try
again
ATM U
wrong
pin
U
ATM U
Access
granted
Server
U
ATM U
Access
denied
• 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
REVIEW: Compositional Reasoning for Networks
When you buy gas at a pump with a speedpass, what is a possible
architecture trace of your transaction?
User
pump
?
pump
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.
REVIEW: Compositional Reasoning for Networks
A Bank ATM System
Users
Mainframe
...
Server
ATM
ATM
ATM ... ATM
Server
ATM
ATM
ATM ... ATM
...
Server
ATM
ATM
ATM ... ATM
Users
• 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
Architecture Life Cycle, Work Products,
and Processes
Architecture Life Cycle: Inputs
INPUTS
Architecture
Fundamentals
Architecture
Practices
Client
Environment:
enterprise arch.
legacy systems
initial requirements
Marketplace
Environment
Domain
Architectures
Enabling
Technologies
Architecture Life Cycle: Inputs: Enterprise Architecture Def’n
• 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: Legacy systems
• 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
Perspective
is crucial
Analyze legacy capabilities
wrt client requirements
– New uses for old data
Understand evolution plans
for legacy assets
– Business case, cost/benefit analysis
Treat legacy integration on a
par with new components
Architect for firm future uses
of legacy elements
Architecture Life Cycle: Inputs: Initial Requirements
• Often not fully known by client
– Effective requirements discovery is essential
– Enterprise and business models are the basis
• Functional requirements
– User tasks and workflows
Perspective
– System services and transactions
Never architect against
presumed requirements
– Use cases are a popular method
Avoid late-life-cycle
• Usage requirements
requirements surprises
Iterate requirements
– User types and roles
definition with clients
– Usage patterns and traffic levels
Involve all client roles and
stakeholders
• Non-functional (property) requirements
Treat requirements as an
architecture entry condition
– Reliability, performance, scalability,
Develop prototypes to elicit
security, survivability, usability, cost, …
requirements from clients
Establish requirements
baselines to manage change
and prevent scope creep
Architecture Life Cycle: Inputs: Marketplace Environment
• 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
Perspective
• User groups and standards
Capitalize on alliance
strategies and agreements
– Provide experience benchmark,
Perform due diligence
enable interoperability
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: Domain Architectures
• 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: Enabling Technologies
• 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, …
Perspective
Maintain knowledge of
– Enablers in continual evolution
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: Work Products
INPUTS
Architecture
Fundamentals
Architecture
Practices
Client
Environment:
enterprise arch.
legacy systems
initial requirements
Marketplace
Environment
Domain
Architectures
Enabling
Technologies
WORK PRODUCTS
Final
Requirements
Prototypes &
Models
Architecture
Design
Architecture
Provisioning
Architecture
Validation
Vendor
Agreements
Development
Plan
Architecture Life Cycle: Work Products: Final Requirements
• 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:
Benefit
Low
High
Cost
High
No Go Discuss
Low Discuss
Go
• 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
Architecture Life Cycle: Work Products: Prototypes & Models
• 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: Architecture Design I
• 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
Perspective
– Development should refine, not
Get all the guidance, advice,
and review you can find
invent, architecture
Simple and straightforward
solutions are best
Use what is known to work -capitalize on similar projects
Architecture Life Cycle: Work Products: Architecture Design II
• 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: Provisioning
• 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: Validation
• 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
Perspective
• Validation processes
Treat validation as a distinct
– Verify “as-designed” against “as-specified” task
Apply validation entry and
exit conditions
– Many methods may be employed
Ensure artifacts are in shape
– Team inspections are a key technique
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: Vendor Agreements
• 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: Development Plan
• 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: Arch. Development
INPUTS
ITERATIVE ARCHITECTURE DEVELOPMENT
Architecture
Fundamentals
Planning
Architecture
Practices
Analysis
Mgmt. Plan
Ent. Arch., Legacy, Reqs., Market, Domain, Enablers
Final
Requirements
Prototypes &
Models
Client
Environment:
Architecture
Design
enterprise arch.
legacy systems
initial requirements
(Architecture Development)
Marketplace
Environment
Architecture
Provisioning
Architecture
Validation
Domain
Architectures
Enabling
Technologies
WORK PRODUCTS
Vendor
Agreements
Devel.
Planning
Env. and Steps
Schedule
Development
Plan
Architecture Life Cycle: Arch. Development: Schedule
• 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: Management Plan
• 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: Analysis
• 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: Development Planning
• 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: Design Activities
INPUTS
ITERATIVE ARCHITECTURE DEVELOPMENT
Architecture
Fundamentals
Planning
Architecture
Practices
Analysis
Client
Environment:
enterprise arch.
legacy systems
initial requirements
Marketplace
Environment
Domain
Architectures
Enabling
Technologies
Mgmt. Plan
Ent. Arch., Legacy, Reqs., Market, Domain, Enablers
External
Behavior
Design Refine Refine
Data &
Software
Design
Hardware
& Network
Validation
Checkpoint
Devel.
Planning
WORK PRODUCTS
Iterations
Prototypes &
Models
Architecture
Design
Refine
Design
Final
Requirements
…
Inspection
Architecture
Provisioning
Architecture
Validation
Vendor
Agreements
Env. and Steps
Schedule
Development
Plan
Architecture Life Cycle: Arch. Development: The Refinement Process
• 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 Iteration 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