#RSAC 2012 Risk Management Summit: Scaling Risk Management

This is piece 2 of 3 on RSA 2012 (also see my first piece "Themes & Misconceptions"). In this post I'll discuss the invite-only Risk Management Summit that was organized by Evan Wheeler within the P2P track. The RM Summit had four 1-hour slots that used a format of 5-10 minutes presentation (no slides!) followed by 40-50 minutes of discussion. Overall, I thought this was an excellent program and format, and I very much look forward to being able to participate in it again.

My participation was both as an attendee and as a speaker. For my speaking topic, I presented my notion of "scaling risk management," posing the question for discussion of "If you're an SMB, what is a reasonable expectation for performance of risk management? What should SMBs be minimally required to do?" This discussion took an interesting turn early on, revealing that there are really two questions contained within the topic: 1) "How do you scale-down 'big finance' risk management practices to the SMB space?" and 2) "How should a small business bridge the gap until it's big enough to adopt formal risk management practices?"

Bridging the Gap

During the discussion, it quickly became apparent that there really is a necessary tipping point that each organization has to reach before being able to formally adopt risk management practices. All people and organizations use risk management techniques, but through our discussion we concluded that many of those early prototypical practices are implicit and closely align to Donn Parker's thoughts on diligence. This line of thinking was fascinating, and brought up the question: If an organization isn't yet ready for a formal RM program, then how should they be addressing the gap between the existing risk management needs and their ability to apply formal techniques?

There were two lines of thinking around this topic. First and foremost, we debated whether or not industry or government regulations are necessary. However, it became quite apparent that for the smallest companies, setting requirements (e.g., as PCI DSS does) simply isn't adequate or fair. If a small business cannot afford to adopt formal risk mgmt practices (and, by extension, hire someone to help in that area), then they also probably cannot very well deal with detailed requirements being foisted onto them.

Instead, the focus needs to be on a) pushing them to outsource support and solutions, b) making sure the outsourcers are addressing security and risk management, and c) requiring the SMBs to pick-up appropriate insurance policies to cover any gaps. The PCI Council has already targeted outsourcers with their requirements for service providers and solutions (i.e., PA-DSS). However, it appears that enforcement still isn't quite up-to-par. On the last point, we noted that insurance may or may not be adequately available today. One attendee noted that merchants used to be required to carry insurance policies, back when physical cards were being processed on paper, but that such requirements went away with eCommerce. General consensus seemed to be that such a requirement should in fact be brought back.

Of course, while a solution like insurance helps address the risk management concerns, it does not do much to address the occurrence of fraud and data breaches. This means that, while this should be part of the solution, there still needs to be a scaled-down set of practices that every business, regardless of industry (including restaurants, hospitality, and other non-technical verticals), can adopt and follow.

Scaling-Down Practices

Working from the assumption that "bridging the gap" only addresses the financial liability, and does not necessarily improve the security posture (note here that you can potentially improve risk posture without improving security posture o_O). How, then, do you scale-down practices - particularly as they apply to risk management (in this context) - for the small business that hasn't yet reached the necessary tipping point to staff-up?

There are a couple different angles to this discussion to consider:
* Practices: The practices themselves will vary. At a minimum, Parkerian "diligence" is the default state. People make risk management decisions based on experience, available information, and typically without a formal process. The question is: is there a lightweight way to formalize these decisions? If so, how do you train the masses? Or, is this really just too much academicism and not enough pragmatic practicality?

* Mandate & Enforcement: At the end of the day, businesses are not going to adopt formal practices that add overhead cost unless there's a good reason to do so or they are required to make changes. Similarly, the changes will only follow if there is at least a perception of enforcement (and penalties). In considering "requiring" formal risk management practices for the SMB space (pre-tipping-point), it's imperative to consider how you would set, communicate, and enforce those requirements.

* Legal Aspects: At the end of the day there are two key measures to consider with respect to the law: are practices commercially reasonable and legally defensible? In the first case, "commercially reasonable" helps look at what the rest of the industry is doing and determines whether or not your organization is maintaining a level of practice that is at least on-par with everyone else. In a very real way this looks at negligence concerns. At the same time, there is also an imperative for ensuring that practices (or the lack thereof) are legally defensible. So, even if the state of the industry does not require meeting certain levels of performance, if you know of a reasonable risk to the business and do not take reasonable measures to at least analyze it, if not find ways to treat it, then stakeholders may determine that you didn't do enough, and you could find yourself in court arguing over whether or not your actions (or lack thereof) were defensible. This is not a scenario in which you want to find yourself.

The discussion at the Risk Management Summit touched on some of these points, but we did not ever reach a consensus. Several notions were mentioned in passing, such as relying on industry self-regulation, relying on government regulation (such as through the Small Business Administration), or setting performance benchmarks through other means like contracts (e.g., as tied to insurance premiums and coverage, as tied to the ability to accept credit cards for payments).

At the end of the day, there is probably a need for articulating a minimum set of expectations as regards the awareness of information risk that affects any organization using IT resources and handling data (especially sensitive data). We've seen some of these programs in action, such as in healthcare where small family practices started issuing privacy statements and requiring the signing and myriad forms in order to allow the practice of medicine on a patience (it should be noted that many of these practices are a bit over-reactionary and undermine the intent of laws like HIPAA, which were meant to facilitate treatment and information sharing, not put up significant roadblocks to them).

Two final thoughts occur. First, if your organization is small and has not reached the tipping point, then you need to figure out (somehow) what your minimum responsibilities are. It's your duty to know this. However, it may fall to other industries or the government to help make you aware of these duties. Second, once your organization reaches the tipping point of adopting formal risk management practices, then a good first step is likely to hire or contract a subject-matter expert who can help get a reasonable framework and process in place.

About this Entry

This page contains a single entry by Ben Tomhave published on March 6, 2012 2:00 PM.

#RSAC 2012: Themes & Misconceptions was the previous entry in this blog.

#RSAC 2012: Concluding Thoughts is the next entry in this blog.

Find recent content on the main index or look in the archives to find all content.

Monthly Archives

Pages

  • about
Powered by Movable Type 6.3.7