I blogged earlier about the role of politics in security risk management, but that’s not the only non-technical factor in the game. I’m about to step into a very arcane territory in which I have no formal expertise (IOW, IANAL), so I can fully appreciate that at least one person is about to step in and tell me how ignorant I am. But hey, I’m okay with that; Socrates is my homeboy.
This is about the use of laws in risk management. I’ve had some experience doing legislative analysis, and I’ve wiped the sausage off my feet from walking through the factory, so I’ve been privy to some of the motivations behind legislation and rule-writing as well as the local policies that you would expect to see pertaining to security inside an organization. For the purposes of this post, let’s call them all “rules,” with the understanding that the term can refer to any of the three categories.
Rules can be used in different ways. They can be used as speed bumps in situations where you want to manage risk either by making it more difficult for people to do the wrong thing, or by making them THINK before doing the wrong thing (“do I really want to have to schedule a meeting with the CEO and explain to her why I want to do this? Is it worth the hassle?”). Don’t ever discount bureaucracy as a tool of risk management; it’s extremely useful. A form that has to be filled out and signed in triplicate is not only an ass-cover, but it’s also a process-shaper—one that can create a data flow through multiple departments, if you wish—that acts as a control every bit as much as the ACLs do. (In fact, if you think of a request form as a meatspace ACL, you’re halfway there.)
However, when you wield a rule as a risk management tool in this fashion, it starts to have messy, unintended consequences as the scope broadens. Here’s where we go back to the three kinds. A policy in your own organization that is useful and safe can be positively destructive if you make it apply to more than one organization. If you’re writing it into law, it’s a whole different ballgame. This is because when you use laws as risk management, you are managing your OWN perceived risk, which may not necessarily apply to anyone else; in fact, it may increase their risk while it lowers yours. (Remember the externalities?) Laws are potentially at such a high level that they have to be interpreted not only in the context of their management of risk (presumably risk to society), but also in the context of their risk to society, or to a subset of society, or to the individual. Inasmuch as you believe that security is in conflict with privacy (and your mileage will vary; see here again), a law that manages risk may also threaten privacy, or economic stability, or any other number of things.
Take the idea of limiting the purchase of firearms to one per month. This is clearly designed for risk management by slowing down the acquisition rate. However, critics of this idea will argue that anyone who wants to acquire firearms for a nefarious purpose will simply collude with other persons to get them faster, or will simply be patient. At the same time, a restriction of this kind may well conflict with what many regard as the absolute, Constitutionally granted right to bear arms (not arm, arms). So the debate will center around three questions: Is the method of risk management effective? Is the risk really as high as you think it is? and: Is this posing a more fundamental risk to civil liberties?
Writing and enacting legislation to manage risk is possibly the hardest task there is. It helps if you are very conscious, clear and forthcoming about what you’re trying to manage, and if you are open to learning about any and all associated side effects, even ones you never considered or don’t care about.
Me, I think I’ll go back to writing policies about media file storage on corporate-owned desktops. It’s probably a lot safer. I have yet to be threatened with a sharpened mp3 of “Witch Doctor.”
Posted by
shrdlu on Monday, February 15, 2010
(1)
Comments •
Permalink •
(I was originally going to title this blog post “plus la meme,” but was worried that I would be the only who found it amusing ...)
It’s clear that we have way too many security problems with software today. You can’t throw an exception without hitting someone who will happily pontificate on how software is crap and we’re all going to die. There are very, very few people who are willing to strike out in a risky direction to do something about it.
Josh Corman is one of those people out there braving the elements. He is in the process of introducing the Rugged Software movement, complete with its own Manifesto, which says in its entirety:
I am rugged - and more importantly, my code is rugged.
I recognize that software has become a foundation of our modern world.
I recognize the awesome responsibility that comes with this foundational role.
I recognize that my code will be used in ways I cannot anticipate, in ways it was not designed, and for longer than it was ever intended.
I recognize that my code will be attacked by talented and persistent adversaries who threaten our physical, economic, and national security.
I recognize these things - and I choose to be rugged.
I am rugged because I refuse to be a source of vulnerability or weakness.
I am rugged because I assure my code will support its mission.
I am rugged because my code can face these challenges and persist in spite of them.
I am rugged, not because it is easy, but because it is necessary… and I am up for the challenge.
Now, this is an interesting and vital attempt at social engineering, in the best sense. As a security manager, I’m fully aware that security is not one of the elements included in the concept of software Quality Assurance. It’s not even listed as a Functional Requirement in software requirement specifications. Hardly anyone outside of the security field today would consider an application to be incomplete without security written in. To change this will require a mindshift of extraordinary magnitude. (Insert pop culture reference here.)
Right now, the argument about secure software is pitting security professionals against software developers; in order to get developers to take this seriously, we need to take their focus off of us as their adversary and put it where it belongs: on actual hackers. “Rugged” doesn’t just mean hack-resistant; it means software that can withstand accidental misuse and random, unpredictable stresses. (When describing this requirement to developers in the past, I’ve pointed out use cases and told them that we also need abuse cases.) Bridges are built not only to withstand normal traffic and explosives; they’re also built to withstand the forces of nature, surges in traffic and any other unpredictable performance scenarios. This is what we need to get across to developers.
When he was working on it, Josh called me up to ask whether I thought it was too “macho.” It’s true that “rugged” (meaning “tough,” not “toupéed”) instantly evokes images of Clint Eastwood and very large pickup trucks, but I really don’t see a better way to describe what we need. And frankly, if it will finally get developers to VALIDATE THEIR FRICKIN INPUT, I don’t really care whether it also causes them to want to hold their scrum meetings at Hooters.
Now, this is only a baby meme. I talked to folks at Shmoocon who liked the idea, but felt there wasn’t enough “there” there yet, in terms of having something concrete that they could take back to their IT departments and present. So there’s still a lot of work that needs to be done, but that just means that all of us need to grab our pickaxes and shovels and dig in. If this is something that you feel you can believe in, follow the gourd and keep the movement going!
Posted by
shrdlu on Sunday, February 14, 2010
(1)
Comments •
Permalink •
Wherever two or more people are gathered, there are politics.
This is no different in security, and yet very few people acknowledge this in their risk models, perhaps because the potential loss there is so hard to quantify. And yet the political aspect permeates many of our risk decisions, and affects them either positively or negatively.
Take a simple example: let’s take the discussion that always happens around a security breach. People want to know whether someone was fired as a result of a breach or otherwise disciplined, and unless you actually identify a likely suspect and see him cleaning out his desk, you’ll never get an answer. This is for a very simple reason: it is generally company policy never to discuss HR matters. Whether it’s out of a fear of litigation or simply out of discretion, management will never confirm or deny disciplinary actions. This makes your life more complicated if you work in security: you CAN’T talk about what you know. You can’t hold anyone up as an example of what really happens when you circumvent the web filters and download porn, even if it would help you motivate everyone else to follow the rules.
Another example: it would be a lot easier to prevent phishing and malware from entering your network if you could just block email from those pesky customers. But because it could be a legal or public relations nightmare if you were seen to be ignoring a member of the public, you have to open a lot more bizarre messages than you really wanted to.
We all know someone in our organization who either gets away with the security equivalent of murder because of Who She Is, or conversely, who has to be protected even more stringently than others because a security incident would cause more political damage.
But if you’re working for an organization that carries more than its fair share of political risk—say, because it’s a entity everyone loves to hate—then just about every operational decision you make will have a tinge of political calculation to it, and your organization as a whole will have a much more defensive posture. For example, if you live under the threat of FOIA requests, your considerations of how and whether to retain email—and even when to use email at all—will be heavily influenced by your calculation of the political risk if even something innocent is obtained and misused by someone with an agenda. You’ll start walking down the hall to have any conversation on a topic that you think might possibly be used against you somehow in the future—even if you are having a perfectly legal, ethical and sensible discussion. You will retain documents exactly as long as you are legally required to do so, and no longer; you won’t simply archive everything and forget about it the way another organization would, because every written record is a double-edged sword.
An organization under political threat will manage to that threat rather than to the security threats we usually think about. Practically speaking, CEOs are a lot more afraid of auditors and attorneys than they are of hackers, because they can calculate the event frequency of being audited or being sued a LOT better than they can figure out how likely they are to get pwned. This is also why they will manage to the flashiest, most recently headlined security threats rather than the ones from last year (that still aren’t mitigated). They will try hardest to avoid that which is most embarrassing rather than that which is most probable or will cause the most technical damage.
And what is most embarrassing can depend not only on the type of business you’re in, but also on your organizational culture. Josh Corman, who has the annoying habit of rooting my thought processes on a regular basis, posed the question today: How do personal politics affect the way you approach Security?
In my experience, personal politics can affect your security work quite a bit—whether it’s deciding how much to monitor employees or formulating an answer to a complaint. If you’re the kind of person who strongly believes in authority, you will tend to use more of an enforcement model when implementing security, rather than using a persuasive, consensus-driven approach. If you distrust authority, you will spend as much time working to protect peoples’ privacy as to protect the systems they use. If you were to take a poll of which security professionals believed there was (or should be) no conflict between security and privacy, I think you would be able to intuit quite successfully the respondents’ political leanings, along with their preferred management styles.
So I believe politics can affect both how you assess and prioritize your security risks, and how you go about mitigating them. If you had some kind of magic Silly String that you could spray into your organization to highlight the invisible political tripwires, you’d have a much broader picture of your security risk landscape.
Posted by
shrdlu on Saturday, January 23, 2010
(0)
Comments •
Permalink •
The good ol’ boys at the Southern Fried Security Podcast were kind enough to deal me in for one round. Make sure to listen to their comments after the interview; such magnificent shovel work only comes along once in a generation.
Posted by
shrdlu on Wednesday, January 13, 2010
(1)
Comments •
Permalink •
I got a really great comment from Esteban on one of my older posts. He asked:
- in the example of purchasin[g] a SIM, SIEM, IDM solution who should be involved (besides finance of course)? CISO? CTO? M-level from IT?
In the cases that he mentioned, these tools are all “up the stack” and much, much closer to the business processes. Identity and Access Management gets into the very heart of your organization’s policy for letting people access your information; that’s why it’s so hard to implement without their understanding and co-operation. And SIEM—well, that’s also about information, isn’t it? And if your information is not relatable directly to business intelligence, then your customer base is not going to care about it one bit.
Nobody cares about IDS alerts any more. Hell, *I* don’t care about them any more. Okay, I pay someone to care, and even HE doesn’t get all excited about them anymore—EXCEPT inasmuch as it tells him on a higher level what’s going on with the data in our network. He’s looking at it not from the perspective of the latest signatures and exploits; he’s looking at them to see whether traffic is flowing in unusual ways that mean that someone has a spyware infection, someone installed an application that nobody approved, or someone took the equivalent of pinking shears to the routing tables again.
When you take security intelligence to the next level, it’s more useful to people outside the security group. Database activity monitoring can tell developers a lot of things they didn’t know about how their applications are working (or not). Access event logs can tell data owners how widely adopted their data sets have become. A GRC dashboard (*ickshudder*) can tell a CTO which remote sites are rebelling against technology standards. LonerVamp had an awesome blog post featuring an epiphany that DLP is really a Sensitive Business Process Identifier.
For this reason, when you go shopping for one of these intelligence tools, you really need to be involving as many other business areas as you can that may benefit from it. For one thing, it’ll make sure you’re making the right choices; for another, it helps to get wider buy-in before the price quote even lands on your CFO’s desk. And if it’s turning out to be the kind of tool you’re only buying for yourself ... then you really should think about whether you’re serving your customers’ security needs at all.
Posted by
shrdlu on Saturday, January 09, 2010
(0)
Comments •
Permalink •
Well, a few people are posting their versions of roundups or awards and whatnot, so I thought I’d come up with my own set of awards. In no particular order:
The Twenex Award for some bodacious security babes: @geekgrrl, @jackiea
The Lifesaver Award: @BIOSShadow
Most Likely To Be Professionally Associated With Animals of Various Kinds: @Beaker
The (Stud)Muffin Man Award: @mortman
Filling Up All the Spots on My “Favorites” List: @shawnmoyer
Most Generous With Their Time and Advice: @rmogull, @securityincite, @adamshostack, @bkdelong
Most Generous With His Time, Advice and Flabongo: @rybolov
Honorary BSOFH Awards: @armorguy, @dunsany, @csoandy (they know why)
Host with the Most (at 65 mph, even): @jack_daniel
Most Intimidating Blogger, in Sheer Volume and Sophisticated Geekiness: @lmacvittie
Sexiest Canadians: @gattaca and @myrcurial
Is There Such a Thing As an Irish Cabana Boy?: @BrianHonan
Haiku-Fu Scooby-Doo Award: @ghostnomad
Breakfast Cereal or Operating System? You Decide: @mubix
David Byrne Award for Most Photogenic: @quine
The 30-Second Stalk Award: @sfoak
The Sunshine Overdose Award: @kairoer
The MIA Award: @alexhutton, who probably won’t even see this until after the 1200th diaper change
And finally:
The Keepin’ It Real Award: @danielkennedy74 
Happy 2010, and keep those bits flying!
Posted by
shrdlu on Wednesday, December 30, 2009
(1)
Comments •
Permalink •
It occurred to me the other day that while it’s always fun to talk security with analysts (hell, who doesn’t like being asked for their opinion?), they probably shouldn’t be talking to me. Or at least, they shouldn’t be talking exclusively to me.
The security community is a pretty self-selecting group. If you only interview people on Twitter, people who blog about security (or comment on those blogs), or people who go to security conferences, you’re not getting an accurate picture of the security landscape. You’re ignoring the vast majority of people who are responsible in some way for the security of their networks, but (a) don’t know it, (b) don’t care, and/or (c) don’t have the knowledge or management backing to do anything about it.
How many organizations out there consider data breach notification laws to be completely irrelevant to them? Not because they aren’t applicable, but because the organization’s security state is so abysmal that they wouldn’t know a data breach if it sent them a strippergram with their own money? How many are falling through the cracks of compliance because they’re too small, in the wrong industry, or simply trapped in the security ghetto? How many are not in Verizon’s breach database because it would never occur to them to call?
On the one hand, the answers will probably make you depressed. On the other hand, those of you who are lusting after accurate data will probably regard anything that expands our state of knowledge as something to be pursued. We need more outreach—not for the sake of selling more security widgets or services, but simply to bridge the security divide.
Posted by
shrdlu on Sunday, December 27, 2009
(3)
Comments •
Permalink •
“Boss, are you in there?” the Intern quavered as he heard his voice echoing in the cavernous space.
“Sure, come on in,” I yelled, and brought the forklift to a slower amble down the improvised corridor of the warehouse floor. “Watch out, don’t trip on the—oh well, too late.”
I hustled over to pick him up off the cable pile. He was still looking around wild-eyed. “What have you done now??”
“I’m reinventing myself as a services provider, my boy. Welcome to the new hosting facility for Quantum Cloud, LLC.”
“I can’t believe ... where did you ... my god, it’s full of racks,” he said. “You’re going to be a cloud provider?”
“Already am,” I said. “We’re all about quick, seamless provisioning, you know. I’ve got my first set of customers already up and running over in Sector R.” I pointed over to a far corner. “It’s easy as setting up a blog—easier, in fact, because there’s less creative thinking involved and you don’t have to know how to spell.”
A chime sounded near the front door. “Uh-oh,” I said. “One of my customers. And if I’m not mistaken, that guy with him has AUDITOR written all over him.”
The customer didn’t look happy. “See here,” he said, “I’m exercising my right to audit as listed in the service contract. This is Edgar, from BowyerShipwrightHoopleMidbanks. He’ll be collecting the audit data and examining the configurations.”
“Excellent,” I said. “Come right this way. I have the Audit Table all set up for you. All the materials are there, in those three binders. Help yourself.” As they seated themselves, I started shooing the Intern back towards the rushing sound of the fans in the live corner.
“Hang on,” said Edgar. “I have a list of questions that I need you to answer. And when do I get a login to the system?”
“I’m sorry,” I replied, “but we don’t answer questions. Access is strictly prohibited to all but Quantum Cloud employees. The information for your audit is in the binders.”
“But ... the contract says I have a right to audit!” stammered the customer.
“Indeed it does. But it doesn’t state what constitutes an audit, and it doesn’t allow you any privileged access on the hosts. Remember, this is cloud computing—we simply provide the services and run the underlying platforms for you; you’re not supposed to know or care about the technical details.”
“Can’t I at least interview one of your staff?” asked Edgar impatiently. “You! Over there! A few minutes, please.” The technician got up slowly from his console and warily approached us, looking to me for cues. “Is this really your only administrator? Where are the others?”
“Oh, he can do it all by himself. We found the BEST cloud administrator! He’s worth at least five regular sysadmins.”
“Why? Is he Cloud Certified?” the customer wanted to know.
“No, but his name is WIN!” I said cheerfully. “You can’t get better than that!”
“Um, actually, it’s Wim,” mumbled the technician.
“Close enough,” I said. “Anyway, you don’t need as many people to run a cloud; all the controls are integrated into one console. All Win here has to do is click on the menus and move the little icons around on the dashboard.”
“Can we see the console?” asked Edgar.
“Of course not! That’s proprietary,” I replied. “All of our resource monitoring, management, load balancing and environmental controls are our own design; we don’t share them with anybody.”
“And security?”
“Oh, right. Security. Sure,” I said.
“Excuse me, I have a conference call,” squeaked the Intern and headed for the door. He’d heard enough.
“But ... we need to audit against the service level agreement,” said Edgar desperately. “We need to make sure you’re really providing the resources on demand.”
“Well, it isn’t really on DEMAND,” I hedged. “It’s more like resources on entreaty. If you complete enough paperwork and enter a new trouble ticket every day for, oh, about six weeks, we might agree to allocate some more of whatever it is you need. Memory is fastest; we can just steal it from one of the other customers and they generally don’t notice.”
The customer’s face, which had been acquiring a robust claret hue, suddenly went the color of chardonnay instead. “Do you mean—have you ever taken any from OUR systems?”
“Sure—we just move it around to whoever’s yelling the loudest at the time. We’re all about dynamic allocation, you know. Agility. Orchestration. All those cool words. It’s really all just juggling.”
“That dynamic allocation was supposed to make our services perform faster!” he snarled. “Quantum Cloud! Services at the speed of light!”
“I’m afraid you misunderstood the marketing,” I said smoothly. “The dynamic, self-adjusting service orchestration is for US, not for any given customer. We run a multi-tenancy operation here. Our agility allows us to react instantly to fulfill our business needs and recover from ... potential disasters,” I said, gesturing with my chin at Edgar.
“That’s it! We’re terminating our contract,” bellowed the customer. “I want our data transferred out of here as soon as I get another provider. Tonight at the latest!”
“Oh, we can’t do it tonight,” I said. “Maintenance window. Downloading patches is going to saturate our Internet connection. It’s only residential cable service. Besides, we’ll have to figure out where all your data is stored.”
“You mean, you don’t KNOW??” He was hyperventilating now. Edgar dropped his BlackBerry and grabbed him under the arms to hold him up.
“Well, we have a pretty good idea. I mean, we can calculate it with high probability. That’s what the ‘Quantum’ part means. Win here is a particle physicist.”
“How long will it take him to find the data and transfer it back?” whispered the auditor as he fanned his client’s face.
“I don’t know, that’s not his job. We’ll have to call our Cloud Migration Manager. He was responsible for moving your applications in the first place and making them standardized to fit our efficiency model. To be honest, I’m not sure what shape your data is in right now; I don’t know what he did with it to make it work.”
I picked up the desk phone from the table and punched two buttons. “Get Procrustes on the line, will you?”
There was a double thud behind me. I sighed and went back to start up the forklift. It’s so difficult to get customers to leave once they get into your workspace.
Simon Travaglia rocks the house
Posted by
shrdlu on Saturday, November 28, 2009
(0)
Comments •
Permalink •
“Oh, there you are, Terry,” I said to the Intern as he peered cautiously around the doorjamb. “Come on in. You’re finally going to learn the secrets of my operation.”
“What IS all this? And why is it even darker than in the sysadmins’ cubes?” he wanted to know.
“This, my boy, is my money-making operation. You don’t really think I can afford all my toys on an ISO salary alone, do you? Not to mention the ongoing bribes.”
He gazed at all the women sitting around with headsets, staring at flatscreens. “You’re running a HELP DESK??”
“Not quite. Meet the one, the ONLY, security phone chat line. And by chat I mean a very special kind of chat. We give the security geeks the one thing they can’t get anywhere else.”
He shivered. “You mean ...?”
“Yes. We talk SECURITY to them. Raw, unadulterated, uninhibited security. We use the words they want to hear. And believe me, they pay a LOT for it.”
I took him by the first pod, where a comely young thing was saying, “Oh yeah, I’m compliant, baby. Want to see my controls?”
“Auditors,” I said, shaking my head and moving him along to the next pod down. “They’re the kinkiest of the lot. Here, this girl is popular these days.”
She had a cloud taxonomy diagram on her screen. “No, no, the cloud can be anything you want it to be. What do you WANT it to be? ... oh yes, we can be private ... very ... private ...”
“What’s that?” asked the Intern, pointing to a symbol pinned up on her cubicle wall. It had a silhoutette of a squirrel with a circle and line over it.
“Never mind. We used to have this one really insistent caller. He was free with the bucks, but the girls were getting a little creeped out.”
From the other end of the room, a voice moaned loudly, “YES! YES! The saturation of vulnerable technology measures the aggregate attack surface available to the exploit code!” The Intern blanched and covered his ears.
“Boss?” said one worker, tugging on my sleeve. “We got a Code Twenex.”
“Okay, don’t panic. Where’s Mike?”
“He’s on break.”
“Tell Pete to stop tweeting and take the call. He’ll do well enough.” I turned back to the puzzled Intern. “We got a woman on the line. It’s rare, but it happens. I charge ‘em double, though. Our boys tend to be exhausted after just one 15-minute session.”
“I just can’t believe you’re making money with this,” the Intern said. “Isn’t this ... well ... illicit? I mean, it’s got to be wrong somehow.”
“Why?” I replied. “It isn’t cheating unless you actually USE the exploit.”
“No, I mean, don’t they have families?”
“Look, we provide a valuable service here. Not everyone can go to a conference as often as they need to. This way they can let off steam, get it out of their system, and go home and pay real attention to their loved ones. Our clients report that they’re much less likely to sneak a look at their BlackBerry, read Liquidmatrix, or talk about responsible disclosure in their sleep. Their home life is BETTER, not worse. One woman even called to thank us, to say she finally could stop role-playing DNS zone transfers.”
“Okay, THAT was TMI.” The Intern looked faintly disgusted. “Can I go back to GRC console hacking now? This is all making me feel a bit dirty.”
“Yeah, go ahead, kid,” I laughed. “You’re not old enough to appreciate the hard-core stuff yet. Just keep this on the down-low, okay?”
“Sure,” he said hurriedly as he fumbled for the door. I popped another diet Mountain Dew and relaxed on the velvet-covered couch. The NIST folks would be getting out of session soon and then we were going to be REALLY busy.
Thanks to Simon Travaglia, as always.
Posted by
shrdlu on Sunday, November 22, 2009
(6)
Comments •
Permalink •
I started writing about metrics at the very beginning of this blog, and hadn’t really seen anything I could add to the ongoing blogo-discussion since then, but the planets aligned: I had a thought-provoking discussion with a super-sharp colleague, and it was followed by a Saturday in which I finally have a little time to write.
This provocateur kept referring to “security practitioners” as opposed to—well, everyone else in the security space, I suppose—and I began wondering what the cultural differences are between the two spheres. The implication is that “real practitioners” know what the real risks are, because they’re living them every day. (What is a practitioner, anyway? Let’s just say it’s someone who’s directly responsible for protecting an organization’s data, as opposed to someone who is developing problems or solutions for OTHER organizations’ data. You can argue with that definition if you like, but I’ll bet if you do, you’re not someone who meets the first description. ) But I don’t find that necessarily to be the case. One of the great frustrations that I see with vendors, researchers, analysts and regulators is that they don’t believe most practitioners actually understand the risk landscape. The only group that arguably does is the one that’s getting attacked the most—the military—and they can’t talk about it. The only other group that kinda understands is the financial institutions, and they won’t talk about it even if they get caught with their cyber-pants down. I remember hearing a great talk by Aaron Turner that was eye-opening in its level of disclosure about things that were really happening, and that was only because of a confidentiality agreement; you’d never get that level of discourse in the public blogosphere.
The reason I think that most practitioners don’t appreciate the security risks in the same way that other security professionals do is this: [donning my asbestos undies] for the most part, security breaches don’t have observable impact in the real world.
Wait, wait, before you click on the comment field—read the rest of this entry.
Riddle me this: when has anyone died as a result of a “cyber” security breach? When has anyone been injured? And can you prove it?
The only group that can even get CLOSE to answering that question is the military, because the loss of military information can arguably lead down the path to that very real scenario. For them, the two are so closely linked that a “hit” on a system is really appreciated as being a “hit” in the very core of their business.
But I’m going to argue that for ALL the rest of us practitioners—including the financial institutions—there is no real, consistent, demonstrable impact. The only effect is in currency numbers, and those are, at the end of the day, just numbers. Money is a way of keeping score. Sure, if you’re homeless and on the street, the lack of money at your level is going to have a very concrete effect on your life. And if you’re a poor nation, the lack of money at that mega-scale is going to have a concrete effect on the quality of everyone’s life. But in the vast realm in between, where we’re talking about security breaches, I’m going to argue that it’s just score-keeping. (“They stole MILLIONS of our numbers and siphoned them off to Russia!”)
Stock price? Nobody can prove that stock price goes down because of a revealed security breach.
Regulatory fines? Have you ever seen an institution fail solely due to regulatory fines? Have you ever seen people lose jobs because their employers had to pay fines?
Downtime and recovery costs? Okay, now you’re getting somewhere, BUT.
BUT.
I submit that organizations don’t make a distinction between downtime due to security breaches and downtime due to any other reason. Nick Selby hit the hammer on the thumb right here in his excellent post pointing this out. For the purposes of risk planning, most organizations see cyberattacks as a force of nature just as they do ice storms, tornados, backhoes, and misplaced dolphins.
So if attacks on computer systems aren’t seen as different or more dangerous than simple availability problems—because by and large the only concrete, real-world impacts look exactly the same—then why are we trying so hard to convince practitioners (and ourselves) that there IS a difference?
And why are we trying to describe the risk of losing numbers in terms of MORE NUMBERS?
Folks, simply driving to more precise numbers isn’t going to make anyone appreciate this kind of risk any more. Or let’s put it another way: the only people who will appreciate those numbers are people who already appreciate numbers. The score-keepers can relate to the metrics folks and they can sit together and entertain each other.
But for the average Joe Practitioner, I believe that security breaches simply don’t have real-world importance. This is why nobody but security wonks gets exercised about the existence of botnets, even if they’re in one (“MILLIONS of BOTS!”). This is why organizations just don’t get freaked out over scan reports that show that they have EIGHT HUNDRED VULNERABILITIES!!!1 This is why only Homeland Security bureaucrats care about the number of hits seen on an IDS (“MILLIONS OF ATTACKS FOILED!”). And this is why only the media gets excited about OMGWTFHEARTLAND!!
This is why even the frantic, hopeless pursuit of security ROI isn’t going to make any difference. It’s still numbers. Sorry, guys.
Until people start losing concrete things that they really care about—homes, food, health, loved ones—as a consistent, demonstrable, direct result of cyberattacks, they’re just not going to bestir themselves to divert funding from defending against risks that actually do have an impact.
So what does that mean for security metrics?
Keep applying the “so what?” criterion to your metrics. Make sure that the metrics can be linked both to evidence-based probability and impact. Impact that results in lowering the number of products that ship per hour. Impact that results in unavoidable personnel costs that affect the organization’s bottom line more than once in a decade. If you can’t make your management get excited about your metrics, it’s because your metrics aren’t exciting.
Make sure you’re not just score-keeping in a game that the rest of the world doesn’t care about. Don’t be a metrics wanker.
Posted by
shrdlu on Saturday, November 21, 2009
(3)
Comments •
Permalink •
Remember long phone calls?
When I was a teenager, our kitchen phone was mounted on the wall; the cord was long enough so that when I got a call during dinner, I could stretch it around the corner into the hall closet, where I’d close the door and conduct whatever urgent business was required (“What are we doing tonight?” “I dunno, did you call Babs?” “She doesn’t know what we’re doing either.” “Do you wanna go to the mall?”). And I also had a phone upstairs in my room, so that I could spend long hours on the phone with a friend late at night (“So what did Babs do while we were at the mall?”).
Somewhere in the intervening years, those long, purposeless chats with friends turned into IMs.
Me: Gotta reboot this POS again
BFF: Sucks
Me: Yeah
BFF: So, what are you doing tonight?
Me: Dunno. You?
BFF: Dunno. It’s almost dawn over here.
Me: Oh yeah.
Now that I’m older, the only long, purposeless chats I have on the phone are conference calls.
CEO: Has Toyko joined yet?
NYC: Nope
CEO: And we’re waiting for Sydney, right?
FRA: Yep
DFW: Babs says she’ll be here in a minute, she’s finishing up another call.
CEO: So, what’s anybody doing tonight?
But the rest of the time, the phone has turned into an instrument used only for very short transactions.
“Can you get the SOW signed by Monday? Okay, great. Staff are ready to start on Tuesday. Fine, I’ll get the conference room booked for them. Bye.”
“Can you come see me?” “Sure, five minutes.” “Okay, bye.”
So I’ve discovered that I’ve lost the fine art of hanging out on the phone with a friend. It doesn’t help, of course, that my kids have discovered that there’s a set of wireless headphones in the house that pick up the signal from the cordless phone (I have to confiscate them when I want to have a private conversation). But in general, these days are so busy that if I’m not Getting Something Done on the phone, then I can’t just stay on the phone.
Time to pass it on to the next generation. My oldest wants to figure out what she’s doing this weekend.
Posted by
shrdlu on Saturday, October 24, 2009
(1)
Comments •
Permalink •
Forgot to mention that the generous Craig Balding lent me a soapbox for a short time:
Might As Well Face It
Posted by
shrdlu on Sunday, September 27, 2009
(0)
Comments •
Permalink •
Here’s a question for you all playing along at home: do you ever delay rolling out a new official security policy?
There are plenty of policies that cost money to implement: systems have to be reconfigured, applications have to be rewritten (and in some cases massively redesigned), business processes have to change—these all cost time and money that your organization may not have in sufficient amounts. You want to do the right thing, but you know you can’t do the right thing all at once.
So do you put the policy on the books, knowing there’s a risk that auditors will come along and use the policy against you because you’re not actually quite following it just yet?
If you don’t publish the policy, how will people know about it so that they can start following it as soon as they can?
I tend to cheat. I roll them out as guidelines first. I start talking them up, especially to the groups that are best positioned to start following it early (such as those writing a new application), and warn them that at Some Point in the Future, they’re going to become official, so I’d like to help them work on aligning with them now. This creates the impression that I’m trying to help them get a leg up—why, it’s almost like helping them cheat on a test that hasn’t come up yet. The news is often received better that way, as long as nobody panics when they first hear of it.
More what you’d call “guidelines” than actual rules.
(Only a few days late posting, me hearties ...)
Posted by
shrdlu on Saturday, September 26, 2009
(4)
Comments •
Permalink •
And now, the moment you’ve all been waiting for: The Security Intern Interview!
==================
Conducted over a couple of days by email (only because I didn’t think of one of the questions until the next day). Hey, I wouldn’t do something this important in less than 140.
@securityintern
1. How did you become the Security Intern?
I’d been a reader of Liquidmatrix for a long while and I know James Arlen personally. Through him I knew that both he and Dave (Lewis) were going through a particularly busy/stressful period and neither had a lot of time to spend on the digest. I put the first news digest together and emailed it anon to James. I didn’t want him to feel obligated to use it, nor did I want to be embarrassed if it was complete shit. I tagged it with a simple note: “If you do publish this, I’ll send another tomorrow.” And so it began. I thought that I’d do the job for a few weeks and then Dave and James would pick it back up and we’d part ways. As it turns out, they like having me around.
2. So, did you actually plan to be a mystery from the beginning on Twitter, or did it just kind of happen that way?
I started doing the news briefs in October and then Twitter in December, if I recall correctly. Originally I was just going to use Twitter to promote the blog. What I did not anticipate was the feedback from the security community on Twitter. Most of it has been very positive and that part was very compelling. I wrongly assumed that I’d sort of just be written off as the newshound. The interest in The Intern was sort of exciting and then right around the same time, I started to get comments on the blog and some email encouraging me to continue.
3. Did you hide your gender on purpose, or was it simply that everyone assumed you were male? Or did you just try to be gender-neutral?
I tried to be gender-neutral in the beginning, people seemed to assume I was male. I’m actually a Social Sciences student with a keen interest in Labour Studies and human behaviour is extremely interesting to me. I suddenly found myself in the middle of a gender-biased experiment of sorts. I also enjoy a fair amount of creative writing which fed right into this.
4. What made you decide to “out yourself” now? Was it simply that you were going to DEFCON and it’s pretty hard to hide your gender when you show up somewhere in real life?
There’s been nothing simple about outing myself. As I stated, I really thought I’d fade into the woodwork after a few weeks. One of my biggest issues was that people were really nice to who they think the intern is and I felt like I wasn’t being honest. I know, a scenario I created myself. Having said that, it was interesting to me how quickly this group of professionals, known to be cynical, paranoid and skeptical engaged with the intern. DefCon seems to be the right time for this. I am not a 19 year old male, surprise!
5. What security work do you do other than the work you do for LSD?
Exactly none though I do know some of the basics thanks to a few years spent working at an ISP doing tech support and a bit of web design.
6. WHERE did you get that AVATAR??
My first twitter avatar was the Starbucks logo which seemed appropriate at the beginning. Then someone, I don’t remember who, began asking about what I looked like. I hit the Google image files pretty hard putting in all sorts of search terms. “Intern” “security” “lackey”, everything I could think of. And then there he was, smiling with his coffee pot and I could tell he was put there for me to find him. The question now is… do I keep him?
7. Does anyone outside of LSD get to know your real name?
One person found out who I am a few weeks ago. I made a mistake when I changed the settings in my email account. Rookie error. One other person knows I am a woman, I told them a few weeks ago. I was trying to gauge how people would react. That person gave me some sage advice, I gained confidence that day.
8. Are there any other earth-shattering secrets that you’re going to hold back from us?
I have freakishly dexterous toes, I brush my teeth in the shower and my mother’s maiden name is… oh wait. Not really, I’m pretty boring.
9. Now that people are going to meet you in real life, are you still going to keep the avatar and mystery going on Twitter?
I honestly can’t answer that. Given how wrong I’ve been up to this point, I’m not going to make any predictions.
10. Are you really into Scarlett Johansenn?
She’s beautiful. I’m not sure if it’s genuine lust or I secretly wish I looked like her.
11. And finally—does this mean our hot hookup is off for next year?
Show up and find out.
==================
(I just hope @myrcurial doesn’t totally kick my ass—it was just harmless flirting, I swear I never laid a finger on her, man!)
Posted by
shrdlu on Thursday, July 30, 2009
(3)
Comments •
Permalink •
I found myself in an interesting conundrum the other day as I was talking to a consultant who was trying to architect a system for me. Now, this guy is a top professional in his field, used to doing this for the Fortune 3.5 or whoever, and he produced a real work of art in the modern style that we call “high availability.” It had synchronization, it had failover, it had clustering, it had all the latest and greatest cornices and articulation and latticework and EVERYTHING.
I couldn’t use it.
Not just because it was too expensive a solution, and not just because of other oddities unique to our environment, but because that level of complexity made it unsupportable by the staff we have in-house.
So we went back to the drawing board, and talked about what WOULD work, and what we came out with was not high availability, but high recoverability. We settled for fewer moving parts, but backfilled with compromises like backups of the VMs so that we could replace them more quickly. Yes, we would have downtime, but with any luck it would be briefer downtime than if we had to bring him back in from the other side of the country to troubleshoot something that only he and a few others at his altitude understood. And with a simpler, more supportable architecture, hopefully that would prevent downtime on the front end to begin with.
So high availability and high recoverability are two sides of the coin that our friend Christofer “SQUIRREL!” Hoff would call “survivability.” (See? I *do* listen to you now and again. )
Posted by
shrdlu on Wednesday, July 29, 2009
(4)
Comments •
Permalink •
