Any time you’re evaluating or designing a system, you have to take into account the ability for things to go horribly wrong.
Now, this is pretty obvious when you’re building a bridge, but for some reason, nobody expects security analysts to be thinking this way. I guess it’s because people on the outside think we’re all about stopping 3v1L H4X0rz, and that security stops there. If they think any further than that, they expect that we’re all about stopping naive users from writing their passwords on Post-It notes (which is also a depressingly frequent part of the job, don’t get me wrong).
So developers get confused when I point out potential failure points in their applications. Either they say, “But who would DO that?” or, “Don’t worry, our users aren’t smart enough to try that.” My Clue Bricks are showing signs of heavy wear; I think they’ll FAIL before the need for them has dissipated.
For example, I’m just picturing my next conversation with a virtualization engineer, where I’m planning to tell him how I want my virtualized instances of a certain critical division handled:
“Oh, and you can’t use VMotion on these.”
“WHAT?? Why not? VMotion will allow us to provide fault tolerance by moving things around!”
“Take a look here. We’ll have eight instances, four primary and four backup, right?”
“Right.”
“Well, you’re going to put each primary and its associated backup on separate VM hosts, right? They’re never going to be on the same ones.”
[Blank look.]
“Because one of the great new things introduced by virtualization is grouping previously separate instances under a SINGLE POINT OF FAILURE.”
[Blank look.]
“If your hypervisor takes a dump, or if the VM host hardware fails, everything on that box is going down together. So I don’t ever want to see a primary and its backup on the same box. Since there are only eight servers, you’re not going to have more than two VM hosts, so there will be no need to migrate anything around except in an emergency. Now, for performance reasons, if the backups aren’t busy, you may want to have two backups on each box with two primaries, so that the primaries can suck up the resources. But you’re not going to do any fancy switching on the fly. So no VMotion.”
“But ... what if both of them go down?”
“In that case, you can move them manually. I want you to be thinking about it; I want you to be careful and deliberate. Besides, these servers are classified differently from all the others and I don’t want any of them to ACCIDENTALLY reappear on some other host with a different policy setting.”
“What’s wrong with that? We can isolate them from each other using policy rules; that’s what this nifty management software is for.”
“Rules can be fubared. Software can be hacked. There’s no substitute for a physical gap when you’re really serious about separation.”
Now, at this point, I expect the engineer to get this sullen look on his face as if I’m telling him that I expect him and his whole admin staff to be stupid. (From what I’ve seen, many of them are only barely IN the drawer with the sharp things.) But that’s not the point: I expect them to be HUMAN. When you have more moving parts, you have more opportunity for FAIL, and that’s why you disable any of them that you don’t absolutely need. Simplify, simplify, simplify. Just because something comes with a nifty new feature, it doesn’t mean you have to use it.
Actually, that’s why virtualization makes me nervous, in a nutshell. It allows you to shoot yourself in the foot faster, with more efficiency and automation. “Dammit, where did that VM go??” “Oh, I thought you wanted that one retired, so I took it offline.” “Well, where is it archived?” “Um, let me see ...” “Hey, who set up this instance called ‘ursopwn3d’?”
Take another example. People keep going on about how DLP is only really good for “stopping stupid.” Well, maybe that’s only as good as it’s ever going to get. And that’s okay; maybe anything that interferes with a business process by design can’t do much prevention when the only differences between malice and stupidity are, well, intent and cleverness.
Human error can and should be prevented wherever possible. Same with stupidity. But in the case of malice, you probably have to lean more on the side of detection instead.
STUPIDITY : MALICE :: FAIL : PWN. Remember this for your Security Aptitude Test, grassh0pper.
Posted by
shrdlu on Sunday, June 29, 2008
(0)
Comments •
Permalink •
Every once in a while I get a request that drives me crazy. It’s usually in the form of, “X group needs to be secure, tell them what to do.”
And you know that “tell them what to do” doesn’t mean “perform an audit, engage a pentester, give them a list of findings, create a security management program for them, and put it all in writing.” It means “put a couple of lines in our contract with them” or “talk to one of their reps for half an hour on the phone.” You can’t tell them to “comply with all our policies,” because then you have to list all of them (including the ones that aren’t written down), and before you know it, you have a book that they don’t want.
So I was thinking: how do YOU sum up “how to be secure” as briefly as possible?
Here’s what I have it boiled down to:
1. Have control over your systems.
2. Check your security frequently.
3. Educate all your people.
Number one expands to maintaining an accurate inventory of your systems; having a process in place to manage and update them consistently; making sure your users aren’t messing them up; making sure nobody is adding unmanaged systems or software; and have policies and processes for access control and system administration.
Number two expands to monitoring, auditing, certification, pentesting, and performing risk assessments against the current trends.
Number three means training users, support people, developers, AND all executives. It includes educating your security people so that they know what they’re supposed to be doing.
I think if you cover these three points, you’ll have a pretty good security program and have most of the bases covered. What do you think?
Posted by
shrdlu on Thursday, June 12, 2008
(5)
Comments •
Permalink •
Executives spend too much time listening to the lawyers’ point of view.
Just because something is legal, doesn’t mean it’s right to do it.
And just because the law doesn’t compel you to do something, it doesn’t mean you shouldn’t do it.
Thank you.
This mini-rant brought to you by the letters A, Q and X, and by the number §.
Posted by
shrdlu on Monday, June 09, 2008
(2)
Comments •
Permalink •
Things like this, that’s why.
And not just because he puts me in mind of songs:
(and yes, I can make references closer to this century)
but because his questions can’t be answered in a short comment.
When he asks, “What are you managing towards?” and gives some good examples of answers, my first impulse is to combine one or more of them and say something like:
“I’m managing towards just enough control strength to let luck take over.”
That’s dipping into Good-Enough-Securityland, where “good enough” is measured as “whatever keeps us from shooting ourselves in the foot.” This doesn’t sound at all noble, I know, and it’s not all cool like Andrew and the Metrics or even our Bayesian Homeboys, but to be real honest, my management doesn’t want to get to that level of elegance. They just want me to keep their names out of the papers, do the right thing by our customers, and tell them how much they should spend to achieve that.
I make it a point to remind them from time to time that we’re doing pretty well on the prevention and detection fronts, but that nobody is going to be able to stop a targeted attack. They’re reasonable folks; they understand this. They understand that you can’t control a threat, especially one that’s external. What I’m doing is working to prevent opportunistic attacks, and making sure we’re doing enough due diligence that a reasonable person would feel that our legal backsides are covered.
Managing to compliance is almost irrelevant to our security landscape. That would be like managing your accounting to compliance. Yes, you want to make sure you’re following the rules, but you sure wouldn’t manage your finances with the end goal of passing an audit. In fact, if you asked any CFO if he were “managing towards compliance,” he’d probably look at you funny.
Schneier’s extremely depressing and extremely true essay on why it’s so hard to sell security says it all. My bosses don’t want to get to “best” or “100% compliant.” They want to do better than the competition, but not radically so if it means incurring too much “loss” in the form of paying for security; they want to feel confident that they have done the best they can to put in reasonable controls. And then they want to forget about it and go about their real business.
Once a year, I write a report (oh, 40 to 60 pages’ worth) on what my section has been doing and what else I think we need to do to stay at “good enough.” And then my senior management sits down with me and we have a discussion to update what we think “good enough” means for us. If they want metrics to help them narrow in on “good enough,” they’re in the report. I tell them what I’m doing with their money, and if possible, I compare it to what our peers are doing. It’s one big “state of the union” talk, and it only lasts long enough for them to grok it, and then we’re done.
They get to spend the rest of the year feeling lucky.
Posted by
shrdlu on Tuesday, June 03, 2008
(6)
Comments •
Permalink •
I’ve been spending a lot of time mentally on vacation, but Rybolov keeps dragging me out of it, damn his zombie-lovin’ eyes.
Here are some security titles I’d really like to see:
Risk Management on $2 a Day
Build Your Own UTM Appliance Out of Kitchen Tiles and Vacuum Tubes
Faking FISMA
Sister Mary Malware’s Corporal Punishment For Naughty Users
Security Metrics: Size Really Does Count
Gauntlet’s Greatest Hits: All the Rules in One Collection, 1996 - 2001
Why All the Good Security Tools Sound Like Drugs
GRC Porn: Confessions of a CISA
Posted by
shrdlu on Monday, June 02, 2008
(1)
Comments •
Permalink •
Why should you audit your security folks?
Note that this is different from an audit of your organization’s security; I’m talking about auditing the folks who do the securing.
Besides the whole quis custodiet thing, there are other reasons why it’s a good idea: if you’re running your security program as a business, as many people say you should, you need to audit your business.
- Are the security staff being effectively utilized?
- Are they keeping proper records and documenting important processes?
- Are they maintaining a proper separation of duties themselves?
- Are they abusing their überpowers (assuming they have any)? Are they only monitoring within documented and approved limits?
- Are they properly negotiating and managing contracts?
- Are they making the right purchases and managing their budget properly?
- Are they enforcing policies equally and fairly?
- Does the security program cover all appropriate areas, and is it being diligently applied?
- Are they securing their own information?
- In other words, are you getting the right value for the money you’re spending on those people?
Remember, there is just as much potential for fraud, waste and abuse within a security group as there is anywhere else—perhaps more, because they’re typically in a trusted position. So audit not, lest ye be audited!
Posted by
shrdlu on Friday, May 23, 2008
(1)
Comments •
Permalink •
In all the initiatives I’ve rolled out in my (checkered) career, the ones that have gotten the most acclaim from my management have always been the ones that were most visible to the users. They turned out to be popular if they:
- were used directly by the users
- allowed the users to do something better, or faster, or better AND more securely
- helped reduce the risk of a legal problem
Never mind that we might have done something much more impressive with the firewalls, or monitoring, or something “under the covers.” It might as well have been plumbing. I could have gone to them and said, “We’ve replaced everything with the finest tubing and we won’t have any more leaks for 20 years,” they would have said, “Oh. Fine. Next?”
This is just to point out that not all “security impacts” are equal. We may spend a lot of time Fighting the Good Fight to secure against cross-site scripting, for example, but it’s often seen as much more valuable if it secures the way people are using data. In the eyes of the business—the ultimate risk decision maker—the more it affects/helps the users, the bigger the win. So from a practical point of view, they’re using a very different set of risk factors than we are from behind our consoles and our dashboards.
Which set is “correct,” which view provides the best understanding of the actual security risk, may never be determined. But an ISO’s job is to try to understand and reconcile the two as far as possible.
Posted by
shrdlu on Thursday, May 22, 2008
(2)
Comments •
Permalink •
I’m sure you’ve had one of those days where you can’t bring yourself to do anything useful.
But have you ever noticed that if you’re leaning over your keyboard with your elbows on the desk and your head in your hands, and are staring numbly at the keyboard from the right distance away, and unfocus your eyes, the keys start floating like one of those Magic Eye stereograms?
I think I’ll go dig up our team’s Policy Enforcer and go have some fun.
Posted by
shrdlu on Friday, May 16, 2008
(3)
Comments •
Permalink •
Was talking with an incredibly smart friend of mine this morning, and as usual, he revved my brain into high gear and it stayed that way even after we hung up the phone.
I never could get what the deal was with GRC, and why it is supposed to be so new and hot and different from just plain compliance-with-a-dashboard. I think it’s because from what I’ve been able to grasp, the only “R” in GRC is the Risk of Not Being Compliant. And as we know, that’s only a small part of everyone’s risk factors.
Compliance is external. It’s commoditized and standardized, by design. It’s very close to being the opposite of risk management rather than just being a subset. Even when the compliance is mostly a matter of interpretation in the technical world, you’re chasing a binary answer: Are you compliant or not? And the authoritative answer will always be someone else’s, not your own. No wonder executives chafe at it and wish it would go away. They’re not going to embrace it lovingly in the form of an expensive reporting product. They really don’t care about someone else’s opinion all that much; they want to get back to making their own risk decisions.
By contract, risk is personal. It’s variable as hell. It “governs” what you spend your money on, and therefore, with or without a dashboard, your CEO is already doing risk assessment every time she decides what your security budget is going to be. Will you really be able to change her mind by showing her the dashboard and saying, “But—but—the needle is pointing to RED!” when you’re sitting there with your line items in your fiscal shopping cart?
As Rothman and others have pointed out, either you have C-cred or you don’t. Either you support your management in making their decisions, or you end up fighting them. And in decision support, it’s their questions that matter. You need to find out what those are and then choose the right instrumentation to help you answer them. (YOU, not your boss. If he wants to play with the tools himself, he doesn’t trust your answers.) He will decide how “compliant” he wants to be, based upon his other business and financial factors. And if you’re going to help him make risk decisions, the more you can help him calculate risk for the other factors besides compliance, the more valuable you will be overall.
One more thing: you will be appreciated more when you can identify the low risk as well as the high risk. Every time you can say, “I think we can get by with this solution, and here’s why,” you’ll make another (sometimes astonished) friend. Don’t bring in a GRC product and use it as a FUD machine. If you can’t use it to identify opportunities* as well as threats, it’s of very little use to you.
Remember, we’re supposed to be enablers. We’re supposed to be a service organization. (If these statements surprise you ... Sekurity—UR doin it Rong.)
*No, I do NOT mean “opportunities for security vendors to make more money.”
Posted by
shrdlu on Thursday, May 15, 2008
(6)
Comments •
Permalink •
You know, when I’m in a meeting with a big group of people and I say something and suddenly there’s this long, silent pause, I can never tell whether it means I just said something really stupid, or whether it means I said something so brilliant that it took everyone’s breath away, or I said something so confusing/obscure that it just went straight over everyone’s heads.
I really should try to figure it out sometime, especially if it’s the first option.
Posted by
shrdlu on Tuesday, May 13, 2008
(2)
Comments •
Permalink •
[Ed. note: Happy blogoversary to me! Time flies when you’re posting ... and especially when you’re not.]
Someday you, too, may be privileged to be able to design a username schema for your system, and I hope you’ll have your safety equipment to hand. There are few activities more contentious than naming something.
Let’s take a look at a few of the aspects you should consider when choosing the format of a username.
- Frequency of use. How often is your typical user going to be logging in? How long are you going to keep that account around? Persistence + infrequent use = forgotten username = help desk call (unless you are satisfied with letting them click a link to get it mailed to them).
- Disambiguation. How are you going to tell your Robert Smiths apart if you let the real name be part of the username? You can add a randomly generated disambiguator, but then you risk user memory lapses again. You can add a disambiguator that the user will remember, but that usually turns out to be biographical data. Please don’t tell me it’ll be the last 4 of the SSN.
- Basis for usage. Why are you letting a user on your system to begin with? Is it inherent in their job? Are you making access decisions based on their position, location, relationship, or other? How often is that likely to change?
- Other identity attributes available. Are you going to try to be clever and overload the username with role or organizational information or some such? Try not to do this as a poor man’s sorting function. Data modelers will hate you and spit on your office chair.
- Need for respectability. Are you going to let your users pick any aspect of their username? Is it a problem if they pick “yourcompanysucks”?
- Will the username be immutable, technically or by policy? Will a user have to apply for a new account if something about the old one changes? How many help desk calls are you willing to support?
- Do you really think that obscuring the schema for the username will make attackers less likely to break in to your system? (Hint: if you choose anything other than a randomly generated string of characters for the username, it’ll end up being generated by an algorithm that is guessable. The security shouldn’t be in the username; it should be in the strength of the password. I hope my pentesters are reading this and will get off my frickin back.)
- Will you need to bulk generate or bulk upload new users? If this is the case, you’ll need to be able to generate and assign usernames automatically. Make sure your schema isn’t too complicated (let’s see, was that the first four of the last name? What about the twenty people named Li?).
- Do you have username length restrictions anywhere? Do you have the ability to create username aliases for an identity to interface with back office systems?
- Audit requirements. Will you need to keep retired accounts around for reporting purposes? I don’t recommend recycling usernames in any case.
- Will users need to have multiple accounts? If you just said no, think again. What about your developers and QA testers? Show me a developer who has fewer than 200 accounts associated with her name and I’ll show you a developer who isn’t earning her keep.
- Don’t even THINK about making the username case sensitive. Thank you.
I hope these little tips help you in your quest to create the perfect system. Good night, and good luck.
Posted by
shrdlu on Thursday, May 08, 2008
(3)
Comments •
Permalink •
I love to play with vendors.
I love to go to those thinly veiled marketing “seminars” where I eat the breakfast danishes, doodle on the notepads, and then stand up to ask ridiculous questions of the sales presenter. Once I actually got a networking guy to start making up stuff as he went along: I asked him if his router had built-in antivirus, and before I knew it, he had drawn up a whole new version of Unified Threat Management, complete with keylogging, database activity monitoring, and an executive dashboard. Too bad he was only selling WAPs.
But my favorite cat-and-mouse game is on the trade show floor, where I try to score all the neat schwag while leading on the booth babes. See, the really good schwag is stored under the table, behind the tablecloth, and they only pull it out if they think they’re gonna make a sale. So you have to go in dressed expensively, but without a tie. With a tie, you’re obviously another sales droid, maybe coming over to check out the competition. With the sharp suit, but without the tie, you look like the senior VP of something who is too important to care about making a good impression.
Whatever you do, DON’T wear one of those dorky Bluetooth earbuds. That’s a dead giveaway that you’re just a wannabe.
So I make a point of walking by the booth quickly, as though I’m about to meet someone equally important for lunch, and then let the display catch my eye. Reluctantly, I back up a few steps and cast my glance at the literature. I frown. By this point, the smell of the chum is almost unbearable and the sharks are circling; they can’t help themselves.
I rate the sales rep on the first line. “Can I help you?” is lame. “Are you concerned about threats to your [insert technical buzzword here]?” does a little better. “Say, didn’t I hear you speak on that panel at RSA?” is the best of all. Some cut to the chase and say, “Would you like a chance to win an iPod?” which is just shy of saying, “I’m dying for some leads here, please give me your business card.”
The trick is to keep them talking but keep your badge hidden, so they’re not really sure how important you are. “I think I bought this last year,” I say. “Oh no, wait, it wasn’t the IronBlade, it was the IronMaiden. Sorry, my mistake.” Spend a little time confusing them with their competition, and they’ll work even harder to see if they can woo you away. Talk about how you’re trying to expand your company’s security portfolio and improve your governance and compliance. Once you get the Most Important Sales Guy talking to you (he’s the one who was holding back, maybe talking on his cell phone, but still listening to the conversation), start mentioning the word “demo.” That’s usually enough to tip them over the edge, and they bring out the embroidered polo shirts or the neon-colored riding crops or whatever the really good schwag is. Score!
That’s the point where I hand them the business card of an ex-coworker from my previous company and tell them to give me a call. I go dump the loot in my briefcase (extra large for this reason) and come back to hit the next victim. If you time this right—say, while everyone else is in the sessions and the vendors are really bored—you can empty them all out before the break.
Sometimes if the schwag pickings don’t look appealing, I go around being really obnoxious and handing out the business cards of each booth’s competitor, which I collected at the previous conference. This works best at large national conferences, where they’re sure not to remember you. With a bit of finesse, I can get them all pissed off at each other and watch them tripping each other up with the power cables on the floor. Once I started a price war by telling each of four competing companies that two of the other ones were undercutting them by over 30 percent. I won’t say that this ended up in a hostile takeover bid ... you can draw your own conclusions and I’ll deny them all.
And when I really, really want to torture a particular vendor, I’ll ask them to set up a pilot for me ... every two years or so. They usually don’t have the same sales staff by that time, so they’re hopeful all over again that they’ll make a sale. I have fun playing with the new improved console, break it, and then send the system back in a fit of pique until the next time. These days I get my kicks by asking every vendor to do a pilot for me ... under VMware. The contortions they go through to convince me that they can virtualize are truly better than what you see at the Cirque du Soleil in Vegas.
Hey, man, I’m just softening them up for you. It’s a dirty job, but somebody’s got to do it ... and even Mike Rowe has his limits.
Posted by
shrdlu on Monday, April 28, 2008
(3)
Comments •
Permalink •
Saw this blog posting this morning on BlogInfoSec.com:
Slashdot Post On Security Ethics Demonstrates Professional Naiveness[sic]
wherein Kenneth Belva takes a frustrated security professional to task:
I wish this anonymous reader put their name to the article. Their statement above demonstrates their complete lack of understanding of the security process within a corporate environment from a political perspective.
Well, in the first instance, Mr. Belva demonstrates professional ignorance of certain words (it’s “naïveté"), and in the second, claims to understand “the security process within a corporate environment” without acknowledging the fact that the issue here is risk, not necessarily politics.
Read the original posting again:
“I am a senior security xxx in a Fortune 300 company and I am very frustrated at what I see. I see our customers turn a blind eye to blatant security issues, in the name of the application or business requirements. I see our own senior officers reduce the risk ratings of internal findings, and even strong-arm 3rd party auditors/testers to reduce their risk ratings on the threat of losing our business. It’s truly sad that the fear of losing our jobs and the necessity of supporting our families comes first before the security of highly confidential information. All so executives can look good and make their bonuses? How should people start blowing the whistle on companies like this?”
You could easily read this as someone who is overstating risk, or someone who is stating it accurately. It all depends on where you’re standing. If you’re on the left, you see it as being too far to the right, and vice versa.
This just underscores the need for an objective dialogue on risk, and a common taxonomy for everyone to use. (No, I swear I’m not trolling for more links from Alex and Jack; I really do believe this.) Everyone knows the situation where an auditor writes you up for allowing SSL v2 or some such silliness, and you just want to shake them by the lapels and say, “Why do you think this is a serious risk? Why is this serious enough to write up?”
So this situation could go either way—they really could be strong-arming auditors into reducing risk ratings on objectively serious issues, OR they could be giving the auditors plausible reasons to reduce the risk ratings. This is why we need explicit, written risk assessments that are open to discussion.
UPDATE
Mr. Belva was kind enough to notify me of his response:
I became aware of a post on Layer8 accusing me of being “professionally ignorant.” Unfortunately this individual will not allow people to comment on the Layer8 site unless one registers. So here is my reply to this blogger:
=============
I believe that naïveté and naiveness are synonyms and are both nouns, which means they are interchangeable.
Dictionary.com:
http://dictionary.reference.com/browse/Naiveness
——-
naiveness
noun
lack of sophistication or worldliness [syn: naivete] [ant: mundaneness]
WordNet® 3.0, © 2006 by Princeton University.
——-
Here’s Princeton’s direct URL which basically states the same thing as dictionary.com:
http://wordnet.princeton.edu/perl/webwn?o2=&o0=1&o7;=&o5;=&o1=1&o6;=&o4;=&o3;=&s=naiveness&i=0&h=0#c
——-
Perhaps a second post with a retraction is in order for your slander against me in regards to my “professional ignorance.”
Sure thing, buddy—I’ll retract my sarcasm if you actually respond to the main point of the post instead of whingeing about “slander.”
(Weren’t you doing the same thing when you accused the Slashdot poster of a “complete lack of understanding” as well as “naiveness”?)
Posted by
shrdlu on Friday, April 18, 2008
(11)
Comments •
Permalink •
I am going to Black Hat,
I am going to Black Hat,
I am going to Black Hat,
And that means DEFCON too (yeah!).
As you might recall, I’ve been given the chance to go to one out-of-state conference this year. I finally decided on Black Hat, because it didn’t seem like a vendor pimpfest, I can get into DEFCON for the same price, and hell, I’ve never been to Vegas. I’ve never been the least bit tempted by gambling, but I sure do want to catch me some more live Penn & Teller (it’s been ... damn, nearly a decade).
So now I find myself pondering the essentials: which t-shirts to pack? Crackberry under the clothes, or in the fanny pack?
I’m actually a little worried that I’ll find the attendees at DEFCON annoying. I’m envisioning a bunch of self-proclaimed badass geeks who are really just young punks who don’t know the ‘net existed before 1992. Yes, this officially means I’m old. But nobody would mistake me for cool anyway. I can be frumpy anywhere, so it might as well be Vegas.
Oh, and I’m going to the Lone Star Information Security Forum again this year, which I’m very much looking forward to. This year I will try not to drive back from Dallas during Tornado Night.
* Did you parents know that Steve Burns came out with some pretty cool indie rock after he left Blue’s Clues? Check it out.
Posted by
shrdlu on Thursday, April 17, 2008
(7)
Comments •
Permalink •
Well, it’s RSA week, and the security blogosphere has been pretty quiet except for the “having-a-great-time-meeting-cool-people-wish-you-were-here-posted-from-my-iPhone” entries, so I thought I’d do my part to fill the void.
How to keep a darknet in your own data center:
1. Order and receive the equipment before your outsourcer arrives. Get it cabled in.
2. Have the outsourcer put asset tags on everything in the server room that doesn’t move. Make sure this is done by someone whose sole job is asset tagging, and the resulting report goes to some central manager who knows nothing about your systems.
3. On the one day of the year that the outsourcer runs the network discovery scan, turn the machines off.
5. Make sure that the outsourcer never gets around to reconciling the network scan with the asset tag inventory, or if they do, make sure it’s done by someone in the central office who doesn’t know your systems and who will assume that the asset tagger just made a mistake.
4. Have your head of networking be sympathetic to your cause and keep his mouth shut.
5. Have system administrators from the outsourcer who are so slammed with work that if it doesn’t have a ticket assigned to it and ain’t on fire, they aren’t going to notice its existence.
6. Own and run the IDS/firewall/logging yourself.
7. Configure the servers using only freeware so that additional procurements don’t show up on the books.
8. Party on.
Notice I haven’t put any names in here so that they didn’t have to be changed ...
Posted by
shrdlu on Thursday, April 10, 2008
(3)
Comments •
Permalink •
