Posts Tagged ‘Compliance’

IT Risk, Security and Money

June 19, 2008

I read an extraordinarily good post this week by Bruce Schneier on how to sell security.  Or perhaps more accurately: what thought process IT security buyers go through when deciding to purchase (or not).

I’ve had the luxury in my time of having ultimate responsibility for selling content security (anti virus/spam) products, database security products and now network access security products.

I have observed first hand the “cost of insurance vs. probability of negative outcome” calculus.  No one questions money invested in Antivirus solutions because everyone knows that the probability of a negative outcome without AV is a virtual certainty.  Same with SPAM.  They might wish for more effective insurance for the money.  They might question whether they need yet-another-layer to really solve the problem – I remember arguing that gateway scanning was important and getting almost no uptake until the Melissa virus came out and demonstrated that the next generation of viruses were going to be transmitted by email, not by floppy disk.  But at least a basic level of insurance is a given.

When selling database security solutions in the earliest days of that technology I saw the opposite calculus.  IT’s almost idealistic belief in the impenetrability of the applications they had developed to front-end their databases.  In those cases our best sales tactic was to ask if it was OK if we tried to perform a SQL injection or cross-site script in a lab environment just to “test our tools”.  We could routinely demonstrate that applications were easily penetrated.  Suddenly database security solutions jumped up the priority list a few notches in organizations with a lot to lose.

The Societe-Generale “situation” vaulted insider security into the collective security consciousness.  We’re still working out the risk vs. cost-of-insurance calculation.

But for the most part, as a life-long security solution purveyor I have found that every discussion becomes a risk vs. cost discussion.  And when the risk we’re addressing becomes the next most painful one on the list we will get a serious hearing.  That’s why good sales people learn very quickly to look for “compelling events” or to simply ask, “where does solving this problem rank on your current priority list”.  If your prospect cannot demonstrate that it’s under broader (than just themselves) organizational consideration somewhere in the top 5 (or perhaps 10 if it’s a larger organization) prepare yourself for a long sales cycle.

Now security is starting to become somewhat synonymous with compliance.  And that has given us the idea that if we just say our security product solves a SarbOx problem the budget will be instantly available.  But go to RSA and walk the floor and you will very quickly realize that when 1,000 vendors proclaim that they are solving the compliance problem in subtly different ways, a prospective customer could not be blamed for putting the clutch in for a bit while sorting out what they really need; no matter how dire we paint the consequences of inaction.

I have no end-world-hunger solutions here but I will say that I’m gravitating toward at least one small solution.  Let’s call a spade a spade.  Tag this: “Security is not Compliance”.  And trying to solve compliance problems with a security solution is likely to be kind of like trying to reduce the cost of oil by invading Venezuela (now this post will show up on the NSA radar screen) – there has to be a more cost effective way.  I’m leaning toward this Compliance or Auditing as a Service (CaaS or AaaS).  And in developing a go-to-market model around this I’m starting to think that many things in IT could benefit from at least someone thinking about the problem from an “As a Service” perspective.  The business model might not be there in all cases.  And politics within IT might present too great a barrier in others.  But when you start thinking about all IT problems the way Google and Amazon are likely thinking about them, perhaps we might find ways to offer more security capabilities as a utility.

Which just might make the cost of insurance negligible enough to make good security a no-brainer deal.

Advertisements

IT Audit Rule #3: Compliance is not a byproduct of an Audit

April 29, 2008

IT Audit Rule #1: An Audit Is An Arms-Length Process (e.g. a system cannot audit itself)

IT Audit Rule #2: IT Audits Don’t Prevent Loss

IT Audit Rule #3: Compliance Is Not a By-Product Of An Audit

This statement should be pretty obvious from the discussion of Rule #2. But just as a refresher. And audit is a measurement and verification tool. In the compliance case, about whether an activity and a state complies with whatever standard you’ve chosen to be compliant with. But an audit doesn’t make compliance happen.

