How Does Your Organization Handle Production Access?
In the past 10 years or so I have worked at, or as projects in, many different types of organizations and there are as many different ways to handle production security as you can imagine. Every kind of process from "we don't need no stinking production security" to "we won't even acknowledge we have production systems".
In most companies hardware and software systems are broken up into several categories, generally some kind of location development environment, perhaps a global development environment for initial testing, a higher level functional test area, a QA area and finally the operational production systems. The latter is where the company stores and handles whatever business data that supports or even is its business. For some entities this data is not central to the business, and its loss or theft (if there is even anything to steal) has no real impact on the bottom line. In more cases this data is vital to the continuing health and welfare of the business and care must be taken to avoid loss or alteration. In other companies this data contains private information of others, such as personal, financial or medical information, for which the loss of alteration could result in bad press, civil or even criminal penalties.
Yet I haven't found a consistent view on security at all. Some places have had tight security yet the data and systems were totally innocuous; other places adopted a "laissez-faire" view that allowed full access to anything anyone wanted despite a vast array of public trust information. Sometimes the level or security was based on the anality of the operational leadership rather than the nature of the systems and data.
It never fails to amuse me when I read about a big data loss, may it be unencrypted backup tapes or laptops that are lost, or hacked in systems that provide a wealth of credit card numbers (TJX Post). I always wonder how people got into positions of security leadership without being at least prudent, much less paranoid, about how information and systems at their organization are protected.
The types of security I have witnessed include these types:
- Total Lockdown - only a few operation people have access to all production systems period. Even production logs must be requested and are scrubbed before viewing.
- Mostly Lockdown - only a few operation people have access to all production systems but specific access is granted to other individuals who need it based on limited username/passwords with full audit trails
- Mostly Lockdown 2 - like the previous but allow more full access but from limited IPs, using electronic keys
- Careful Lockdown - only a few operation people have access to all production systems but other users have specific access rights to areas which have been set up for them (such as log directories)
- Come On In The Waters Fine - production is protected by passwords known to everyone. No audit trails are possible since it's a shared "secret" other than possible recording an IP address.
Financial entities such as banks and investment companies, healthcare companies and the like you would think always operated in a lockdown mentality but in my experience it hasn't been universal. In one place I saw total lockdown, but the reason had more to do with hiding the failures of the operations team than any real desire for tight security. I have often heard the excuse for a "Waters Fine" system that people need quick access to solve production problems; also since the outer security walls of the company are so solid that no possible issue exists with external attackers hitting internal systems. [I'll pause while you either laugh or gag].
When I was working on a big project at a large company (customer) around 1999, me and my project partner initially had access to both our test and the production systems (generally during most the 12 month development and beta roll out) which ran in a small data center on the same network. This system had both an external web application for the external customers and an internal one for the team that processed the data. The database was highly complex with both full audit trails and a workflow system. We were given access to the network with username/passwords/ip filtering/electronic key generator but otherwise allowed to do the work. Near the end of the project the company hired EDS to take over operations and all of our access was completely revoked, making it impossible to actual continue the project in any reasonable way. We were limited to calling an operations person who would type into a command line what we needed done, and have them read the result to us over the phone. Yet the two of us were the only people would were able to do anything with the code or database so progress came to a complete halt. So we did what enterprisey programmers always do; we put a backdoor into our application (protected by two levels of passwords and IP filtering) with full access to both databases. Needless to say it worked because EDS didn't care about the application or the project at all, and the folks we were building it for only cared about getting the system finished and working. Eventually the entire system was automated to the point that the backdoor was no longer necessary (and more sane access put into place anyway).
The point is that there is always a balance between the need for some access to production systems with the need to protect them.
So what can go wrong? Unfettered access to systems that should be secure can lead to:
- Errors
- Mischief
- Theft
- Blackmail
I'm sure you can think of more. Yet every day you read of people who failed at the basics of how to properly protect their production systems or data.
Statistics show that most operational security problems come from inside your own staff, yet defending against the proverbial "hacker" from outside seems to pervade most corporate security discussions.
I can see the most reasonable path has to be tough protection combined with limited, fully auditable access. Sometimes it's hard to imagine how to do this since systems, software, databases and platforms are not consistent in how they provide access, authorization and authentication, much less provide easy single-signon interoperability. These types of challenges often lead to diminished security since it's considered "too hard" to overcome and thus nothing is ever done. Sometimes the cost of doing it right seems too high compared to doing the easy way (or not doing anything at all) and hoping for the best. Hoping is not a great security system. It's like leaving your house unlocked and hoping no one will open the door and take your stuff.
I'd love to hear stories from other folks on what people are doing in their companies.

Project management faqs 08/04/2008 20:38
Yes when your organization grows it would not be possible to give production server access to even top members. It should be only accessible to System administrator group
Michael Chermside 08/05/2008 07:12
I work for a bank... not just a bank, but a bank which is obsessed with security. (Anyone curious can tell which one from a quick web search.) And while there are a few things I would change if I were in charge (aren't there always?) for the most part I would say that we do a pretty good job.
First of all, production machines are a separate domain. Several years ago there was a time when some developers had at least read access to these machines, but that has been removed quite some time ago. Instead, there is a separate group, the "Application Support" team, that responsible for (1) deploying code (after it has been thoroughly tested and signed off), (2) daily monitoring of systems and (3) troubleshooting problems as "Tier 2 support". (Tier 1 is the help-desk that directly fields user issues.)
Of course, the truth is that some issues are just too difficult to be resolved by "Tier 2 support". After all, they're smart people and they've gotten a description of the system design and some instructions, but they aren't programmers and are simply not in a position resolve all issues. So whenever they need to, they contact "Tier 3 support" -- that's the developers. We (I'm one of the developers) try to resolve things by discussing it a little, recreating the problem in QA or development, or by reviewing a log (which Application Support will send us). But when that approach isn't enough, the one or two individuals working on the issue from the development team ("Tier 3 support") are added to the necessary production access groups. We're expected to resolve the issue as quickly as possible, then give a full report afterward (and the access is removed).
This seems to strike a reasonable balance between security (only a limited group of people have production access) and the ability to resolve problems (I, too, have seen places where nothing could get fixed because the people able to fix it were not permitted to).
Your point about building a back-door into the application is a good one: unfortunately, it is extremely difficult to protect against this kind of thing. We have policies against it (obviously!), but if done right it is the sort of thing that QA and application support would never be able to identify. We have made some attempt to use commercial code analysis tools to identify such things (but I am skeptical: I feel confident that I could evade that if I were trying, and so I'm sure a malicious insider could as well). Our main lines of defense against this are (1) careful hiring including background checks and (2) code reviews.
-- Michael Chermside