While reading Brian Krebs’s latest article in the Washington Post, I came across a quote that just grabbed me:
In May, the magistrate overseeing the trial, Justice Peter Openshaw, interrupted the proceedings with a statement that observers said stunned prosecutors for the Crown. “The trouble is I don’t understand the language. I don’t really understand what a Web site is.”
Now, I’m not about to go on a rant about “how stupid can you be?” Not at all—I’m just trying to fathom what it must be like for someone to have grown up normal.
You see, it’s quotes like this that make me realize what an odd duck I am. I’ve been playing around with computers since the age of twelve, when I complained (unwisely) of being bored, and my father threw a Basic manual at me and told me to “go make the bell on the teletype ring.” I’ve been in the computer world ever since, so thoroughly that I have no idea what it’s like to view it from the outside. It’s as if I’ve been a fish in the ocean, coming face-to-face with someone from a desert who’d never seen a body of water.
What if ...? I wonder how very different my whole life would have been without the Internet. I certainly wouldn’t be in this field, with the spouse and family that I have. I might still be in my hometown, doing something completely different, or I might have ended up on the other side of the planet, scratching my head at this point and going, “Web what?”
Food for thought.
Posted by
shrdlu on Thursday, July 05, 2007
(2)
Comments •
Permalink •
Spaf, the source of many a bon mot, has done it again:
For years I (and many others) have been telling people in government that they need to set an example for the rest of the country when it comes to cyber security. It seems they’ve been listening, and we’ve been negligent. From now on, we need to stress that they need to set a good example.
Posted by
shrdlu on Wednesday, July 04, 2007
(1)
Comments •
Permalink •
Jack Jones’s wonderful discussion of loss events started out by defining an incident even more narrowly than I have, and I think he’s on the right track.
* How many of you have worked for an organization that suffered a security incident of some kind? (I have, and I suspect most if not all of you have experienced viruses/worms, system or data abuse and/or theft by employees, web defacements, etc.)
* In how many of these incidents was there the potential for significant loss/harm to the organization? (In my experience, many of the incidents have had the potential for significant harm.)
* How many of these incidents actually resulted in worst-case loss? (In my experience, none of them did – they didn’t even come close.)
I am all over Jack’s suggestion that we only count it as an incident if actual loss was incurred. But hang on a tick—let’s define “loss,” too, and as something more tangible than just “productivity loss incurred because someone had to stop and pay attention to this event.”
Let’s try defining loss as a loss of confidentiality, availability and/or integrity that resulted in the loss of significant productivity or actual revenue. If a virus blew up someone’s PC and he couldn’t get any work done until it was fixed, I’d call that an incident. But if it just had spyware on it, and he had happily been working with it for months without anyone noticing or caring, then it’s not a loss, even if we had to stop him from working for an hour while we cleaned it up. In this case, “significant” is whatever the management considers to be significant, and comes back to their decision on whether it’s worth pursuing or letting go. One company’s significant loss is another company’s annoyance.
This definition of “loss” gets tricky if you get into legal matters. Say an employee mails himself company intellectual property that he ought not to have. That’s a loss of confidentiality, all right, but has it caused any revenue loss? Potential revenue loss, perhaps—but then you’d have to prove harm in a court of law if you decided to prosecute anyway. If there’s a specific law broken by the loss of the C, I or A, then I guess you could consider that “harm,” but I’m getting on swampy ground and would need a lawyer’s help getting through that. (Mark Rasch, where are you?)
By this definition, is every breach of company policy an “incident”? Not by any means. It starts looking more incident-like if a senior manager takes enough offense at the breach to want to take disciplinary action. That can certainly cause a loss in (or at least diversion of) productivity to deal with. But I think Jack might agree with me that choosing to enforce policies is the cost of having them, i.e. the cost of doing business. When HR, Legal, Audit and Security take time to deal with the fallout of a breach, that’s what they’re there for; it’s a part of their job descriptions. It’s not a loss in and of itself, caused by an adverse event. It’s an extension of our controls system designed to prevent actual losses.
This definition, if it were widely accepted, would help draw a better line between the “hey, I was just looking” sort of security breach that the original hackers were accused of, and the organized crime sort of breach that is intended to cause actual loss (and presumably gain for themselves). Most laypeople never understood the difference anyway, since most of this activity takes place on a nonphysical, technical level that they can’t understand.
This is also why the privacy angle is so murky these days, and it’s hard to prosecute companies for the exposure of individuals’ private information unless actual monetary losses occurred (in the form of fraud or identity theft). Just because you feel someone Shouldn’t Be Looking doesn’t mean you’re incurring a loss. But I’m not ready to give up on the privacy fight. It’s just that I think we have a lot more to work out on the legal front.
Nevertheless, I think this new definition of “incident” will help us clear away a lot of cruft that has inflated our public statistics to the point where people don’t believe them any more. And it gives me a new direction for my risk management discussions. Thank you, Jack—and happy Fourth of July.
Posted by
shrdlu on Wednesday, July 04, 2007
(6)
Comments •
Permalink •
There’s a whole art to managing business-to-business connectivity, and it all comes to a head when your organization merges with another. This great article by Mike Chapple can get you started down that road.
Once the new letterhead stationery starts appearing in your stockroom and the domain names have been registered, it’s good to be proactive in managing the management. Myself, I always like to start with a “default deny” stance: start with no extra connectivity to the other network (other than what you already have over the Internet), and then start meeting with the business areas to find out explicitly what they do need. If you treat the other company as you would other sites on the Internet, you may be able to keep things down to a dull roar as you figure out what security the other side has in place. Mike’s advice not to rush is good: as long as the business can get what they need within a reasonable period of time, and there’s a known process that they can use, they often don’t care whether you still have firewalls between your networks a year from now. (You should probably have some access controls in place permanently anyway, but that’s another story.)
Negotiations on merging security policies take a lot more time. You may find out that the firewall is protecting them from you rather than the other way around if their policies are stricter than yours. If you stay on the technical level with your peers on the other side, you’ll probably avoid some of the nastier aspects of mergers, most of which are political in nature (get into the bunker while your senior management jockeys for position). Be creative about letting executives get access to data where they need it—and only give them as much as they need. Again, being proactive counts for a lot: if you come up quickly with a secure data-sharing model, they’re much more likely to follow it and thank you for being a business enabler.
No, I’m not going to help you with your struggle to come out as Top Dog CISO. That’ll take every ounce of business-sucking-up that you can muster, and I definitely don’t recommend breaking in to the other CISO’s email. I’ve heard that Sun Tzu at 40 paces works for some people, though.
Posted by
shrdlu on Tuesday, July 03, 2007
(0)
Comments •
Permalink •
I’m getting awfully tired of seeing this quote, so I think I’ll just respond to it right now:
... after all, wasn’t the Internet built on the founding principle of freedom of expression[?]
Uh, no. It was built on the founding principle of open-architecture communication. Your freedom to be a loud idiot didn’t enter into it. Thanks for playing.
Posted by
shrdlu on Monday, July 02, 2007
(4)
Comments •
Permalink •
If you could attend any one (and only one) security conference in a given year, which one would it be, and why?
I’ve been on a curtailed (okay, nonexistent) travel budget for a while, so I haven’t gotten to any of the major cons in several years. I don’t want a tarted-up version of a large trade show floor; I want a smart, fun conference that will give me the biggest, widest bang for my security management buck.
Any recommendations from the studio audience?
Posted by
shrdlu on Monday, July 02, 2007
(6)
Comments •
Permalink •
One little phrase in Mike Rothman’s Daily Incite made me snicker:
Security shorts are not clean. It seems many security products have security holes.
Made me think right away of underwear. And not only hole-y underwear, but with skidmarks too—because I know that every time I have to look at the innards of one of our applications, I want to sh*t myself ...
Posted by
shrdlu on Thursday, June 28, 2007
(0)
Comments •
Permalink •
Today’s rumination is brought to you courtesy of a metrics thought process gone out of control. We’re going to talk about just one topic, which is:
How do you compare your organization to someone else’s for the purpose of getting security metrics?
I see that executive sneaking in at the back, trying to get a ROSI number without anyone noticing. He wants to know whether he’s allocating his security resources as well as the CIO next door. Fine, let’s see what he’s trying to ask, and let’s dissect the questions.
- How do we find a comparable set of organizations to compare ourselves with?
We’ll throw a few stats at the wall and see how well they stick. For each one, we’ll ask:
1. Does this statistic tell us the same thing when we apply it to different organizations?
2. If not, what else do we need to know to make this number comparable and meaningful?
3. Why do we think this statistic will tell us something useful about security resource allocation?
Number of employees.
1. Do 500 employees here equal 500 employees there?
2. Maybe we think that 500 employees within the same industry are more comparable? If so, how?
3. Do we think that the number of employees correlates somehow with the difficulty of ensuring security?
Number of IT employees versus regular employees.
1. Is there some magic ratio that makes our organizations comparable if they match?
2. Does it matter what those IT employees are doing versus what the non-IT employees are doing? Again, does industry matter?
3. Does a higher ratio make security more or less challenging, or is it a non-sequitur?
Number of dedicated IT security employees.
1. Again, is there a magic ratio that works everywhere?
2. Does it matter what the IT security employees are doing, or does sheer headcount make a difference?
3. We’re assuming here that “dedicated” == “better at security.” Probably a safe assumption, but you never can tell.
Number of applications supported by the organization.
1. Does it matter whether the applications are being sold or just used internally?
2. What other information would we need to know about the applications to be able to compare real levels of security difficulty? How about number of legacy applications, funding for development and remediation, and whether the applications are tied to revenue generation?
3. The assumption is that the more applications you have, the more complex the environment you need to secure.
Number of networked hosts.
1. A host is a host from coast to coast?*
2. How about heterogeneity of hosts? Or number of sites (which may imply system and organizational complexity)?
3. This is a pretty straightforward assumption of security complexity right here.
Overall market capitalization.
1. Is capitalization the same across the world?
2. Does knowing the type of industry tell us more about the assets to be secured?
3. Does this say anything about the amount of money you should have available to spend on security? Or anything about what you should be spending on security to protect the assets represented by this capitalization?
IT budget.
1. Again, is an IT budget dollar the same at every organization?
2. Does it make a big difference what the IT dollars are being spent on?
3. Are we going to use the tired old “security budget as a percentage of IT budget” rule? What does this really tell us?
Are there some other/better ways to compare organizations in order to see how your security investment stacks up? And in the end, what do you really care what the dot.joneses are doing?
*A host is a host from coast to coast
And no one will talk to a host that’s close,
Unless the host (that isn’t close)
Is busy, hung or dead.
Posted by
shrdlu on Friday, June 22, 2007
(0)
Comments •
Permalink •
Once in a while a discussion comes up about enforcement—sure, we have all these policies, but how much are we expected to enforce them, and with what Louisville Slugger?
There’s a school of thought that says that in a relationship governed by a contract, whenever you find yourself having to refer to the contract, it’s a sign that the relationship is in trouble. I think that’s a pretty valid point. If you’re quoting the prenup at your spouse during the honeymoon, it’s a sign that either you or your spouse should RUN. If your employee is quoting HR rules at you, it’s a pretty good sign that they’re not going to work out. If you’re having to quote HR rules at your employee, ditto.
So yeah, we have security policies in writing, and sometimes they’re for awareness purposes (did you know you’re not supposed to install your own software? Now you know), but a lot of times they’re there as a last resort if you have to take what are known in the trade as Adverse Employment Actions. They’re Grounds For Getting Fired When There Were Plenty of Other Good Reasons For Firing You But This One Is Legally Defensible Because It’s Written Down. For the most part, they’re not enforced the way most people define the word, because you shouldn’t have to go that far.
My other favorite saying is Always Wait to Escalate. It’s better to start out slowly, and you can always kick things up a notch if the person in question chooses not to cooperate.
Sometimes a very light touch with the “enforcement” will produce the needed results. It’s often enough if I just call an employee into my office and say brightly, “Say! Can you explain to me what ‘anal violation’ means?” They turn beet red and stop downloading the pr0n to their laptop. Or I call them and say, “We’re seeing some strange traffic from your machine that looks to our IDS like P2P traffic. Could I send someone over there to have a look at it tomorrow?” They always say yes ... and if we find in the meantime that the traffic has mysteriously died down, it’s achieved the same end and it’s fine with me.
I do keep stronger measures on tap, of course, if someone really gets out of hand. We can slam the system door shut on them fast. (And I have a trigger-happy deputy who is just itching to take someone down, bodily.) But that really depends on their own behavior, and in most cases, they got all the way up to hysterical without any help from anyone else. In my experience, if you have someone who tends to blame everyone else for their problems, that’s the one who is most likely to launch an insider attack. The personality profile works pretty well as a threat indicator.
So I tend to use the blunt end of the policies as tools of awareness, and try not to use the sharp end unless I’m really going for the kill. This may be completely different from the way other security people use enforcement, but it works for me.
Posted by
shrdlu on Tuesday, June 19, 2007
(3)
Comments •
Permalink •
“What’s that smell?”
—my two-year-old
To my long-suffering staff:
Office gossip is a fact of life, but the rumors circulating lately have become disruptive enough that I feel I must address them in order to return the focus to our actual corporate mission. It has helped tremendously that our HR department has seen fit to emphasize our diversity policies, and that more organizations have taken up the awareness banner. It makes it easier to share with you some personal information.
Your suspicions are true: I am indeed a Necro-American.
This should not come as too much of a surprise to many of you who have had to sit in poorly-ventilated conference rooms with me. I apologize for the distress this may have caused, and I fully understand why I have not received any invitations to join any of you for lunch. It explains why I prefer to eat at my desk with the door closed, rather than take a lunch break, but I would like to point out that this behavior can be seen in many regular workaholics, and does not necessarily mean that anyone who doesn’t take a lunch break has the same ethnic background that I do.
There are many other ways in which I might have revealed my condition to you. The email messages coming often at 3 am: you’re right, I don’t sleep. My lack of fashion sense, alas, has been with me since well before my demise and subsequent resurrection. But now I expect you all understand why I argued so strenuously against the use of biometrics for two-factor authentication in our data center. (It was not because I was “receiving favors” from the RSA salespeople. I heard that rumor, too.) And those of you who know how to use Google probably figured out why my vanity license plate says “DRAUG.”
Let me reassure you on one very important point: yes, I hired you all for your brains, and yes, they are some of the very highest-quality brains to be found in our industry. But I have no intention of eating them; you are all truly valued for your contributions to our important work. As long as your performance evaluations continue to show stellar accomplishments, you have nothing to fear.
I would like to take this opportunity to thank you all once again for your support and hard work. I am very proud to be your ZISO.
Posted by
shrdlu on Wednesday, June 13, 2007
(3)
Comments •
Permalink •
To make it easier on all the security vendors out there, I’m now releasing my crescent fresh RFP Template. Now they’ll have a much easier time responding. And all you issuers of RFPs out there, feel free to borrow it too; it’ll save you time when you have to review the responses.
1. Vendor information: Brag here about how STuDLy your company is and how you’re the only and the best and you really know how to treat customers right. List some of your most impressive customers; the list should include something military (no matter if it’s the Waxahachie Department of Defense) and at least one bank (North American Regional Chartered Union Standard Bank and Trust, Ltd.).
2. FUD section: Talk here about how important security is and how you take it seriously. Throw out some wild and yet stale statistics about how many billions of dollars were lost because of some worm somewhere.
3. Management program: Copy and paste an entry from a Project Management 101 textbook here. Say it’s your own proprietary model.
4. Details of services: Copy and paste some other vendor’s marketing literature here.
5. Security risk model: You must include at least one Fortress Analogy and one Onion Analogy. Bonus points for any process graphic that is not circular.
6. Omissions: Leave out sections of the RFP that you didn’t feel like doing the homework for.
7. Qualifications: Refuse to give out any names of actual customer references or financial statements. Instead, include the resumes of your five employees, the minority relative you sold the business to in order to get HUB credits, and the project manager who actually runs everything and keeps possession of the cell phone.
8. Throw more verbiage at me: Include reams of photocopies of the user guides for whatever products you’re trying to rebrand as your own for your response. Expect that this will compensate for the fact that you didn’t actually write anything technical in the earlier sections.
9. Example service contract: Put in a sample statement of work and forget to redact the name of your last customer from it.
(Optional: Print the whole thing on some weird-ass textured stationery paper that bleeds onto my hands.)
Posted by
shrdlu on Saturday, June 09, 2007
(5)
Comments •
Permalink •
Just had to jot down a few reactions to Marc Andreessen’s personal productivity guide. Yes, this is a perfect example of his description of Structured Procrastination: I have a bulging inbox to get to (ooo, there’s another pr0n analogy!), but once in a while I allow myself to do something else beforehand as long as I keep it short. Kind of like sneaking in a doggie treat to keep myself going longer on the other stuff.
Structured Procrastination, though, sounds like it’s a new cool invention, when any compulsive multitasker will simply recognize it as something you do when you have an extremely long To Do list and can’t afford any downtime even when you want to procrastinate. If I hate making phone calls, I figure that the least I can do if I’m not making phone calls is to get something else done, like answering email. If I go through my priority list and can’t stand to do any of the top things, I work my way down the list until I find something I can stomach. If I can’t make myself do anything, I try at least to sit there and think something through, like writing a memo in my head that I’ll commit to bytes later.
The whole thing about refusing to schedule any meetings is hilarious. This works only if you’re so important that people will bow to your scheduling will, and you’re the only one they need to meet with. Must be nice. But if you’re like the rest of us poor working schmoes, who are just one cog in the productivity wheel and have to mesh with several other working parts in any given meeting, you don’t have the luxury of making them all bow to your lack of scheduling. And the alternative? “Let’s just meet now”? How well does that work when you get several meeting requests in a day? Isn’t that every bit as disruptive to your “flow” as answering the phone or reading email when it comes in?
Besides, as a manager, one of my big responsibilities is being available to my staff. If they need direction from me, or need me to influence someone else on their behalf, or need information from me, then it’s highly irresponsible of me to make them wait until I feel like talking to them (not to mention just plain rude). They need to plan their days, too.
There’s a much more sensible middle ground. This bit of advice comes from more than one columnist who’s had to help a person with a demanding parent who keeps wanting constant contact. The trick is to schedule regular times with them, so that they know when they can count on talking to you and you can feel better about putting off the demands in between. If you have a regular meeting scheduled, say, once a week, and someone brings you something that you know will take more time than you can afford right then, you can say, “Let’s talk about it at our next meeting.” They won’t get instant gratification, but they know when they can plan on getting it at all.
So block out times when people know they can book you. Or, conversely, block out time for yourself when people know they can’t interrupt you. It lets you have better control of your time without totally dissing everyone else on the planet.
Now, getting to the 3x5 cards. This is a problem I have all the time. My to-do items are in discrete chunks, as are the notes I take. I want to be able to move them around, toss out the ones I don’t need any more, and keep the other ones in sight. I’m reduced to Post-It notes, because those are the only things I can lay out in an overview, carry with me in a notebook, and rearrange at will. I hate flipping through pages of scratched-out lists to find the items that I haven’t gotten to yet; it’s a sure way for me to lose track of them. And rearranging electronic text isn’t as convenient, ergonomically speaking. I haven’t found a better solution yet, and 3x5 index cards seem both like a waste of paper inches (just to write down a phone number, for example) and are just, well, twee. They remind me of junior high school outlines and my college honors dissertation (which never got finished and is still buried in a large envelope somewhere, both the typed manuscript and the juvenile index cards).
The Anti-Todo List just wouldn’t work for me either. If I spent all that time writing down everything I did do, it would cut my actual productivity in half.
I work at a frenetic pace, most days. I don’t have time to leave Pandora running (much as I enjoy it), because it’s just one more noise source that I can’t pay attention to. In the one hour I had off from a training class today, I listened to all my voicemail messages, caught up on my unread email, answered a bit of it, ate lunch, and met with four different people (it’s amazing how many meetings you can pack into fifteen minutes when you don’t let anyone else talk 
).
And yes, now that I’ve taken all this time to compose this blog post, I’ve lost a lot of time that I could have spent doing work. But sometimes I’ve just got to shift gears to get my traction back.
Off I go!
Posted by
shrdlu on Friday, June 08, 2007
(2)
Comments •
Permalink •
How do you decide whether to give someone a login account? How do you decide which access(es) to provide?
Ask an account administrator in a small shop how he knew it was okay to do it, and the answer will generally be along the lines of, “The Right Person told me to do it.”
Okay, who is the Right Person, and how do you know who it is? How do you determine a replacement if that Right Person leaves?
Access is generally approved because the decision has been made that (1) the requester really needs the access to those resources, and (2) some owner of the resources is willing to allow it. I’m going to call these two aspects Validation and Authorization.
In some areas, these two decisions are made by the same person: the owner of the resources. This will generally be someone near the top of the organization in charge of those resources.
Sound incredibly obvious so far? Okay, let’s go deeper.
The administrator generally “just knows” who is the supposed owner of the resources, by virtue of the Right Person’s position in the organization. If there are different sets of resources in different departments, you’ll find the administrator choosing the appropriate department head, or the organization head over all of them, to get that authorization.
What if the organization or user base is so large that the Authorizer has no idea who the requester is, and therefore can’t do the Validation? That’s when you start breaking out those roles. You end up with two approval steps in the process. Someone has to Validate the user’s identity and need for access, and then the resource owner has to decide that the access being requested is appropriate, given the reason(s) supplied. When you’re using role-based access control, the Validator will recommend the role to be used, and the Authorizer will generally put together whatever he knows about the requester’s organization, the Validator, and other business rules to decide whether that’s the right role. If you’re automating the approval chain, these are generally the steps that get put in.
Wait! It gets more fun. The astute reader will have noticed that the Validator and Authorizer are both roles unto themselves. They can overlap. When the resources being accessed are financial, or have other legal constraints on them, you have to worry about situations where a Validator becomes an Authorizer for the same resource and can therefore (theoretically) both validate and authorize his own access to something. This is where auditors like to see the roles clearly separated, especially if the approval chain is automated. Separate roles + small department = headache for the security designer.
Now, the one place where this model usually collapses in a gooey mass is when you’re talking about privileged access, i.e. access for the person who runs the system containing the resources. Even if you have an ultra-L33T user enrollment workflow, chances are, when you hire new system administrators, you don’t use it to grant them access. It’s just sort of “understood” that of course a system administrator needs full access, and if he’s in that job, by definition he’s both validated and authorized. This happens a lot for the developers of the application, too, especially if they’re in charge of production support. (It also goes for the administrators running the user enrollment workflow application!) And this is where you’re most likely to get dinged by the auditor, because that’s the one place you’re least likely to have explicit, written policies and written approvals.
So do yourself a favor and write down a generic algorithm that works for your situation, using roles rather than names in the approval process. Then when Ms. Shoulderpads leaves as department head, your administrators know whom to tap as a replacement in the approval process. They have a better idea of who qualifies as the Right Person and who doesn’t, and why. They also know how to set up the system to avoid audit dings.
And while you’re at it, get rid of those shared administrator accounts!
Posted by
shrdlu on Saturday, June 02, 2007
(0)
Comments •
Permalink •
There’s a certain kind of smell I love: the smell of a new building, with the paint and the polished wood and new carpeting. It usually gets concentrated best in these small office parks where the buildings look like two-story cottages. It reminds me of the startups I used to be in. Ah, those were the days ...
Speaking only tangentially of startups, Chris Harrington makes a good point I’ve noticed myself. Not only do I have trouble differentiating vendors’ products, they have trouble differentiating themselves. I spent some time quizzing a SIEM vendor rep, and every time he said, “We’re the only ones who do X,” I’d sweetly name some other vendors who were also doing the same thing. Why aren’t they doing their homework and at least reading their competitors’ brochures?
Next up on This Old App: building generalized algorithms for user enrollment business rules.
UPDATE: Whatever Amrit’s on, I’ve got to make sure he gets more of it.
Nobody understands us, the executives seem to ignore security, the business owners want to focus on profits or other nonsense completely irrelevant to the seasoned IT security professional, the users seem oblivious to the malware laden websites dripping with fresh bot-infected, backdoor, keyword snarfing doodoo, and some jackass from a fortune 100 tech firm has convinced upper management that driving a CMDB across an ITIL landscape will allow us to ride atop a mighty horse of SLA metric goodness to the forbidden city of IT nirvana where operational efficiencies coalesce with the zenith of perfect security – breath[e] it in friends!
I’m just trying to picture Andrew Jaquith jousting atop a “mighty horse of SLA metric goodness,” with Alex Hutton hauling in the powerful and terrifying FAIR Trebuchet.
Posted by
shrdlu on Thursday, May 31, 2007
(4)
Comments •
Permalink •
Boy howdy, you folks are busy out there! My number of “unique visitors” has tripled within the last two months. My suspicion is that most of the traffic is spammers and script kiddiez becoming aware of this site due to more links from other, more popular blogs. But I still appreciate the small, deeply disturbed following that shows up here on a regular basis.
This month’s top search terms had a lot more security in it: the usual variations on “layers of hell,” “encryption,” “security metrics,” and “pentest.” But here are some of the Other ones:
ranum jaquith
Sounds like a cool consulting firm, a mathematical model, or maybe a serious alcoholic drink.
liechtenstein trivia
This is just way cool.
link all. slippery people
Ooookay.
tef control strength and probable loss magnitude
Alex, this one’s for you! People actually do search on these things!
In the WTF??? category:
chevrolet
nigel huffens
julie hagerty
mazda
crasking nail
In the Double WTF??? category:
porn
I mean, how many other Google hits do you have to wade through before you follow one to MY site???
And this month’s winner: TWO (count ‘em, 2) hits on
flamingo poop
Thank you all for playing, and see you next month!
*It’s not out of the realm of possibility that someone’s doing this on purpose. After all, I used to send messages to a sysadmin friend of mine by logging in repeatedly to his ftp server as “anonymous” and putting my message in as the password. I knew he read his logs religiously, you see ...
Posted by
shrdlu on Wednesday, May 30, 2007
(2)
Comments •
Permalink •
