標準と基本概念から学ぶ正しいセキュリティの基礎知識

(Last Updated On: )

今回は一部の技術者が勘違いしているセキュリティ概念の話です。技術者とはWebアプリケーションのソフトウェア技術者を指していますが、他の分野の技術者にも同じ勘違いが多いかも知れません。常識であるべき知識が常識でないのが現状のようです。全ての技術者が知っておくべきセキュリティの基礎知識です。

残念ながらセキュリティ対策の定義どころか、プログラムの構造・動作原理も正しく理解されていないと言える状態です。

ソフトウェア開発には膨大な知識が必要です。目的（ソフトウェアを作ること）以外の知識を取り入れる機会や余裕が無かった方も多いと思います。セキュリティ基礎知識を知らなかった方、安心してください！基本は簡単です。一度知ってしまえば忘れるような難しい事ではありません。勘違いしていた方、問題ありません。正しい知識を身に付ければ良いだけです。誰にでも勘違いはあります。

思い違いをしやすい部分を、かい摘んで解説します。

追記：ホワイトリストの基本中の基本は”デフォルトで全て拒否する”であることに注意してください。全て拒否した上で、許可するモノ、を指定しないとホワイトリストになりません。

ここでのセキュリティはITセキュリティを意味しています。

参考：

• 「出力対策だけのセキュリティ設計」が誤りである理由
• 実は標準の方が簡単で明解 – セキュリティ対策の評価方法
• エンジニア必須の概念 – 契約による設計と信頼境界線
• IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき

こちらも合わせてご覧ください。

とくに IPAは基礎的誤りを明示し、正しい原則を開発者に啓蒙すべき は開発者であれば、目を通しておく方が良いです。IPAが10年以上も原理的に誤ったソフトウェアセキュリティ対策を啓蒙していました。今もその影響が大きいです。

セキュリティ対策の定義

セキュリティ概念の話の前に、セキュリティ用語の基礎知識からおさらいします。Securityを辞書で引くと

3〔危険・危害などに対する〕防衛(手段), 警備(態勢), 安全保障
http://ejje.weblio.jp/content/security

と出てきます。一般的な意味としての「安全」もあります。この辞書には書かれていませんが意訳して「防御」を訳語としても適切でしょう。防御の訳語はdefenseが適切であるため載っていないのだと思われます。セキュリティ対策を防衛対策、警備対策、安全保障対策と訳すとなんだか物々しい感じになります。英語でもdefenseをsecurityに置き換えて意味が通じるものは多くあります。「安全対策」「防御対策」などと訳すと思います。

ITセキュリティにおけるセキュリティ対策とは何でしょうか？セキュリティ対策（英語ならsecurity measureが最も近い）には公式な定義はありません。ITセキュリティはOECD情報セキュリティガイドライン勧告を経て、ISO標準で定義されています。一般に言われるITセキュリティの「セキュリティ対策」の同義の用語としてISO/IEC 27000:2012で「Risk Treatment」（リスク対応）が定義されています。「セキュリティ対策」とは、目的を達成する為に適切なリスクを選択し、削減可能なリスクを削減する事にあります。本質的には「リスクにどのように対応するか」がセキュリティ対策です。

ISO 27000の定義

2.71
risk treatment
process (2.54) to modify risk (2.61)

NOTE 1
Risk treatment can involve:

• avoiding the risk by deciding not to start or continue with the activity that gives rise to the risk;
• taking or increasing risk in order to pursue an opportunity;
• removing the risk source;
• changing the likelihood;
• changing the consequences;
• sharing the risk with another party or parties (including contracts and risk financing); and
• retaining the risk by informed choice.

NOTE 2
Risk treatments that deal with negative consequences are sometimes referred to as “risk mitigation”, “risk elimination”, “risk prevention” and “risk reduction”.
NOTE 3
Risk treatment can create new risks or modify existing risks.

これを訳すと以下のようになります。（個人的な私訳です）

2.71

リスク対応
リスクを変化 (2.61)させる為のプロセス(2.54)

ノート 1
リスク対応には以下の項目を含める事ができる:

