After 26 days, and almost 350 million e-mail messages, only 28 sales resulted -- a conversion rate of well under 0.00001%. Of these, all but one were for male-enhancement products and the average purchase price was close to $100. Taken together, these conversions would have resulted in revenues of $2,731.88 -- a bit over $100 a day for the measurement period or $140 per day for periods when the campaign was active. However, our study interposed on only a small fraction of the overall Storm network -- we estimate roughly 1.5 percent based on the fraction of worker bots we proxy. Thus, the total daily revenue attributable to Storm's pharmacy campaign is likely closer to $7000 (or $9500 during periods of campaign activity). By the same logic, we estimate that Storm self-propagation campaigns can produce between 3500 and 8500 new bots per day.

Under the assumption that our measurements are representative over time (an admittedly dangerous assumption when dealing with such small samples), we can extrapolate that, were it sent continuously at the same rate, Storm-generated pharmaceutical spam would produce roughly 3.5 million dollars of revenue in a year. This number could be even higher if spam-advertised pharmacies experience repeat business. A bit less than "millions of dollars every day," but certainly a healthy enterprise.

Of course, the authors point out that it's dangerous to make these sorts of generalizations:

We would be the first to admit that these results represent a single data point and are not necessarily representative of spam as a whole. Different campaigns, using different tactics and marketing different products will undoubtedly produce different outcomes. Indeed, we caution strongly against researchers using the conversion rates we have measured for these Storm-based campaigns to justify assumptions in any other context.

Spam is all about economics. When sending junk mail costs a dollar in paper, list rental, and postage, a marketer needs a reasonable conversion rate to make the campaign worthwhile. When sending junk mail is almost free, a one in ten million conversion rate is acceptable.

News articles.

• Corporate desktop image
  
• Outlook 2003
• Symantec AV
• PGP-8.1
  

1. Install PGP-9.6
2. reboot twice per instructions
3. Find that my networking completely doesn't work.

1. regsvr32 /u PGPfsshl.dll
2. Run a Registry merge on c:\WINDOWS\system32\PGPlspRollback.reg
3. Reboot

I say today is a good day for two reasons:  1.)  BT’s CSO Jill Knesek wrote an article called “Keys to establishing an end-to-end security strategy” which begs some discussion within context, and 2.)  Sara Peters on Twitter last night wanted to know why I thought “risk management” requires more than what most “best practices” around the subject suggest the effort requires.

WHAT SHOULD WE BE REFLECTING ABOUT?

Jill Knesek’s article gives us a rough outline of how to develop a security strategy.  It’s fairly high-level, Pragmatic CSO-ish type stuff.  It gives us a nice outline of

• Get a seat at the table
• Process
• People
• Technology

Nothing earth-shattering there.  But it is a very nice broad CISO-level taxonomy about what we have to reflect on.  The need to reflect is driven by something Jack told me long ago,

“The amount of risk we have is a function of the decisions we made and our ability to execute on them from some point in the past”.

As an Aside:  So Sarah if you’re reading, this quote does much to explain why I said I disagree with much of what our industry calls “risk management”.  We tend to define the process of risk management as essentially a tactical “issue whack-a-mole” exercise. Find the issue.  Analyze the “risk” around the issue.  Fix the issue.  Repeat. This hamster-wheel-of-pain, while sometimes an effective tool for the CISO, is incongruous with addressing root causes (the ability to match a tactical issue to the strategic shortcoming that created the issue is up to the expertise of the analyst or consultant).  It is only Kaizen without (good) Hansei, if you will.

Back to what Jill is writing - the sorts of things we should be reflecting about can be thought of in context of her outline.  Namely:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?  How do I know that the training they petition me for will effectively reduce organizational risk?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Knowledge could they provide me with (to make good decisions and execute upon them, from above)?

This, for the CISO, is Hansei.  The continuous management of it is Kaizen.  Not to particularly pick on Jill’s article, but creating a “risk register expressed in ALE” might be fine if you’re trying to explain to the board what your “first 100 days in office” will be like - but these sorts of lists are usually not very strategic in nature, and as such, depending on the outcome of that risk register (and the models used to create it) it might not actually be useful.

