ISO27001：2013規格の「特権ユーティリティプログラムの使用」とはどういう意味ですか？
ISO27001：2013標準（およびISO27002：2013ガイダンス）では、システムとアプリケーションの制御を上書きできる「ユーティリティプログラム」の使用を制限および制御する必要があります（A.9.4.4）。
たとえば、インスピレーションを得るために http://en.wikipedia.org/wiki/Utility_program を調べたところ、「特権ユーティリティプログラム」と見なされるものを決定するのが困難であることがわかりました。ほとんどは「デュアルユース」である可能性があります。つまり、特権なしで使用した場合、それらは安全です（そして便利です）。
- これは、ユーティリティのアクセス許可の設定に関するポリシーを意図したものですか？
- この分野で他の組織はどのようなポリシーを持っていますか？
Windows（Vista +）の特権プログラムは、有効になっている場合にUACをトリガーするものです。
linux（Androidを含む）の特権プログラムは、rootとして、またはsu/Sudoを介して実行する必要があるすべてのものです。
ほとんどの組織は、「管理者権限」を持たないように従業員の権利を制限し、代わりに、ユーザーがログイン目的で使用するものではなく、別の管理者アカウントを使用して、グループポリシーを介して更新/インストール/プログラムをプッシュします。
特権ユーティリティプログラムは、ジョブを実行するために一定レベルのシステム特権または管理特権を必要とするアプリケーションです。
特定のタイプのウイルスを検出するためにシステムへの非常に低レベルのアクセスが必要なため、アンチウイルスアプリケーションが良い例です。
あなたが言うように、これらのアプリケーションのすべての機能が特権アクセスを必要とするわけではないかもしれませんが、それらはそれらの操作のある側面のためにそれを必要とします。
一般に、ユーザーが通常のユーザーアカウントから特権機能にアクセスできないようにすることが重要です。マルウェアがシステムに足を踏み入れるとすぐに、マルウェアがはるかに簡単になります。このため、管理者アカウントに電子メールなどの一般的なオフィスソフトウェアへのアクセスを許可しないでください。これは、アクセスを取得するのが簡単になるためです（最近の監査では、私が知っているのは非常にはっきりしていることです！）。
更新：2つの特定の質問を明確にするために：
- ユーティリティのアクセス許可のポリシー：これは管理が難しく、OSレベルの一般的なツールではなく、特定のエンタープライズツールに対してのみ実行されます。
その他のポリシー：
懸念の分離が主な方針です。管理者は、電子メール/オフィスなどの標準アカウントを持ち、本当に必要な場合にのみ特権アカウントを使用する必要があります。
機密性の高いシステムでは、監査ログのチェックも重要です。監査に目を向けないと、何が起こっているのかを確実に知ることはできません。
年次ヘルスチェックには、管理者に対するフィッシング攻撃が含まれます。ポリシーと標準のセキュリティ慣行を順守していることを確認するため。
機密性の高い領域については、スタッフを吟味するか、セキュリティをクリアする必要がある場合があります。
最も機密性の高いシステム（PKIマスターCAなど）へのアクセスは、追加のアクセスログと正当化により厳しく制限されています。
実際には？ほとんどの環境ではこれを解釈して以下を含めます：
- 管理者として実行されるWindowsプログラム
- Setuidまたは同様の特権を持つUNIXソフトウェア（setuidであるsuおよびSudo自体を含む）。
これは、ユーティリティのアクセス許可の設定に関するポリシーを意図したものですか？これは、目標を達成する1つの方法です。
この分野で他の組織はどのようなポリシーを持っていますか？
私は、システム管理者にサーバーオペレーティングシステムへのアクセスのみを許可し、あらゆる種類のシステムユーティリティの使用のみを許可することから始めました（これにより、ISO27002：2013、9.4.4i、b、cが実装されます）。 HTTP経由で配信されるアプリケーションが増えるにつれて、これはより簡単になります。
次に、不要なユーティリティの削除を含むシステムの強化は、2番目に優先される優れたアクティビティです。
実際にはどういう意味でしたか？この質問を少なくとも10人の外部監査人に依頼しましたが、一貫した回答がありませんでした。
1つまたは2つは、特定のメインフレームオペレーティングシステムの時代にはそれがより理にかなっていると示唆していますが、これについての主な証拠はあまり見かけません。唯一のリファレンスは： 
http://pubs.usgs.gov/of/1991/0329/report.pdf
これは http://en.wikipedia.org/wiki/RSX-11 システム用で、マニュアルページの日付は1991年です。
また、適切に設計されたシステム上のすべてのプログラム（エクスプロイトを除く）は「システムのセキュリティ制御を無効にする」ことができないと簡単に主張できます。それらはオペレーティングシステムによって許可された拡張された特権を利用するかもしれませんが、確かにコントロールを上書きしません。
ポリシーの定義と実装に関しては、そのようなユーティリティプログラムを既存のパスワードポリシーの範囲内に持ち込み、システムおよびサービスアカウントを許可の下で取得する手順を行い、デフォルトを回避し、特権アカウントを使用するすべてのユーティリティ、ツール、アプリケーションの一覧を作成します。時々ログを確認し、アクセスプロファイルと監視を確認します。
そうは言っても、このようなアカウントにパスワードポリシーを適用すること自体は、より困難な作業です。あなたがSMB/SME組織である場合、それはさらに困難です。どこかで始める必要があります。そのようなアカウントのインベントリから始めて、毎月それらを確認することができます。これにより、意識と洞察の感覚が高まります。
これが役立つことを願っています。