Access Audit as a Service

NetVision announced our new Access Audit Managed Service offering today.   After years (more than a decade – in fact) of providing software tool sets to our customers we saw a distinct outcome in some customers.  This outcome is fairly common to Enterprise Software overall.  The problem outcome is under-utilization.

Frequently a compelling event such as an audit or a technology migration surfaced the need to measure something discrete.  And tools were bought.  And one of four ouctomes occurred:

1) Successful deployment, value is realized as expected or more (yeah for everyone!)

2) Never deployed.  Shame on everyone – vendors hate this probably more than the buyer hates it.

3) Deployed and well used but champion left the company.  And no subsequent champion stepped into his/her shoes so practices, methodology and value start a downhill slide

4) Deployed but for a very narrow, unsatisfying purpose.  The bloom is off the value “rose” pretty quickly.

Thus our impetus for SIMON (it simply stands for Simple Monitoring).  Our goal is to be able to deliver best practice as an outcome rather than as a capability.  Some of our customers prefer the DIY (do-it-yourself) strategy – that’s fine with us too.  But for those who cannot dedicate a methodology champion or who recognize the problem but perhaps not the breadth of the solution that is available, SIMON delivers the entire methodology and service management so that the customer can just consume the result.

IT Risk, Security and Money

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.

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

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”.

IT Audit Rule #2: IT Audits don’t prevent loss

Sorry to leave this topic open for so long since the last post. Financing activities take top priority for a private company….enough said.

Let’s talk about IT Audit Rule #2. Remember these are my rules, not an official set of commandments. But based on some experience in auditing.

IT Audit Rule #2: IT Audits don’t prevent loss.

Security’s intent is to stop loss. Audit’s intent is to verify the accuracy of something; typically by checking a sample of outcomes but also by making sure that critical controls are functioning. The theory of an audit is that if the right controls are consistently working then the thing being asserted (in this case your data’s accuracy or the state of your data security or privacy) is probably accurate.

Does an IT Audit help security? Absolutely. It will help to point out where weaknesses exist; where controls might be needed to prevent loss or inaccuracy.

And here’s one of the beauties of technology and automation. You literally can audit every event as it happens with automation. So instead of sampling a few transactions and seeing if the outcome was right, you can audit every transaction to see if the outcome was right. Not only that it occurred (see last post for flaws of IdA products for auditing) but that it was right.

But here is the Corollary to Rule #2: Don’t ask an IT Audit product to provide security. For the simple reason that if an IT Audit product now is reversing or stopping inappropriate events, it can no longer be trusted to audit (See Rule #1). It is tampering with the evidence of whether the processes and controls it is auditing are actually working.

