IS 425 Enterprise Information I LECTURE 3 Autumn 2004-2005 2004 Norma Sutcliffe

IS 425

Enterprise Information ILECTURE 3

Autumn 2004-2005 2004 Norma Sutcliffe

IS425 Autumn 2004-2005 Norma Sutcliffe

Session 3 2

This Session

Software engineering/architecting is about ensuring that certain thing happen

Security engineering is about ensuring that certain things do NOT happen


Session 3 3

Agenda

Exercise reviewing Week 2 material The Debate Risk Management Analysis Primer Software Development / Architecting Security Disaster Recovery


Session 3 4

Exercise

How do you reconcile the issue rankings below from 1996 to the “hot topics” that we discussed last week?

What pressures are different and what pressures are the same for the issues and topics?

1. Building a responsive IT infrastructure2. Facilitating and Managing Business Process Redesign3. Developing and managing distributed systems4. Developing and implementing an information architecture5. Planning and managing communication networks6. Improving the effectiveness of software development7. Making effective use of the data resource8. Recruiting and developing IS human resources9. Aligning the IS organization within the enterprise10. Improving IS strategic planning11. Implementing and managing collaborative support systems12. Measuring IS effectiveness and productivity


Session 3 5

The Debate

Discussion Forum “Debate Topics” is now open.

If you have a topic that you would like to debate – add a message giving a short description of the topic.

If you see a topic that interests you particularly – reply to the topic message stating you are interested giving your section number and your name.

Discussion forum is open for next two weeks.


Session 3 6

Risk Management Analysis Primer

A process for assessing threats and determining which ones to

ignore, reduce, eliminate

level of feasible support for efforts to reduce and eliminate

Expected Loss = P1 x P2 x L where: P1 = Probability of attack P2 = Probability attack is successful L = loss occurring is attack is successful


Session 3 7


A process for assessing threats and determining which ones to

ignore, reduce, eliminate

level of feasible support for efforts to reduce and eliminate by comparing expected losses to prevention costs


Session 3 8


Expected Loss or EL = P1 x P2 x L

where:

P1 = Probability of attack

P2 = Probability attack is successful

L = Loss occurring is attack is successful

PC = Prevention costs

If EL < PC then ignore

If EL > PC then investing in PC is reasonable


Session 3 9

Risk Analysis Steps


Session 3 10

What is the appropriate level


Session 3 11

Software Development/Architecting

The design on a system from multiple viewpoints – some common are: Technology stack (physical) view Object (data) view Use (behavioral) view

But need to see attributes such as: Modifiability, Build-ability, Security, Reliability, Performance, Business-oriented qualities.


Session 3 12


The architectural view is a component or subsystem view of the system

Module approach where a module is something that can be replaced by another implementation without causing other elements to change.

Relatively small amounts of information are exchanged between modules.

Modules are loosely coupled Allows concurrent development


Session 3 13


Software Architecture definitions-- 1. the description of the elements that compose the system, their

interactions, the patterns and principles that guide their composition and design, and the constraints on those patterns.

2. The observable properties of a software system (aka the form of the system) including:

1. Static forms2. Dynamic forms

3. Encompasses OO and Analysis methodologies

Software Architecting means process of creating software architectures.


Session 3 14


VIEWS have PHASES which Distinct – once completed Never Overlap Contain ACTIVITIES which

Overlap Repeat Can contain many non-decomposable STEPS Part of problem-specific TASKS


Session 3 15

Enterprise Architecture Business (process) architecture

Business strategy Governance Organization Key business processes (BPs)

Information Technology (IT) architecture Software infrastructure supporting BPs

Information (Data) architecture Logical and physical data assets Data management resources

Application (software) architecture Internal physical structure Problem models to aid developing implementation-

independent models


Session 3 16

Software Product Life Cycle

Management View

Software Engineering View

EngineeringDesign View

ArchitecturalView


Session 3 17

Management View

Phases constitute a development cycle

Inception when need identified Gathering or capturing

requirements aka specification of requirements

Construction when product is implemented (coded), unit tested & system tested

When transitioned to users--


Session 3 18

Software Engineering View

Multiple chains of activities running concurrently & overlapping

Inputs to activities are “whats” Outputs are “hows” RAS – understand the actual

problems Design – transforming reqs

into a technically feasible solution

I & T – source code D & M – to users


Session 3 19

Engineering Design View

Taken from mechanical engineering Phases are sequential but can be

overlapping Information flows from phase to phase PP –problem is defined and req list

created CD –problem analyzed and solution

concepts created/revised ED –main design or draft design DD –physical arrangement, dimensions

and other material properties are specified


Session 3 20

Architectural View

Phases are sequential and milestone driven

Product planning and study the entire enterprise context

DA- understand completely needs of acquirers and users

SD- prepares the architectural-level design

DD- refining the architectural description and selecting among alternative designs

BP- construct system


Session 3 21

Pulling It Together

If firms are trying to minimize costs why would they embrace “software architecting”?

Is there a possible relationship between software architecting and the value chain?

Is this type of software architecture prevalent now?

What kind of risk analysis can be done on a software development project?


Session 3 22

Security Engineering

Definition == building systems to remain dependable in the face of Malice Error Mischance.

To mitigate, reduce, the effects of threats Unintentional Intentional


Session 3 23

Security Threats


Session 3 24

General Controls Physical controls

Physical design of data center to limit access and protect from elements

Access controls Restriction of unauthorized user access to a system

Data Security controls Protecting data

From disclosure to unauthorized persons From destruction/modification by unauthorized

Administrative Controls Issuing guidelines / monitoring compliance

Programming Controls Development/Testing standards and procedures

Application Controls Inputs/Processing/Output


Session 3 25

Security Engineering Tools

Protocols Passwords Access controls Cryptography Distributed Systems Monitoring Systems


Session 3 26

Network Protection

To protect Internet and E-Commerce Most common security measures are:

Access control (PINs) Encryption Cable testers with protocol analyzers Firewall systems that enforce access control

between two networks


Session 3 27

Disaster Recovery Planning

Purpose is to keep business running after a disaster.

Backups –onsite and offsite Offsite computing arrangements made in

advance with hot-site vendors Offsite office arrangement made in advance

with cold-site vendors Critical applications identified and recovery

procedures addressed Written plan kept in several locations


Session 3 28

Pulling It Together

What kind of aptitude does a security engineer need?

What skills does a security engineer need? What kind of aptitude does a software

engineer need? What skills does a software architect need? Are they different?

Documents

IS 425 Enterprise Information I LECTURE 3 Autumn 2004-2005 2004 Norma Sutcliffe