そして、なぜ、実際には？
別の答えがあるかもしれません：賢明な指導者の指示に従う、外部の要件を正式に順守する、神秘的な「ベストプラクティス」を導入したい、または会社の安全規則を形式化する必要があります（毎回説明するのではなく）
セキュリティポリシーは、ITの機能、ISの機能、および何をどのように保護するかに関するビジネスの主要ユーザー間の内部合意の固定であると想定しています。 この簡単な言葉遣いは、優先順位付け、リソース計画、実用的な実装方法の合意、および（行われていない）制御メカニズムなど、いくつかの重要なトピックを隠しています。 私たちは美しく正確なポリシーを書くだけでなく、実際にその実装を達成する必要があることを思い出させてください。
言い換えれば、セキュリティポリシーは「ゲームの統一ルール」を確立し、関係するすべての同志のガイドラインであり、法律および外部のレビュー担当者の多くの正式な要件を閉じ、また情報セキュリティ部門の爆発的な活動の明白な証拠で経営陣を喜ばせます。
親愛なる読者
セキュリティポリシーを作成するときは、対象読者を想像することが不可欠です。 取締役会の副議長、システム管理部門の長、および通常の倉庫従業員に等しく適した文書を書くことができるとは考えられません。
通常、プレゼンテーションは管理者向けに準備されます（アクションプラン、問題を解決するためのオプション、または結果について通知する必要がある場合）。したがって、そのようなドキュメントの構造は他の機能ユニットのマテリアルと変わりません。 ユーザーの安全規則に関しては、これは読んだ後に署名欄があるページ上のメモか、美しい写真を使った遠隔学習システムのための資料です。
セキュリティポリシーの対象読者は、ITシステムの開発、実装、およびサポートに何らかの形で関係しているIT部門、情報保護部門、プロジェクトオフィス、主要ユーザー、およびその他すべてのオフィス居住者のヘッドとスペシャリストです。 また、私たちの組織で同様の機能を実行する請負業者やコンサルタントも忘れないでください。
ターゲットオーディエンスを正確に理解すると、セキュリティポリシーに含める要件と削除する要件に影響する優れたフィルターが得られます。 その後この要件を機能させるために使用する表現。 古典的なパスワードポリシーの例でこれを説明しますが、必要なパスワードの品質に対する考えられる異議を無視します。
パスワードには、少なくとも1つの大文字と1つの数字を含む、少なくとも6文字が含まれている必要があります。および代替オプション：
ユーザーが選択したパスワードに、少なくとも1つの大文字と1つの数字を含む少なくとも6文字が含まれていることを確認する必要があります。最初のステートメントはユーザーのセキュリティルールに最適であり、（指令ではなく）参照順でありますが、2番目のステートメントはITシステムの技術的なセキュリティ要件として完全に実装できます。
議論する前に
用語と定義は、将来のポリシーの最も重要なセクションの1つです。 読者（および非常勤のパフォーマー）に主題の明確な考えを与え、本文で提示されるすべての要件をより理解しやすくするために、適切な定義が必要です。
定義は法律、標準、またはウィキペディアから取得するのが最も簡単ですが、読みやすく、セキュリティポリシーを作成している組織の特性を満たすことができるという事実ではありません。 したがって、重要な用語については、上記のソースを参照して、自分で定義を記述する方が簡単で良い場合があります。
実践では、ポリシー開発を数回繰り返した後、用語集には高度に専門化された概念（2要素認証など）や、より汎用的なエンティティ（サーバー、モバイルコンピューターなど）以前に他のポリシーや組織の一般的な用語集で定義されていません。
法と秩序
用語と定義を理解したら、ドキュメントのコンテンツの構造を見てみましょう。 一般的に受け入れられているアプローチは、国際標準ISO 27002（または対応するGOST）のセクションの構成を採用するか、情報保護の基本原則を包括的に説明する他のソースに基づいています。 セクションの構造と内容の両方が、組織のプロファイルによって大きく異なる可能性があることは明らかです。
例として、開発されたポリシーに反映することが理にかなっているトピックの最小セットをリストします。
- 組織構造と保護対象（誰が、何を、なぜ保護するか-リスク、資産の分類、役割と責任の配分について）
- アクセス制御（実際には、プロセス参加者と保護オブジェクトの相互作用のルール）。
- 変更管理（システムが1つの状態から別の状態に安全かつ制御して移行する方法について）。
- 監視と監査（セキュリティの現在の状態を評価および確認する方法）。
明らかに、セクションのリストはより小さな部分に分割され、他の重要なトピックで補足されますが、上記のオプションの利点の1つは最小性と十分性であるようです。
まあ、セマンティックの観点から重要なもう1つの詳細-セキュリティポリシーは、記述的（「現状のまま」、現在の状態が修正される）またはディレクティブ（「to be」、実行されるべき）です。 通常、「既に行われている」よりも「行われる」よりはるかに少ないので、指示オプションは読みやすく、その後の使用にとって論理的です。
そして、審査員は誰ですか？
組織に参照情報を管理する部門や、規制文書の作成という困難なタスクを支援する他のスタッフがいると便利です。 存在しない場合は、ドラフトと既に承認されたポリシーの単一のリポジトリ、バージョンの割り当て手順、そしてもちろん、ドキュメントの標準テンプレートを忘れないでください。 これは最初は少し冗長に見えるかもしれませんが、その後のバージョンのポリシーを開発する際には非常に貴重です。
直接フィードバックを得るには、選択した同僚にドラフト文書へのリンクを提供し、読書の結果について質問することを提案することをお勧めします。 書き直されたポリシーが、たとえば、頑固なシステム管理者であるシークレットサービス部門のベテランであるセルゲイステパノビッチと誇り高いPMI証明書保有者のイヴァンによって理解された場合、最も厳格な文書品質管理が合格したと想定できます。
そしてもう一つ。 ポリシーの主要な作業が完了するとすぐに、スペルと句読点の規則を確認する必要があります。 確かに、あなたよりも彼らをよく知っている組織の従業員が少なくとも1人はいるでしょうし、テキストで見つかったエラーについて喜んでみんなに話す機会を逃さないでしょう。
同意と和解
ご存じのように、規制文書を承認するプロセスは、特定の不便な言葉遣いの口頭での戦いから始まり、必要な署名のセットを取得するために教室での探求で終わる別の歌です。 間接的な方法で、この段階の複雑さがセキュリティポリシーの更新頻度に影響し、したがって、書かれたテキストの実用的な有用性に影響することに注意してください。 誰もこのアクションに再度参加することを望まないため、ドキュメントは完全に調整され承認される前に古くなることがよくあります。
この段階で無意味な動きを減らし、セキュリティポリシーを調整する手順を簡素化するために、次のスキームが提案され、正常にテストされました。
- コンサルタントとして文書を作成するために、調整が行われる部門の主要な従業員が関与します。 これにより、プロセスへの関与の感覚が強調され、すでに採用されているポリシーの実施を拒否するリスクが軽減されます。
- 管理レベルでは、通常の紙の方法で、ITおよびISポリシーの調整が電子形式で実行され、ドキュメントの承認の事実が企業ポータルでのポリシーの次のバージョンの公開であるという合意が行われます。 必要に応じて、紙のバージョンはバックグラウンドで署名されます。
- 承認プロセスは「特定の日付にコメントがない場合、それが合意されたと見なします」体制に移され、遅れて受け取った異議と修正は文書の次のバージョンに含まれます。 途中で、このアプローチは、プロセスのすべての参加者をうまく訓練します。
まあ、私たちはまた、従業員がポリシーに記載されている要件を満たすすべての部門の長が承認者のリストに含まれるべきであることも別に注意します。 原則として、IT、セキュリティ、弁護士、および人員です。
実装の成功
セキュリティポリシーを開発するときは、その後の実装の必要性を常に念頭に置く必要があります。 次の成功基準を提案できます。
- 対象読者は、ドキュメントのテキストに精通しており、ポリシーに記載されている要件を理解しています。
- ポリシー要件のほとんどは実際に実装されており、例外処理手順は未解決の要件に対して実装されています。
- 前の2つのステートメントを客観的かつ独立して検証することができます。
例外処理手順の検討はこの資料の範囲を超えていますが、最も重要なことに注意してください。 セキュリティポリシーに記載されていない、または矛盾する（違反を排除できない場合）状況に普遍的な意思決定メカニズムが存在することは、非常に有用なセキュリティ管理ツールです。
熊手について（結論ではなく）
もう一度、セキュリティポリシーの作成時に発生する可能性のある一般的な問題を簡単にリストします。
- 「そして、それは一体何なのか？」-読者（実行者）を見つけられないか、どこにも向けられない要件。
- 「ある種の濁り...」-曖昧な用語、ポリシー要件のわかりにくい表現。
- 「完全ながらくた！」-意見が考慮されなかった主要ユーザーの積極的な反対による調整と実装の難しさ。
- 「ドキュメントはそのように書かれていますか？！」-デザイン、スタイル、スペル、句読点のルールを無視します。
そして、もちろん、著者はこのノートを読んだ後に生じるかもしれないどんな質問とコメントにも喜んでいるでしょう。