【脆弱性鼎談】第二回　実務担当者が現場の立場で語りつくす！　IT/OTセキュリティ対策の実際

前回はlog4jなども話題になっている「脆弱性情報のトレンド」について3人の識者に報告して頂きました。今回は、こういった脆弱性に対して、一体どのように担当者が考えて対策を打ち、それを踏まえて企業のセキュリティポリシーをどう適用させていけばよいのかというテーマを中心に議論が展開されました。

机上で発生する脆弱性は本当に有効なのか？

エンジニアA
(脆弱性に関わる事象であることなのですが)OpenSSLについてサイドチャネル攻撃（★注1）が見つかった後に、また雨後の竹の子のようにサイドチャネル攻撃が見つかったのかとか。どこかの大学院生が卒論で発表したような、確かに机上では可能だけど……という脆弱性が発見され、それを騒ぐということもありました。

（★注1）サイドチャネル攻撃
side-channel attack：暗号解読やソフトウェアのバグなど、アルゴリズムの実装自体の弱さではなく、コンピュータシステムの実装から得られる情報をベースにした暗号解読の攻撃のこと。「タイミング攻撃」「故障利用攻撃」「電力解析攻撃」「電磁波解析攻撃」「キャッシュ攻撃」「音声解析攻撃」などがある。

エンジニアB
それはハードウェアの消費電力を外部から測る電力解析攻撃のような話ですよね？

面氏
そうですね。研究として見つけた脆弱性ですね。ひとつ面白かったのが「電球の光を測る？」っていうのがありまして。消費電圧が変わるから、電球の光の微妙な変化（電圧）を光センサーで測って、それで何を処理しているかということと、この処理のタイミングなどを見つけられるみたいな論文が一時期発表されました。しかし「それの有用性ってどうなんだろう？」という疑問は残りました。

エンジニアA
まあ、ほんとに想像というか、確かに理論上は可能かも、という脆弱性も目立ちますね。

面氏
セキュリティの世界は、やっぱり軍事技術から来ているので、「そんなハードウェアの電圧などのレベルまで民間に求めるのは酷」という話はあるかもしれません。

脆弱性公開情報の推移と、ノイジーな情報の増加

面氏
あちこちで脆弱性公開情報の推移の話をするのですが、特にHeartBleed（★注2）の辺りで、OpenSSLに対しての脆弱性がさまざまなソフトウェアからOSSを利用している機器まで影響を受けていまして。その辺りでGoogleがSyzbot（★注3）とか、ファジングツールでの自動脆弱性調査ツールを出してきたわけですね。他にもファジングツールがいろいろ登場して、その煽りでファジングツールが見つけてくれるような脆弱性がいっぱい出てきたんですね。結局、皆さんツールを突っ込んで、自動的にソースコードを調べる、という感じになったので。

（★注2）HeartBleed
OpenSSLの暗号ソフトウェアライブラリ上で発見された脆弱性。OpenSSLにはSSL の死活監視機能として「Heartbeat」があるが、この機能の処理における境界チェックの不備に起因するもので、本脆弱性が悪用された場合、システムのメモリー内の情報が第三者に閲覧され、SSL暗号化通信の内容や秘密鍵などの重要情報が漏洩する可能性がある。

（★注3）Syzbot　
kernel/syzkallerのビルドとアップデートを自動的に行ったり、テストマシン(qemu、Android,、ODROIDなど)の管理、バグのレポートとステータスのトラッキングなどを行うツール。

エンジニアB
そうですね。セキュリティ界隈の人達のSNSを見てみると「今度はこんなCVEを見つけました」っていうツイートを見かけることがあります。実際に報告のissueを見てみると、「ファジングツールでこのデータを入力すると、ソースコードのこの箇所でこういうことに成功しました、それを再現するためのデータが一緒に付属している」という報告だったりします。

（★注4）CVE
Common Vulnerabilities and Exposuresの略。 情報セキュリティにおける脆弱性やインシデントについて、それぞれ固有の名前や番号を付与し、 リスト化した事典のこと。

面氏
あれが出てくれたおかげで、だいぶLinuxなどもバグ出しなどが終わってきていました。私は脆弱性をずっと追いかけているのですが、「2018年ぐらいにはもう粗方（あらかた）終わった」という言い方が適切ではないかもしれませんが、Linux Kernelに関しては開発もガンガン進んでいるので、脆弱性が見つかっても数自体は減ってきています。Open SSLやBindにしても、年に1、2回くらいしか大きな脆弱性が出なくなっていますね。

