How compliance and security requirements may conflict

[アーティクル]
08/25/2016

デスクトップファイルセキュリティと規制遵守

Wes Miller

IT プロフェッショナルは、相互に補完し合うべき目標が、逆に悪影響を与え合う状況に直面することがよくあります。セキュリティと規制遵守は、この状況をよく表している 2 つの組織目標ですが、一方を実現することによってもう一方が強化されることが理想です。ただし、残念ながら常にこの理想が叶うわけではありません。このコラムでは、

規制遵守がセキュリティとまったく等価値であると考えられているにもかかわらず、セキュリティを強化することが、必ずしも提示されたイニシアチブの要件を満たすことにならない理由、および規制を遵守することが、多くの場合、セキュリティを強化することにならない (少なくとも、必要なセキュリティを確保できない) 理由を大まかに説明します。

セキュリティはチェックボックスではありません

SDL の関連情報

Michael Howard、Steve Lipner 共著『The Security Development Lifecycle』(Microsoft Press、2006 年)
セキュリティ開発ライフサイクルに関するブログ
マイクロソフトにおけるセキュリティ開発ライフサイクルの解説
セキュリティデベロッパーセンター
信頼できるコンピューティングのセキュリティ開発ライフサイクル

一般的に、規制遵守とは、組織、業界、企業、または製品に対して外部から課せられる要件 (人、プロセス、インフラストラクチャ、テクノロジなど) を満たすことを意味します。また、業界内で推奨される標準 (支払いカード業界データセキュリティ基準 (PCI-DSS) など) を満たすことを意味する場合もあります。これらのイニシアチブが、組織で既に取り組んでいる対策に、少なくともある程度対応していることが理想です。導入する標準の数が増えるにつれて、ビジネスを行うのであればその標準を無視するわけにはいかないことに気付き、最終的にはその中に飛び込み、目標の達成に全力を尽くすことになります。

通常、より厄介なのは、もう 1 つの種類の規制遵守です。これは、医療保険の相互運用性と説明責任に関する法律 (HIPAA) や米国企業改革法など、政府から提示されるイニシアチブのことを指します。これらのイニシアチブは、実装するかどうかや、そのタイミングを選択できる余地を与えてくれることはほとんどありません。

規制遵守の重要な特徴は、"トップダウン方式" の手法が関係してくることが多い点です。通常は、イニシアチブを定義する画一的な雛型が存在するので、使用している製品とプロセスと照らし合わせながら、配布されたこの奇妙な形の雛型にそれらを適合させる方法を見つけ出す必要があります。遵守イニシアチブの目的を認識しておくことも必要ですが、おそらくより重要なのは、遵守イニシアチブに従わない場合、またはその要件を満たすことができなかった場合に、どのような法律上または金銭上の悪影響 (考えられる場合) が発生するかを認識しておくことです。

多くの遵守イニシアチブの目的には同意できると思いますが、これらの実装は困難な場合が多く、要件を満たすことができない可能性があります。そして残念ながら、多くの遵守イニシアチブには強制力がありません (つまり、従わなくても、法律上または金銭上の直接的な悪影響は発生しません)。

治療を受ける患者として言わせていただきますが、私は HIPAA によってもたらされる利益について十分に説明できません。わかっているのは、病院に行くときにさらに多くの書類への記入を行わなければならないということのみです。さらに悪いことに、予期しない結果に直面することもあります。重要な医療情報を、ある医師や機関から受け取り、別の場所に持って行こうとしたことはあるでしょうか。許可書がなければ、どれだけ緊急に情報が必要な場合でも、その情報を入手することはできません。

問題は、一部の遵守イニシアチブが、色々な意味でチェックボックス化していることです。つまり、遵守イニシアチブに従うという目的のためだけに、プロセスや製品が設計または変更されています。3 才になる私の子供によくする質問ですが、"本当にそれでいいのでしょうか"。

