News Article
The dangers of privilege
keeping the secrets in and privacy invaders out. How best to safe guard the companies privates during an era of multi user access and privileged account holders. Calum Macleod, European Director of Cyber-Ark, discusses a plan of defence.
I never used to have to look for the telephone - it was always in the hall. But now we have this wonderful DECT system in the house with telephones in key locations, such as my daughter's bedroom, usually under an Everest-like mountain of clothes. No matter how often we've agreed that the person who last used the phone should put it back in its rightful place, it still seems that every time it rings the hunt is on. Personally I think that the policy of returning the telephone to its rightful place is a good policy, my problem is enforcement, and I haven't got the time to monitor personally 24x7.
One of the biggest issues facing organisations is the elimination of bad practices related to the use and abuse of privileged accounts. Organisations frequently suffer from unrealistic policies that are being bypassed, usually because of a lack of resources, or having no policies with the result that there is no control. It is therefore worth while considering some of the most common problems, and suggesting ways in which these can be improved.
User Accounts have Super User or Administrative Rights - In general an organisation should never allow any user account to have Privileged Access. In many organisations IT staff will create user accounts with administrative rights. This is frequently the case with UNIX systems where the root account is normally not accessible remote from the system. The problem with this approach is that the actual user will frequently tend to use their specific user account for general access. This will result in serious problems when audits are conducted since IT Security are faced with the problem of trying to decipher which log-ins were simply for general access, and which were for specific administrative tasks. In certain environments this practice can also expose the system to Trojan horse attacks, particularly in the Windows environment.
Recommendation - Since it will always be necessary to have shared accounts for services such as access to UNIX environments, and in some case Windows environments, the password for the shared accounts should be kept in a secure location, and the number of user accounts with privileged access must be kept to a minimum and passwords for these accounts must be changed on a regular basis. Additionally access to the password for the shared account and the administrative/ root/service passwords should be only available based on a "need to have "basis which must be in the policy. By default every access to any of these passwords must have an audit trail.
Every shared account must have an account owner(s) who is responsible for controlling access to the account. This should allow for contingency procedures where any member of the responsible group can be authorized to release the password. All Systems Share the same Privileged Passwords - This all too common practice means that systems are grouped according to categories, and all systems will share the same privileged passwords. This is a common practice in Windows environments where frequently all service accounts will share the same password, with the obvious result that having got the password for one service account, all accounts are now accessible. Recommendation - Every Privileged account must have its own unique password and should be configured to change at least every 30 days. Service Accounts are not secured - A Service Account such as the account to manage an Active Directory will be used regularly but represents a serious security risk for an organisation.
Frequently administrators will use their privileges to set up service accounts, and when staff leave an organisation these accounts are overlooked. Although Service Accounts can have a useful purpose in ensuring that a specific user is only allowed the privileges necessary to do their function, these accounts must still either be assigned to specific users (if possible), resulting in considerable additional IT Security administration, or must be shared among a group of privileged users.
Recommendation - Service Account Passwords should be kept securely and be changed very frequently. Accounts have Non-Expiring Passwords – This situation is found commonly in two scenarios; either administrative or service accounts are set to non-expiry, or embedded accounts which are coded in scripts, especially database applications have non-expiring passwords.
In both cases these accounts represent a major security flaw since they are vulnerable to password cracking tools since the password never expires, and in the case of embedded accounts all personnel involved in the development and maintenance lifecycle have knowledge of the account detail. Using embedded accounts is a relatively easy way for someone to access sensitive data without being traced.
Recommendation - All non-expiring accounts should be modified so that they change the passwords on a regular basis. Additionally since these accounts provide privileged access, no single individual should be allowed to change the passwords manually. Policies are not applied to users universally – It is not uncommon to see organisations apply different standards to different staff. For example, managers have root access to all servers, and developers, and testers have root access to all development servers. It is imperative that organisations apply a consist policy for all staff, regardless of function or position.
Recommendation - The use of any privileged account must have the accompanying audit trail. Consideration should be given to differing policies for development and production systems. For example, privileged access to a production system should only be possible with dual control, whereas a development system password may be accessible, within certain environments, without the need for dual control. Both production and development systems should be changed on a regular basis Policies are not applied to groups universally - Frequently organisations will not have a consistent procedure between different groups. This results in various departments (Databases, UNIX, Windows, Mainframe, Networking, etc) working as independent entities without a consistent security policy.
Recommendation - All groups, regardless of responsibility or location should adhere to a common policy. This implies that policies related to how passwords are released, and the frequency of change should apply across the board. Guest IDs are set up with Privileged Access but are not deactivated - Since many organisations depend on outsourcing or contract staff, or will frequently have technical support from vendors, requiring privileged access to specific systems. In fact there should not be a reason to define a Guest Privileged Account.
Recommendation - External staff should never have privileged access to a system using a Guest Account. Access should use the default account, and the passwords should be immediately reset on completion of the task. Administrators have access directly with Privileged Accounts - For practical reasons it is never possible to completely isolate direct access to systems. Frequently privileged users will be required to access a system from the system console, and in this case the user can always try the root or admin accounts if they have access to the password.
Recommendation - The password must only be released under strict controls, and the policy must ensure that the password is directly changed after each use. Emergency Envelope (Firecall) Accounts – These accounts are designed for use in specific emergency situations. In many cases the procedure is a manual procedure that requires that a password is placed in an envelope, and based on a security policy, access to the envelope is controlled.
Recommendation - Each use of this procedure should require that a designated member of each team is responsible to report each use to IT Security, and the password should be changed within a minimum time period after the user has finished the necessary task. If possible those responsible for releasing the passwords should not be able to know the password. A daily audit report should be carried out to advise use of any Firecall accounts. Multiple IT Security staff should be designated as having approval rights to authorize use, with a best practice of dual control.
Best Practice is Vital
In order to ensure an organisation protects its interests, it must ensure clear policies and standards are in place to manage and control administrative access. Ultimately the most effective approach is to ensure that the number of privileged accounts on systems is kept to an absolute minimum. This will significantly ease the administrative burden for the organisation, and with effective password management access is controlled at the entrance.
The more effective the controls at the entrance, the less one has to worry about having distributed controls. Practice has shown that once the number of individuals who may access a system exceeds three, it becomes exponentially difficult to mange the process. The more user accounts that are defined with privileged access the closer the auditors are going to look at the policies, and especially the adherence to the policies.
Other areas to consider are ensuring that users are only given access if all the conditions are correct, such as are they on duty, are in they in an appropriate location (releasing privileged passwords to the user in an Internet Café with VPN access is not appropriate policy no matter how urgent the situation).
Changing passwords regularly is a necessity, and not repeating passwords within certain time periods is a must. Also it becomes critical to maintain old passwords in a secure location since you never know when a particular system needs to be recovered.
It is important to understand that organisations should allocate privileges on a restricted basis, such as on an event basis, or a need to use basis, and that a detailed record is kept regarding what privileges have been given and to whom, when, for what purpose, where and when this was given, and who approved this request - for every single event. And of major importance ensuring that all authorisation processes are completed, in the correct sequence before privileged access is allowed.
There are many technical solutions created to try and protect the privileged systems and applications to ensure that they are not vulnerable, but ultimately it is impossible to ensure that an infrastructure can be built that is 100% secure. It is therefore imperative that the strictest controls possible are applied in providing access to passwords that are the keys needed to open each and every privileged account.
The challenge that has to be answered is how to ensure requirements are enforced. In my opinion the only way to deal with this effectively is with a password management technology that enables the most repetitive processes to be automated, and allows IT Security departments to enforce their policies. And as far as the telephone goes I'm thinking a piece of string and super-glue might be the answer.
One of the biggest issues facing organisations is the elimination of bad practices related to the use and abuse of privileged accounts. Organisations frequently suffer from unrealistic policies that are being bypassed, usually because of a lack of resources, or having no policies with the result that there is no control. It is therefore worth while considering some of the most common problems, and suggesting ways in which these can be improved.
User Accounts have Super User or Administrative Rights - In general an organisation should never allow any user account to have Privileged Access. In many organisations IT staff will create user accounts with administrative rights. This is frequently the case with UNIX systems where the root account is normally not accessible remote from the system. The problem with this approach is that the actual user will frequently tend to use their specific user account for general access. This will result in serious problems when audits are conducted since IT Security are faced with the problem of trying to decipher which log-ins were simply for general access, and which were for specific administrative tasks. In certain environments this practice can also expose the system to Trojan horse attacks, particularly in the Windows environment.
Recommendation - Since it will always be necessary to have shared accounts for services such as access to UNIX environments, and in some case Windows environments, the password for the shared accounts should be kept in a secure location, and the number of user accounts with privileged access must be kept to a minimum and passwords for these accounts must be changed on a regular basis. Additionally access to the password for the shared account and the administrative/ root/service passwords should be only available based on a "need to have "basis which must be in the policy. By default every access to any of these passwords must have an audit trail.
Every shared account must have an account owner(s) who is responsible for controlling access to the account. This should allow for contingency procedures where any member of the responsible group can be authorized to release the password. All Systems Share the same Privileged Passwords - This all too common practice means that systems are grouped according to categories, and all systems will share the same privileged passwords. This is a common practice in Windows environments where frequently all service accounts will share the same password, with the obvious result that having got the password for one service account, all accounts are now accessible. Recommendation - Every Privileged account must have its own unique password and should be configured to change at least every 30 days. Service Accounts are not secured - A Service Account such as the account to manage an Active Directory will be used regularly but represents a serious security risk for an organisation.
Frequently administrators will use their privileges to set up service accounts, and when staff leave an organisation these accounts are overlooked. Although Service Accounts can have a useful purpose in ensuring that a specific user is only allowed the privileges necessary to do their function, these accounts must still either be assigned to specific users (if possible), resulting in considerable additional IT Security administration, or must be shared among a group of privileged users.
Recommendation - Service Account Passwords should be kept securely and be changed very frequently. Accounts have Non-Expiring Passwords – This situation is found commonly in two scenarios; either administrative or service accounts are set to non-expiry, or embedded accounts which are coded in scripts, especially database applications have non-expiring passwords.
In both cases these accounts represent a major security flaw since they are vulnerable to password cracking tools since the password never expires, and in the case of embedded accounts all personnel involved in the development and maintenance lifecycle have knowledge of the account detail. Using embedded accounts is a relatively easy way for someone to access sensitive data without being traced.
Recommendation - All non-expiring accounts should be modified so that they change the passwords on a regular basis. Additionally since these accounts provide privileged access, no single individual should be allowed to change the passwords manually. Policies are not applied to users universally – It is not uncommon to see organisations apply different standards to different staff. For example, managers have root access to all servers, and developers, and testers have root access to all development servers. It is imperative that organisations apply a consist policy for all staff, regardless of function or position.
Recommendation - The use of any privileged account must have the accompanying audit trail. Consideration should be given to differing policies for development and production systems. For example, privileged access to a production system should only be possible with dual control, whereas a development system password may be accessible, within certain environments, without the need for dual control. Both production and development systems should be changed on a regular basis Policies are not applied to groups universally - Frequently organisations will not have a consistent procedure between different groups. This results in various departments (Databases, UNIX, Windows, Mainframe, Networking, etc) working as independent entities without a consistent security policy.
Recommendation - All groups, regardless of responsibility or location should adhere to a common policy. This implies that policies related to how passwords are released, and the frequency of change should apply across the board. Guest IDs are set up with Privileged Access but are not deactivated - Since many organisations depend on outsourcing or contract staff, or will frequently have technical support from vendors, requiring privileged access to specific systems. In fact there should not be a reason to define a Guest Privileged Account.
Recommendation - External staff should never have privileged access to a system using a Guest Account. Access should use the default account, and the passwords should be immediately reset on completion of the task. Administrators have access directly with Privileged Accounts - For practical reasons it is never possible to completely isolate direct access to systems. Frequently privileged users will be required to access a system from the system console, and in this case the user can always try the root or admin accounts if they have access to the password.
Recommendation - The password must only be released under strict controls, and the policy must ensure that the password is directly changed after each use. Emergency Envelope (Firecall) Accounts – These accounts are designed for use in specific emergency situations. In many cases the procedure is a manual procedure that requires that a password is placed in an envelope, and based on a security policy, access to the envelope is controlled.
Recommendation - Each use of this procedure should require that a designated member of each team is responsible to report each use to IT Security, and the password should be changed within a minimum time period after the user has finished the necessary task. If possible those responsible for releasing the passwords should not be able to know the password. A daily audit report should be carried out to advise use of any Firecall accounts. Multiple IT Security staff should be designated as having approval rights to authorize use, with a best practice of dual control.
Best Practice is Vital
In order to ensure an organisation protects its interests, it must ensure clear policies and standards are in place to manage and control administrative access. Ultimately the most effective approach is to ensure that the number of privileged accounts on systems is kept to an absolute minimum. This will significantly ease the administrative burden for the organisation, and with effective password management access is controlled at the entrance.
The more effective the controls at the entrance, the less one has to worry about having distributed controls. Practice has shown that once the number of individuals who may access a system exceeds three, it becomes exponentially difficult to mange the process. The more user accounts that are defined with privileged access the closer the auditors are going to look at the policies, and especially the adherence to the policies.
Other areas to consider are ensuring that users are only given access if all the conditions are correct, such as are they on duty, are in they in an appropriate location (releasing privileged passwords to the user in an Internet Café with VPN access is not appropriate policy no matter how urgent the situation).
Changing passwords regularly is a necessity, and not repeating passwords within certain time periods is a must. Also it becomes critical to maintain old passwords in a secure location since you never know when a particular system needs to be recovered.
It is important to understand that organisations should allocate privileges on a restricted basis, such as on an event basis, or a need to use basis, and that a detailed record is kept regarding what privileges have been given and to whom, when, for what purpose, where and when this was given, and who approved this request - for every single event. And of major importance ensuring that all authorisation processes are completed, in the correct sequence before privileged access is allowed.
There are many technical solutions created to try and protect the privileged systems and applications to ensure that they are not vulnerable, but ultimately it is impossible to ensure that an infrastructure can be built that is 100% secure. It is therefore imperative that the strictest controls possible are applied in providing access to passwords that are the keys needed to open each and every privileged account.
The challenge that has to be answered is how to ensure requirements are enforced. In my opinion the only way to deal with this effectively is with a password management technology that enables the most repetitive processes to be automated, and allows IT Security departments to enforce their policies. And as far as the telephone goes I'm thinking a piece of string and super-glue might be the answer.
