· Website down | · Office down |
· Security incident | · Data breach | · Insider threat | · Privacy breach | · Fraud |
Ask leaders for their feedback and if they have scenarios to add. That amounts to known risk or exposure. Next, ask if there are risks they suspect from their knowledge of the environment and experience. Suspected risk may go unreported by those who are data-focused or are concerned about their credibility. Flesh out the list of scenarios as you gain a better understanding of the processes, technology and the people that support them.
Privacy issues can result in business impact. Be sure to account for that as well.
Prioritize scenarios by potential business impact and likelihood. Evaluate each scenario against the control environment. Risk Scenarios should be 'known unknowns', meaning they have a reasonable likelihood of having business impact. The scenarios within this article are examples. They may not apply to your organization and are not all inclusive.
IV. Application Risk Profiles and Scores
Expand on the list by identifying scenarios that result in that high-level risk. For example, a data breach can occur through production data stored in a test environment. Consider scenarios where adherence to standards is resource intensive and difficult to audit.
· Denial-of-service attack
· Natural disaster · Data center outage
· Malicious insider threat
· Human error
· Social engineering and phishing
· Malicious USB flash drives, bar codes, DVDs
· Data exfiltration
· Process failure (e.g. Target data breach)
· Compromise through a supplier
· Direct access to data (outside of applications)
· Copies of data (e.g. in test environments)
· Malware spread through advertisements
· Shadow IT (rouge suppliers)
· Domain or SSL certificate registration expires
· Newly adopted technology
· System or application missed by assessment or scan
· Project does not receive an assessment or scan
· Legitimate traffic causes performance degradation or outage
· Data cannot be restored from backup
· Technical change results in a service outage
· Personnel with access to sensitive data
· Physical security breach
· Exploitation of a security vulnerability
· Privacy and terms of use statements
· Failure to adhere to Opt-In / Opt-Out · Failure to adhere to the Do Not Call List
· Violation of privacy laws and regulations
Monitor many sources of information to account for emerging threats and compromise trends. RSS feeds are an efficient way to tap into information from many websites. Review industry reports and surveys such as the Verizon Data Breach Investigations Report and the US State of Cybercrime Survey. The SANS Top 20 Critical Security Controls has a list of Attack Types in the Appendix. The ISACA Risk IT Framework has utility as well.
Attend information security conferences and local chapter meetings. Have reoccurring calls with information security leaders in your industry and from companies of similar sizes.
III. Kill Chain Analysis
Learn to think like a hacker. Consider their tactics for compromising data. A paper from Lockheed Martin describes the Kill Chain as "a systematic process to target and engage an adversary to create desired effects" [ii]. Use the kill chain phases to identify controls to prevent or detect compromise in your company.
· 1. Reconnaissance
· 2. Weaponization · 3. Delivery
· 4. Exploitation
· 5. Installation
· 6. Command and Control (C2)
· 7. Actions on Objectives
An Application Risk Profile provides context. It gives executives the information they need to assign resources and reduce the risk of an application. Start by considering exposure such as whether the application is Internet facing or supplier hosted. Identify data that is stored, processed or transmitted by the application. Determine business impact if data was stolen, edited to commit fraud or if the application was unavailable. Take into account protective controls such as hardened application code, assessments and scans and Web Application Firewalls. Consider known vulnerabilities within security issue records and risk registry entries. These elements can be used to establish a risk score. The score can be used to prioritize applications by risk and to assign additional controls.
V. Process Risk Analysis
People have a tendency to document processes based on business-as-usual. There will be errors and failures in practice. Data may not be adequately protected. Processes must account for that with preventive and detective controls. Establish control points at critical process steps. Use Failure Modes and Effects Analysis to evaluate process issues by Severity, Rate of Occurrence and Detection. The multiple of those three values produces a Risk Priority Number.
VI. Trust, but Verify
Conduct verification on your own where possible. Request support from personnel from there. Explain the risk scenario and potential business impact. Be mindful of impact to productivity. Make requests that clearly follow the risk. Be wary of assurances that existing processes or technology mitigate the risk. The expression "Trust, but verify" applies. Obtain evidence that controls are in place.
Each of these methodologies has a cost and a return. Start simple with interviews. Branch out as you establish credibility. Establish a Multi-Generational Plan to chart the path forward. Recognize people for identifying risk. Track the results and value add of your program.
Reliance on frameworks and standards alone will not protect your organization. True due diligence requires risk assessment. Business leaders think in terms of risk. You have that on your side.
About the author:
Gideon T. Rasmussen is a Charlotte-based Information Security Risk Manager with over 15 years experience in corporate and military organizations. His website is www.gideonrasmussen.com. The opinions expressed here are those of Gideon Rasmussen and do not necessarily represent those of his current or past employers.
Originally published by RiskCenter (July, 2014)