スクを発生させる活動を開始しない、または継続しないことを決断することによりリスクを回避する。
機会を獲得する為にリスクを選択または増加させる。
リスクの原因を排除する。
発生の頻度を変える。
結果を変える。
他の組織（契約企業やリスクの資金的処理を含む 訳注：保険など）とリスクを共有し見聞のある選択によりリスクを抑える。

ノート 2
否定的な結果をもたらす事象のリスク対応は、”リスク緩和策”、”リスク排除策”、”リスク防止策”、”リスク削減策”などと呼ばれる事がある
ノート 3
リスク対応は新しいリスクを生成したり、既存のリスクを変更することができる

備考：ISO 13335では「管理策」が「リスク対策」として定義されています。

セキュリティ対策 ≒ リスク対応

国際情報セキュリティ標準（ISO 27000）の定義では「リスク対応」が一般に言われる「セキュリティ対策」に最も近いことが分かります。Securityの直訳である防衛策、警備策や安全保障もリスクを完全に無くす物ではなく、概ねリスクを減少方向に変化させる物です。ITセキュリティで異なる部分はリスクを追加できる部分であり、それ以外は辞書の定義とも概ね一致しています。

標準や仕様書などでは先ず用語の定義から始まります。これは用語の定義が異なるとコミュケーションが不可能になるので先ず定義しています。もし一般とは異なる定義を使う場合、明確に定義してから使わないと混乱の元です。

用語の独自定義は避ける

情報セキュリティに於ける「セキュリティ対策」に独自の定義を持っている方も居ますが、ISO 27000は幅広い企業で採用されている国際的なセキュリティ認証規格であるISMS適合性評価制度に利用されている標準です。ほとんど一般に知られていないような標準であれば、一般に通用する標準外の用語定義を使っていても問題はありません。そういう用語はよくあります。

しかし、一般（英和辞書）の定義とも異なる上、多くの企業がセキュリティ標準として採用するISMSに利用されている標準用語を技術者が使わないなら問題があります。技術者なら基本的にISOの用語定義に書かれている通りの定義を使うべきです。

本来「情報セキュリティ対策」とは「情報セキュリティ」を定義するOECD情報セキュリティガイドライン勧告、ISO 13335やISO 27000の概念、要求事項を”包括”する言葉と言えます。これでは意味が広すぎるので「セキュリティ対策 ≒ リスク対応策」と言われていると思います。私はセキュリティ対策と言う場合、リスク対応策を意味する言葉として使うことが多いです。

 

セキュリティ用語定義の間違い

時々SNSなどで自信満々に「大垣のいうセキュリティ対策の定義は間違っている」と主張される方がいます。これらの方はセキュリティ対策とは「リスク排除策」「リスク防止策」のみの限定された用語であると理解しているようです。これはISO標準、ISMSでも、一般の辞書の定義にも合致しません。

幾つか代表的な誤解を紹介します。

• × 緩和策はセキュリティ対策ではない

セキュリティ対策とはリスクに対してどのように対策するか？がセキュリティ対策であり、リスク対応の定義に「リスク緩和策」が含まれると明確に書かれています。コンピュータ利用のリスクは全体で評価します。たとえ一部に完璧な対策を行っても、全体としては緩和策です。小さなところ、基礎的な所から少しずつ積み上げる事は非常に重要ですが、完璧な対策はあまりありません。ほとんどのセキュリティ対策は緩和策です。例えば、通信の安全性を守るとされているSSLも完璧ではありません。エンタープライズ環境ではSSL通信を無効化し、通信を監視するシステムは当たり前に運用されています。SSLエラーなどは表示されず、管理者は通信内容を見れます。攻撃者が同類の環境を作る事も可能です。

Securityに「完璧またはほぼ完璧でなければならない」という意味はありません。このような願望を持つこと、一部の機能に持たせることは可能ですが、意味には含まれません。このような定義にするとほぼ全てのセキュリティ対策がセキュリティ対策でなくなります。

開発会社としてのリスクもあります。情報システム部の方にはISO標準、ISMSをしっかり勉強されている方も沢山居ます。開発会社が「緩和策はセキュリティ対策ではない」などと言うと「この会社は大丈夫なのか？」と疑問に思われるかも知れません。下手をすると次回の契約に影響するかも知れません。