とはいえ、「CVEが発行されているのは何か？」と言うと、GitHubも流行ったおかげで、どんどんいろんなものを公開するようになって、その辺、自分で公開しているソースコードに脆弱性があるみたいなパターンが増えています。

いわゆるLAMP的なところ（★注5）や、Bindみたいなメジャーなものじゃなくて、それ以外のソフトウェア。そういう比較的新しいツールがGitHub上で公開されていて、そのあたりの脆弱性がけっこう増えています。 ナンバリングされてるイメージですね 。

（★注5）LAMP的なところ
Linux、Apache、MySQL、PHPの頭文字を取ってLAMPという。

エンジニアB
いわゆる1人プロジェクトみたいな感じで作っているシステムですよね。

面氏
そうです。その脆弱性について、ユーザーが全部を使ってるとも思えないケースが多く見られます。CVEがノイズっぽくなってきているんですよ。メジャーな脆弱性が見えにくくなっています。脆弱性情報を見るとき、中身をしっかり見るというか、ノイジーなところが多くなっているので気をつけましょうという点を、話したかったわけです。 脆弱性情報の肥大化に伴い、何でも脆弱性情報を引っ張ってくるのではなく、その情報にフィルターを掛けて、「これはよく使うやつだから、脆弱性情報を出してあげよう」というような機能が必要になっているのかな、と思ってます。だから製品なり、SIなどのサービスは有用と考えています。

セキュリティポリシーの策定によって、防げる脅威も数多くある！

エンジニアA
ノイズのような脆弱性情報に関して、お客さんからお問合せをいただくこともあります。しかし、「まずお客さんの環境では発生しないから心配しなくてもいいですよ。それより、もうちょっと他に心配するべきことがあるでしょう」と言いたくなることはあります。

面氏
確かにありますよね。「パスワードを、もうちょっと長くしましょう」とか。

エンジニアA
あと「ログインできるユーザーをきちんとaudit などで縛ってしまう」とか。

面氏
「ちゃんと1ユーザー、1アカウントでログインしましょうよ」とかね。

エンジニアA
ここらへんのポリシーがしっかりすれば、防げる脆弱性がかなりあると思うんですよ。システムの作り方の教育とか、あとはユーザー教育など。日ごろからの予防をしっかりすれば、かなりの脆弱性は押さえられます。

すごい古いOSを使っているお客さんは、最低限というか、できる限りのことは自分たちのルールで守っていて、それでも経営層から「脆弱性対策しっかりしてるの？」と言われたから、うちに仕事を依頼してきている、うちに頼ってもらっているというケースもあります。まあ、ここまで自分たちで頑張っているんだったら、お守りをぶら下げてあげる感じでもいいのかなと思っています。

エンジニアB
お客さんの運用が終わるまで、攻撃されないことを祈るばかりですね。本当に危険な状態だったら、僕たちが出てきて「危険です、危険ですよ」って警告する立場に回らないといけないですね。

面氏
話が横道にそれるかもしれないですけど、ツールでなんとかするということが最近、流行しています。OpenSCAP（★注6）というツールがあるんですが、PCI-DSSのような規約で決まっている「パスワードが何桁以上」とか「スクリーンロックが掛かっているか」といったことを調べられるツールが便利です。

（★注6）OpenSCAP
セキュリティ設定共通化手順である「SCAP」（Security Content Automation Protocol）を実施するためのオープンソースソフトウェアで、システム管理者はSCAPの規格に従ってシステムのセキュリティポリシーを簡単にチェックし、そのチェックに合格すれば、SCAPに準拠していることになり、安心して運用を継続することができる。

つまり「セキュリティの設定をちゃんとしよう」ということです。しかし、これは残念ながらOSとかを実際に運用している現場のところまではカバーできない。ポリシーを規定し、機械的にそれを遵守させることまでは可能ですが、1ユーザー・1アカウントできちんと運用しているのか、そういう点はカバーできないという弱点はありますよね。

なので、こういうツールである程度はカバーできても、最終的には運用のところが必要になってきます。そこで運用になるとコンサルが重要になりますよね、どうしても。さっき言ったような「1ユーザー・１アカウントのルール」や「パスワードを書いた紙をその辺に貼っておかないでください」ということが必要になるわけです。

ユーザー側のリスク評価と、ポリシーを決定するうえでの障害

面氏
「仮にsshに脆弱性が出たと言っても、sshを使ってなかったらいいじゃないですか」という判断が出てても、そこがちゃんと別の手段でブロックされているなら、リスクは少ないと判断できることが重要です。

