|
Segregation of Duties for IT Personnel
The Sarbanes-Oxley Act section 404, as well as other acts and regulations, such as the Health Insurance Portability and Accountability Act (HIPAA), the Federal Financial Institutions Examination Council (FFIEC) guidelines, Public Company Accounting Oversight Board (PCAOB) guidelines, and the Basel II Accord stipulate a stronger emphasis on enforcing segregation of duties and the concept of least-privileged user accounts in critical environments, for both business users as well as IT personnel.
Separating developers from the production environment and keeping their access privileges to the bare minimum are also basic security "best practices" stipulated in COBIT (Control Objectives for Information related Technologies) Security Baseline (DS 25), ISO 1799 (sections 9.1, 9.2, 9.6), and ITIL (Application Management Publication Security Management Book).
Developers' Access to Production Requirements
A specific requirement for segregation of duties in IT is the separation of developers from the production environment. This is considered a regulatory demand, as well as a fundamental security best practice.
Developers' Access to Production is a Frequent "IT Controls" Deficiency
When developers also serve as support for production applications (A.K.A Third Level Support) they require access to the production environment in order to identify the root cause of applications problems. This results in numerous and frequent accesses to the production environment.
Access Controls and Change Management Systems were not designed to enforce segregation of duties in this scenario.
High Risks Associated with Developers Access to Production
The risks organizations incur when developers access production are categorized into two main areas:
 |
1. |
Threats to the Integrity of the Production Environment: |
| |
• |
Unintentional changes such as diagnostic patches |
| |
• |
Malicious changes such as Trojan horses |
|
| 2. |
Privacy Risks: Loss of private customer data (e.g., social security numbers, credit card numbers) with the potential for significant financial losses (fraud) and damage to the company's reputation (publicity focused on privacy-loss notification) |
BMC Application Problem Resolution Eliminates the Need for Developers to Access Production
BMC Application Problem Resolution ELIMINATES developers access to production by securely extracting the information the developers need for application problem resolution. The solution is based on the following steps:
- Capture: BMC Black Box software transparently captures a complete record—from user actions to code-level trace—of the uncovered defect creating a comprehensive record of everything within the application and its environment. This includes all interactions between the database, operating system, and network, as well as a play-by-play actual recording of every key stroke and every mouse click that preceded the error.
- Extract: All of the relevant data that the developer will need to investigate the problem is extracted and sent to a secure repository.
- Access: Developers are granted access to the secure repository based on least-privilege policies and can identify the root cause of the problem without accessing the production environment. All access is based on Read-only privileges.
- Analyze: The BMC Application Problem Resolution Console enables application team members to analyze captured problem data at different levels and drill down for root cause identification. The BMC Black Box log can be replayed and analyzed to quickly pinpoint the root cause of all kinds of Microsoft Windows, .NET, and J2EE application problems, whether related to performance, configuration issues, user mistakes, or code errors
Once the root cause of the problem has been identified and the developers have created a solution, it is then applied to the production environment according to incident handling processes in the change management policies.
For more information please see:
Have a BMC Application Problem Resolution compliance specialist contact you
|