Two separate processes need to exist in IT. The security process that tries to create an outcome. And the IT Audit process which verifies that the security process is working. If you have the option, don’t trust the vendor providing one solution to provide the other (Back to Rule #1).

IT Audit – What is it?

If you search on “IT Audit” you will return pages and pages of relevant hits. I have no idea how many pages you have to go out before you hit the end of relevance but it’s more than I care to read. And here I am adding one more.

How can I sort out what I need to do about IT Auditing between what the audit firms, vendors, government (regulation), upper management, and Board compliance committee are telling me to do?

I spent just enough time as an internal auditor and an external auditor in my misspent youth to have yet another opinion to express and I’m going to use a couple posts to do it.

When it comes to IT Auditing, the value that should – in theory – be derived is that an uninterested party (not you) can attest with reasonable certainty that what you SAY you are doing is actually what you are doing. Those policies you say are protecting your mission critical information? They’re actually being implemented and followed (two separate tests there) .

There’s a month’s worth of blog fodder there. But to close for today let’s drag out Rule #1 of IT Auditing. It is not possible to audit yourself. Unless you are the only person you need to satisfy with an audit.

By way of example, in Identity Management circles there is a tendency to call something an Identity Audit (IdA) tool if it creates a record of an activity executed by an Identity Management System (IdM). This would, according to Rule #1, be a valid audit if the IdA tool were completely independent of an IdM tool (not from the same vendor for example) and whose audit strategy (implementation and configuration) was controlled by an independent party from you. But most of these tools are not independent of the tool they audit and therefore are incapable of satisfying Rule #1 of Auditing. We could call them attestation tools (they attest to what was done) but they are not audit tools.

Human Error or Human Misbehavior

Many minds seem to be wondering something like this: “is an organization’s data more at risk from an insider (employee, contractor, etc) purposely doing damage or from a well intentioned employee?”

It seems to be a relative certainty that one of the two represents the largest risk to an organization’s data.  I read this article about a Deloitte survey.  To the point that 91% of those surveyed said they were worried about the risk of employee misconduct related to information technology.  I’d call 91% many minds.

When I was at Trend Micro we used to say that there would always be a virus threat as long as there were humans using computers.  It has become trite to suggest that virus writers relied on the thoughtless-but-innocent behavior of users.

But is that also true when it comes to damage done by insiders? I would hypothesize that in absolute dollar numbers the highest risk of loss due to insider behavior is probably also from the well-intentioned person trying to do their job.  I won’t elaborate here on that topic because Matt Flynn has recently done that very well in a recent discussion with IT Business Edge.

Does the distinction matter?  When talking about insider security solutions with IT professionals  many times the conversation gravitates to concerns about a few malicious people often concluding that the real need for insider security solutions is confined to a few people who are so malicious that they cannot be effectively stopped.

I suspect that if the real economic damage to organizational data from all sources could be accurately charted we would find the most compelling justification for securing against inadvertent harm from insiders.

Compliance, Identity and the SME

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

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.

Context and Identity again…

When Dave Kearns makes a prediction you better think about betting on it or at least pay attention. From his 2008 predictions….

Risk management, which I lump under context-based access control (CBAC), will become very important in 2008.

Source: Risk management and access management come to the fore in ’08 – Network World

So that’s at least the second pundit using the word context in predictions. If I get his drift, Dave is predicting that risk awareness will become a key component to determining access. So context drives smarter preventative controls. Can’t disagree with that.

I believe that risk awareness will also be a key component in determining audit requirements, proof of compliance requirements, monitoring requirements, etc. So context drives smarter detective controls and processes too. I think this will be particularly true given the recent Audit Standard 5 guidance [for a full text treatment] given to auditors which encourages “auditors to use professional judgment in the 404 process, particularly in using risk assessment”.

Is Your IT Policy Working? IT Quality Assurance

This statement grabbed my attention this week. Mostly because it seemed to be concisely obvious (a good thing).

“You can generate all the polices that you want, but unless you have some kind of monitoring and enforcement mechanism, you don’t know if a policy is working or not,” says Bob Gorrie, information security project manager at USEC, a supplier of enriched uranium fuel for commercial nuclear power plants based in Bethesda, Md.

Source: Data loss start-ups sell out – Network World

Having spent more than a few years at Intel (read: manufacturing) I often view IT processes and relate them to manufacturing practices and see parallels. In a manufacturing world you would never think of establishing a process without establishing control limits and tests to tell whether you were operating within control limits. It would be a disaster for manufacturing to “run off the rails” and for you not to notice it until large quantities of defective goods were produced.

I think the same methodology (design process, design tests) is hugely beneficial to IT. Hooray for you (truly) for you if you are a practitioner of the “process determines results” school of thought in IT. And that you have great policies, broadly communicated and understood and practiced. But frankly, if you don’t have a way to routinely tell if your policies and processes are working the way you intend, you’re missing IT Quality Control.

In the context of NetVision, If you have great role definition and automation and processes for giving out rights and managing identities but you don’t have an arms-length (read: independent, 3rd party) check on the state of the system and the effectiveness of your controls – you probably are missing the element you need to stay on track for your desired goals and to improve.