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 •
I’ve been wondering this for several years now, and maybe you can help me: what kind of “professional development” should a CISO have, both to stay current and to prepare for the next position?
In my own experience, you’re supposed to be a mile wide AND a mile deep in order to do your job effectively. The problem is that I have the schedule of an executive with the issues of a hands-on techie. I really envy the people that have a job that allows them to focus on one facet of security; I can’t really become an expert in anything any more, except for maybe CISO-ing.
I have to be able to take part in a design review, discuss data models, argue about virtualized switches, interpret legislation, explain the latest security exploits, manage personnel issues, negotiate contracts, and examine registry keys. I have to be able to talk about everything from LDAP schemas to data masking. This isn’t even including the business-specific issues and processes that I need to be aware of.
So what kinds of classes should I be taking? I can take generic management training (“20 ways to terminate your psycho employee without endangering yourself, others or the company’s liability”), and I can go to conferences and listen to what everyone else is doing (“we’ve discovered AWARENESS TRAINING!”), whether it helps me or not. I can read blogs until I’m crosseyed, but that doesn’t get me CPEs. As far as I know, they don’t offer courses like “Ruby on Rails for the Executive Who Used to be Hands-On Back When It Was FORTRAN on Rails.” I don’t have time to take the regular week-long courses in everything I should know at least something about; I don’t even have time to go to one-day classes.
And I’m sorry, but there are only so many times I can sit in on a vendor’s breakfast seminar on some hot new topic before I start hurling croissants (in both senses of the word). As I’ve said before, executive briefings on security are NOT the same thing as briefings for security executives. There’s only one group I know of that does the latter well.
As much as I love the people who go to Black Hat, I do not want or need to sit through 8 hours a day of people describing in great detail exactly how someone could theoretically 0wn my network. And learning how security products work is not the same as professional development.
It seems to me that there are only a few ways that CISOs can grow. One of them is to move to managing the security of a BIGGER operation. Another way is to become a consultant to other CISOs. There are a few who migrate to the CIO role, but I don’t know of anyone who’s actually done that. Assuming that I’m not going to have the chance to do any of these, how am I supposed to “develop” myself further?
Looking forward to your comments ...
Posted by
shrdlu on Friday, June 19, 2009
(6)
Comments •
Permalink •
Does your organization have a cloud policy yet?
By that, I mean: does your organization have a policy about who’s allowed to use third-party hosted services, and under what circumstances?
One of the banes of a CISO’s existence is the rogue IT group that a department has built up on its own. They make their own procurement, architecture and implementation decisions—they just go out and do whatever they think is best for them. You’ll find infrastructure you didn’t even know had been installed; you’ll find software, of course, that magically appeared; and you’ll sometimes even find that their administrators had taken over control of the infra you thought you were running.
Back in the day, to do that you actually had to hire IT people. But now, thanks to services, anyone with a checkbook can buy them.
What’s your answer when a department head asks you why they can’t ditch the lousy Exchange server and just use Gmail? It’s free, everyone knows how to use it, and it’s a lot more reliable with no support costs. How about Survey Monkey? How about a hosted service of any kind where you upload data to them for some kind of processing?
I’ll give you a hint: you can’t just say “It’s not secure.” Nobody will believe that. Remember, if they see everyone else taking the risk, they’ll think it’s an acceptable one. Luckily, there are other business issues to contend with besides security, and if you can get the right people at the table, they will answer them FOR you.
Which services require contracts (and presumably money), and which don’t? Do you care whether departments use free services?
Where contracting is needed, can the departments all set up their own, or should there be a coordinated or centralized contracting process?
Are there availability issues that need to be highlighted? (Yes, even Google has been known to FAIL.)
Will the service involve data that might be needed for litigation? If so, how do you get it back? (This might be a terrible disadvantage to your legal staff—“We’re sorry, we can’t provide IM logs, go talk to AOL”—or it might be a great advantage—“We’re sorry, we can’t provide IM logs, go talk to AOL.”)
Are the service-level agreements with the provider aligned with your own service-level agreements to your customers? If not, how do you pass along liability?
If the service provider goes under, or the department decides to terminate the contract, do they have a place to come back to in your infrastructure?
Once your executives hash through these questions and are sufficiently open to listening, you can start bringing up questions like this:
How are we going to look in the papers if this provider has a breach with our data?
Remember, most of the time the name of the OWNER of the data goes above the fold, and the name of the contractor goes below the fold (if it’s mentioned at all).
At this point, if you’re lucky, the CEO will frown and ask you to start looking into the reliability and security of the proposed service provider, and then you can do what you had been planning to do in the first place: a real risk analysis. Hopefully you will have written down the answers to the earlier business questions, and you can start referring to that list as a Policy. Tack your security risk decisions at the bottom, et voilà!
Posted by
shrdlu on Thursday, June 18, 2009
(0)
Comments •
Permalink •
Imagine the chatter:
@soc1 @soc2 k send me the pcap
@soc2 @soc1 00 04 23 c1 de 2f 00 04 23 bf a1 2f 08 00 45 00 ..#../..#../..E.
00 3c 95 32 40 00 40 06 c6 5b bf d7 0a 90 bf d7 ..2@.@..[......
@soc2 fuck
@Beaker CLOUD RULEZ OK
@schneier @Beaker No, it doesn’t.
@Beaker @schneier Shut up
@schneier @Beaker No you shut up
@schneier MOOOOMMMMM
@Beaker MOOOOMMMMM
@lmacvittie SHUT UP BOTH OF YOUSE
@lmacvittie As I was saying -
@lmacvittie The trth is tht whn u strt spnng up mult inst of any client 4 the prpses of tstg an app u cn indvrtntly doom ur test 2 fail due 2 undrlyng a
@lmacvittie Damn it.
@alexhutton Now obviously the probabilistic statements would eventually require more effort once some substantial level of organizational maturity has b
@alexhutton Screw it, let’s go with risk = assets x threat x vulnerability.
@ISO @user I see you downloading that pr0n. Take your hands off the keyboard and put them behind your back.
@ranum Security is broken and it’ll never be fixed. Any conferences left where I haven’t tweeted this yet?
@hacker1 Dude, I totally broke Adobe. Want the sploit?
@hacker2 Dude, I totally broke SHA1. Want the sploit?
@hacker3 Dude, I totally broke DNS. Want the sploit?
@hacker4 Dude, I totally broke the Pentagon. Want the sploit?
@securityresearcher Dude, I totally broke WPA2. Want the sploit?
@vendor1 We will describe a sustainable approach where access controls are not just viewed as an IT artifact but as way to deliver sustainable value i
@vendor2 A policy mgt approach cn intgrte key access ctrl, id mgmt and governance capabilities into the fabric of risk mgmt processes and solutions.
@ISO @spam @vendor1 @vendor2
@auditor compliance compliance compliance compliance compliance compliance compliance compliance compliance compliance compliance compliance complian
@rybolov I KAN HAZ FISMA?
@auditor @rybolov No FISMA, ISO 17799. We sweetch.
@phisher Hi Im Twitter admin please give me yr password here: _______________________ kthx
@securityczar OMGWTF Dude, they totally broke our Pentagon.
Posted by
shrdlu on Sunday, June 14, 2009
(6)
Comments •
Permalink •
I’ve been a little worried about losing my geek cred, so I figured I’d rant a little bit about the new Star Trek movie.
Okay, first of all, I can see why some deep thinkers hate it. It has logic holes you could drive the Enterprise through (oh wait, they did).
Spock marooning Kirk on a frozen planet? Really? When you’re in command and in charge of the well-being of your crew, you do not abandon them in a life-threatening situation, even ravine-climbing distance away from a station. Spock should have been brought up on charges for that one. If he needed Kirk out of the way, he could have just thrown him in the brig, and/or told McCoy to keep him sedated until the crisis was over. Sending him down to the planet was an idiotic convenience for the next big plot hole ...
Meeting Spock Prime in some random cave on exactly the right planet at the right time? How stupid is that? And it really annoys me that ever since they cracked the Great Wall of Spock a couple of times in the old series, he’s all, “Jim, my old friend” at the drop of a hat. Remember when it took intoxication and physical and emotional trauma to get him to choke out that name JUST ONCE?
Moving on with the stupidity: Spock just figuring out time travel in an instant, when the shuttle addresses him with, “Welcome back, Ambassador Spock.” Remember, the rest of the Old Series hasn’t happened yet, and discovering accidental time travel back then was a big deal. They should ALL have freaked out bigtime. It’s as if the Federation had time travelers popping in all the time. No time for that, though, because they had to hurry and defeat Nero, who was carrying that “red matter.”
And will someone explain to me why they had to do all that drilling to put the “red matter” in the core of the planet? If it created a black hole, all they had to do was fling it onto the planet for it to gather critical mass and do its work. Yes, yes, I know, then we wouldn’t have had the cool drilling sequences and the headfirst dive onto the platform and Sulu’s swordfight. But it’s still stupid.
Same thing with Scotty and the transwarp beaming. They explain to him that he WILL invent it, and he’s totally complacent about it. This should have rocked everybody’s socks, and it didn’t. They had to rush on to the next CGI effects.
But I’m saving my wrath (because I khan) for the final indignity: Uhura. They made this token effort to have the one female character, who was always just decoration on the original set, have some bitchen skillz in this movie. They tried to depict her as just a little more bad-ass and capable. And then they went and ruined it by having her go gaga for Spock. Originally it was Nurse Chapel, and now it’s just a slut of a different color. Is a deck officer and a professional going to go lock lips with the commander in the turbolift just because something bad has happened? I think not. This was EXACTLY the sort of shit they used to pull with women in the old series, and I would have hoped that FORTY YEARS LATER they would have grown out of it. No such luck.
NOW. If you turn your brain off, it’s a fun movie. They were a little heavy-handed with some of the references. When the kid Kirk announces his full name to the police, he should have pronounced “Tiberius” like “Go ahead and make fun of it, I DARE YA.” Nobody could have missed the origin of “Bones” unless they were in the restroom at the time. But all in all, the actors pulled off what was certainly a difficult task. Scotty was delightful. Chekov’s accent in this one was even thicker than in the original series, and that’s saying a lot.
I might watch it again. I saw it in IMAX in the front row, and I was close enough to see phaser shots go up my nose. Maybe a home theater experience would lessen the shock of seeing Spock’s five-o’clock shadow under his perfectly shaved chin. I would definitely place it on the even-numbered side of the canon, but not necessarily at the top.
Posted by
shrdlu on Saturday, May 23, 2009
(1)
Comments •
Permalink •
Another fun topic to consider when you’re defining cloud governance is the use, support and administration of encryption.
The way I see it, there are two main types of encryption use: let’s call them container encryption and content encryption.
Container encryption is wrapping some data in encryption, usually to move it from place to place, but also if you’re just protecting it as one big blob. Examples are SSL (building a tube just to get data safely from A to B—or, as Spaf puts it, getting it safely from the cardboard box to the park bench), whole disk encryption, flash drive encryption, and media encryption.
Content encryption is used to protect particular data, no matter which form it’s in or where it’s headed. This includes file-level encryption, email message encryption, and anything else where you are protecting it for dedicated use by an intended recipient.
When do you use one versus the other? It depends upon which threats you’re worried about. More to the point, it depends upon whether you trust your provider. If all you use is SSL, you’re clearly not concerned about your web administrator or your system administrator; you just want to make sure your session can’t be hijacked by outsiders. If you’re worried about internal threats as well as external ones, you’ll prefer a separation of duties enforced by having someone else manage the encryption keys on data that cannot be accessed in any other way, at any time, without decrypting it.
Let’s say that you have confidential data that you want to protect “at rest.” (I use the quotes because in my opinion, data isn’t truly at rest unless it’s on a host that is turned off. The rest of the time, even if it’s not actually on stage, it’s in the green room.) In one scenario, you let your cloud provider decide which encryption product to use (as long as the algorithm is approved), you let him install it, and you let him manage the keys on behalf of you and your users (and his other cloud customers). In the other scenario, you do it yourself, and just let the provider run the rest of the layers.
Do you have a provision model where the vendor only administers the operating system and shouldn’t have any need to access the data you’re protecting? If you’re encrypting the entire hard drive on a laptop, you’re going to need to let your PC support person access it in order to diagnose problems, perform upgrades, and—oh yes—issue you a rescue token when you forget your passphrase.
This model makes a difference when you’re talking about encrypting backups. Do you take already encrypted data (to which the administrator has no access) and write it as-is using a regular backup utility? Or do you only encrypt it on its way off to tape, because the only threat you’re worried about is the Iron Mountain guy who leaves the tapes stacked outside the cafeteria entrance while he gets himself coffee on the way to the offsite storage?
Your provider will probably understand your need for SSL over the Internet. He may or may not understand your demand for SSL within the cloud. He’ll assure you that he’s got plenty of measures in place to separate your data from the data of his other customers. But unless he’s very security-savvy, you’re going to have a fight on your hands when you talk about installing and administering your own encryption, because he can’t conceive of you seeing HIM as a potential threat.
UPDATE: Completely missed that Rich Mogull is, as usual, a step ahead of me. And he brings up the idea of data monogamy, which I like.
Posted by
shrdlu on Wednesday, May 20, 2009
(0)
Comments •
Permalink •
So Dell has been getting a lot of well-deserved flack about its attempt to market to women with its mini Netbook. They’ve claimed to have made some changes, but their page still reads as though you could roll up the Netbook and use it as a deodorant tampon.
If I were to rewrite it, it would look more like this:
1. Get organized: Sites like lifehacker.com give you tips on everything from organizing your home server room to planning your next OS upgrade. Terrorize the guys in the co-op next door by cracking their lame-ass WEP keys. Organize your VMs and your malware samples.
2. Get smarter: It’s easy to turn your netbook into a completely portable pirate stash. You can download all your torrents and take it offline when the FBI comes calling.
3. Get moving: Take your death metal everywhere you go, especially game nights on the office LAN. Some netbooks even offer an optional DVD drive if you’re not already streaming pr0n online. And if your netbook has an HDMI port, you can expand your screen by connecting your netbook to an external monitor or TV. Several minis have HD screens available as an upgrade! (But we wouldn’t recommend it for viewing pr0n; nobody wants to see Ron Jeremy in HD. Ew.)
4. Get more: Add storage to your netbook with memory cards or memory keys. Pringles cans now supported!
5. Get up and travel: Your lightweight, packable netbook can transform your traveling experience, whether you’re teasing paranoid commuters on the train or hitting every security conference in the country. Use your netbook to vlog and blog about your Casa Fuente visits; collect extortion photos; store your rainbow tables; and even collect bread recipes.
Really, if they thought they needed to do something special to get women to buy more of their netbooks, all they had to do was show women doing the same things with them that men do. If they really felt the need, they could offer the hardware in pink. But pretending that women only use computers to travel, diet, update their Facebook page, and store their yoga poses is nothing short of incredible in this day and age.
Posted by
shrdlu on Monday, May 18, 2009
(1)
Comments •
Permalink •
Perhaps the hardest part about security risk analysis is reconciling the widely divergent perceptions within your organization. On the one side, you have the security professional who reads up on the latest threats; on the other side, you have Joe the User who may not even be aware that the security group exists. Somewhere in the middle, you have a random IT staff member who knows his own area but never thinks about the security aspects of it because “we have a group for that.”
Frankly, security professionals can often have an extreme view of risk. When you are reading about exploits and attacks every single day, you tend to rate the probability higher than it warrants. In the same way that a guy with a hammer sees everything as a nail, a responder (be it security, law enforcement, or emergency personnel) sees a biased cross-section of life because he sees only the events in a concentrated form, not the population that makes up the statistical average. There are some sad examples of what can happen when you overestimate risk because that risk is all you work with and think about every day. I get risk fatigue on a regular basis from the streams of vulnerability announcements coming into my mailbox, and most of the conference tracks I see these days are along the lines of, “Oh noes! Another esoteric exploit is discovered! We’re all gonna die!” If you didn’t know anything about risk analysis, and simply read the titles of blog posts, books, magazine articles and conference talks, you’d swear that every system was under attack every second of every day.
[No. No. NO. No, they’re not. I don’t care what your IDS says. A probe that has no chance of succeeding is not an attack; it’s a contact event. Is the rain attacking you as you walk beneath your umbrella? Yes, water can drown you if applied correctly, but it doesn’t mean every drop is trying to kill you.]
Folks, if you so much as talk about these things too frequently to the same people, they’re going to come away with the impression that you think the risk is extremely high, even if you don’t. It’s completely at odds with their own experiences, so they’re not going to take you seriously even long enough to split the difference.
Now, it’s not entirely our fault: on the other side you have the users who never think about security at all. If they’re already intimidated by technology, they’re not going to want to try to understand it long enough to get a realistic understanding of security risk and how their actions affect it.
Perhaps the worst group of all is the one in the middle: the programmer who personally couldn’t figure out how to code a SQL injection attack, so he doesn’t believe they’re a threat. The help desk dude who doesn’t understand HTML, so he rejects any notion that even displaying a page could set something off. The PC technician who doesn’t understand malware, so he can’t conceive of it as anything other than a harmless set of error messages that need to be made to disappear by re-imaging the desktop. In other words, it’s the dangerous bias of someone with incomplete knowledge.
Put these all together, and you have a massive disconnect between the population that doesn’t think anything is possible—and the population that knows what’s possible and believes it all to be inevitable. If we’re to have any hope of achieving a realistic estimation of risk and having it accepted on all sides, we have to use a model that separates raw, irrational perceptions from knowledge-based data points. Our users lack knowledge, and we have to give it to them in the right way, not by abusing the data to take advantage of our psychological tendencies to misinterpret risk.
We have to stop defining risk by saying, “It happens all the time.” If you are chasing down tornadoes, of course they “happen all the time”—to YOU. That doesn’t mean they happen all the time to everyone, and we shouldn’t mislead people into thinking they do.
We have to stop “managing risk by headlines”—yes, I mean YOU, the ISO who emails scary Heartland stories around to all the management to try to convince them that a breach is imminent.
We have to build an understanding of the difference between attacks of opportunity and targeted attacks, and understand our particular exposure within the whole population.
In other words—and I mean this in the nicest possible way—we all need to get a grip.
Posted by
shrdlu on Saturday, May 16, 2009
(4)
Comments •
Permalink •
Wash your data when it comes in from the Internet. Do you want to get viruses?
Don’t leave the firewall open!
Don’t share your shared secret with anyone else. (?)
I don’t care whether your friends are doing it. On MY network, you’re not doing it, and that’s final.
Just wait until the CEO gets home!
You tracked that worm into the house. YOU clean it up. I’m tired of cleaning up after all of you.
I don’t care who started it; I’m finishing it. Both of you, go to your offices!
No games until you clean up your hard drive!
When YOU pay for the computer, THEN you can keep it private. Until then, I’m coming in whenever I want.
How many times do I have to tell you not to open strange attachments?? Am I talking to a wall??
Because I’m the ISO, that’s why!
and finally:
Just wait until you have users of your own, then you’ll understand.
[RECYCLED from Mother’s Day 2007]
Posted by
shrdlu on Sunday, May 10, 2009
(0)
Comments •
Permalink •
Pretty soon the New School Guys are going to say everything I wanted to say, only better, and I can hang up my cleats and get out of the game.
Alex Hutton, who appears to be catching up to David Mortman in the number of blogs he appears on, had this post over at the Verizon blog on clouds and the evolving role of the CISO. The magic phrase is this:
[T]he Cloud transition is about how to gracefully lose control over computing assets.
Ten years ago, IT outsourcing meant that you hired the bodies from somebody else, but they still did what you wanted them to do. Someone else paid them and managed their benefits, and if they had a management structure, it was embedded within yours. That didn’t achieve economies of scale as much as everyone hoped, so these days, instead of buying (or renting) the bodies, you’re buying the service—which means they get to do it THEIR way, presumably to save money. Hence, the hounds^H^H^H^H^H^HCloud.
It should be intuitively obvious, but everyone keeps hitting their faces against the same lamppost over and over again: “economies of scale” means “cookie-cutter.” It means one size fits all, and you’re stuck with the resultant blisters or chopped-off toes to make your organization fit within the shoe. In theory, everyone is in favor of standards, but there are an incredible number of different ways even to implement the same standard, much less choose among several standards to implement. IT is not “cookie-cutter” by any stretch of the imagination, even at the lower ISO layers.
So with the “cloud,” you’re expected to buy someone else’s implementation of infrastructure/platform/software/whatever, and you’re not SUPPOSED to change it. If you’re not supposed to change it, why would you need to know exactly how it’s being done? This is the conundrum for today’s CISO.
As Alex says, you start giving up visibility, which means you need to trust that cloud provider. Not only do we lose the important data necessary to form risk decisions, but we also lose the ability to implement and respond to risk. Take a very small example: say that you have an uptime SLA with your provider that says that if something is down, they have to have it back up and running within four hours. Sounds good in the contract, but in the actual execution, this means that if your server is shooting out warning errors, you would probably start making plans to replace the failing hardware (or whatever it is) proactively. Economy-of-scale providers don’t do proactive; it’s not economical. So THEIR operational rule will be, “We’ll replace it when it fails, and not before.” And you will spend a lot of time watching tickets go by that state as the resolution, “We rebooted it and the errors went away.” A slowdown in performance is not the same as an outright failure, so you will have no recourse but to sit and watch your business limp along. (I’m actually surprised that we don’t see more arson in hosted data centers, where someone in desperation sets fire to a server to get it to FAIL ALREADY.)
So there are two main areas of expanded risk that need to be calculated: our knowledge into the state of the system, and our ability to control the controls. I’m only a FAIR padawan, so I haven’t been inducted into the mysteries of calculating this far down, but I’ll bet someone around here can shed light on it.
As we get dragged kicking and screaming by our business areas into the Cloud, it will be very interesting to see whether the CISO’s accountability is correspondingly reduced, and whether more real liability is transferred to the cloud provider. I’m not talking performance penalties here; I’m talking REAL liability, in which the provider shoulders the total loss incurred by an incident on their watch. When are we going to start seeing cloud providers sued by their customers?
I’m getting the popcorn and the lawn chair ready.
Posted by
shrdlu on Thursday, May 07, 2009
(5)
Comments •
Permalink •
I just decided that on one particular site that I use maybe twice a year, it’s easier to use the “forgot password” function and have the password reset every time I want to log in, rather than come up with a memorable password. Why? Because the challenge question, unlike the password, never has to be changed!
So I just put any old thing into the new password field, and forget about it until next time.
I’m sure this isn’t what the designers intended.
Posted by
shrdlu on Monday, May 04, 2009
(1)
Comments •
Permalink •
I’m in a quandary.
My oldest has been using computers and the Internet for a long time now, and wants to register on non-kid sites these days, which for the most part I won’t allow. As a parent, I’ve never believed in just saying “No”; I’ve tried to make it “this is how to do it safely” or “here’s what you have to accomplish to earn it.” You do this with all sorts of things—after all, your job as a parent is to teach your kids to survive and thrive in the real world, not to keep them locked away from it forever. Step by step, you show them how to cross a street, stay on the sidewalk, wait for a traffic light, and walk further and further distances until they can walk to school by themselves.
So how do you develop a child’s Internet survival skills?
The child needs a healthy dose of skepticism (“Dad, this YouTube video says that if I don’t forward it to five friends immediately, I’m gonna die.”). He needs to understand that there are a lot of people out there who post weird, patently false, misleading, manipulative, and mean things.
The child needs a thick skin to be able to withstand the usual stupid attacks that anyone can be subject to at any time. She needs to understand how to have a civil discussion, how to argue well, how to support her arguments with reliable sources, and how to quit the battlefield at the right time. How to be sure you’re having a private chat with someone, and how to spot an imposter. How to size up strangers you meet on the Internet to figure out whether they’re really who they say they are.
As with anyone else, children need to be able to tell when a site is unreliable or suspicious; which scripts to allow and which to block; which ads might be okay to click on and which ones definitely aren’t. And they have to have a certain level of maturity to be able to deal with shocking, obscene, or hateful things they might see, because you will never be able to protect them from those, not even with the best nanny software.
Finally, a child has to be able to understand the concept of privacy, and how that privacy might be violated and how it could hurt him later on. I’m not talking just about identity theft, predation or bullying; I’m also talking about understanding how information can be aggregated and retained over decades.
So there are a lot of sites that purport to teach children about Internet safety, but it seems mostly to be along the lines of “watch out for this!” and “don’t do that!” That’s like teaching a child, “Watch out for cars! And drunk drivers! And suspicious men in windowless vans! And vicious dogs! And obnoxious bikers!” They have to venture out sometime, and have to learn the positive steps to take to protect themselves, because these days, using the Internet is as ubiquitous as walking down the street.
What would you propose as a sensible course of study for Internet use, and for which age levels? How do you achieve the objectives listed above, without turning into a fearmonger? And at which point do you judge your child ready to venture out to different areas?
Posted by
shrdlu on Sunday, May 03, 2009
(3)
Comments •
Permalink •
I just want to give a shout-out to my biggest referrer EVAR—those awesome Perl hackers at http://pentester.jogger.pl.
... Wait, what? That’s not Perl? They’re Polish? ...
EVEN MORE AWESOME.
Posted by
shrdlu on Sunday, April 26, 2009
(2)
Comments •
Permalink •
So Verizon Business released one of the hottest breach reports in the industry—and by hot, I don’t mean just that it’s in that cool black and red and has bubble charts galore. No, I mean that their executives can travel to conferences on it for the whole YEAR and if they play their cards right, nobody will get tired of hearing about it. I’m looking forward to seeing what the pundits say about the conclusions.
There are some awesome data points here, ones that puncture the conventional wisdom:
- A big majority of the breaches resulted from outsider attacks.
- You can prevent most of these breaches by doing really simple and cheap things, like CHANGING DEFAULT PASSWORDS (more on that later).
- 81% of the victims were not PCI compliant (ouch!).
- Nearly half their caseload comprised interrelated incidents (different parts of the same organization, committed by the same individual, etc.).
Now, let’s look at the visualization, which is really half the appeal of the report. There was a gratuitous use of bubble charts; most of these could easily have been depicted by bar charts, but I guess they wanted some variety in their geometric shapes (this led to my frequent impression that the data breaches were all coming from Jupiter). The only really stellar (heh) use of the bubble chart was figure 31, showing the different time spans for breaches, in which you could get an overall feel for the proportions of a complex data set at a glance. That one and the line chart showing threat categories were worth spending a lot of color on.
They mostly did a good job slicing and dicing the numbers, but they went a bridge too far when they trotted out their “pseudo risk calculation.” First of all, I’ve never liked the variations on “frequency x impact = risk” because I always ended up with a number in the “risk” category that sat in my hand like a Japanese vending machine snack: I had no idea what it was, didn’t want to consume it, and certainly didn’t want to foist it off on anyone else because I couldn’t vouch for it. In this case, the mystery gelatinous mass is still the “risk” column in their chart, which is simply a blending of their historical data—NOT likelihood—and the number of records breached, which gives you 28,000 Somethings. Now, I’m always suspicious when two columns of a chart have units specified and the grand finale column doesn’t. Is that supposed to be the average number of records someone can expect to lose next year with a probability of 1.00? They don’t SAY it’s the number of records, but that’s the most likely candidate, given the scale. Is this supposed to be a substitute for annualized loss measured in dollars?
Guys, if you have to call it “pseudo,” you’re already backing away from it yourselves. If you can’t vouch for it and tell me exactly what’s in it, I ain’t eating it.
On the upside, I was glad to see some other things confirmed, such as my belief that database encryption really doesn’t buy you a whole lot in terms of protection, because the attack pathways are the same ones that belong to legitimate users. (Encryption at rest is for protecting data that is TRULY at rest, i.e., the server is turned off.) It is depressing, but utterly believable, to see that the vast majority of breaches are aided by “errors and omissions,” also known as system administration FAIL.
Looking at the commonalities, we see the very elementary errors and misconfigurations, the lack of PCI compliance, and the fact that most of the breaches were detected by a third party. If you roll this all together, you could plausibly assume that the victims were all generally lackadaisical about managing their systems. This could be attributed to a lack of skilled resources—and by that, I mean that either they didn’t have sufficiently knowledgeable resources, or they had skilled ones but way too few of them to get the work done. You might be able to infer that these folks didn’t want IT management cramping their style; that would also explain why very basic security measures weren’t properly implemented. And finally, we see that third parties and their interconnectedness play a significant role, in that mergers and acquisitions make an IT environment more complex than it already was, and trusted third parties really shouldn’t be trusted when their own security house isn’t in order either.
All in all, there were enough interesting data sets in here to keep it from being another standard industry FUD piece. I actually learned some things from it, so color this one a winner.
Posted by
shrdlu on Tuesday, April 14, 2009
(9)
Comments •
Permalink •
I have to thank the kind and dapper Kai Roer for nominating me for the RSA Social Security Awards. Of course, I have no chance of beating any of the other blogs in the Most Entertaining category, but I already feel like a winner (wiener?) because at least one or more of the judges will have to look at this scrivening, where they ordinarily would never know it existed. That alone is just so freakin cool.
(Insert Photoshop mashup of Sally Field, dressed in an Oscar Meyer costume, being consumed by a LOLcat)
Posted by
shrdlu on Friday, April 10, 2009
(0)
Comments •
Permalink •
