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 •
Is that really the dichotomy? Or is it privacy versus security? Can you have liberty without privacy, or vice versa? Enough v-words.
One of my favorite security pundits always has a good point to make, and his take on the topic is no exception:
In security, we always say “The insider threat is responsible for 70% of all loss bearing security incidents” yet we rarely talk about effective ways to do anything about it. The reasons why are many:
- Keeping the bad guys out is heroic, making sure the good guys don’t do bad things is invasive
- The external bad guys are faceless and evil - the internal bad guys are our co-workers
- Most of what internal people do is good, by monitoring them to see if they are doing bad things we give up liberty and privacy in the name of security - Ben Franklin wouldn’t like that
- Information security groups believe they don’t have the charter to monitor employees without human resources and chief legal counsel involvement and approval - a lot of paperwork is involved.
So, because of the above we have employees putting Social Security Number databases on laptops and taking them home, we have child pornography being found on corporate servers, we see backdoor trojans on many, many laptops that lead to customer databases flying out the door and we see supposedly confidential financial information and intellectual property being accidentally or intentionally leaked by internal users.
I take exception with his last bullet point, though: of course we don’t have the charter to monitor individuals without HR and general counsel permission. And we shouldn’t cross the line of monitoring behaviors to the point where they can be tracked down to an individual without that same permission and real cause. But that doesn’t mean we can’t log everything and then get permission to examine it later. Any entity that is legally liable for the actions of its employees has the right—and the responsibility—to monitor for and prevent illegal activities. (This is different from the current NSA wiretapping fiasco, where they are not complying with existing legal restrictions on their monitoring. If I monitored my individual co-workers without getting the requisite signatures—on the form I created myself for that purpose—I would be fired faster than you can say “executive privilege.”)
Personally, I would rather prevent behaviors so that I don’t have to monitor for them. The old saying goes, “Trust but verify”; I’d rather verify so that there’s no question of trusting. It makes it easier to trust in an environment where you know that certain bad behaviors just aren’t possible. And since we all want to trust our co-workers, we’d better have those security measures in place so that we can go on about our jobs without worry.
It’s those sticky situations where you have to allow a behavior because sometimes it’s for a good reason that cause trouble. Then you have to spend a lot of time figuring out on a case-by-case basis which behaviors are legitimate and which are a breach of policy. Email is a good example of this; so is laptop usage.
In these cases, I’m not squeamish about monitoring. It’s my job to address all threats to my organization within the strictures of our policies, ethics and laws. And let me tell you, the VAST majority of my investigations involve insiders—and I’m not the one requesting them, either. It’s just an ugly fact of life that people misbehave on both sides of the fence, and when they’re on the inside they have the potential to cause more damage.
My management can take the public position that they care about their employees and will protect their privacy; that’s okay with me. I’m fine with being the bad cop they come to first thing in the morning and say, “Um, we need you to look at something.” I’ve set things up so that I’m held as accountable as possible: the logs of my privileged activities are kept on a server that I don’t have access to, and I have the reports from those logs delivered to my boss on a regular basis. I make sure that my ass is covered with as much paper as it takes, and I keep all my signed forms and documentation safely archived.
I sleep fine at night.
Posted by
shrdlu on Wednesday, May 31, 2006
(0)
Comments •
Permalink •
It’s just not enough these days to sit at a Starbucks and partake of the hot and cold running wireless. Noooo. Some people have to go the extra mile and toy with the carbon-based utilities as well:
However, there are other less exercised code paths that have significant input validation errors. My personal favorite is the “iced tea” overflow. Barristas are used to only two variables of input when taking an order for iced tea - “sweetened/unsweetened”, and “lemonade/no lemonade”.
If an order is given to an unpatched barrista containing extended variables, a buffer overflow occurs and the results of service delivery are extremely unpredictable.
I submit that the Starbucks help was probably thrown together in a hurry without much coding expertise. Back in the good old days, when programming was a slowly, carefully crafted art, the older food and retail service models embodied the default-deny posture. Which we all know is the best security measure anyway.
But now, dammit, I’m tempted to do a little probing at the local McD’s. All white hat, of course.
Posted by
shrdlu on Thursday, May 25, 2006
(0)
Comments •
Permalink •
Trying to plan out a security budget for the next fiscal year is bad enough; try planning it for THREE YEARS OUT. What are going to be the new threats and vulnerabilities appearing within that timeframe? Who the hell knows?
All I know is, part of my budget will be focused on operational compliance—making sure that what we have is, and stays properly configured—and part will be on researching and responding to whatever comes next.
I can only say for sure that it will probably involve buying new software and/or appliances. But putting an entry in an Excel spreadsheet that says “(Insert generic security appliance here) - $100,000” does not make anyone in my management chain happy.
So put on your psychic goggles with me for a minute, or dust off your crystal ball, or roll the silicon bones. What’s going to happen within the next three years?
As several people have pointed out, most notably Richard Bejtlich in this memorable blog entry, we may already have lost the battle for host security.
When intruders can completely control all aspects of a running system, there is almost no where else for defenders to go. The only places left are found in CPU microcode or outside the CPU itself, monitoring it via a hardware JTAG port as described in a recent Dr Dobbs Journal article.
If the desktop cannot be trusted then detection and prevention must be performed elsewhere, on a trusted platform outside of the intruder’s, and more importantly, user’s reaches. This can only be done at the network infrastructure. While the network will not yield as rich a collection of evidence about host exploitation, the data collected via network platforms bears a higher degree of trust.
From a separation of powers standpoint, this perspective has always made sense to me. If part of your job is to place checks on your own system administrators—and, in this brave new Unix and Windows world, the system operator account is a winner-take-all proposition—then the only thing you can do is to get the logs off those boxes as quickly as you can and move them someplace where your admins don’t have access. And the only thing you can count on is that you might be lucky and get that login event captured before the intruder or rogue sysadmin cuts off the flow entirely. (Yes, I know a really smart one would just keep it going and insert fake log events. But unless they have a canned set ready, I can’t see someone with nefarious goals being that patient and diligent.)
We may indeed have to retreat from the CPU. But we do have one remaining advantage: in this day and age, you can’t do anything useful without the network. A host is useless as a bot if you won’t let it talk to its controller.
So whatever I’m going to be buying in the next year or two, it’s probably going to be focused on two areas: monitoring and enforcement on the network, and monitoring and enforcement of application behavior.
(I hate to say “prevention,” because to my mind, our current understanding of “prevention” in IT security is only good until the next unanticipated event comes along. Either you’ll punch a hole in your prevention yourself, because you need to make an exception to your own rules, or something will come along that just takes advantage of the holes you’ve already made. When you think about it, every firewall you have is an exception to policy. You know you really ought not to have a network connection there, but you need to for business reasons, so you make an exception and say “just this once” with every “permit” you put in.)
We’re already working on smarter event consolidation and correlation, which is good. I think we’re going to have to get even smarter, though, and put filters at the ends of every tunnel, too. Whether this means an extra networking device that sits in front of every CPU and says, “Nope, you don’t get to SSL unless I know exactly what you’re doing in there,” or whether it means going back to default-deny proxies in front of every important service on your network, we’ll have to keep network, application and host-based security all separate from one another.
We may well have to cede ground in the security war, because our own users are often our worst enemies, even when they’re not unwitting accomplices of crackers. If we operate on the assumption that anything the user can control, can’t be trusted, then we’ll at least have a workable model for the territory we have left.
Come to think of it, we may just end up building a mainframe security model all over again, treating the host and the user as one entity and re-creating RACF on the network. Wow, how scary is THAT?? It makes you want to go cower in the shadow of that Excel spreadsheet.
So, back to the budget. About that team-building exercise in Bermuda ...
UPDATE: What he said.
Posted by
shrdlu on Friday, May 19, 2006
(2)
Comments •
Permalink •
Denial: Oh, the issue’s not that bad. They won’t bother writing that up.
Anger: What do you mean, they’re writing that up??
Bargaining: Look, we’re going to remediate it today ...
Depression: I can’t believe they wrote it up anyway.
Acceptance: *sigh* Okay, when does the next audit start?
(With apologies to Dr. Kübler-Ross)
Posted by
shrdlu on Tuesday, May 16, 2006
(0)
Comments •
Permalink •
I don’t think so.
It’s so nice to see the security realm maturing. It used to be all testosterone-laden chest-thumping (with the obligatory l33t speak). Nowadays, not only are teh girls playing too, but we can sit back and enjoy some truly creative bitchslapping.
(Did I mention that ze l33t speak is also sexier in French?)
Posted by
shrdlu on Friday, May 12, 2006
(0)
Comments •
Permalink •
As I tell our new employees over and over again, delete doesn’t work as well as you think it does. I tell them it’s safest just never to let the bits hit the disk or the network to begin with. But do they listen? Noooo. In true fallible human fashion, we all believe that somehow we are special exceptions to the laws of probability and nature.
So I spend time looking through mailboxes as a result of requested investigations. These people think they’re very clever by deleting their “sent items” and then emptying their trash. But what they don’t realize is that unless you know the SeKriT CoDe, Outlook actually keeps a restorable copy of your Deleted Items folder even after you think you’ve cleared it out.
Not only that, but your correspondents may do you in. You may have wiped all copies on your side, but in a lot of cases they haven’t. It only takes one copy of the correspondence to get what we need.
In addition, very few users have or know how to use DBAN. So with just a couple of forensics tools, we can easily get at deleted files on any hard drive. Again, a combination of human nature and what I call “psychological computer ergonomics” comes into play: users tend to think of their dedicated workstations as more private than they really are, considering that they’re on a network. When users want to squirrel something away, they will prefer to do it on the box that’s physically in their office, because they subconsciously believe that if it’s with them behind a closed door, it’s safe. So if you want to look for any suspicious files, you know just where to go: their workstation’s hard disk.
Personally, if I were really hellbent on saving and yet hiding some mail messages, I’d do it in a huge archive of other messages, which were carefully sorted and organized. When I get a request to pull files, it’s usually by a combination of date range and correspondent. A less thorough investigator who had to weed through dozens of megabytes of email, and who was trying to be careful not to read more than she needed to, might not bother to look at an “Accounting Projections 2001” folder if she was looking for personal email dated 2006.
Humans are pretty predictable, though. The same personality profile that believes everyone else but himself is to blame for his problems is the same one who will believe that he’s the special exception that won’t get caught. It usually trips them up sooner or later.
Posted by
shrdlu on Friday, May 12, 2006
(0)
Comments •
Permalink •
NIST just came out with their draft of SP 800-80 (do they tweak these numbers to make them look cool?), optimistically entitled Guide for Developing Performance Metrics for Information Security.
Their idea of metrics still covers mostly my metrics category number two, which is “due diligence.” They want you to keep track of what you said you were gonna do, how much of it you did, and how often you report on it.
They do include an interesting wrinkle, though, which is to track how many security incidents occur as a result of you not implementing your planned controls.
In other words, metrics are good for measuring how much you mess up, but not how successful you are. Unless your idea of success is the same as an auditor’s.
Compliance in security != success in security. It’s just the only thing you can measure and blame when you’re not successful.
Posted by
shrdlu on Tuesday, May 09, 2006
(0)
Comments •
Permalink •
(Imagine Peter Cook from The Princess Bride saying the title.)
Metwics is what bwings us togethaah today. That dweam wivvin a dweam ...
There’s just no satisfying way to measure how secure you are, or how well you’re doing your job as a secuwity pwofessional.
An executive asks me: “So, if you let me have this wireless access point, how insecure will we be?” (WAPs are today’s modems.)
And I have to say: “I dunno. Five? Red? What scale do you want? Should I draw it in the form of a graph?”
Yes, I know there are extremely sharp people who are valiantly trying to tackle this issue, and I wish I could be a fly on the wall at Metricon.
The way I see it, there are five (three, sir) main questions that I need metrics to be able to answer:
1) How well are we tackling the threats we know about? How much are we preventing?
2) Due diligence: How well am I covering all the various bases that a security officer is supposed to address? Am I expending the right amount of effort and attention on application security reviews, awareness, training, system configuration standards, business-enabling engineering, legal compliance, and monitoring and detection? Am I tackling the newest security issues at the right time—not too late, but not so early that they don’t matter yet to the organization?
3) How much value am I delivering for the money the organization spends on security? How can I justify the budget I’m requesting?
Number one is a pain in the butt to try to answer. You can talk about the attacks you actually see, and you can point to statistics from other similar organizations on what THEY saw, and you can even wave around a bunch of C-level magazine reports on the latest threat activities. But that doesn’t tell you anything about what didn’t happen just because nobody felt like trying it. The most popular n00b meTriC, antivirus software statistics, is completely useless. That’s only a reflection of how well your particular vendor is updating the signatures, how quickly you’re getting them (and if it’s automated updating, that isn’t even a reflection on you at all), and how many adolescent pukes are spending time trying to impress their buddies or Make Money Fa$t.
n00b meTriC number two is time to patch. Depending on your particular organization, that might just indicate how persuasive you are at getting the sysadmins to put in the patches, or even how homogeneous your systems are (because if some patches break some machines, your deployment is going to be spotty at best). Sure, it’s a key indicator for auditors, who want to see that you’re keeping up. But it’s not an indicator of how you, personally, as a security professional are doing your job. Shoveling patches these days is like shoveling coal.
n00b meTriC number three is bad passwords. Yes, it’s a way to measure your vulnerability, but let’s face it: you only need one bad password. It’s an unreasonable measure of protection. It’s more a measure of how your awareness program is working and whether you were able to configure your systems to enforce password quality (good luck on that mainframe). And the number of bad password attempts is just the number of bad typists.
The problem is, unless you’re a bank, you don’t really know for sure how big a target you are. And you don’t know how the landscape will change tomorrow if you become a bigger target. So you don’t actually know what you’re preventing, except for the bits you see stuck in your filters.
Number two is comparatively easier to tackle. You can point at the legal requirements, you can make lists of what you’re complying with, and you can collect data on what similar organizations are spending their time on, in what proportions. Assuming that you’re aiming for conformity, you can demonstrably get there, and prove to your bosses that you’re keeping up with the Joneses. Listing the things you’ve done is straightforward.
Number three ... well, you can try to fudge it and compare your spending with that of your peers. But it’s hard to make comparisons when your choices are between an incredibly expensive appliance and a bunch of open source software with three frazzled security analysts trying to put it all together. If you’re extremely lucky, you can actually show your executives that spending what you did saved your collective butts, as opposed to the poor schmo across the pond. Usually, though, you can’t tie spending to effectiveness, because you can’t prove what you prevented. In the best case, you can point to the losses you incurred and use a nice formula to show that they need to give you more money to prevent them next time. Let me know if your CFO buys that one.
When you’re trying to show that you’re doing a good job, I think the best you can do is to show that you know what you’re doing. You understand the business, you understand the network, you’ve thought about and written down what you need to do, and you can make a decent swipe at a risk analysis upon demand. You’re aware of what’s going on, and you understand your user base and what they’re likely to do. You know how to handle an investigation without making things worse. You’ve got information, and you know how to use it.
Good luck putting numbers or colors on it, though.
Posted by
shrdlu on Tuesday, May 09, 2006
(0)
Comments •
Permalink •
