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 •
This just in from the VERT Daily Post:
We’ve had a “responsible disclosure” debate in the vulnerability research community for a whole lot of years - the point is simply that, while disclosure forces everyone to be responsible, sometimes, you can have too much of a good thing.
The recent VA compromise is a great example. The analyst whose laptop was stolen obviously potentially compromised a large amount of personal data. However, the average domestic laptop theft isn’t a targeted act - the purpose isn’t to steal data, but to steal a laptop. However, with the amount of disclosure that happened in this case, it’s a safe bet that, if the thieves didn’t know what they had stolen (and the value of the data on the laptop), there’s no question that they do now.
We likely won’t ever know if the thieves stole the laptop for the sake of the laptop, or for the sake of the data. But, if the disclosure had been a little more discreet, it’s at least possible that they wouldn’t have known what they stole.
Come on, does anyone really believe this? Any disclosure that involves sending out 26.5 million letters can in no way be discreet, any more than I can be a little bit pregnant. (I can’t, not when I’m throwing up my toenails.)
The only way disclosure can be discreet (i.e. controlled) is in the case of a vulnerability that is being communicated by the one who found it to the one who wrote it and presumably can fix it. And it’s discreet only because the disclosure doesn’t include any of the potential victims of the vulnerability, which is why there’s so much Sturm und Drang about “responsible disclosure.“ To whom are you being responsible?
Even if you’re excluding those potentially affected by a vulnerability, the disclosure can still get out if you have to notify a lot of people just to address it. Being responsible with disclosure means recognizing the fact that humans don’t keep secrets very well. Being responsible means taking this into account and making contingency plans. It means mitigating as much risk as you can even while you’re disclosing.
And it means acknowledging that there are just some vulnerabilities that are never going to be kept secret. That our society doesn’t WANT to be kept secret. Hence, the new disclosure laws. We have decided that the potential victims of a certain kind of vulnerability are not better served by not being informed. If there are ANY steps that they can take on their own to mitigate their personal risk, they deserve the chance to do so.
The response to a laptop data loss should always include a good faith disclosure and remediation plan. If you have no control over the disclosure, then you need to work extra hard at repairing the breach of trust, and you’d better do it fast. I believe that companies will, in the end, be judged more by their incident response than by their prevention. I’m not saying that’s right or fair; I’m just saying that’s the way it is.
Posted by
shrdlu on Monday, June 19, 2006
(0)
Comments •
Permalink •
Found this multi-step nightmare via The VERT Daily Post.
Now, it would be both easy and fun to turn this into another episode of MS bashing, but really, let’s think about this for a moment. Microsoft is trying to do mutually exclusive things: they are trying to make a system that is infinitely powerful and configurable—moreover, infinitely configurable by the typical user (aka my mother)—and at the same time protect that system from the ravages of said user and the virus-writing vermin that take advantage of that user.
It’s much easier to secure a system when you have a knowledgeable system administrator in charge of it and the user has to take what you give them. When the user has to be able to configure it directly, mmm, notsomuch. We have a nation of personal computers maintained (assuming they’re maintained at all) by a nation of minimally tech-savvy teenagers, tired sandwich generation baby boomers, and the occasional Geek Squadette. Not a good recipe for security.
Take the Mac. They were doing fine when it was a simple user interface and you couldn’t do a whole lot to get under the hood. But add the erstwhile NeXTstep OS on top of it (I guess Jobs had to try to re-use it somewhere after the black boxes tanked in the market), and you’ve suddenly got too many moving—and vulnerable—parts in it.
We need a stripped-down client, the equivalent of a rotary dial phone, for those users who still aren’t even really clear on the concept of the scroll bar. Everything needs to be pre-configured for them and immutable. It should get them from point A to point B and that’s it. It won’t protect them from phishing, of course, and other social engineering scams, but at least it will protect them from having their own user powers used against them.
In commercial areas where you have system administrators and some kind of central control, you can customize the stripped-down client that you deploy. For private users, maybe the way to go is to offer a centralized, dependable system administration service, complete with help desk and routine maintenance. If you could sign up with a bonded PC “service” that managed and controlled everything on your desktop, from the applications to the home area network and the Internet connectivity, then you’d be in much better shape. We have a lot of little consulting outfits offering parts of it already, but it doesn’t go nearly far enough to become an effective, trusted household name.
Once we got there, we could entertain an even more radical thought: maybe we should start fining those users who allow their computers to be taken over in a way that causes damage to others and the network. They could hand over the responsibility and liability to a third party, or they could keep it themselves, but someone would be liable. As Schneier always says, you’ve got to put the externalities in the right place.
Once users were made liable, they’d start demanding better security of MS and other vendors. They might even accept less control over their PCs if it meant less liability for them.
Just a thought ...
Posted by
shrdlu on Friday, June 16, 2006
(0)
Comments •
Permalink •
I just got a chance to listen to the Silver Bullet Security podcast with Gary McGraw and Dan Geer. I normally don’t get time to listen to podcasts, because I’m too interrupt-driven, both at work and at home (“Mooooommm ... the mainframe’s relaying spam again!“ “Dammit, who’s been ‘troubleshooting’ the firewall? Get ‘em on the phone!“). But this week my most disruptive children are off at training, so I can take a spare 20 minutes to listen and concentrate.
I’ve met Dan in passing a few times (including at a lovely whisky BOF ages ago); we travel in some of the same circles even if mine are at a distinctly lower altitude. He talked in the podcast about how this is a great time to be in IT security, since it’s transitioning from an entirely IT-sourced field to one in which people are moving in from other diverse fields. (I can vouch for this myself, having been a liberal arts major with no computer science background whatsoever.) According to Dan, now is the magic moment in which the IT security executives don’t yet come from specialized IT security education backgrounds. I think that’s true; security is becoming a trade, now that you can actually get degrees in it. People who are hiring will start looking for these certified tradesmen rather than taking a chance on a “renaissance (wo)man.“ (You can see signs of this already, in that not having a CISSP will sometimes get your résumé tossed right off the bat.)
But I think the renaissance factor is more than just the fact that information security itself wasn’t a broadband academic field until recently. I think it’s part and parcel of the whole growth of the Internet and the people who built it—their distinct renaissance personalities.
The stereotype of the nerd who only understands science, or numbers, is a myth. The most creative and driven people who built everything the Internet rests on today have always been renaissance people. Sure, a lot of them came up from the technical ranks (even if they were as far afield as biostatistics), but they were so much more. These people not only write operating systems; they build gazebos out of satellite dishes. They learn origami and hieroglyphics. They retire to the coast and spend their days sailing. They spin their own thread. They raise hogs, for crying out loud. 
So yes, the Arpanet started out distributed for a military reason, but I believe the rest of distributed computing and networking grew the way it did because of the open and unconventional personalities of the people who built it.
Example: Dan talked about how at MIT long ago they published all the root passwords to make it less impressive (and therefore less attractive) for people to break in to their systems. (Of course, at the same time Richard Stallman was leaving all his accounts open for the world to use too, to the point where “to rms into a system” was a common term.) I really don’t think that’s a solution that anything other than an academic, freethinker culture would have come up with. These same people are still fighting for openness, diversity and neutrality today, the open source movement being the most visible example. It’s a culture thang that happens to be conjoined with the technology.
What makes it a Perfect Storm is, of course, the fact that it’s carrying our information along with it. Dan talked about the value of information itself increasing more than the value of the technical assets that are carrying it. I’m not sure the value of the information itself is increasing, unless you consider the risk of loss to add value to something.
Companies have ALWAYS had this information that is at the center of attention today. It’s nothing new. The only difference is, information technology has made it infinitely more portable, infinitely more copyable and infinitely more malleable. Information wasn’t considered an asset unless it was at high risk of being stolen, and you just couldn’t steal fifty boxes of paper files wholesale the way you can sneeze and copy a database today. Not only that, but if someone stole the boxes, you’d notice right away. If someone wanted to alter business figures, it would take laborious work and a ton of wite-out—not, as Dan mentioned in passing, a well-written and subtle virus.
We have turned our information into water, and we haven’t figured out yet the best way of holding it. THAT’S why it’s become an asset class all its own.
And the corollary to that is that contrary to some popular beliefs, information does NOT want to be free. There has always been information that needs to remain private, that represents hard work and intellectual property, that people rely upon for accuracy and completeness. That’s why leakiness is a big operational problem.
It’s going to take creative people to solve this. That’s why I’m glad we have the people that we do in this field.
Posted by
shrdlu on Tuesday, June 13, 2006
(0)
Comments •
Permalink •