• × 入力バリデーションはセキュリティ対策ではない

これも明らかな思い違いです。入力バリデーションは最大の緩和策であり、セキュリティ対策として最も基本的かつ重要な対策です。この後に説明する”境界防御”の概念を理解していれば当たり前のセキュリティ対策であると解ります。CWE/SANS TOP 25で最大のセキュリティ対策とされているのは入力のバリデーションです。緩和策がセキュリティ対策でない、とする誤解から生じた勘違いのようです。

• × 入力バリデーションはアプリケーションの仕様であり、セキュリティ対策ではない

そもそも、ソフトウェアのセキュリティ対策として挙げられる物はソフトウェアで無数に仕様として実装される物の中から、リスクを削減する為に必要である仕様を限定的にまとめた物がセキュリティ対策です。つまり、ソフトウェア開発におけるセキュリティ対策と言われる物はそもそも「仕様」であり、アプリの仕様であるからセキュリティ対策ではない、は論理的な説明になっていません。セキュリティ対策集は仕様の集まりである、という事実を見落としています。

またセキュリティ対策として認識した対策はPDCAサイクルで常に再評価され、改善されます。入力バリデーションをセキュリティ対策としない、ということはPDCA管理サイクルの対象としない、ことになります。これはソフトウェアセキュリティにとって重大な問題です。

参考：

• CERT Top 10 Secure Coding Standard
• OWASP Secure Coding Practices – Quick Reference Guide

• × リスクを除去するものがセキュリティ対策であり、他はセキュリティ対策ではない

セキュリティの意味を取り違えています。リスクを除去する物「も」セキュリティ対策です。一般にいうセキュリティ対応策はより広い範囲であると定義されています。セキュリティ対策はリスクの除去だけではありません。リスクの緩和、削減もセキュリティ対策です。また、情報セキュリティにおいては、リスクを軽減する事だけがセキュリティ対策ではありません。適切なリスクを選択すること、目的を達成する為に必要なリスクを適切に増やす事もセキュリティ対策です。（目的とは実装したいアプリケーションやサービスです）

• × セキュリティ対策と言うより、これはフィルターだからセキュリティ対策でない

リスク削減の為の対策がセキュリティ対策です。リスクと関係ないフィルター処理ならセキュリティ対策ではない、は正しいです。しかし、例えばRails4に導入されたStrong Parameter（モデルで利用するパラメーターを指定する機能）は名前からも、導入の動機からも明らかにセキュリティ対策です。SANS TOP 25の入力バリデーションでも、この種のフィルター処理がセキュリティ対策として紹介されています。Railsでは入力の境界防御の考えが弱かった、というよりアプリ内部のモデルでバリデーションしているので縦深防御でした。縦深防御のみでセキュリティが維持できない事もないですが、基本形とは言えません。

Rails4で入力バリデーションがコントローラーに追加された事は、入力の境界防御が追加されたという意味で画期的です。エンタープライズセキュリティをやっている方からするとRailsの入力バリデーションは貧弱なので、今後も境界防御を行う機能追加があると考えています。

注：導入の動機はRailsのモデルにあるマスアサイメント（Mass Assignment）と呼ばれる問題です。PHPのregister_globalsと同類の問題で余計な変数まで書き換える問題です。手っ取り早くて便利に思える機能は、脆弱な仕様だと判明していても何度か取り入れられる物です。これを防止するのがStrong Parameterによるフィルター処理です。個人的には、register_globalsもRailsのモデルが勝手にパラメータを処理する機能も便利だと思った事が一度も無いのですが、このような処理は一定の人気があるようです。

• × 入力バリデーションはそもそも実現できない、無効なセキュリティ対策である

これは用語の意味の取り違いというより、入力バリデーションを理解していないことが思い違いの原因です。ほとんどの入力はバリデーションできます。私のブログでも何度も紹介していますが、入力バリデーションの方法はSANS TOP 25のMonster Mitigation #1を参照してください。

セキュリティ概念の間違い

