IT Security - SOD and Best Practice for Security Profiles 2570

  • I would like hear opinions on this.
    Is there a best practice for setting up security profiles under the following exaple:
    An application has profiles for SalesRep1, SalesRep2, and SalesRep3.
    SalesRep1 being the most junior and SalesRep3 being the most senior.
    Assume that a SalesRep3 can have the same permissions of 1 and 2 without any potential conflicts or increased risk.
    Assume the application has ideal flexiblity to set-up security profiles (so that the best possible solution could be used…ha-ha…of course in reality this is rarely the case.)
    Is is best to use:
    Solution 1)
    Have three distinct security profiles, each with increased access (but not inclusive). So a SalesRep3 employee would be assigned SalesRep1, SalesRep2, and SalesRep3.
    In this scenario a SOD matrix would not be symterical. Meaning that an employee acting as a SalesRep1…would have SalesRep1 should not have SaleRep2 or SalesRep3.
    But an employee who is SalesRep3 could have (and would have) SalesRep1 and SalesRep 2.
    Solution 2)
    Build each profile completely seperately, so that the permissions of the lower security group are included in the higher one.
    Therefore, SalesRep3 would only have the SalesRep3 profile.
    Not sure how this would look on an SOD matrix. Technically, it would be the same as the above.

    • Trying understand which is the best practice considering all things (management, ease of review, audit related concerns, etc.)
    • Also trying to answer the question, are the ‘X’s’ (conflicts) on a SOD always symmetrical. (I don’t believe so…rather to look at the roles on the right hand column as the ‘actual’ role…and the roels across the top as the potential conflict).
    • Any other thoughts would be appreciated.
      Sorry…this is a bit lengthy, but I hope it stirs some interesting discussion.

  • Hi David - You’ve shared an excellent question. As a starting point, this level of granularity would not be found in SOX 404. Role based security is always encouraged and COBIT 4 standards are used often to measure SOX effectiveness by outside SOX auditors.
    COBIT 4.x Guidelines - Free with registration
    Personally, I like having either one or two groups in the SM1, SM2, and SM3 examples you’ve shared. For example, if the access roles are very similar, just build one group called SM and add additional rights for SM2 and SM3. However if there were very marked differences in access between SM1 and SM3, it would justify creating a SM and Senior SM job role.
    The key in building security groups is to assess likenesses and differences in access rights. They more they are related in their job roles and access rights – the more they below to the same group.
    One more thought on groups, is that you must have multiple users participating in a group. If only 1 person makes up a group, it’s not truly a group.

  • Agree with Harry, but would add that I would be less concerned about how the SOD matrix looks and more about how easily this was administered in the application.

  • ^ As Denis shares, I would approach avoid any ‘nesting’ of security rights among groups and avoid the use of roaming profiles. There might be some duplication of rights among groups (from the basic to senior job roles, but ‘keeping it simple’ helps with maintanance and future audit reviews.

Log in to reply