Our organization has recently restructured IT and has separated network engineers into new roles such as architect, implementation engineer, and operational support engineer.

There are concerns surrounding SOX compliance and how / whether we would implement appropriate controls to restrict access to the production environment for architect level personnel as their primary role is strategy and planning. My understanding is that SOX controls for separation of duty are more specific to financial or accounting data - and access to (for example) a production database for dev/QA only personnel.

What are SOX requirements for access to route/switch/transport equipment? Where would separation of duties apply to network engineers?

  • 1
    I think much of this depends on your company and what specifically network engineers are responsible for. This SANS Institute SOX Compliance Overview seems relevant and may help. If you discover the answer on your own, please add the resolution of your question as an answer below.
    – This
    Jul 7 '14 at 8:50
  • I'm curious... did you find anything to answer your question?
    – This
    Jul 18 '14 at 7:43
  • Did any answer help you? if so, you should accept the answer so that the question doesn't keep popping up forever, looking for an answer. Alternatively, you could post and accept your own answer.
    – Ron Maupin
    Jan 4 at 1:38

After having been through this process for a for a few clients now I would generally start with ensuring that you have implemented at least the following controls - note that none of these are specific to SOX, as route/switch/transport doesn't generally play a role in financial reporting aside from a pure availability standpoint:

  • All changes to the network are performed by authorised individuals (e.g.: RADIUS/TACACS backed accounts for any super-user access)
  • All changes to the network are reviewed by authorised individuals (e.g.: there is some formalised method of change management, including perhaps an audit trail in the form of helpdesk tickets, change forms etc.)
  • An audit trail exists for providing super-user access and any changes to it (e.g.: logging on your directory server of choice that shows user/role assignment and who performed it)
  • An audit trail exists for any changes that are made and who made them (e.g.: version control of network configurations, syslog recording of logins and interactive commands)

To answer your question regarding your Architect resource having access to the production network, I would not see this as being dictated by SOX requirements.

On the other hand, from a security standpoint the Principle of Least Privilege would probably apply and thus a read-only account may be more appropriate.

  • Are you aware of any technical guidance on Sarbanes Oxley style networks?
    – Ryan Foley
    Dec 16 '14 at 21:41
  • None whatsoever. Coming at it from a pure networking standpoint, the Act doesn't really mention anything outside of the above as controls, and even those are mainly for applications handling financial reporting. (Application) Security obviously plays an important role in ensuring that results are accurate/not tampered with, but in terms of straight switch/route, I don't see the connection. As usual, IANAL/YMMV Dec 17 '14 at 2:22

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.