1. (c) 2007 Charles G. Gray1 IT Risk Management, Planning and Mitigation TCOM 5253/MSIS 4253 Implementing Controls 15 November 2007 Charles G. Gray

2. (c) 2007 Charles G. Gray2 Seven Stages of a Project Uncritical acceptance Wild enthusiasm Dejected disillusionment Total confusion Search for the guilty Punishment of the innocent Promotion of non-participants Anonymous

3. (c) 2007 Charles G. Gray3 No - - Seriously Many (if not all) project management tools will apply to implementing IT risk controls Must take a “holistic” approach to projects –Have to consider: The entire IT system The entire business unit The entire organization –Seek to avoid the “law of unintended consequences”

4. (c) 2007 Charles G. Gray4 The IT Project Dilemma Only 34% of IT projects are truly successful 95% of IT projects are over budget (Aberdeen Consulting) 50% of IT projects fail to meet objectives (Gartner Group) “Project Portfolio Management” (PPM) did/does not solve the problem

5. (c) 2007 Charles G. Gray5 Why Projects Fail Lack of alignment between IT projects and business objectives Improperly estimated IT projects –Dollars are easier than heads Lack of standardization of project processes Poor visibility into project performance Poor (or no) change management process

6. (c) 2007 Charles G. Gray6 “Old” PPM is No Solution Vendors develop feature-bloated products –70% of features are never used –Employees hate to use See no value added to their daily responsibilities Added costs are passed through to the customer Implementation of complex features drives up the cost Result – Millions of $$$ worth of software sitting on the shelf doing nothing

7. (c) 2007 Charles G. Gray7 A “New Breed” of PPM Must be easy to use –Incents the customer to continue to subscribe Low start-up costs –customer can bail out at any time Simple recurring fee – no hidden costs New features provided automatically upon log-in –No extensive (painful) upgrades

8. (c) 2007 Charles G. Gray8 “On Demand PPM” ® (Innotas) Up and running in days/weeks Built with both “C-level” executives and workers in mind –Rapid adoption due to ease of use Reasonably priced – scales well Built-in “best practices” Multi-featured –Request management, project management, resource management, financial/time management

9. (c) 2007 Charles G. Gray9 Project Definition A series of well-defined tasks Performed in a prescribed sequence Assigned to specific individuals Definite start and completion dates

10. (c) 2007 Charles G. Gray10 A Successful Project

11. (c) 2007 Charles G. Gray11 Barriers to Project Management Poor communication –Team doesn’t know what has already been done, or exactly what is to be done Disagreements Failure to comply with standards Personality conflicts Poor management Poorly defined project goals –Scope creep

12. (c) 2007 Charles G. Gray12 Threats to a Successful Project Ad hoc requirements management Ambiguous and imprecise communications Overwhelming complexity Undetected inconsistencies in requirements Insufficient testing Subjective assessment of project status Failure to properly assess risks Uncontrolled change propagation

13. (c) 2007 Charles G. Gray13 Project Management One project manager in charge –Well defined responsibilities –Adequate resources Competent people Money Facilities/equipment Defined reporting structure Documented change management process –Seek to avoid “scope creep”

14. (c) 2007 Charles G. Gray14 Change Management Process Every change formally identified –Communicated –Documented –Reviewed –Approved –Implemented Without it, delivering the project within “time, cost, and quality” objectives may be compromised

15. (c) 2007 Charles G. Gray15 Change Management Must have a well defined process, including a change control manager and committee Request must include (in writing): –Detailed proposal description –Justification including CBA (what is the benefit?) –Impact of not implementing the change –Alternatives to be considered –Additional resource requirements Obtain signatures of all concerned

16. (c) 2007 Charles G. Gray16 Getting Started Agree on the purpose of the project Define the objectives Finalize the scope (prevent “creep”) Identify activities Assign resources Create time and cost estimates Make honest assumptions about “what if” Propose alternative scenarios and build contingency plans

17. (c) 2007 Charles G. Gray17 How a Project Gets Done Roles are “who” –Behavior and responsibilities of a person or team - not the person themselves Artifacts are “what” –Outcome of activities – documents, etc. Workflow is “when” –Sequence of activities to be completed Activity is “how” –The actual tasks a worker performs

18. (c) 2007 Charles G. Gray18 Task Sequencing Finish-to-start –Dependent task can’t start until its predecessor is finished Start-to-start –Dependent task can’t start until its predecessor has started Finish-to-finish –Dependent task can’t be finished until its predecessor is finished Start-to-finish –Dependent task can’t finish until its predecessor has started

19. (c) 2007 Charles G. Gray19 PERT Chart Example (CPM)

20. (c) 2007 Charles G. Gray20 PERT Chart Example (CPM) 1 2 3 4 5 8 7 6 10 9 11 Create Schedule Buy hardware Installation Programming Test code Test system Write Procedure System Conversion Training User testing Dummy Activity

21. (c) 2007 Charles G. Gray21 Microsoft Project Software Tasks –Summary –Subtasks –Recurring tasks –Milestones Links Constraints –Flexible or inflexible Costs

22. (c) 2007 Charles G. Gray22 Gantt Chart Example

23. (c) 2007 Charles G. Gray23 Gantt Chart Example Click to View Full Size Click to View Full Size

24. (c) 2007 Charles G. Gray24 Project Controls Senior management commitment is vital Documented project plan Project meetings – regularly scheduled –Agenda –Attendance –Commitment Project reports – structured –Oral at meetings –Written for “the record”

25. (c) 2007 Charles G. Gray25 Commitment Unambiguous executive commitment –Clearly establish priorities –Staff members authorized to implement the controls within the project framework Managers recognize (accept) high priority –Resource allocation (time, money, equipment) Staff allowed to reprioritize existing work as needed –Record and document progress and report to RM Team and Security Steering Committee

26. (c) 2007 Charles G. Gray26 Participants Mitigation owners –IT Architecture –IT Engineering –IT Operations Assisted by –Risk management team –Information security –Finance and accounting

27. (c) 2007 Charles G. Gray27 Responsibilities IT Engineering –Determine HOW to implement controls IT Architecture –How to integrate control solutions with existing systems IT Operations –Actually implements control solutions Finance and accounting –Ensure that spending stays within budget

28. (c) 2007 Charles G. Gray28 Use Subject Matter Experts RM Team should assign an SME technologist to each identified risk Single point of contact Reduces risk of inconsistent messages from the RM Team Provides a “clean” engagement model throughout the process

29. (c) 2007 Charles G. Gray29 “Defense in Depth” Concept Courtesy of Microsoft ™

30. (c) 2007 Charles G. Gray30 Physical Security Controls Adequate locks –Physical or electronic keys (e.g., RFID) limit the number of “master keys” Implement controls for issue and retrieval Perimeter fences – laser augmentation Surveillance cameras/recorders Prohibit “tailgating” of employees Security badges – biometric systems Strict controls for vendors, visitors, and contractors

31. (c) 2007 Charles G. Gray31 Network Defenses Well-designed architecture facilitates defense –Proper network design –Wireless network security –IPSec (IP security measures) –Admit only trusted computers to critical network resources

32. (c) 2007 Charles G. Gray32 Host Defenses Strike balance between degree of hardening and ease of use –Increased security usually means systems are more difficult to use Disable certain services Remove specific user rights –Compartmentalization Update operating systems Antivirus software Distributed firewalls

33. (c) 2007 Charles G. Gray33 Application Defenses Applications exist in the context of the overall system –Must consider the entire environment Adequate testing prior to putting into production –Seriously try to “break it” in test Run with the least amount of privilege, with the minimum exposure possible

34. (c) 2007 Charles G. Gray34 Data Defenses Data is usually an organization’s most valuable resource Often stored locally –Particularly vulnerable to attack Encrypting File Service –Certificates based on ITU Recommendation X.509 (SSL) Frequent backups