圧倒的に有利な攻撃者
セキュリティ担当者は反撃できない
「攻撃は最大の防御」という言葉があります。しかし情報セキュリティの場合、私たちは外部からの攻撃を防ぐために相手を攻撃できません。つまり、どこからどのような攻撃が来るか想定できない状態で、常に防御しなければなりません。
攻撃者にとってみれば、攻められることがない状態なので、自分のタイミングで行動を起こせます。守りが手薄になっている時期や、重要な情報が集まっている時期など、ターゲットの状態を把握したうえで攻撃が可能です。しかも、あらゆる手段を使って攻撃を実施し、失敗すればほかの手段を順に試せます。ウイルスだけでなく、DDoS攻撃やネットワークへの不正侵入、アカウントの乗っ取りなど、さまざまな手段があります。
ターゲットに1つでも弱点があれば、攻撃者は見つけてしまいます。攻撃に成功し、パソコンを乗っ取れば、攻撃者にとっては資産になります。乗っ取ったパソコンで複数のウイルスをインストールしたり、外部から操作するためにポートを開けたり、ほかのコンピュータにも手を広げて資産を増やしたりと、次々と攻撃が成立していきます。
攻撃に成功しなかった場合は、別のコンピュータや会社にターゲットを変更するだけです。世の中には不適切な設定でインターネットに接続されているコンピュータが多数存在するため、攻撃ができないタイミングはありません。攻撃者にとって圧倒的に有利な状況です。
団結して守る
逆に考えると、ほかの組織に被害が広がらないように、防御する側による情報の共有が求められています。例えば、IPAを中心に組織されている「サイバー情報共有イニシアティブ(J-CSIP:ジェイシップ)」のような取り組みもあります。検知されたサイバー攻撃などの情報をIPAに集約して、参加組織間で情報共有を行っており、運用状況も公開されています。
また、「日本シーサート協議会」のように、セキュリティインシデントが発生した場合に、シーサート間で連携し、被害を最小限に食い止める体制作りも進んでいます。
バランスを意識した対策の実施
情報漏えいの事件が発生すると、多くの企業ではツールを導入して防ぐ方法が検討されます。しかし、安全性を保つために導入したツールによって、利便性が大幅に失われるのは問題です。インターネットからの攻撃を防ぐためにインターネットに接続しない、というのでは仕事にならないでしょう。
そこで人の教育を進めるという話も出てきます。定期的に従業員にセミナーを受講させたり、テストを実施したり、といった対策を行っている企業も多いでしょう。ただし、それでも情報の漏えいはなくなりません。
結果として、人の対策には限界があり、やはり技術的に対策すべきだという意見が出てきて、堂々巡りになります。リスクと対策コスト、安全と利便性のバランスを考えて対策を模索することは続きそうです。
なぜ脆弱性が生まれるのか?
開発時に作り込まれる脆弱性
コンピュータを攻撃して管理者権限を取得するには、管理用のパスワードを盗むほか、脆弱性を攻撃する方法があります。多くのエンジニアはソフトウェアを開発するとき、セキュリティに気を配って脆弱性を作り込まないように考慮していますが、人間が開発する以上100%防ぐことはできません。
意外と多いのが、開発時には問題なくても、修正したときに脆弱性を作り込んでしまう場合です。特に、当初の開発者とは異なる人が修正した場合、セキュリティ上の意図に気づかずに修正してしまい、脆弱な部分ができることが考えられます。
学校などでプログラミングを学び始めたときに、セキュリティに関する説明が後回しにされる現実もあります。時間的な制約もあり、実現したい機能の実装が優先されると、見た目上の問題がなければ完成とみなされることもあります。結果として、セキュリティ意識が低いまま開発してしまい、脆弱性のあるソフトウェアができあがります。
また、ベテランになると古い知識のまま開発を行っている場合があります。新たな攻撃手法は日々研究されているので、継続して勉強していないと、セキュアなシステムは開発できません。
セキュリティの優先順位が低いままになっていないか
一方で、セキュリティを意識した開発の重要性を理屈では分かっていても、ビジネス面から優先度が下がっている場面も見受けられます。納期に間に合わない、開発費用を抑えたいなどの意識が働くと、テスト工程が削減される傾向にあります。
一般に、セキュリティに関する業務は利益を生まないため、設計や開発に対するコストが発注側に理解されにくい部分があります。多くの利用者にとっては、「不具合がある方が問題だ」「不備の修正であれば費用は開発側が負担すべきだ」「不具合がなくなってからサービスとして提供すべきだ」と考えます。これは間違いではありませんが、現実的には困難です。
安全を保つためにも、エンジニアの倫理観や、発注側の意識を育てる必要があるでしょう。セキュリティ事件が発生してしまった場合には、システムの修正や復旧だけでなく、損害賠償やクレーム対応、企業イメージの回復策などに莫大なコストがかかります。これらを未然に防ぐためには、システム開発の費用や納期、テストの網羅性などを総合的に設定する必要があります。