When writing this blog post for ISACA it occurred to me that to be an effective cybersecurity leader requires that you understand the dynamic of risk communication and becoming comfortable with the decisions of well-informed business leaders.
You can read the article here.
I really enjoy reading Duncan Watts work and I was blown away by how he assailed the concept of common sense that we all rely upon so readily:
What we don’t realize, however, is that common sense often works just like mythology. By providing ready explanations for whatever particular circumstances the world throws at us, common sense explanations give us the confidence to navigate from day to day and relieve us of the burden of worrying about whether what we think we know is really true, or is just something we happen to believe.
Questioning our perception of reality is pretty heavy and you can spend a lot of time working through that. But in my article I use this idea to break out of the crutch of using common sense to manage risk.
You can read the full article on the @ISACA Newsletter site here.
I’m pleased to announce that a new book has been published that includes a chapter that I wrote on Cybersecurity and Technology Risk. I was approached by the good folks at Risk Books on contributing some original Cyber content in their new publication on Operational Risk. I choose to address the general risks in the domain and paid special attention on how to define risks (risk syntax) to avoid the problems of defining control deficiencies as risk.
The other chapters in the book are really great too! There are discussions of blockchain, Big Data, Privacy, OpRisk modeling and quantification, and emerging risk.
You can pick up your copy of Operational Risk Perspectives: Cyber, Big Data, and Emerging Risks at the Risk Books website (including eBook).
We conducted a yard sale last week. If you’ve ever done this, then you know the turmoil over pricing. Your stuff is valuable to you, but there is often a hard reality that hits you when you try and extract that value from the public. Put simply, your stuff typically isn’t worth what you think.
Pricing your security services reflects a similar statement of risk. Many organizations mandate a security review as a part of their SDLC (and if they don’t, they should). Paying for this is an interesting conundrum. Once upon a time, I developed a metaphor that I thought was useful for getting to the root of the pricing problem. I called it “Pizza Sauce.” At the time, we were trying to develop a way to price the value that we thought security could add to software development projects. The problem that we came to quickly was that people thought security was already a part of the price (at the time, we were selling to 3rd parties not internal organizations, but the metaphor works either way). I equated it to a pizza: if you ordered a pizza, you assume it comes with sauce. You’d be insulted if you received a bill for the pizza with a line-item for sauce. Similarly, there is a negative perception associated with adding a line-item for security (If I don’t pay extra you’ll make it insecure?). So let’s assume that you created a really amazing, brand-new sauce. You can’t charge extra for the sauce, but you can include pricing to reflect that value in the overall price of the pie.
Security needs to be priced similarly – namely, since people already assume there is security baked in, you need to include that pricing in the overall cost in a way that doesn’t encourage people to skip it to reduce costs. For many organizations this can include listing security personnel on project plans at a zero dollar bill rate, or to include security in the overhead charged to cost centers for general IT services.
The key take-away is to ensure that you price security to extract value but not so high as to encourage circumnavigation.