WHAT IS NEEDED FOR REFLECTION?

So what is needed for this sort of CISO-level Hansei?

The CISO must understand the

• Current State of Nature

turn that into a

• State of Knowledge

and use that to create a

• State of Wisdom.

CREATING A STATE OF NATURE FOR THE IRM PROGRAM

This Current State of Nature determination be done by applying analytical methods to a program audit.  We must understand questions like,  “What is in that program and how is it structured?”  before we can answer questions about “how (good/bad) are we at managing risk?”

There are many ways to structure an IRM program, but as an example - below is a graphic shared with me by Adrian Seccombe.  For those who know Adrian and the Trust Model - this is classified as “white” so it’s OK for public display and consumption.  But here’s what Adrian is trying to build at a high level:

So regarding Adrian’s program diagram:

1. Is a governance framework.  Think ITIL.
2. Is a risk framework.  Think ISO 27002 using FAIR as an analytical engine.  To be fair (pun) I believe this is really issue management, and it’s a process, but that’s OK.
3. Reg compliance should be self explanatory.  That’s essentially what GRC products do for you.
4. With architecture, I think Adrian is inclined towards TOGAF.
5. Security is the ISMS in place (27001, ISM^3, PCI, whatever…)
6. Are the processes that drive execution
7. Monitor (audit) is creating a State of Nature and Evaluate is creating a State of Knowledge from that State of Nature around items 1-6.

EVALUATE - CREATING A STATE OF KNOWLEDGE ABOUT THE IRM PROGRAM

That evaluate is Hansei/Kaizen.  Evaluation, done effectively, will drive actual organizational risk exposure.  Evaluate will even answer those four questions we raised in the “What Should We Be Reflecting About” section above:

1. Once you have a seat at the table, what is the nature of that relationship?  Who are you reporting to and what are their concerns? What and how are you reporting and how might that be addressing their concerns?
2. What processes are in place?, How do you know that those are the processes that should be in place? If they are, what kind of job am I doing at those processes?
3. What is the quality of the skills and resources I have from a people perspective, and how do I know if they are adequate?
4. Are the Technology solutions I have in place effective, are we managing them effectively, and what sort of States of Wisdom do they provide me with (to make good decisions and execute upon them, from above)?

If we could have a nice metric (or set of metrics) that answers these questions, we might call it something like “My Ability To Manage Risk” or MATMR for short.

GETTING TO A STATE OF WISDOM

What’s then missing is how you create a State of Wisdom around the State of Knowledge developed - your “MATMR” metric.  That is, given the current State of Knowledge - how can I be most effective?  This State of Wisdom requires proper models for what risk is, and what you can do to manage it applied in a probabilistic manner (because we can’t intrinsically *know* the future, we can only say with some degree of certainty what the desired course should be).

So the outcome of Hansei/Kaizen should be to create a State of Wisdom about Risk Management.  This is why reflection must be relentless - because your wisdom must be similarly abundant.

This is no small part of the reason RMI exists, why we build software and help organizations understand the things they do.

Today, however, I discovered a huge security breach in Google Docs. While I was in my account working on a spreadsheet I suddenly found my Google Doc account listing many documents that did not belong to me. I clicked on one of the documents and the results are in the image below, where my Google Doc session appears to have “crossed over” with another users.

I decided to do a bit more exploring and take a few more screenshots, because I don’t yet know how to reproduct this security breach. The image below show a Google document (fifth from the top) which is not owned by me, “owned by me”. However, when I click on this mysterious “owned by me” document, it is owned by another user. Here is another screenshot below; you can click on the image for the full-screen version.

Again, here is another example of the same security violation with two documents. As above, you can click on the image for a full-screen version.

I contacted the owner of the Google Docs account which I had suddenly and mysteriously “crossed sessions” with today. I asked him if he was in Thailand (since a few of the documents were in Thai) and he said yes, however he say he did not have any Thai language documents in his account. However, as you can see from the screenshot, the Google Docs menu shows this person as “the owner” of a Thai language document. He also mentioned that, today, he saw “wierd documents” in his account that did not belong to him (or “normally” shared with him).

