Marc’s initial shoplifting model in his post is based on John Colapinto’s concepts of matching a pattern of customer movements in the store with their estimated patterns of shoplifting behavioral patterns.    Marc’s asks how Coral8 might address this.   We are not ready to seek a vendor solution.  We do not yet have a workable detection model.

As indicated above, I don’t think the example situation cited by John and Marc is a viable model for automated processing.    Tracking the behavior of customer’s movements, by machine, would require some very sophisticated image processing technology that would be too expensive compared to any possible loss at most retails stores.    This type of behavioral pattern recognition. in retail stores, is performed by people (security personnel), not machines, observing people.  

To develop a machine pattern recognition application to detect retail shoplifting we need to build detection models that are economically feasible.  If we are going to use a model of shoplifting pattern recognition versus anomaly detection, we need to define the objects we must track.  

In the most simple model, we have merchandise-objects.   Stores normally (physically) track merchandise-objects only at the exit/entry points of the store using some electromagnetic proximity detection technology.   In this model, the detection configuration is a combination of simple alerting with humans watching the store (”minding the store”).    This is not complex event processing.

However, if we added another object to our model, the customer-object, then we start to get more “complex,” but we have not defined “complexity” yet because we have not defined the object properties, the possible states of the objects, and the relationships between the objects that are the basis for estimated situations.

Hence, model building is constrained by available resources, simple economics and risk (cost-benefit).  If we are detecting shoplifting in Walmart the cost-benefit model for implementing an automated shoplifting detection system would be different than at a top diamond store on 5th Avenue in NYC.   Protecting loss at a weapons-grade uranium respository follows a different model than protecting loss at a handicraft shop, naturally.

Like Marc, I find models to automatically detect shoplifting interesting, so permit me to close with a general discussion of shoplifting in the context of our CEP/EP reference model.

One approach would be do determine what objects will be represented in our model.   For example, if we are going to track merchandise, we need to model the ”merchandise-object”.  If we are going to track people, we need to define the properties of this “person object.”  If we are going to represent the store layout, we need to define all these objects (store-object, table-object, shelf-object, entry-object and so forth).  The model can get “complex” quite quickly. 

Editorial Note:  An object-oriented approach greatly assists complex model building because we can benefit from OO properties such as encapsulation and polymorphism.  For example, we can define a basic “person object class” and then create superclasses of this object for “customer-object”, “manager-object”, “or criminal-object.”

Generally speaking, each object we define will require a state-model, for example, in Marc’s example of a customer moving around the store, we would need to model the possible states (customer at the entrance, at table 1, at table 2, at shelf 1, in the bathroom, at the cashier, etc.)  Indeed Marc, this is complex event processing if we have modelled multiple objects and defined object-object relationships that indicate situations of interest.   For example, customer-object at table2 where merchandise-object has the property of  ”very expensive, high risk” and then customer-object changes state to “in bathroom”.  Of course, we need more key indicators, but you get the idea.

Right now, I am typing from the Taste from Heaven Vegetarian Restaurant in Chiang Mai and my battery is running low.  The owner of this excellent restaurant also runs the Elephant Nature Park, a non-profit organization advocating and acting on behalf of the rights of the mighty elephants in Thailand.  Would be great if we could also automatically detect the situation of “elephant abuse” by poachers and other crimes against nature.   Time to get back to my delicious mushroom salad, Northeastern Thai style.

As always, thanks for reading, time for me to get back to eating!

This makes the compliance area rife for scammers, who send letters or emails claiming that businesses owe them penalties or haven’t filed the right forms.

Tony Mancuso at Nolo, the publisher of books about corporate forms and law, writes about how to recognize some of these scams.

One official-looking legal letter came into the controller’s office recently. It was from an “agency” calling itself the Corporate Minutes Compliance Counsel, or somesuch, and it strongly advised (warned, really) that Nolo send the Board a payment of $125 to prepare its state-mandated domestic corporation statement. Failure to do so could result in dire consequences, the letter advised, including a loss of corporate status with the Secretary of State.
Nolo’s controller, who has years of experience with real and bogus corporate service solicitations, shredded this letter immediately.