A while back there was an interesting debate between Mark Macauley and Ian Glazer about Compliance and whether it could be delivered as a service (CaaS). At the end of Mark’s final response on the topic he uses these words – rather intentionally I suspect: “Compliance is 100% cost at the end of the day, and companies who have figured out that it is in their best interest to automate every process to be compliant, and automate the measuring of that process……….”

Let me take the liberty of making a taxonomy out of that:

– “automate every process to be compliant” = automation which channels behavior in acceptable ways (e.g. user provisioning).

– “automate the measuring of that process” = automation of an audit

Audits can measure compliance, but not make it happen…..except in the limit, where audit findings prompt better mechanisms to channel behavior in compliant ways. Again, this point is probably an obvious one but I continue to be surprised every time I have a discussion with someone about how to get an audit tool so they can “be compliant”.

Compliance, Identity and the SME

February 1, 2008

Matt Flynn brought this article to my attention. At the surface it covers an important topic. Typically software vendors get stars in their eyes over Fortune 1000 size clients while the vast majority of enterprises are not able to consume solutions designed for the “biggies”. So, interesting topic. But I found the premise a bit disingenuous. Particularly the line of logic expressed here by one vendor (condensed with names excised)….

“Most small to midsized enterprises have far fewer IT professionals on staff to manage the overall IT infrastructure, making the user access management issue more critical than their large counterparts,” says (XYZ), senior vice president of (Vendor).

Source: Processor Editorial Article – Automate Role Management & Identity Compliance

So far, so good. Can’t argue with that. Continue please…..

(Senor XYZ) recommends that companies seek out vendors that [also]……..have a strong consulting services capability with an implementation and management methodology that has been used successfully in the field at several different types of organizations.

Now, we’re off the reservation a bit. Having been an IT guy in a small organization (~700 users) in my very distant past I will say that if a vendor ever said, “you should buy my solution because I have good consulting services” all kinds of alarms would start going off.

My immediate response would have been, “if this solution requires vendor expertise to get it to work for me then it’s not designed for an SME like me.”

I actually think Europe is generally more forward thinking than the US enterprise in this regard. Generally, in EMEA, a key test of a product for a prospective buyer is if they can run their own Proof of Concept; No vendor Sales Engineers or consultants allowed. If the vendor insists that only one of their sale engineers or consultants can get the product working right – well, Failure Condition #1.

Admittedly most SME’s would love to get that kind of attention from any ISV. But most also know that the attention is fleeting. And when the next version of the product is released or when the use environment changes and the vendor’s solution needs to be reconfigured – good luck getting that level of attention again.

That’s not to say that an SME wouldn’t be well advised to pay a local integrator or reseller to deploy a solution for them. That’s a judicious use of resources. But any time you have to rely on the vendor to get it to work right…..that’s just an extended bout of heart-burn waiting to happen. Maybe Big Money Center Bank can invest that kind of cash resources and mindshare in a solution on an ongoing basis. But Regional Community Bank With Ten Branches probably can’t.  Or shouldn’t.

Cost of Compliance

January 29, 2008

Deloitte’s Center for Banking Solutions published an interesting study on compliance based on a survey of 20 of the top 50 financial institutions in the U.S. As my friend Mark Macauley (his identity blog) has said to me many times, “compliance is a cost center”. Here are a few excerpts from the study that I doubt are unique to financial institutions….

  1. “As costs have risen, financial institutions appear to have responded more by applying people resources to monitor compliance versus technology resources to manage it. “
  2. “Only 10% of financial institutions reported that compliance information was always effective and 15% that it was always timely.”
  3. Compliance related spending has jumped from 2.83% of net income in 2002 to 3.69% in 2006.
  4. Of compliance spending, 18% was for computing infrastructure (hardware, software, etc) while 60% was for compensation (people presumably).
  5. Overall 95% of the respondents reported that their management and administrative employees were spending more time on compliance than before and fully 40% saying that the time they devote to compliance has increased by 22% to 25%.