エンジニアA
そうですね。「お客さん自身がどうリスクを評価するか」っていうわかりやすい指標が必要です。彼らもわかってるんだけども、もうちょっと我々に後押しして欲しいというような要望があります。お客さん自身がリスクアセスメントをして、我々としてはその材料を提供してあげれば良いと思います。

もちろん、無限にお金をつぎ込めば、確かに解消可能な脆弱性はあるかもしれませんが、台所事情もあるでしょうから、リスクの評価とその後の対応ポリシーの策定は先に手を付けるところかもしれません。

面氏
ITベンダーからすれば、ビジネスチャンスかもしれませんね。そういったコンサルが、さまざまな脆弱性をスキャンするとか、設定のスキャンでちゃんとお客さんの状況を見てます、というような。

エンジニアB
たとえば、あるCVEについて、お客さんの対応ができていないことがわかった場合に、アラートを出すということですね。

面氏
諸々の対応を含めて、年間でいくらというような（笑）。

エンジニアA
ポリシーに関連しては、日本企業でよくあることですけれど、お客さんのある部署で「うちのポリシーでやってるけど、それは他の部署の管轄では、うちの手の出しようのないところだから」と言われることがあります。我々としては「その担当者に確認してください」と言っても、本当にその担当者に確認しているんだろうか？ と。そうこうしているうちに、うやむやになるような事象があります。

面氏
だから、そのあたりのスキームを外から作ってあげる必要があるのかな。あとは、ちょっとズレますけど、脱PPAPのように国が音頭を取って「ちゃんと改めましましょう」と言ってくれるのが理想です。

エンジニアA
「こんなことで、みんな動くんだ」っていうので、ちょっとびっくりしましたけどね。あと「よそはこうやっているから、うちもやる」っていう感じで。

面氏
上からの指導っていうのと、あとは同調圧力。この2つが有効ですね。

まとめ
ここまで2021年の脆弱性情報の話から、脆弱性にどう対処していくのか、また会社のセキュリティポリシーをどう適用させていけるかという話に広がりました。直近では2021年の年末に「Log4jの脆弱性」という問題も出てきています。この脆弱性はlog4jを組み込んだシステム全般に波及しておりますが、結局「どのシステムで」「どういう（ライブラリを含めた）構成を使っているのか」という情報が、対応するために不可欠になっています。最終的には自動情報収集のインベントリと脆弱性確認をできるようなツールをなるべく多くのシステムで導入して運用し、今回のような問題が起きた場合でも早急にシステムを更新して行ける枠組みが必要になるでしょう。そういう意味では、MIRACLE Vul Hammer（★注7）のようなシステムが更に拡張されて、ライブラリなど全ての関係を一元管理できるようになれば、運用も楽になり、管理者にとっても助かると思います。

（★注7）MIRACLE Vul Hammer
企業の情報システムを構成するOSやソフトウェアに脆弱性があるかどうかを調べて可視化する、サイバートラスト社の脆弱性管理ソフトウェア。単体利用のほか、同社のシステム監視ソフトウェア「Zabbix/MIRACLE ZBX」と連携させ、Zabbix/MIRACLE ZBXの画面上で脆弱性を一元的に把握することも可能。

◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇ ◇

【面 和毅氏】
サイオステクノロジー株式会社 執行役員
OSS/セキュリティエバンジェリスト

略歴：OSSのセキュリティ専門家として20年近くの経験があり、主にOS系のセキュリティに関しての執筆や講演を行う。大手ベンダーや外資系、ユーザー企業などでさまざまな立場を経験。
2015年からサイオステクノロジーのOSS/セキュリティエバンジェリストとして活躍中。また、ヒートウェーブ株式会社でも講師として活動中。
専門分野はSELinuxを含むOSのアクセス制御、AntiVirus、SIEM、脅威インテリジェンス。

【エンジニアA】
サイバートラスト株式会社 基盤技術部に所属

元々は HP-UX でテレコム系の保守をしていたが、紆余曲折あって入社後 Linux OS である MIRACLE LINUX の開発・サポートに従事。好きな生き物はカエル。

【エンジニアB】
サイバートラスト株式会社 OSSプロダクトマネジメント部 シニアエンジニア

入社後基盤技術部にて、Linuxディストリビューション「MIRACLE LINUX 8」の開発・サポート、脆弱性のウォッチなどに関わる。
現在の所属はOSSプロダクトマネジメント部