一方、セキュリティイニシアチブには、その実装が正しく行われる場合、ボトムアップ形式の手法が使用されます。ソフトウェア製品を設計する場合でも、組織の新しいネットワークのアーキテクチャを設計する場合でも、重要なのは、周到に準備をするということです。たとえば、製品のアーキテクチャを設計する場合、最初の段階で通信手段、他言語への対応、バージョンなどを考慮することが推奨されていますが、アプリケーションに組み込む必要があるセキュリティ要素も、最初から設計に含める (そして、開発作業全体を通じて調査および改良していく) 必要があります。

他の人が設計したアプリケーションやアーキテクチャを使用する場合 (ほとんどの皆さんはこれに該当すると思いますが) は、このコラムでもよく言っていることですが、それらのセキュリティを徹底的に評価することが重要です。しくみがわからなければ、安全であるかどうかを理解することはできません。マイクロソフトのセキュリティ開発ライフサイクル (SDL) の詳細については、補足記事「SDL の関連情報」を参照してください。

全体像

セキュリティの強化とは、単に暗号化、アクセス制御リスト (ACL)、TLS、公開キー基盤 (PKI) などを実装することではないと昔教わったことを思い出します。真のセキュリティを提供するには、全体像を理解することが重要です。つまり、プロトコルの特定のバージョンが使用されなくなった、またはサポートすらされなくなった理由、新しく追加したコードによって介入者攻撃を阻止できる理由、製品の以前のバージョンの方が処理速度が速いにもかかわらず、次のバージョンで速度を犠牲にしてセキュリティを強化した理由などを理解する必要があります。また、インフラストラクチャのそれぞれの部分がどのように組み合わさっているかを理解することも重要です。

一方、規制遵守とは、使用しているテクノロジを評価し、構築したインフラストラクチャが一定の基準を満たすようにすることです。支払いカード業界データセキュリティ基準 (PCI-DSS) や北米電気信頼度協議会 (NERC) などの一部のイニシアチブは、目的がはっきりしているため、これに従うことによって、正しくセキュリティを強化できると思います。ただし、最終的には、さまざまな種類の "遵守イニシアチブ" を選択し、特定のプロジェクトをそれらに適合させることになり、さらに利用できるリソースも限られているため、セキュリティイニシアチブの要件を満たすことができなくなります。

セキュリティは、ソフトウェア開発において、長い間あまり重要視されてきませんでした。間違いなく、皆さんの多くはセキュリティを "後回し" にする組織に所属しています。現在、遵守イニシアチブが世間に浸透している理由は、"セキュリティは後回しにできる" という考え方が誤っており、これまでその考え方が功を奏したためしがないからです。

"とりあえず" という考え方

最近、私は転職しました。現在は、ここテキサス州オースティンにある規模の小さいベンチャー企業に勤めています。ここでは、Winternals で構築した Protection Manager 製品のテクノロジと若干似ている、安全なアプリケーションを登録する (ホワイトリストに追加する) テクノロジを構築しています。顧客と話していて非常に興味深いと思ったのは、顧客が現在使用しているテクノロジを安全であると考えていることです。より具体的に言うと、それらの顧客は、インフラストラクチャの構築に使用している一連のテクノロジを安全であると考えています。それらの大部分は安全で、セキュリティの脆弱性が原因で侵害されることはなさそうですが、少しうんざりするのは、システムが "とりあえず安全である" という評価をよく耳にすることです。

遵守イニシアチブにはおかしなところがあり、それは、従っても従わなくても問題が発生しないという点です。責任は皆さんにあります。たいてい、イニシアチブに従わないことの代償として挙げられるのは、罰金、罰則、または解雇です。多くの場合、本当に何かを変えるには、これだけでは不十分です。

