- 1. Architecture Definition & Analysis Survivable Network
Analysis SecurityArchitectures Security Architecture and
Analysis:Course Roadmap ArchitectureDevelopment Management 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 components Why:
Most security vulnerabilities are the result of poor system
development and acquisition practices.From a security perspective,
good practices and management methods arecritically important.
- Student team project in survivability analysis (Mead)
- Guest lectures on special topics
2.
- Security Architecture and Analysis:Session 2a
- Architecture Life Cycle, Work Products, and Processes
3. Session 1 Review 4. REVIEW: Architecture Defined
- An information system architecture
- is aspecificationfordevelopmentof a system
- composed ofhardwareandsoftware componentsandconnectors
- whoseexternal behaviorsatisfies theenterprise missionand
Enterprise mission and business requirements Systemarchitecture
Systemdevelopment Systemoperation Validate Design Validate Design
5. REVIEW: Concepts of System Architectures
- Architectures are comprised of components and connectors:
- Workstations, servers, mainframes, printers, sensors,
actuators,
- Operating systems, data base systems, middleware,
-
-
- browsers, applications, utilities, firewalls, ...
- Connectors(Communication)
-
- Communication links: routers, switches, public telephone
-
- network, leased lines, virtual private networks,
-
- Communication protocols: TCP/IP, SNMP, HTTP, FTP , Linkage
-
- conventions: procedure calls, remote procedure calls,
thread
6. REVIEW: Concepts of System Architectures
-
-
- Must satisfy domain-specific functional requirements
-
- Non-functional properties (the ilities)
-
-
- Must satisfy performance, availability, reliability, safety,
security, survivability, maintainability, usability, manageability,
properties
-
- Trade-offs seek optimal combinations of properties
-
- based on cost/benefit analysis
7. REVIEW: Architectural Styles Example: A Bank ATM System
Style: 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/ Communications LayerDomain/Enterprise Logic/ Data
Layer 8. Presentation Business Rules Data Access DBMS Fat Client
Two Tiers Desktop: Server(s): Presentation Business Rules Data
Access DBMS Plump Client Two Tiers Presentation Thin Client
Multi-tier Ultra-Thin Client Multi-tier Browser Business Rules Data
Access DBMS Business Rules Data Access DBMS REVIEW: Architectural
Styles Gartners Two-Tier and Multi-Tier Enterprise Architectures:
9. REVIEW: Architecture Impact of COTS Products
-
- Started with environment support
-
-
- Operating systems, data bases, language processors,
-
- Specialized applications, middleware, network services,
...
- Most architectures today are assembled from COTS products
-
- Bend business processes to match software capabilities
-
- Glue code ties incompatible products together
-
- 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
10. 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, &
usagerequirements 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 validationArchitecture patterns and properties COTS
evaluation and integrationAbility to Develop Marketplace
Environment: Partners and alliancesCOTS 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
systemsOperating systemsHardware and Network View(Physical
Infrastructure): Computing hardware: servers, mainframes, PCs,mass
storage, Networks, wired & wireless: media, devices, topology,
protocolsSystem Requirements:function, and properties of
reliability, performance, scalability, security, usability, cost,
SYSTEM ARCHITECTURE 11. REVIEW: Box Structure Reasoning for
Components
-
- 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
toresponses?
-
- Three fundamental component representations:
-
-
- Black box: Component behavior based on history of use
-
-
- State Box: Component behavior based on retained data
-
-
- Clear box: Component behavior based on procedure
(anothercourse!)
12.
- The example ofblack 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 thehistory of use
- Transition functionof a black box description
- (stimulus history, stimulus)(response)
13.
- Opens up a black box to reveal retained data; allows reasoning
about
- Transition functionof 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 14. REVIEW: Compositional
Reasoning for Networks A Bank ATM System ATM ATM ATM ATM ... ATM
ATM ATM ATM ... ATM ATM ATM ATM ... Server Server ... Mainframe
Server Users Users ... Presentation/User Interface Layer
Infrastructure/ Communications LayerDomain/Enterprise Logic/ Data
Layer 15. REVIEW: Compositional Reasoning for Networks
- 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 component
-
-
- Note that eachuse of a componentis in the composition
- Component compositions are also known asarchitecture
traces
- ATM Security: Composition with wrong pin number (U for
user)
ATM Server ATM Server ATM Server ATM Try again wrong pin Try
again wrong pin Access denied User User U U U U U U U U 16. REVIEW:
Compositional Reasoning for Networks
- Another pin number composition
ATM Server ATM Server ATM Server ATM wrong pin Try again wrong
pin Try again right pin Access denied Server ATM Access granted
wrong pin
- Compositional reasoning is concerned with thenet effectof
- 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 17. REVIEW: Compositional Reasoning for
Networks When you buy gas at a pump with a speedpass, what is a
possible architecture trace of your transaction? ? pump pump User
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. 18.
REVIEW: Compositional Reasoning for Networks
- Many systems are designed to preserve composition and
isolate
- Bank system preserves independence of transactions based
on
- In general, systems are designed for compositional
operations
A Bank ATM System ATM ATM ATM ATM ... ATM ATM ATM ATM ... ATM
ATM ATM ATM ... Server Server ... Mainframe Server Users Users ...
19. Architecture Life Cycle, Work Products,and Processes 20.
Architecture FundamentalsArchitecture Practices Client
Environment:enterprise arch. legacy systems initial requirements
Marketplace Environment Domain Architectures Enabling Technologies
INPUTS Architecture Life Cycle: Inputs 21.
- 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
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 Defn
22.
- 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,
-
- Legacy systems are often difficult to modernize
-
- Assessment of legacy capabilities is crucial
-
- Business valuation of legacy assets
-
- 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 forfirm future
usesof legacy elementsArchitecture Life Cycle: Inputs: Legacy
systems 23.
- Often not fully known by client
-
- Effective requirements discovery is essential
-
- Enterprise and business models are the basis
-
- System services and transactions
-
- Use cases are a popular method
-
- Usage patterns and traffic levels
- Non-functional(property) requirements
-
- Reliability, performance, scalability,
-
- security, survivability, usability, cost,
Perspective Never architect against presumed requirementsAvoid
late-life-cycle requirements surprises Iterate requirements
definition with clients Involve all client roles andstakeholders
Treat requirements as an architecture entry condition Develop
prototypes to elicit requirements from clients
Establishrequirements baselinesto manage change andprevent scope
creep Architecture Life Cycle: Inputs: Initial Requirements 24.
-
- Partnering can reduce costs and spread risk
-
- Extensive, comprehensive capabilities available
-
- Vendor capability and track record can be issues
-
- Product function and quality can beissues
-
- Trend to standard, integrated solutions
- User groups and standards
-
- Provide experience benchmark,
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 othersArchitecture Life
Cycle: Inputs: Marketplace Environment 25.
-
- Data-, application-, portal-, process-oriented,
-
- XML, middleware, RPCs, message brokers,
-
- Packages: SAP, PeopleSoft, BizTalk,
-
- Content, payments, orders, fulfillment,
-
- Security, trust, privacy, QoS
- Industry standard architectures
Perspective Capitalize on applicable domain architectures
Maintain knowledge ofevolving domain methods Architecture Life
Cycle: Inputs: Domain Architectures 26.
- Computation & communication hardware
-
- Processing power and bandwidth
-
- Hardware in continual evolution
-
- Applications, middleware, operating systems,
-
- Environments in continual evolution
-
- Enablers in continual evolution
Perspective Maintain knowledge ofevolving technologies Where
possible, build on existing client environments Recognize enabler
selections tie clients to supply chainsArchitect for component and
environment evolution Architecture Life Cycle: Inputs: Enabling
Technologies 27. Architecture FundamentalsArchitecture Practices
Client Environment:enterprise arch. legacy systems initial
requirements Marketplace Environment Domain Architectures Enabling
Technologies Final RequirementsPrototypes & Models Architecture
Design Architecture ProvisioningArchitecture Validation
VendorAgreementsDevelopment Plan INPUTS WORK PRODUCTS Architecture
Life Cycle: Work Products 28.
- Discovery and reconciliation
-
- Requirements analysis with client
-
- User experience with prototypes
-
- User needs vs. product capabilities
-
- Optimal non-functional property mix
- 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
doesnt 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 29.
-
- Requirements elicitation and finalization
-
- Simulation, prediction of system performance
-
- 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 inputsMatch modeling effort to project stakes
Architecture Life Cycle: Work Products: Prototypes & Models
30.
- 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
-
- Functional and non-functional requirements
-
- Traceability of requirements into architecture is
important
- Prescribes system development
-
- Architecture should leave nothing out at
-
- Development should refine, not
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 31.
-
- External behavior design (system specification)
-
-
- 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
-
-
- How properties are satisfied
Architecture Life Cycle: Work Products: Architecture Design II
32.
- Provide specifications for every component
-
- 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
Perspective Select sources based on component
specificationsSatisfy 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 33.
- 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
-
- 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 34.
- Architecture is a driver of vendor agreements
-
- Incorporates vendor components
-
- Basis for development plan
-
- Defines component deliverables
-
-
- Requirements and specifications
-
- Defines service deliverables
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 35.
- Defines development environment
-
- Development and testing processes
- Defines development steps
-
- Incremental development is essential
-
- Stepwise completion of system parts
-
- Client feedback from early increments
Perspective Define environment early to drive staffing and
training Define steps so that systemaccumulates into final form Be
prepared for development feedback to architectureEvaluate early
increments wrt required propertiesArchitecture Life Cycle: Work
Products: Development Plan 36. Architecture
FundamentalsArchitecture Practices Client Environment:enterprise
arch. legacy systems initial requirements Marketplace Environment
Domain Architectures Enabling Technologies Final
RequirementsPrototypes & Models Architecture Design
Architecture ProvisioningArchitecture Validation VendorAgreements
Development Plan INPUTS WORK PRODUCTS ITERATIVE ARCHITECTURE
DEVELOPMENT Ent. Arch., Legacy, Reqs., Market, Domain, Enablers
Env. and Steps Analysis Devel. Planning Schedule Mgmt. Plan
Planning (Architecture Development) Architecture Life Cycle: Arch.
Development 37.
- Embedded within project schedule
-
- Supports project dependencies
- Entry conditions (rarely satisfied)
-
- Stable and complete requirements
-
- Availability of appropriate staff and resources
-
- Architecture work products are complete and validated
Perspective Failure to meet schedule is a non-starterSurface
schedule-impacting problems early Work at level of abstraction
compatible with schedule Architecture Life Cycle: Arch.
Development: Schedule 38.
-
- Project-specific architecture artifacts
-
- 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 riskArchitecture Life
Cycle: Arch. Development: Management Plan 39.
- Understand the client and resources
-
-
- Enterprise architecture and business models
-
-
- From present operations to envisioned future operations
-
- May require experimentation, training
-
- Document understandings for decision-making
Perspective Never stop learning about the problem and resources
Architecture Life Cycle: Arch. Development: Analysis 40.
- 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 41.
Architecture FundamentalsArchitecture Practices Client
Environment:enterprise arch. legacy systems initial requirements
Marketplace Environment Domain Architectures Enabling Technologies
Final RequirementsPrototypes & Models Architecture Design
Architecture ProvisioningArchitecture Validation VendorAgreements
Development Plan INPUTS WORK PRODUCTS ITERATIVE ARCHITECTURE
DEVELOPMENT External Behavior Data & Software Hardware &
Network Design Refine Refine Refine Design Design Ent. Arch.,
Legacy, Reqs., Market, Domain, Enablers Env. and Steps Validation
Checkpoint Analysis Inspection Devel. Planning IterationsSchedule
Mgmt. Plan Planning Architecture Life Cycle: Arch. Development:
Design Activities 42.
- 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 Cant design
the top without knowing the bottom Last intellectual passis top
down Architecture Life Cycle: Arch. Development: The Refinement
Process 43.
- 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