JNSA「セキュリティしんだん」

 

«(24)「ワッセナーアレンジメント再交渉とトランプ政権のサイバーセキュリティ政策」 (26)WannaCry覆面座談会 〜何故、単なるワームがこれほど騒がれたのか〜 »


(25)腹が立つのもわかるけど - 脆弱性とセキュリティ対策再考(2017年6月19日)

日本マイクロソフト株式会社 チーフセキュリティアドバイザー
日本ネットワークセキュリティ協会 副会長
高橋 正和

ここ数か月の間にも、ランサムウエアやクレジットカード情報の流出など、セキュリティ事件が相次いでおり、これらの事件の背景にはソフトウェアの脆弱性がある。Windows等のソフトウェア製品であるか、Apache等のオープンソースソフトウェア(以下OSS)であるかにかかわらず、膨大な脆弱性が報告され、深刻なセキュリティ事故へとつながっている。

利用者の立場で考えると、脆弱性はソフトウェアメーカーの問題であり、なぜ自分達(利用者)が対応しなければならないのかと、腹が立つものわかる気がする。しかし、対策を放置することで攻撃を受け、大規模な事件につながるよりは、ソフトウェアには脆弱性があるものだと考えて合理的な対策を進める方が、ITを効果的に利用し、ビジネスの不確定要素を減らすことになる。
 一般に、セキュリティ対策はいわゆるウォータフォールモデルのメンテナンスサイクルと考えられることが多く、特に脆弱性対策は補正的・補助的なメンテナンス、つまり本来は必要がない余計なものとして捉えられる。
 一方で、ソフトウェア開発では開発とリリースのサイクルを短くするDevOpsへの取り組みが進んでおり、必然的にメンテナンスが開発と運用に組み込まれはじめている。セキュリティ対策においても、DevSecOpsとして開発(企画、設計、導入)と運用にセキュリティと“メンテナンス”を組み込み、セキュリティ対策のサイクルを短くすることも考慮すべきである。

ところで、脆弱性は欠陥やバグと呼ばれることもあるが、これらの品質問題とは少し違っている。品質は、原則として利用者とソフトウェアの二者間の問題だが、脆弱性の悪用は攻撃者という第三者が問題となる。つまり、ソフトウェアを利用者が使っている上では問題がないのだが、攻撃者が悪用をすることで、PCの乗っ取りや破壊といった問題がおきる。自動車でいえば、ドアに鍵をかけているのに車上荒らしに合う問題や、鍵がないのにエンジンをかけて車を盗まれるといった問題が脆弱性に該当する。
 オーストラリア自動車アセスメント・プログラム(ANCAP)が公表した、同じ自動車の1998年モデルと2015年モデルのクラッシュテストの結果を見ると、1998年モデルは衝突時に脆弱であることが明確に示されている。古いシステムが通常の利用では大きな問題がなくとも、クラッシュという危機的な状況では、きわめて脆弱なシステムであることを直感的に示す事例となっている[*1]。

脆弱性を悪用した攻撃は、原則として脆弱性を取り除けば防ぐことが出来る。脆弱性情報はソフトウェアの開発・販売元やJPCERT/CCなどから公表されているので、これを参照して対応すれば該当する脆弱性が攻撃される心配から解放される。しかし、往々にして必要な対策が行われず、未対策のソフトウェアが攻撃を受け、大きな被害につながっている。
 脆弱性対策を実施しない理由を考えてみると、脆弱性情報を知らないケースと、脆弱性情報を知っていても対策を実施しないケースが考えられる。例えば、マイクロソフト社は脆弱性が多いと言われるが、これは脆弱性を周知する公式な手順があり、また積極的な周知が背景にある。マイクロソフト社製品についての情報収集は容易であり自動化ができる。一方で、適切な脆弱性情報開示をしていないメーカーやOSSの場合は、脆弱性情報の入手が必ずしも容易ではなく、脆弱性「情報」の入手は利用者自身の取り組みに大きく依存する。

