Presentation on theme: "Audit Issues regarding Passwords on Elevated Privilege Accounts Gene Scheckel Global Internal Audit."— Presentation transcript:
Audit Issues regarding Passwords on Elevated Privilege Accounts Gene Scheckel Global Internal Audit
Audit Issues on Elevated Privilege Accounts Passwords are not changed regularly. Passwords on shared accounts are not changed when an individual with knowledge of the passwords leaves the department.
Audit Issues on Elevated Privilege Accounts On shared accounts, there is no individual accountability. On shared accounts, passwords are stored in a location that is widely accessible to large group of people.
Audit Issues on Elevated Privilege Accounts Password complexity is not enforced. System default passwords from the software vendor are still active in the production environment.
Business and Policy Considerations for an Electronic Password Vault Richard Leonard Global Information Protection & Assurance 918-661-3918 Richard.firstname.lastname@example.org
1 st Core Standard Network Administration System and application protection Monitoring system security and usage Workforce and staffing –Separate Login ID for administrator –Granting system privileges necessary for them to carry out their jobs –Administration and management of business- critical systems must not become dependent upon a single individual –Immediate withdrawal of system privileges from staff in trusted positions This chapter and associated standards are the minimum requirements to be applied by Information Technology (IT) Administrators in order to secure Company Information Assets. Administrators are in a special position of trust within the Company, being in charge of the critical computer infrastructure and data on which the Company depends, in order to do business. It is therefore vitally important that Administrators read, under- stand and fully implement the contents of this chapter. Standards in this chapter must be used in conjunction with the rest of the standards chapters. References are inserted in applicable sections to point to related chapters.
2 nd Core Standard Logon and Authentication Accounts and accounts management System Access Authentication Password requirements Activity monitoring and logs Local account - a User ID, functional ID, or service ID that is locally used and not defined to be global. Examples are Root (Unix), System (Oracle), and Administrator (Windows) Functional IDs - shared user accounts, usually associated with a role created for various job functions and permissions to perform certain operations Service IDs - non-user accounts assigned to system tasks or business applications
Functional & Service Account Issues Solved With a Password Vault Functional Account –Shared password for many devices known by many Administrators Service Accounts shall not be used for: –Regular interactive login. –Any activity where individual accountability must be maintained –Have annually expiring passwords when more frequent password changes unacceptably increase the risks/business impact associated with password changes
Business Drivers Audit non-compliance findings with PCI, HIPAA, and SOX audits Lack of individual accountability when using shared passwords on privileged accounts Ongoing burden of password changes in application accounts Ongoing break-fix events caused by unsynchronized password changes Ongoing unsecure methods for communicating passwords amongst Administrators Disparate privileged account management models
Balance of Operational and Security Considerations Common functional account use by Administrators Automated password changes for applications and systems Password changes because of staff rotations Reduced break-fix because of password changes Activity monitoring and staff accountability Passwords confidential and protected Multiple passwords for a functional account Strong password maintenance Best practices insider threats Best practices, password change cycle Best practices log monitoring and accountability Passwords encrypted in transit and at rest OperationsSecurity
Risks to Implement a Password Vault New Technology Risk – Password Vault environment –May not implemented correctly –can’t support Information Services effectively on an ongoing basis Support and applications groups resisting a privileged account management model that changes procedures and culture User password maintenance may bypass passwords managed by a password vault Professional services may not be provided on a timely basis Project funding to implement the vault may be constrained Password Vault may not be technically compatible with some applications, devices, and systems Compliance rather than ROI funding justifications Management support and emphasis
Results & Questions Password vault selected Infrastructure architected and implemented Password vaulting efforts initiated Questions at end of joint presentation
Technical Aspects of the Password Vault Glenn Davis Sr. Analyst, Identity Management/Vault Administrator Glenn.R.Davis@email@example.com
Why we chose Cyber-Ark Most Flexibility –Windows (AD and local accounts) –Unix –Cisco IOS –Oracle –Sybase –OS390 –Microsoft SQL Server –.NET (V5.0) –SAP (V5.0) Good Reputation for Reliability and Support Ability to handle hard-coded (scripted) passwords
What is a “Password Vault”? Safe 1 Safe 3 Safe 2 Vault
Password Vault Components Password Vault Web Access Central Password Manager Password Vault Application Password Manager
Retrieving a Password with a Script Set sdk= CreateObject(“COMPasswordSDK.PasswordSDK”) Set PassReq= CreateObject(“CompPasswordSDK.PSDKPasswordRequest”) With PassReq.Safe= “Test”.Object= “Passwo5”.CredFilePath= “C:\CredFiles\AppUser.cred”.Reason= “Just experimenting with EPV” End With Set Pass = sdk.GetPassword(PassReq) With Pass MsgBox “Password is:”&.Content End With