ITセキュリティは国際標準化（ISO27000）もされ、ISMS認証取得済みの組織も5000程もあり広く認知されている概念のハズですがそうでもありません。簡単にセキュリティ基礎知識を持っているか、いないか、判別でれば、エンジニアの採用や既存スタッフの知識レベルの確認などに役立つと思います。
以下はITセキュリティの基礎知識を持っているか、いないか？簡単に判別できる質問です。一言で答えてください。
- ITセキュリティ対策の目的とは？
- ITセキュリティ対策の定義とは？
（解説を見るにはスクロールしてください）
解説：ITセキュリティ対策の目的とは？
国際情報セキュリティ標準に準拠する模範的な解答は
- ITシステムを、許容可能なリスクに抑えて、利用すること
です。NGの解答例は
- 脆弱性を修正／排除すること
- 攻撃者からシステムを守ること
- 攻撃できないようにすること
などです。
「脆弱性を修正／排除すること」や「攻撃者からシステムを守ること」はITセキュリティを実現する為の手段の１つであり、手段は目的になりません。「保険を利用すること」もITセキュリティ対策の手段の１つであったり、「スタッフの教育を行うこと」や「リスクを許容すること」もITセキュリティ対策の手段として含まれることから明らかです。サブセットをフルセットと取り違える（部分を全体と勘違いする）のは明白な誤りであり、手段を目的化するのは間違いの元です。
ITセキュリティ対策の目的は「ITシステムを許容可能なリスクに抑えて利用する」ことにあり、それを実現するために必要なマネジメントを行います。これがセキュリティ対策です。
参考：
解説：ITセキュリティ対策の定義とは？
- ITシステム利用のリスクを変化させる全ての管理策
です。全てのリスクに対応する管理策がセキュリティ対策です。以下はISO 27000のリスク対応（Risk Treatment）の私的に訳した日本語訳です。
リスク対応
リスクを変化 (2.61)させる為のプロセス(2.54)ノート 1
リスク対応には以下の項目を含める事ができる:スクを発生させる活動を開始しない、または継続しないことを決断することによりリスクを回避する。
機会を獲得する為にリスクを選択または増加させる。
リスクの原因を排除する。
発生の頻度を変える。
結果を変える。
他の組織（契約企業やリスクの資金的処理を含む 訳注：保険など）とリスクを共有し見聞のある選択によりリスクを抑える。ノート 2
否定的な結果をもたらす事象のリスク対応は、”リスク緩和策”、”リスク排除策”、”リスク防止策”、”リスク削減策”などと呼ばれる事がある
ノート 3
リスク対応は新しいリスクを生成したり、既存のリスクを変更することができる
NGの解答例は
- 脆弱性を排除することを目的とした対策
- リスクを低下させる対策
などです。
あるリスク対応策（≒セキュリティ対策）が部分的にはリスクを廃除／軽減しても、他の部分でリスクを増加させることはよくあることです。リスク増加を管理しない／無視することは”セキュリティ対策”ではありません。
脆弱性を排除、リスクを低下させるモノだけがセキュリティ対策ではありません。まして、セキュリティ対策かどうか？の区別に主観に基く「目的」は関係ありません。ITセキュリティ対策の目的は「ITシステムを許容可能なリスクに抑えて利用する」です。ITシステムを利用する為にリスクを許容する（リスクを増加させる）こともセキュリティ対策として管理します。
ISO27000では「セキュリティ対策」という用語は直接定義していませんが、一般にセキュリティ対策と呼ばれる言葉の意味で「リスク対応」を定義しています。
この定義を一言で言うと「リスクを変化させる対策すべて」になります。リスクの変化には増加も削減も含まれます。リスクの変化は客観的に評価でき、目的のように主観で変ることもありません。セキュリティ対策であるものは常にセキュリティ対策であり、その優劣は費用対効果で決まります。
参考：
まとめ
ITセキュリティの「目的」や「用語の定義」が異なっているようではマトモなセキュリティ対策を期待できません。自身の組織や顧客がISMS認証を取得している場合、これらは基礎の中の基礎ですが、正しく認識されているか確認してみると良いでしょう。意外に正しく理解されていないケースが多いと思います。「これはセキュリティ対策である／ない」「セキュリティ対策とは何が何だか解らない」などとなるのは、この2つの定義が理解／共有されていないことに原因であるようです。
ITセキュリティ”専門家”の中には国際標準の概念を無視し、主観に基く狭い目的／定義を利用している方も居るので注意が必要です。知る限りでは、非科学的で根本的な部分から問題な物ばかり、標準より優れた概念と言える物は聞いたことがありません。ですが、それでも問題ないと感じる方も多いようです。
根本から間違っていると、プログラミング原則やセキュアプログラミング概念を真っ向否定したり、最も重要な対策は「セキュリティ対策ではない」と勘違いしてしまいます。それが開発者であったりするので問題は大きいです。
参考
