Research

I got email from friends this week about a web site that creeped them out. It’s called Spokeo, and it provides a Google-like search on personal information. Rather than creeped out, I was fascinated. Not to look for other people, but to see what the search found for me. I hate mentioning it as I am not endorsing the web site or service, but I can’t help my fascination at seeing what personal data has been collected and aggregated on me. I actually have a larger Internet fingerprint than I expected! This tool is kinda like Firesheep for personal information: the data is already out there, this site just shoves in your face how easy it is for anyone to collect basic stuff about you. But the friends who directed me to the site were genuinely worried that criminals would use the site to locate single women in their late 70s in order to create a robbery target list. Seriously … that explicit. I told them they needed counseling as they probably had ‘mommy’ issues. I find this ridiculous because in Arizona we call have ‘Sun City’ – the age-restricted community where everyone seems to be over 70, with some of the lowest crime rates in the county. I make a big deal about personal data because I believe no good deed goes unpunished. Shared personal information will sooner or later be used against you. My personal phobia is that an insurance company will write an automated crawler for personal data, consider something I do ‘risky’, and quadruple my rate for fun. Yeah, I probably need counseling as well. The paranoid part of me wanted to know how much more I had exposed myself. I looked myself up in various states, with and without my middle name. In most cases it’s easy to see where the data came from. Facebook. LinkedIn. Yelp. Some information has to be public because of government regulations. Sometimes it looks like data collected from other people’s contact lists that I never authorized, which is why I found old phone numbers from decades past. In some cases I couldn’t tell – I looked on all of the social media I use and couldn’t find a reference. It’s been a decade or so but I knew I would eventually see a tool like this. What made me laugh is that my years of paranoia have paid off. This shows up in how they get a lot of stuff wrong. Whenever I sign up for anything on line I always use make-believe data: age, race, contact information, etc. Sure, some digital profiles are work-related and so can’t be totally fake, but it’s kinda fun to see that I am a late-40’s hispanic woman to much of the digital world. Still, private as I am, I lost the bet with my wife, who has less public data out there. She is virtually invisible online. “Ha! Take that, Mr. Privacy Expert!” was her comment. Share:

One of the concepts I use in my Pragmatic CSO material is a Day in the Life of a CISO. There are lots of firefighting and other assorted activities. I usually get a big laugh when I get to the part about groveling to the CIO and CFO for budget. Yes, I call it like I see it. But after seeing a post on budgeting by Ed Moyle from before Thanksgiving, I think it’s time to dig a bit deeper. Remember the budget is pretty critical to your success (or failure) in security. This job is hard enough with sufficient resources and funding. Without them, you’ve got no shot. So becoming a budget ninja is one of the key skills to climb the security career ladder. Ed makes a number of good points about spending transparency and measuring effectiveness. Basically trying to show senior management what you spend money on and how well it’s working. I agree with all of those sentiments. And I’m being a bit sarcastic (go figure), when I talk about groveling for budget. You need to ask, but in a way that provides a chance of success. And the most useful tool I’ve seen used for this in practice is the idea of scenarios. Basically when building up your architecture, project plans, and other assorted strategies for the coming year, think about breaking up those ideas into (at least) three scenarios: Low bar: This is the stuff you absolutely need – in order to have any shot at protecting your critical information, or meeting your compliance mandate, or the like. To understand where this bar is, think about a scenario where you would quit because you don’t have enough resources/funding to have any shot, and a significant issue becomes a certainty. That is your low bar. High bar: This is what you need to really do the job. Not to 100% certainty – don’t be silly. But enough to have a good feeling that you’ll be able to get the job done. Real bar: This is somewhere in the middle and what you hope to be the most likely scenario. To be clear, how much funding you get to do security is out of your control. It’s a business issue. You are competing with not just IT projects, but all projects, for that resource allocation. And if you think it’s a slam dunk to build a case for a new perimeter security infrastructure, as opposed to a new machine that can streamline manufacturing, think again. Even if you know your project is the right thing to do, it may not be as clear to someone with lots of folks all groveling for their own pet projects. The scenarios help you explain the risks of not doing something, and provide a more tangible idea of the costs, than a long project list which means nothing to a non-security person. Scenario Risks Group your projects into scenarios, and model a specific type of attack that would be protected. For example, in your low bar scenario, just make the case that you’ve got no shot to meet compliance mandate X without that funding. Then explain the possible ramifications of not being compliant (fines, brand damage, breaches, etc.). This must be done in a dispassionate way. You are presenting just the facts, like Joe Friday. The burden is on the business managers to weigh the risk of not meeting (funding) the low bar. When presenting the high bar, you can discuss some of the emerging attacks that you’d be able to either block or more likely detect faster to mitigate damage. Get as specific as you can, use real examples of your applications and the impact of those going down. But be careful to manage expectations. Even if you reach the high bar of funding (which typically only happens after a breach), you still may have problems, so don’t bet your firstborn or anything. The real bar provides a good mixture of protection and compliance. Or at least it should. Truth be told, this is our hopeful scenario, so make it realistic and plausible. Make it clear what you can’t do (relative to the high bar) and what you can do (compared to the low bar). And more importantly the potential risks/losses of each decision. Not in an annualized loss expectancy way, but in a we’ll lose this kind of data way. The key here is to rely on contrast to help the bean counters understand what you need and why. The low bar is really the bare minimum. Make that clear. The high bar is a wish list, and in reality most wishes don’t come true. The real bar is where you want to get to, so use some creativity to make the cases push your desired outcome. Don’t Take It Personally Above all else, when dealing with budgeting, you can’t take it personally. Every executive team must balance strategic investments and risks and decide what is the best way to allocate the limited resources of the organization. Sometimes you win the battle, sometimes you lose. As long as you get to the low bar, that’s what you get. If you don’t get to the low bar, then maybe you should take it personally. Either you made a crappy case, you have no credibility, or the powers that be have decided (in their infinite wisdom) that they are willing to accept the risks of not hitting the low bar. That doesn’t mean you have to accept those risks. Remember, you are the one who will be thrown out of the car (at high speed), if things go south. So if you don’t reach the low bar, it make be time to look for another gig. And do it aggressively and proactively. You don’t want to be circulating your resume while your organization is cleaning up a high profile breach. Photo credits: “spare change towards weed + starbucks 🙂 long live bank of america” originally uploaded by sandcastlematt Share:

This is usually the time of year I write a how-to article on safe seasonal shopping. And some of it is the usual generic advice – use a credit card, don’t click email links, use merchants you trust, etc. – but I like to include specific advice to deal with new seasonal threats. Wading into the deluge of threat warnings about Black Friday shopping schemes this year, I found mostly noise. There are plenty of real attacks consumers should be worried about, but many which aren’t worth the attention. And every article seems to have a particular agenda. For example, I have a hard time believing SMS banking scams are a real threat to holiday shoppers, in the same way I can’t imagine someone falling for a Nigerian banking scam or turning off their refrigerator because of a crank call. Some are so targeted at a small group, the news is only interesting to the most dedicated security researchers. Others attacks combine good old fashioned fraud with a few Search Engine Optimization shenanigans to game the system, causing a lot of people grief, but persist until law enforcement makes then a priority to investigate. Of the dozens of articles out there, they all seemed to feed the security theater, making it much harder to know what’s a real threat and what’s not. I don’t know if Bruce Schneier coined the term Security Theater, but he’s certainly the first person I head use the expression. Over the years I thought I knew exactly what he meant: pretending to do something about security when not really doing much of anything. But every couple years I find a new wrinkle to the concept, and now the term embraces several variants. To my mind there are at least four additional variations on this theme, all quasi-political: Grandstanding: For the pure selfish desire to be front and center in a discussion, and a relevant force in the industry, talking about security topics in overheated terms such as ‘Cyber-War’, taking the popular side on a one-sided issue like spam, or stating “X technology is dead!” Voyeuristic Groupies: The audience for security theater. If you have ever been to Washington DC and watched the lawyers and lobbyists huddle around politicians and policy makers for the sheer enjoyment of watching partisan politics as if it were Shakespearean theater, you know what I am talking about. The audience for security theater is simply fascinated by the hacks and clever ways in which hardware, software, and people are subverted. They love security rock stars. Hacking news may not contain much actionable information, but this audience feeds on the drama. Red Herring: Cry loudly about one problem, while studiously avoiding equally troubling issues. A little security theater redirects the spotlight away from the real problem. Like how to protect oneself from Firesheep, when the real problem is security irresponsibility and sloppy web site coding practices, which are much harder to tackle. Or focusing attention on ATM skimmer fraud becoming more of a problem while releasing very little information on the rates of compromised point-of-sale computers that serve credit card readers. Both are serious security problems – and I am guessing that they cause equal financial losses – but we have published numbers in one instance and not for the other. I understand why: one makes the bank or merchant look like the victim, but the other makes them look too cheap/lazy/incompetent to provide security. Reverse Scamming: The ATM skimming article referenced above states that there are technologies that solve these problems, such as ‘Chip-and-PIN’ systems. The theoretical argument is that this system is better because it uses two-factor authentication (knowing your PIN and having the card with the chip in it), in practice these systems have been hacked with great success. Look no further that European ATM fraud rates if you have any doubt. If you are a vendor of such technologies, it’s sure great to have people think you can solve the problem, and maybe even get adopted it as a standard. What better way to fill the company coffers? One thing we know for sure is that on-line fraud rates are on the rise, and both companies and individuas are targets. What we don’t have this year is one or two popular attack types to warn users about – rather we are seeing every known type. And this is further clouded byt seeing more ‘spin’ on security news than I have ever seen before. So this year’s advice is simple: use your head, and use your credit card. Hopefully that will keep you out of trouble, or at least reduce your liability if you do find any. Share:

Information Security Magazine’s November issue is available. In it is an interesting rehash of the security monoculture debate between Bruce Schneier and Marcus Ranum some 8 years ago. Basically the hypothesis was that if all your software is provided by one vendor, a single security vulnerability means everyone is vulnerable. The result is a worldwide cascade of failures. The term “domino effect” was thrown around to describe what would happen. I remember reading that debate when it first came out, but the most interesting aspect of this discussion is actually how much the threat landscape has changed in 8 years. Much of the argument was based on a firm with a culture of insecurity. Who knew Microsoft would take security seriously, and dramatically improve their products? Who knew that corporate espionage would be a bigger threat than DDoS? And that whole Apple thing … total surprise. All in all I tend to agree with Ranum’s position, but not because of the shaky points he raised. It’s not because everyone patches at different rates, or that some systems are “loosely coupled” or in “walled gardens”, or even that the organism analogies suck. It’s because of two things: Resiliency – Marcus’s point that the first part of the scenario – hacked systems every week for the last 15 years – is spot on. But the Internet continues to rumble along, warts and all. I don’t think this has so much to do with the difference in the way servers are managed, it’s that companies are a lot better at disaster recovery that they are security. Recover from tape, patch, and move on. We know how to do this. We got hacked, we fixed the immediate problem, and we moved on. Vulnerabilities – Even if we had very small communities of software developers, is there any reason whatsoever to believe security would be better? Just because we don’t have write-once, exploit-everywhere malware, it does not mean that all the smaller vendors would not have been hacked. Just because Microsoft was a large target does not mean Adobe was any more secure. Marcus has published research on how people studiously avoid accepting blame for stupid decisions and are likely to repeat them. Even without a monoculture, classes of vulnerabilities like buffer overflow, SQL injection, and DoS are common to all software. And classes of people persist as well. It would take hackers more time and effort for every system they attack in a diversified model, but they would still be able to hack them. But the goal is usually stealthy theft of data, so the probability of detecting compromise also falls. We did see millions of web sites, applications, and databases compromised over the last 8 tears. And we know many more were never made public. And we have no way to calculate the cost in terms of lost productivity, or the damage due to corporate espionage. But recent APT attacks using unpublished Microsoft 0-day attacks, such as the recent Stuxnet attack, show it does not matter whether it’s mainstream software from a single large vendor, or obscure SCADA software nobody’s ever heard of. Every piece of software I have ever encountered has had security bugs. Monoculture or otherwise, we’ll see lots of vulnerable software. I could offer an organism based analogy, or a parable about genetics and software development, but that would probably just annoy Marcus more than I already have. Share:

You may have noticed we’ve renamed the React Faster and Better series to Incident Response Fundamentals. Securosis shows you how the security research sausage gets made, and sometimes it’s messy. We started RFAB with the idea that it would focus on advanced incident response tactics and the like. As we started writing, it was clear we first had to document the fundamentals. We tried to do both in the series, but it didn’t work out. So Rich and I re-calibrated and decided to break RFAB up into two distinct series. The first, now called Incident Response Fundamentals, goes into the structure and process of responding to incidents. The follow-up series, which will be called React Faster and Better, will delve deeply into some of the advanced topics we intended to cover. But enough of that digression. When we left off, we had talked about what you have to do from a structural standpoint (command principles, roles and organizational structure, response infrastructure and preparatory steps), an infrastructure perspective (data collection/monitoring), before the attack, during the attack (trigger, escalate, and size up and contain, investigate, and mitigate, and finally after the attack (mop up, analyze, and QA) to get a broad view of the entire incident response process. But many of you are likely thinking, “That’s great, where do I start?” And that is a very legitimate question. It’s unlikely that you’ll be able to eat the elephant in one bite, so you will need to look at breaking the process into logical phases and adopt those processes. After integrating small pieces for a while, you will be able to adopt the entire process effectively. After lots of practice, that is. So here are some ideas on how you can break up the process into logical groups: Monitor more: The good news is that monitoring typically falls under the control of the tech folks, so this is something you can (and should) do immediately. Perhaps it’s about adding additional infrastructure components to the monitoring environment, or maybe databases, or applications. We continue to be fans of monitoring everything (yes, Adrian, we know – as practical), so the more data the better. Get this going ASAP. Install the organization: Here is where you need all your persuasive powers, and then some. This takes considerable coercion within the system, and doesn’t happen overnight. Why? Because everyone needs to buy in on both the process and their response responsibilities & accountabilities. It’s not easy to get folks to step up on the record, even if they have been doing so informally. So you should get this process going ASAP as well, and coercion (you can call it ‘persuasion’) can happen concurrently with the additional monitoring. Standardize the analysis: One of the key aspects of a sustainable process is that it’s bigger than just one person; that takes some level of formality and, even more important, documentation. So you and your team should be documenting how things should get done for network investigation, endpoint investigation, and database/application attacks as well. You may want to consult an external resource for some direction here, but ultimately this kind of documentation allows you to scale your response infrastructure, as well as set expectations for what and how things need to get done in the heat of battle. This again can be driven by the technical folks. Stage a simulation: Once the powers that be agree to the process and organizational model, congratulations. Now the work can begin: it’s time to practice. We will point out over and over again that seeing a process on the white board is much different than executing it in a high-stress situation. So we recommend you run simulations periodically (perhaps without letting the team know it’s a simulation) and see how things go. You’ll quickly quickly the gaps in the process/organization (and there are always gaps) and have an opportunity to fix things before the attacks start happening for real. Start using (and improving) it: At this point, the entire process should be ready to go. Good luck. You won’t do everything right, but hopefully the thought you’ve put into the process, the standard analysis techniques, and the practice allow you to contain the damage faster, minimizing downtime and economic impact. That’s the hope anyway. But remember, it’s critical to ensure the QA/post-mortem happens so you can learn and improve the process for the next time. And there is always a next time. With that, we’ll put a ribbon on the Incident Response Fundamentals series and start working on the next set of advanced incident response-related posts. Share:

Though I have tailed off a bit from my ridiculous pace of two years ago, I still go see a lot of live music. Although many of these acts make a mint, it’s not an easy life. I can only imagine how difficult it is to be on the road for months at a time. It’s hard enough for me, and I’m only gone one or two nights at a time. Though it’s not like I’m staying at the Ritz every night (don’t tell Rich I’m staying at the Ritz, okay?). But there are examples of bands that do a job and earn their money every night. Let me highlight two great examples. First off, I saw Green Day during the summer. Those guys are one of the biggest bands in the world right now, but they haven’t forgotten where they came from. They played for almost 3 hours, had folks doing stage dives, and even gave a guitar to a lucky audience member. At one point they all dressed in drag for a few laughs. And repeatedly they made the point about how much they appreciated their fans and that they give everything every night to make sure the fans get their money’s worth. They know that seeing a rock concert is a luxury for many people, and are grateful their fans choose to spend money they may not have to see them play music. Next I’ll highlight Styx. I saw them a few weeks ago on their Grand Illusion/Pieces of Eight tour. They played each album in its entirety and it was like stepping into a time machine. These guys haven’t had a hit record in decades, but they are able to travel around and play their classics year after year. And folks like me show up every time, which I assume provides a decent living for guys who probably carry AARP cards. They get how lucky they are and they play like it. It was a great show. I guess my point is that we all have fans, whatever that definition is. Folks who allow you to do what you do. Do you appreciate them? Really? In the day to day mayhem of deadlines and other demands, I need to remember that without our readers and contributors, I wouldn’t be able to do what I love. With Thanksgiving coming up, I want to let you know how appreciative I am. For all of you who read our stuff, who show up when we pontificate, and who ask for our advice, thank you. I know I speak for Rich and Adrian as well. We know how good we have it, and that’s because of you. So before you take off for the long weekend (if you are in the US, anyway), make sure your fans know you appreciate them. I know they’d appreciate being appreciated. Photo credits: “Starsky & Hutch Appreciation Fan Club originally uploaded by Ged Carroll Incite 4 U Truth in advertising? – Stop reading this and click this link. Read the words in the picture very carefully. Doesn’t it make a pretty acronym? Mike is pretty slow, so I’ll spell it out. The first letters of McAfee’s three attributes (Focused, Unwavering, & Dedicated) spell out FUD. Really. You have to see it to believe it. I have a really hard time believing this was completely accidental, and nobody at McAfee was sniggering when they came up with it. Perhaps some marketing wonk misunderstood the meaning. Perhaps someone knew what they were doing, and wanted to see if they could pull a fast one. Perhaps this was a Titanic example of proofreading FAIL. I actually saw that while driving to my hotel for an appointment today, but only off in the distance when I couldn’t read it. Anyway, I suspect it won’t be up for long, which is too bad because it shows a heck of a sense of humor. Maybe. – RM Why bother? – The SQL Server 2008 option for massively parallel servers is going to be late. Actually, it’s already late, but it’s going to be even late-er-er or something like that. But the question in my mind is why? Why play this game at all? Why try to be the biggest and fastest relational database out there when performance benchmarks have not been a major buying considerations for databases in 15 years. Teradata has a killer database that scales great … but it’s not exactly dominating the market. Look at super-fast databases and database hardware providers historically, and tell me how they have generally done. Ant? Sequent? Yeah, exactly. I can see why Microsoft would like to be a player in that lucrative field, but the number of firms willing to spend $40k per processor on giant mission critical transaction processing systems is dwindling. BI and data warehousing is moving to generic cloud based non-relational data stores that perform 10 to 100 times better, but can be leased at fractions of the price. And the requirements of the data warehousing market are changing. My guess is that cloud services will be “good enough”, and this will be a case where “cheap, fast, and easy” cuts the massively parallel server market down before Microsoft arrives on the scene. – AL Ray Noorda rolls in his grave… – Like Shimmy, I remember when Novell was the king of networking. In fact, I cut my teeth on a Novell LAN (Token Ring, in fact) and am happy to say I have a CNE (that lapsed probably 20 years ago). But Novell is no more. It’s being acquired by Attachmate for a cool $2.2 billion. And that doesn’t seem to include some intellectual property that Microsoft is buying. It seems Attachmate is becoming a friendly CA, in that they buy mature, slow-growth businesses with big customer bases and the associated maintenance streams. Novell does compete in some growth markets like Identity Management, SIEM, and desktop management – but really the private equity guys are using leverage to buy cash flow. It’s a good model for the investors – not sure for customers.

Skipped out of town for a much needed vacation Friday, and spent the weekend in a very remote section of desert. I spent my time hiking to the top of several peaks and overlooking vast areas of uninhabited country. I rode quads, wandered around a perfectly intact 100 year old mine shaft, did some target practice with a new rifle, built giant bonfires, and sat around BSing with friends. A total departure from everyday life. So I was in a semi-euphoric state, and trying to ease my way back into work. I was not planning on delving into complex security philosophy and splitting semantic hairs. But here I am … talking about Quantum Datum. Rich’s Monday FireStarter is a departure from the norm for security. The resultant comments, not so much. Cloud, SaaS, and other distributed resource usage models are eviscerating perimeter based security models. For a lot of you who read this blog that’s a somewhat tired topic, but what to do about it is not. You need to view Rich’s comments from a data perspective. If the goal is to secure data, and the data must be self-defending because it can’t trust the infrastructure, what we do today breaks. As is his habit, Gunnar Peterson succinctly captured the essence of the friction between IT & Security in response to Mike’s “Availability Is Job #1” post: I agree that availability is job 1, its just not security’s job. We have built approx zero systems that have traditional cia, time to move on. And we fall back into the same mindset, as we don’t have a mental picture of what Rich is talking about. The closest implementations we have are DLP and DRM, and they are still still off the mark. I look at traditional C-I-A as a set of goals for security in general, and attribution as a tool – much in the way encryption and access control are tools. Rereading Rich’s post, I think I missed some of the subtleties. Rich is describing traits that self-defending data must possess, and attribution is the most difficult to construct because it defines specific use cases. Being so entrenched in our current way of thinking limits our ability to even discuss this topic in a meaningful way, because we have unlearn certain rules and definitions. Is availability job 1? Maybe. If you’re a public library. If you’re the Central Intelligence Agency, no way. Most data will fall somewhere between these two extremes, and should have restrictions on how it is available. So the question becomes: when is data available? Attribution helps us determine what’s allowed, or when data is available, and under what circumstances. But we build IT systems with the concept that the more people can access and use data, the more value it has. Rich is right: treating all data like it should be available is a broken model. Time to learn a new C-I-A. Share:

I had an insanely early flight this morning for some client work in the Bay Area, so last night I hopped out to fill up on gas and grab some pizza for family movie night (The Muppets Take Manhattan, in case you were wondering). I’m at the gas station when the guy at the pump next to me asks if I ever shop at Target. This is the sort of question that raises my wariness under most circumstances, and since we were, at that moment, about 100 meters from said Target, this line of conversation was clearly headed someplace interesting. My curiosity piqued, I said, “yes”. My pump-mate then proceeded to ask me, “We’re just trying to get some cash to find a place to stay tonight, I have this $50 gift card that I’ll sell you for $40…” “No thanks.” I realize it’s been over two decades since I lived in New Jersey (the part that likes to say they’re from New York), but some instincts never die. Anyone reading this blog knows that said gift card was, shall we say, certified pre-owned. The odds of there being $.01 left on it, never mind $50, were significantly lower than those of my baby’s diaper not requiring a full hazmat response. Or it was totally fake. This isn’t that significant an event. Most of you encounter this sort of stuff every couple years or so, at a minimum. I even once fell for an artful scam when I was traveling abroad, although my paranoia did manage to constrain the damage. But I do find the parallels with online scams interesting. Unlike my overseas adventure, this dude was clearly not the most trustworthy on the face of the planet. That’s one nice thing about online – even with bad grammar, no one knows you smell like a wet dog on a three week bender, and look like Lindsay Lohan after a weekend drug vacation with Charlie Sheen. And this dude had to run from location to location, because sitting still for very long would result in a call to law enforcement. And never mind that each contact is a one-off, costing time and gas. Perhaps it’s an effective scam, but certainly not overly efficient. Anyway, it’s been a long time since someone tried to defraud me face to face, so it was kind of refreshing. Share:

As we all get ready for the turkey-induced food coma awaiting us Yanks in two days, let me expand a bit on an incomplete thought put forth by the Hoff. His Cloudiness wonders aloud if Compliance is the Autotune of the Security Industry. Instead of having to actually craft and execute a well-tuned security program which focuses on managing risk in harmony with the business, we’ve simply learned to hum a little, add a couple of splashy effects and let the compliance Autotune do it’s thing. Genius. Forget that squirrel stuff, Hoff should just dub himself T-Comply. It’s actually worse than this. Our friends at the PCI Security Standards council have not only provided the sheet music, but also the equivalent of a nice little iPad app that has a big red button in the middle saying COMPLY. Press the button, it makes your friendly assessor go away (with his/her check for lots of money for the ROC), and you go back to playing World of Warcraft, right? Many of us rue the fact that compliance is the only thing that gets the attention of senior management. And this has resulted in the elimination of one bar previously security had to clear. These days there is really only one bar to get over: the ‘COMPLIANT’ rubber stamp you need in the annual report. There is little incentive to go beyond compliance, because if it’s good enough for the card brands it should be good enough for you, right? Of course, that’s wrong. But the ‘good’ news is that most people and organizations believe it. And they build their Auto-Tune security programs to just barely clear the bar. They are the folks at the bottom of the fraud food chain. So the reality is that Auto-Tune security is good for you, as long as you can convince senior management to clear the bar by a couple feet. Remember: You don’t have to outrun the grizzly – just your slowest friend. Yes, that’s easier said than done, but as you are munching on gizzards Thursday (or veggie meatballs and Tofurky, as it may be) be thankful that Auto-Tune security has emerged. It makes you look like a Security Rockstar in comparison. Though Chris could have used some Auto-Tune magic himself on that one. Share:

It’s drilled into us as soon as we first cut our help-desk umbilical cords and don our information security diapers: C is for Confidentiality I is for Integrity A is for Availability We cite it like a tantric mantra. Include it in every presentation, as if anyone in the audience hasn’t heard it. Put it on security tests, when it’s the equivalent of awarding points for spell your name at the top. We even use it as the core of most of our risk management frameworks. Too bad it’s wrong. Think about this for a moment. If availability is as important as confidentiality or integrity, how is CIA even possibly internally consistent? Every time we ask for a password we reduce availability. Every time we put in a firewall, access control, encryption, or nearly anything else… we restrict availability. At least when we are talking about information security. When we talk about infrastructure security, I agree that availability is still very much in the mix. But then we aren’t really concerned with confidentiality, for example – although we might still include integrity. Keeping the bits flowing? That’s infrastructure rather than information security. (And yes, it’s still important). But I do think there is still a place for the “A”. I mean, who wants to ruin a perfectly good acronym? Especially one with a pathetically juvenile non-sexual double entendre. A doesn’t stand for Availability, it stands for Attribution. Logging, monitoring, auditing, and incident response? Knowing who did what and when? That’s all attribution. Who owns a piece of information? Who can modify and change it? All that relies on attribution. Pretty much all of identity management – every username, password, and token: attribution. Availability? When it comes to information, that’s really a usability issue… not security. If anything, more availability means less security. Changing A from Availability to Attribution solves that problem and makes security internally consistent. (This is a prelude to a series of deeper theoretical (nope, not pragmatic) posts based on my Quantum Datum work. Special thanks to the Securosis Contributors for helping me flesh it out – especially Gunnar). Share: