Osama Bin Laden Death Photos Not Needed for Proof

Blogs are clamoring for proof that Osama Bin Laden is dead–show us the photos! However, I do not think Osama death photos are needed, at least not to prove he’s dead.  I also think that keeping this event in mind can help move your audits along. Let me explain.

Some say you have to believe Osama is dead because it would be hard to believe that Navy Seals would go along with such a fiction if he weren’t dead. Others say the political price of being found out perpetuating such a hoax would simply be too high.

For me, the best proof has to do with what hasn’t happened: Osama hasn’t shown himself.  The easiest way to show that the Obama administration is lying is for Osama to demonstrate it himself.  So how does that relate to your audits? Let me provide some background first.

I sure hope during the scope of your audit that you publish periodic status reports of your progress and any observations you’ve found. I recommend you have some kind of a disclaimer stating that observations are findings that may be changed after more evidence is available.  I’d also reinforce this in your opening meeting and when you discuss a finding with your auditees prior to publishing it in your status report.

Sometimes, it can be hard for auditees to produce the evidence you need, especially in a timely manner (in 2 companies I’ve worked in, this was 2 days after the request). For example, let’s say I’m seeking evidence that IT reviewed, tested, and deployed a critical patch within X days of vendor release.  Most of IT teams I’ve audited don’t document their progress very well as they execute their procedures, even though the procedure stipulates specific time frames for completing each step.

So after 2 days, even though I’m told they followed the procedure and are still looking for the evidence, I write up an observation stating that no evidence was provided.  This accomplishes one of the following: 1) IT stops “looking for evidence” since everyone knows they don’t have it, because once a finding is published, the game of IT stalling the auditor is over, or 2) IT suddenly produces the evidence because the heat is on now that the manager (and usually directors and VPs) are on the hook for the finding, now that it has been published.

Just like Osama can easily show Obama is wrong by producing himself, IT can invalidate a finding by producing the evidence.  Either way, once Audit does its due diligence and publishes a finding, regardless of IT’s response, Audit (and the company) wins.

Leave a Comment



Filed under Audit

8 responses to “Osama Bin Laden Death Photos Not Needed for Proof

  1. Sherr

    Sorry, but your article misses the point. Osama hasn’t shown up in 7-10 years. So does that prove that he is dead for 7 years?


    • Sherr,
      You have a good question. However, one thing changed recently that wasn’t true the past 7-10 years: Obama claimed that special forces killed Osama. While Osama was in hiding, he was still able to terrorize people by appearing in a video once in a while. People were still afraid of what he COULD do.

      However, once an official organization (the gov’t) claims you’re dead, it’s kind of hard to terrorize folks – especially from the grave. So if Osama was alive, I doubt he’d miss the chance to make a fool out of our president AND let everyone know he’s still armed and dangerous.

      I’ve found the same principle works in Audit. Once you publish a finding, auditees love to prove you’re wrong. And even if that happens, it moves the audit along.


  2. Pingback: The Osama Bin Laden Photos « David's Blog of Common Sense

  3. Insane but awesome analogy :)

    But to the doubters, the fact that even Al Qaeda is ‘playing along’ and admitting it is akin to management “accepting” the finding too. Unless you’re wearing a tinfoil hat and everything is a conspiracy – in which case no one here can help you.

    Random source in support of this POV: http://ibnlive.in.com/news/al-qaeda-to-release-osamas-last-audio-message/151552-2.html


  4. Very nice work weaving these two strings together. Certainly we could all spend less time chasing wild geese if we followed your approach.

    Similar principle behind a test short-cut I’ve used to great effect : When looking at a user access approval, rather than sample testing initially, I sometimes start by asking for evidence of the most recent time a request was declined. In the (surprisingly frequent) instances when one can’t be provided, it is fairly straightforward to draw a conclusion that the control is ineffective, and with minimal work I can move on. Not universally applicable, but depends on the process.


    • Cow,
      I’m not sure whether your comment was tongue-in-check, similar to your blog. I’ll assume you were serious in my reply…

      While I like shortcuts, how can you conclude that the control is effective when they can’t produce a denial? Could it not be possible that no one inappropriately requested an account and was denied?

      While I’ll admit it may not be likely, I would still have trouble concluding the control is ineffective based just on that. I noticed your last statement, which gives you an out….want to provide some examples of processes in which you felt this was an effective test (real ones, not made up ones–you’re on my blog now :)


  5. I was indeed serious about this one (although its hardly my natural style). My position is basically that if a process is prone to error, but no errors are reported, then it is too good to be true. So in this case if it is possible to submit a request without proper authorisation, but this has never been found, then the security administrators aren’t being thorough.
    A couple of conditions make the conclusion more robust:

    1. The approval method needs to have some realistic margin for error. So not heavily automated or subject to upstream controls. An example of an unsuitable mechanism would be a request for access based on an HR system flag – where someone has moved into a department, the HR process generates a request for system access to the relevant applications or directories. This mechanism might not allow improper access requests through. A good example would be a manual step of approval in an unlinked system, preferably one with limited data input validation.

    2. There needs to be a reasonably high volume of traffic through the approval method. There would need to be enough requests so that over time, the probability of error becomes statistically significant. Assuming a 1% chance of error (for example), you might want to see that step completed a few hundred times before you would reasonably expect to find one exception. I would guess 1% is lower than real life where non-security types are involved in the approval mechanism, unless they are guided along by a helpful tool.

    So say it’s a situation where the user logs in to a system and requests access, and then nominates who will approve the request from a company-wide directory service (say AD). If the security administrator needs to manually look up a different system to validate that the approver is on the current list (this might be a spreadsheet of authorised approvers for each directory or application), and is in the same department as the requestor, there is a possibility of manual error, say because the user chose their line manager to approve rather than a system owner, and the administrator should pick that up and reject the request. My conclusion is that if no errors have been identified, if the administrators have never found that a user has entered the wrong approver, that this check is not being performed in a reliable way.

    The only alternative explanation is that untrained users are miraculously surpassing a 99.9% quality standard, and I think if you cast your eyes across any sort of process compliance figures you will agree that we can often reject that possibility without too much supporting evidence …

    Very hard to give concrete examples from my life, unfortunately, but if you will excuse a little poetic license … I first found this approach useful when I was looking at an archaic, stand-alone, text-based sign-off application. The administrators needed to manually look up part of the access requests, for temporary local admin or similar, on this system to validate that it was approved by the relevant platform owner. I asked for an estimate of how many unapproved requests come through each month, and no-one could answer me. So I asked someone to show me a recent example where they had checked the system for approval and found a problem with it. Again no-one could remember ever finding a problem. I then took a walkthrough this part of the process to find that the administrators did not have access to view the approvals! They later admitted to me (not in front of management) that they assumed that having a reference to an approval record meant that it was OK, and they didn’t ever look further.


Leave a Comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.