This scam also seems particularly nasty because not only can the scammers steal money from you, they will get valuable information and insight into your private business!

One smart way to avoid these scams is to check anything suspicious–call your secretary of state office or look up the organization who sends you that nasty letter. Or learn more by reading the full article here.

It's become a big deal in IT security, too. Many corporate customers are demanding ROI models to demonstrate that a particular security investment pays off. And in response, vendors are providing ROI models that demonstrate how their particular security solution provides the best return on investment.

It's a good idea in theory, but it's mostly bunk in practice.

Before I get into the details, there's one point I have to make. "ROI" as used in a security context is inaccurate. Security is not an investment that provides a return, like a new factory or a financial instrument. It's an expense that, hopefully, pays for itself in cost savings. Security is about loss prevention, not about earnings. The term just doesn't make sense in this context.

But as anyone who has lived through a company's vicious end-of-year budget-slashing exercises knows, when you're trying to make your numbers, cutting costs is the same as increasing revenues. So while security can't produce ROI, loss prevention most certainly affects a company's bottom line.

And a company should implement only security countermeasures that affect its bottom line positively. It shouldn't spend more on a security problem than the problem is worth. Conversely, it shouldn't ignore problems that are costing it money when there are cheaper mitigation alternatives. A smart company needs to approach security as it would any other business decision: costs versus benefits.

The classic methodology is called annualized loss expectancy (ALE), and it's straightforward. Calculate the cost of a security incident in both tangibles like time and money, and intangibles like reputation and competitive advantage. Multiply that by the chance the incident will occur in a year. That tells you how much you should spend to mitigate the risk. So, for example, if your store has a 10 percent chance of getting robbed and the cost of being robbed is $10,000, then you should spend $1,000 a year on security. Spend more than that, and you're wasting money. Spend less than that, and you're also wasting money.

Of course, that $1,000 has to reduce the chance of being robbed to zero in order to be cost-effective. If a security measure cuts the chance of robbery by 40 percent -- to 6 percent a year -- then you should spend no more than $400 on it. If another security measure reduces it by 80 percent, it's worth $800. And if two security measures both reduce the chance of being robbed by 50 percent and one costs $300 and the other $700, the first one is worth it and the second isn't.

The Data Imperative

The key to making this work is good data; the term of art is "actuarial tail." If you're doing an ALE analysis of a security camera at a convenience store, you need to know the crime rate in the store's neighborhood and maybe have some idea of how much cameras improve the odds of convincing criminals to rob another store instead. You need to know how much a robbery costs: in merchandise, in time and annoyance, in lost sales due to spooked patrons, in employee morale. You need to know how much not having the cameras costs in terms of employee morale; maybe you're having trouble hiring salespeople to work the night shift. With all that data, you can figure out if the cost of the camera is cheaper than the loss of revenue if you close the store at night -- assuming that the closed store won't get robbed as well. And then you can decide whether to install one.

Cybersecurity is considerably harder, because there just isn't enough good data. There aren't good crime rates for cyberspace, and we have a lot less data about how individual security countermeasures -- or specific configurations of countermeasures -- mitigate those risks. We don't even have data on incident costs.

One problem is that the threat moves too quickly. The characteristics of the things we're trying to prevent change so quickly that we can't accumulate data fast enough. By the time we get some data, there's a new threat model for which we don't have enough data. So we can't create ALE models.

But there's another problem, and it's that the math quickly falls apart when it comes to rare and expensive events. Imagine you calculate the cost -- reputational costs, loss of customers, etc. -- of having your company's name in the newspaper after an embarrassing cybersecurity event to be $20 million. Also assume that the odds are 1 in 10,000 of that happening in any one year. ALE says you should spend no more than $2,000 mitigating that risk.