あるイニシアチブに従うことが連邦政府によって義務付けられた場合、"とりあえず監査担当者を満足させよう" という考え方や、このイニシアチブを支える法律 (HIPAA など) の制定機関によって適切な資金が提供されないことを理由に、規制遵守に関するきちんとした体制を整えずに要件を満たそうとする組織が出てきます。これは、非常に少ない費用で、何の保証もないままイニシアチブに従おうとし、後になってあらゆる潜在的な影響に直面することを意味します。

多くの場合、セキュリティイニシアチブに関しても同じ問題が発生しますが、少なくとも遵守イニシアチブに比べると考え方は明確です。開発者や実装者は、ある部分を仕様から除外すると製品が著しく脆弱になることを経営陣に前もって伝えておけば、少なくとも製品を出荷した後や展開が完了した後に、「だから言ったでしょう」と言うことができます。私の経験上、遵守イニシアチブの場合は、できるだけ少ない予算で、できるだけ早く要件を満たすことが求められます。目標は、そのイニシアチブの最低限の要件を満たすことのみであるため、要件を満たすことができても、その内容を継続的に意識することはできないと思います。

現在の状況を判断する

セキュリティと規制遵守の関連情報

理想としては、製品や組織のセキュリティを可能な限り強化してくださいと言いたいのですが、実際には、ほとんどの遵守イニシアチブが、不十分な設計や、多くの場合は自己満足による妥協の産物です。不幸なことに、私たちは "とりあえず" で事足りる世界に暮らしています。ただし、セキュリティの世界では、"とりあえず" が賢明であることはほとんどありません。世界中の IT プロフェッショナルは、遵守イニシアチブを喜んで受け入れ、精神と実装の両方において、そのイニシアチブに従おうとするかもしれませんが、組織に導入されているインフラストラクチャのセキュリティは、"できるだけ" 強化するのではなく、"必要とされる度合いまで" 強化する必要があります。つまり、単にイニシアチブの要件を満たすのではなく、真のセキュリティを手に入れることによって、規制を遵守する必要があるということです。

現在構築しているテクノロジが、商用ソフトウェアの一部であるか、大規模なシステムに統合する一連のテクノロジであるかどうかにかかわらず、そのしくみを 1 歩下がったところから見ることは重要です。システムの連結部分、それぞれの部分が連携するしくみ、およびシステムに対する大きな脅威について理解することの重要性は、いくら強調してもしすぎということはありません。

携わっている業界ごとに、さまざまな遵守イニシアチブが業務に影響を与える可能性があります。日常的に遭遇することもあれば、新しいプロジェクトやテクノロジの設計時のみ遭遇することもあります。また、法令遵守に関する評価または監査中に行う一部の作業でのみ遭遇する場合もあります。ただし、そのことは問題ではありません。遵守イニシアチブを無視した方がよいとは思いませんが、皆さんには現状を打破していただきたいと思っています。任務として課せられた遵守イニシアチブの要件を満たすための作業のみを行うのではなく、セキュリティに関するすべての点を評価することによって、使用しているテクノロジについて徹底的に理解し、法令遵守に関する評価を行う際に、そのテクノロジをモデル化する必要があります。

失うもの

最終的に遵守イニシアチブの要件を満たすことができなかった場合の罰則はあいまいです。要件を満たすことができなかった場合、そのイニシアチブが対象としている脅威の影響を実際に受ける危険性が残ることになります。この脅威はあいまいでわかりにくいかもしれませんが、確かに存在します。皆さん個人に影響が及ぶことはないかもしれませんが、現状に気を配りながら、常に最悪のシナリオも心に留めておいてください。

厳密なセキュリティの観点から同じ問題に目を向けると、この脅威は明らかになるはずです。そして、これは重要なことですが、脆弱性を未解決のままにした場合のコストをすばやく予測できるようにしておく必要があります。

