2020年 11月 18日
PDCAサイクルから考えるセキュリティポリシーの見直し
ーセキュリティポリシーは、ホワイトカラーの業務改善の一つの要素であるー
PDCA サイクルと呼ばれる「継続的改善」手法は、本来QC活動：「品質保証」用語として用いられます。
PDCAサイクル
-1. Plan : 計画-2. Do : 実施-3. Check : 見直し-4. Action : 執行
という４つの要素がグルングルンとサイクリックに回って「品質改善」を目指そうという皆さんご存知の QC 活動ですね。
で、セキュリティポリシーというのは、ビジネス上重要な、ホワイトカラーにとっては一つの重要な「業務改善」の手段なのです。
ーなんの Plan もなくDo されて始まるセキュリティポリシーー
スタートアップビジネスでは、「とりあえずやっちまおう」的なノリで仕事を始めてしまうので、セキュリティポリシー自体の Pサイクル(Plan) も何もないところから始まって(Do) してしまいます。
つまり、セキュリティポリシー自体、何もないところから始まり、いつの間にか「慣習化」された理由で Do されているところがおおいのではないかとそう考える訳です。
これは、スタートアップ企業だけではなく、大手企業でのスタートアップビジネスにもあり得る話かもしれません。悪しき記憶として印された、ADSLビジネスを始めた頃のソフトバンクの大量の情報漏洩事故なんかがそうでしょう。なんの情報管理ポリシーもなかったわけですね。
ー文書化されたポリシーと慣習化されたセキュリティポリシーー
セキュリティポリシーに限らず、コンピュータシステムを使う上で重要なのは、運用ルールが文書化されているかどうかの視点です。コンピュータの命名規則や、ユーザアカウントの命名規則も、文書化されていれば破綻することは少ないでしょう。この様なルールも PDCA のサイクルで見直しが必要なのですが、不思議と文書化されている組織は少ないようです。多くの運用ルールは「慣習化」されたモノから始まるのです。
コンピュータ名（ホスト）の命名規則？ 15文字の63バイト制限、ホスト名の命名権利はだれの責任？
ユーザアカウント名は８文字以内にすべきか？ユーザの命名規則の理由と対策
ー一番重要な Check サイクルー
セキュリティポリシーは「慣習化されたポリシー」と「文書化されたポリシー」の二つに分類されます。
そこで、セキュリティポリシーが「どういった理由でその様に慣習化されたのか」「文書化されたポリシーは徹底されているか、形骸化しているか、妥当かどうか」という「現状チェック」、つまり PDCA サイクルの Check のサイクルを把握し理解することがとても大切なのです。
この中で「慣習化されたポリシー」が「有効」と判断されたら、セキュリティポリシーの中に文書化すべきであるし、文書化されたポリシーでも、不適切で運用上、意味のないものであれば削除したり、方式を見直すべきなんですね。
特に文書化されていない「慣習化したポリシー」には、どういった背景があるかを吟味することは大切です。意外とエンドユーザの考えることは「妥当」であり「有用」な事が多いのです。
「取引先の要求でこんな感じで文書ファイルを扱わなければならない」
とか
「パスワードは難しく、かつ簡単にこんな風に個人的に管理している」
とか、色々あるわけですね。
特に「パスワードはメモ帳やノートに書かない」というのは、今の時代「死語」に等しいという事も、ユーザ部門はよくわかっているのです。
ー厳格なポリシーは形骸化し易いー
パスワードは大文字小文字記号混じりで１２字以上、同じアルファベットはつかってはダチかんぞ、３０日に一度パスワード変えないとダメだ、なんていうセキュリティポリシー、よく見ますよね。
しかしユーザはよく知っているのです。システム管理部門が知らないだけで、実業務に関してはユーザさんたちはその道の玉筋金太郎並みに抜け道を作るンです。自分のパスワードのルール化です。
意外と社内システムで使われるパスワードなんて、厳しくしなくても簡単には他人がわかるものじゃありません。それよりパスワードを管理して運用させるための利用者側、運用担当者双方のコストを考えれば、厳格なポリシーが如何に形骸化しやすいかを理解できそうなものです。
セキュリティの厳格化を誤ると、運用面でも形骸化が進み、本来守らなければならないルールも形骸化します。その結果「社内ルールがルーズになりセキュリティインシデントが発生する」「本来遵守すべき事項が守られず捏造されたセキュリティチェックだけが残された」という結果にも繋がりかねません。
こんなのは形骸化したルールを見直せば如何に現実性がなかったポリシーだったかがわかるでしょう。
霞ヶ関でパスワード付きzipファイルを廃止へ 平井デジタル相
ー同意を得てのアクションー
ここまで書いてみて、言いたいことは、セキュリティポリシーの PDCA サイクルは「利用者の日常業務の PDCA に関わるもの」だと言うことです。セキュリティポリシーの Check サイクルは、利用者の業務全般の、無理、無駄のチェックのプロセスを含み、業務の運用改善にも繋がるものなのです。
PDCA サイクルの中で重要なのは、Check のサイクルなのです。重要なものをチェックしてピックアップし、形骸化して意味をなさないポリシーは削除する。取捨選択して、現状をどう改善するか。Plan と Do はシステム運用者の業務の範疇でしょう。そして重要なのは Action に必要な、セキュリティポリシーの文書化と徹底するための組織を挙げての規定化です。
必要なことであれば、就業規則にも取り入れ、罰則規定も絡めて検討します。
ーセキュリティルールの習慣化ー
どの企業、組織にも「文化」というものがあります。セキュリティポリシーの習慣化、セキュリティ文化は、組織の意識を向上させます。
PDCA の Action がもたらした結果です。
よく「ウチは ISOxxxxx の認証を取っているから」という事をウリにする組織がありますが、あれは形骸化して「形だけのセールストーク」に使われる仕組みなんですね。
逆に安心して使える取引先は、たとえ ISMS認証がなくとも、数分お話しただけでしっかりしているな、という印象があるものです。ちょっとしたことでもスキがなく素人さんと話しても理路整然としています。
こういった組織はセキュリティだけではなく実業務についても信頼できてスキがないんです。
by islandcenter
| 2020-11-18 16:02
| 雑文
|
Comments(0)
