6

This is a tricky issue I'm dealing with at the office. Management has a very... interesting concept of segregation of duties when it comes to traditional 3 tier applications.

I'm trying to figure out if this is an internal culture which grew out of a broken telephone game, or if it is part of some framework which I haven't encountered before.


Application Administrators
~~~~~~~~~~~~~~~~~~~~~~~~~~

                        Management       Me
                        ~~~~~~~~~~       ~~
Application Reader          X            X
Application Admin           X            X
OS User                     O            X
OS Admin                    O            O
Database User (ro)          O            O
Database User (rw)          O            O
Database Admin              O            O


OS Administrators
~~~~~~~~~~~~~~~~~

                        Management       Me
                        ~~~~~~~~~~       ~~
Application Reader          O            O
Application Admin           O            O
OS User                     X            X
OS Admin                    X            X
Database User (ro)          O            O
Database User (rw)          O            O
Database Admin              O            O

There are vague comments about ITIL, and other vague comments about "external" policies. No specifics.

Does anyone know of any principles of segregation which might prevent an Application administrator from having any OS level access?

I'm specifically speaking of 3-tier apps. Keep in mind the OS admins do not have expert knowledge of the Application. Application Administrators are responsible for providing customized install guides to the OS admins, who quietly mess it up, leaving us to troubleshoot without access to see what they did wrong.

It sounds to me like a very fractured adaptation of a software development model, but I can't quite put my finger on it.

Improve this question
2

This is not something out of the ordinary but you need to keep in mind that, ITIL is not a set of rules but guidelines. It is upto each organization employing ITIL guidance, to set up their own interpretation of these guidelines.

And it is not unusual, although unfortunate, to have application admins messing up a procedure and handing it to the less knowledgeable personnel as gospel and watch them fail. Sometimes, again unfortunately, some of this effort is concerted, especially if the segregation of duties are fresh and they are resenting their privileges being stripped off of them.

Unfortunately there is no solution or explanation to the security rules in an environment, handling sensitive data. The best method I cam to realize is NOT TO avoid the steering committee meetings and assert your views on the security matters. I personally fought tooth and nail when they wanted to strip my team from accessing root account. At every organization, one or two people should be carefully selected and be trusted with these elevated privileges. Security decisions made in vacuum by people who don't know what goes into those decision but only making them because the decisions will make them look good on paper, should be avoided at all costs. If this means killing a couple of hours of your already busy schedule, sitting in nonsense meetings, let it be.

Improve this answer
4
  • 1
    Not having "read" level access, i.e., the ability to even review the work of the server administration team is what's hard for me to swallow. Taking root away is perfectly reasonable. The server administration team can't be exposed to the risk of people outside their group changing things.
    – mgjk
    Apr 11 '13 at 0:38
  • You said Taking root away is perfectly reasonable. The server administration team can't be exposed to the risk of people outside their group changing things... mind you I am/was a member of server administration team and they wanted to force us to use sudo for each statement we need, which needs root privileges. Management are penny-wise and dollar stupid sometimes. But you have to give it to the, it looks good on paper. So is your case. But real life is different and they will come to realize that, first time it blows up on their faces. Just give it time and follow their rules.
    – MelBurslan
    Apr 11 '13 at 7:05
  • Eventually somebody needs access to the system, and hopefully it's somebody who knows what they're doing. I would like to see policies, models or arguments which discuss the merits and flaws of different approaches. I strongly suspect the approach they're asking for in my case isn't part of any existing model. Segregation of duties is not new to me... it's just this nutty interpretation. I can't imagine any value to it.
    – mgjk
    Apr 11 '13 at 11:29
  • Demanding sudo for every command (when possible) preserves an audit trail. I can even see an argument for it. Although, if not done very, very carefully, and if they don't permit administrators root at all, then they're smoking something.
    – mgjk
    Apr 11 '13 at 11:30
1

Segregation of duties is a strategy that attempts to defend against vertical attacks, that is attacks that require the cooperation of two or more integrated elements for success.

For example, if one set of people are responsible for creating logging policy and reviewing the logs, and another set of people are responsible for adding or removing users from the system, it would require two people to collude to add a person to the system without the even being logged.

The segregation of duties strategy does incur a performance and efficiency penalty. A job that might be done by a single person without segregation of duties must be done by two people. This is clearly less productive.

It is typical that when duties are separated into application administrators and OS administrators that there is lost productivity and even group friction. Try to suggest approaches that increase your productivity without compromising the overall security. Ask OS administrators to document their install with screenshots or logs. That way when something goes wrong you have data to work with.

Improve this answer
3
  • I'm responsible for taking over an existing environment where the team who built it, built it without the same separation of duties. This means they were given privileged access to the command line. Figuratively they wrote their own requirements and built the environment without documentation. We're assuming the environment, but many assumptions about the environment are proving wrong. I've raised to management that administering the environment in this fashion is contrary to the vendor recommendation and makes it effectively impossible to perform due diligence in supporting it.
    – mgjk
    Apr 13 '13 at 16:12
  • I'm trying to develop a strategy to smooth the politics in the situation (which have grown out of control), while ensuring that the environment continues to run smoothly during transition. I've seen this before in enterprises, but in far less seriously restrictive separations. Formal frameworks may help me get clarification from corporate, and possibly get clarification added to the policy guide for the org. There are many risks in this model and I don't think management recognizes that an uncompromising position is bad for everyone involved.
    – mgjk
    Apr 13 '13 at 16:15
  • 1
    Oh and the whole thing is p**ing me off.
    – mgjk
    Apr 13 '13 at 16:18
0

I have had the same conversation with a lot of our customers… it keeps me awake at night.

Here is how many customers have described it to me:

We have millions of documents sitting in our enterprise application servers that we know are accessible to all our users. We are subject to regulations that require us to identify classified documents within these large sets of data, and segregate them into restricted servers. It is also important for us to restrict users from storing documents in the wrong servers. We are not sure how to segregate this data and put them into the right physical servers. This project is so complex, we do not even know where to start.

This is the problem of Content Segregation. We would all agree that Enterprise Content Management applications are very important in the day-to-day operations of the business: an essential part of the Global Collaborative business process. However, these applications have not adequately addressed the need for content segregation. Enterprise and Security Architects are looking for more sophisticated ways to secure and manage the data that is created, stored and shared and in these applications.

Read more on my thoughts about data segregation: Data Segregation: Missing piece in securing Enterprise Content http://goo.gl/8E0E8E

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.