1. (c) 2007 Charles G. Gray1 IT Risk Management, Planning and Mitigation TCOM 5253 / MSIS 4253 Risk Assessment 27 September 2007 Charles G. Gray

2. (c) 2007 Charles G. Gray2 Learning Objectives Learn how risk assessment fits into the overall plan for risk management Understand how risk is identified and assessed Learn the fundamental aspects of documenting risk through the creation of a risk assessment

3. (c) 2007 Charles G. Gray3 Risk Defined Risk is a function of the likelihood of a given threat-source exercising a particular potential vulnerability, and the resulting impact of that adverse event on the organization or on individuals

4. (c) 2007 Charles G. Gray4 Sun Tzu Chinese general and philosopher –Lived c. 500 - 320 BC (?) A general is skillful in attack whose opponent does not know what to defend He is skillful in defense whose opponent does not know what to attack

5. (c) 2007 Charles G. Gray5 Sun Tzu – Plan Ahead The art of war teaches us to rely not on the likelihood of the enemy’s not coming, but on our own readiness to receive him; not on the chance of his not attacking, but rather on the fact that we have made our position unassailable

6. (c) 2007 Charles G. Gray6 Sun Tzu – The Art of War If you know the enemy and know yourself, you need not fear the result of a hundred battles If you know yourself but not the enemy, for every victory gained you will also suffer a defeat If you know neither the enemy nor yourself, you will succumb in every battle.

7. (c) 2007 Charles G. Gray7 Know Yourself Identify, examine and understand the information systems currently in place Understand everything about the information Look at what is already being done to protect information and assets

8. (c) 2007 Charles G. Gray8 Know the Enemy (Threat) Identify, examine, and understand the threats that most directly affect the organization and the security of assets Use this understanding to create a prioritized list of threats of importance to the organization

9. (c) 2007 Charles G. Gray9 Quick Review Attack – an act or action that takes advantage of a vulnerability to compromise a controlled system –Accomplished by a threat agent that damages or steals information or a physical asset Vulnerability – an identified weakness in a controlled system where controls are not present, or are no longer effective Threats always exist – Attacks occur only with a specific act or action

10. (c) 2007 Charles G. Gray10 Risk Assessment The process to identify and prioritize enterprise Information Technology security risks to the organization

11. (c) 2007 Charles G. Gray11 Success Factors Executive support –Cannot be overemphasized! Stakeholder acceptance (buy-in) –Active participation –Assessment results may affect budgets Well defined roles and responsibilities

12. (c) 2007 Charles G. Gray12 Participants in Risk Assessment Business owner(s) –Determines value of business assets Information Security Group –Determines probability of impact on assets IT – Engineering –Designs technical solutions, estimates costs IT Operations –Designs operational components of solution and estimates operating costs

13. (c) 2007 Charles G. Gray13 Preparation for Risk Discussions Risk Management Team should invest time to prep for meeting with stakeholders Subject areas to be researched include: –New business drivers – M&A activity Organizational changes –Previous risk assessments –Audit reports –Security incidents Highlight control deficiencies

14. (c) 2007 Charles G. Gray14 More Subject Areas for Research Industry events –External influences –government regulation –International activities Bulletins – security alerts –On the web, directly from software vendors Information security guidance –New trends, tools, standards (e.g., ISO)

15. (c) 2007 Charles G. Gray15 Planning for Risk Assessment Align risk assessment with business processes Accurately scope the assessment objectives Gain stakeholder acceptance

16. (c) 2007 Charles G. Gray16 Alignment Ideally, begin risk assessment prior to the corporate budget build process Facilitates executive support and visibility Builds consensus with stakeholders during the planning process Good timing demonstrates that the security group is a proactive partner – not just reacting to every “emergency”

17. (c) 2007 Charles G. Gray17 Scoping Document all boundaries, resources and functions to be included in the risk analysis –Identify all stakeholders –Delineate operational authorization bounds Gain executive approval Install effective change management controls –Don’t expand the scope without the necessary resources Note: Scope creep is the biggest project killer!

18. (c) 2007 Charles G. Gray18 Stakeholder Acceptance Active participation essential for success “Pre sell” the concept of risk assessment Interact with stakeholders early and often, both formally and informally There is a difference between “approval of the project” and “acceptance of the time and resource priorities necessary” Request a formal commitment from each stakeholder group (management)

19. (c) 2007 Charles G. Gray19 Setting Expectations Participants need to understand their role in the larger process Business owners define the value of business assets Info Security Group’s expertise is to estimate the probability of threats Learn to accept (or even embrace) subjectivity DO NOT introduce FUD!

20. (c) 2007 Charles G. Gray20 Facilitated Data Gathering Get input from both technical and non- technical professionals Meet collaboratively with stakeholders –Infosec experts must “bridge the gaps” that non-technical members do not grasp Discuss – don’t “interrogate” –Use open-ended questions –The objective is understanding – not an audit