国際的に共有されているセキュリティの概念はOECD情報セキュリティガイドライン勧告から始まり、ISO 13335で標準化されました。ISO 13335は重複が多いISO 27000が存在するため現在は撤回（Withdrawn）されています。（用語が異なるなどの問題もありますが、ITセキュリティマネジメントを簡潔に理解するには良い規格です。今でも一読をお勧めします）ISO 13335はOECD勧告後に初めて体系的にセキュリティ概念をまとめた標準です。多くの概念が定義されていますが、当たり前過ぎて明確に文書化されていない物もあります。その一つが境界防御です。

• ◯ 境界防御

もしかすると、これがソフトウェア系技術者に最も理解されていない概念かも知れません。ITシステムに限らず、何かをリスクから守ろうとする場合、必ず境界防御（Boundary Defense）を行います。国境警備、ビルの入退室、工場への搬入・搬出、空港での出入り、これらの全てで境界にあたる部分でのチェックを行います。セキュリティ要件が厳しければ厳しいほど境界防御は厳しくなります。首相官邸は一般の建物とは比べ物にならない境界防御が行われていること明らかです。ソフトウェアも同じです。Boundary Defenseは様々な文書にでてきますが、常識とされているため英語版Wikipediaには掲載されていないようです。

境界防御はセキュリティ維持の為に先ず第一に行うセキュリティ対策です。まずリスクの原因となる物を境界で排除することは、完全でないにしても、効果的かつ合理的です。CWE/SANS TOP 25でも境界防御を最大のセキュリティ対策（入力が第一位、出力が第二位）としています。しかし、開発者の一部にはこの境界防御の概念が無いと思われる方も居ます。文書化された概念ではないですが、常識として理解すべきです。境界防御が必要ない、と言うセキュリティ専門家は一人も居ません。

• ◯ 縦深防御（多層防御、多重防御、階層的防御）

この概念もよく勘違いされている概念に思えます。セキュリティ用語としては多層防御などと書かれる事が多いです。縦深防御（Defense in Depth）とは元々軍事用語で防衛ラインを下げつつ（境界防御を後退させつつ）敵にダメージを与えながら防御・戦闘する戦略の事を言います。単純に負けて退却するのではなく、敵の侵入を許しつつ、できる限りの反撃を行いダメージを与え、可能であれば最終的に撃破するという戦略が縦深防御です。軍事戦略的には必ずしも負けている場合に選択する戦略ではありませんが、状況的には縦深防御の実行が必要になった時点では境界防御が不可能か失敗している、つまり劣勢であり負けているのです。防御はできるだけ負けないように行います。軍事作戦の於ける縦深防御は必ずしも悪い戦略ではありません。しかし、ITセキュリティにおいては、負けを前提とした防御、侵入を阻む努力を放棄した防御、が最適解であるケースは多くありません。

ITセキュリティにおいて縦深防御とは攻撃者の侵入を許さざるを得ない場合の対策（例えば、非SSLのHTTPセッションハイジャックなど）、万が一許してしまった場合のコンティンジェンシープラン（不測事態対応策）と言えます。予め予期される攻撃への対策、コンティンジェンシープランは非常に重要です。しかし、そもそもはまず境界防御で最大限の防御を行うべきです。その上で縦深防御策を検討・準備・実行します。

技術者の中には縦深防御があれば良い、と考えている方も少なくありません。これは構造化プログラミング、抽象化などのプログラミング技法の影響があるのだと思われます。構造化プログラミングや抽象化などの概念では、下位のモジュールや抽象化されたオブジェクトなどの実装を隠蔽する事が良いとされています。その実装の中にセキュリティ対策を入れてしまえば良い、つまり縦深防御を行えば良いと考えているのではないでしょうか？逆転の発想は難しいものです。

セキュリティの概念はこの考えとは反対方向の概念です。まず境界防御があり、次に縦深防御を行うのがベストプラクティス（PDF）です。間違えてはならない点は、コンピューターシステムが非常に脆弱であるという事実です。境界防御があれば縦深防御が必要なくなる訳ではありません。縦深防御がどうしても必要になる場合もあります。