So far, so good. But maybe your CFO thinks an incident would cost only $10 million. You can't argue, since we're just estimating. But he just cut your security budget in half. A vendor trying to sell you a product finds a Web analysis claiming that the odds of this happening are actually 1 in 1,000. Accept this new number, and suddenly a product costing 10 times as much is still a good investment.

It gets worse when you deal with even more rare and expensive events. Imagine you're in charge of terrorism mitigation at a chlorine plant. What's the cost to your company, in money and reputation, of a large and very deadly explosion? $100 million? $1 billion? $10 billion? And the odds: 1 in a hundred thousand, 1 in a million, 1 in 10 million? Depending on how you answer those two questions -- and any answer is really just a guess -- you can justify spending anywhere from $10 to $100,000 annually to mitigate that risk.

Or take another example: airport security. Assume that all the new airport security measures increase the waiting time at airports by -- and I'm making this up -- 30 minutes per passenger. There were 760 million passenger boardings in the United States in 2007. This means that the extra waiting time at airports has cost us a collective 43,000 years of extra waiting time. Assume a 70-year life expectancy, and the increased waiting time has "killed" 620 people per year -- 930 if you calculate the numbers based on 16 hours of awake time per day. So the question is: If we did away with increased airport security, would the result be more people dead from terrorism or fewer?

Caveat Emptor

This kind of thing is why most ROI models you get from security vendors are nonsense. Of course their model demonstrates that their product or service makes financial sense: They've jiggered the numbers so that they do.

This doesn't mean that ALE is useless, but it does mean you should 1) mistrust any analyses that come from people with an agenda and 2) use any results as a general guideline only. So when you get an ROI model from your vendor, take its framework and plug in your own numbers. Don't even show the vendor your improvements; it won't consider any changes that make its product or service less cost-effective to be an "improvement." And use those results as a general guide, along with risk management and compliance analyses, when you're deciding what security products and services to buy.

This essay previously appeared in CSO Magazine.

However, I got a few emails from my readers asking me something along these line, thus this post. For example, I got asked "Should I focus more on targeting security professionals or general IT users?", "Any pitfalls I should be aware of?" as well as general questions about how to start, what content is best, etc all the way to "How did I profit from my blog?"

Q: Who should I blog to?

A: Blog to colleagues first i.e. infosecurity pros. Blogging to IT or general public is - in some sense - harder or - gasp! - will turn you into a journalist (someone who knows nothing about everything BUT writes about it as an "expert" :-)) Maybe you can broaden it later. Even better, write for YOU (!)

Q: What area of security I should focus my blogging on?

A: Focus on the area of security that you like the most or know them most: IDS? Patching? PIX administration? Linux? AD esoterica? Logs, maybe? :-) Then broaden if you feel like it or as you learn new areas

Q: Any advice on site design, themes, etc?

A: Site design, themes, etc will all come later; just pick something basic and FOCUS on content, not on SEO, design, etc. MUST have RSS feed; make it highly visible (HTML is out, RSS is IN :-))

Q: Any security blogging pitfalls that I should avoid? Any other tips?

A:

• Don't stick to only long, deep posts? Unbelievably, people often prefer shorter posts or a mix of short/shallow and longer/deep posts (that came as a shock to me early on!)
• Tips on how to do whatever useful work well; comments on hot issues (that you understand) works too for a shorter post.
• Definitely comment on other bloggers posts (more often early on, later - as you wish...)
• Avoid long breaks in blogging (>7 days); it will  lead to reader loss (you should only care about it later - focus on fun content first!)
• Join Security Bloggers Network (drop an email to Alan Shimel for it)

Q:  Has blogging in this niche generated any income for you? If so, how much?

A: Exactly $0. The reason is that I never wanted to "monetize" my blog;  I don't have banners, etc. This is by design.

Q: How did it help your professional career in a significant way?

Yes, I think it helped my career and connected me to a lot of fun people! I sure hope I am not "known only as as blogger", but blog can definitely make one much more known professionally, especially if you create fun and/or useful content.

