10

The ISO27001:2013 standard (and ISO27002:2013 guidance) requires that use of "utility programs" that might be capable of overriding system and application controls should be restricted and controlled (A.9.4.4).

I've looked, for example, at http://en.wikipedia.org/wiki/Utility_program for inspiration and am finding it difficult to decide what might be considered a "privileged utility program", as most could be "dual use", i.e. if used without privileges they would be safe (and useful!), but with elevated user privileges they could introduce risk.

  • Is this intended to be a policy around setting access permissions for utilities?
  • What policies do other organisations have in this area?
david-ocallaghan
  • 193
  • 1
  • 1
  • 6

4 Answers4

2

Privileged utility programs are applications that require some level of system or administrative privilege to do their jobs.

A good example is an anti-virus application since this requires very low-level access to the system in order to detect certain types of virus.

As you say, not all of the functions of these applications may need privileged access but they will require it for some aspect of their operation.

In general, it is important that users should not have access to privileged functions from their normal user accounts. As soon as they do, it becomes much easier for malware to gain a foothold in a system. It is for this reason that you should not allow administrator accounts to have access to general office software such as email because it becomes trivial to gain access (as a recent audit I am aware of shows all too clearly!).

UPDATE: Just to clarify for your 2 specific questions:

  • Policy for access permissions for utilities: This is hard to manage and is actioned only for certain enterprise tools not for OS level general tools.

  • Other policies:

    Separation of concerns is the main policy. Administrators should have standard accounts for email/office/etc and only use privileged accounts when they are really required.

    Checks on audit logs are also critical for sensitive systems. Without eyes on auditing, you can never be certain what has been happening.

    Annual health checks include phishing attacks against administrators. To help ensure they are adhering to policies and standard security practices.

    Staff may need to be vetted or security cleared for sensitive areas.

    Access to the most sensitive systems (e.g. PKI master CA's) is heavily restricted with additional access logs and justifications.

Julian Knight
  • 7,092
  • 17
  • 23
  • I don't think that AV is a good example. If you tried to apply the guidance in the standard to AV it doesn't make much sense. – JCx May 21 '15 at 13:35
  • AV applications may not be the best example of that part of the standard. However, they are good examples of privileged programmes that people are familiar with. If administrators have access to AV controls, they are able to change settings and weaken security. Access to any privileged application should, therefore, be restricted. Indeed, the use of privileged accounts must be restricted. It is a common mistake to allow administrators to use admin accounts for day-2-day work. This allows social engineering attacks to be devastating. – Julian Knight May 21 '15 at 23:30
  • @JulianKnight: the job of the administrator is to administer the machine, if you have to have a security policy to restrict access to your administrators, then you have a bigger problem. Why are you giving people that aren't qualified to administer the machine administration privilege? – Lie Ryan May 22 '15 at 14:51
  • 1
    Sorry but in a typical enterprise this is not an accurate description. The job of an administrator may be to look after *many* services which may span a great many machines. They will spend a significant amount of time handling emails and documents & they absolutely should not be using a privileged system account for that. This is consistently highlighted in audits and IT Health Checks. – Julian Knight May 22 '15 at 14:55
  • @Julian Knight: if you're in an enterprise who hired a sysadmin that opened emails using their admin account, I would have fired a couple people: the sysadmin and whoever cleared that person for sysadmin privilege. If you can't trust your sysadmin not to know the basics, then you have a bigger issue on hand. – Lie Ryan May 22 '15 at 16:15
  • It is the nature of people to do what they can to make their lives easier. This was an outsourced service. But not everyone knows that this is a bad idea which is why I've highlighted it here. We do phishing attacks against admins as part of ongoing health checks to weed out these sorts of issues. – Julian Knight May 22 '15 at 16:22
2

Practically? In most environments interpret this to include:

  • Windows programs that run as administrator
  • UNIX software with setuid or similar privileges (that includes su and sudo themselves which are setuid).

Is this intended to be a policy around setting access permissions for utilities? That's one way of achieving the goals.

What policies do other organisations have in this area?

I've start with only letting system admins access to server operating systems and therefore only allowing them to use system utilities of any kind (this should implement ISO27002:2013, 9.4.4i, b and c). This is getting easier as more and more applications are delivered via HTTP.

Then system hardening including removing unnecessary utilities would be a good second priority activity.

What was it actually supposed to mean? I've asked this question to at least ten external auditors and not received a consistent answer.

One or two have suggested that it made more sense in the days of certain mainframe operating systems, but I've not seen much primary evidence for this. The only reference was: enter image description here http://pubs.usgs.gov/of/1991/0329/report.pdf

This is for a http://en.wikipedia.org/wiki/RSX-11 system and the manual page is dated 1991.

And you could easily argue that all programs on well designed systems (other than exploits) cannot 'override system security controls'. They may make use of enhanced privileges permitted by the operating system, but certainly don't override the controls.

JCx
  • 480
  • 2
  • 6
  • Not sure how this is meant to help the OP? W apps running as admin are not the only risk. W apps running as SYSTEM for example are an even bigger potential. What does the last para mean? No OS is perfect and therefore there are always applications that are privileged in the way mentioned in the std. – Julian Knight May 21 '15 at 23:35
  • My point, badly made, was that anti-virus for example is not in any way 'bypassing system security controls'. It's making use of system security features to obtain access it needs to function. (Agree ref: SYSTEM and other privileged accounts) – JCx May 22 '15 at 20:33
1

A privileged program for windows (vista+) would be anything that triggers the UAC if enabled

a privileged program for linux (including android) would be anything that needs to be run as root, or via su/sudo

most organizations limit the right of their employees such that they do not have "admin rights", and instead push updates/installs/programs via group policy, using a separate administrator account, rather than the one that the users use for login purposes

user2813274
  • 2,051
  • 2
  • 13
  • 18
  • 2
    Besides programs that need root access, this would also seem to include programs that can override other controls, e.g. via set-group-id programs, or running under accounts that have special (but limited) sudo privileges, etc. – nealmcb Aug 06 '14 at 23:21
0

In terms of defining and implementing a policy, bring such utility programs under the ambit of existing password policy, procedure to get system & service accounts under authorization, avoid defaults, have an inventory of all such utilities, tools, applications that use privileged accounts; Review logs once in a while, review access profile and Monitor.

Having said that, enforcing password policy on such accounts by itself is a more challenging task. If you are a SMB/SME organization, its even more challenging. Somewhere you need to start. You may begin by an inventory of such accounts and review them monthly. This will bring in greater sense of awareness and insights.

Hope this would be useful.

Thiru A
  • 11