I have found the Metrics Prophet for our times, and his name is Andrew Jaquith.
I stumbled home yesterday from work, sleep-deprived, jittery, and feverish from an oncoming cold. I tucked myself into bed, hoping to sleep—but I could not sleep until I had read Security Metrics cover to cover. It was That Good.
Now, either that makes me the biggest saddo anorak west of the Pond, or it means Jaquith is an extraordinary writer about what would otherwise be an extremely dull subject. I would of course prefer to think it’s the latter, and I’m sure he would too.
First off, his writing is chock full of playfulness and amusing literacy, from the literary nods (“Call me Analyst.“) to the rimshots (“... the top and bottom 50% are divided by—wait for it—the median!“).
Secondly, his metrics are for the most part accessible, meaning that as soon as I see them, I think, “Yeah, I could get those!“ And a whole lot of them are ones I’d already thought of, but there are a few gems in there that were like little Altoids in my mouth, that made me sit up and go, “Whoa.“
For example:
- Tracking the number of change control exemptions, including by business unit—to identify the “cowboys” in the organization.
- Correlation of password strength with training latency
- Cycle time to deprovision users, by system type
- “Toxicity rate” (I love this concept) of customer data and ratio to all other data
His section on analysis techniques is also well-written, but I think he misses another reason to avoid some instances of taking the average or median of data instead of focusing on the outliers. The reason to avoid averages is this: humans don’t think that way. And by “think,“ I mean using that funny combination of flawed psychology and intuition to make risk decisions. When an executive is making a decision on security, she doesn’t give an auditor’s ass what the average number of incidents is across the country, or the industry. She only cares about numbers that can indicate what she might expect for her organization. Give someone an average and he will immediately try to apply it to his own situation, either by going into denial (“I’m sure we’re below the average”) or overestimating the risk (“That means it’s sure to happen to us.“).
So I think it’s important to know when to avoid averages and medians in analysis when there is a good reason to believe that your decision-maker will try to apply those numbers to calculate probability for risk assessment. And if your purpose in showing a median is to lead in to discussing the outliers, for heaven’s sake, just go straight to the outliers; don’t make him do the math in his head while he’s looking at a number on a page.
In his chapter on visualization techniques, Jaquith really does me a huge favor by giving loads of hints on how to bend Excel to my will. When I’m doing my annual security risk management report, by far the largest time-sink is just plain trying to get the numbers and charts to say the right things. His “rules” on making things easier on the eyes are great—although I would tweak him about not following his own rule about previewing the charts in black and white first; his Figure 6-14 is well-nigh unreadable on the printed page.
One thing I do know for sure after having read this chapter:
I’ll never get a Treemap Chart; I never hope to see one.
And I can tell you this right now: I’d rather die than make one.
Another side note: I’m sorry, but Figure 7-2, the “Logical Model of IT Security Controls (Level 2),“ makes me think immediately of the Hamster Maze of Pain.
However, Figure 7-4, “Metrics Sources in the Data Center,“ should be printed out as a wallet card and laminated. Boy howdy, is that one useful.
The final chapter on designing security scorecards is good, but I will probably never make it as far as a Balanced Security Scorecard. I will probably spend the next several years just trying to automate the collection of my key metrics.
And that final chapter just stopped short and dumped me off the end of the book, without so much as a fare-thee-well Final Overall Summary. It just stopped, and without another word, put on its clothes and went home, and I was left staring at the Index. But I’ll get over the disappointment.
One other thing, though: I was terribly gratified and relieved to read that I’m not the only one who doesn’t think “asset value” can be practically calculated. All the risk-assessments-in-a-box I have seen have started off with an inventory and asset value, and hell, how am I supposed to compute the asset value of a firewall? In terms of its hardware cost? In terms of business loss if it’s a single point of failure? In terms of the criticality of data it passes or blocks?
In short, I still have some burning questions, but they’re the good kind: they’re the kind you’re left with after a stimulating barstool conversation with a very smart partner. My overall enlightenment level has been raised, and that is a very fine thing indeed.
Posted by
shrdlu on Saturday, April 14, 2007
(4)
Comments •
Permalink •
When an exploit comes out based on some vector or user activity, pundits are all over it and saying, “Duh! Well, just don’t DO that!“
Dudes. If it were that easy to stop, we’d have stopped it already. We can’t just strip all .gif files at the gateway willy-nilly. And password-protected zip files are often the poor man’s “encryption” for email. Would you like to explain to a few hundred non-technical business partners how to download and use AxCrypt as an alternative? Would you like to buy them a real encryption product? Would you like to explain to hundreds of internal users why they suddenly can’t get legitimate attachments from external correspondents?
I didn’t think so.
I’m taking your pragmatic armchairs away for a time-out now.
UPDATE: Mike Rothman gets all bombastic on my ass about how there are “no excuses” for not just stripping .zips at the gateway. (He also seems really to care about my chromosome allocation; I suppose he can’t decide whether to patronize me or buy me a beer.) Come on, Mike, I thought you were all about pragmatism.
There are a lot of workarounds to getting secure information from one location to another. They are not all overly technical and hard to use.
Great. Give me a practical solution, right now, as to how to get around the lack of available mail encryption. AxCrypt classes for hundreds of external business partners? Tell them all to send us password-protected CDs in the mail? And how do you deal with correspondents who HAVE to zip up their 10-meg files just so they don’t melt down their ISP dialup connection? (They still exist, y’know.) Seriously, when was the last time you actually had to implement a quick solution in a real-world environment where things were NOT perfect and getting a new solution in required not only hours of your time, but hours of everyone else’s?
It ain’t excuses, son, it’s reality. Give me a workable solution, and I’ll be glad to implement it. Don’t give me the security equivalent of “just say no.“
Posted by
shrdlu on Friday, April 13, 2007
(1)
Comments •
Permalink •
Dear Vendors:
Just so you know, if you draw up a contract with me, I will insist on the following:
Remediation of existing security vulnerabilities is considered to be maintenance, not enhancement or new functionality.
Let’s not have any misunderstandings here. If you write bugs into your code, I don’t care how long it is before they’re discovered or exploited; they were there from the beginning and you need to fix them. At your expense, not mine. Just because nobody ever mentioned security before doesn’t mean it’s “new functionality.“ Having a secure product is not an “enhancement.“ We will treat security vulnerabilities just like we would treat any other flaw in your software.
Also, you are responsible for testing your code for security vulnerabilities just as you are responsible for any other types of QA (unit testing, load testing, whatever). It’s tempting to rely on my team to do all the security testing for you, because hey, we’re better at it, but that doesn’t absolve you of your responsibility to give us a quality product. Get some security expertise of your own and get to work.
This has been a public service announcement from Annoyed ISOs International.
Posted by
shrdlu on Friday, April 13, 2007
(0)
Comments •
Permalink •
Dan Morrill does a nice summation of what’s dangerous about RSS and ATOM feeds.
Really, this shouldn’t come as a surprise to anybody. I saw this coming ten years ago. Any time someone is pushing data to you, there’s the greater possibility that it will contain bad stuff. (Yes, some people can wait for you to pull it, but I suspect that most attackers want to initiate the transfer if they can.)
I think the only thing keeping this from being a worm vector is the fact that you can’t necessarily count on the recipient of an RSS bomb having anything in place to forward it on; one feed doesn’t necessarily go to another site with its own feed. I could see it being used to spread botnets, though. Compromise the site of a really popular blogger and you could hit a lot of people. (Come to think of it, I hope Bloglines takes its security seriously ...)
Okay, my fifteen-minute FUD break is over now. Back to work ...
Posted by
shrdlu on Wednesday, April 11, 2007
(0)
Comments •
Permalink •
I was thinking about Lieutenant Worf this morning.
Poor old Worf. He inherited his security job from a colleague who was killed by a slimeball (an actual one, not a metaphorical one). You never really got to see him doing anything security-like except practicing how to kill people. Now, I’m not saying that having a batleth mounted on my wall wouldn’t help in motivating some more compliance in people who visit my office; the handcuffs I’ve already got attached to my desk drawer do cause a few amusing double-takes. But that’s the very smallest portion of my job. And it was probably only a small part of Worf’s, too.
Come to think of it, IT security doesn’t really get good treatment in any kind of media. Especially Hollywood—you’ve either got bad guys and the macho security guys who do battle with them, or in the very rare case you have lovable, quirky, anarchistic hackers. (I do collect the latter, but not for the purposes of taking on The Man.) In any case, nothing I read about describes my actual job all that well. (Mike Rothman’s The Pragmatic CSO comes close, except that I don’t do the hokey AA meeting crap.)
My job is a balancing act, pure and simple. It’s a balancing act of risk, reward, enforcement, and manipulation. My job is to get my organization to follow its own rules. Secondarily, it’s to help my organization make good decisions in how to follow its own rules, when the way isn’t clear. I’ve already said that a lot of security is working out the exceptions to rules, and that’s where the risk assessment part comes in on a daily basis.
But unless you’re in the military or a similar environment, where you have any hope of issuing Commands to Be Followed, the rest of the job is a balancing act between being persuasive to people who don’t necessarily have to do what you say, and at the same time being firm enough to be able to push things through when it’s called for. That requires a heckuva lot of intuition and knowledge of psychology. My lovely and talented webmaster has said that I speak softly and carry an enormous stick; I suppose that’s true. But I’ve almost never had to lay hands on that stick, and if I did, I would consider myself to have failed in my primary mission, which is to convince people in my organization to Do the Right Thing.
Sometimes I cheat and wear them down by persistence; I’ll cop to that. But more often I just go to the right decision-maker and say, “Here’s what I understand our policy to be. If that’s the case, what do you want to do here?“ The decision-maker is the one to do the enforcing. When enforcement fails, I sometimes get called to gather the evidence for the disciplinary action, but that’s the extent of my role, no matter how much it might be whispered otherwise among people who generally aren’t in the room when this stuff goes down.
It’s all tightrope work. How to meet the legal requirement of informing people that you can and might be monitoring them at any time, for any reason, without rubbing their noses in it so that they feel like they’re living in a police state. How to reassure them that you don’t monitor without several levels of authorization and a lot of justification, without leading them to think that they have a legal expectation of privacy. How to explain to them that they just did something really stupid without making them defiant enough to want to do it again. How to pass the Responsibility Hand Grenade across the board room table, and get the other side to accept it. How to grant an exception to policy while making sure the door doesn’t get opened even wider next time. How and where to deploy resources and money to get the maximum value. How to pick which fires to put out, every hour of every day.
With the exception of the occasional virus infestation, which I treat more like a cockroach sighting than an Epic Battle (“dammit, who left food out on the counter again??“), I don’t have any Bad Guys to fight. There aren’t any Bad Guys. There are just us, the enemy within, and I spend much more of my time acting like Jiminy Cricket than Jack Bauer.
It’s probably just as well. His underwear would never fit me.
Posted by
shrdlu on Sunday, April 08, 2007
(0)
Comments •
Permalink •
The blogosphere is all over the latest saga of a victim of anonymous bullying on the ‘net, and there is the usual condemnation of anonymity.
All I can do is quote Eric Clapton: It’s in the way that you use it.
Clearly, the f***tards that have been posting death threats and disgusting photoshopped images deserve to be spanked vertically with a sixteen-inch spiked fencepost, splinters and all. But what they’re doing is nothing new. I’ve been on what is now called the Internet since 1984, and even in those days there was a small group of deeply disturbed sociopaths who reveled in this new tool for anonymous attacks. The only difference is, there are even more tools now, and a much wider world on the Web, so the proportion of psychos to decent people is more closely mirroring the rest of the population, and they don’t need help getting creative. Also, more “regular folks” are becoming celebrities, thanks to blogging, and they are suddenly thrust into the dark side problems that meatspace celebrities have always had to deal with—only without benefit of money or bodyguards. It freaks them out, and I can’t blame them.
New Internet users don’t understand the real implications of what they’re posting. I liken it to being on a stage, where the lights are in your eyes and you can’t see who’s in the audience. You can only see those people on stage with you—those who are also posting—and it’s easy to think that you’re the only ones in the room. You’re not. You have no idea who is coming and going from the audience and not saying a thing. Worse yet, the “show” is extended in time, so you don’t know who might come into the audience weeks, months or years later. Okay, my analogy is falling apart on me, so I’ll move on.
You start getting comments from other people, and maybe a few flattering links from other bloggers, and you feel great, and you think the whole world is friendly, because that’s all you see. But then the anonymous tomatoes start flying out of the darkness, and you’re bewildered, and there’s really nothing you can do.
Anonymity can clearly be used for evil. We pay more attention to that side of the duct tape, because that’s the horrifying part.
But anonymity can be used for good as well. I’ve used several noms de net in my time, and I’ve always been glad that I did. For one thing, it’s only fair for me to keep a separation between my writing and my employer, who didn’t ask to be associated with the non-professional me. I’m only allowed to speak for my employer in limited areas, and I make sure that I have authorization to do so. It wouldn’t do to have someone recognize me from alt.booger.stowage, connect that with my professional life, and have that taint my employer’s image, even tangentially. It’s my right to post about boogers, but I don’t have the right to let that affect my employer. It would be the same if I made newspaper headlines by going on a drunken rampage, for example. Luckily, I can have a semblance of a private life on the ‘net that isn’t a Google away from my professional life.
People have defended the other justifiable uses of anonymity, so I won’t go into them here. But I thought that I should point out that sometimes being anonymous is the responsible thing to do.
Posted by
shrdlu on Wednesday, April 04, 2007
(4)
Comments •
Permalink •
I’m a firm believer in the use of layer 8 mechanisms for controls, along with other layers. You may claim that users are unreliable, and that they’re the weakest link, but I think if you pick the right users, they can provide a service that nothing else can: escrow.
Let’s say that you have a security group separate from your IT operations group, and you want to implement a separation of powers. The elements you can use are:
- the power of one group to cut off access for the other one
- the power of one group to monitor the other one in a way that the second group can’t alter
- the power of selected passwords that only one group knows
Now, when you have sysadmins, there’s very little you can do to get around the fact that they hold the keys to the system kingdom, i.e. the administrative passwords. They can cut off anyone from a system, or an AD domain, at any time. However, you can set up a system that they don’t know the password to. As long as the sysadmins don’t also control the network infrastructure (that should be a separate group), you can set up a balance of power. If you get a copy of all the logs off the sysadmins’ boxes as soon as the events are generated, and send them to a receptacle that they don’t control, then at the very least you can detect activity when the stream stops.
But if your security group also has sooper powers, you end up with a kind of standoff situation. Either side can mess up the other, but mutually assured destruction doesn’t usually make the CIO feel any better. And you still have to monitor the security group for equal accountability.
First of all, I prefer to keep my sooper powers in a box: i.e. a separate login. My activities under that login are still visible to the sysadmins (they still have a copy of their own logs, remember), and they still control the systems that I work on, including my workstation. However, I do have an encrypted volume to which they do not have the key. Who has the key? The rest of my security group. Anyone can go ask them for it at any time, but being who they are, they won’t accept anything less than a clearly documented order from MY boss, or higher up. I’m still accountable to them.
Another example of escrow: you can base a key on information that a very separate group has, such as the facilities people who issue the badges, or human resources. You can always go get the information from them, but given their nature, they’re going to ask you, a person from an unrelated department, why you need it. You’ll have to have that documented good reason. Sometimes bureaucracy, organizational silos, and suspicion can be wielded as useful security controls.
If you spread out the pieces widely enough in an organization, the end effect is that only the common management—usually high up in the chain—can make use of the whole. This is bad when you’re trying to speed things up, but it’s very handy when you’re trying to slow things down. It ensures that nothing in the security arena will be misused by any one side.
Oh, and it also helps to have a deputy who has a suspicious streak a mile wide and is handy with zip-strips.
Posted by
shrdlu on Saturday, March 31, 2007
(2)
Comments •
Permalink •
What counts as being “influential” in the area of IT security punditry, anyway?
Being good at Not Letting Bad Things Happen doesn’t really land you in the top ranks of the influential. Being the Chief Speedbump on the Information Superhighway doesn’t endear you to people you work with, so I wouldn’t count that as positive influence either. I don’t have a large readership here, despite the best efforts of Alex.
But I have successfully executed a buffer overflow attack against two other bloggers, including the #16 Top Influencer in IT Security, so I guess that’s second-order influence, right there.
It would appear from the Top 59 List that being influential involves being part of the BlogClusterFoxtrot that is Security Blogging today. I read most of the bloggers on the list, but really only got to them because they all constantly refer to each other. So how do you move up in the ranks? By the number of trackbacks? Number of security blog memes that you start? The number of times you get quoted in mainstream media? Bruce Schneier probably wins on all counts.
The bloggers that have the greatest influence on me are the ones who teach me something new. That’s not too many, these days. I don’t care to read about the Sploit O’ the Day unless it comes packaged with a paradigm shift. I don’t care about who’s acquiring whom and for how much. To a certain extent, I’m interested in technical details IF I think they apply directly to me and my particular security challenges. I really don’t need to read someone’s ego-bloated ranting just for the sake of telling other ranters how wrong they are. But I do appreciate particularly elegant Security Snark[tm].
For those reasons, MY top influencers are, in no particular order:
Bruce Schneier
Marcus Ranum
Alex Hutton
The Matasano Gang
Ron Gula
Richard Bejtlich
Oh, there are other blogs on my blogroll, but these are the ones I consistently head to first, because they’re the ones that expand my horizons on a regular basis. Not that they’ll care, but thanks, guys.
Posted by
shrdlu on Wednesday, March 28, 2007
(5)
Comments •
Permalink •
If you’re going to have a pentest, you might as well lie back and enjoy it. Here are some fun things to try next time you have to open the kimono:
6. Port flashing. Randomly open and close access to ports while he’s doing his scans, so that when he comes back for a closer look later, they’ve changed. Bonus points if you can make it look like whole hosts are appearing and disappearing.
5. Tell him you have a whole class B to scan, even if you don’t. Make him figure out which IPs belong to you and which ones belong to the Department of Public Safety down the street. If he’s really good, he won’t tick off the wrong people.
4. Change the hostname on your most critical server to “honeypot.“
3. Have your lawyer deliver “cease and desist” letters to his house.
2. Let him get about 1/4 of the way through his initial scan, and then shun his IP address and call him up, saying, “Game over! I win!“
and the number one way to annoy your pentester:
1. Accidentally add an “is” to his job title.
Posted by
shrdlu on Tuesday, March 13, 2007
(11)
Comments •
Permalink •
Sometimes I envy my subordinates.
Back before I was a manager, it was a lot easier to socialize with my teammates. We’d have outrageous adventures together in whatever city we happened to be in (I remember an inebriated network guy sitting on top of a glass pyramid in one European town, spinning and saying, “Look, I’m a grapefruit!“), we’d have each other over to our houses, and just generally hang out together.
All that changes when you become someone’s boss. With management comes power, and with power comes ... well, fewer opportunities to have fun and more opportunities to have to be careful.
Some of the very best people I’ve known in my life have been work associates. And many of those were in a position relational to mine where purse strings were involved, so it made things awkward. Probably one of the worst times was when my husband went to work for a vendor with whom my company had a contract, for which I was one of the signatories. The vendor decided later on to start background checks, and my husband very reasonably pointed out that since background checks would involve his credit record, it would also involve MINE, and it wasn’t appropriate for a vendor to perform a credit check on one of their customers. There was no solution except for him to quit that job to avoid the conflict of interest.
But some of my favorite times in my life have been in the company of very smart people, laughing hysterically. This is what makes my work worthwhile. It’s not the pay (heaven knows), and it’s not the work itself, although that’s very interesting. No, it’s the opportunity to be with smart, talented people who have a great sense of humor (i.e. MY twisted sense of humor). Without getting too mawkish, I love these folks. I’ve spent the last 23 years or so in the company of computer geeks. They’re my tribe.
It’s a damned shame that so many of them now are people who report to me, or for whom I have some influence over paying, or for whom I could even potentially be a source of sales.
Nevertheless, I can enjoy a few moments of forgetting all that, when I’m riding in the back of a 37-year-old convertible with the top down, and the sun is shining, and I’m laughing so hard at a really obscure joke that I can’t catch my breath.
It makes the management resposibilities bearable.
Posted by
shrdlu on Saturday, March 10, 2007
(1)
Comments •
Permalink •
I found a folded letter on my desk today. It must have fallen out of my leather portfolio, which I’ve had for yonks.
It said:
Dear Registrant:
This letter confirms your registration for the 7th USENIX Security Symposium being held January 26-29, 1998 ...
You are registered as a Member for the following:
M3 - Certification: Identity, Trust and Empowerment
T2 - Network Security Profiles
And you know what? I don’t remember a damned thing from those classes.
Posted by
shrdlu on Thursday, February 15, 2007
(0)
Comments •
Permalink •
Dammit, Rothman set me off again. His notes from the RSA keynote highlighted several stabs in the dark at the evolution of access management:
At first they are focusing on the network, something near and dear to my heart. It needs to evolve. Right on. No one is going to rip and replace (except maybe for a greenfield location). The slide talks about a “trusted zone” and an “untrusted zone.“ IPSec is the technology they’ll use.
[...]
“Policy, not topology.“ Hmmm. That’s interesting, especially given mobility and the fact that most companies can’t assume they control the networks that their users will connect over.
[...]
They use IPv6, IPSec, and store everything in Active Directory. Individual policies based on USER, not where the user is.
[...]
Securing data at rest and motion. How? Rights management. Arghhh. The world is not ubiquitously Microsoft, so how does their flavor of rights management help me with that? Applications are also part of the equation. NSS (No Shit Sherlock). They “trust” the program and application? I don’t buy it. Applications can be broken, trojans and rootkits installed at the hardware level to complicate things. I don’t know I trust it.
This goes on and on. Here’s the way I see access management.
We don’t need user-centric access management or data-centric access management or network-centric access management. We don’t need “zones.“ We need CONTEXT-BASED access management. (You read it here first. I’m coining the term. Unless someone else has already; I haven’t bothered to Google it yet.)
Access policy decisions are a matrix. They’re based on:
- Who the user is proven to be.
Identification, authentication. We’ve been here before.
- Which organization the user is affiliated (officially) with.
This makes a big difference in access decisions. Internal employee, contractor, business parter, former-employee-now-part-time-consultant, the list goes on and on. This organization affiliation drives the decision on who APPROVES the access for this user, and sometimes the roles, but not always.
- Which hat the user is wearing currently.
Users have multiple roles. They might be affiliated with one organization but act on behalf of several different ones in the context of data access. This happens a lot more than you think, and it’s almost never properly acknowledged. The worst offender is the developer who has to create dozens of test accounts so that he can test it wearing different “hats.“ You’re probably thinking, “No, we support roles for users.“ Focus on the DEVELOPER. Which “role” have you given HIM? You gave him the highest level of access, right? Because the only account that gets to wear multiple hats and change context within the system is usually the administrator.
- Where the user is currently (geographically).
We make hidden assumptions about the security environment in which the user is operating based on whether they’re at home or in the office (or at Starbuck’s, or at their friend L33T H4X0R’s house, or whatever). We also make hidden assumptions about the platform the user is using based on their geographical location, which isn’t necessarily linked and needs to be split out:
- Which platform and tools the user is currently using.
Right about now, some reader out there is jumping up and down, screaming, “NAC! NAC!!“ Yes, this is where we talk about NAC, but not as a method of automated DoSing of your users. I would much rather use an SSL VPN policy and put a virtual condom around the user to protect him from his platform than just block the platform (and therefore all his access).
On a much higher level, there are two ways in which breaches can be detected. They appear as:
- An authorized user, coming in from the “wrong” location. (Usually referred to as an external attacker.)
- An authorized user in the “right” location, doing the “wrong” things. (Usually referred to as an insider.)
It’s all about context. And we need to make our context decisions more visible and flexible than we’re currently doing. Otherwise we’ll never truly get a handle on access management.
Posted by
shrdlu on Tuesday, February 06, 2007
(4)
Comments •
Permalink •
1. I loves me some Marcus Ranum. “There goes port 80. I told you that would happen.“
2. How to motivate users to lock their screens: force their desktop background to display their SSN.
Posted by
shrdlu on Friday, February 02, 2007
(1)
Comments •
Permalink •
Mike Rothman, normally a sharp guy, just blew it so hard in this quote that I had to drop what I was doing (all 25 things, actually) and rant about it.
So what? - This puff piece in ESJ about PGP isn’t worth too much. But it gives me an excuse to once again talk about STRATEGIC use of encryption. This idea of encrypting everything is stupid. There is a cost to encryption and it’s not just the cost of buying PGP (or your favorite other encryption vendor), there is a lot of management and performance overhead. So you encrypt what needs to be encrypted. Sensitive and private information. Intellectual property. You get the drift. But when thinking about encryption, start with the data and work outwards. Not the other way around.
In the words of a former colleague, “You don’t even know how wrong you are.“ Here are the problems with that platitude:
1. Not everyone in your organization knows for sure what constitutes “sensitive and private information.“
2. Even if they know, it’s probably not tagged and organized to the point where they know where all of it is.
3. You can’t keep it in one place.
Data is created all the time. It’s copied. It flows into every nook and cranny, with every email, every cut and paste, and every drag and drop. I dare you to show me any non-DoD installation where they can afford to encrypt ONLY the sensitive data and be sure they’re not missing anything.
The first question you ask when a laptop or tape or anything else goes missing is: “What was on it?“ And nine times out of ten, even the one who used it the most can’t tell you for sure. “Are you SURE there was no sensitive or private data on it?“ “Uh, pretty sure.“ Try saying that in front of your legal staff.
It is much, much easier to encrypt whatever your users touch so that they don’t have to ponder, with every file they create and every word they type, whether they should be putting it into a special volume somewhere. Hell, just try to get them to do record retention—good luck.
Users don’t want to be burdened with meta-thoughts about their data. They just want to get work done.
Adt that’s the truth-thpthbpthbpthbpthb.
Posted by
shrdlu on Thursday, February 01, 2007
(6)
Comments •
Permalink •
I’m procrastinating at the moment, putting off some forensic work that always depresses me when I have to do it. So let’s see what I can do to kill some time.
Investigations depress me. I hate to have to look through someone’s files, see what I have no business seeing, and put together the List of Files With Bad Stuff in them to hand over to someone else.
Pentests, on the other hand, are fun. Even when the point is to rule OUT any security problems, and you’re supposed to hope you don’t find any, it’s still disappointing if you don’t find something juicy. You’re going for the opposing team’s soccer goal, after all.
“Yep, boys, I think we’ve got us some telnet!“
“Aw, dang, it’s supposed to be there. Okay, keep looking ...“
“Oh, he’s found a DoS exploit ... he’s loading it into the proxy ... he’s kicking it off ... we’renotgettinganyresponsefromtheservercoulditbeyesitisPWWWWWWWWWWWWWWNNNN!!!!!!!“ (Goal dance ensues, flinging of jerseys, etc.)
I’ve got a copy of the Pragmatic CSO, but have no time to read it. (“We’ve alrrready got one, it’s verrry nice.“) Am I the only one who is appalled by the graphics? Those have been turning me off ever since they showed up on Rothman’s website. It looks like security meets the Sims, with a little bit of the Vienna Convention on Road Signs and Signals thrown in. I know I shouldn’t be judging the book by its cover, but jeez.
Does anyone have experience reverse-engineering a huge, complicated legacy application? I’ve got a heavy metal monster app to fix and don’t even know where to start. It talks to about 50 other apps (that we know of) in probably 50 different ways. I could make a case for scrapping it and starting over, but I can’t use the justification of “let’s trash it because we’ll never figure it out,“ and besides, about 100 developers and managers would come after me with torches and pitchforks.
Is ITIL dead? I have a feeling we’re about to find out, because if it’s one thing humongous outsourcers love today, it’s the methodology du jour. And why shouldn’t they? By the time we get it into my organization, it may reek and be wrapped in old newspapers. I’ll keep you posted.
Oh, and while I’m complaining: I hate playing mind-reading games with an auditor. Is he gonna like this solution? What are the secret woids to make him NOT write up a finding? It would probably be very helpful to our developers and sysadmins if they just had a copy of whatever checklists the auditor was going to use so that they knew in advance what they would have to supply.
Well, enough foot-dragging. Back to work. Do you suppose “hotchickwantsyou” is a business-related screen name? I didn’t think so either ...
Posted by
shrdlu on Tuesday, January 30, 2007
(1)
Comments •
Permalink •
