IS 425

1. IS 425 Enterprise Information ILECTURE 3 Autumn 2004-20052004 Norma Sutcliffe

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? • Building a responsive IT infrastructure • Facilitating and Managing Business Process Redesign • Developing and managing distributed systems • Developing and implementing an information architecture • Planning and managing communication networks • Improving the effectiveness of software development • Making effective use of the data resource • Recruiting and developing IS human resources • Aligning the IS organization within the enterprise • Improving IS strategic planning • Implementing and managing collaborative support systems • 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. 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 by comparing expected losses to prevention costs Session 3

8. Risk Management Analysis Primer • 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. Software Development/Architecting • 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 Development/Architecting Software Architecture definitions-- • 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. • The observable properties of a software system (aka the form of the system) including: • Static forms • Dynamic forms • Encompasses OO and Analysis methodologies Software Architecting means process of creating software architectures. Session 3

14. Software Development/Architecting 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 EngineeringDesign View Management View Software Engineering View ArchitecturalView Session 3

17. 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-- Management View Session 3

18. 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 Software Engineering View Session 3

19. 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 Engineering Design View Session 3

20. 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 Architectural View 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? Session 3