It has become axiomatic that financial sector organizations sit at the top end of the scale for security and reputational risk. Banks and finance firms are built on customer data and criminals are drawn to that as surely as are regulators tasked with ensuring companies safeguard it to the required legal standards.
Unfortunately, networks are necessarily built from a number of insecure elements, starting with desktop and laptop PCs. A growing theme in this area has been the use of administrator rights to enable not only common everyday software but the legacy applications that are now a fundamental part of modern banking and finance.
A consensus has emerged that unmanaged administrator rights pose a critical security challenge, making possible malware attacks that exploit elevated privileges and encouraging employees to run unauthorised applications that generate inadvertent, unquantifiable risk.
Privilege management is a practical solution to the problem of the ‘loosely-managed’ desktop. The following is an outline of the key business, technical and implementation considerations when assessing an investment in such technology.
Rationale
The first task is to clearly define the benefits of a privilege management project, which will vary even between organisations in the financial services sector depending on their application infrastructure. A few themes will be common to all.
Security: the permissive elevation of admin privileges is an obvious security risk. Users can potentially run unauthorised software or even malware. Malware attacks routinely ask for such privileges so these represent a significant security vulnerability.
Compliance: policing admin rights has become a regulatory issue not only to meet legal requirements imposed in some countries but to satisfy independent audits. The global nature of financial services means that the toughest regulation is always the one to worry about.
Efficiency and cost: there is a potential to reduce helpdesk workload. Low-level functions (e.g. power management, connecting to local printers) can be granted without staff involvement, based on policies. These policies will also regulate all application elevation, again lowering the authorization overhead.
With the rationale in place, the technical goal of the project should be explained clearly. This will usually be that an organisation wants to end up with a design in which every user has become a ‘standard user’, that is a user with the least privileges needed to do perform their roles. The only exceptions to this will be a small number of elite administrator accounts defined as individuals requiring such privileges in order to directly manage applications and users or to oversee this role.
No compromise. In order to deliver the benefits of security and compliance mentioned above, administrator accounts must be pruned to an absolute operational minimum. Because this invariably means removing rights from groups of users that have grown used them the first stage is to carry out an audit.
By Avecto’s calculation, the number of users in financial services with admin rights can be as high as 5-10 percent so the problem should not be underestimated. The maxim of ‘least privilege’ is the mission statement and guiding principle and essential for desktop compliance.
Planning
Stage one is to perform an audit using some form of passive monitoring for roughly three months. How privileges are being distributed will be known but not necessarily who has received them and to which resource so this information will help build an application rights map. Depending on the current modus operandi, some privileges will be ‘rogue’ that is unmanaged and unrevoked.
It will be an aid to divide users into at least three categories: administrators, standard office users and special cases, for instance those accessing special applications or departmental heads and in-house developers.
The applications themselves must also be audited. Bear in mind that once an organization has implemented a privilege management system, these policies will be subject to constant modification as new applications are added or as ones already known about are gradually added to a controlled list.
At this stage a baseline should be established using a reporting tool (see conclusion): this will offer a ‘before’ and ‘after’ comparison with which to assess a project’s success and to identify wrinkles. All privilege management systems will come with reporting but this element is the single biggest aid to implementation and must meet an organisation’s requirements to the level of detail required.
Pilot
Because implementing privilege management is a major project for any large organization, the best place to start is by identifying a department that can be used to roll out a three to six-month pilot with the minimum disruption. The has the double purpose of testing the implementation at a technical and user level but also of communicating its imminent arrival to a relatively small group the better to model likely complaints.
Armed with monitoring data, the project heads must assess use and policy elevation cases for specific applications after inviting users to register them using a web-based pick list, eliminate false positives (i.e. applications that ask for admin rights but will work without them), and identify applications that should be blocked.
During the monitoring and pilot phases, profiles (different types of application user) must be finalised from this and policies designed to meet the requirements of each based on least privilege. The ‘special cases’ will require the most thought.
The organisational challenge
Implementing least privilege control presents a significant cultural change for organisations on a number of levels. All users will find that their interaction with applications has changed and the project team must model how people relate to the new system. A smaller group of users will find that their access to some applications and functions has become more restricted; this underlines the political hurdles facing such a project. The workflow of communicating the new regime will be time-consuming.
Communicating clearly with users in a step-by-step manner is essential by outlining the various stages and timeline of the project, including the schedule for notification where admin rights will be removed and who is affected. A detailed FAQ will have to be drawn up to explain this and common issues.
How do you know a project has worked?
Choosing a privilege management product that can perform the basic functions of account and application discovery is mandatory. But the final essential component is a reporting framework, essential for demonstrating to auditors that the policy design is not only consistent but has been implemented. Without this it will be impossible to assess the success of a least privilege project let alone manage it on a day to day basis.
Ideally, this should automate the reporting process as far as possible, offering pre-defined reports for use at every stage of the process, including application and privilege discovery, the types of elevation requested and applications that have been blocked.
Such software will generate reports compatible with a central database (say, SQL) and possibly an external higher-level management system. The requirements will vary by organisation but the data gathered here is essential for auditing. As previously noted, the report will also offer a ‘before’ and ‘after’ view of privilege use in the organization.
Without reporting there can be no auditing oversight. Without that there can be no compliance.