Overall, blog is a time commitment, but it is also a passion. It does help your career, but "forcing " yourself to do it just for "career benefits" is,  IMHO, a wrong approach.

Yo, my fellow bloggers; help the newbies out, will ya?! Let's start a series of posts on "how to be a good security blogger!"

Companies think they own their reputation, but in reality they don’t. A reputation is the aggregate of the popular opinion about you. Opinions, or thoughts, belong to an individual, true or not, and a company doesn’t own a person’s thoughts, therefore a company doesn’t own its reputation. QED.

Yes.  Absolutely.  In fact, there are already changes in the works to the FAIR model that reflect this line of thinking that will allow us to approach reputation damage in a much more rational manner that anything else I’ve seen to date.

Second, RE:  Hansei & Kaizen, Richard left the following comment.

I don’t agree with your view on Gemba even if we live in a virtual world. Look into any company’s wiring closet and you’ll immediately see a reflection in its maturity from the state of the equipment, the labeling / documentation and overall neatness. “Man with messy wiring closet, will have messy virtual servers.”

However, the true benefit in Gemba is not in the actual visual inspection. It is in in the journey from your desk to the data center / wiring closet.

I agree that the benefit is in the journey.  I can’t see the wiring closet as the main destination (I just don’t see it as a useful prior).  Maybe I wasn’t clear, or was taking for granted that you guys have been reading the blog for the past 2 years, but the journey needs to be to the LOB that owns the application.  The example most given when describing Gemba is going to the production line to look at the issue that causes a problem in the ability to create and sell a car.  The “security” journey is not to the wiring closet, but to the system itself and the logs that we have for the system and whatever network-based controls might be applicable.  And we, as an industry, are just starting to understand that this “security” is only part of the picture.  The whole picture is represented by the factors that create risk.

And for our “risk journey” that security journey is only a one of serveral useful pieces of prior information for use in analysis.  For risk we have to also journey back to the “production line”, or, in our case, to the application/LOB owner.  It may also be to corporate counsel, to marketing, to all sorts of other places in the enterprise because probable losses (a necessary measurement we need in order to understand risk) may come from many different sources in the organization.  For those with FAIR knowledge, think of the six forms of loss to get an idea of what sorts of journeys we need to make.

This is why tomorrow’s post is designed to look at what should we be reflecting about, and what is needed for reflection.

Hint:  our models for risk & risk management can give us an idea of how to create structure around Hansei for the IRM program.

It all started with the loss of a memory stick by a UK Government contractor which contained somewhere around 120,000 records, including the details of 10,000 of our nation's most serious criminals. We then heard about a compromise at global hotel chain Best Western...]]> Wed, 27 Aug 2008 20:00:00 +0000 global hotel chain olympic sport summer vacation pole position data government contractor medals table memory stick nation If there were gold medals for Data Leakage... http://securityratty.com/article/c474f15d19ef80949f385cbe7b510b79 http://securityratty.com/article/c474f15d19ef80949f385cbe7b510b79 Instead of my usual "blogging frenzy" machine gun blast of short posts, I will just combine them into my new blog series "Fun Reading on Security." Here is an issue #7, dated August 27th, 2008.

