Transcript IS 425 Enterprise Information Spring 2008

IS 425
Enterprise Information
Spring 2008
James Nowotarski
8 May 2008
Today’s Agenda
Topic
Duration

Recap of 5/1
45 minutes

Security and risk
30 minutes
*** Break
15 minutes

Security and risk (cont.)
30 minutes

eCommerce
60 minutes

Wrap-up
10 minutes
2
Core Concepts
Systems development life cycle (SDLC)
Example
Planning
Modeling
Construction
Deployment
3
Core Concepts
The waterfall model is the granddaddy of life cycle models
Planning
Modeling
Construction
Deployment
4
Waterfall model
System
requirements
Software
requirements
Analysis
Program
design
Coding
Source: Royce, W. (1970,
August). Managing the
development of large software
systems. IEEE Proceedings,
WESCON, 1-9.
Testing
Operations
5
What’s
Protracted integration and
late breakage
wrong with waterfall?
Conventional application of the waterfall
model typically results in late integration and
performance showstoppers
Late design
breakage
100%
Development progress
(% coded)
Integration
begins
Original
target date
6
Source: Royce, W. Software Project Management: A Unified Framework. Addison-Wesley (1998).
Core Concepts
Iterative/Evolutionary/Spiral life cycle models
advocate multiple “threads” through the SDLC
phases
Version 1
M
C
D
Version 2
M
C
D
Version 3
M
C
D
7
Core Concepts
Incremental life cycle models advocate
delivering the end product piecemeal
Version 1
M
C
D
Version 2
M
C
D
Version 3
M
C
D
8
Risk Profile: Iterative vs. Waterfall
Inception
Waterfall
Elaboration
Risk
Iterative
Construction
Transition
Preliminary
Iteration
Architect.
Iteration
Architect.
Iteration
Devel.
Iteration
Devel.
Iteration
Devel.
Iteration
Transition
Iteration
Transition PostIteration
deployment
Time
Copyright © 1997 by Rational Software Corporation
9
Rational Unified Process
(RUP)
10
Each Iteration is a mini-waterfall
R
R
A&D
R
A&D
C
A&D
C
T
C
T
T
11
Phase boundaries in waterfall
are activities
System
requirements
Software
requirements
Analysis
Program
design
Coding
Testing
Operations
13
Phase boundaries in RUP are
milestones
System
requirements
Software
requirements
Analysis
Program
design
Milestone
Coding
Testing
Operations
14
Agile/Light/Lean Methods

“We have come to value:




Individuals and interactions
Working software
Customer collaboration
Responding to change
over
over
over
over
processes and tools
comprehensive documentation
contract negotiation
following a plan”
15
Agile methods wind the RUP
model more tightly
System
requirements
Software
requirements
Analysis
Program
design
Functioning
Code
Coding
Testing
Operations
16
Agile/Light/Lean Methods
Approach
References
XP
www.extremeprogramming.org
www.xprogramming.com
M. Marchesi et al, Extreme Programming
Perspectives, Addison-Wesley, 2002.
Crystal
A. Cockburn, Agile Software Development,
Addison-Wesley, 2001
SCRUM
K. Schwaber and M. Beedle, Agile Software
Development with Scrum, Prentice Hall, 2001.
Adaptive Software
Development
J. Highsmith, Adaptive Software Development,
Dorset House, 2000.
FDD
S. Palmer, A Practical Guide to Feature-Driven
Development, Prentice Hall, 2002.
Agile - General
http://www.agilealliance.org/home
http://www.agilemodeling.com
17
Key Practices – Agile Methods
Customer on-site as integral part of team
 Short iterations, small releases


2 month releases, 2 week iterations
Refactoring and evolutionary design
 Test all the time
 Pair programming (XP)
 40-hour week (XP)

