Slashdot Mirror
IT Turf Wars: the Most Common Feuds In Tech
snydeq writes "InfoWorld's Dan Tynan reports on the most common feuds in tech: turf wars in the IT department. 'IT pros do battle every day — with cyber attackers, stubborn hardware, buggy software, clueless users, and the endless demands of other departments within their organization. But few can compare to the conflicts raging within IT itself.' Dev vs. ops, staff vs. management — taking flak from fellow IT pros has become all too common in today's highly territorial IT organizations."
it's the best.
Disagree != mod troll.
the layer between which management absolves its direct interaction with developers, and through which a SOX policy completely devoid of any comprehension of the developer or her work is enforced.
Good people go to bed earlier.
Or is that just a California thing?
To quote Lincoln Spector and sung to the tune of the Jets song from West Side Story.
When you use DOS you use DOS all the way
From your first data loss 'til you format drive A:.
When you use DOS, why your confidence grows;
For your keys there's commands, for your mouse there's Windows.
It's DOS that's sublime; it's used by all go-getters.
At file-namin' time, we're never locked in fetters--
We choose eight letters.
When you use DOS, old hardware you can swap.
You can buy something new, next month prices will drop.
When you use DOS, why, you're never a stooge,
If your 640's low, well, there's always a cludge.
DOS users: On clones we can run, with brand-names we're the choosers.
The Macs'll buy none, cause all the Apple users
Are mouse abusers.
We're using DOS, yeah! and we're gonna fix
Every last system that's not something eighty-six--
Not something eighty, very weighty, six.
"Have you ever thought about just turning off the TV, sitting down with your kids, and hitting them?"
As Office Space so convincingly depicted it, loss of a precious stapler to another employee can have severe ramifications for the future of the business.
Luckly we have the equivalent of Sun Tzu's Art of War for the IT crowd.
B.O.F.H
Agent K: A *person* is smart. People are dumb, stupid, panicky animals, and you know it.
Your problem shows up in production only? That's too bad.
That's a really nice software release life cycle you've got there. It would be a shame if anything were to happen to it.
Obviously they've never read any of the BOFH tales...
Don't blame me, I voted for Kodos
shutdown -s -f -m \\theman
The network guys are never wrong. Nope. Doesn't happen. Must be something wrong with your servers. Can't be the 2k line ACLs we've put on each vlan to protect the windows machines. Nope. You don't need any ICMP protocols anyways. Why?? What do you need it for? There are no problems with the network. Don't believe me, look at my stats....
Alex, I'll take keybindings not used by Emacs for $400....
It seems like any time I try to write software correctly there is inevitably some retard who gets in my way.
Sometimes it's a senior (in years only) developer who created a "standard" before I got there. Other times it's a shitty outsourcing company in India that decided they would rather write a buggy version of asp.net (using asp.net no less) than let .net developers do things correctly.
When these lousy yet powerful developers get involved (and they always find a way), projects slow down and become buggier. At some point my manager asks why the projects take so long, and the senior developers attack is complete.
Where can I escape retarded senior developers???
are not technical, they are interpersonal. Cognitive intelligence is enough to get one started in this field, but gradually developing knowledge our one's own mind, how to work with others, develop a commitment to encouragement, and gaining a think skin are a must. A lot of IT jobs are a disaster. But you can still find peace in the middle of it if you develop the strength.
Years ago I quit my job web developing because a customer of my former employer was shady, and promising that the websites could do credit card sales, built in... at no additional charge. So when I quit my job over this kind of blatant lying, I was blacklisted by the former employer. A couple months later, their prized customer stiffed them in $15k worth of fees.
I phoned my former employer when I heard the news and gave her a bit of the "I told you so," except I was kind about it, and polite. It was apparent from her responses she felt sorry for blacklisting me, and sorry for not listening.
Sometimes the flak is warranted. Management: listen to your people or don't fucking hire them to begin with.
The dangers of knowledge trigger emotional distress in human beings.
BA who design applications v. BA who analyze problems. I constantly get documents from BAs that don't contain any requirements nor the business rules that govern the application. Instead, they give me screen designs and the flow of the application. No idea of what could go wrong or what is considered bad input.
DBAs always seem to want root for some reason or other... with apologies to A Few Good Men:
SysAdmin: You want the authority?
DBA: I think I'm entitled.
SysAdmin: You want the authority?!
DBA: I want the root!
SysAdmin: You can't handle the root!
What do you mean they cut the power? How can they cut the power, man? They're animals!
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive. get him to adopt it as his pet project and get it working on the Dev servers. now when he announces it Security cant do anything but say yes and do your bidding because they do not dare tell the Senior VP of marketing that they wont let his project run. Do I make enemies withing security? yup. Every one of them hated me because my default approach to them was an end run. And it was simply because the security guys were incapable of thought outside of the "lock it all down" OMG OMG! DANGER DANGER! WE got a iphone/ipod app launched for use in the company and made every one of the security guys froth at the mouth and fall on the floor convulsing when I end ran them to a VP who loved it and wanted every sales person to have it. They lost their mind at allowing 190 non company locked up iphones and ipods connected to the holy internal wifi.
Just wait when my ipad system for sales forecasting get's greenlighted and they have to allow 200+ ipads on it as well...
Do not look at laser with remaining good eye.
Have you tried no being a dick yet?
I have found not one, but two jobs where the entrenched administration chose Novell and refused to budge. I normally am pretty calm about using any tech, if it works then it works.
Novell, however, is a bloated piece of crap that no user should be forced to use. However, if it were the only game in town, then you're stuck with what you've got. It's not, however. It's not even the best at what it does. The only reason it's still in use is because there is a certain class of 'admin' out there that refuses to learn something new and update their skill set. So they instead drag the rest of their organization down with them in to the nightmare that is Novell software.
Mod me down with all of your hatred and your journey towards the dark side will be complete!
It's easy to point at other vendors, engineers, deployments, designs, et al and say that it went wrong because of them. But how much of that is an excuse made by midrange or flat outright incompetent personnel? Not everyone can be brilliant on the bell curve, and for everyone else, well, it's easier to blame others when the plan blows up.
Heh, must be nice to work for a tiny company that doesn't need to comply with things like SOX and PCI.
Also, if you did that to ME, I'd have a friend hack the company and make damn certain it was your end-running that responsible for the attack surface that was used.
Remember that the network switches / hubs / routers are part of "the network".
So when there REALLY is a problem on the network, the network admins usually hear about it because EVERYONE is having problems with ALL of their apps.
If one workstation or one server is having a problem (but the others are working) then it probably isn't a problem with "the network".
It may be that the network is not configured the way you'd like it to be for whatever you're trying to do ... but remember that the network admins have to keep the network configured to support all the OTHER items that were on it before yours.
At least be able to tell them what you want to do protocol-wise.
This is not a troll comment. This is the truth at my company. I am a software engineer, and every time I try to get the ops team to do anything for me it's like pulling teeth. I have had numerous fights with them because when I need to get access somewhere, I want it right that second, not 2 days later. The ops are never around during business hours, and every time I ask them to do work, they give me the dirtiest look because I'm interrupting their break.com video watching. System admins are a joke at my office.
If the IT department guys knew what they were doing they would be programmers. I don't care what they do I just don't want to help do their jobs for them. Oh yeah, and if you upgrade a server to a new OS because you have a wild hair up your ass, it's your responsibility to migrate the apps.
In this regard the iPad/iPhone is equivalent to kids driving around with motorized scooters on the freeway. It's exciting and easy to use. But completely incorrect tool for the job. iPads are consumer products without any security features worth mentioning.
I admit: my first reaction is that if I worked security at your company, I'd want to kick your ass. I mean, I like you, but they probably have a very valid point about not wanting untrusted apps popping up all over the place.
But my second reaction was that you're right. There's no valid reason why you can't have unsecured guests on the holy internal wifi. We have an open WLAN here at the office, but it's firewalled away from anything we actually care about, with exceptions on a case-by-case basis. You don't get open access to the database server just because you're connecting to our corporate wifi. If your security guys can't handle that, then, well, sucks to be them. Good for you for finding away to make people actually do their jobs.
Dewey, what part of this looks like authorities should be involved?
Any developer that writes an app that requires admin rights on the desktop should be beaten and stabbed. (yes, you should be able to disable auto-updating)
I see this all the time in government. Various IT departments will make it impossible or difficult for others to do work, but limiting access to various things, restricting software, no allowing for permissions, and refusing to take responsibility for a role or function that might enable any of those things.
ME: I would like to do X. I need to have access to Y in order to do X, may I have access please?
IT Dept: A) No you cannot do it, but we would happy to do it for an exorbitant sum, but we don't have capacity now, so you will have to wait 6months. B) We are not responsible for granting that access but please speak with RandomITDept (who will immediately say its not their responsibility, and refer you back), however we would happy to do it for an exorbitant sum, but we don't have capacity now, so you will have to wait 6months.
I understand the rational for limited access to certain things, but the sole purpose for most of this seems to be to secure work and thus positions for their particular IT department as well as the power base for those managers so that their staffing and budgets are justified.
Sigh.
Daily life around here.
Marketing wants what marketing wants. To hell if it has a positive cost/benefit ratio. "Nice and shiny and uses lots of Flash ... and runs on my iPhone ... drool"
Devs dev what marketing wants. Dev only wants to dev in production. As Administrator/root/qsecofr (or ALLOBJ).
IT Management, but especially Finance Magement skimp of every possible detail until they end up spending more time AND money patching it until it would have been cheaper to do it the way joint Ops/Securty said it would.
Ops/Security is handed a dogs breakfast of non-working, insecure code that produces amiguous, and often wrong results. Last to find out or provide input. But it's our fault when it doesn't work, or opens all security doors, or breaches laws in several countries. (The last ones to touch it must have broken it).
Classic way NOT to do it.
Q:I was listening to a CD in Grip and it sounded horrible! What's up? A:Perhaps you are listening to country music
Designing a wireless / wired network to support unsecured guests is a LOT different than designing one to support only secured guests.
AND it requires that all the PREVIOUS systems not have problems with the design.
The network admin has to support ALL the systems. Not just your pet.
What happens when the corporate database IS accessible from the corporate wifi because other apps need that access and those apps are run by people on wifi?
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive.
One of the best environments I ever worked security for allowed for senior managers to take personal responsibility for these kinds of decisions. The business unit would announce their Big Idea. InfoSec would look at it, analyze risks / security issues, and (often missing from many InfoSec groups) work out ways to allow the same functionality while mitigating any discovered risks, and ultimately document those risks. If the business unit didn't want to follow InfoSec's recommendations, they could take their Big Idea to their boss and make the business case for it so that their boss can take personal responsibility for the decision. InfoSec would provide the risk assessment. Senior management would then decide if the business case overcame the risk and everyone would press on accordingly. The process did wonders for enforcing open communication. Management wanted good information before they put their own butts on the line. Business units couldn't get away with just grousing or avoiding InfoSec and InfoSec couldn't get away with arbitrarily dismissing any new ideas. I should point out that this system is seeped in conflict. And that's good. Conflict is fundamental to security and, in many ways, any pursuit that has many options guided by creative thinking - something that all good IT environments should be encouraging. The key is to ensure that conflict can drive a constructive process. Too many IT environments pretend conflict doesn't exist and has no proper outlet for it.
The head of our systems branch used to always say, without irony, "The applications branch can't run without systems, but without the applications branch, systems run just fine."
To which the head of apps branch would mumble, "Yeah, and without customers Apps branch would run just fine."
i ~ Celebrating Science, Cyberspace, Speculation
I love how the article assumes organization within IT. Ops vs. Devs? We're lucky if management knows what to manage.
and kicking! I just wrote some code to do tracker desktop search from within emacs (using dbus and dired).
Got a great idea and want to get it past security without trouble? that's simple... simply get buy-in from a senior executive. get him to adopt it as his pet project and get it working on the Dev servers. now when he announces it Security cant do anything but say yes and do your bidding because they do not dare tell the Senior VP of marketing that they wont let his project run.
They should go to the VP of marketing and ask him about delaying the implementation of the project to try to address some security issues, and inform him that the devs didn't give corporate security a heads up to even start considering the security ramifications.
Then a few weeks later, they can deliver a shiny report to the VP quantifying the risk that this new effort brings to the company, explain what the risks are, and propose mitigations to the risk (some of which involve removing things from the project, locking it down, or spending a lot more money), as well as the risks and costs for going forward with no changes.
After the VP weighs his options, he may cancel the project, due to the cost created by not involving security planning at Stage 1.
Do I make enemies withing security? yup. Every one of them hated me because my default approach to them was an end run. And it was simply because the security guys were incapable of thought outside of the "lock it all down" OMG OMG! DANGER DANGER! WE got a iphone/ipod app launched for use in the company and made every one of the security guys froth at the mouth and fall on the floor convulsing when I end ran them to a VP who loved it and wanted every sales person to have it. They lost their mind at allowing 190 non company locked up iphones and ipods connected to the holy internal wifi. Just wait when my ipad system for sales forecasting get's greenlighted and they have to allow 200+ ipads on it as well...
Just wait 'til Security has to have an auditor in with a pen test that involves sneaking in an iPhone with malware installed, and gives the company an F rating on a SOX audit, with demands that the "open wifi policy" cease, and 10-million$$ fines for the company.
That is the problem when you are working in a gatekeeper position or have deal with people in that role.
No one notices the gatekeeper until they screw up. The default answer to any request must be no, because if they say yes and something bad happens it is their fault. No one remembers that they have been keeping the bad stuff out up until this point. Only that they let this one bad thing through so they must be bad at their job and should be replaced.
Maybe I read it wrong, but wasn't the GP's post about having unsecured guests onto the internal, secured wifi?
Having unsecured guests on an unsecured, external wifi network is easy.
Allowing someone in parking log to access your internal network from his unsecured machine ... that's a problem.
Just ask Target about it.
What a sad day it is, I read DOS as denial of service through most of the first verse. The sad thing is I grew up on DOS, ok MS-DS.
insert inflammatory comment here!
It sounds like anytime you want something, you run to upper management. I guess you will be a manager firing people in no time with that kind of attitude. Good job. You are successfully not seen as much of an IT person, but a corporate person that pushes people around under him/beside him by getting in with upper management. I would not consider your story as much of an IT story as much as a corporate "push your weight around" story. Sure, it happened in the IT department, but it could possibly happen in any department.
The world is how you make it
> One of the best environments I ever worked security for allowed
> for senior managers to take personal responsibility for these
> kinds of decisions.
Yeah, I once had a dream like that too, except the senior managers were also unicorns who shit candy.
Log in or piss off.
Just think how that would have gone if you had done steps 1 (buy-in) and 2 (dev servers) and replaced step 3 (be a dick) with (approach security with said buy-in and offer to collaborate on making the security work in a conducive manner). Senior VP would know you know how to manage a project and get things done and security would know that you're someone who cares about their requirements and is willing to work with them, making future engagements that much easier. Now that you've established your reputation as you have, good luck working with them on that ipad system now that the gloves are off.
It's very green to think that the most important thing to focus on at work is technology or process choices. It's more important to build meaningful bonds with other teams than any other skill set. That's why IT goes to bat for me when I need them to. Because I work with them, not against them. If they say things need to be a certain way, I may question why and protest civilly if it's not legit, but I follow their rules. It's their playground I need to run my code. They need my code to keep their playground. It's in our best interest to work together. So put aside the silly topics that split you and focus on why you are truly there, to make a good living doing what you love.
I know that sounds a little wistful. But after many years of this industry, I can honestly say there are some things more important than what tool set you use. I'm in demand because I can code well and I'm a good teammate. Those two things are both equally important.
Tiger Blooded Bi-Winning Machine
IT Myth 0: Let's get a bunch of boys who relate to machines better than they do to other people, put them all together, and expect them to work as a team.
Black bear*, FTW.
* Ref
You mean MS-DOS wasn't a Denial Of Service OS?
Not a sentence!
It is situations like this where the need for a CIO is so important. In this case the CIO would squash you for being a douche and make you come up with a new secure way to handle the same situation. Security matters, especially if you are running wired/wireless together.
You can't have Dev doing what ever they want , just as you can't have admins or security doing whatever they want. The CIO needs to lay down the direction and the minions need to follow.
Disclosure: App Dev and Teleco, with a sprinkling of unix admin and dba. Yes, I know enough to fuck up anything.
Thanks. Keep up the good work. People like you keep us penetration testers in business and doing nicely ;).
Yeah, those "personal responsibility" contracts are just proof that you allowed senior management to do something unbelievably stupid and attempted to absolve yourself of the duties you were hired for. When it hits the fan, you'll be canned because you weren't doing your job (senior management might or might not be fired depending on cronyism).
"Of course, I wasn't the one who was constantly rebuilding hosts in the internal network because black hats kept breaking in through compromised iPhones, so for me, it was a total win."
Your solution is all nice and fluffly, but completely NOT grounded in reality, and the GP was talking about reality.
Devs have NO say, Ops have NO say. You get handed the dog food and you can either eat it or find someone else to feed you.
Opinion:=TMyOpinion.Create(Me);
Do your goddamn job and quit turfing tickets to "Waiting for customer response" every chance you get.
captcha: executor
One of my favorites is http://www.thewebsiteisdown.com/ featuring "The Sales Guy vs. The Web Dude" as web dude tries desperately to get his important work (gaming) done while assaulted on all sides by rampant incompetence. And the email from the boss, "whatever happens, DON'T REBOOT THE SERVER!" (of course that emailed was conveniently "not found").
mfwright@batnet.com
Yeah, those "personal responsibility" contracts are just proof that you allowed senior management to do something unbelievably stupid and attempted to absolve yourself of the duties you were hired for. When it hits the fan, you'll be canned because you weren't doing your job (senior management might or might not be fired depending on cronyism).
I invite you to re-read my post. My job was to identify and outline the risks. Which I did in my report that was distributed to the team and all management involved in the decision process (always CYA with documentation). At that point, it is management's job to make the decision. That's what management does. If you're in a position where you can do your job, get ignored, and still get fired then you should cut your losses and get a different employer (or be a contractor with sufficient fees to cover the service of being a scapegoat).
I'll point out that in this environment, it was exceedingly rare for a management showdown. People tended to back down instead of taking the risk assessment to their managers. Managers would often come back with more questions and directions for their team to adopt recommendations. When it went up to the next level, it wasn't a given who would "win" the argument. If management over-ride was a trivial and common-day practice, I wouldn't have viewed my environment as being "one of the best." I agree that not every environment is like this. Heck - many environments seem to have little concept of accountability. But that doesn't mean it is impossible to do.
Why an iPad app? Why not a web app? That way you don't (necessarily) have to buy any new hardware, and don't need to lock yourself in to any proprietary platform.
You have to understand, each iPad is a portable, overpriced little security nightmare. They're fully capable of running advanced malware like a desktop computer, but at the same time, are uncontrollable, unsecurable black boxes. You have less control over them than Apple, the telcos, and anyone who can compromise anything they're running. A brand new iPad out of the box must be treated with at least as much suspicion as any random, potentially malware-riddled home PC. And you want to introduce hundreds of these onto a network presumably intended for secured machines.
I'd really like to hear more about this, because from what you've said it just sounds like you pulled the biggest backstabbing dick move of all time to get a silly iShiny app in use for some reason. Maybe the security guys were being totally unreasonable, and maybe your iPad app is genuinely useful and really awesome, but from your post your idea sounds like a bad one.
"When information is power, privacy is freedom" - Jah-Wren Ryel
Ding ding Ding!!!! we have a winner.
And that is the point of getting executive buy-in. to bypass the security guys that say by default "no way, if it does not meet NSA security specs it's not on my network" and actually getting work done in the company.
I'm a big one on giving the guys that matter, sales, the tools to sell more and make more money for the company. It's that understanding that get's me as a IS guru and dev the ear of most of the executives as I talk their language.
"increased sales, better time management, low cost easily replaced hardware (iphone/ipad)" makes them listen, buy in and say, "great idea, let's test that and see if it can be implemented "
SEC would prefer we use $3500.00 each windows 7 tablet computers instead of $500.00 ipads. SEC guys are out of touch with reality, end running them is the only option in getting real technology in the company.
Do not look at laser with remaining good eye.
For years I have walked a fine line between being a developer and a sysadmin and am happy in both roles. I do not put up with the whole protectionism mentality, you want access you got it. I just let it be known that if you screw up it's your ass. It is the IT groups job to provide support to dev not to keep them from doing their jobs.
The only issues I have ever had are management struggles over who I am going to work for, IT or Dev. I don't like performing pure sysadmin work and or development work. Eventually one side or the other wins, I get pissed and leave and the cycle begins again.
http://www.channel4.com/programmes/the-it-crowd :)
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
And that is the point of getting executive buy-in. to bypass the security guys that say by default "no way, if it does not meet NSA security specs it's not on my network" and actually getting work done in the company.
The problem here is having to bypass the security guys. In that environment, we were constantly coming in to a meeting and putting the breaks on the Big Idea as presented. There were often huge risks due to absolutely no consideration or understanding of security or even the underlying technology. Our job was to not only find these problems, but help the business unit come up with solutions to those problems. That was the usual outcome. Sometimes the business unit just didn't want to change their direction or the Big Idea was fundamentally risky. And thats when we had the face-off between business gains and business risk.
That doesn't mean we didn't have people doing the end-run game you're describing. But they were often exposing our mutual employer to pretty significant risks - often completely unaware of what they were doing. Granted - your environment might be different. Your security group might be setting up their own headaches by being viewed as a problem rather than part of IT solutions. Or you might be setting yourself up to be part of the next big security incident for your employer.
http://www.infoworld.com/print/151016 "You're welcome." --Nick Burns
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
So I am curious how this evolved into this form. How did this get implemented? How did you get the buy in that you should actually take the time to do this assessment?
I better jump on this chance to ask my question. No, I'm not trying to start a flamewar, but this might be a unique chance to some more insight.
Okay, you use emacs. What was your choice based on? What were the factors that ended up getting you on emacs?
For me, I decided to learn vim, because I had heard that there was a lot of chording (ie. Esc-Meta-Alt-Ctrl-Shift type simultaneous keys) in emacs. It worked out well when I started using vim on my smartphone. But I haven't actually used emacs before, so I don't know what emacs is like, and I freely admit that I don't know what I'm missing.
It sounds like there are a lot of historical for preferring either, which are not necessarily relevant today (e.g. Emacs took up more memory, before massive cheap memory was available on the market; there were no colour screens when vi was created, etc.).
So, my specific questions to all you emacs/vim users out there are:
1. Which do you use?
2. Have you used the other one before?
3. If you have had experience with both, what were the deciding factors for your choice?
Note: Please don't say which one is better overall --I think we've all heard that before. Please don't tell us how Pico or Gedit or MS DOS Editor is better than either vi or emacs (unless you want to share how your decision came about after actually having used vi/emacs). The purpose of this question is (among others) to help a user naive to both vim and emacs to decide which to learn.
Thanks for any insight you can give.
404555974007725459910684486621289147856453481154 in hex is "You sank my Battleship?"
[GPG key in journal]
I'm pretty sure he has.
Their security sounds eerily familiar to my security - Who forces me to sit with my laptop on an unsecured connection right on the internet, because I'm an "untrusted" contractor - but working on developing their systems, who are thus *also* untrusted. And therefore they can't allow internal access, so none of the internal customers are allowed to actually see what I'm developing, unless I mail them a screenshot.
Oh yeah - since I'm in the untrusted segment, they also don't allow debugging because that's against policy, since the server needs to connect to my development environment (the insecure one - the one I'm using to BUILD THEIR SOFTWARE for them that will then be promoted to the internal servers, no questions asked).
I've told my project lead that he could do two things: one was to change the policies, and the other one was to accept more billed hours. He chose the hours. Way easier.
Therefore, by the (faulty) logic you're using, you're just a cow with a keyboard - osu-neko (2604)
Tried it. Didn't like it. It really wasn't much fun.
If I were God, wouldn't I protect my churches from acts of me?
So I am curious how this evolved into this form. How did this get implemented? How did you get the buy in that you should actually take the time to do this assessment?
It was the job description. The employer was dealing with a number of major security incidents and was trying to get a handle on the situation. They wanted to change how things were operating but they didn't want to kill the golden goose.
I have to admit, the environment was different than others. It was corporate but had more of a research feel to it. Unlike, say, banking environments where locking things down is a part of the culture. Yet this culture allowed for personal responsibility as management put their reputation on the line to support a business case. Taking risks was a part of that culture but you had to be able to justify those risks. So in effect, the security group was working as consultants to the various business units (while still being Masters of the Firewall and therefore holding the kill-switch to external network access).
I believe this would work in other environments. I've applied some of this to Government as well. I championed getting ourselves involved as problem solvers and not simply They Who Know You Surf Porn or Masters of the Firewall. I attended a number of meetings where we acted as consultants to help the group identify and mitigate security problems. Sometimes it was with existing or about-to-be-deployed solutions. Sometimes we got involved at the requirements stage and were able to help the organization start on the right path from the very beginning (which tended to make everyone happy). Come to think of it, this was another environment with a history of high-visibility security incidents.
I've been at various times, a syadmin, a dba, sec/op, developer, manager and even took my turns at answering the phones at one point in time. Often, several of these roles at once. I've been on every side of this issue, and if you wanted to take a stab at a generic fix, it could be summed up simply: work on your communication skills.
I hate to plug agile, but the focus on round table discussion among all stakeholders really seems to be the way to go. Aside from the criminal examples, the problems in the article all stem from lack of understanding or an inability to explain. Making the people who dream it (sales & marketing) sit with the people who make it (developers, dbas), the people that make it go (admins, security), and the people who say go or no-go (managers), is required if you're going to churn out products with as little strife as possible. Devs need requirements and tools, DBAs and Admins need hardware budgets and usage estimates, Security needs the policy followed or amended, Management needs to keep costs down and cycle time high, and so on. You need to communicate this to all members, not just via project managers.
The article ends with a choice quote:
"The top sources of conflict are the tech person's ego, poor management, a lack of proper leadership, and allowing technical people to make business decisions. The solution there is to know your role and let your talents shine where they should."
No. This is just a quote to sell services to non-technical management. Paraphrased: "Those silly technical people have no social skills, or business acumen. It's their all their fault, pay us to tell you why" with a subtext of, 'use this to ensure your year-end bonus to the board, and why only the grunts should be fired'. Everything in there perpetuates the myth of the antisocial nerd, incapable of everything but a magic control over computers.
As an aside, I think the devs get it the worst. Requirements always suck, always move, and often conflict, management always moves up dates, removes people, adds features, and rearranges priorities in the 11'th hour. Some companies don't allow devs to install local software, slowing development. Most hardware allocation requests have to come from them, instead of the product managers, so it's often one dev vs. dba/sec/admin- department. Operations crews don't want to learn new systems or introduce esoteric requirements only after software is gold, and so on.
For some reason, no one has problems when security or admins say it will take 3 weeks for a badge or new hard drive, but expect developers to rewrite software in a day. I often wonder if it's just that the dev department never does a good job training their manager compared to the other groups.
That's Nikko.
http://www.amazon.com/Nikko-230-Stereo-Power-Amplifier/dp/B000E304YA
cheap ass jap crap, consumes VA, 620 of them, as if I have VA coming out of my ass
Product Description
Continuous Power Output 120w + 120w Min RMS per channel into 8 ohms from 20 to 20,000 Hz at rated T.H.D both channels driven Both Channels driven at 1,000Hz - 8ohms 120w +120w - 4ohms 130w + 130w Total harmonic distortion at 8ohms at rated power 0.008% Intermodulation distortion 0.008% Power Bandwidth (T.H.D. 0.05%) 5 - 70kHz Damping factor - 8ohms 70 Slow Rate 100V/uS Input sensitivity/impedance Main In - 1,000mV/50kohms Signal to noise ratio Main in - 110dB Frequency Response Main in (5-100kHz) +0/-0.5 DB Power AC 120v 60Hz Power Consumption 480W 620VA
oh cry more. oh no, security was compromised and i have to do more work!
but if your happy politicizing yourself out of a job. be my guest. i will continue to demand root access to my damn machine because i don't want to wait the 3 days it takes you whiny security guys to install a simple app.
our security guys are demanding that we only use internet explorer 7, because apparently Firefox is insecure. that's all well and good, but I'm a web developer and i need Firefox (as well as ie & chrome) to do my job properly.
Just for fun, what would malware actually do? Apps are heavily insulated from one another, and a corporate Ipad store has exactly what you want it to have. I wonder if Apple has set up a whitelist control for its corporate plans, as that would address most of your concerns. In the meantime, a compromised Ipad can be wiped without much problem.
"We returned the General to El Salvador, or maybe Guatemala, it's difficult to tell from 10,000 feet"
It's not about skills so much about caring about consequences.
It was interesting when I started at a new job and a developer was working as a temporary sysadmin and he was "showing me the ropes". I pointed out a problem on a MS Windows domain controller which could be resolved by stopping and starting services, but before I'd got very far he walked out and hit the fucking reset button on the machine. There was no backup domain controller ("if it breaks I'll fix it"). He then did not answer the large number of phone calls that came through in the next half hour while doing nothing but sit and watch it do it's disk check and told me not to answer either ("they'll get over it"). The guy KNEW how to do the right thing but didn't think that was his job and didn't even contemplate the lost production and anger he had caused just to save a few mouse clicks but waste a lot of his time staring at a screen. That illustrated to me more than any of quite a few other examples that some developers just have to realise that running systems is a completely different job with different aims than running a test system they can reboot at any time.
It's not about skills.
It is about understanding what the job actually is.
That is why developers are typically kept as far from production as possible until they can understand what sort of actions are incredibly stupid in production and what the consequences of those actions could be.
exactly.. its just bits on the network.. the security guys should be concentrating on all hosts being untrusted.. Far too often I have seen nastiness happen because someone plugged a personal laptop into the company network behind their lovely well maintained and managed at the front end of the network.
What are we going to do tonight Brain?
I hope (yet doubt) you have enough guts to take full responsibility for the problems your shenanigans will cause. I hope you remember this post when it happens.
Or, co-opt security and they get Active-Sync installed so you can get a push email client on that Iphone, lock down the environment and a third party support and distribution engine so the Devs can write internal apps and ops can deploy them to the company hardware.
It's a simple matter of working *TOGETHER* instead of working against each other.
You just don't get "IT" since you now have no idea of the integrity of your Iphones (are they jailbroken and full of malware? How the fuck would you know?) Do you have people running older versions of the IOS (oh I dunno like your clueless CEO?) Do you let people store their credentials on the phone (Cracking an iphone takes less than 10 minutes if their purse/laptop bag is stolen...)
You have an insane superstitious fear of a regulatory requirement that a company have and follow documented policies. Requiring that you have and follow documented policies does not mean that you can't let your sales staff use iphones. SOX does not require your company to abandon logic and reason.
Meanwhile, your competitors don't actually give a rat's ass about your sales data for Omaha.
Yeah, related to the "last hand to touch it" syndrome I read in another post here.
sr
His ignorance covered the whole earth like a blanket, and there was hardly a hole in it anywhere. - Mark Twain