縦深防御のポイントは「可能なかぎり敵にダメージを与えながら防御する」ことです。先日書いた間違いだらけのHTTPセッション管理とその対策で紹介している対策には「攻撃者にダメージを与えながら防御する」仕組みが入っています。可能であれば攻撃を防止するだけでなく「ダメージを与えながら防御する」ことが重要です。攻撃者は攻撃を検出される事を嫌います。攻撃を検出、記録しレポートしたり目に見える形でユーザーに知らせたりする事が重要です。

縦深防御で重要になるのも境界防御の考え方です。プログラム／システム内で境界をつくり、適切な場所で入力／出力（境界）を確実に制御します。複数の境界（階層）を作るので階層的防御とも呼ばれています。アプリケーション／システムの入力・出力を確実に制御することは必須ですが、アプリケーション／システムの入力・出力だけを守れば良い訳ではありません。必要（セキュリティ要求など）に応じて境界を分け、一つのアプリの中でもコンポーネントごとに境界防御を行わなければなりません。結果的にこれが縦深防御となります。

• ◯ 信頼境界線

信頼境界線（Trust Boundary）とは信頼できる境界がどこにあるのか？を定義する概念です。信頼境界線は比較的正しく理解されている概念だと思いますが、その境界線の引き方にケアレスミスが多く見られます。例えば、Webサーバーの利用するデータベースは信頼できる、とする考え方です。普通データベースはファイアウォールなどによる境界防御により守られていますが、信頼できるとは定義できません。データベースサーバーの中には外部からのデータが保存されている事がほとんどです。データベースは保護されているとしても、データは信頼できません。これは間接SQLインジェクション問題として知られているので、Web開発者の多くは正しく理解していると思います。

しかし、XXEなどのSSRF攻撃が非常に有効である現状からすると、まだまだ誤解も多いと思われます。ソフトウェア技術者は基本的に自分（または自分たち）が書いているコード以外は信用できない物として扱わなければなりません。信頼境界線の中に入れるには「信頼できる」とするための検証が必要です。（TPMがどのような考えで設計されているのか、調べると参考になります）

入力に対するバリデーションを比較的しっかり行っているアプリケーションでも、いい加減な出力になっている場合がよくあります。信頼境界線の外からのデータのみ注意を払っていたのでは片手落ちです。信頼境界線を越える出力が、出力先の入力仕様として正しい出力であることにも注意が必要です。典型的な例は、リクエストされてきたURLを他のシステムにリダイレクトする場合に、ホスト名部分だけ入力バリデーションしてパラメータ部分はバリデーションしていない例です。自分のソフトウェアで使わないパラメータだからと言って、入力バリデーションしないのは問題の原因です。SSRFではこの問題が幅広く利用されています。

 

入力・出力セキュリティの誤解

非標準のセキュリティ対策定義を行っている、セキュリティ対策で最も基本的な概念である境界防御の概念を学習する機会がなかった、などが原因で入力・出力セキュリティを誤解している場合が少なくないように感じます。この話題になると日本のソフトウェア技術者の認識は欧米などに比べて10年以上遅れているように思えます。今時、「入力バリデーションはセキュリティ対策ではない」などというと正気か？と疑われてしまいます。しかし、日本では「入力バリデーションは最大のセキュリティ対策です」と言うと反対に正気か？と疑う人が出てきます。10年どころか20年以上認識が遅れているかも知れません。

セキュリティ対策の最も基本かつ重要な概念である境界防御を理解していれば、入力と出力で十分なセキュリティ対策を行う、に疑念の余地はありません。もし、自由に記述できるプログラミング言語を使いながら、境界防御を行わなくてもより効率的かつ安全にソフトウェアを構築できる概念が存在するなら是非共有して頂きたいです。（境界防御を考えなくても作れるアプリケーション／プラットフォームなどの構築は可能です。”自由”を制限すれば良いだけです）

