IT , Sarbanes-Oxley, and Design 1476

  • Hello all,
    I have what i hope is a quick question. (that usually precedes a very long and drawn out one)
    I am an industrial designer, I work at a Point-of-Purchase display company. My fellow designers and I just got new MacBookPro laptops. We are told that we cannot have administrative rights on our computers because of the Sarbanes-Oxely act. In fact every time we say ‘we dont’ like this, or we don’t like that’ we are told ‘Sarbanes-Oxely Act’ like it’s the ace-in-the-hole.
    I don’t like boxed answers to complicated questions, so I have been digging into the SOA and can’t seem to find anything that says i can’t actually be given Administrative rights. Unfortunately our IT support on the Mac side is usually less than helpful when it comes to actually having a dialogue about something. I find it utterly frustrating that we can’t just sit and talk about the situation and come to an agreement.
    It’s also very interesting to me that when I had a PC I was allowed to be an administrator, and had a different IT admin.
    Everything I read in the 404 section gears itself towards the financial reporting systems. I have not read the section verbatim, obviously. I hooked up with Protiviti to try and find some information quickly, and no luck on this specific issue.
    Now for the question; Could someone post a quote, or an excerpt that states a policy one way or the other on this issue?
    It’s a royal pain in the butt that I can’t even install a flash player software, or an update for quicktime, or quicktime pro, or any other host of things that are usefull to me when I’m out and about. I ask for a quote because I need to make a case, and present it to my supervisor so he can be armed with the proper information to ask for our rights back.
    Can anyone help our design department please?

  • Welcome to the forum.
    The restrictions stipulated do not come under the realm of SOX. I cannot get you excerpts but based on 4 SOX life cycle plus a latest 2006 planning meeting with our Big-4 auditors, for IT SOX compliance , we are not tapping this requirement of stopping to load certain restrictive functions on Laptops. As long as those laptops are company owned and there is restriction to log onto the company’s server either through VPN or company sponsored ISP, you are good to go.
    Milan is in a very good position to provide authoritative excerpts.
    All the best.

  • I’ll paraphrase from my recent post in CAS thread just changing the subject matter around slightly, as this is very common: 😉
    You won’t find ‘Local User Authority (LUA) restrictions’ specifically named in SOX compliancy guidelines. However as part of the SOX 404 standards, the Information Technology area must adhere to best practices and sound security controls to protect the company’s information resources. Companies wanting to meet SOX guidelines certainly want the best practices in security to ensure sensitive financial records cannot be accessed or altered outside prescribed controls …
    Companies will also use SOX compliancy sometimes as a reason (i.e., excuse) to tighten controls they have desired to in the past, but couldn’t convince various areas to do so …
    My own professional background includes several years in security administration, as well as a on-going interest in the security field (e.g., as noted by the WWW button at the bottom). Unfortunately, with the current level of Windows security, it’s ‘all or nothing’, as without ADMIN authority you can’t install software or even change your desktop wallpaper. In fact, you can foul up your PC if you are in the middle of installing software and as a ‘POWER USER’ you try to update the Windows registry 😞
    Typically, developers are assigned local ADMIN rights to their workstation or laptop and users operate on a more restrictive basis with POWER USER rights (completely restricting the registry environment). Typically, restricted rights are valuable for:

    1. In actual practice, the Windows Admin authority can sometimes help provide safeguards against some viruses, spyware, etc., as users are restricted from updating the Windows registry
    2. The power user settings can keep folks from altering started services like Windows Updates (from SUS servers), Remote control agents, Software distribution agents, Virus protection, Personal Firewalls, Anti-Spyware software, etc
    3. The more restrictive services can keep folks from installing software that the company may not be licenced for or may not approve.
      It sounds like you have a true need for local ADMIN authority to your workstation and you’ve used this privilege responsibly in the past. Also, keep an eye out for software that writes to the Windows registry and requires ADMIN authority to even work on your PC as that was once a showstopper for us locking down PCs in the past. As part of the Graphics Design area, typically software is highly advanced and could indeed have this type of requirement.
      Your company has implemented a good practice for most users. However, in the case of your department, there might be a need to grant an exception to the rule. I’d present this to your manager with assurances that you wouldn’t violate the 3 principles noted above – which are the chief concerns of security folks (i.e., they can still always check on your workstation for compliancy if you have ADMIN authority).
      Otherwise, as you have a true business need to install software, I’d recommend working through proper channels by contacting the Support Center (help desk) or network technician. If you keep doing this long enough with legitimate needs – that too can be a factor in returning the security rights you need to do your job properly 😉
      Good luck to you on this and I hope that you can make a case to regain ADMIN authority to your PC 🙂

  • Thanks so much for the warm welcome and the good advice.
    Most of your examples apply directly to the PC environment, but the principles apply to the Mac as well.
    I am compiling a document to state the case of Design and will definatley utilize some of your advices. Thanks very much again.

  • SOX and IT Controls
    Section 404 requires the CEO and CFO to produce an annual audit report that:
    Assesses the effectiveness of the internal control structure over financial reporting.
    Discloses all known internal control weaknesses.
    Discloses all known frauds.
    This report will cover all applicable IT controls, including program logic and related change controls, ACCESS CONTROLS, and data protection.
    PCAOB Guidance
    The PCAOB Auditing Standard No. 2 suggests the COSO Internal Control Integrated Framework as a basis for Section 404 compliance management.
    SAS 95
    References to Statement of Auditing Standards (SAS) 95
    also emphasize the importance of IT and information security controls to Sarbanes-Oxley.
    CobiT Framework
    The CobiT Framework for general controls includes:
    Plan and Organize
    Acquire and Implement
    Deliver and Support
    Monitor and Evaluate
    Internal Controls Over Financial Reporting (ICFR)
    The following may have potential impact on financial reporting internal control objectives:
    Security if designed and implemented properly can assure that transactions are executed by only those individuals authorized to do so.
    If security is designed appropriately, access to assets (physical and electronic) is appropriately restricted and safeguarded.
    Potential impact on financial reporting internal control objectives:
    Application change provides assurances that applications function as intended and integrity of processing can be assured
    Appropriate application changes assure completeness and accuracy of processing
    Together with the security administration, processes assures transactions can only be initiated, modified or deleted by appropriate individuals
    Access to applications and data through the change process must be restricted so that inadvertent or deliberate changes to the following do not occur:

    • Production data
    • Other related components such as interface routines, background processing and updates, etc.
      SOX Relevancy Conclusion
      Thus, administrator privileges (access controls) granted to computer users fall within the scope of SOX.
      Logical Access Controls
      Some of the items for consideration generally include:
    • Authorized users may gain inappropriate or excessive privileges.
    • Authorized user’s access privileges should be defined and restricted by group profiles which provide a template of role-based rights for their designated job function. The group profiles are established by the business areas and used by the security administrator.
      Client-server access rights are defined in user groups containing rights to specific servers, applications, drives, and files. Users are assigned to groups only where there is a business need.
      Assignment of rights to data and sensitive transactions is based on established Data Classification scheme or on business need.
      Application or data base level security restricts user access to the application and/or from specific types of transactions, dollar levels, or even individual data
      Defined authorities and limits built into applications and tables
      Regular or periodic monitoring of the appropriateness of authorities and limits
      Monitoring of transaction activity
      Direct access or updates to data/master files from command lines or batch programs by power users should be prohibited or restricted. If access must be allowed, access should be restricted to only authorized personnel and is monitored and supported by an adequate audit trail.
      Access is restricted based on business need
      Programming personnel do not have update access to production data
      Access for IT or key user personnel is monitored
      Special privileges or authorities, such as Administrator rights are assigned to a limited number of individuals (primary and backup personnel who require those rights to perform their job duties.
      Security of desktop and laptop computers is addressed in the IT Control Framework (CobiT) that is de facto, now the accepted IT Control Framework that is used by most companies that are required to comply with the Sarbanes-Oxley Act of 2002.
      Access Controls
      For SOX compliance purposes, access to applications and data should be restricted to only authorized users with rights commensurate with their responsibilities
      Frequent control deficiencies identified by auditors include:
      Too many super users
      Improper segregation of duties / responsibilities
      Access not properly granted or monitored
      Authorization for access not retained
      Change in roles / terminated employees
      Administrator Rights
      Thus, to establish a nexus between the granting of Administrator Rights on a computer and its relevance to SOX, it is necessary to determine the risk involved that may impact the processing, summarizing, and compilation of data or transactions that have impact on financial reporting. It is also appropriate to determine the business need for granting access and level of access granted (super-user, administrator, end-user, etc.)
      IE Administrator Rights and ICFR
      As an Industrial Engineer for your Company, if by having administrator privileges, you have or can gain access to the financial system(s), sales module(s), or other components that may have an impact on financial reporting as defined above, it may be appropriate to implement logical security controls and enforce system access restrictions to maintain effective IT security control.
      However, if by having administrator privileges, it is not possible to modify production/sales data, transactions, or effect any computer instructions that may impact financial reporting, it seems appropriate to enable the security rights and simply monitor activity through IT control logs and maintenance of good audit trails for all user activity performed on the system.
      It is interesting to note that the introduction of the new Apple MacBookPro laptops can startup in either a Windows or MAC OS (Unix) environment. Thus, a dual approach might be employed to assign security rights in the system–Assign security privileges in each environment based on the criteria and business needs as defined above.
      Given that, it might be possible to enable administrator privileges on the MAC side and deny them on the Windows side if the financial applications, processing, and related sales/production data are performed in a Windows environment. However, I am not sure if this possible. But if it were, it would definitely work in your favor to make a case to grant administrator rights on your new laptop computer.
      Hope this further helps,

  • Thanks milan for sharing excellent information - as usual 🙂 🙂 … It was interesting to note that desirable levels of desktop controls are more explicitly expressed than I had suspected. In Windows, you have two main categories for ADMIN accounts, (e.g., Domain Admins for the network and local admin authority to the PC). I saw many of the good points shared encompassing both of these key control points.
    In my own sharing, I was centering my thoughts around the aspect that SOX won’t mandate restrictive access to desktop explicitly, as some users need to install software themselves (or have applications that won’t run properly). However based on the factors milan shares, companies will indeed want to tighten desktop controls to better mitigate security risks and be more compliant with SOX guidelines.
    I wasn’t certain in the original post if this was pertinent to the Mac System X environment or Windows XP (as recently there was an announcement that Mac systems can now run in XP mode). I’m guessing System X is used as the OS environment and that there are concerns in granting root level access (similar to the local ADMIN issue).
    Maybe in working with security professionals access rights can be adjusted. Maybe root level access is not needed for System X, but some escalation of privileges in the user account to install software? I’m not well versed in this area.
    I’ve experiemented some with Linux from an educational standpoint. As another idea, one master ADMIN account can be created (with root level access) and to create a secondary USER account for your routine day-to-day usage (that’s what I’ve always done personally). When you need to install software you’d use your ADMIN account and then switch back to the your normal user account for normal day-to-day usage.
    Hopefully, our original poster will be empowered with a good fit between meeting business needs and improved security controls. It’s definitely a challenge to meet both goals effectively sometimes.

  • that writes to the Windows registry and requires ADMIN authority to even work on your PC Yes, definitely avoid software that requires Administrator rights for normal operations, except of course for security utilities that it is reasonable that they must.
    Perhaps the writing to the registry part needs clarification. It is very normal and common for applications to write to the registry; things such as the most recently used files that appear in the File menu.
    Items in the registry have security rights for the specific items. People can be confused if they try to prevent all access to all of the registry.

Log in to reply