Developers w/access to production 2804

  • We are in the process of remediating our developers with access to the production environment. There are discussions about emergency access privileges. Are there any tools out there that can support this function? Are there tools out there that supports some kind of audit trail?.
    Any insights will be appreciated.

  • Hi - Specific tools might be difficult to describe as there are a wide range of IT environments (e.g., web, client/server, mainframes, minicomputers, PCs, Windows, UNIX, etc.)
    However, some key design points include:
    – Setting up IT policies for how Emergency production changes are performed within the organization
    – Setting up IT standards and procedures for Emergency repairs (e.g., how the system works, how to request PROD access, FireIDs, etc)
    – Many companies use special FireID accounts (Login accounts that are checked out from the Production Control Center and are heavily logged when emergency PROD access is granted). This way normal user accounts won’t need regular write access there. Passwords for FireID accounts usually rotate every 24 hours. Always record who checks out a priviledged account
    – Special corrections must be documented electronically (e.g., trouble ticket system, change management, etc)
    – Ensure audit (internal and external) approves and buys into the final solution … get their advice up front in designing an approach
    – IT security must monitor and evaluate FireID accounts regularly to look for any inappropriate uses of PROD access privileges
    – Sharepoint might provide a facility to capture information efficiently and inexpensively by setting up special libraries to store incidents (that can later be shown to audit in review of the new controls)

  • Thanks for the response. In creating FireID accounts. What tools can be used for such monitoring.

  • Fire IDs can be established without the need to purchase any special software or tools. Some ideas are as follows:
    – Use a special login account: FIRE001, FIRE002, FIRE003 … Put them all in a special Windows security group (or other operating systems as required)
    – Give the new FIREID Security group the right level of privileges using a minimum security approach (e.g., just enough privileges to get the job done – for example, update to DBs may be allowed by not deletion, or don’t allow changes to the O/S)
    – Set a 24 hour only password (and if folks need more time they check another one)
    – Let IT security set special complex passwords as these are issued to developers
    – Set up Windows (or other operating systems) to audit login, logoff, access to production DBs, etc.
    – Using email or change management software, document who, when, or why a FireID was requested and log it
    – Key access performed by the IT developer should be reviewed to ensure no information was altered in an unauthorized manner. This can be accomplished using security management tools like Bindview reporting or examination of the logs.
    – Auditors definitely like to see that privileged access is actively monitored, so this step should not be neglected.

Log in to reply