Ouch. Talk about an area of opportunity for improvement.

Identity Provides Security Context

January 3, 2008

We were talking to Eric Norlin about 2008 trendspotting. Given NetVision’s core raison d’etre we see a growing groundswell toward what we are calling “context” (see Eric’s post). Eric expanded our definition – which is good. But let me clarify what we mean for in our narrower definition for a second.

What we’re seeing is identity management monitoring (at least in a corporate context) being used as a stalking horse for achieving proof of compliance and risk management regarding the insider threat. As in: “I am required to demonstrate that I have control over admin rights so I need to monitor this group membership for all changes”, and other similar examples.

What we’re also observing is that providing such security (or evidence thereof) requires trolling through a lot of event data – often after the fact. As a result we’re seeing more and more customers asking us to link our risk assessment product with our change auditing product so that the search for risky behavior isn’t unguided. That’s what we mean by context. Instead of looking at the universe of data after the fact in order to document a conclusion you instead target your data gathering to areas of risk and obvious policy violation in the first place.

I am no expert on the subject of listening in on the phone calls of the world to find evidence of a threat to national security. But I believe what we’re talking about is metaphorically equivalent to whatever the national government does in order to decide what to listen to.

The question we hope to answer is: “Can this be done without creating a false negative” or overlooking a breach of security or policy which doesn’t rise to theoretical definition of risk. More on that later but opine if you have one.

Is compliance possible?

December 10, 2007

This excerpt from an article caught my eye this morning

Compliance is hardly rocket science-or is it? Directives to use firewalls and change vendor-supplied default passwords are simply security best practices. But in other areas, merchants struggle to interpret the standards, haggling with auditors, consultants and sometimes the PCI Council itself over exactly how to protect cardholder data.

Source: Can mid-market merchants comply with PCI standards? – Network World

It’s referring to the difficulties faced – in particular – by mid market companies in achieving PCI compliance but the principles apply in other regulatory areas too.  It’s a point I made in our whitepaper.  The unfortunate reality is that unless there are very clear requirements defining “success”, many companies will spend unnecessary dollars trying to stay in front of an ill-defined process.  My friend Matt  Flynn (also from NetVision) has put some thought into at least one aspect of this problem that he has published in his blog and on the NetVision site as a whitepaper on “Surviving an Identity Audit”.

Policing the Power of Identity – Security by and for Identity

December 3, 2007

I recently published a whitepaper entitled Policing the Power of Identity. It’s a vision (mine anyway) for the future use and success of identity in corporate computing. Use of identity gives us a “handle” to use in consistently assessing, analyzing, monitoring, etc. insiders. We developed multiple, fairly mature disciplines for dealing with “outsider” threats (firewall, IPS, anti-SPAM, anti-virus). We should have the same goal with protecting ourselves from insider threats – which are prevalent.

I could be accused by a reader of this whitepaper of giving the impression that I think identity is the problem. That’s not the case. But as corporate IT uses identity more exhaustively for all its good purposes then identity becomes a handy mechanism for identifying insider threat – both potential and realized. This process could most accurately be described as “Policing Computing Power BY (using) Identity”. But also, casually used, identity can create a false sense of security. And in such an imperfect-use scenario identity itself can be a problem (or more accurately, poor identity management can be a problem). In that case the process we prescribe is accurately described as “Policing the Power of Identity”. And such cases are exceedingly common if our IT customers and contacts are any indication.

Either way, our goal is never to attempt to cast identity itself as bad. But instead, to identify practices, tools and standards that use identity to provide better security and to improve identity management (aka security) practice. Along the way we believe that proof of compliance with regulations, policies or best practices will be a natural by-product of our efforts; at least in the area where identity is implicated.

If this sounds like an interesting line of discussion to follow, join the conversation or let me join yours. We’ve had a number of offline comments back on the premises in the whitepaper. I’ll add those to this blog in imminent posts.