We help companies with risk analysis and compliance.
Risk Appetite: When details are reviewed set up your risk analysis diagram:
Why is Risk Analysis difficult?
It depends on your industry - if in health industry, the obvious data to protect is patient data. But if one swipes credit cards then accounting information is important. What about discussions between doctors? Is that important? i.e. email. When discussing Industry trends and insurance details is that important? Is data only important when patient data is included? Do new internet capable patient monitoring devices have risks builtin?
So in this one industry we thought 1 piece of data was the most important (patient data) and now I have listed several other pieces in a couple of minutes:
- Credit Card information
- Intra-agency doctor conversations
- Insurance details without patient data
- Internet capable patient monitoring devices fitbit like, heart devices, etc.
other potential problems: Risk is not always looked at in aggregate - in total.
Maybe the 1, 2, and 3 are not as risky, but if they are connected in some way now the risk is higher, and thus the impact is higher.
Should we just throw in the towel and proclaim everything is important and protect everything already?
Managing risk means to rate risk and then we have to rate our risk appetite.
Here is a risk appetite matrix from ISACA¹
We can help you define risk for compliance and better security reasons.
All of us have to learn to be comfortable with a little bit of discomfort - the real question is: How much discomfort can we really live with?
If you never review your true risk profile and catalog your data then you don't even know what you have?
A blogpost at OversiteSentry² (our website) discusses the problems of risk management when systems are not upgraded or patched.
Risk management has problems when there are unknown issues at your systems.
When there are combination of risks that cause higher risks or impacts. Risk analysis is worth every minute you spend on it, since afterwards it will be clear where you should spend resources when scarce and resources are never plentiful.
Think about this for a minute (or 2) ... if you have a high level of risk appetite for a specific vulnerability how good is your decision in not fixing this vulnerability? Have you put down the gory details? We choose not to fix this vulnerability for the next 2 months because X, Y, and Z? If you say "we choose not to fix a vulnerability" then you better have a good reason for not fixing - besides we can't do it, or we do not have time etc.
Can you answer these questions quickly without doing further research?
What is your technique for handling new uncertainty? Is it clear?
What is the decision tree for New items coming into your environment?
Is there a policy for when a new incident comes in? and changes the equation? giving examples is sometimes not enough, as we don't know the things we don't know... how comfortable are you really?
Also once the lines are drawn - medium low and high impact, would a small change in one direction make it go to high impact? Would your decision make it now medium impact?
There are many questions to answer - many questions to review the details of the answers. And don't forget to bring up the supporting proof.
Is "high risk" fixing a vulnerability in 1 month? or 2 weeks?
Can you fix all high risk vulnerabilities in 2 weeks? Because if not, then you ARE taking on more risk unless a change of IT procedures reduces vulnerability fixes in time.
The most likely circumstances are that risk analysis is not being done to the degree you know your risks, especially as your environment changes.
We have worked with companies to develop a good risk matrix with impacts and risk probabilities assigned to the IT assets in companies (Databases of employee and customer data among others).
Sometimes it is the proposal and project files that are important. (can you afford to be down for a few days within a project execution?).
what has to be done to finalize the analysis of risk is to find the impact of data resources and the likelihood of vulnerabilities.
High likelihood = 3
Med likelihood = 2
Low likelihood = 1
High Impact = 3
Med impact = 2
Low impact = 1
risk = likelihood * impact
Another way to view this Risk analysis table is a 3D graph with risk being the height of the column while the axis are likelihood and impact.
Because traditional Risk management is very difficult to keep up on, I recommend a new approach with testing at the forefront.
Since performing Risk management correctly requires a lot of work and IT departments are already stretched trying to keep up on everything AND defend the network from hackers.
As I have mentioned before a "proper" Defense of a decent size network:
- Security operations - keeps up on security events (blue team)
- Threat intel - certain events require more research and special care
- Firewall and Router operations - need special care for opening and closing ports etc.
- Penetration testing (red team)
- Vulnerability scanning - has to be done consistently
- Forensics - after an attack somebody has to have the skills to find out what happened (they are also used in emergencies for specific HDD issues)
- Endpoint security - when there are thousands of computers they must have specific help and care that is constant (updating definition files etc)
- Web application scanning( Web applications must be scanned)
That is what i am used to. If the proper analysis and resources are not available (like in the SMB(Small Medium Business) market there _can't_ be 15-30 people in an IT department.
There must be a simpler method of analyzing Risk.
Contact Tony Zafiropoulos now to discuss Risk Analysis - 314-504-3974 or tonyz"@"fixvirus.com