audit issues regarding passwords on elevated privilege accounts gene scheckel global internal audit
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 LeonardGlobal Information Protection & [email protected]
1st Core StandardNetwork 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.
2nd 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 AccountIssues 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
Operations Security
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 DavisSr. Analyst, Identity Management/Vault [email protected]
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 PassMsgBox “Password is:”& .Content
End With
Questions?