Someone in SOIRA (see this New School post to learn about the Society of Information Risk Analysts) asked a few questions on pre-reqs for an infosec risk management program and I thew in my two bits. I've mentioned in the past we'd like to share more of our experiences building these programs. People are interested in examples and it makes sense to share.
My question is what's the real demand and how actionable is content? Do you have a real need to read how someone else spun up a program or is it just interesting? If there is a need, what specific examples would inspire you to start or alter your program?
My guess is the cost of reading is cheap so why not. That's my view and my expectations are usually met. If I see a nugget I take it, if not, the price was right. Every blue moon I'll actually find someone who appreciates our war stories so it's fun for me to keep sharing. If there is something specific though, shoot me a mail/comment and maybe we can rustle something up.
Below was my top of mind response to a few of the questions on SOIRA. If there's interest I'll expand on the topics since they're incredibly under served below. There were more questions around 15 second risk decisions and qualitative risk models. I'll post more on these in the future. Week of 6/21 we have a fun Risk Communicator update that should inspire more qualitative discussion!
What are the pre-requisites for a information risk management program?
Big topic. My quick:
1. Exec buy in
If decisions aren't made as a result of your process, it's worse than nothing. This doesn't mean risks won't be taken, they need to be evaluated consistently, then taken.
2. Recognized Process/Service
This isn't free lunch. Carve out a % of your team's resources, put it on your perf, team and, group goals.
3. Consistent Model
Pick one that fits your business culture i.e. what kind of business case resonates best with your decision makers.
4. Defined Process
Write it down, collaborate, and get approval for the frequency, swimlane, and RACI for who conducts, prioritizes, and finalizes. The key to success is to include stakeholders outside security. This includes metrics e.g. % business assessed. % risks with a decision. % completed on time.
5. Crawl, walk
Pilot with a friendly/fertile biz/IT unit to prove the process and get final buy in.
If you truly have exec buy-in, they'll bounce decisions through your process. If they go around it, something's wrong. I'll never forget the first time the CTO called me about something an exec saw in the news. They wanted it run through the process and results communicated out.
Lots will be broken or inefficient. Set expectations up front, it's a journey.
If the business wants risk management, then get started. There's no run book because you're making technical decisions in a business/political environment. Embrace it and just do it. It's powerful, rewarding, and improves morale. No one's a victim when decisions are vetted through a process.
How can I establish and communicate risk tolerance?
In my experience, you can't. You can only facilitate. That's why the RACI is so important. The business owner accountable for the asset in question is accountable for the tolerance decision. Incidents (evidence) are your guide and currency. In my experience it takes about 18 months to train/win/lose/learn.[As a quick add to this: another task to facilitate establishing risk tolerance is to proactively meet with stakeholders before incidents or risk questions pop up. Every security program should be meeting a couple/few times a year with business and IT leaders asking open ended questions about their strategy, priorities, measurements, and concerns. This context really helps seed your estimates in drafting loss predictions that the business ultimately owns.]