世界のセキュリティ専門家のみでなく、言語開発者の間でも既に入出力セキュリティがどうあるべきか、結論が出ています。最近開発されているモダンな言語のほぼ全ては契約プログラミング（Design by Contract）を何らかの形でサポートしています。契約プログラミングでは呼び出す側が呼ばれる側の契約（仕様）を満たし、呼び出された側は呼び出しが終了した場合に契約（仕様）を満たす事が求められます。プロダクションコード実行時には契約確認は行われません。開発時に全ての契約が正しく定義され、契約が満たされていれば契約確認のコードは必要ありません。

契約プログラミングを行うと、最終的に契約を満たすかどうか確認はアプリケーションやライブラリの入力と出力で行われる事になります。この部分は実行時に削除される契約確認のコードではありません。契約プログラミングを行った上で、厳格な入力バリデーションと確実な出力をアプリケーションやライブラリが行えば、安全かつ高性能なソフトウェア構築が可能となります。（十分なテスト、縦深防御や適切なエラー処理は必須です。念の為）

契約プログラミングの有効性は実験段階ではありません。既に実証済みです。契約プログラミングは、実装の詳細をできる限り隠蔽する構造化プログラミングや抽象化といった設計スタイルからは少し違った形の設計モデルですが、契約プログラミングが安全かつ高性能なソフトウェア開発に有意義であることはソフトウェア技術者であれば理解できると思います。

「入力バリデーションがセキュリティ対策として効果的でない」と主張される方も居ます。CWE/SANS TOP 25のMonster MitigationはCVE、CWEなどを体系的に分析し、セキュリティ専門家が最大のセキュリティ対策である、と結論しています。効果的でないとするにはそれなりの根拠が必要です。私の感覚でもアプリケーション脆弱性の8割、9割は入力と出力の処理部分で発生していると思います。

ソフトウェアのセキュリティは何はともあれ、「入力」と「出力」の境界防御で守る。境界防御が十分に有効でない場合や失敗した場合に備え、縦深防御を行う。これが常識になった時、日本で生産されるソフトウェアの安全性が向上する時だと思います。

ネットワークセキュリティ対策では当たり前に行われており、実績もあげています。

ネットワークにおける境界防御と縦深防御

境界防御と縦深防御の例として解りやすいものは恐らくネットワークセキュリティ対策です。ネットワークセキュリティ対策と言えば、まずファイアウォールでの境界防御です。

安全なネットワークを構築する場合、まず組織のネットワーク（境界）を守るファイアウォールを設置することは常識です。ファイアウォールでは全てのネットワークパケット（入力と出力）をホワイトリスト方式（許可するパケット）のみを通過させます。ファイアウォールにメールファイアウォール（SPAM、ウィルスフィルター）やWebアプリケーションファイアウォール（WAF）を組み込む事もできます。この場合、アプリケーションレベルの境界防御もファイアウォールで行うことが可能です。

通常WAFでは完全にWebサーバー・アプリケーションへの攻撃を防止することは不可能です。Webサーバーへの通信を許可する場合、攻撃者は攻撃用のデータをWebサーバーに送信可能になります。この場合、ファイアウォールの次の境界はWebサーバー・アプリケーションになり、Webサーバー・アプリケーションが自分の責任範囲となる境界防御を行わなければなりません。Webアプリケーションにとっては境界防御ですが、ネットワークシステムから見ると侵入を許さざるを得ないケースの縦深防御です。

ファイアウォールによる境界防御でネットワークを保護する目的は、多数あるネットワーク機器の安全性を完全に担保することが困難だからです。アプリケーションでも同じです。多数あるライブラリやシステム上のリソースへのアクセスの安全性を担保することは困難です。たとえオープンソースのみであっても、アプリケーションが利用する全てのライブラリやシステムリソースの安全性を完全に確認しながら、コードを書くことは不可能です。プロプライエタリの場合、コードの確認はそもそも不可能です。自らが書いているアプリケーションコードの安全性の保証もままならない場合も多いのに、フレームワークやライブラリ、その他のリソースの安全性まで保証することは不可能でしょう。

ネットワーク防御の常識（概念）ではまず境界防御をホワイトリスト方式で行う、その上で必要な縦深防御策を用意します。アプリケーション防御の常識としても利用可能です。まず境界防御をしっかり行い、アプリケーション内部への侵入を許可せざるを得ないデータやセキュリティ上重要な部分に縦深防御策を用意すると、安全性を維持しやくなります。

ネットワークセキュリティ対策では常識である考え方が、アプリケーションセキュリティ対策では常識になっていません。これは開発者の問題ではありますが、セキュリティ教育の問題の方が大きいように思えます。

まとめ

標準のITセキュリティ維持の方法をどう説明しても考えが伝わらない方が時々居ます。単純にセキュリティの用語定義が異なっていることが原因だとしても、Securityの訳語である「安全・防衛・警備」に「リスクの緩和」「リスクの削減」などが含まれる事は明らかでしょう。完全な「安全・防衛・警備」などは実現不可能です。ISOの定義でもリスクの緩和策、削減策もセキュリティ対策です、と紹介しても理解できません。根本的な原因はセキュリティを体系的に学習していない為、セキュリティの意味、基本概念である境界防御が縦深防御を理解していない事にあるのかも知れません。ITセキュリティリテラシーの欠如が根本的な原因に思えます。（もしくは、標準的ではないITセキュリティの概念を教えられている？！）

セキュリティ関係者、特にソフトウェアセキュリティに関わる関係者は個別のテクニックや手法を啓蒙するより、まずSecurityの意味を教え、セキュリティの基本概念である境界防御と縦深防御の概念とはどんな概念なのか啓蒙すべきだと思います。Securityの意味が異なっていたり、境界防御、縦深防御を否定するようでは話になりません。その上で「ITセキュリティ」の概念を啓蒙すべきだと思います。いくらテクニック・手法を教えても、概念から勘違いしているようでは安全なソフトウェアを構築する事は困難です。

 セキュリティ専門家で、Securityはリスクの排除のみ、境界防御／縦深防御は必要ない、と言う人は一人も居ません。ITシステムに関わる方は全ての技術者はセキュリティの概念を正しく理解しましょう。基本は簡単です！その上でITセキュリティとは何か？基本的なリテラシーを身に付ければ効果的でしょう。技術者としてOECD情報セキュリティガイドライン勧告、ISO 13335、ISO 27000を一度読んでおいて損はありません。

アプリケーションセキュリティ対策のポイント

• セキュリティ対策とは基本的には全て緩和策
• セキュリティ対策な何よりもまず境界防御（入力：ホワイトリスト優先、出力：確実に安全な出力）
• 境界防御で防げないリスクは、縦深防御で確実に防御（縦深防御もレイヤーの異なる境界防御）
• セキュリティ上重要な部分は攻撃・間違いが発生する前提で縦深防御を用意
• セキュリティ対策の評価は結果と発生頻度、許容の可否よって決まる（これは別エントリで）

セキュリティ対策や脆弱性の評価についてのエントリも必要だと思います。これにも誤解が多いと感じています。これはまたの機会に紹介します。

もし誤った用語定義や概念を教えられていた方、それは貴方の誤りではありません。教えた方の誤りです。気にする必要はありません。もし誤った事を教えてしまった方、訂正すれば問題ありません。できるだけ早く、広く誤りを訂正しましょう。

もしこの説明でも解らなかった方、残念ながら私にはこれ以上解りやすい説明は今の所ありません。身近なセキュリティ専門家に相談してみてください。結果をこのブログのコメントで頂けると助かります。

セキュアなプログラムを書く具体的な方法の解説は行いませんでしたが、このブログでも色々紹介しています。今後も紹介します。基本は簡単です！楽しくセキュアにコーディングしましょう。

追記：

合成の誤謬の罠にはまってしまっている方も居ると思います。参考リンクをご覧ください。

参考：

• 「出力対策だけのセキュリティ設計」が誤りである理由
• 実は標準の方が簡単で明解 – セキュリティ対策の評価方法
• ニュートン力学と相対性理論 – エンジニアに見られるセキュリティ対策理解の壁
• 知らないと勘違いする「合成の誤謬」の罠
• 攻撃者が”嫌う”セキュリティ対策とは何か？
• NSAのTOP 10の緩和策（＝セキュリティ対策）アメリカ合衆国編
• TOP 35の緩和策（＝セキュリティ対策） オーストラリア編