ITセキュリティ標準ではセキュリティ対策（リスク対応）はリスクの増減に着目して対策を行います。（最初のリスクアセスメントが正しく実行されていれば、リスクの増減を見るだけで管理／対策できる）概念的な部分は理解しづらいようなので、なぜセキュリティ対策をリスクの増減として考えるのか解説します。
ここで紹介していることはリスク管理の基本的な概念です。リスク対策はITセキュリティ対策に対して上位互換、つまりより広い範囲のリスク/セキュリティ対策です。
ITセキュリティ対策＝リスク削減／排除、と考える問題点
リスク受容の概念がない
リスク管理の基本にリスクを受け入れ受容する、があります。リスクの受容も「リスク管理策」です。セキュリティ対策に於てもリスクの受容は同じでリスクを管理する管理・リスク対応策、つまりセキュリティ対策です。
リスクの受容もセキュリティ対策、というと先入観が邪魔して理解しづらいかもしれません。リスク管理策と言い替えると解りやすいかも知れません。
リスクの受容（リスク増加）をリスク管理策として管理しないリスク管理は有り得ません。増加／追加されるリスクを考えないリスク管理策だと、リスク管理策とは何が何だか解らない、になります。何が何だか解らない、は”セキュリティ対策”でもよく聞く話です。
論理的な矛盾
リスク受容は基本的なリスク管理策であり、リスク受容の概念がないリスク管理策は論理的に矛盾してしまいます。人は論理的に整合性がないと理解できません。論理的に矛盾していると理解できないのは当然です。「ITセキュリティ対策＝リスク削減／排除」と考えると簡単に論理破綻をしてしまいます。例を挙げて考えると解りやすいと思います。セキュリティ対策の多くはリスクを減らす方向性の対策ですが、リスクを増やしたり、新たなリスクを生むモノも多いです。
- SSO（シングルサインオン）をセキュリティ対策として導入する
SSOは認証を集中的に管理し、複数のサービスを１つの認証情報でサービスを利用可能にする仕組みです。これは可用性を向上させるセキュリティ対策で、沢山のパスワードを管理しているときより複雑で類推されづらいパスワードを設定しやすい、という意味で機密性の改善も期待できるセキュリティ対策です。しかし、一つの認証情報が漏洩するだけで複数のサービスの機密性が侵害されます。SSOはかなりのリスクを増加させます。
このように「何かを導入する」とITセキュリティの属性の何れかのリスクは削減しても、何れかが増加する、という結果になるケースは少なからずあります。ITセキュリティ対策＝リスク削減／排除、とだけ理解していると「リスクは増えているのにセキュリティ対策？！セキュリティ対策とは良く解らないモノだ」となってしまいます。
対策漏れの原因
「何かを導入する」と複数のセキュリティ属性リスクが変化するので、それらに対して漏れ無く対応する必要があります。「ITセキュリティ＝リスク削減／排除」とだけ定義すると「増加／残存するリスクを見逃す／無視する」結果となってしまう場合があります。
「増加／残存するリスクを見逃す／無視する」結果となる例としてSQLインジェクション対策を挙げます。
- SQLインジェクション対策としてプレイスホルダ／プリペアードクエリを利用する
プレイスホルダ／プリペアードクエリを利用すれば、SQLクエリの”パラメータ”によるインジェクションリスクは削減／排除できます。しかし、プレイスホルダ／プリペアードクエリだけでは”識別子／SQL語句”によるインジェクションリスクは残存します。（この他にもLIKEクエリのインジェクションや正規表現をサポートするDBMSなら正規表現インジェクションも）「セキュリティ対策の指針」の中には残存している「”識別子／SQL語句”によるインジェクションリスク」を無視／見逃しているケースが散見されます。これはセキュリティ専門家が作ったセキュリティ対策の指針でも見られる間違いです。
プレイスホルダ／プリペアードクエリはSQLクエリパラメータのインジェクションリスクを削減するには優れた対策です。そしてSQLインジェクショ ンの多くはパラメータのエスケープ漏れが問題の原因でした。ITセキュリティ対策＝リスク削減／排除、と単純化しすぎた為に「残存リスク」を見逃した結果 が「SQLインジェクション対策にはプレイスホルダ／プリペアードクエリを使えば良い」であったと考えています。
本来は「増加／残存するリスクを見逃さず／無視せず」、識別子のエスケープとSQL語句のバリデーションをリスク対策として実施しなければなりません。
「SQLインジェクション対策にはプレイスホルダ／プリペアードクエリを使えば良い」は不十分なセキュリティ対策であることは明白ですが「ITセキュリティ対策＝リスク削減／排除」と単純化しすぎていると、誤りになかなか気が付かないようです。セキュリティ専門家でも間違えるので、一般の開発者が「ITセキュリティ対策＝リスク削減／排除」と考えるのはより危険と言えるでしょう。
誤解が誤解を生む
「ITセキュリティ対策＝リスク削減／排除」が更に進むと「ITセキュリティ対策＝”直接”リスクを削減／排除」という定義になってしまう場合があります。もちろん明らかに誤りです。ITシステムを利用する上で発生するリスクを効果的に削減／排除するには、”直接”リスクを削減するかどうか？は関係ありません。対策の効果と費用が問題であり、”直接”／”間接”は無関係です。
「ITセキュリティ対策＝”直接”リスクを削減／排除」がさらに進むと「ITセキュリティ対策＝”直接”リスクを削減／排除することが”目的”の対策」になります。特定の対策の”目的”が何であるか、はセキュリティ対策であるかどうかとは全く関係ありません。”目的”は無関係で、リスクをどのように変化させるのか？がセキュリティ対策であるかどうかを見極める箇所です。
”目的”は主観によって決まります。人によって「これはセキュリティ対策」「これはセキュリティ対策ではない！」となってしまいます。そして時には”目的”がセキュリティ対策でないから、セキュリティ対策でないとして最もセキュリティ対策として効果が高い対策まで「これはセキュリティ対策ではない」と区分したりもします。
こうなってくると「セキュリティ対策とは何が、何だか解らなく」なります。直接／間接、目的などは”セキュリティ対策かどうか”とは無関係です。
問題点の解決策
何が何だか解らなくならないようにするには、論理的に整合性のある体系的なITセキュリティの概念が必要です。それには明確な目的
- ITシステムを許容可能な範囲内のリスクで利用する
を設定し、ITセキュリティ対策を
- ITシステムの利用で発生するリスクを増減する対策
と定義すると解決します。ITセキュリティ対策は「ITシステムを許容可能な範囲内のリスクで利用する」目的を達成するために「リスクを増減させる対策」と考えると論理的に破綻せず、必要な対策を考えられるようになります。
- 減ったリスク
- 増えたリスク
- 元々存在したリスク
※ 全てまとめて残存リスクと考えることもできる
これら全て”目的”に適応しているか？考えます。許容できるリスクなら許容し、できない物はリスク削減策を検討／実施します。もし、リスクの増減がないならセキュリティ対策以外の何かです。
ITシステムに限らず、何かを作る／導入する場合にはほぼ必ずリスクが発生します。そして多くの施策でリスクが増えたり、減ったりします。リスク管理はリスクの増減で考えないと、マネジメントできません。
増加するリスクを管理しないと致命的な間違いの発生原因になります。ITシステムに限らず「え？どうしてこんな事に？！」となるようなリスク管理の失敗の多くは、増加するリスクを評価／管理していないことが原因のように思えます。
元々存在して変化しないリスクは多少厄介です。セキュリティ対策を導入する場合には比較検討の対象にはならないことが多いですが、無視すると「SQLインジェクション対策はプレイスホルダ／プリペアードクエリだけでOK」としてしまったように、存在するリスクを無視／見逃す結果になります。元々存在するリスクに注意するのは当たり前のことですが、見落としがちなので注意が必要です。
どうしても解りづらい場合
セキュリティ対策は基本的にリスクを削減／排除する対策、と考えても構わないです。ただし、
- リスクが増加する部分があっても、セキュリティ対策であること
- 変化したリスク、削減したリスクだけでなく、増加したリスクと残存したリスクに注意すること
- 変化しなかったリスクには特に注意すること
- 存在するリスクを無視しないこと（対策を取らなかったとしても、セキュリティ対策の管理項目とすること）
- セキュリティ対策の評価は「リスクの増減と必要なコストで評価」すること
- 特定の対策が「リスクの削減／排除が”目的”であるかどうか」「”直接”リスクを削減／排除するかどうか」はその対策がセキュリティ対策であるかどうかには無関係であること
などに注意が必要です。何がセキュリティ対策かどうか？議論する事に意味はありません。どのようにリスクを変化させる対策なのか？を議論することに意味があります。
リスクの受け入れて受容する、という考え方をがないと余計に解りづらいと思いますが、どうしても解りづらいと感じる方は上記の様な考え方でも大きくは間違わないと思います。
まとめ
色々書きましたが、単純に「ITセキュリティ対策＝リスクを変化させる対策」と考えて「減るリスク、増えるリスク、残ったリスク」と「対策に必要なコスト」でセキュリティ対策を評価すると簡単です。簡単ですが「ITセキュリティ対策＝リスクを削減／除去する対策」とした時のような論理的な破綻は起きず、他の問題も起きづらいです。
最後に、どれがセキュリティ対策でどれがセキュリティ対策ではない、といった議論は意味がほとんどないです。どちらの方が効果的に「ITセキュリティの目的」を達成できるか？を議論すると意味のある議論になります。
リスクの受容もリスク対策（つまりセキュリティ対策）であることは忘れないようにしてください。セキュリティ対策＝セキュリティ管理策、と考えた方が解りやすいかも知れません。ISO27000の前のセキュリティ標準であるISO13335では「管理策」として定義していました。