18
Iterative/Agile Guiding
Principles
Objectives
Customer
Value
Quality
Iterative
Development
Strategies
Accommodate
change
Attack risk
Tactics
Work together
Executable
software
Architecture
baseline
Component-based
development 19
Iterative/Agile Guiding
Principles
Objectives
Customer
Value
Quality
Iterative
Development
Strategies
Accommodate
change
Attack risk
Tactics
Work together
Executable
software
Architecture
baseline
Component-based
development 20
Why focus on change?
Cost of change
y = axp
Req
Anal. Des. Impl. Test
Prod
Life cycle phase
21
Change curve – Agile methods
Cost of change
Agile methods purport to change the curve so that the
cost to find and repair software problems does not rise
dramatically over time
Time
22
Iterative/Agile Guiding
Principles
Objectives
Customer
Value
Quality
Iterative
Development
Strategies
Accommodate
change
Attack risk
Tactics
Work together
Executable
software
Architecture
baseline
Component-based
development 23
Why emphasis on executable
software?
“Without this first pass, the project
manager is at the mercy of human
judgment. With this first-pass
‘simulation,’ he can at least perform
experimental tests of some key
hypotheses and scope down what
remains for human judgment, which in
the case of computer program design . .
. is invariably and seriously optimistic”
Source: Royce, W. (1970,
August). Managing the
development of large software
systems. IEEE Proceedings,
WESCON, 1-9.
24
Who is Fritz Bauer?
• Chairman of 1968
NATO Software
Engineering
Conference
• Credited with coining
the term “software
engineering”
25
Core Concepts
Software Engineering
• The establishment and use of sound
engineering principles in order to economically
obtain software that is reliable and works
efficiently on real machines (Fritz Bauer, 1969)
26
RUP Guiding Principles
Objectives
Customer
Value
Quality
Iterative
Development
Strategies
Accommodate
change
Attack risk
Tactics
Work together
Executable
software
Architecture
baseline
Component-based
development 27
Architecture
arch·i·tec·ture n. The
fundamental
organization of a
system embodied in its
components, their
relationships to each
other, and to the
environment, and the
principles guiding its
design and evolution.
Source: IEEE
28
What is software architecture?
Software architecture is a level of design that
“involves the description of elements from which
systems are built, interactions among those
elements, patterns that guide their composition,
and constraints on these patterns.”
Shaw, M., Garlan, D. (1996). Software architecture: Perspectives on an
emerging discipline. Upper Saddle River, NJ: Prentice-Hall.
29
Software architecture
Applications and
Data
• Presentation layer
• Application logic
• Data management
Middleware
System Software
Hardware/Network
30
Key principles of
architectural design
Abstraction
 Modularity
 Reuse

31
Abstraction

There is a limit to the number of ideas
you can comprehend at any one time


Raise the level of detail by creating
relationships


7 +/- 2
Example: Grouping
Think in logical instead of physical
terms
32
Grouping: What’s easier to
understand and retain?
Grapes
Milk
Potatoes
Eggs
Carrots
Dairy
Oranges
Butter
Apples
Sour cream
Fruit
Vegetable
Sour cream
Milk
Eggs
Butter
33
Logical vs. Physical
IT-enabled
solution
Business
problem
Analysis
Logical
Design
Physical
Design
Build
Test
Deploy
34
Entity relationship diagram (ERD)
35
Think in logical instead of physical
terms
Big idea: As a prelude to creating a design, represent
the basic computational requirement for the system to
be designed in more abstract terms, i.e., in terms of
data flow
employee_data
PRINT_
PAYCHECK
salary
CALC_
SALARY
taxes
employee_
data
READ_
DATA
salary
CALC_
TAXES
36
SafeHome Security: State
Transition Diagram
Resetting
Start/
stop
switch
power
“on”
SystemOK
Entry/set systemStatus “inactive”
Entry/set displayMsg1 “Starting system”
Entry/set displayMsg2 “Please wait”
Entry/set displayStatus showBlinking
Do: run diagnostics
failureDetected /
set displayMsg2
“contact Vendor”
Reset
Activate
deactivatePassword
Idle
Entry/set systemStatus “inactive”
Entry/set displayMsg1 “Ready”
Entry/set displayMsg2 “”
Entry/set displayStatus steady
keyHit/handleKey
off/powerOff
deactivate
Password
ActingOnAlarm
MonitoringSystemStatus
Entry/set systemStatus “monitoring”
Entry/set displayMsg1 “Armed”
Entry/set displayMsg2 “”
Entry/set displayStatus steady
Do: monitorAndControlSystem
KeyHit/handleKey
falseAlarm
timeOut
sensorTriggered/
startTimer
Entry/set systemStatus “monitorAndAlarm”
Entry/set displayMsg1 “ALARM”
Entry/set displayMsg2 triggeringSensor
Entry/set displayStatus fastBlinking
Do: soundAlarm
Do: notifyAlarmResponders
keyHit/handleKey
sensorTriggered/
restartTimer
37
Students at a university
Inquiry
Lead
Enrolled
Applicant
Rejected
Admitted
Withdrawn
Matriculated
Drop Out
Graduated
38
Modularity

