• 脆弱性の深刻さはそれぞれ違う
  • パッチ適用前にシステム部門の意見を聞け
  • 代替策を必ず用意せよ

    • 　セキュリティ対策は、一筋縄ではいきません。現場によって利用環境や体制などが大きく異なり、PCI DSSなどの業界標準やセキュリティベンダーが語る「あるべき論」を、そのまま当てはめれば済むというものではないからです。コストや人員といった制約がある中、それぞれの企業の現場で知恵を絞り、考えを巡らせて日々対応しているのが現実です。

    　本記事では、さまざまなセキュリティ施策が、実際の現場でどのように実装、運用されているのかに焦点を当て、「現場の知恵」を伝えていきます。普段はあまり表に出ることのないセキュリティ担当者の役割や奮闘ぶりを企画担当者やアプリ担当者などに知ってもらい、相互に連携が不可欠な作業がより円滑に進むようになればと願っています。

    　さて、今回は、セキュリティの基本中の基本ともいえる「パッチマネジメント」を取り上げます。パッチマネジメントは、長年にわたりシステム運用におけるセキュリティ上の大きな課題であり続けてきました。特に昨年から今年にかけて、HeartbleedやShellShock、POODLE、GHOSTといった脆弱性がセンセーショナルに報道されました。他にもStrutsやBINDなど、クリティカルな脆弱性がたびたび報告される製品もあり、システム運用において頭の痛い問題になっています。

    　これらニュースになるような深刻なもの以外にも、数多くの脆弱性が毎日のように報告されています。センセーショナルに報道された脆弱性であっても、POODLEやGHOSTなどは、実際に悪用するには厳しい前提条件があるので、すぐに被害が出るとは考えにくいものでした。その一方で、公開後数日で世界規模のサイバー攻撃が起こった2013年のStruts2の脆弱性（CVE-2013-2251）のように、早急な対応が求められるものもあります。また、脆弱性によって影響範囲が狭いもあれば、サーバーサイドのPHPやJRE、データベースなどのように影響範囲が広く、検証に手間がかかるといった理由からパッチ適用が難しいものもあります。