このテーマについて、他の人たちとも話をしたことがありますが、多くの人は、遵守イニシアチブはかなり自由に解釈できるため、うやむやにされる場合があるという事実を力説していました。ただし、セキュリティ評価を実施すると、特定のセキュリティ対策を実装しなかった場合、その影響はうやむやにはならないことがわかります。そのセキュリティ対策を無視したことによって発生する直接的な脅威は、はっきりとわかります。脅威が明確にならない場合は、セキュリティ評価の実施者を再検討することをお勧めします。というのも、実装されているソリューションの中に存在する問題点を発見してくれる重要なチームメンバを見逃している可能性があるからです。

無駄な努力

昨年、「データの損失を防ぐ方法」(technet.microsoft.com/magazine/cc162325) という、セキュリティに重点を置いたコラムを執筆しました。あれから 1 年が過ぎましたが、攻撃を受けるシステムの数、盗難にあった暗号化されていないラップトップの数、および流出した個人情報の量は増加しています。なんらかの進歩があったかどうかを判断するのは困難です。なぜ状況が変わらないのでしょうか。プロジェクトの進行はたびたび遅れています。これは、予算が非常に限られていること、リソースの負荷が高すぎること、および短い期間であまりに多くの機能を提供しようとすることが原因です。

残念なことに、このような環境では、必要最低限の作業が標準的な作業と見なされます。これではソリューションのセキュリティを確保することも、規制を遵守することもできませんが、プロジェクトのスケジュールやコストには致命的な影響を与えずに済みます。

個人的には、次のような信念を持っています。

セキュリティを確保するつもりがない場合は、ソリューションを構築すべきではありません。
新しい機能を追加する場合は、必ず最初にセキュリティの設計を行う必要があります。
組織が設計プロセスにセキュリティを組み込むことに前向きでない場合は、企業または組織の全体的な方針に疑問を持つ必要があります。

組織が安全に保管する責任がある顧客やパートナーの個人情報はますます増えています。残念なことに、現在の世の中では、セキュリティがないがしろにされることがあまりに多く、従業員は安全性を感じられず、組織のセキュリティに対する姿勢を疑問視しています。

たいていは、実際にセキュリティ対策 (規制遵守ではありません) の欠如が原因で問題が発生したときに、"システムのセキュリティを強化する必要がある" ことを認識します。また、顧客、学生、患者、および従業員が、個人情報が漏洩したり金銭上の福利が侵害される可能性を懸念している場合は、"個人情報盗難保険" を標準的な説明手段として使用し、不安を取り除くことができます。

私たちは皆、過剰な量の作業を、ほとんどの場合少ない予算で、たいてい非常に短い期間内に行うよう要求されます。ただし、IT プロフェッショナルの責任として、なぜセキュリティが軽視されるのか、なぜ経営陣は、遵守イニシアチブが提示されたときや、セキュリティ障害が発生し (可能性はこちらの方が高いでしょう)、それによって法律上の脅威が実際に生じた、または生じる可能性があるとき (これによって組織の評価が下がり、窮地に陥ることもあります) でなければセキュリティについて考えないことが多いのかを問題として取り上げる必要があります。

挑戦してください

まずは、現状を打破することを試みてください。単に規制遵守のみを要求された場合、その作業を行うときに、他の人が考案したセキュリティの概念に従うことに時間を無駄に費やしているのではないと考えるようにします。システムのセキュリティを強化し、さらにその中で、遵守イニシアチブの要件を満たすことができるようにプロセスやインフラストラクチャを定義することを目標にしましょう。詳細については、補足記事「セキュリティと規制遵守の詳細情報」を参照してください。

要するに、規制遵守は、多くの場合、セキュリティに通じる道ではありませんが、セキュリティは、正しく実装し整備すれば、高い確率で規制遵守につながります。

Wes Miller は、テキサス州オースティンにある CoreTrace 社 (www.CoreTrace.com) のシニアテクニカルプロダクトマネージャです。以前は Winternals Software 社に勤務し、その後はマイクロソフトでプログラムマネージャとして働いていました。Wes の連絡先は、technet@getwired.com (英語のみ) です。

その他のリソース