Unfortunately, I was having problems with the Internet connection in my hotel room so I could not continue to investigate the breach. When I logged back in a few hours later, everything was back to normal. So far, all is “normal” and I have not been able to repeat this breach.

I suspect the Google Docs flaw comes from a JavaScript error in how Google manages user sessions. The bottom line is that the security breach is real and dangerous. Your Google Docs, and I suspect other Google applications that use the same session management code, are vulnerable. There may be an underlying XSS vulnerability as well.

Note: Reposted from my original post on the ISC2 blog.

• Certified Information Systems Auditor (CISA) : http://www.isaca.org/cisa/
• Certified Information Systems Security Professional : https://www.isc2.org/cissp

Are You Ready ?
A few basic questions to ask yourself to gauge how ready you are:

• Do I meet the spirit, and not just the letter, of the experience requirements ?
• Has there been sufficient diversity in my experience ?

Five Step Approach to CISA or CISSP Exam Preparation

1. Perform an initial benchmark and assessment of your readiness
2. Read a “survey” level preparation guide cover to cover
3. Perform a secondary benchmark, and compare your readiness
4. Review official, or “deep dive”, preparation materials on areas identified as your weaknesses
5. Re-benchmark, and repeat targeted reviews until ready

CISA and CISSP Preparation

We’re calling this part II - and it’s being advertised as:

“How to conduct a risk analysis and produce a high impact deliverable to senior management.”

With topics:

• The life-cycle of a quantitative risk analysis
• Key control opportunities against targeted attacks
• Getting senior management to understand the risk posed to the business

I got to do the Q&A backchannel on the last presentation, and there were great questions asked.  I think this presentation will be even more exciting, as it’ll cover both analyst and management considerations.

If you’re a regular reader of the blog, I don’t think you’ll have to have attended the last one for this one to be worth your while.

REPEAT PERFORMANCES OF THE FIRST WEBEX ARE AVAILABLE

And if you missed it the first time, the playback of the first preso is here, and the slides are here.

What makes me say this is the amount of redundancy in some testing that I’ve seen without any value added.

The way to avoid this redundancy is the concept of common/shared controls.  The whole idea is that you take whatever security controls you have across the board and put them into one bucket.  You test that bucket once and then whenever something  shares controls with that bucket, you look at the shared control bucket and make sure that the assessment is still relevant and accurate.

So, what makes a security assessment not fraud, waste, and abuse?  It’s a good assessment if it does the following:

• Does not repeat a previous assessment.
• Discovers previously-undiscovered vulnerabilities, weaknesses, or findings.
• Has findings that get fed into a risk management plan (accepted, avoided, transferred, etc–think POA&M).
• Is not exhaustive when it doesn’t need to be.
• Provides value to the project team, system owner, and Authorizing Official to make key decisions.

Now the problem is that the typical auditor has a hard time stopping–they have an ethical obligation to investigate anything that their “professional skepticism” tells them is out of place, just like cops have an ethical obligation to investigate anything that they think is a crime.

The Solution?  Don’t use auditors! The public accounting model that we adopted for information security does not scale the way that we need it to for ST&E, and we need to understand this in order to fix security in the Government.

What we need to be doing is Security Test and Evaluation which is focused on risk, not on compliance using a checklist of control objectives.  Usually if you know enough to say “Wow, your patch management process is whacked, you’re at a high risk!” then that’s enough to stop testing patch management controls.  This is one of the beefs I have with 800-53A in the hands of less-than-clueful people:  they will test until exhaustion.

There isn’t a whole lot of difference between ST&E and an audit, just the purpose.  Audits are by nature confrontational because you’re trying to prove that fraud, waste, and abuse hasn’t occured.  ST&E is helping the project team find things that they haven’t thought of before and eventually get the large problems funded and fixed.

The Little Frauds Harrigan & Hart’s Songs & Sketches Photo by Boston Public Library

Bookmark to: