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
(2)
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 •
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 •
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 •
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 •
“In the very moment that you attempt to achieve compliancy, you have lost it,” explained the master. “Strive therefore simply to be secure, and compliancy will come of itself.”
Saying “compliancy,” thus was the master exposed as a vendor, and the students beat him.
“Master, master!” cried the student as he entered the temple. “I was meditating, and had a great vision. All threats were united into one entity, and thus were they managed together. I have finally become enlightened!”
The master hit the student. “You were not enlightened,” he told him. “You were pwned.”
What is this mind?
Who is hearing these sounds?
Do not mistake any state for
Self-realization, but continue
To ask yourself even more intensely,
Who is logged into my SAP system?
“All roads lead to DEFCON,” said the master to the students as they were sitting beneath the trees.
One student raised his budget. “See, master, I cannot travel.”
“DEFCON is of the mind, not the budget,” replied the master. “Find but the right t-shirt, and you shall know it. All that you require is within you. Be still within your heart, seek always the Riviera Path, and DEFCON shall find you.”
“The hell with this,” said the student, and wandered off to find a mojito.
Those who see worldly life as an obstacle to Security
see no Security in everyday actions.
They have not yet discovered that
there are no everyday actions outside of Security.
At least, not when you are outside the C-suite.
“There are no material findings,” said the master to the QSA, “since there is no material world. All is impermanent in this world of the mind.”
“And yet,” replied the QSA, “PCI-DSS is not of this world, and therefore you may reach the state of compliance with it.”
And the master said nothing.
Secure and insecure have no self nature;
Open and closed are empty names;
In front of the firewall is the land of LOLcats and phishing;
And also inside, where the users bring them.
“Your server settings are not compliant,” said the auditor.
“This is not surprising,” said the master with equanimity, “for the server you are inspecting is a UPS.”
The auditor was not enlightened, and wrote him up anyway.
The perimeter is no perimeter. —Jericho
The intern approached the master. “Master, I would like to become a CISO. How do I enter the world of security?”
The master replied, “You have no servers.”
The intern nodded sheepishly.
The master continued, “You have no network.”
The intern also acknowledged this with sadness.
The master concluded, “And you have no users.”
The intern replied, “All this is so, Master. Have I no hope of achieving security?”
“Fear not,” said the master kindly. “You have already achieved it perfectly.”
Posted by
shrdlu on Saturday, July 25, 2009
(4)
Comments •
Permalink •
Catching up on my blog feeds, I see that Rich has been having a heated discussion on data classification and labels. I agree with him: beyond a very high level, data classification is too costly to be useful in most environments. When you start trying to get granular in your classification (“this document is confidential, this table is sensitive, these app pages are TopSekrit ...”), you immediately run into the temptation to label them so that they stay classified for everyone else to see. This leads to problems:
- Are you labelling the data, or the container holding the data? (Look at my examples above. Those are all containers, not the data. And yet, this is how people try to label things.)
- If you’re labelling the container, what do you do when the data moves to a different container? (This is one of Rich’s arguments.)
- If you’re labelling the data, how does it stay labelled as it flows through different formats and containers? (Imagine trying to tag ones and zeros, as “Ben” points out in the comments of Rich’s posting.)
In my experience, people don’t want to spend more than a bare minimum of brain cycles classifying data. They don’t WANT to have meta-thoughts about the data they’re working with: how it’s classified, how long it’s retained, or whether it’s going to be transferable in its current form to where it needs to go. They just want to work with the data and go home. In the IT field, we really enjoy classifying and modelling and thinking meta-thoughts way too much; our customers don’t. We should stop inflicting our anal retentiveness on them in the name of security.
And yet, at the same time, the business users can understand which kinds of data are confidential. Not because it’s labelled that way, but because in the context of their business process, they know which kinds of data in the wrong hands can lead to fraud, theft of trade secrets, or political or personal embarrassment. If you use the Boss Test—ask them, “Would your boss be angry if you posted this on the Internet / left it in a taxi / sent it to the wrong person?”—they can answer that. They do know—because they understand the business.
So in order to bolster data security, we need to do two things:
1. We need to make sure that each user understands the business classification of the data they work with. Which pieces of information are the company’s intellectual property; which information is absolutely not to be released until a certain date; what constitutes PII when you have enough of the elements in one place.
2. We need to teach them which technical measures they need to take when they understand that their data needs protecting. What to do with it, what not to do with it. And I don’t mean telling them not to post it on the Internet; they get that. We need to teach them not to put it on a web server that is Internet-accessible, even if they haven’t created a link to it, because they need to learn that a link isn’t the only way to get to data on a server. We need to teach them that sending email over the Internet is like sending a postcard that everyone along the way can read. We need to make sure they know the different ways you can shoot yourself in the foot by configuring and using software the wrong way.
Only in this way can we put the responsibility for data protection back on the business, which is where it should have been all along, and stop banging our heads against DLP appliances. If DLP solutions are only good for “stopping stupid,” well, there are different ways to cure stupid. We should help the business protect itself against mistakes wherever possible, but the brunt of our security efforts should be in removing the ignorance of the user, not in relying on technology to try to replace the user’s thought processes.
And I know this is going to sound totally heretical, but we shouldn’t try harder than the CEO. If s/he isn’t that concerned about data loss, there is no helping that organization until and unless something actually happens. Shrieking about risk isn’t going to help, and will only annoy the people around you. Because data protection belongs to the business, and because the CEO makes a risk decision every time the budget is signed off, we should be urging the CEO to make the organization’s business policies known.
Remember: the CEO probably understands the total business risk better than you do.
Posted by
shrdlu on Monday, July 13, 2009
(0)
Comments •
Permalink •
Yeah, I know, it’s been a long time. I spent several months doing the Security Conference circuit, eating for free at vendor-sponsored tables and peddling the same tired old PowerPoint over and over again, just shuffling the slides at random and renaming them after Top 40 songs. But now I’m back in the saddle and returning the company to its previously gridlocked state.
Why, just the other day I was breaking in a new security intern. He was all wide-eyed and earnest, with a copy of Shon Harris under his arm that looked like he had seriously made a laminated book cover for it. He wanted to start off by aligning our corporate security policies with FISMA or some shit like that, but I told him to go pull some cable and I’d have a special mission for him later.
He had a cute pout. “Can’t we at least do some risk analysis first?”
“Listen,” I said in an avuncular fashion, “we don’t do risk analysis here. Risk analysis is for math weenies who are bored with getting off on economics statistics and they want a little strange, so they try to import the formulas into IT.”
“But ... but ... how do we prioritize? How do we justify our budgets?”
“I’m glad you asked,” I replied. I pulled a book covered in coffee and salsa stains out from the bottom of a stack on my desk and tossed it at him.
“Sun Tzu’s Art of War?” he asked, confused. “Do we use this to defeat hackers?”
“Oh, no,” I said, “we use it to defeat our management. Boy, there’s a war on, and nobody’s gonna tell you this, but you gotta keep the enemy on the defensive every minute of the day if you want to get your security work done.”
The look on his face was both priceless and timeless. If you took a sad puppy and bent his head at a 45-degree angle to the left, that would be him. I’d seen that look on every member of my team at one time or another.
“It’s simple,” I said. “Humans are crap at risk analysis, and they have dozens of biases that you can exploit to your advantage. For example, everyone who hears a personal anecdote about something bad happening thinks that risk is higher than a risk they’ve only read about. So I make it a point to go at least twice a month to every management and project meeting and tell a story about someone I know who was hacked because he didn’t have—let me see ...” I consulted my shopping list. “He didn’t have a GRC threat management appliance with HIPAA-certified anomaly detection.”
The poor intern was looking less like a puppy and more like a little boy whose puppy had been shaved, drowned, and buried in a field of Gartner analysts.
“And management wants nothing more than to be told that they’re following ‘best practice.’ So I give them plenty of magazine articles that talk about what other companies are doing. If that doesn’t work, the auditors will issue some findings to motivate them in the right direction.”
“How do you know what the auditors will find?”
I grinned and leaned back in my chair. “Junior auditors aren’t as well paid as you might think. A few tokens of esteem and a few words of guidance are all that’s needed.”
He sat down and put his head in his hands.
“It’s all right,” I consoled him, patting him on the shoulder of his starched button-down shirt. “Here, I’ve got something that will make you feel better. You can make a real difference, right here, right now.”
I handed him a tool and some instructions, and sent him with my badge off to the data center. He was looking nervous but a little grin was forming on his lips.
After about forty-five minutes of reading xkcd, I picked up the phone and dialed a well-worn pattern on the keypad.
“Technical support center, may I help ... oh, god,” the voice on the other side said as it recognized my caller ID.
“Hey,” I said. “You know those five database servers that have been flooding their consoles with error messages? You know, the ones that you guys ignore because the SLA doesn’t assess performance penalties for slow throughput? The ones that we’ve been bugging you to upgrade the hardware on?”
“... Yes ...?”
“Check your tickets. I think you’ll find that they’ve all failed now and the status has been upgraded to P1. Remember, that’s a four-hour turnaround time according to the SLA. Have fun.”
I hung up the phone just as the Security Intern came back in, smelling faintly of ozone and with a huge beaming smile on his face.
“I think I’m really going to like it here,” he said, handing me back what he was carrying.
“Just wait until you get to try it on users,” I said, pocketing the Taser. “Let’s go to lunch.”
NOTE: I owe, as always, a debt of gratitude to Simon Travaglia for the inspiration.
Posted by
shrdlu on Tuesday, June 30, 2009
(5)
Comments •
Permalink •