Modular design



Reduces complexity
Facilitates change
Results in easier implementation by supporting parallel
development of different parts of the system.

Information hiding

Functional independence

Objectives: High cohesion, low coupling
39
Call and return
PROCESS_PAYROLL
for each employee
get_data(:employee_data)
calc_salary(employee_data:salary)
calc_tax(salary:tax)
print_check(employee_data, salary, tax)
employee_data
employee_data
employee_
data
salary
salary
tax
salary
GET_DATA
CALC_SALARY
CALC_TAX
tax
PRINT_CHECK
40
Cohesion and coupling


Cohesion
A measure of the relative functional strength of
a module
Func A-1
Func B-1
Func A-2
Func B-2
Func A-3
Func B-3
High Cohesion (good)
Coupling
A measure of the relative interdependence
among modules
High coupling (bad)
41
Today’s Agenda
Topic
Duration

Recap of 5/1
45 minutes

Security and risk
30 minutes
*** Break
15 minutes

Security and risk (cont.)
30 minutes

eCommerce
60 minutes

Wrap-up
10 minutes
42
security
Security is a pervasive
thread throughout the SDLC
Planning
Analysis
Design
Implementation
43
Security terminology









Backup
Controls
Decryption/Encryption
Exposure
Fault tolerance
Integrity (of data)
Threats (or hazards)
Risk
Vulnerability
44
Types of threats

Threats
Unintentional
 Intentional

• Attack
• Data tampering
• Programming fraud
45
Controls address threats





Prevention and deterrence
Detection
Limitation
Recovery
Correction
46
Types of controls

General controls
Physical
 Access
 Data security
 Communication network
 Administrative

47
Risk management
“The basic problem of software development is
risk”
Beck, K. (2000). Extreme Programming Explained. Boston, MA: Addison-Wesley
48
Risk management process
Identify
Analyze
$$
Cost of protection
Plan
Control
$$
Cost of exposure
49
Security & Controls
Chief Information Security Officer
Threat and
Vulnerability
Services
Security
Governance,
Risk Management
and
Business
Continuity
Audits &
Controls
Management
Role
Management,
Security Access
Design
Information
Security
Research
Security
Managers by
Geography
Americas
EMEA
Asia Pacific
Information Systems IS 425
Information Security - Today
The Facts
– Vulnerability
– Threat
– Risk
– Increasing points and modes of attack
– Increasing attackers and incidents
– Increasing value available for compromise
The Result
– Time stolen by security measures is increasing
– Money invested in security measures is increasing
– Effectiveness and life-cycle of security measures are
decreasing
DePaul University
51
Information Systems IS 425
Contents
 What is information risk (i-risk)
 Why is i-risk management important
 How do you assess
i-risk
 How do you manage
i-risk
 What this means to you
DePaul University
52
Information Systems IS 425
Definition: Information Risk
Nature and
level of harm
Likelihood of suffering harm
Information risk is the chance or possibility of harm
being caused to a business as a result of a loss of the
confidentiality, integrity or availability of information
Exists in varying forms:
The 3 key properties
of information to be
protected




DePaul University
held in people’s heads
communicated face-toface
recorded in deeds and
other securities
entered into, stored,
processed, transmitted
and presented via IT
53
Information Systems IS 425
I-Risk Impacts Other Business Risk
Market risk
(factors beyond the control of
management such as interest
and currency rates)
Financial risk
(uncertainties about
projected earnings or
expenditure)
Information risk
Information risk
intensifies all
other business
risks

Borrowings and investment
positions

Projected rates of interest

Projected cash flows

External developments
Operational risk
(information risk, theft,
fraud, loss of facilities or
key employees)
Information risk is an
increasingly important
component of
operational risk

Sales forecasts

Information risk status reports

Forecast expenditure


Actual sales and
expenditure
Identity of key assets
(equipment, facilities and
employees)

Key variances

Status of continuity
arrangements
Sound information is needed to manage each category of risk. Thus,
managing information risk well is essential.
DePaul University
54
Information Systems IS 425
The Chance of Incidents Is High
Information incidents are a feature of day-to-day business life, and there’s a high
chance of suffering a MAJOR incident
Average no. of incidents suffered over a year per information resource
Percentage of information resources that suffered a MAJOR incident
100%
400
334
75%
276
300
52%
56%
58%
55%
220 55%
50%
200
147
88
100
0
Business
applications
(260)
Computer
installations
(247)
Communications
networks
(159)
Systems
development
activities (115)
25%
Overall
average
(781)
0%
Collectively
known as
information
resources
DePaul University
55
Information Systems IS 425
Why is I-Risk Important?
 Information risk is
– One of the most important and fastest growing components of business risk
– Required for good corporate governance
 Because information risk is not well understood or managed
– A business-critical information resource has a 50% chance of experiencing a
MAJOR incident over the course of a year
– Minor incidents are accepted as a part of day-to-day business life
 Incidents sap an organization’s energy, compromise service targets, erode
profitability, and can seriously harm an organization’s reputation
DePaul University
56
Information Systems IS 425
Definition: Risk Management
Identify
Identify different types
of risk that affect
Evaluate
Act
Evaluate their
Initiate action to keep
relative significance risks within acceptable levels
 Risk management is a process to identify, measure, control, and minimize or
eliminate the likelihood of an incident
 Risk management must strike a balance between the impact of risks and the
cost of protective measures
DePaul University
57
Information Systems IS 425
Definition: Risk Assessment
 A risk assessment identifies different types of risk to Organization information resources
and evaluates their relative significance
Info Resource’s Importance
Criticality
Business
Impact
Information Resource
(Application, Computer, Network)
Magnitude of
Incident’s Harm
Vulnerabilities
Control Weaknesses
Threats
DePaul University
History of Past Incidents
58
Information Systems IS 425
Driving Down Risk
 Based on a risk assessment,
