Everyone agrees that SSNs are overused and overexposed today, both as unique identifiers and as authenticators, but nobody is able to step up and tell J. Random Corporation how to stop using them. You can’t—not when there is no other immutable, unique identifier for an individual in these here United Snakes. There’s nothing that follows you from state to state, from birth to death, through marriage and divorce ... except taxes. (Yep, and taxes follow you even after death.) This is why the IRS is the best tracker on the planet. There’s nothing like a government’s incentive to make sure it is getting its hands on as much money as legally permitted ... but I digress.
Please don’t bleat “federated identity management” at me. There’s no economic incentive to make that work (except of course for the vendors selling it). People won’t buy it and use it until it becomes a political necessity (read: economic, imposed by politicians). And that won’t happen until enough people are outraged by identity theft to pressure legislators into doing something about it. Just telling organizations to “protect personal data” won’t work when they don’t know how to stop using it like monograms on towels.
But there are a few guidelines you can offer your particular organization.
First, teach them the difference between identification (telling two individuals apart) and authentication (verifying that they are who they claim to be for the purpose of granting them access to something).
Next, teach them the difference between registering an individual (that is, authenticating them once and then assigning them a unique identifier in your systems) and tracking them thereafter. You might need an SSN for the first part—that is, assuming you even bother to validate that SSN, which most organizations don’t, even if they’re reporting payments to the IRS—but you don’t need it every time you reference that individual later on.
Tell them that if they’re only using an SSN as a unique identifier, and it’s only for the purposes within your organization, they should generate and assign a new ID to that user instead of being lazy and indexing on the SSN in the database and everywhere else. There’s no reason why you can’t tell a customer to reference a customer ID in correspondence with you rather than making him provide his SSN every time. You’re doing a lookup either way, and the strings don’t matter as long as they match.
Unfortunately, if you have to track individuals between organizations that don’t share any common IDs, you’re stuck with the SSN, especially if you’re crossing state lines. I just don’t see any way around that today, and if you can think of one, please speak up.
Either way, for Bog’s sake, tell them NOT to use the SSN or any other personal data just to create a unique login name for a user. And they don’t need to display the SSN for that user every time he logs in. There are SOME braindead practices we can start eradicating right here, right now.
(This post is dedicated to LonerVamp, who poked me at just the right time while I was feeling ornery about this very issue.)
Posted by
shrdlu on Friday, September 08, 2006
(4)
Comments •
Permalink •
The Information Technology Process Institute (and that name alone should tell you plenty about their agenda) came out with a useful, even believable study of how the best performing organizations have good IT controls.
All warnings about correlation versus causation aside, what they list makes sense. But it’s still in godawful management-speak, so I’ll do a little translating for the benefit of those in the studio audience:
Top Performers Are Different in a Few Key Areas
The subset of Foundational Controls that most differentiate top from medium performers are in the areas of change and configuration controls. The top six controls that differentiate high and medium performers are:
- Do you monitor systems for unauthorized changes?
- Are their [sic] defined consequences for intentional unauthorized changes?
- Do you have a formal process for IT configuration management?
- Do you have an automated process for configuration management?
- Do you track your change success rate?
- Are you able to provide relevant personnel with correct and accurate information on the present IT infrastructure configurations, including their physical and functional specifications?
*There apparently aren’t defined consequences for bad spelling in an expensive report.
To put this into plain English, if you keep track of what you’re doing to your systems; if you take note of how often you’re causing something to melt down while doing it; if you actually go after the people who make changes they’re not supposed to; if you automate your changes so that there’s less chance of messing them up; and if you know what you have and what’s on it, you’ll perform better.
Or, as they put it:
We characterize the controls that differentiate top from medium performers as the activities that sustain and continually improve their control systems. These activities such as enforcing processes and the consistent use of controls to avert high risk activities proactively stabilize the IT environment.
So if your system management isn’t a free-for-all, your environment will be stabler.
Can I get a “DUH”?
The sad thing is, they want you to pay $1,695 for the whole report with circles and arrows to convince your CEO that it’s true.
I’m clearly in the wrong line of work.
Posted by
shrdlu on Tuesday, August 29, 2006
(4)
Comments •
Permalink •
Managing security comes naturally to parents.
“Mom, can I go just this once?”
“Well, it isn’t a school night ... okay.”
“But mooooommm ... everyone else uses GET instead of POST.”
“I don’t care how many of your friends are doing it wrong; YOU are going to do it right.”
“But you said last week that it was okay.”
“That was before I found out this new bit of news. Sorry.”
“That’s not FAIR!!!” (Exit developer, stamping feet and slamming doors.)
“Guess who forgot to lock his workstation—AGAIN?”
“Nobody likes a tattletale. Go back to your office.”
The point is, a good portion of security work is managing and documenting exceptions. Pretty much ALL of firewall management is about exceptions. (That is, if you’re doing it right and starting from a default deny stance.) All remote access is about exceptions. In fact, if you looked at all user management as being about exceptions, you wouldn’t be too far off the mark.
That’s why I wish that security vendors had much more support for user annotation in their products. Take any vulnerability scan. The first thing you’re going to do is weed out the false positives: the ones where the scanner mis-identifies the platform, the ones where you don’t consider it a problem, and the ones where you know you ought not to be doing it in an ideal world, but you have to because of some brain-dead six-year-old product (or antiquated business partner).
Now, how do you track those so that you don’t have to weed them out AGAIN for the next scan? How do you document those when the auditors come in and ask you for the output? How do you keep track of who approved them, and why?
Same thing with compliance tools. How do you mark something as “To be done next year when we have the budget, now get off my back”?
And how do you track these over time, over multiple sites? How do you mark that Antwerp has taken care of this issue because they only have 20 hosts in their one office, but New York will probably NEVER get it done until they upgrade to Vista?
How do you document the decision to let J. Random Developer create 200 of his own testing accounts because he just can’t test his application any other way? How do you post a flag to follow up later and make him delete them all when he’s done? (“I want you home by ten, young man—and that’s final!”)
Right now, too much of security rests on institutional knowledge that may or may not be documented, but certainly isn’t documented anywhere near the scene of the crime. And none of it’s centralized to make it easy for me to print out and hand to a security analyst who’s trying to figure out why we have port 31337 open to an IP range in Qbekistan, accessing a workstation that’s running NeXTstep. Short of a big-ass Excel spreadsheet, I don’t know how to keep track of what I approved for whom, for what reasons, and for how long, in every area where I make decisions on a daily basis.
Do you treat every login and every network connection as an exception? If so, how do you document them so that someone else can find and read them?
Posted by
shrdlu on Monday, August 28, 2006
(3)
Comments •
Permalink •
The April 2006 issue of Information Security magazine has a face-off between Marcus Ranum and Bruce Schneier (free subscription required). I love to read both of them, and it’s even more fun to get some Point-Counterpoint action. (“Bruce, you ignorant slut ...”)
I’m guessing from their arguments here, about how to handle users’ failure to learn, that Marcus is politically to the right of Bruce. You can see the classic “let them learn from their own mistakes” contrasting with the “let’s blame the business” position. (Now, don’t try to draw any inferences about my own leanings from how I describe these; I’ve got a Kinky Friedman bumper sticker on my car.)
Here’s Marcus:
From where I sit, it appears that the most effective tools for teaching users about security are pain and humiliation. In fact, they seem to be the only effective tools for teaching about security. I’ve noticed, for example, that there is nothing that gets people to take identity theft seriously like a $15,000 credit-card bill. Having to reload Windows every three months is an effective lesson about why viruses are good to avoid. Seeing stock options plummet because the customer database is on a public FTP site gets even the most reluctant IT manager’s attention. Should we stop spending time trying to educate people and spend our time pointing and giggling instead?
And here’s Bruce:
The real problem is that computers don’t work well. The industry has convinced everyone that people need a computer to survive, and at the same time it’s made computers so complicated that only an expert can maintain them.
If I try to repair my home heating system, I’m likely to break all sorts of safety rules. I have no experience in that sort of thing, and honestly, there’s no point trying to educate me. But the heating system works fine without my having to learn anything about it. I know how to set my thermostat and to call a professional if something goes wrong.
Punishment isn’t something you do instead of education; it’s a form of education—a very primal form of education best suited to children and animals (and experts aren’t so sure about children). I say we stop punishing people for failures of technology, and demand that computer companies market secure hardware and software.
To which I say: it’s a floor wax AND a dessert topping! Yes, we need to put in better safety measures to save users from themselves, but until that happens, whatcha gonna do? What happens between the first strikes of litigation and the final rollout of the New Improved Crash Helmet? You still need to teach people which things not to do today. We can’t slack off on user awareness training; we just have to do it better.
Marcus has the right idea in making it a personal issue for the user; that sort of lesson is taken more to heart. That’s why I provide classes on how to secure your home computer and how to prevent identity theft. The employees of my organization are more interested in protecting their own resources, but the basic principles are the same: if they learn better practices at home, that’ll translate into better practices at work. And besides, remember those endpoints? It can only improve corporate network security if the users are accessing it remotely from better secured boxes.
Still, there are some lessons that people just can’t, or won’t, learn until they actually do a face-plant. America’s Funniest Home Videos is chock full of examples of people who still don’t quite grasp the laws of physics, and how long have THOSE been around? We need to get better with built-in security to keep those kinds of people from doing the worst things: we need better fences, unmissable warning signs, air bags, and other safety locks. We need to be able to contain the damage better. But we also need to get stricter about the idiots who do the technological equivalent of setting off fireworks in the middle of a drought area. And we need to be ready to pick up missing fingers in the field. Computers and firecrackers are both too user-friendly and too powerful.
Posted by
shrdlu on Wednesday, August 23, 2006
(1)
Comments •
Permalink •
[Bloggiste note: I originally lost most of this post in a deadly combination of senior moment and really short session timeout. So now I’m faced with reconstructing my deconstruction. Soon I’ll work up to mixing antipasto with penne, and then all hell will break loose.)
The Office of the Inspector General’s report on the VA laptop theft is a doozy. It contains a lot of valuable lessons for those who can see beyond what most people are focusing on: the lack of disk encryption.
The employee explained that much of the data that he had stored on the stolen external hard drive was for his “fascination project” that he self-initiated and worked on at home during his own time. Because of past criticism on the reliability of the National Survey of Veterans, his project focused on identifying approximately 7,000 veterans who participated in the 2001 survey, in order to compare the accuracy of their responses with information VA already had on file. He began the project in 2003, but could not recall spending time working on it during 2006.
First off, the employee took this data home to work on his own project, about which his management knew nothing. This points to a serious lack of communication and supervision on their parts. But notice also that he was schlepping this data around for THREE YEARS. Did no one take a look at his laptop or external hard drive in all that time? Did they even have a refresh cycle, and if so, what was it?
To conduct this project, the employee took home vast amounts of VA data and loaded it on an external hard drive. The stolen laptop did not contain VA data.
I have no idea at all why this is supposed to be even worth differentiating. See below.
While the employee stored the laptop and the external hard drive in separate areas of the house, he acknowledged that he took security of the data for granted.
Now, this is amusing. Just where did he store the two so that he felt that this improved security? Did he store one of them under a mattress?
This is something that executives STILL don’t get: whenever you allow mobile devices or remote access, you are relying upon the security of wherever those endpoints happen to be. You’re relying on the physical security of hundreds of employees’ homes, the security at Starbucks, the security at the Paris Hilton (sorry, couldn’t resist; it’ll up my Weird Google Hit Quotient), the security at the airport kiosks, and anywhere else your users happen to be—all at once. In other words, you’re relying on the security of the USER, not the device they’re using. Your perimeter is no longer a shield wall; it’s a blob of Jell-O.
As I’ve said before, our information has turned to water, and it’s flowing everywhere. Another problem is that a lot of web-based applications act like sprinklers.
Let’s look now at the chain of reporting events ...
Click to read MORE...
Posted by
shrdlu on Sunday, August 20, 2006
(3)
Comments •
Permalink •
Security isn’t pretty.
You hardly ever get the chance to start with a clean slate; you don’t get the advantage of the calm, leisurely 1000-foot overview when you get into an environment. People say blithely that security should be built in from the beginning. And so it should. But in an existing organization, chances are, your biggest job is to solve the problems that are already there.
Network security can be messy in and of itself. I’ve worked in places so big and so dispersed that they had no idea how many external connections they had, much less whether they were firewalled in any way. And just try counting modems; I’ve known users to disconnect them and hide them in their desk drawers when you walk by. (I’ll bet you they’re doing the same thing now with WAPs.) So you sit down and start gingerly pulling threads: why are we permitting this in from the Internet? What’s that IP resolve to? If we cut it off, what else is going to break?
Oh no, they say, you can’t get rid of that. The third-party application will only work with all those ports open. No, they don’t do encryption. So you back off and say, well, okay, what “best practice” CAN we do? The answer is usually depressing.
Application security is even worse. The problems you find there are either the result of ignorance, laziness, crippling legacy dependencies, and/or trying to accommodate the lowest common denominator of user. Some problems come from trying to make the application easier to administer or update. (Thanks so much, Matasano. I was in denial until you ruined my weekend.) You try to ask questions like: can we partition this off? Do we really have to use this data? Does the developer really need to do all this himself? What will happen with the users if we tighten these parameters?
Even assuming you have all the people around you who can give you the answers (and that’s not always the case; legacy apps live on long after their creators have left, and if they’ve been running fine, nobody’s bothered to learn about them since), you’ll find that the applications and infrastructure are all depending on each other in complicated ways, AND there is no central architect who can speak for or manage the whole shebang.
The situation is ripe for a cascading security failure. Because you had a shortage of help desk people, you had to let users choose their own passwords. Because they chose bad passwords, one or more of them were cracked. Because you had to make it easy to get to the apps without additional authentication, the hacker got to one of them. Because the other apps trusted the one app, they got popped too. Because you had no money to buy additional disks, you had no disk space for logs. Because you had no logs, you had nobody monitoring them. Because you had nobody monitoring them, nobody noticed the security breach. Because all your servers had to talk to each other, the hacker was able to spread out. Because you were used to plenty of workstations ignoring your updates, you didn’t notice anything different when they were taken over. And so it goes.
Pick any combination you like. You can’t get rid of SSNs because you don’t have any other enterprise-wide unique identifier. You can’t enforce one security policy because you have to develop a whole new infrastructure to make it possible for people to comply with it. You can’t clean up this database without going through six months of cajoling in committee meetings. You can’t secure this site because the local admin resents your very existence and is protecting his domain. You can’t spend time and money to secure this server because “it’s going away real soon, we promise.”
It’s amazing that we can make any progress at all. The trick is to find a reasonably short thread to follow, and then another one, and then another one, all in the same region. By shoring up the weft, you may eventually be able to address the warp. Except this weave is eight layers deep, and you pretty much have to work on all of them at the same time. (Think I’m wrong? There are plenty of times where puzzles at a higher layer can only be finally solved by tracing the cables.)
My dreams are full of missing horseshoe nails. But there’s only so much I can do.
Posted by
shrdlu on Friday, August 04, 2006
(0)
Comments •
Permalink •
So, if you’re an IT security manager, and you live in the real world of constrained resources, how do you decide on your priorities?
I know there are a lot of different ways to slice and dice the Security Management Program pie, but just as a strawman I’ll throw out these categories:
- system and network configuration
- application security
- physical security
- policies and awareness
- incident response
- monitoring and detection
- legal and audit compliance
A little clarification: you’ll find buzzwords like “vulnerability scanning” and “firewalls” under system and network configuration. Incident response in this case means training and preparing for incident response, not actually doing it (of course incidents take top priority).
And you’ll notice that I put compliance in its own category, because I don’t believe there’s a complete one-to-one correspondence between it and any of the other categories. It sort of sits over all of them, but not very well.
Do you tend to be event-driven? When you have an incident that was caused by a lack of something in a particular category, do you put that one at the top of your priority list? Do you try to give equal time and attention to all of them in an endless Whack-a-Mole loop?
I’m going to be a little radical here and toss out the idea that your first priority and your greatest effort should be in awareness and security education, with the rationale that since security depends on people, if you do nothing else but teach your organization how to Do the Right Thing, you’ll get farther than by pushing harder on the other categories.
Security managers can’t be everywhere at once. You have to depend on the system administrators knowing how to configure systems securely, keep the patches rolling, monitoring their particular systems, and knowing when to call you if they see something funky. You have to depend on developers knowing the basics of secure application design, because you’ll never be able to check all their code. The general users have to know what to do, what not to do, and be encouraged to ask questions when they’re not clear on policy.
So I’d argue that you’ll get more tasty tuna by teaching the rest of the organization to fish than by trying to keep up with all the nets yourself, even if you’re the Net.Professional.
Posted by
shrdlu on Thursday, July 27, 2006
(0)
Comments •
Permalink •
Ha! You thought I was only going after users? Think again.
Here are some of the things I hate to hear from developers:
1. We’ll fix that in the next release cycle.
No, you’ll fix it now. It’s a security flaw. You don’t get a pass on security flaws just because your app hasn’t actually broken in a way that makes management sit up and take notice.
(Have you ever, EVER heard of a developer being fired for writing insecure code or not fixing a hole quickly enough? Neither have I, more’s the pity.)
I don’t care if this makes you blow your deployment deadline. I don’t care if it delays the start of your next project writing MORE buggy code. There are only two good reasons why you may be allowed to keep to your deadline: if we’re going to be breaking the law by missing it, or if the organization will lose serious money by missing it. Interestingly enough, this almost never happens.
2. We don’t need encryption, because this is inside the internal network/it doesn’t carry confidential data/other lame reason.
Bzzt! Wrong. Unless you have a very good, compelling business or technical reason why you can’t implement encryption, you will do it by default. Always assume that there are bad guys inside the perimeter (because that’s where they LIKE to be), and remember that anything that will give them an extra toehold into our systems is a BAD THING.
3. The user interface will enforce access control.
BWAHAHAHAHAHA ... snort ... giggle ... >>THWACK!!<< Go home and read up on people who do not NEED user interfaces to talk to back-end servers. Next?
4. This wasn’t ever considered a problem before ... why do we have to fix it now?
Um, because now you have someone in your organization who (a) knows about security and (b) is paying attention?
5. The users won’t be able to handle that.
Well, you’ll just have to train them, then. Just because you have stupid users doesn’t mean a really smart, UNAUTHORIZED one won’t come along.
6. The users won’t be able to handle that.
You mean YOU can’t figure out how to implement it. Not my problem.
7. It’s okay, because they won’t be able to see that part.
Go to the chalkboard and write fifty times, “SECURITY THROUGH OBSCURITY DOES NOT WORK.”
8. Please, please can I use AJAX? It’s really cool.
No.
(Stopping here because I feel no need to make this a Top Ten list.)
Posted by
shrdlu on Tuesday, July 25, 2006
(2)
Comments •
Permalink •
Bejtlich redesigned his site, so I have to maintain my slavish devotion by following suit. Actually, my lovely and talented webmaster slipped me from Drupal into ExpressionEngine while I wasn’t looking. Pardon my dust while I fumble my way around. If you were getting the RSS feed and it broke, I’m sorry. I’ll buy you a beer sometime.
Posted by
shrdlu on Saturday, July 22, 2006
(0)
Comments •
Permalink •
(By the way, to hear a hilarious oompah version of the song, listen to this clip on Amazon.de)
Previous entry aside, it’s just not enough when you’re hiring a security person to say that you’re looking for “Smart, and Gets Things Done.” I was gratified to hear one of my top executives describe his search criteria as “talent” and “speed,” and add that he “know[s] it when [he] see[s] it.” I know the feeling. But that still doesn’t make for a decent job posting.
So, what do I ask for? I’m biased, admittedly: I tend to think that the best hands-on security analysts have a system administration background. I look for candidates who have a certain number of years’ experience in at least three of five areas: network admin/support/design, OS admin/support/design, database admin/support/design, application development/support, and “Internet technologies” (email, web, etc.) admin/support/design. It’s especially important that I see at least some design work in there, because I know of too many support people who just run what they’re given and don’t really understand it.
On top of that, I look for a minimum amount of experience with admin/support/design of the usual security infrastructure: firewalls, IDS/IPS, encryption, VPNs, and so on.
I weight the sysadmin experience more heavily than the actual “security” experience, though. To my surprise I’ve discovered that there now exists a breed that I’ll call the “security technician”: someone who can install and run VPNs and firewalls without really understanding the security principles behind them. Someone like that might look good on paper, with six years or so installing commodity firewalls, but when you get them into the interview, they fall flat in the conceptual areas. (A tipoff is when you ask them to describe how public key encryption works, they start talking in terms of SSL certificates being installed on a server. Another is if they spend a lot of time talking about security in terms of tools. “Well, to solve this problem you fire up the IDS ...”)
I can take a good sysadmin and train her up in the security area, because if she’s a good sysadmin, she’s already tackled a lot of those areas and just needs to focus more on them. But a top-down “security” person just doesn’t turn out as well in my organization.
After the technical skillsets (which includes the ability to explain complicated technical issues using little teeny words), I look for people skills. Once in a while I will take a real introvert if he’s extremely good technically, but in general, I need all my security folks to be able to work on Layer 8 as well as the other layers. Security is tricky enough without having a personality on my team that pisses people off for no good reason. Let’s face it: a lot of security work involves breaking the news to people that they’re doing things Wrong. That takes finesse. Also, someone who doesn’t have good people skills won’t make a good team member, and I want my team to play nicely with each other as well as with the rest of the organization.
This is just my set of filters, though. I’m not a vendor installing security products for the masses, and I don’t have a large team where I can afford to have too many specialists. Most of the time I get lucky and find a combination of people who are strong in different parts of the “Five Areas,” and they make a good mix.
Being able to quote Real Genius isn’t strictly necessary, but it helps.
Posted by
shrdlu on Friday, July 21, 2006
(1)
Comments •
Permalink •
Well, Bruce Schneier has finally weighed in on certifications. As usual, he makes a lot of sense even when I don’t totally agree with him:
In the end, certifications are like profiling. They work, but they’re sloppy. Just because someone has a particular certification doesn’t mean that he has the security expertise you’re looking for (in other words, there are false positives). And just because someone doesn’t have a security certification doesn’t mean that he doesn’t have the required security expertise (false negatives). But we use them for the same reason we profile: We don’t have the time, patience, or ability to test for what we’re looking for explicitly.
Full disclosure: as far as security practitioners go, I’m completely uncertified. I don’t have a college degree, I don’t have any professional certs—hell, I’ve never even had a single academic computer course in my life. (I’m not counting the time I tried to take a Fortran class in summer school, and dropped out because the teacher was trying to teach both us and the trig class next door at the same time.)
So I’ve always fought the battle to keep certs from being the sole source of profiling that Schneier describes here. He’s exactly right in his last sentence above: if you’re depending on a non-security manager or an HR flunky to screen résumés, it’s much, MUCH easier to tell them to look for a certain string of letters as a profiling aid.
But I would argue that in this field, we still don’t have a sufficient number of really, truly qualified AND certified practitioners that we can afford to exclude the “false negatives.” And I’d also argue that certifications haven’t necessarily honed in on the skillset that I’m looking for when I hire. (Maybe GIAC; I tend to rate those higher. But CISSP, notsomuch.)
Then again, I still have lots of arguments with my HR department about the preference for a college degree. Again, it’s profiling and it’s sloppiness. I could go back, do nine more credit hours and get my BA in German with a minor in history. What good would that do me at this point in my career? Absolutely none. I know a security consultant who has a degree in Chinese philosophy. I’d wager, without any hard data to back it up, that only about half of the qualified practitioners in our field have any kind of college degree that’s computer science-related. So why the fuss about certification?
In a field as young as IT security, certifications are still misleading. There aren’t any standard solutions to most of the problems we’re trying to solve. We’re all, to a large extent, still groping in the dark, and what we need to look for are good gropers, not people who are certified in particular room configurations.
In the discussion on what to look for when hiring, there are some good points made out there, Dan Morrill’s being a prime example—both in his posting and in the follow-on comments:
I am sure that people will point out that I did not include in this firewall management, or certificates like the CISSP or GIAC. Nor did I mention education like Bachelors, Masters or Doctorates in this list. And that would be correct, because I am looking at hard skills, things that people know and when the rubber meets the road, I know that they can perform a task. CISSP and even formal education are more for the HR department and the companies screening processes. This top 10 list looks at core skills and core processes where if the person has even ½ of this list down cold, I know that they can do good work, and that I do not need to worry about them unless they cannot communicate.
Then you have a WAY false positive with “Frank Kenisky IV, CISSP, CISA, CISM” (wow, he’s had extra letters after his name from BIRTH!!), who shows that peculiar combination of arrogance and insecurity that you just can’t screen out on a résumé:
Dan, these are probably the rudimentary steps to hiring an experienced individual with any of these skills sets but to specifically exclude specific certifications now says volumes that Freud would start at your miserable experience at potty training.
In the end, I’m much more of Dan’s mindset, along with Joel Spolsky’s wonderfully lucid Guerilla Guide to Interviewing:
First of all, the #1 cardinal criteria for getting hired at Fog Creek:
Smart, and
Gets Things Done.
That’s it. That’s all we’re looking for. Memorize that. Recite it to yourself before you go to bed every night. Our goal is to hire people with aptitude, not a particular skill set. Any skill set that people can bring to the job will be technologically obsolete in a couple of years, anyway, so it’s better to hire people that are going to be able to learn any new technology rather than people who happen to know SQL programming right this minute.
Read Spolsky’s whole article. Learn it. Know it. Live it. THIS is the filter you should be hiring on, not the paper profiling.
If we ever get to the point where I can filter out all the uncertified applicants and still have 50 résumés on my desk from which to pick the five who are Smart and Get Things Done, then I will reconsider my opposition to profiling. Until then, sorry, Bruce—I’m with Marcus Ranum on this one.
Posted by
shrdlu on Thursday, July 20, 2006
(0)
Comments •
Permalink •
I make mistakes.
Nø realli, I do. My latest one was, as usual, spending too much time on an expedient deployment and not enough time actually designing it to be both thorough and as easy as possible for the user.
Let’s take, for example, The Laptop Problem. We all know what that one is about (especially if you’re a veteran and got one of Those Letters in the mail). Everyone is saying that the solution to that is encryption.
Okay, walk me through this. What kind of encryption are we talking about?
Full-disk encryption? With access controlled by another password? You know exactly what will happen if you try to deploy that to the common user. Either the user will just write down that password right next to his Windows password for the laptop, or he’ll ask you to tie the two together in a typical “single sign-on” accommodation. So you’re just back down to one password between you and the data on the laptop. If users can’t even get their laptop to operate without decrypting the disk, they’ll take whatever shortcuts they can to get up and running as quickly as possible.
Volume encryption? You still have the password problem. You also have to teach the user how to mount the volume, keep all his files in there, and NOT delete them by dragging them to his trash. You have to make sure his Outlook PST files are in the volume too, and you have to stop the user from leaving copies of the files on his desktop. And if you’re deploying this to a user who already has his laptop, how do you make sure ALL his existing files get moved to the volume and sufficiently sanitize the places where they used to be? And if the user can use his laptop just fine without opening the volume, you know he’s going to slip into that habit.
Just to make things more interesting, bear in mind that there are plenty of cases where a department has a shared laptop. How do you make sure ALL the users can check out the laptop and use it securely without taping those passwords on the keyboard?
It’s all very well and good to say, “It’s okay if that laptop was stolen, because we have E*N*C*R*Y*P*T*I*O*N on it!” But the reality is, do you KNOW for sure that the user was actually using it? And where’s the password for the encryption utility being handled? Are you really, truly providing any more protection than with one Windows password?
Here’s what I would do:
1. Get the laptop back from the user. Back up all the user files.
2. Sanitize and re-install the laptop.
3. Create the encryption volume to take up most of the disk. Configure Outlook to put its files there, along with any other applications that might handle sensitive data (that means all the Office apps). Make “My Documents” point to the volume too. Restore the user files into that volume.
4. Put the volume encryption key on a USB fob. Tell the user to put it on the keyring with his car keys so that he’s not tempted just to leave the USB stick plugged in to the laptop all the time.
Alternatively, I’d try the same thing with full-disk encryption, as long as I could make sure that it wasn’t tied in to the Windows login.
What I’d really like to do is put the user’s SSN on the USB fob as well, so that he’d have the proper motivation to protect it—but my boss is a fuddy-duddy and won’t let me do it. Drat.
But this is the only way I can think of to set things up in such a way that if I get a stolen laptop report, I can say to my management, with a clear conscience, that we not only had encryption installed, but that we did everything we could to make sure the user was actually using it.
Then again, I could be wrong. It’s been known to happen.
Posted by
shrdlu on Wednesday, July 19, 2006
(0)
Comments •
Permalink •
Don’t get me wrong: I get a lot of very useful perspectives, news and information from reading security blogs. But I’m starting to feel as if the high-level discussions slip a little too easily into platitudes and away from concrete solutions.
Take this frequently quoted gem from Avivah Litan at Gartner:
“A company with at least 10,000 accounts to protect can spend, in the first year, as little as $6 per customer account for just data encryption, or as much as $16 per customer account for data encryption, host-based intrusion prevention and strong security audits combined,” Litan said in an accompanying statement. “Compare [that] with an expenditure of at least $90 per customer account when data is compromised or exposed during a breach,” she added.
Everyone and his DOG picked up on this (there are 298 Google hits on it as of this writing), and even though a few people argued with the figures, nearly everyone is nodding sagely and saying that money spent on prevention is more cost-effective than money spent on recovery.
What I want to know is, who even knows how to count up security dollars in the REAL world?
Let’s say you run any kind of shop where you have a dedicated IT security group. You’re trying to identify your spending on security. Let’s even say for the sake of argument that everything that isn’t detection and response counts as prevention.
What do you count as spending on security prevention?
• capital spending and maintenance on antivirus, anti-spyware, filtering, scanning, and any other kind of “dedicated” security software
• capital spending and maintenance on the servers to run these (assuming they’re dedicated)
• capital spending and maintenance on firewalls, IDSes, and other dedicated security appliances
• salaries for your dedicated security personnel
• identifiable security training
But that’s not all. Do you count these costs, too?
• spam filtering software
• log consolidation/processing software and hardware
• man-hours spent on installing upgrades and patches
• man-hours for awareness activities and training (for the trainees as well as the trainer), including training and support for encryption software
• man-hours spent on application security, including design and code reviews and QA testing
• man-hours spent on account administration
• man-hours spent responding to audits
• man-hours spent on business continuity planning and testing
• man-hours spent on asset tracking and disk sanitation
• legal fees for figuring out which OS security settings count as SOX compliance
This is all still “prevention,” remember. Can anyone REALLY demonstrate to me that incurring all these costs, and doing it right, would have been cheaper than the VA’s costs in responding to one unpredictable security incident? Because if anyone can tell me the VA’s true security spend on prevention, I’ll eat my copy of Quarterman’s book.
Yes, the VA hit the jackpot. They had to send out 26 million letters. The postage was probably more expensive than encryption software would have been. But that’s not a typical case, and just about everybody knows it.
Don’t be tempted to confuse “spending on prevention” with “insurance.” Insurance is what you buy to help you recover when your prevention fails. Insurers will not insure you unless they’re satisfied that you’re already spending enough on prevention. It’s not the same thing.
So don’t tell me what to spend unless you can tell me exactly what to spend it on. Don’t tell me to encrypt all my sensitive email unless you can explain to me how to encrypt mail to millions of external customers without buying them software, making them learn it, and managing millions of keys. Don’t tell me to stop using Social Security numbers unless you can tell me what to use instead when all the organizations I have to get data from are still using them as unique identifiers.
We need fewer Punditry Platitudes and more actual solutions. Avivah, thanks for nothing: you’ve done nothing to solve my problems except hand my bosses a paragraph that they’re going to wave at me and expect me to explain to them. Tell me instead how the hell you calculated that “per customer account” spend and how I calculate that for MY organization.
Meanwhile, I’m going back down to the Accounting department with a notepad and some thumbscrews.
Posted by
shrdlu on Friday, July 14, 2006
(0)
Comments •
Permalink •
I’m always on the lookout for new twists to put on my security awareness campaigns. After all, how many times can you say, “Don’t open the freakin’ spam attachment or I’ll send Sgt. Smackdown over to disconnect you with extreme prejudice”?
Thank heavens for the Advertising Slogan Generator!
The best one so far:
I Wish They All Could Be Security Girls.
(Although I admit that I also like That’s Handy, Harry! Stick It In The Security.)
Posted by
shrdlu on Sunday, July 02, 2006
(0)
Comments •
Permalink •
I hadn’t even heard about the sabotage of UBS PaineWebber’s systems until recently. The ongoing trial is fascinating, especially since it centers around the use of this simple little thing:
According to InformationWeek’s reporting, which you can find here, here, here, and here, the evidence for the prosecution consists mainly of these items:
- They found two copies of the code on the defendant’s computers, and one on his bedroom dresser.
- The defendant, who was ticked off that his annual bonus came up $15,000 short that year, went out and bought $23,000 worth of put options just before the logic bomb went off, the vast majority of them betting against his employer.
The desperation of the defense is entertaining to see: they’re reduced to complaining that the first company UBS hired for the investigation, @Stake, had former black hats in it; that the Secret Service made the images of the disks they seized at their field office instead of in the house; and that there was a single latent, mystery fingerprint on the piece of paper with the bomb code.
Now, obviously this defendant was himself a time bomb waiting to go off. He fits the classic profile of an insider threat. He was having money problems, he was an older IT employee, and was probably showing signs of narcissism:
A sense of entitlement, associated with the narcissistic personality, refers to the belief that one is special and owed corresponding recognition, privilege or exceptions from normal expectations. This sense of “specialness” is often associated with a self perception of gifts or talents which are unrecognized by others. The perception that this specialness is not being recognized by authority figures often combines with a pre-existing anger at authority to produce feelings in these individuals that they have been treated unjustly and are entitled to compensation or revenge. Often, this sense of entitlement is supported by special arrangements or exceptions to rules granted to highly valued but “temperamental” MIS employees. Thus employers actually reinforce this belief, up the ante, and contribute to what often becomes an inevitable crisis. The current shortage of information technology personnel may also influence feelings of entitlement among older information technology employees, who may resent special treatment and bonuses paid to new hires.
(bold emphasis mine)
The worst thing you can do is to make special exceptions for bad behavior on the part of a system administrator or privileged programmer. Not only is it not necessary—there are plenty of technical people who are just as good who don’t have the emotional maturity of a three-year-old—and not only does it hurt morale in other parts of the organization, but it can lead to reinforcing that bad behavior, as shown above. System administrators and security professionals should be held to a higher standard, not a lower one.
How do you protect against an insider threat like that? Well, first, by acknowledging that it exists, and making plans for it. In fact, if you try to implement additional separation of control and monitoring, you’ll be able to pick out the potential problem children by seeing which ones object to it. Real sysadmins aren’t threatened by separation of powers; they welcome it because it’s an additional layer of protection for them. If anyone insists that they’re above being watched, if they vehemently defend their right to be trusted (i.e. special)—watch them more carefully.
Many people would try to defend against this sort of attack by approaching it from the vulnerability standpoint. They’d claim that using host-based monitoring or Tripwire would have reduced the likelihood of this little file being pushed out to so many servers. (It wouldn’t have. There’s no way you can monitor and investigate every time a sysadmin does an rdist to thousands of machines.)
This is a classic case where you have to manage the threat, not the vulnerabilities. For one thing, you can’t possibly think of all the vulnerabilities and eliminate them. And when your threat is also a trusted element, everything is a vulnerability. All your defenses have to be threat-centric.
(Of course, as Schneier points out, this principle applies to quite a few bigger problems, too.)
Yes, UBS will have a lot of work to do to make sure this sort of thing doesn’t happen in the future. I hope they’re spending their security money in the right place.
UPDATE: Duronio was found guilty. And yes, it appears he was angry.
Posted by
shrdlu on Monday, June 26, 2006
(0)
Comments •
Permalink •
