The classic discussion came up again recently of where an ISO should report in an organization. One school of thought says it should be in IT; the other says it should be outside IT and as high up the food chain as possible to achieve objectivity and authority.
I’m pretty clear on where I think it should be: in IT. I think the people who believe it should be elsewhere aren’t IT people themselves and think IT security is all about policy. It isn’t.
You don’t just pronounce policies from on high and wait for them to be implemented. Often you have to help engineer the solution for the implementation, explain to the sysadmins or developers exactly how to do what you’re requesting, and check their work. You have to be able to conduct investigations on the ground.
Most importantly, though, you are extremely dependent upon the goodwill of the sysadmins, network people, and everyone else who actually runs the infrastructure. They are the first line of defense, and they are your greatest source of intelligence info. If you don’t have a close working relationship with them, you’ll miss finding out about a lot of security incidents—especially insider activity, where the only reason it’s detected is that someone was very familiar with the normal behaviors and knew something was out of line.
You won’t have the trust of the IT people if you don’t work with them, among them, and (where possible) for them. You help come up with tools to make their lives easier, and they’ll help you in return. Many times I’ve had a first-level technician sidle into my office, close the door, and say, “Um, there’s something I think you should look at.” You won’t get that if you’re in the C-level wing of the building.
The only time I can see reporting outside of IT is if you don’t have a supportive management chain, and therefore can’t get any policies or work implemented without being right next to the Top Hammer. But that’s an indication of a bigger problem within the organization, and reporting there shouldn’t be the default. (And for crissesake, don’t make the ISO report even further out of the organization, say to an external oversight group. That would just be the Kiss O’ Death for getting anyone to talk to you, much less do you any favors.)
Posted by
shrdlu on Monday, November 20, 2006
(3)
Comments •
Permalink •
(Can I get Keanu Reeves over here to frown broodingly at a screen and say, “That’s odd ...”?)
Following on the previous post, Andrew Jaquith brings his alliterative and quantitative skills to the flat screen. How thrilling is this?
He makes a lot of sense with his post, but I’d like to pick apart some of his examples and try them on for size in MY world.
Likewise, for learning and growth, we want to spread responsibility for security, equip employees with the right security knowledge and skills, and promote adaptability in the face of changing threats. These themes imply the following typical objectives:
- Delegating responsibility for authoring user activities to business units
- Increasing collaboration between IT security and business units
- Ensuring effective levels of security certifications for security staff
- Promoting security awareness throughout the organization
- Integrating secure behaviors into employee’s everyday activities
- Ensuring that security features are easily understood and adopted
- Heightening awareness of emerging security threats
- Exploring discretionary security frontiers
- Giving employees the skills needed to properly handle security incidents
I’ve purposefully listed the objectives for both perspectives (internal process and learning/growth) as objectives, not metrics, because they illustrate the behaviors that organizations should be encouraging. Every one of them can be readily mapped to process metrics — key indicators — that show whether an organization is achieving those objectives.
Let’s try some process metrics for those then, shall we?
Delegating responsibility for authoring user activities to business units - I’m not completely sure I understand this, but okay, assuming you can measure their activity somehow, you can argue about how much they were doing as a result of having it delegated to them.
Increasing collaboration between IT security and business units - How do you measure this? By the number of business unit keggers that IT security gets invited to? By the decreasing number of flames being sent back and forth with a Cc: to senior management?
Ensuring effective levels of security certifications for security staff - Bwahahaha. Define “effective” and then we’ll talk.
Promoting security awareness throughout the organization - Okay, I do this now through the number of newsletters issued, the number of training classes provided and the number of attendees, and the results of an annual OCTAVE survey.
Integrating secure behaviors into employee’s everyday activities - What kind of secure behaviors are we talking about? Not going to MySpace? Not opening spam attachments? I suppose you could count the number of times screens were left unlocked, or if you were really ambitious and nosy, you could count the number of outgoing emails that should have been encrypted but weren’t. Other than that, though, I’m metric-less.
Heightening awareness of emerging security threats - How is this different from the awareness activity just above? Do we count the number of CERT advisories we mail around? Do we do another survey?
Exploring discretionary security frontiers - I think this means researching new security technologies, but I’m not sure. Okay, so we measure spending dollars and dedicated man-hours, or number of pilots resulting in new procurements, or something. Help me, Jean-Luc!
Giving employees the skills needed to properly handle security incidents - You mean, other than giving them a phone number to call? What are some metrics for this one?
Don’t get me wrong: I’m not arguing that these aren’t great objectives, or that we shouldn’t be focusing on security behaviors. Far from it. I’m just having trouble making the leap from objective to mapped metrics. Then again, Jaquith is doubtless much smarter than I am. I am Only An Egg.
Posted by
shrdlu on Friday, November 17, 2006
(5)
Comments •
Permalink •
Just as tornado season is starting up again, so is the topic of metrics swirling around the sec-blogosphere. rmogull has nothing but reasonableness to offer, but the Best Security Analogy of the Week Award goes to Amrit Williams:
Apparently measuring security is like anal probing. Aliens, with their advanced technology, have cracked the space/time continuum but apparently the mysteries of the human rectum still elude them – security metrics are like the ass of IT, with all our advances it still eludes us.
Maybe we should work on our advances? 
I’d been meaning to write about an excellent metrics talk I heard by William H. Murray, who is as refreshingly pompous, crusty, colorful and practical as they come. He’s one the first people I’ve heard speak who actually made me feel as if there were simple, concrete metrics I could take home and try.
Many of them get echoed time and time again, and appear to be straight IT metrics:
- State
- Populations of systems
- Progress
- Compliance
- Spending
- Attacks
- Losses
- Program
- Service
- Customer satisfaction
- Risk acceptances and risk accepted
Source: Cybertrust slide
Measuring state is a given. Enumerating your network segments, address ranges, system configurations, and the currency of your security-related software. Funny how just knowing what you’ve GOT is a security issue.
Progress. Spending. Service. Customer satisfaction. Wow, how many people have even THOUGHT of trying to measure customer satisfaction as a security metric??
Now, compliance I’m not so sure about, because I personally always find that when I try to use any given tool to measure compliance with policy, I’m actually relying on someone else’s technical/legal yardstick, and I’m having to explain all the cases where I think we’re compliant but the tool doesn’t. It’s a starting point for discussion with management, to be sure, but I think it’s just a wee bit inaccurate.
Measuring attacks and losses now brings us into real security and risk management territory. Murray brought up things like measuring the mean time before failure and the mean time to recovery. Both of those require serious incident reporting skills; there’s no point in talking about mean time before failure if the failure isn’t provably security-related.
Murray also recommended budgeting for losses, to which I said, “WHA-ha-ha-ha??” It’s a sophisticated form of risk management, but I can’t see that working in an organization with a restricted budget or extra accountability requirements. As I said before, you can budget for first-order costs of incident response, but my management would confiscate my keys and passwords if I tried to suggest that I get a gambling pot and keep what we don’t lose over the fiscal year.
What I don’t think we measure enough is behavior. By that I mean application behavior, user behavior, and system behavior, especially as it translates into network traffic. Never mind what the IDS says: who’s talking to our server, and how often, and why? What does it tell us that web usage spikes at the magic hours of 8 am, noon, and 5 pm? What are we allowing, and what does that say about our business rules and policies?
I’m going to leave a lot of these IT inventory and configuration metrics, like time to patch, to the rest of IT Operations. What I think I should be more concerned about are in the areas of controls, intelligence, and response. I also like to measure awareness: I’ve been using the same OCTAVE survey for two years now, and can finally show some trending (okay, two dots’ worth, but that counts).
And there’s nothing like measurement to highlight the warts in business processes. When you’re trying to define authentication and authorization rules, all sorts of inconsistencies show up that you have to bring to the business to figure out. When they want to delegate, what’s their definition of a suitable candidate, as opposed to an unsuitable one? Whom are they authorizing for unofficial reasons? When you do a user audit and can’t find anyone who can explain why half of the accounts were created to begin with, that sends you right back up to layer 8.
So I’m getting closer to choosing metrics, but I start by getting some data and asking myself: Are we better off now that we know this information? Is it telling us something useful that we didn’t know before? I know how far behind we are on our patching; that’s not a useful metric. But discovering network traffic from an application that none of the developers claimed to know about: THAT’S some useful security intelligence.
Onward thru the fog ...
Posted by
shrdlu on Thursday, November 16, 2006
(4)
Comments •
Permalink •
It sounds kinda romantic, doesn’t it? Your 133T skillz against those of the wily hacker. Showdown at the 0K corral. (Heh. Would that be “zero k”?) But most of the time, it doesn’t happen that way—at least, not to me. Here are some of the harsh realities of security incidents:
- They usually start with someone frowning at the screen and saying, “That’s odd ...”
- It can take a really long time whether you even know for sure that you’ve got a breach.
- Sometimes you can work on something for hours and then figure out that it was just some weird-ass behavior on the part of some application.
- When it comes to an insider, not everyone will agree that it was really a breach of security, much less one requiring disciplinary action.
- In fact, sometimes you have to work instead on protecting the network against someone who is behaving badly, yet whose management refuses to fire him.
- Does two people arguing over control of a root password constitute a security breach? If one of them changes it out from under the other one? You tell me.
- There is very rarely, if ever, a “takedown.” Most of the time you just manage to block the bad guy out and hope that he’ll move on to another target.
- It can take law enforcement a really, really, really long time even to get around to looking at the evidence, much less decide whether they have a case.
- You’ll never know whether you found everything. You just have to live with that.
Posted by
shrdlu on Sunday, November 12, 2006
(3)
Comments •
Permalink •
Today’s example of taking marketing to Ludicrous Speed is brought to us courtesy of McAfee. I’m surprised this latest white paper wasn’t plaid.
The Power of M
Security to the Power of M™ is McAfee security. It’s security that’s exponentially better. It protects over 100 million people worldwide. And it’s backed by nearly 20 years of real-world experience. Security to the Power of M is totally focused. In fact, it’s all we do. It is in our very DNA to protect our customers and to provide leadership within our industry. Every minute of every day, all we think about is how to make security comprehensive, integrated, and simple for homes, for small to medium-sized businesses, and for the world’s largest enterprise organizations. We are not distracted by non-security products. We are not conflicted about our priorities. It’s simple: We live to protect our customers. And in a world that’s becoming ever more interconnected, Security to the Power of M is not merely smart, it’s mandatory.
First of all, when I think of the letter M, I have this very disturbing vision of Peter Lorre in my head. And I really don’t think McAfee wants to adopt the Grieg theme from “In the Hall of the Mountain King” as their corporate theme song.
In fact, I have a bad taste in my mouth from way back when it comes to describing security in terms of letters. I had a colleague once who seriously tried to convince some executives that a product was more secure because it had an additional letter “s” in the name.
And if I were working for McAfee, I doubt I’d be spending every minute of every day thinking about security; I’d be spending at least one of every three minutes laughing my ass off at the Marketing department and/or trying to apologize to my customers. I actually feel pretty sorry for my McAfee rep, who is quite sensible and clueful. I wonder whether she’s sitting with her head in her hands right now.
(Amusing side note: I dutifully talked to both Symantec and McAfee at the last local conference I attended. A few days later, two different colleagues of mine showed up in my office within ten minutes of each other, bearing more marketing literature that the reps at the conference had asked them to bring to me. Dueling brochures!)
Posted by
shrdlu on Sunday, November 05, 2006
(3)
Comments •
Permalink •
For me, it’s all about identity and access management these days.
How to disambiguate users without relying too heavily on the classic “identity theft” data.
How to handle ad hoc registration and secure communication with hundreds of thousands of transient users.
How to make sense of business rules to build them into approval chains in user provisioning. (This is the sticky part. There are always unwritten rules that bubble to the surface. “All users have to be approved for access to that data, so that data owner needs to sign off on it.” “What about the developer writing the application? Does he have to get approval too?” “Oh no, he can create as many test accounts as he wants.")
How to consolidate management of access to ALL the platforms, and no, I don’t just mean single sign-on through Citrix. Is a system administrator going to go through Citrix to log in to the console of a misbehaving Linux box? I don’t think so. Are you going to get your third-party financial application to log in to a local system account through Citrix? Nuh-uh. Please don’t tell me there’s a silver-bullet single-signon solution out there that handles ALL access control, because it’s still only modeled on the Windows-using non-IT employee.
I’m probably going to be spending the next two years solving this problem, and some of my choices are going to be made for me midstream, because I’m dealing with an imminent outsourcing as well.
All in all, I think I’d rather be doing my taxes.
Posted by
shrdlu on Sunday, November 05, 2006
(2)
Comments •
Permalink •
tk just has the best quote in the latest VERT Daily Post:
Decision support is driven by intelligence. No one knows this better than your adversaries and competitors.
I have been screaming for quite some time now that CEOs need to reinvent and transform their security organization into the INTELLIGENCE ORGANIZATION. It is a much higher value proposition and much more accurately describes their role in the organization ...
Being at the core of your organization’s decision support is critical and it is not about always being the bearer of bad news but about being the one stop shop for Operational Intelligence and Situational Awareness.
I couldn’t agree more, but I’m finding it hard to do so without looking like I’m pinning a Mensa Medal on myself.
“Intelligence” is a loaded word. Can we use “information” instead? It doesn’t sound as macho as “intelligence” when you’re in the DoD Metropolitan Area and you also like to use the word “cyber” a lot. But it also keeps you from sounding smug when you’re trying to justify your reporting line to other areas of your IT department.
Actually, let’s break it down some more. I end up being a nearly-one-stop shop for answers that require the discreet gathering of system data, the holistic view of IT if any of it is arguably security-related, and any legal or HR policies that need to be implemented in any way at the IT level. In other words, if they need IT information that involves confidentiality, enforcement or any kind of risk, then they come to me. Since there’s hardly anyone in the building who doesn’t use a computer for their work, that ends up being pretty often.
I like the words “decision support” in this context. I like them a lot. I don’t make the decisions, but I provide the information and help break down the problem space for those who do. Often I say, “I don’t know whether you’ve thought of this particular issue, but if you have, what do you want to do about it?” (Disingenuity disclosure: yes, I know that their decisions will be influenced by the data I give them, and half the time they will punt and say, “What are your recommendations?") But I really do see my role as a holistic sort of regulatory-and-risk IT person who ends up in the boardroom more often than others because the issues bring me there.
Posted by
shrdlu on Friday, November 03, 2006
(1)
Comments •
Permalink •
Ira Winkler, who is normally a smart guy, completely blows it with this article on why ethics should stay out of computer security awareness programs.
Clearly, a good computer security program should help to identify illicit activities, but it is not what it exists to do, and it’s counterproductive to accomplishing the program’s true goals. In too many organizations, computer security has a negative connotation, and its rules (and personnel) seem to exist mainly to mete out punishments for rule infractions.
Well then, Ira, I’d suggest that you’re not doing it right. Users who are not technically sophisticated also need to be taught why certain behaviors on the computer ARE unethical. Too many people don’t understand that copying software to multiple computers can be wrong and even illegal. They don’t see anything wrong with sharing passwords. They don’t understand that if they’re blogging about confidential information, it’s findable by the whole world, including their employers.
Underlying practically all security awareness instruction is plain old IT instruction. It’s needed both within IT and in other parts of the organization. You simply cannot assume that a developer understands that he shouldn’t build a back door into an application; he may not even realize that it IS a back door until you explain it to him.
Not only that, but computer security is data security. You have to explain to people what they are allowed to do with data and why. A security awareness program is very closely married to confidentiality and legal issues. Most of the policies created in those areas end up being funneled through my awareness program because it makes sense to do so, and often I’m the one who raises the issues because I end up having to investigate them and deal with their fallout.
My awareness program isn’t all “meting out punishments for rule infractions.” It’s also education for the users on how to keep themselves secure at home, and how to keep themselves out of trouble in general. I think it’s better for me to warn them that everything on the network is potentially logged, and that they shouldn’t write anything that they don’t want their co-workers to know about, just in case a legal discovery request forces me to go through their mailbox. I warn them that they shouldn’t publish anything under their own name on the Internet unless they want it to be searchable by their bosses or employees for the next 20 years. (One of my guys is STILL giving me grief about a college photo of mine that he found. It was a Coca-Cola bottle in my hand, I swear!)
And you should never pass up an opportunity to educate users about IT policies that you may be using later as grounds for disciplinary action, termination and/or prosecution. The Legal, HR and Audit folks will all thank you for it. You shouldn’t have to say “Don’t impersonate a co-worker,” but you may well have to say, “Don’t send email from someone else’s account; that’s the same as impersonation.” You may have to explain why stealing bandwidth IS stealing. Our justice system isn’t THAT robust yet when it comes to dealing with ethical violations involving information technology.
If you do it right, a security awareness program can open the door for all sorts of IT-related education, some of which is sorely necessary. If you’re only concentrating on telling users How Not To Break The Computers, you’re missing a huge part of the big picture, and therefore you’re not doing your job.
Posted by
shrdlu on Friday, October 27, 2006
(3)
Comments •
Permalink •
Nice article by mogull on why, even though IT security is a relatively new field, you still can’t be a revolutionary overnight.
We see this all the time in any complex field of study or practice. Someone from the outside, either left field or a related field, gets a really cool idea that they think is paradigm shifting. This person believes their outside view is “clearer” than those stuck in the tradition of their various area of expertise.
On very rare occasion such genius exists. But it isn’t you.
[...]
Some fields are more prone to, what I’ll call “exploding lightbulbs” than others. Physicists, cryptographers, and doctors battle this on a sometimes daily basis.
In other words, if you believe you have an absolutely right answer, you’re almost certainly wrong. As a great bumpersticker says, “Don’t believe everything you think.” This dovetails nicely with eLamb’s discussion of the 10 types of security practitioner personalities (sorry, just couldn’t resist mixing my “in” jokes):
I’ve noticed that there are two types of security people: anal “type A personalities” who live every moment by the rules, and those that realize that there is no real security.
Actually, this dichotomy extends further than the security field. I encountered them on a daily basis as an American working in Switzerland. You can guess that a country where people have been seen scrubbing their roofs would be deeply concerned with appearance, order, form, and rules. Americans tend to chafe at anything that interferes with their right to make things up as they go along.
Me, I’ll sit vehemently in the middle. You do need rules, but you need to be able to adapt them when it makes sense to do so, and realize that they’re not absolute. If it’s one thing we humans are good at, it’s making rules and then promptly coming up with exceptions to them. This doesn’t mean the rules weren’t good; it’s just that hardly anything is immutable and universally applicable. If we didn’t work this way, we’d be robots; and it’s exactly why silicon-based systems can be so annoying to carbon-based systems.
I was talking with a peer from another organization the other day, and realized that the problem he was having was that he had to deal with an oversight organization that was seeing security in terms of checklists rather than risk. They were saying to him, “You don’t have X set up, therefore you’re insecure, therefore we’re shutting you down.” (If that isn’t binary thinking on a massive scale, I don’t know what is.) I suggested that he come back at them and challenge them to tell him in quantifiable terms exactly what they were claiming his risk was in not having X. (I then sent him a copy of Jack Jones’s most excellent paper on FAIR to give him a leg up.)
The answer to an absolute statement is to ask “how much?” That completely changes the terms of engagement.
So if you find a soi-disant expert who claims to have solved the whole problem of zero-day attacks, or will revolutionize anything in the security field, ask him to measure it. Chances are, either he won’t know where to start, because he doesn’t understand it himself, or he’ll make up the numbers, because he figures that worked for his idea in the first place. If you can get objectively verifiable numbers in the middle of the scale, then you may just have a winner.
Posted by
shrdlu on Thursday, October 26, 2006
(1)
Comments •
Permalink •
Mike Rothman had a good rant today about the big tech media players. I have so much already to read and do that I have no time to peruse general tech publications any more, unless they relate to security or I get led there on a particular topic from somewhere else. Even my free publications like Information Security Magazine pile up on my desk and gather dust.
So what’s up with the paid report sector? I admit it’s been many years since I worked for a place that could afford analyst subscriptions like Gartner. I still get a few reports and quasi-freebies handed to me, though, and I still don’t get the value added there. As far as I can tell, they’re all writing either for executives who want to go on a spending spree and need to know what else to buy, or they’re writing for vendors in the space who want to know what their competition is doing (and whether they’re getting better publicity). Every time I’ve seen a quartile chart, it only told me things I already knew. Am I just keeping up better than I think by reading free stuff on the web, or are these paid reports not worth the simoleons? Are there any tech publications that really distinguish themselves? and if so, how? Do any of them really go to 11?
Maybe it’s product and FUD fatigue. I’m tired of reading about the latest and greatest software/appliance/gateway/acquisition/merger. I’m tired of reading about the same security headlines over and over again. Even the exploit sites are starting to blur in my mind. When Microsoft releases 26 patches in one fell swoop, how is anyone supposed to pay sufficient attention to understand each one of them?
I’m not even a tech-illiterate manager; I was informed just today that I allegedly have a “massive clue.” (Of course, that might just have been an attempt to butter me up in advance of a performance review.) If I’ve got report fatigue, what must it be like for others? I can understand how any executive who hasn’t spent years in the security realm could get overwhelmed by the media and just want to bury her head in the sand.
What is the well-dressed ISO buying this year? Security shouldn’t be about fashion, and yet that’s what it’s starting to feel like. If the crowded vendor space can’t be disambiguated, and therefore the trade mags don’t have anything new or different to say, then doesn’t it come down to which designer you like the best, and whether you have one of every accessory in your closet/server room?
I’m just waiting for the Vogue equivalent in the security world ...
Posted by
shrdlu on Tuesday, October 10, 2006
(2)
Comments •
Permalink •
Just a quick list of the kinds of things I tackle on a daily basis as an IT security manager:
- Email, phone calls and/or personal visits from unhappy users who feel oppressed by security policies.
- Organizing trainings on arguably security-related software.
- Contract negotiations.
- Press releases. (Yes, really.)
- Software architecture discussions, ranging from the abstract to the concrete.
- Submitting, reviewing, prioritizing and signing off on software change requests.
- Looking at rack and cabling diagrams.
- Tweaking legal wording in policies and other places.
- Diagnosing production problems (and having to prove that they’re not being caused by security).
- Dealing with staffing logistics (such as making sure new hires have a desk, a phone, a computer, and a projectile launcher).
- Cooking up security metrics and status reports for my management.
- Answering the same complaints about spam and phishing over and over and OVER again.
- Reviewing project plans and RFOs.
- Reviewing and discussing random product descriptions and security articles that my boss asks me about.
- Reviewing reports on antivirus and patch levels.
Did I mention that another thing I have to do is clean out my inbox because it’s over its size limit?
Posted by
shrdlu on Tuesday, October 10, 2006
(1)
Comments •
Permalink •
I have a particular requirement to stay awake until 1 am tonight, so I’ll finally be able to take some time to blog in appeasement of my one fan.
Starting off with an easy one: a list of the more unusual search keyphrases that bring people to this site.
- is it possible to to stop other computers to pining to my computer with packet filter
(Pining for the /dev/fjords?)
- frank kenisky veterans affairs
(Boy, I’ll bet HE didn’t find what he was looking for!)
- medium performers employees training
(A bit generic, but I hope they found something a bit useful.)
- food network tasty travels 16 layer pie
(Hoo boy, did THEY end up in the wrong neighborhood!)
- huns reparation
(Bwahahaha!!)
And finally, my favorite:
- survey of the eleven layers of hell
(You’ve come to the right place. Welcome.)
Posted by
shrdlu on Tuesday, October 10, 2006
(1)
Comments •
Permalink •
Also on my list of planned rants was the one about how I’m suffering from vendor fatigue. I get bombarded with marketing email; I have newsletters that come to me directly and are forwarded by my boss; I read security news sites and security blogs and I go to conferences and I walk by booths and collect literature and I gotta tell ya, it’s all becoming a blur in my tiny mind. I thought it was just me, but then I came across this marketer who said it even better:
One might assume that large outsourcing contracts that are multiyear, multimillion dollar deals are highly customized and tailored to each individual customer. This just isn’t the case. According to META Group (who has now been acquired by Gartner) in 2004 40% of outsourcing buyers could not differentiate the proposals between vendors. Not on price, product, solution, approach, vision, etc. This lack of differentiation is growing and expected by some to reach 60% by the beginning of 2007. Without clear differentiation, these firms went with the provider they liked the best.
I think this is a problem across the board. Yes, it’s a problem with huge outsourcers, who have often become that way because they developed an effective boilerplate that allowed them to achieve the elusive economies of scale. (You don’t get that savings by spending time customizing and tailoring.) But it’s also a problem with the flooded security market in general.
It gets worse when you add this gem, a combination of Mike Rothman and Scott Santucci:
Do Your Value Propositions Go to Eleven?
In Rob Reiner’s 1984 “rockumentary” This Is Spinal Tap, one of the main characters, Nigel Huffens, proclaims they are different than other bands because their speakers “go to 11.”
I cannot help but be reminded of good ole Nigel every time I talk to clients who are working on their value proposition. A few claims I’ve heard over the years:
“We are more scalable”
“We are truly global”
“We are more adaptive”
[we stop zero day threats with proactive protection and zero false positives is a common security claim]
Translation? “These go to eleven.”
The buzzwords are just getting ridiculous in this business. Here are phrases and claims I’m really getting tired of hearing about:
- stopping zero-day threats (tell me, exactly how do you do that? Do you have a time machine and go back to 0-day-minus-1?)
- risk management (sorry, guys, but it’s true; it’s overused)
- regulatory compliance
- leveraging synergies
- return on investment / increasing value of IT
- appliances that block spam, viruses, spyware, trojans, malware, worms, zero-day attacks, data loss, P2P, IM, and annoying PCI auditors (I just made that last one up)
- anything using the word “appliance,” “gateway,” “shield,” or “enterprise” in any way.
Mike and Scott go on:
Don’t laugh. It’s happening in your market too.
[NAC, extrusion prevention, email security - you name it and all of these markets have the same characteristics. Too many vendors, not enough differentiation.]
Why?
Anything you can say on your website, your competitors can say as well.
Let’s say your value proposition is different than anyone else’s and that you do come up with some concepts that resonate with customers as truly unique, and this helps get you traction. How hard is it for your competitors to steal this value proposition, reword it, and use it?
[I know this is true because it happened to me in every marketing job I’ve had. I came up with a cool term (like Early Warning System or Connection Control) and every other vendor talked about their capability to do this within a month. Literally a month. Of course, none of it was real - but it still confused the customer. That means longer sales cycles, etc.]
Not only can any vendor use those words, but the salespeople really don’t know what that MEANS. Hell, I don’t know what it means. The only possible differentiation of these products is at such a low technical level that there is no point in my talking to any salespeople at all about it, unless they’re actual sales engineers. I want someone who can tell me exactly what they do differently so that I can decide whether or not it’s better for me.
As Scott says in his Seven Irrefutable Laws of Customer Centricity:
Customers buy solutions to their business problems, they do not buy products; and
Only a customer can call it a solution.
I’ll finish with another quote from Scott, because he just plain Gets It so well:
- IT executives consider fewer than 5% of their vendors to be strategic.
- The typical CIO does not meet with sales people.
- New efforts are in place to shield IT executives from vendor sales people.
- The overwhelming majority of IT executives (defined as the CIO or a direct report to a CIO) find sales people annoying and wasteful of their time.
All true. My CIO generally doesn’t meet with vendors, and certainly not as a result of a cold call. A couple of bozos have made the mistake of trying to shoehorn their way into a meeting with him by appealing to HIS management up the chain. Big mistake. We sat politely and unhelpfully while they made their (lame) spiel, and resolved NEVER to do business with them. Don’t Be That Guy.
I spend a good portion of my day dodging sales calls from vendors who happen to have gotten my number, and deleting marketing email advertising tons and TONS of webcasts. (Here’s a clue for you: I spend my days either doing productive work myself, or helping my team in whatever way I can; I don’t have time to sit endlessly in front of my monitor and listen to webcasts. I don’t do webcasts at all unless I’ve already decided to look seriously at piloting the product in question.)
Now, how can I get someone like Scott to front for all the good products I might want to look at? Wouldn’t it be cool to have your own personal reverse-marketer, sort of like a Security Concierge? 
Posted by
shrdlu on Friday, September 29, 2006
(2)
Comments •
Permalink •
Dan Morrill had a great blog entry a while back about the difficulty in finding good third-party consultants to do penetration testing. I always meant to comment more on that, but never got around to it. Then Tate Hansen at ClearNet Security came out with a great flowchart basically illustrating the same thing: that a good pentester doesn’t just fire up the tools and send you the results.
The best analysts I have worked with have (1) taken time to understand the business; (2) inspected the network (when not on a black box engagement); and (3) put processes together with vulnerabilities and leaked information to discover combinations that led to compromise. They used Google hacking, mined information from our websites, and manipulated system parameters and application behavior to break in. (In other words, they worked like a REAL hacker would, not like a script kiddie who knew how to run Nessus.) They considered human foibles in procedures and processes as well as coding weaknesses. I got a holistic view of our exposure instead of just a scan report that said, “You need to turn off these ports and strengthen your passwords.”
When you’re having a third-party assessment done, you really need analysis, not tool-using. Some things that I like to be told are how my organization stacks up security-wise against similar organizations, and what fixes we can make that will bring the biggest, most cost-effective improvement in our posture. The best consultants I know are businesspeople and system architects as well as security professionals.
If anyone’s shopping around for consultants, drop me a note here and I’ll give you a list of my favorites.
Posted by
shrdlu on Wednesday, September 27, 2006
(1)
Comments •
Permalink •
The security equivalent of Nietzsche has spoken, and ROSI is dead, although there are still some Monty Pythonesque security pundits who claim that it’s just pining for the fjords. (Pining for the quantifiable risk management?) I think the concept of a return on investment for security was mostly a management fad, born out of irrational exuberance on the part of security professionals who were trying to get to the C-level. (And for the most part, some appear to have succeeded.) But nobody talks about ROI for physical security, so I don’t think there was ever a chance for ROSI.
HOWEVER. We still have a great need for a different measure: effectiveness of security investment.
There are so many different ways to spend on security that nobody can come up with a formula. (No, I don’t care about the 10% of IT rule; tell me how the 10% breaks down into a real line-item budget.) Is it more effective to invest in personnel or in “enterprise security solutions”? Are you really getting more bang for the buck by going open source whenever you can? Once you’ve (presumably) solved the standard problems—you’ve bought antivirus, antispyware, antispam, and firewalls, and have them all tuned properly—where do you go from there? If you take your security spend over five years (which is an eternity in security time, never mind Internet time), can you show a rational pattern there, or just a reactive one as new threats and new products came over the horizon?
The problem space breaks down in a couple of ways. You have your line-item budget versus your performance-based budget. Executives will understand the latter somewhat better than the former, but will still end up asking for the former as well; you might as well put them in a matrix together. They want to know (1) what you’re buying, and (2) what you’re going to do with it, and why.
How do you create performance-based budget categories? My personal choices are in these areas:
- maintaining security infrastructure (capital spending on hardware, software and maintenance)
- maintaining compliance with existing requirements (legal, compliance and “best practice,” whatever that is)
- remediation (show me an organization that doesn’t spend on remediation, and I’ll show you a shop that’s been open less than a year, or is going to be open for less than a year)
- training and awareness
- developing solutions for new compliance and business requirements
- incident response
Yes, there are a few problems with this, especially in the last two forward-looking categories. That’s the other part of the problem space: predictable costs versus unpredictable ones. If you don’t know what your new business requirements are going to be, you don’t know whether the solution they need is going to involve you buying a new security product, or having real people rewrite or reconfigure what you already have. And you can put a bit of a nest egg away to respond to incidents from a resource perspective (hired guns to come in and help with forensics, for example), but your management probably won’t let you sock away much. Need I point out that covering the other costs of an incident (litigation, fines, notification, etc.) should come from the insurance part of your organization’s financial risk management? That shouldn’t be your responsibility anyway.
The biggest problem with security spend is trying to quantify the HR end. Security activities take up time from just about everyone in IT to some extent, and unless you’re very determined and very controlling, you probably won’t capture that part. Your best chance is to list any staff who are arguably dedicated to security activities, and then add the cost of any other security activities that you can put in the form of a project (remediation and new rollouts are best for these).
This is the point where you have some good charts for your executive management, but you still have to remind them that there is no Return at the end of the investment rainbow. You just have to convince them that you’re buying the equivalent of the right safe for the right jewels, and explain the going rate for suitably trained bodyguards.
Now, all we need is for someone to simplify things down that far, and we’ll be set! 
Seriously, though, you can approach spending partly from a due diligence perspective ("everyone needs to have one of these"), but the rest of it is going to be based on your judgement of your organization’s particular risk profile: what you’re protecting; whether it takes more people, processes or products to cover those particular things; where you’re weakest; and which hill your business is going to ask you to take next.
The hardest part, for me, is deciding whether I need the all-in-one coffee, espresso and tea-maker, or whether I can get by with one of those Bodum French presses and hope anybody who wants tea will be satisfied with a jar on a sunny windowsill.
Posted by
shrdlu on Saturday, September 16, 2006
(4)
Comments •
Permalink •
