Location via proxy:   [ UP ]  
[Report a bug]   [Manage cookies]                
SlideShare a Scribd company logo

Krage jousha

•
•

The document discusses how different fields approach risk assessment but use similar frameworks involving likelihood and impact/consequences. It reviews common risk equations and challenges in evaluating likelihood, threats/vulnerabilities, and impact. The document also compares how project management, engineering, and security approach risk management.

1 of 24
Download to read offline
Risk is Risk, Right? PM Challenge 2007 Joshua Krage NASA Goddard Space Flight Center Greenbelt, MD
Agenda • Review of risk assessment processes – Equations – Likelihood – Impact – Human impact • Review of risk dialects – Management of programs and projects – Engineering efforts – Security concerns • Final comparisons and recommendations February 2007 Risk is Risk, Right? 2
What is Risk? • We deal with risk every day – Each of us has an instinctual understanding of how to discern “day-to-day” risk, and avoid too much of it • But… do we: – mean the same thing? – make the same assessments? – manage the same risk? • Definition: (noun) 1: a situation involving exposure to danger. 2: the possibility that something unpleasant will happen. 3: a person or thing causing a risk or regarded in relation to risk (Compact Oxford English Dictionary, www.askoxford.com) February 2007 Risk is Risk, Right? 3
Many Risk Disciplines • Many disciplines use risk and risk assessment language – Psychology (decision theory) – Statistics – Financial institutions – Scenario analysis • While fascinating, these are (mostly) out of scope for today’s discussion • Today we focus on management, engineering, and security risk February 2007 Risk is Risk, Right? 4
Risk Equations The various risk disciplines distill a complex process into a easy-to- remember equation, with slight variances in approach and language. Source Risk Equation ISO17666:2003 Likelihood x Severity = Risk NIST SP800-30 Likelihood x Impact = Risk NASA NPR8000.4 Likelihood x Consequences = Risk Probabilistic Risk Assessment Probability(of Event) x Consequence = Risk Security Risk P(threat) x P(vulnerability) x Impact = Risk P(threat) x P(vulnerability) x Cost = Risk Engineering & Safety Risk P(accident) x LossesPerAccident = Risk The commonality in these equations supports thinking of risk assessment as a uniform process. February 2007 Risk is Risk, Right? 5
Picking Apart Likelihood • Likelihood is usually measured in terms of probability – The probability a particular outcome will be achieved • Ex. 98% chance the audience understands this – Generally considered an objective measurement – Can be derived mathematically (through proofs) or experientially • Challenges: – Basic probability assumes all outcomes are equal • Ex. Flipping a coin yields either heads or tails – True probability allows for some uncertainty • Ex. It is statistically improbable for the coin to land on its edge; or even not to land – Requires data from outcomes of similar situations • The longer the baseline, the better the data – Experiential data is generally time-bound • Ex. Flood of the century – If other techniques are not sufficient, then one is left with estimates and judgement calls February 2007 Risk is Risk, Right? 6
Picking Apart Threats & Vulnerabilities • Some risk assessment techniques (e.g. security) split likelihood into threats and vulnerabilities – Vulnerability indicates a weakness in a specific area or function, which if exploited will cause impact – Threat indicates the source or actor which can exploit the vulnerability – If neither a threat nor a vulnerability exist, then no risk – Usually have the most control over vulnerabilities, not threats • Examples of threats (exploits) and vulnerabilities: – Sick birds can infect healthy but non-immunized birds – Wind can generate un-dampened oscillations in an overly fluid bridge – Continuing resolutions will delay new work in the US Federal Government – A cracker will break into a misconfigured database to steal credit card numbers February 2007 Risk is Risk, Right? 7
Picking Apart Impact • Impact has many measuring systems – Cost is the most common objective measurement – Many impacts are intangible • Ex. Reputation/image, politics, copying intellectual property, etc. • These are measured subjectively: mild, moderate, severe, catastrophic – Typically rated in terms of Confidentiality, Integrity, and Availability • Challenges: – Accurate cost impact assessments require a sufficient level of cost data – Intangible impacts depend on a subjective assessment • Frequently inconsistent among reviewers • Breaches of confidentiality and integrity are typically the most challenging to assess February 2007 Risk is Risk, Right? 8
Exhibit: 5x5 Risk Matrix in Four Areas Safety Technical Cost/Schedule Likelihood (Likelihood of safety (Estimated Likelihood of not meeting mission (Estimated Likelihood of not meeting allocated event occurrences) technical performance requirements) Cost/Schedule requirement or margin) Bins 5 5 Very High (PS > 10-1) (PT > 50%) (PCS > 75%) Likelihood 4 4 High (10-2 < PS < 10-1) (25% < PT < 50%) (50% < PCS ≤ 75%) 3 3 Moderate (10-3 < PS < 10-2) (15% < PT < 25%) (25% < PCS ≤ 50%) 2 2 Low (10-6 < PS < 10-3) (2% < PT < 15%) (10% < PCS ≤ 25%) 1 1 2 3 4 5 1 Very Low (PS < 10-6) (0.1% <PT < 2%) (PCS ≤ 10%) Consequence Consequence Categories Risk Type 1 Very Low 2 Low 3 Moderate 4 High 5 Very High Negligible or No impact. Could cause the need for only May cause minor injury or May cause severe injury or May cause death or permanently minor first aid treatment . occupational illness or minor occupational illness or major disabling injury or destruction of Safety property damage. property damage. property. No impact to full mission Minor impact to full mission Moderate impact to full mission Major impact to full mission Minimum mission success criteria success criteria success criteria success criteria. Minimum success criteria. Minimum is not achievable HIGH RISKS Technical mission success criteria is mission success criteria is achievable with margin achievable MODERATE RISKS Negligible or no schedule Minor impact to schedule Impact to schedule milestones; Major impact to schedule Cannot meet schedule and program impact milestones; accommodates accommodates within reserves; milestones; major impact to milestones Schedule within reserves; no impact to moderate impact to critical path critical path LOW RISKS critical path <2% increase over Between 2% and 5% increase Between 5% and 7% increase Between 7% and 10% increase >10% increase over allocated, allocated and negligible over allocated and can handle over allocated and can not handle over allocated, and/or exceeds and/or can’t handle with reserves Cost impact on reserve with reserve with reserve proper reserves February 2007 Risk is Risk, Right? 9
Human Factors • The brain does funny things with risk – Humans have a tendency to subconsciously ignore or downplay the “edge” risks (implicit acceptance) • Extreme impact: don’t think about it • Low impact: not a big deal • High likelihood: what can you do? • Low likelihood: will never happen • Low occurrence rate with low impact: not a big deal – Subjective assessments allow the brain to insert its bias and can skew results • Mitigations: – Use objective assessments as a baseline where possible – Use peer reviews with common definitions to validate results February 2007 Risk is Risk, Right? 10
Reviewing the Bidding • Many disciplines, but a common terminology – Risk = Likelihood x Impact (Threat & Vulnerability) • Likelihood – Typically presented in mathematical probability terms – Frequently includes some estimation or judgement call • Impact – Very subjective – Varying units of measure • If not controlled, humans can skew assessments • Varied results are common, despite common language and approach February 2007 Risk is Risk, Right? 11
Risk Management • Four classic strategies to handle risk: – Accept • Do nothing – Eliminate • Force likelihood (or threat or vulnerability) OR impact to zero – Mitigate • Do something to limit the likelihood or reduce the impact, but not completely – Transfer • Assign someone else the acceptance of the risk, usually through insurance • Risk ignorance is equivalent to implicit risk acceptance February 2007 Risk is Risk, Right? 12
Management Risk • Project risk focuses primarily on schedule and resources (people, equipment, locations, money) – Good project managers consider the other areas as well, but the expectations set for the project manager are based in management risk – New issues (nascent risks) are tracked with increasing measurements – Lack of change or action is equal to lack of changing risk (controlled variables) – Risks tend to be eliminated or accepted, sometimes mitigated, rarely transferred – Politics plays a frequent (undocumented) role • Managerial decisions define the overall project’s risk management strategy – Drives all other risk areas – Can override technical concerns (appropriately) – Generally provides the most flexibility to the project February 2007 Risk is Risk, Right? 13
Engineering Risk • Engineering risk has its base in applied technology – Pushing the envelope of technology is a common goal of engineering risk – Given enough freedom, engineers can address most challenges successfully – Engineering is a critical component to mission success -- it cannot be ignored – Impact is usually that something breaks or progress down a path is stopped – Extensive materials and methods baselines are available • Aggressive testing can help develop or extend the baseline, even into conditions outside of “normal” • Partial matches to existing baselines can be extrapolated with low uncertainty – Not all risks can be mitigated; some have to be accepted • Ex. Comet hits deep space probe – Risks to others (safety) exist, but can usually be quantified – Risks are frequently mitigated or eliminated, sometimes accepted, and rarely transferred February 2007 Risk is Risk, Right? 14
Security Risk • Security risks (both physical and information) are generally about people and only sometimes about technology – Security protects and enables the project (or it is supposed to, anyway) – Security should be considered across the project, but is frequently underutilized – Good security staff are creatively paranoid; they expect the unexpected – Mitigations or eliminations are almost always possible, given sufficient resources • Various points of diminishing returns, and mitigation is rarely 100% guaranteed – “New” vulnerabilities are constantly identified • Generally already exist; we were just unaware of their existence (risk ignorance) – Risk to others is frequently challenging to quantify • Ex. Your home computer being used to attack others – Many security guides focus on implementing appropriate controls, not measuring or tracking the process output (i.e. tracking how the control is effective) – Risks are commonly mitigated, and sometimes accepted, eliminated, or transferred February 2007 Risk is Risk, Right? 15
Adaptive Adversaries • The single largest difference between security risk and others is the concept of the “intelligent, adaptive adversary” – Project management has many things to deal with, but sabotage is not common – Engineers plan to overcome natural and incidental human-triggered risks – Security staff focus on adversaries and situations where both deliberate and accidental actions are important – Adversaries continually adapt and evolve, unlike most natural threats – The adversary is the perfect example of an uncontrolled variable • It is rare to be able to limit the adversary’s threat source – The attacking adversary can choose which vulnerability to attack to what degree while the defender must address all possible vulnerabilities – Quantifying the adversary is very subjective – The types of adversary vary widely February 2007 Risk is Risk, Right? 16
Adversary Pyramid •Advanced, tailored, exploits nag te pio ta Highly •Very motivated e Es tion-s Skilled •Extensive resources Na Attacker •Very limited penalties apply Adversary Capabilities •Custom exploits pio al Skilled attacker •Motivated (usually financial) ge Es ustri na •Many resources Ind •Limited penalties apply •Limited exploit customization me ed Semi-skilled attacker Cri ganiz •Self-motivated •Limited resources Or •Penalties apply Un-skilled attacker •Use others’ tools sm •Out for fun tivi ck •Limited resources Ha •Many penalties Adversary Pool Size February 2007 Risk is Risk, Right? 17
Final Comparisons • Risk language is consistent, with common approaches – Various dialects of the same language, with custom terminology and assumptions – The mechanics are simple to understand, if complex to implement – Results can be varied across the dialects – Subjective elements can be hidden by the terminology • Commonalities between dialects exist: – Management and security risk is mostly about people and communications, and have the most intangibles to assess in impact – Engineering and security risk have the least control over external variables, and are always identifying previously-unknown latent issues – Management and engineering risk can depend on long baselines of prior experience • Some uniqueness exists: – Management risk includes politics – Engineering risk is the most straight-forward to quantify – Security risk includes the adaptive adversary February 2007 Risk is Risk, Right? 18
Final Recommendations • Set the risk management approach and tone early – Ensure risk management is utilized throughout the project lifecycle – Engage the subject matter experts early and often – Identify the risk management approach(es) to be used for each dialect and ensure all staff are familiar with the approach – Be aware of the dialect differences in risk discussions – Communicate continuously about risk issues across the project; cross-breed awareness between the subject matter teams – Identify the subjective elements of the risk assessment and repeatedly re-evaluate • As with most project problem solutions, communications is a key element to managing risk February 2007 Risk is Risk, Right? 19
Questions? • Any questions? • Contact information: – Joshua Krage Joshua.Krage@nasa.gov February 2007 Risk is Risk, Right? 20
Backup Slides February 2007 Risk is Risk, Right? 21
Action Learning • Need three audience volunteers – One project manager/engineer – Two operatives, not assigned to the project • Project: Toss – Mission success criteria • Using the provided components (balls/beanbags), get as many as possible into the target receptacle within the time provided (the schedule) – Constraints • Resources (staff and components) are limited to those specifically provided • Project staff may not approach within the minimum distance indicated until all components have been used • Others as indicated • Operatives receive special instructions individually February 2007 Risk is Risk, Right? 22
References • ISO17666:2003: Space Systems -- Risk Management http://www.iso.org/ (available for purchase) • NIST SP800-30: Risk Management Guide for Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf • NASA NPR8705.5: Probabilistic Risk Assessment (PRA) Procedures for NASA Programs and Projects http://nodis.hq.nasa.gov/ (download site) • NASA NPR8000.4: Risk Management Procedural Requirements https://nodis.hq.nasa.gov/ (download site) February 2007 Risk is Risk, Right? 23
Additional Reading • European Network and Information Security Agency (ENISA): Risk Management: Implementation Principles and Inventories for Risk Management/Risk Assessment Methods and Tools http://www.enisa.europa.eu/rmra/files/D1_Inventory_of_Methods_Risk_Management_Fina l.pdf • Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) http://www.cert.org/octave/ • Information Security Management Maturity Model (ISM3) http://www.ism3.com/ Process oriented information security management February 2007 Risk is Risk, Right? 24