1. Sad, but VERY insightful story of Alan Shimmel getting 0wned (1,2,3,4, others on his blog)
2. A very good essay on security industry/market/community "Evolution is Punctuated Equilibria" ("Right now, Internet security is due for another period of rapid change.")
3. As I like to say, most everybody in out industry is confused about risk (myself included, in fact) - here is some nice reading about the subject: "Quant love", "What is Risk?" ("The probability of a threat overcoming security controls resistance to exploit a vulnerability that results in a loss.") While you are at it, check this blurb about risk and CVSS (BTW, CVSS is about "V" - vulnerability, not "R" for risk!)
4. Solid gold on "running IT as business" (and where it hits the wall) - Richard, the original CIO.com piece ("If you've tried managing an internal IT department as a bona fide business you already know that you can't take that very far, for the obvious reason that your IT department isn't a business.")
5. More fun stuff from Richard on insiders and why NOT look for them (sadly, same logic applies to not looking for owned boxes in your environment...).
6. Analyst firms shocking discovery: wireless MAY have security issues (I guess count it as humor...)
7. Fun read: "Challenges of Enterprise Cloud Computing" ("By moving the data into the cloud, enterprise, for now, will lose some capabilities to govern their own data set.")
8. Raffy on visualization. ("One of the dangerous things is if you don't understand the log file itself, don't assume you'll understand the visualization of it or even generate a visualization that makes sense") Amen to that! BTW, Raffy's book is finally out.
9. Compliance and checkbox mentality: fun pickup from my original "DLP and Compliance" post - Rich and TechTarget. Good stuff! ("Don’t Sell ‘Compliance’ If It Isn’t A Checkbox ")
10. RedHat is nicely 0wned (more info)
11. BGP hole to dwarf the DNS hole?
12. Chris continues the virtualization and PCI DSS theme here. The jury is still out on this one, even though the common sense approach (that virtualization is OK in regards to PCI) will probably win.
13. NEWS FLASH! Privacy dies. The date of death? 1967. While reading it, think just how visionary some folks are...
14. Finally, just for laughs: How to Spin Bad News

Enjoy!

BTW, I am saving some fun reading for dedicated posts soon :-)

Complicating factors is the impact (or lack thereof) of incidents on stock price.  Many researchers who identify themselves with the New School of Information Security (yours truly included) want to immediately look at stock price as a bell-weather metric for incident impact.  I think this stems from our days of slinging FUD, back when we could scream “Buy a firewall or we’ll have an incident and you’ll be on the front page of the paper and the stock price will go down!”  But these days notable incidents seem to suggest that the impact on stock price for an incident is short lived.  With qualifications, of course.

So what would/should we make of this from Money.co.uk?

£12million ($24m) Wiped off Helphire Stock after Malicious Email Sent to Clients

Car hire firm Helphire have taken Google to court after a malicious email sent from a Gmail account saw their shares plummet £12million in a single day.

The Bath-based business who specialise in providing replacement cars to ‘no-fault’ drivers involved in accidents on behalf of car insurance companies, initiated legal proceedings against the search engine giant as part of their attempt to find out who is responsible for sending the defamatory mailing.

Google are now known to have complied with the court order and have controversially supplied details of the email account and ISP used by the meddler.

Written under the psudoname Peter Franks, the 1200 word email is know to have been sent from a gmail account that was opened specifically for this purpose and closed a few minutes after the damage had been done…

…The misdemeanour couldn’t have come at a worse time for the struggling firm who have undergone a £45million rights issue and seen a 75% drop in the value of their stock already this year.

That last paragraph, for me, explains some of the difficulty in tying reputation damage to stock decreases.  It’s like when you read the headlines from Bloomberg about why the days stocks (or commodity) prices are up or down.  You know, the “Oil closes $3 higher on news that a notable South American dictator has a rather unpleasant boil in a very uncomfortable area” type of headlines.  You really do have to question the causality and correlation.  So in the Helphire case above - is this new drop in stock really because of the email sent?  If so, should we view that $24mil number as an independent data point to describe this sort of attack on reputation, or is the magnitude aggravated due to the long-term trend of stock price?

Even when we have “Objective Data” (an in-joke for Adam S.) like this decline in stock price, it is really difficult to provide any sort of precise estimate or measurement - about the future, present or past.  The best we can do is use ranges, distributions, that are reasonable based on evidence and observation.

So it’s worth filing away this sort of datum for future use - while dutifully acknowledging the qualifiers we might place around it.

So the questions I ask here - what should we make of this new information, and how should we view the $24million drop - they’re not rhetorical.  I am very interested in your views and welcome your comments!