21. (c) 2007 Charles G. Gray21 Identifying Assets Asset–anything of value to the organization All assets must be identified –Tangible – physical infrastructure –Intangible – company reputation, digital info –IT service (more on next slide) Confirm and document the owner of each asset Disregard impact statements at this time Enough detail to allow the business owner to assign a value to the organization

22. (c) 2007 Charles G. Gray22 IT Service as an Asset Combination of tangible and intangible assets –E-mail –File sharing –File storage –Remote access –Telephony Owners of tangible and intangible assets may be different

23. (c) 2007 Charles G. Gray23 Example of Asset Description System name Hardware/Software (software version, etc.) System interfaces (e.g., internal and external connectivity) Data and information stored/processed Persons who support/use the system System mission (what processes are performed?) System and data criticality to the enterprise

24. (c) 2007 Charles G. Gray24 Example of Asset Description (2) Functional requirements of the IT system System security policies –Organizational policies –Federal requirements –Applicable federal/state laws –Industry “best practices” System security architecture Current network topology (network diagram)

25. (c) 2007 Charles G. Gray25 Example of Asset Description (3) Information storage protection System input/output flowchart Management controls Operational controls –Personnel security –System maintenance –Off-site storage/backup facilities –Privileged vs. “standard” user access Physical/environmental security

26. (c) 2007 Charles G. Gray26 Asset Classes Start with only three, to keep it relatively simple –High business impact (HBI) –Medium business impact (MBI) –Low business impact (LBI) Having only three classes limits debate and reduces the time needed to reach consensus

27. (c) 2007 Charles G. Gray27 HBI Impact Compromise of confidentiality, integrity or availability will cause: –Severe or catastrophic loss Direct or indirect financial loss Theft of financial instruments Damage to reputation Loss of productivity Significant legal and regulatory liability Access limited – need-to-know only –Explicit control by the asset owner

28. (c) 2007 Charles G. Gray28 HBI - Examples Authentication credentials –Passwords, crypto keys, hardware tokens Highly sensitive business information –Financial data, intellectual property Assets subject to specific regulatory requirements –HIPAA, EU Data Directive, Sarbanes-Oxley Personally Identifiable Information (PII)

29. (c) 2007 Charles G. Gray29 More HBI Examples Financial transaction authorization data –Credit card numbers, expiration dates Financial profiles –Consumer credit reports, personal income statements Medical profiles –Medical record numbers, biometric identifiers

30. (c) 2007 Charles G. Gray30 MBI Impact Compromise of confidentiality, integrity or availability will cause moderate loss: Direct or indirect financial loss Theft of financial instruments Damage to reputation Loss of productivity Significant legal and regulatory liability Disrupt normal organizational functions to the degree that proactive controls are necessary to minimize impact

31. (c) 2007 Charles G. Gray31 MBI Examples Employee directory –Useful for social engineering Purchase order data –Requests for proposal –Bid sheets/pricing information Network infrastructure design Information located on intranets Data on file for internal business use only

32. (c) 2007 Charles G. Gray32 LBI Impact Includes all non-HBI and non-MBI assets No formal protection requirements or controls beyond standard “best practices” for securing infrastructure Information is usually intended to be widely published and publicly available

33. (c) 2007 Charles G. Gray33 LBI Examples High-level organization structure Basic information about IT Read-access to publicly accessible web pages Public cryptographic keys Press releases, product brochures, white papers and product documentation

34. (c) 2007 Charles G. Gray34 Gathering Information Questionnaire –Both technical and non-technical personnel On-site interviews –Information about physical, environmental and operational security of IT systems –See handout for sample questions to ask Document review –Policy documents, system documentation, security-related documents Automated network mapping tools

35. (c) 2007 Charles G. Gray35 Questioning Technique Avoid “info sec” terminology, such as “threats”, “vulnerability”, and “countermeasures” Use functional business-related terms Objective is to understand the larger risk areas – not to debate competing definitions Wait until the end of the discussion to resolve questions about risk definitions

36. (c) 2007 Charles G. Gray36 Questions to Ask What asset are you trying to protect? How valuable is it to the organization? What are you trying to avoid happening? –Both known and potential threats How might loss or exposure occur? What is the extent of potential exposure to the asset?

37. (c) 2007 Charles G. Gray37 More Questions What are you doing today to reduce the probability of or the extent of damage? What are some actions that we can take to reduce the probability in the future? Refer to ISO 17799 Information Security Standard for guidance in formulating additional questions See handout for more sample questions

38. (c) 2007 Charles G. Gray38 Organizing Risk Information Limit meetings to 60 minutes –Four to six stakeholders Risk Assessment Facilitator –Keep conversation/discussion going without interfering Risk Assessment Note Taker –Use a standardized format/template –Consistent capture of information across meetings with different teams