More Related Content

Krage jousha

  • 1. Risk is Risk, Right? PM Challenge 2007 Joshua Krage NASA Goddard Space Flight Center Greenbelt, MD
  • 2. Agenda • Review of risk assessment processes – Equations – Likelihood – Impact – Human impact • Review of risk dialects – Management of programs and projects – Engineering efforts – Security concerns • Final comparisons and recommendations February 2007 Risk is Risk, Right? 2
  • 3. What is Risk? • We deal with risk every day – Each of us has an instinctual understanding of how to discern “day-to-day” risk, and avoid too much of it • But… do we: – mean the same thing? – make the same assessments? – manage the same risk? • Definition: (noun) 1: a situation involving exposure to danger. 2: the possibility that something unpleasant will happen. 3: a person or thing causing a risk or regarded in relation to risk (Compact Oxford English Dictionary, www.askoxford.com) February 2007 Risk is Risk, Right? 3
  • 4. Many Risk Disciplines • Many disciplines use risk and risk assessment language – Psychology (decision theory) – Statistics – Financial institutions – Scenario analysis • While fascinating, these are (mostly) out of scope for today’s discussion • Today we focus on management, engineering, and security risk February 2007 Risk is Risk, Right? 4
  • 5. Risk Equations The various risk disciplines distill a complex process into a easy-to- remember equation, with slight variances in approach and language. Source Risk Equation ISO17666:2003 Likelihood x Severity = Risk NIST SP800-30 Likelihood x Impact = Risk NASA NPR8000.4 Likelihood x Consequences = Risk Probabilistic Risk Assessment Probability(of Event) x Consequence = Risk Security Risk P(threat) x P(vulnerability) x Impact = Risk P(threat) x P(vulnerability) x Cost = Risk Engineering & Safety Risk P(accident) x LossesPerAccident = Risk The commonality in these equations supports thinking of risk assessment as a uniform process. February 2007 Risk is Risk, Right? 5
  • 6. Picking Apart Likelihood • Likelihood is usually measured in terms of probability – The probability a particular outcome will be achieved • Ex. 98% chance the audience understands this – Generally considered an objective measurement – Can be derived mathematically (through proofs) or experientially • Challenges: – Basic probability assumes all outcomes are equal • Ex. Flipping a coin yields either heads or tails – True probability allows for some uncertainty • Ex. It is statistically improbable for the coin to land on its edge; or even not to land – Requires data from outcomes of similar situations • The longer the baseline, the better the data – Experiential data is generally time-bound • Ex. Flood of the century – If other techniques are not sufficient, then one is left with estimates and judgement calls February 2007 Risk is Risk, Right? 6
  • 7. Picking Apart Threats & Vulnerabilities • Some risk assessment techniques (e.g. security) split likelihood into threats and vulnerabilities – Vulnerability indicates a weakness in a specific area or function, which if exploited will cause impact – Threat indicates the source or actor which can exploit the vulnerability – If neither a threat nor a vulnerability exist, then no risk – Usually have the most control over vulnerabilities, not threats • Examples of threats (exploits) and vulnerabilities: – Sick birds can infect healthy but non-immunized birds – Wind can generate un-dampened oscillations in an overly fluid bridge – Continuing resolutions will delay new work in the US Federal Government – A cracker will break into a misconfigured database to steal credit card numbers February 2007 Risk is Risk, Right? 7
  • 8. Picking Apart Impact • Impact has many measuring systems – Cost is the most common objective measurement – Many impacts are intangible • Ex. Reputation/image, politics, copying intellectual property, etc. • These are measured subjectively: mild, moderate, severe, catastrophic – Typically rated in terms of Confidentiality, Integrity, and Availability • Challenges: – Accurate cost impact assessments require a sufficient level of cost data – Intangible impacts depend on a subjective assessment • Frequently inconsistent among reviewers • Breaches of confidentiality and integrity are typically the most challenging to assess February 2007 Risk is Risk, Right? 8
  • 9. Exhibit: 5x5 Risk Matrix in Four Areas Safety Technical Cost/Schedule Likelihood (Likelihood of safety (Estimated Likelihood of not meeting mission (Estimated Likelihood of not meeting allocated event occurrences) technical performance requirements) Cost/Schedule requirement or margin) Bins 5 5 Very High (PS > 10-1) (PT > 50%) (PCS > 75%) Likelihood 4 4 High (10-2 < PS < 10-1) (25% < PT < 50%) (50% < PCS ≤ 75%) 3 3 Moderate (10-3 < PS < 10-2) (15% < PT < 25%) (25% < PCS ≤ 50%) 2 2 Low (10-6 < PS < 10-3) (2% < PT < 15%) (10% < PCS ≤ 25%) 1 1 2 3 4 5 1 Very Low (PS < 10-6) (0.1% <PT < 2%) (PCS ≤ 10%) Consequence Consequence Categories Risk Type 1 Very Low 2 Low 3 Moderate 4 High 5 Very High Negligible or No impact. Could cause the need for only May cause minor injury or May cause severe injury or May cause death or permanently minor first aid treatment . occupational illness or minor occupational illness or major disabling injury or destruction of Safety property damage. property damage. property. No impact to full mission Minor impact to full mission Moderate impact to full mission Major impact to full mission Minimum mission success criteria success criteria success criteria success criteria. Minimum success criteria. Minimum is not achievable HIGH RISKS Technical mission success criteria is mission success criteria is achievable with margin achievable MODERATE RISKS Negligible or no schedule Minor impact to schedule Impact to schedule milestones; Major impact to schedule Cannot meet schedule and program impact milestones; accommodates accommodates within reserves; milestones; major impact to milestones Schedule within reserves; no impact to moderate impact to critical path critical path LOW RISKS critical path <2% increase over Between 2% and 5% increase Between 5% and 7% increase Between 7% and 10% increase >10% increase over allocated, allocated and negligible over allocated and can handle over allocated and can not handle over allocated, and/or exceeds and/or can’t handle with reserves Cost impact on reserve with reserve with reserve proper reserves February 2007 Risk is Risk, Right? 9
  • 10. Human Factors • The brain does funny things with risk – Humans have a tendency to subconsciously ignore or downplay the “edge” risks (implicit acceptance) • Extreme impact: don’t think about it • Low impact: not a big deal • High likelihood: what can you do? • Low likelihood: will never happen • Low occurrence rate with low impact: not a big deal – Subjective assessments allow the brain to insert its bias and can skew results • Mitigations: – Use objective assessments as a baseline where possible – Use peer reviews with common definitions to validate results February 2007 Risk is Risk, Right? 10
  • 11. Reviewing the Bidding • Many disciplines, but a common terminology – Risk = Likelihood x Impact (Threat & Vulnerability) • Likelihood – Typically presented in mathematical probability terms – Frequently includes some estimation or judgement call • Impact – Very subjective – Varying units of measure • If not controlled, humans can skew assessments • Varied results are common, despite common language and approach February 2007 Risk is Risk, Right? 11
  • 12. Risk Management • Four classic strategies to handle risk: – Accept • Do nothing – Eliminate • Force likelihood (or threat or vulnerability) OR impact to zero – Mitigate • Do something to limit the likelihood or reduce the impact, but not completely – Transfer • Assign someone else the acceptance of the risk, usually through insurance • Risk ignorance is equivalent to implicit risk acceptance February 2007 Risk is Risk, Right? 12
  • 13. Management Risk • Project risk focuses primarily on schedule and resources (people, equipment, locations, money) – Good project managers consider the other areas as well, but the expectations set for the project manager are based in management risk – New issues (nascent risks) are tracked with increasing measurements – Lack of change or action is equal to lack of changing risk (controlled variables) – Risks tend to be eliminated or accepted, sometimes mitigated, rarely transferred – Politics plays a frequent (undocumented) role • Managerial decisions define the overall project’s risk management strategy – Drives all other risk areas – Can override technical concerns (appropriately) – Generally provides the most flexibility to the project February 2007 Risk is Risk, Right? 13
  • 14. Engineering Risk • Engineering risk has its base in applied technology – Pushing the envelope of technology is a common goal of engineering risk – Given enough freedom, engineers can address most challenges successfully – Engineering is a critical component to mission success -- it cannot be ignored – Impact is usually that something breaks or progress down a path is stopped – Extensive materials and methods baselines are available • Aggressive testing can help develop or extend the baseline, even into conditions outside of “normal” • Partial matches to existing baselines can be extrapolated with low uncertainty – Not all risks can be mitigated; some have to be accepted • Ex. Comet hits deep space probe – Risks to others (safety) exist, but can usually be quantified – Risks are frequently mitigated or eliminated, sometimes accepted, and rarely transferred February 2007 Risk is Risk, Right? 14
  • 15. Security Risk • Security risks (both physical and information) are generally about people and only sometimes about technology – Security protects and enables the project (or it is supposed to, anyway) – Security should be considered across the project, but is frequently underutilized – Good security staff are creatively paranoid; they expect the unexpected – Mitigations or eliminations are almost always possible, given sufficient resources • Various points of diminishing returns, and mitigation is rarely 100% guaranteed – “New” vulnerabilities are constantly identified • Generally already exist; we were just unaware of their existence (risk ignorance) – Risk to others is frequently challenging to quantify • Ex. Your home computer being used to attack others – Many security guides focus on implementing appropriate controls, not measuring or tracking the process output (i.e. tracking how the control is effective) – Risks are commonly mitigated, and sometimes accepted, eliminated, or transferred February 2007 Risk is Risk, Right? 15
  • 16. Adaptive Adversaries • The single largest difference between security risk and others is the concept of the “intelligent, adaptive adversary” – Project management has many things to deal with, but sabotage is not common – Engineers plan to overcome natural and incidental human-triggered risks – Security staff focus on adversaries and situations where both deliberate and accidental actions are important – Adversaries continually adapt and evolve, unlike most natural threats – The adversary is the perfect example of an uncontrolled variable • It is rare to be able to limit the adversary’s threat source – The attacking adversary can choose which vulnerability to attack to what degree while the defender must address all possible vulnerabilities – Quantifying the adversary is very subjective – The types of adversary vary widely February 2007 Risk is Risk, Right? 16
  • 17. Adversary Pyramid •Advanced, tailored, exploits nag te pio ta Highly •Very motivated e Es tion-s Skilled •Extensive resources Na Attacker •Very limited penalties apply Adversary Capabilities •Custom exploits pio al Skilled attacker •Motivated (usually financial) ge Es ustri na •Many resources Ind •Limited penalties apply •Limited exploit customization me ed Semi-skilled attacker Cri ganiz •Self-motivated •Limited resources Or •Penalties apply Un-skilled attacker •Use others’ tools sm •Out for fun tivi ck •Limited resources Ha •Many penalties Adversary Pool Size February 2007 Risk is Risk, Right? 17
  • 18. Final Comparisons • Risk language is consistent, with common approaches – Various dialects of the same language, with custom terminology and assumptions – The mechanics are simple to understand, if complex to implement – Results can be varied across the dialects – Subjective elements can be hidden by the terminology • Commonalities between dialects exist: – Management and security risk is mostly about people and communications, and have the most intangibles to assess in impact – Engineering and security risk have the least control over external variables, and are always identifying previously-unknown latent issues – Management and engineering risk can depend on long baselines of prior experience • Some uniqueness exists: – Management risk includes politics – Engineering risk is the most straight-forward to quantify – Security risk includes the adaptive adversary February 2007 Risk is Risk, Right? 18
  • 19. Final Recommendations • Set the risk management approach and tone early – Ensure risk management is utilized throughout the project lifecycle – Engage the subject matter experts early and often – Identify the risk management approach(es) to be used for each dialect and ensure all staff are familiar with the approach – Be aware of the dialect differences in risk discussions – Communicate continuously about risk issues across the project; cross-breed awareness between the subject matter teams – Identify the subjective elements of the risk assessment and repeatedly re-evaluate • As with most project problem solutions, communications is a key element to managing risk February 2007 Risk is Risk, Right? 19
  • 20. Questions? • Any questions? • Contact information: – Joshua Krage Joshua.Krage@nasa.gov February 2007 Risk is Risk, Right? 20
  • 21. Backup Slides February 2007 Risk is Risk, Right? 21
  • 22. Action Learning • Need three audience volunteers – One project manager/engineer – Two operatives, not assigned to the project • Project: Toss – Mission success criteria • Using the provided components (balls/beanbags), get as many as possible into the target receptacle within the time provided (the schedule) – Constraints • Resources (staff and components) are limited to those specifically provided • Project staff may not approach within the minimum distance indicated until all components have been used • Others as indicated • Operatives receive special instructions individually February 2007 Risk is Risk, Right? 22
  • 23. References • ISO17666:2003: Space Systems -- Risk Management http://www.iso.org/ (available for purchase) • NIST SP800-30: Risk Management Guide for Information Technology Systems http://csrc.nist.gov/publications/nistpubs/800-30/sp800-30.pdf • NASA NPR8705.5: Probabilistic Risk Assessment (PRA) Procedures for NASA Programs and Projects http://nodis.hq.nasa.gov/ (download site) • NASA NPR8000.4: Risk Management Procedural Requirements https://nodis.hq.nasa.gov/ (download site) February 2007 Risk is Risk, Right? 23
  • 24. Additional Reading • European Network and Information Security Agency (ENISA): Risk Management: Implementation Principles and Inventories for Risk Management/Risk Assessment Methods and Tools http://www.enisa.europa.eu/rmra/files/D1_Inventory_of_Methods_Risk_Management_Fina l.pdf • Operationally Critical Threat, Asset, and Vulnerability Evaluation (OCTAVE) http://www.cert.org/octave/ • Information Security Management Maturity Model (ISM3) http://www.ism3.com/ Process oriented information security management February 2007 Risk is Risk, Right? 24