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 •
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 •
Sometimes I get pushback from my users when I’m doing a risk assessment and want to examine the risk associated with a particular partner. They frown and say, “They’re secure,” as if it were offensive that I should even ask. Of course, an executive that says this has never performed an audit of this party’s networks, or asked to see the results of a pentest, or indeed made any effort to collect information to bolster this assessment. He’s running purely on trust.
Lots of folks have explored the reasons why we choose to trust something in general; it’s part of our subconscious risk assessment engine. So I won’t go too deeply into it, except as it affects me and my own responsibilities.
We tend to trust something that we have known for a long time. An employee that has worked for us for 20 years; a vendor that has worked for us before; a barista we see every morning. Because of our history of experiences with them in which nothing bad has happened, we rely on that prior knowledge to estimate a lower risk.
We also trust something that is well-known. Big Three-Letter Vendor tends to get higher automatic trust than Bob’s PCI Shoppe.
We trust something that we see everyone else trusting. Fortune 100 companies can’t be wrong, right?
We trust something with which we feel an affiliation. If those folks over there are Just Like Us, they must be okay.
And finally, we trust something when we feel the anticipated benefits will outweigh the risk (that we haven’t examined all too closely, and won’t, because if we found something bad it would conflict with our need to get these great benefits).
All of these factors come into play when you’re trying to make a case for auditing a third party, or monitoring a user, or restricting access. And it’s very hard to come out and confront this, because if you have a CEO who has friends over at this vendor shop, he’s not going to be too introspective about it. People will look at you strangely when you ask for security testing of a product that people have been happily using for five years. Especially if you’re the only one who has ever thought about security, you’re going to be battling a lot of human nature in the name of objectivity and verification.
Quoting Ronald Reagan helps sometimes. That’s about all I can give you.
Posted by
shrdlu on Monday, April 06, 2009
(5)
Comments •
Permalink •
Well, despite my earlier misgivings about the utility of security certifications, I decided that the price was right, so I went and got my very first cert:
Won’t my momma be so proud of me?
Those are three letters I’ll be proud to list after my name in every signature line, blog posting, business card and CV.
Posted by
shrdlu on Wednesday, April 01, 2009
(1)
Comments •
Permalink •
Okay, so now that the “in order to feel cool I have to make fun of something”* crowd has finished piling on about Twitter, let me just step forward and say that I really like it.
Those who think it’s all about ego have completely missed the boat. Srsly, ppl, if it were expected to be profound it would be called Thunder, not Twitter. It is not a “micro-blog” since it does not fulfill any of the other functions of a blog, even in 140 characters or under. (I can hardly wait for Nanoblogging, in which updates consist of one word—followed closely by Picoblogging, with one-letter posts.)
It’s a chat client for people who actually have a life—who step away from the keyboard on a regular basis and just like to catch up and comment when they can. It’s an open-ended conversation in both senses of the word, in which you jump in and out of the neverending stream of chatter; and half the fun is hearing only one side of an exchange and figuring out that the other person must be pretty entertaining, too. It’s punctuated announcements, brief banter, and a way to pass on links without having to write a whole article around them. Short, people. Think short and pithy, like me.
I enjoy the public timeline too: it’s like sitting at a table in a sidewalk café and hearing one sentence as a conversing couple walks by. It’s out of context, and all you see is the person’s avatar and what passes for a full name. You make up a story in your mind to fill in the blanks. This people-watching is enhanced to great effect by Twittervision in 3D.
Twitter is the final vindication for all the people who used to be annoying on Usenet by posting one-sentence responses to something. It’s the CB radio of the information superhighway. Can it be used for serious purposes? Maybe, but I tend to think that the more seriously you try to take it, the sillier you end up looking, especially if you’re trying to keep follower scores.
It’s just fun, people. Remember “fun”?
*These were the same people who claimed for decades to hate disco. Come on, folks, I know I wasn’t the only one out on the dance floor back then. Get over yourselves, or I’ll have to dig up that picture of you with the tiny coke spoon on your hairless chest and the sock in your pants.
Posted by
shrdlu on Sunday, March 29, 2009
(3)
Comments •
Permalink •
