扱うソフトウェアすべての脆弱性情報を収集するのが不可能なら、優先的に管理すべきソフトウェアを決める必要があります。
大量に個人情報を扱っているソフトウェアや、重要性の高い脆弱性が何度も公表されているソフトウェアは、情報を適時に入手すべき対象の候補になるでしょう。
開発元のリリース情報を直接参照する必要もあるでしょうし、場合によっては開発者向けのバグトラッキングシステムのチケットを追いかける必要もあるかもしれません。
内製することが難しい場合は、「台帳に基づいて脆弱性情報を提供してくれるサービス」を利用することも考えられます。
ーーパッチはどのように適用すればよいでしょうか。
この3月、「Struts2」の脆弱性によって大きな被害が発生しました。日本でクレジットカード情報漏えいの被害にあった企業では、開発元が脆弱性情報を公表してからわずか30時間後に最初の攻撃を受けています。
これでは、検証環境にパッチを当てて半月ほど検証し、問題がないことを確認してから本番環境に適用する――といった典型的な手順では間に合いません。
「とにかくパッチを当てなければやられる」時代になりつつあります。
一方で、この6月に世間を賑わした「NotPetya」の感染源のひとつは、ソフトウェアアップデートの改ざんでした。「パッチを当てるとやられる」わけです。
ーーすぐにパッチを当てないとやられる、でもパッチを当てるとやられる……。
もはや、パッチ適用の手順だけの見直しでは対応しきれません。もう少し広い視点で対応を考えていく必要がありそうです。
サイバー攻撃対策が一筋縄でいかないのは、自分たちの業務プロセスのどこにリスクがあるのかといった内的要因だけでなく、攻撃の傾向といった外的要因、インテリジェンスの果たす役割の比重が大きいといった点に主な原因があります。
「Struts2やNotPetyaの出来事に基づいて、パッチ適用方法の改善を検討できているか」ということが、組織の対応力を図る上でも重要ですね。
<続く>
