This week, it’s Chapter 6 (Analysis Process) and 7 (Understanding Results) in Measuring and Managing Information Risk, the FAIR book, and now we’re getting hands-on with a working knowledge of quantitative cyber risk analysis.
All summer, we are reading and discussing the FAIR™ book, Measuring and Managing Information Risk by Jack Freund and Jack Jones, the authoritative text on quantitative cyber risk analysis and risk management, with a new discussion guide every two weeks to help FAIR summer book clubs spark conversation.
Get your highlighters ready – find a stack of Post-it notes – the FAIR Institute is putting on a summer book club to read and discuss the FAIR™ book, Measuring and Managing Information Risk
With the ongoing big move to cloud storage to support working from home, it seems inevitable that we’re going to see more data breaches on Amazon S3 “buckets”, an evergreen cybersecurity problem. It happened again a week ago
In basic terms, a company’s “risk appetite” is the level of risk the organization sees as acceptable. Not surprisingly, some use the phrase “risk tolerance” interchangeably with “risk appetite” (there is an important difference: "tolerance" is how far off "appetite" the organization will go).
I’ve heard it many times – “Why can’t we just do this analysis over the whole IT environment? Why do we need to pick a specific asset or population or assets?”
As a former auditor, I understand the value a control has for an organization, a process or an application. But, I’ll be honest I used to think a control was one dimensional. It didn’t really matter what the control protected, if the control wasn’t functioning properly or configured exactly to a ‘T’, it was failing.
Time and time again I see analysts perform a FAIR risk analysis but get caught up in searching for the absolute perfect data or second guessing the results.
Imagine this – an issue is assigned to your risk analyst team, either by your management, someone in the business, or perhaps it's some area of weakness your own team identified. After completing the analysis, now it's time to prepare a presentation on the risk results.
As a risk consultant, I run a lot of meetings for project scoping or data gathering that bring together people from around a company, usually with different perspectives and agendas. Often these meetings require that everyone come together and agree on a direction for a risk analysis project.