to drive down risk
– Strengthen existing controls
or implement new controls
– Increase user education
– Add layers of physical and
information security
– Implement or revise business
processes
– Implement or revise policies
and standards
– Add resources
– Make contingency arrangements
DePaul University
59
Paring SOX Down to Size: The Impact of Sarbanes-Oxley on IT
Governance
Information Systems IS 425
What is SOX
• What does it require, why and who cares?
• State of the market
• Investments and Organization
• Building a Defensible Compliance Strategy
• Recommendations
“We did not formally build a compliance architecture. It just sort of
happened.”
DePaul University
61
Information Systems IS 425
The Sarbanes-Oxley Act of 2002
• Increasing responsibilities and liabilities for:
•
CEOs, CFOs, Ind. Auditors, Boards/Committees
• Internal Controls
•
Adequacy
•
Changes
• Auditors and management
•
Must report & attest to accuracy of financial
and disclosures
statements
DePaul University
62
Information Systems IS 425
The Sarbanes-Oxley Act of 2002
• Applies to US public companies, private companies with public debt
and accounting firms
• Does not exempt foreign private firms or non-U.S. public accounting
firms
• Driven by the Enron, Tyco and WorldCom fiascos
• SOX has sections covering
– Reporting – improves disclosure requirements
– Roles – strengthens corporate governance
– Conduct – expands on accountability
– Enforcement – improves oversight
– Penalties – broadens sanctions
– Relationships – forces auditor independence
DePaul University
63
Information Systems IS 425
Why is it a Big Deal for IT?
• Lack of comprehensive documentation of existing internal
controls at most firms
•
No comprehensive evaluation of internal controls by the majority
of firms
• SOX often has to be fit into on-going development activities
• Limited resources available
• 1 in 10 companies have made financial restatements in the past
five years (U.S. GAO study)
DePaul University
64
Information Systems IS 425
What the Fortune 50 are Saying
• “Our controller’s department has direct responsibility for SarbanesOxley implementation. We have a program team with finance
devoted to this today.”
• “We are still trying to put together a plan of what should be the
overall governance of all IT systems. We want to use the structure
we have put in place for Sarbanes-Oxley to be used for other
compliance initiatives.”
• “Our success in working through activities the first time has
depended on buy in from the CEO and CFO.”
• “The IT compliance manager and internal audit are joined at the
hip and coordinate all activities together.”
DePaul University
65
Information Systems IS 425
Big IT Impact Anticipated
DePaul University
66
Information Systems IS 425
People, Processes and Systems will be Impacted
DePaul University
67
Information Systems IS 425
Which Provisions Apply to IT?
• 302 – Corporate responsibility for financial reporting
• Is our financial data accurate?
• Do we have transaction level detail if required?
• Do we understand all the processes involved?
• 404 – Annual mgmt assessment of internal controls
• How does our control structure operate?
• Who is accountable?
• Is it monitored?
• Is it documented?
• 409 – Real-time disclosure of material changes
• 802 – Retention of relevant records for audits/reviews
DePaul University
68
Information Systems IS 425
Emerging IT Requirements/Impact
• Definitely influence, perhaps certify…
–
–
–
–
–
–
–
–
–
Anti-fraud techniques – development & operations
Change management process
Data integrity
Disaster recovery practices
Electronic records retention policy
– “properly recorded and reported” transactions
– “reasonable assurance” test
Integrity of communications
Patch management
Process/work flows – internal & partners
Security policies and practices
– SOX compliance built into overall security architecture
DePaul University
69
Information Systems IS 425
What is SOX’s impact on IT?
1.
2.
3.
Minimal
Some impact
Big impact
4.
Impacts most of development and operations
30%
1
30%
2
20%
20%
3
4
DePaul University
70
Information Systems IS 425
Key Organizational Issues
• The Sarbanes-Oxley Act of 2002 has brought companies to focus
on a more centralized way to address governance and
compliance.
• Centralized authority usually resides in finance or an audit group for
assuring overall regulatory compliance. IT compliance is treated as
an operational consideration and is usually handled by an IT
compliance officer or an IT compliance committee.
• Companies normally have a compliance committee that consists
of members from IT, finance and lines of business (LOBs). The
committee facilitates constant and clear communications among the
member participant departments.
DePaul University
71
Information Systems IS 425
Key Findings of Recent Research
1.
Companies not focusing on technology fixes - instead auditing,
procedures and reporting. Most not buying new technology to
solve, but may upgrade or partially replace to address. Most
drive to 90%+.
2.
Split on whether finance understands technology issues involved
in SOX compliance, and whether IT understands the business
issues
3.
IT will be affected by SOX, more so than all other departments
except finance. Most viewed SOX compliance more resource
intensive than other regulatory compliance projects.
4.
Confident that 404 requirements will be met.
5.
Almost 1 in 10 think their job is at risk if the firm is noncompliant and 1 in 4 must certify results personally.
6.
Successful companies have strong support by CxO management
in driving compliance activities across the organization. It was
not just the role of the CIO.
DePaul University
72
Today’s Agenda
Topic
Duration

Recap of 5/1
45 minutes

Security and risk
30 minutes
*** Break
15 minutes

Security and risk (cont.)
30 minutes

eCommerce
60 minutes

Wrap-up
10 minutes
73
eBusiness
eCommerce
74
What is eCommerce?
eCommerce
Marketing, buying, and selling . . .
. . . of goods and services . . .
. . . over the Internet
75
What is eBusiness?
eBusiness
Conducting of business . . .
. . . over the Internet
76
eBusiness Models
Business to Business (B2B)
 Business to Consumer (B2C)
 Consumer to Business (C2B)
 Consumer to Consumer (C2C)
 Business to Employee (B2E)
 Etc.

Our focus
77
eBusiness “value chain”
Attract
•
•
Interact
•
•
Act
•
•
React
•
•
How can IT enable?
Attract
Interact
Act
React
B2C
1
2
B2B
3
4
Information
commerce
5
6
79
eBusiness Processes
80
For May 15

Readings on architecture

DL: Discussion on Business intelligence
(due May 22)
81
Extra slides
82