IPAがテクニカルウォッチとして、2015年に公開をした「脆弱性対策の効果的な進め方(実践編)[*2]」 によれば、2014年にはOSSであるOpenSSL, Apache Struts, GNU bash等、大きな被害につながった深刻な脆弱性が取り上げられており、本年(2017年)も、新たにApache Strutsの脆弱性が公表され、公表直後の攻撃により日本国内でも多くの事件が確認されている[*3]。これらの事例は、セキュリティ対策においてOSSの対策が盲点となりがちなことを示している。
 IPA資料では、脆弱性情報の入手先が紹介されており、これらの情報を参考にして、利用しているソフトウェア製品(ハードウェアの場合もある)の脆弱性情報の収集を進めることが推奨されている。
 一方で、脆弱性情報の収集を始めてみると、情報量があまりに膨大で適切な対処を行うことが難しいことを実感することになる。IPA資料では、現実的な手法として登録した製品の脆弱性だけを表示するmyJVN[*4]が紹介されている。myJVNのアプローチは、セキュリティ対策を進める上では、稼働しているリソース(ソフトウェア、ハードウェア)を正確に把握することが不可欠であることを示している。
 リソースの把握に重点を置くのは国際的な動きでもあり、SANS CIS Critical Security Controls(CISCSC)[*5]では、効果的な対策(コントロール)の1番目にハードウェアのインベントリ、2番目にソフトウェアのインベントリを挙げている。そして、3番目としてシステムの設定、4番目の項目としてここで話題にしている脆弱性の診断と修正が挙げられている。さらに、5:管理権限のコントロール、6:監査ログ、7:電子メールとブラウザの保護と続き、8番目の項目として:マルウェア対策が挙げられている。
 この資料では、セキュリティ対策の軸が、ウィルス検知等の異常系から、ガバナンスに基いた正常系に力点を置くなど、セキュリティ対策の考え方が変わってきていることを示している。

SANS  CIS Critical Security Controls
 CSC1: 許可されたデバイスと無許可のデバイスのインベントリ
 CSC2: 許可されたソフトウェアと無許可のソフトウェアのインベントリ
 CSC3: モバイルデバイス、ラップトップ、ワークステーションおよび サーバに関するハードウェア
     およびソフトウェアのセキュアな設定
 CSC4: 継続的な脆弱性診断および修復
 CSC5: 管理権限のコントロールされた使用
 CSC6: 監査ログの保守、監視および分析
 CSC7: 電子メールとWebブラウザの保護
 CSC8: マルウェア対策.
 CSC9: ネットワークポート、プロトコル、およびサービスの制限およびコントロール
 CSC10: データ復旧能力
 CSC11: ファイアウォール、ルータ、スイッチなどのネットワーク機器のセキュアな設定
 CSC12: 境界防御
 CSC13: データ保護
 CSC14: Need‐to‐Knowに基づいたアクセスコントロール
 CSC15: 無線アクセスコントロール
 CSC16: アカウントの監視およびコントロール
 CSC17: スキル不足を補うためのセキュリティスキル評価および適切なトレーニング
 CSC18: アプリケーションソフトウェアセキュリティ
 CSC19: インシデントレスポンスと管理
 CSC20: ペネトレーションテストおよびレッドチームの訓練

ここまで、脆弱性とセキュリティ事件から、セキュリティ対策の方向性について取り上げてきたなかで、二つの傾向が読み取れる。
 まずは、脆弱性対策の重要性である。現在のICT利用において脆弱性対策を避けて通ることは難しい。腹が立つのもわかるのだが、検証や展開の自動化、モジュールやセグメントの見直し、そしてセキュリティ対策の影響を受けにくいソフトウェアやシステムの選択など、淡々とセキュリティ対策を進めるための工夫が必要になっている。DevOpsの考え方は、セキュリティでも展開が可能であり、DevOpsのサイクルにセキュリティを組み込むDevSecOpsの傾向が強まると考えられる。
 次に、セキュリティ対策が、異常系から正常系にシフトしている点である。セキュリティソフトを中心とした対策から、利用するソフトウェアやハードウェアのインベントリを行い、適切な設定で運用すること。そして脆弱性の対策を行い常に攻撃可能面(アタックサーフェス)を最小に保つこと。アカウント戦略を明確にし、適切な権限で利用すること等のあるべき姿が重要視される。正常な状態が定義されていない状況では、セキュリティソフトは適切に機能せず、あるべき姿が適切に実施されることで、初めてセキュリティソフトが効果的に機能する。
 この二つの傾向を念頭においてセキュリティ対策を進めることで、より効果の高い、腹の立ちにくいセキュリティ対策が実施できるものと考えている。

[*1]【ビデオ】1998年式と2015年式のトヨタ「カローラ」同士で衝突試験を実施!
http://jp.autoblog.com/2017/05/18/corolla-vs-corolla-crash-test-safety-video/
[*2] IPAテクニカルウォッチ「脆弱性対策の効果的な進め方(実践編)」
http://www.ipa.go.jp/security/technicalwatch/20150331.html
[*3] 2017年3月に発生したApache Struts 2で稼働していたとみられるWebサイトへの不正アクセスについてまとめてみた
http://d.hatena.ne.jp/Kango/20170311/1489253880
[*4] MyJVN
http://jvndb.jvn.jp/apis/myjvn/mjcheck.html
[*5] SANS CIS Critical Security Controls :効果的なサイバー防御のためのCIS クリティカルセキュリティコントロール
https://www.cisecurity.org/wp-content/uploads/2017/03/CIS-CSC_v6.1_Japanese_Final_r1.pdf



 
«(24)「ワッセナーアレンジメント再交渉とトランプ政権のサイバーセキュリティ政策」 (26)WannaCry覆面座談会 〜何故、単なるワームがこれほど騒がれたのか〜 »