Been spending several days bemused. There are a few things I’ve never understood, but I think they’re starting to gel for me.
See if you can find the unifying theory behind these observations:
- I have never had the patience to sit in classes. I’ve always needed to be doing at least one other thing to keep my mind occupied (usually, it was doing the homework for tomorrow).
- I hate most presentations. Except ones that go at the speed of sound, like Hoff’s (does that man ever draw a breath?). This is why I vastly prefer the hallway track at cons.
- I’ve been sitting in at least five presentations in the last two weeks in which the presenter went on and on about how “millennials” are different from “us” (meaning boomer executives), and how they need to multitask and need interactive learning and need social networking and all that shit. I don’t understand how this is supposed to be new, because I’ve been multitasking and using these so-called “2.0 technologies” for more than 20 years (remember Usenet, folks? And IRC’s been around for 17 years). Does this mean that I’m secretly a millennial? I don’t think so.
- Had a fascinating chat with Myrcurial about ADD and how it might apply to me.
- Read about NADD and realized that was SO me.
So put these all together, and here is my theory—which is mine—and what it is, too:
There are no “millennials.” There are only young people who have a certain ADD-ish mindset who now have the advantage of technology that better meets their mental lifestyle. I’m one of those people myself (okay, not young), who had the advantage of getting into it early before it spread to the rest of the world.
And the thing is, I KNOW I’m not alone. I know this is not a case of a generational gap; there are plenty of 0Ld Sk00L hackers out there who are not fazed by this influx of technology and change in lifestyle either. Hello? Boomers INVENTED the Internet, you punks. If I had a dollar for every gray-haired iPhone user, I’d be rich enough to buy one of my own.
Pundits are confusing the delay in technology spread with a change in a whole generation, and that’s just not the case. Not every kid needs, wants or has a Wii to survive; they are not fundamentally psychologically different as humans. It’s ridiculous to cite statistics that show that they’re reading less and less WHEN THEY’RE RECEIVING THOUSANDS OF EMAIL AND TEXT MESSAGES. I’m getting really tired of listening to presentations by TECHNOLOGY INDUSTRY EXECUTIVES who talk about all this stuff as if it just started in the year 2000. They, of all people, ought to know better—unless they bought their way into their positions and don’t actually understand what they’re selling.
I don’t feel any different from millennials. I don’t think they’re anything but young and naturally literate in the world they grew up in. I don’t think they have a different view of privacy; they’re just making the same mistakes on the ‘net that I did 20 years ago, and in 20 years when they’re trying to land a board position they’ll be just as embarrassed as anyone else. I don’t think they speak a different language. They just have more learning and communicating choices than I did at that age, but you can bet that as soon as the choices came along, I adopted them too. And so did a lot of other boomers and Gen Xers.
Those of us who are naturally ADD-prone (can we call it something else? Natural, compulsive multitaskers?) are just better supported these days in our particular style. Let’s not turn this into an intergenerational crisis. Either you’re adaptable, or you’re not, and if you’re not, you shouldn’t be running a corporation anyway. Get with the program, and for chrissesake stop calling it 2.0.
(Oh—and one more thing. I’ve finally realized that “security briefings for executives” are not actually briefings for security executives. This explains why I want to throttle various security industry speakers.)
Posted by
shrdlu on Wednesday, August 13, 2008
(2)
Comments •
Permalink •
OMFG, why didn’t anyone warn me about Vegas?
Black Hat was the most bizarre combination of Copacabana, Comdex, LSD trip, and Bataan Death March. It combined the “best” of jet lag and Rolfing. It was like being inside a pinball machine with a few good friends to keep you company. Being an INTP, I can’t deal well with distractions anyway (the multiple tracks within my own head are bad enough), and Vegas is built to be nothing BUT distractions.
But here are the few highlights of my trip:
- Hoff’s talk (pretty much the only one I sat all the way through)
- Meeting up with a dear former colleague after ten years apart (let’s not wait that long again, m’kay?)
- Meeting Jack Jones, although we really should have been sitting in a Zenlike tea house, contemplating every word with reverence, rather than shouting over a dead crustacean the size of a Volkswagen with Elvis impersonators walking by
- Meeting so many of my other security pundit heroes (I should have known Rothman would be suave in person, myrcurial rocks the house before detonating his verbal IEDs under the foundation, Dave Lewis is my other other evil twin besides rybolov)
- Talking about my special c*mpliance woes with guys who Get It
- Getting into the Microsoft party, but more to the point, escaping again with my eyes and ears intact
- Jeremiah Grossman’s talk at the Fortify dinner
- Bending Shostack’s ear while he was sitting still long enough to eat
- Goddammit, why is everyone in Vegas so TALL???
- STEAK BITS!!
- and of course, my buddy through thick and thin, without whom I would have been lost, clue-depleted and chai-less.
Assuming I ever go back there, I will probably go only to Defcon and bring a large dose of Ritalin and a Segway.
Discovering all over again how old, decrepit and uncool I am ... priceless.
Posted by
shrdlu on Sunday, August 10, 2008
(1)
Comments •
Permalink •
It’s twue, I’m off to DefHat or whatever the hell passes for a week-long party in Vegas. Packing now:
- list of people to buy drinks for
- list of vendors to tease
- list of people to bring back souvenirs for
- list of things to carry on my personage in case the bag gets lost
- NOT BRINGING LAPTOP, ARE YOU CRAZY?
- anti-h4X0r spray
- dinner-with-expensive-vendor clothes
- non-black t-shirts
- CHARGER. Must remember BB charger.
- absinthe lollipops (hope they get here in time)
- decoy USB drives
- decoy Fed polo shirt
- fake mustache
- fake merkin
- jumbo-sized Tiger Balm
- garlic Altoids
- winter-issue handcuffs—wait, this is Vegas, make it the gel-chilled ones instead
- Chuck E. Cheese tokens
- Dostoyevsky comic books
- backup set of bongos
- Dora the Explorer underwear, just for good luck
There, I think I’m ready. See you RSN.
Posted by
shrdlu on Sunday, August 03, 2008
(2)
Comments •
Permalink •
Let me be somewhere in the middle of the long line of bloggers to welcome Chris Hayes to the Risk-o-Drome. I’m sure he’ll be an interesting part of the neverending conversation on risk.
He’s started off first of all with the age-old question, “What is Risk?”
But it wouldn’t be an interesting blog post if I didn’t find something to take issue with, so here it is:
A loss form needs to be quantifiable in the form of money if you want to justify the cost to mitigate it.
I’m not sure that’s necessarily true. Oh, it is if you’re trying to emulate a financial institution, where quants are the nerdy but nevertheless STuDly backbone of the risk management department, but I tend to believe that many executives’ eyes glaze over when you’re trying to walk them through the contortions needed to squeeze some quantifiable numbers out of what started out as a qualitative IT security assessment.
Yes, I remember Jack Jones’s canonical story about being asked by a CFO, “How much risk do we have?” But that was a CFO (IIRC—right, Jack?), and they’ve got a big hammer that they’re used to using, so of course they want you to bring them nails. And it did prompt Jack to develop this lovely risk assessment taxonomy and model that can get you awfully close to using lots of pretty numbers. But I’m just sitting here, imagining trying to hold a FAIR conversation with anyone else on my executive team that was, say, longer than two slides, and I suspect I’d lose them. They might think about financial risk that way, but they don’t think about security risk that way. And I’m not sure that they should have to.
How do you put a price tag on a bunch of primary or secondary loss events, only a few of which actually translate into dollars? You can estimate productivity loss, replacement costs, legal costs, and fines. You might think you could do stock price, but if you could guess which way the wind EVER blows on that one, you’d already be rich. If the studies are to be believed, you can’t even count on losing customers in the wake of a security breach. Once you get into the realm of how much your boss will hate to see his name in the papers, you really can’t get back to quant-land from there, and neither can he.
What’s more, people using slides tend to focus on the “someone breaks in and steals SSNs” scenario, which is easier to cost out in terms of loss than other types of breaches. You’ve also got scenarios like the mayor’s steamy text messages being published, which everyone would agree is bad enough to want to avoid, but everyone will assign it a different amount of badness relative to what they personally are willing to spend to avoid it. And what they are willing to spend to avoid it varies widely based on how much money they have to start with. I just don’t think this is an equation that can be worked out.
Because real-life risk decisions are based on the culture in your organization, the risk appetite and tolerance of your leaders, the industry, the spending patterns, and even whether you’re public or private sector. I’ll be willing to bet a lot of Patron that if you gathered a bunch of organization heads and gave them the same odds of a particular loss event, gave them the same dollar estimates for the quantifiable loss, and asked them whether they’d be willing to spend the same $100,000 to reduce the risk to the same number—I’ll bet they would give you different answers, ranging from “Sure, here’s a check” to “Are you crazy?”
If organization A is only willing to spend up to $10,000 to avoid the same loss that organization B is willing to spend $100,000 to avoid, then do these numbers really have any meaning any more? Especially if the loss is in face? I just don’t think you can call it a tradeoff—spending one number to avoid losing another number. (Okay, okay, as the first number approaches the second, you’re going to see a dropoff in willingness in any case. But again, that’s assuming your second number really quantifies all the loss.)
So I don’t think it’s always necessary to quantify a loss in order to justify spending to mitigate it. We don’t quantify our pleasure in a new car to justify spending money on it. We don’t quantify our fear of having our child flunk out of school to justify spending money on a tutor. There is a wide world of loss out there that can’t be quantified, and I’m cool with that. What matters is the building blocks your executive wants to use to make his risk decisions, and whether they’re dollar figures, colors, or Venn diagrams, you’ll need to make an effort to supply them. Otherwise you won’t have the communication that is so necessary between you and your bosses—and you sure won’t get your spending money.
Posted by
shrdlu on Saturday, August 02, 2008
(3)
Comments •
Permalink •
I hope you’ll pardon me while I take a few minutes to wax sentimental.
Fifteen years ago on this here day, my lovely and talented webmaster and I got the Piece of Paper at a town hall. We went out to lunch with our parents afterwards, and our two Best Men, and then went back to the flat, where we ordered a pizza for dinner. Mind you, it took us six more months after that piece of paper was issued before we were authorized to live in the same country together, and we continued commuting 4-1/2 hours each way every weekend until then. But it sure beat the initial 8-hour flight between us (mommas, don’t let your babies meet people in #hottub).
Since then, we’ve lived in three countries, combined four or five sets of furniture, and added two mini-geeks to the household. We’ve collected and junked hardware and collected some more. We’ve bought each other every geek toy we could think of (we still have our first-version PDAs from 10+ years ago, and they still have the old appointments in them). We’ve been to cons, renfaires, weddings, and funerals. You can’t walk into any room without tripping over an SF book. We fight over who gets to wear the favorite nerdy t-shirts each day. We still tell each other obscure, bad geek jokes. And when we’re in the house alone, we still email each other or send Dingleberry messages rather than actually yell from the loft to the living room. Our parents don’t understand us, but it doesn’t matter.
What I’m trying to say is, I’m endlessly grateful that I found the right geek to share my life with.
Here’s to the next 00001111 years. :-*
Posted by
shrdlu on Wednesday, July 30, 2008
(3)
Comments •
Permalink •
... be sure to have some backup for your egomaniacal network admin.
I’ve been reading this saga with increasing amazement but not very much surprise. I never bought the argument “I’ve got to protect my network from these incompetent boobs”; it just made me more sure that what we’ve got here is another case of narcissistic personality disorder.
I’ve seen this more than once in my career, and if there’s any one personality type that you can count on more than any other to launch an insider attack, it’s the narcissist. The first clue is someone who blames everyone but himself for his problems. You can then count on him matching the DSM-IV criteria:
1. has a grandiose sense of self-importance
2. is preoccupied with fantasies of unlimited success, power, brilliance, beauty, or ideal love
3. believes that he or she is “special” and unique
4. requires excessive admiration
5. has a sense of entitlement
6. is interpersonally exploitative
7. lacks empathy
8. is often envious of others or believes others are envious of him or her
9. shows arrogant, haughty behaviors or attitudes
This all adds up to the techie who feels his genius isn’t being sufficiently appreciated, and therefore he’s entitled to take revenge on those who are conspiring against him.
To confirm this diagnosis, merely suggest to this person that he and his knowledge are SOOOO valuable that you’re really worried about what would happen to the organization if he were hit by a bus, and that therefore you should all work on enabling other people to be backups for him. If he starts to fidget, pout, or outright object, you know you’ve got to deal with this right away. Before it gets worse.
When you’re terminating an employee, especially one with privileged access, there’s often a debate about whether to cut off the access ahead of time. You may consider doing it even if the employee is voluntarily resigning. In either of these cases, if you have any suspicion that the employee is (1) leaving with a less than fond attitude towards the organization, and (2) has this “blame everyone else” attitude, you can and should make a good argument for disabling that access right away. This is one of the things they don’t teach you in CISSP skool.
UPDATE: He tried to copyright the “technical artistry” of his network design. (See July 2007 in the timeline near the bottom.) Quod erat demonstrandum.
Posted by
shrdlu on Thursday, July 24, 2008
(1)
Comments •
Permalink •
Please don’t make me work any harder than I have to.
What I mean by this is: if the job posting calls for “x years’ experience in foo,” please write on your resume “x years’ experience in foo.” Don’t make me go through all your dates of employment (assuming they’re there), trying to infer the term “foo” in whatever you said you were doing, and then adding years together. In some cases, hiring managers have to go through a precise checklist and justify each person they bring in for an interview (because they may get sued by the ones who didn’t get in). In other cases, you have someone in HR screening the resumes ahead of time, and if you don’t put the exact term, they will 86 your application without a second thought (if they even had a first one).
Yes, OS X hacking experience counts as Unix experience in my book, but that’s just because I happened to have lived through the Mach BSD NeXT OS era. Don’t count on anyone else being that flexible.
Also, do not say you increased or improved or decreased something by X percent. I don’t know what the hell 10% means. Tell me numbers and tell me units, and let me do the math if I want to be impressed by the percentage. Increasing throughput by 10% doesn’t impress me if your previous throughput was lame to begin with. Increasing customer satisfaction by 78%? Exactly what units of satisfaction are you using? Happy faces on trouble tickets?
And finally, if you have a security-degree-in-a-box and are working as a cashier at Walmart, do us all a favor and don’t apply for a senior security position. Although it was nice to have the laugh in the middle of the paper stack.
Good night, and good luck.
Posted by
shrdlu on Wednesday, July 23, 2008
(0)
Comments •
Permalink •
Any time you’re evaluating or designing a system, you have to take into account the ability for things to go horribly wrong.
Now, this is pretty obvious when you’re building a bridge, but for some reason, nobody expects security analysts to be thinking this way. I guess it’s because people on the outside think we’re all about stopping 3v1L H4X0rz, and that security stops there. If they think any further than that, they expect that we’re all about stopping naive users from writing their passwords on Post-It notes (which is also a depressingly frequent part of the job, don’t get me wrong).
So developers get confused when I point out potential failure points in their applications. Either they say, “But who would DO that?” or, “Don’t worry, our users aren’t smart enough to try that.” My Clue Bricks are showing signs of heavy wear; I think they’ll FAIL before the need for them has dissipated.
For example, I’m just picturing my next conversation with a virtualization engineer, where I’m planning to tell him how I want my virtualized instances of a certain critical division handled:
“Oh, and you can’t use VMotion on these.”
“WHAT?? Why not? VMotion will allow us to provide fault tolerance by moving things around!”
“Take a look here. We’ll have eight instances, four primary and four backup, right?”
“Right.”
“Well, you’re going to put each primary and its associated backup on separate VM hosts, right? They’re never going to be on the same ones.”
[Blank look.]
“Because one of the great new things introduced by virtualization is grouping previously separate instances under a SINGLE POINT OF FAILURE.”
[Blank look.]
“If your hypervisor takes a dump, or if the VM host hardware fails, everything on that box is going down together. So I don’t ever want to see a primary and its backup on the same box. Since there are only eight servers, you’re not going to have more than two VM hosts, so there will be no need to migrate anything around except in an emergency. Now, for performance reasons, if the backups aren’t busy, you may want to have two backups on each box with two primaries, so that the primaries can suck up the resources. But you’re not going to do any fancy switching on the fly. So no VMotion.”
“But ... what if both of them go down?”
“In that case, you can move them manually. I want you to be thinking about it; I want you to be careful and deliberate. Besides, these servers are classified differently from all the others and I don’t want any of them to ACCIDENTALLY reappear on some other host with a different policy setting.”
“What’s wrong with that? We can isolate them from each other using policy rules; that’s what this nifty management software is for.”
“Rules can be fubared. Software can be hacked. There’s no substitute for a physical gap when you’re really serious about separation.”
Now, at this point, I expect the engineer to get this sullen look on his face as if I’m telling him that I expect him and his whole admin staff to be stupid. (From what I’ve seen, many of them are only barely IN the drawer with the sharp things.) But that’s not the point: I expect them to be HUMAN. When you have more moving parts, you have more opportunity for FAIL, and that’s why you disable any of them that you don’t absolutely need. Simplify, simplify, simplify. Just because something comes with a nifty new feature, it doesn’t mean you have to use it.
Actually, that’s why virtualization makes me nervous, in a nutshell. It allows you to shoot yourself in the foot faster, with more efficiency and automation. “Dammit, where did that VM go??” “Oh, I thought you wanted that one retired, so I took it offline.” “Well, where is it archived?” “Um, let me see ...” “Hey, who set up this instance called ‘ursopwn3d’?”
Take another example. People keep going on about how DLP is only really good for “stopping stupid.” Well, maybe that’s only as good as it’s ever going to get. And that’s okay; maybe anything that interferes with a business process by design can’t do much prevention when the only differences between malice and stupidity are, well, intent and cleverness.
Human error can and should be prevented wherever possible. Same with stupidity. But in the case of malice, you probably have to lean more on the side of detection instead.
STUPIDITY : MALICE :: FAIL : PWN. Remember this for your Security Aptitude Test, grassh0pper.
Posted by
shrdlu on Sunday, June 29, 2008
(0)
Comments •
Permalink •
Every once in a while I get a request that drives me crazy. It’s usually in the form of, “X group needs to be secure, tell them what to do.”
And you know that “tell them what to do” doesn’t mean “perform an audit, engage a pentester, give them a list of findings, create a security management program for them, and put it all in writing.” It means “put a couple of lines in our contract with them” or “talk to one of their reps for half an hour on the phone.” You can’t tell them to “comply with all our policies,” because then you have to list all of them (including the ones that aren’t written down), and before you know it, you have a book that they don’t want.
So I was thinking: how do YOU sum up “how to be secure” as briefly as possible?
Here’s what I have it boiled down to:
1. Have control over your systems.
2. Check your security frequently.
3. Educate all your people.
Number one expands to maintaining an accurate inventory of your systems; having a process in place to manage and update them consistently; making sure your users aren’t messing them up; making sure nobody is adding unmanaged systems or software; and have policies and processes for access control and system administration.
Number two expands to monitoring, auditing, certification, pentesting, and performing risk assessments against the current trends.
Number three means training users, support people, developers, AND all executives. It includes educating your security people so that they know what they’re supposed to be doing.
I think if you cover these three points, you’ll have a pretty good security program and have most of the bases covered. What do you think?
Posted by
shrdlu on Thursday, June 12, 2008
(6)
Comments •
Permalink •
Executives spend too much time listening to the lawyers’ point of view.
Just because something is legal, doesn’t mean it’s right to do it.
And just because the law doesn’t compel you to do something, it doesn’t mean you shouldn’t do it.
Thank you.
This mini-rant brought to you by the letters A, Q and X, and by the number §.
Posted by
shrdlu on Monday, June 09, 2008
(2)
Comments •
Permalink •
Things like this, that’s why.
And not just because he puts me in mind of songs:
(and yes, I can make references closer to this century)
but because his questions can’t be answered in a short comment.
When he asks, “What are you managing towards?” and gives some good examples of answers, my first impulse is to combine one or more of them and say something like:
“I’m managing towards just enough control strength to let luck take over.”
That’s dipping into Good-Enough-Securityland, where “good enough” is measured as “whatever keeps us from shooting ourselves in the foot.” This doesn’t sound at all noble, I know, and it’s not all cool like Andrew and the Metrics or even our Bayesian Homeboys, but to be real honest, my management doesn’t want to get to that level of elegance. They just want me to keep their names out of the papers, do the right thing by our customers, and tell them how much they should spend to achieve that.
I make it a point to remind them from time to time that we’re doing pretty well on the prevention and detection fronts, but that nobody is going to be able to stop a targeted attack. They’re reasonable folks; they understand this. They understand that you can’t control a threat, especially one that’s external. What I’m doing is working to prevent opportunistic attacks, and making sure we’re doing enough due diligence that a reasonable person would feel that our legal backsides are covered.
Managing to compliance is almost irrelevant to our security landscape. That would be like managing your accounting to compliance. Yes, you want to make sure you’re following the rules, but you sure wouldn’t manage your finances with the end goal of passing an audit. In fact, if you asked any CFO if he were “managing towards compliance,” he’d probably look at you funny.
Schneier’s extremely depressing and extremely true essay on why it’s so hard to sell security says it all. My bosses don’t want to get to “best” or “100% compliant.” They want to do better than the competition, but not radically so if it means incurring too much “loss” in the form of paying for security; they want to feel confident that they have done the best they can to put in reasonable controls. And then they want to forget about it and go about their real business.
Once a year, I write a report (oh, 40 to 60 pages’ worth) on what my section has been doing and what else I think we need to do to stay at “good enough.” And then my senior management sits down with me and we have a discussion to update what we think “good enough” means for us. If they want metrics to help them narrow in on “good enough,” they’re in the report. I tell them what I’m doing with their money, and if possible, I compare it to what our peers are doing. It’s one big “state of the union” talk, and it only lasts long enough for them to grok it, and then we’re done.
They get to spend the rest of the year feeling lucky.
Posted by
shrdlu on Tuesday, June 03, 2008
(6)
Comments •
Permalink •
I’ve been spending a lot of time mentally on vacation, but Rybolov keeps dragging me out of it, damn his zombie-lovin’ eyes.
Here are some security titles I’d really like to see:
Risk Management on $2 a Day
Build Your Own UTM Appliance Out of Kitchen Tiles and Vacuum Tubes
Faking FISMA
Sister Mary Malware’s Corporal Punishment For Naughty Users
Security Metrics: Size Really Does Count
Gauntlet’s Greatest Hits: All the Rules in One Collection, 1996 - 2001
Why All the Good Security Tools Sound Like Drugs
GRC Porn: Confessions of a CISA
Posted by
shrdlu on Monday, June 02, 2008
(1)
Comments •
Permalink •
Why should you audit your security folks?
Note that this is different from an audit of your organization’s security; I’m talking about auditing the folks who do the securing.
Besides the whole quis custodiet thing, there are other reasons why it’s a good idea: if you’re running your security program as a business, as many people say you should, you need to audit your business.
- Are the security staff being effectively utilized?
- Are they keeping proper records and documenting important processes?
- Are they maintaining a proper separation of duties themselves?
- Are they abusing their überpowers (assuming they have any)? Are they only monitoring within documented and approved limits?
- Are they properly negotiating and managing contracts?
- Are they making the right purchases and managing their budget properly?
- Are they enforcing policies equally and fairly?
- Does the security program cover all appropriate areas, and is it being diligently applied?
- Are they securing their own information?
- In other words, are you getting the right value for the money you’re spending on those people?
Remember, there is just as much potential for fraud, waste and abuse within a security group as there is anywhere else—perhaps more, because they’re typically in a trusted position. So audit not, lest ye be audited!
Posted by
shrdlu on Friday, May 23, 2008
(1)
Comments •
Permalink •
In all the initiatives I’ve rolled out in my (checkered) career, the ones that have gotten the most acclaim from my management have always been the ones that were most visible to the users. They turned out to be popular if they:
- were used directly by the users
- allowed the users to do something better, or faster, or better AND more securely
- helped reduce the risk of a legal problem
Never mind that we might have done something much more impressive with the firewalls, or monitoring, or something “under the covers.” It might as well have been plumbing. I could have gone to them and said, “We’ve replaced everything with the finest tubing and we won’t have any more leaks for 20 years,” they would have said, “Oh. Fine. Next?”
This is just to point out that not all “security impacts” are equal. We may spend a lot of time Fighting the Good Fight to secure against cross-site scripting, for example, but it’s often seen as much more valuable if it secures the way people are using data. In the eyes of the business—the ultimate risk decision maker—the more it affects/helps the users, the bigger the win. So from a practical point of view, they’re using a very different set of risk factors than we are from behind our consoles and our dashboards.
Which set is “correct,” which view provides the best understanding of the actual security risk, may never be determined. But an ISO’s job is to try to understand and reconcile the two as far as possible.
Posted by
shrdlu on Thursday, May 22, 2008
(2)
Comments •
Permalink •
