脆弱性診断技術やサイバーセキュリティに関する情報を発信するブログメディア

「稼働中のサービスには脆弱性が100%存在する」脆弱性が無くならない理由と、対策への第一歩


イエラエセキュリティの顧問を務める川口洋が、イエラエセキュリティを支える多彩なメンバーと共にゲストを他社からお迎えし、サイバーセキュリティやサイバーリスクの今を語り合う座談会シリーズが、本日から始まります。
川口洋氏は、株式会社川口設計 代表取締役として、情報セキュリティEXPO、Interop、各都道府県警のサイバーテロ対策協議会などで講演、安全なITネットワークの実現を目指してセキュリティ演習なども提供しています。2018年からはサイバー攻撃をゲーム感覚で楽しむプロジェクト「Micro Hardening」で全国ツアーを開催するなど、サイバーセキュリティに関するコミュニティ活動にも長年貢献してきた人物です。

今回の座談会に登場するイエラエセキュリティのメンバーは、研究開発室 室長を務める柏崎央士。2007年からセキュリティ業界に入り、脆弱性診断などの業務に従事してきましたが、現在は脆弱性診断にまつわる技術支援者という立場になっています。
そして記念すべき第1回目のゲストは、フューチャー株式会社より、OSSの脆弱性スキャナ「Vuls」作者である神戸康多氏をお招きしました。HITCON、Open Source Summit North Americaなどの海外カンファレンスを始め、国内カンファレンスにも多数登壇されており、1万人以上のエンジニアが参加する情報収集用公開Slack「モヒカンSlack」総裁でもありますので、ご存じの方も多いのではないでしょうか。
サイバーセキュリティという分野の中でも特に「診断」という部分に深く関わってきたお二人から、顧問・川口洋がどんなエピソードを引き出せるのか。どうぞお楽しみください!

イエラエセキュリティ顧問/株式会社川口設計 代表取締役

川口 洋

2002年 大手セキュリティ会社に就職。社内のインフラシステムの維持運用業務ののち、セキュリティ監視センターに配属

2013年~2016年 内閣サイバーセキュリティセンター(NISC)に出向。行政機関のセキュリティインシデントの対応、一般国民向け普及啓発活動などに従事

2018年 株式会社川口設計 設立。Hardening Projectの運営や講演活動など、安全なサイバー空間のため日夜奮闘中。

イエラエセキュリティ研究開発室 室長

柏崎 央士

SIerから2007年にセキュリティ業界へ。スマホアプリ、Webアプリケーション、ネットワークなどの脆弱性診断に従事。2018年5月にイエラエセキュリティ入社。現在は、脆弱性診断チームの技術支援、研究開発、脆弱性やツールの検証、診断サービスワークフローの改善など品質向上にまつわる活動をとおして社内で暗躍している。
自作キーボードはじめました(この記事はErgoDashで書いてません)。

フューチャー株式会社 シニアアーキテクト

神戸 康多

2004年、フューチャー株式会社新卒入社。R&D部門に所属し、様々なプロジェクトを技術的にサポートする傍ら産学連携の一環で東工大にてスケーラブルDBの研究にも参画。OSSの脆弱性スキャナ「Vuls」作成者。HITCON, Open Source Summit North Americaなどのカンファレンスにて発表、国内カンファレンス登壇多数、セキュリティ・キャンプ2017、2018講師。一万人以上のエンジニアが参加する情報収集用公開Slack「モヒカンSlack」の総裁を務める。週3回のサウナが趣味。

技術支援とOSS開発、専門家2人が選んだ脆弱性との向き合い方

川口洋(以下、川口):本日はお集まりいただきありがとうございます。まず最初に、お二人が普段従事しているお仕事について、それぞれ教えてもらえますか。

柏崎央士(以下、柏崎):イエラエセキュリティの柏崎央士です。2007年にセキュリティの世界に入って、長いこと脆弱性診断に関わってきました。ここ数年は脆弱性診断そのものではなく、診断にまつわる環境構築や自動化、品質管理などを行なっています。脆弱性診断の技術支援といった感じでしょうか。

川口:「脆弱性診断」といっても、いろんなジャンルがあると思いますが、イエラエではどの分野に注力しているんですか?

柏崎:イエラエに入社してからはWeb診断、ネットワーク診断、そしてスマホアプリ診断の技術支援をしています。

川口:自分で脆弱性診断をする、というよりも環境整備をメインに仕事しようと思ったモチベーションはどんなところにあるんでしょう。

柏崎:そうですね、私1人が「1」の働きをしたら、「1」の売上でしかないですが、もし私1人の働きで「50人が0.1ずつ」改善したら、そちらの方がパフォーマンス高いんじゃないか。そういう考え方で動いています。

川口:これまでの経験をフル活用できる立ち位置ですよね。全体のパフォーマンスを底上げするのって、大変なことだと思います。

柏崎:脆弱性診断に関わっている人の考え方やワークフローのことを知っていないと支援の仕事はできないので、そこは自分の強みだと思います。

川口:続いて神戸さん、普段のお仕事や、開発された脆弱性検知ソフト「Vuls」についてご紹介をお願いします。

神戸康多(以下、神戸):フューチャー株式会社の神戸康多です。OSSの脆弱性検知ツールである「Vuls」(https://github.com/future-architect/vuls)の開発と、クラウドサービス「FutureVuls」(https://vuls.biz/)のプロダクトマネージャーをしています。他にも、営業に行ったり、啓蒙活動もしたりと、Vulsに関するあらゆる仕事をしています。

ネパールとインドに行って現地の寺とガンジス川で修行して、悟りを開いて、その悟りの経験と以前社内システムを運用していた時の脆弱性管理のが大変だった経験がフュージョンして、脆弱性スキャナを作るぞいうことになりまして。3ヶ月間家にこもって、サウナにしか行かない、という勢いで作りました(キリッ)。

川口:「Vuls」の開発について話を聞き始めるとこれだけで1日かかってしまうので、読者の皆さまにはリンク先を読んでいただくということにしたいと思います(笑)。なぜ「Vuls」をオープンソースで開発をしようと思ったんですか?

神戸:やはり世界平和ですね。

川口:世界平和!

神戸:プログラマが世界平和の役に立とうと思ったら、オープンソースが一番手っ取り早いんです。柏崎さんと同じような考えで、自分が書いたコードで「0.1」幸せになる人が沢山出てくるようになれば、その総和が僕なりの世界平和なので。

川口:確かに。その神戸さんの行動力を会社が支援してくれているのも素晴らしいですね。「FutureVuls」は私も楽しく便利に使わせてもらっています。

運用者? OS? システムの脆弱性が無くならないのは誰のせい?

川口:これまでの人生、ずっと「脆弱性」と向き合ってきたお二人にお伺いしたいのですが、「脆弱性がどれくらい残っているのか」って、わかりにくいと思いませんか。世の中の多くの人は、「脆弱性ってそんなに残ってないんじゃないの?」って思っているような気がしてるんですが、そのあたり、どう思われますか。

柏崎:おそらく、今動いているサービスの100%に「脆弱性」は存在すると思います。でも「脆弱性」は、悪用可能なものか否かで分けられます。「Vuls」が見つけてくれるのはありとあらゆる全ての脆弱性ですが、イエラエが見つける脆弱性は「悪用できるもの」「顕在化している」内容に絞っています。

ですから、「Vuls」でチェックしたらたくさんの脆弱性が発見されたという場合であっても、イエラエでブラックボックステストをしてみたらOKだった、運用上は問題がない、という状態は多いと思います。他にも、アプリケーションの仕様上問題ない場合もあります。ある脆弱性があっても、他の機能で潰せている場合もある。その場合も「脆弱性は無い」とも言えます。

立ち位置、見方によって脆弱性が「有る」とも言えるし「無い」とも言えるのです。

神戸:個人的な話ですが、今、友人のWebサイトをWordPressで運用してるんです。CentOSなんですが、スキャンすると脆弱性が900とか出るんですね。パッケージをアップデートすれば脆弱性が無くなるわけでもないし、Red Hatが認識はしているけどパッチを出していない、出さないと決めている脆弱性もありますから、一言で「脆弱性」といっても内容は様々ですよね。

川口:自分もスキャンして出てくる脆弱性の数が多すぎて絶望しています(笑)。「脆弱性900とか出ても困るんです」という声は多いんじゃないでしょうか。どうしてくれるんですか神戸さん、僕のサーバーの脆弱性。どうやって片付けていきゃいいんですか?

神戸:・・・というような声は沢山頂きまして(笑)。でも、それは、「スキャン」「可視化」の次の段階なんですよね。まずはとにかく、一度、スキャンして可視化していかないと。だって、基本的に、パッケージのアップデートなんて、テストし直しになるし、ダルいじゃないですか。

川口:ダルい。

神戸:パッケージをアップデートする必要性を認識するうえで、可視化することはまず第一歩なんだと思います。

川口:でも、なんで脆弱性ってこんなに残ってるんですか? Red Hatのせいなんですか? CentOSのせいなんですか? それとも自分の運用のせいなんですか?(詰め寄りながら)

神戸:(苦笑)さきほど柏崎さんのお話にも出た通り、発見された脆弱性の中には問題ないものも多いです。攻撃される可能性や影響は低いだろうというので、Red Hatが「寸止め」してる脆弱性はたくさんあります。具体的には「will not fix」ステータスのものが、900件のうち、多分800件くらい。優先度が高くないというか、修正を取り込まなくても影響が無いと判断しているんじゃないでしょうか。

川口:つまり・・・Red Hatを買った方がいい、ってことですか。

神戸:そうですね。CentOSはソフトウェアアップデートがの流れてくるスピードが遅いですからね。でもRed Hatにお金払って、せっかく早くパッチを当てる権利を持っている人も、実はアップデートしてない人も多いんじゃないかと思います。それならCentOSでもいいんじゃないかとも言える(笑)。

川口:「なぜアップデートしないのか」という問題について伺いたいんですが、よくある理由は「テストし直してエラーが出たら面倒くさい」というケースですよね。でも、テストし直してエラーが出るケースって、実際にどれくらいあるんでしょうね。

柏崎:実際は「ほとんど出ない」と皆わかっていても、「テストはしないといけないよねぇ」「そうなるとテストする工数がネックだよねぇ」というケースが多いんじゃないでしょうかねぇ。

神戸:ライブラリ系だと、APIの互換性が崩れるとエラーになったりしますよね。アップデートしたら互換性が崩れたり、システムが止まっちゃったりという話も聞きます。

川口:そうなると前にも後ろにも進めなくなるから「やりたくない」というケースが多そうですね。

柏崎:脆弱性が沢山出ていても、お客様によっては「当社はアップデートしない方針です」とおっしゃるところもあり、頭を抱えたこともあります・・・。

神戸:テストが手動になっているのも問題ですよね。自動化されていればまた違うと思うんですが。日々ステージング環境でアップデート後の正常動作を担保できていれば「アップデートやろうかな」っていう気になるんでしょうけど。手動は大変ですよね。

「脆弱性を発見しても、そのままリリース」が起こってしまう理由

川口:ちょうどこの座談会は3月に行っているのですが、この時期、なぜ忙しいと分かっているのに、脆弱性診断が増えてしまうんでしょうね。

柏崎:予算消化の可能性も高いと思いますが、4月リリースのサービスや製品が多い、というのも理由のひとつな気がします。本来は、リリース前に一気に診断するんじゃなくて、細かくステップを踏んでやって欲しいですね。

神戸:ある程度完成した段階でチェックしたいという気持ちは分かりますけどね。

柏崎:完成直前で「基本思想に誤りがあった」というレベルの間違いがあると厳しいじゃないですか。

神戸:それって、ツールで見つけられないものなんですか?

柏崎:そこは設計を見てみないと分からないですね。例えば、パスワードリマインダー機能の実装ケース。

「パスワード忘れました」ってボタンをクリックすると、メールで平文のパスワードが送られてくるような機能がありますよね。これを直すのは、実はメチャクチャ大変なんですよ。パスワード管理の基本思想が変わってきてしまいます。これを最終工程で直せって言われてもなかなか厳しい。途中でチェックしながら軌道修正していくことが大切です。

川口:「シフトレフト」のような考え方もそうですが、早い段階で対応できるスケジュールが重要ということですね。脆弱性を発見するツールは既にあって、イエラエがしっかり調べてレポートをする仕組みもある。でも、それを受け取った側のお客さんは、どれくらい直しているんでしょう。

柏崎:お客様(会社)の、脆弱性に対する取り組み方によって随分状況は変わってきます。セキュリティ部門が上位に位置している会社だと「報告された脆弱性は直すまでサービスリリースしない」というケースもあります。直さないなら、直さない理由をきちんと説明する必要がある。そういう会社さんのサービスはだいぶ脆弱性が潰された状態でリリースされていきます。

一方でセキュリティ部門が強い権限を持っていないと、開発部門にあまり強く意見を言えないケースが多いように思います。直すのにもコストがかかるし、リリースの時期も迫っているし、できるだけ修正するコストを抑えたい。問題があっても、「こういう理由で、この脆弱性は問題がないから直さない」「間に合わないから直さない」という理由をつけて、何とか直さずにリリースに進もうという圧力がかかってしまうんです。

川口:せっかくお金をかけて診断しているんですから、直さないと意味がないと思っちゃうんですが、皆がそう考えるわけでもないんですよね。リリースギリギリのタイミングで診断していると、後戻りするスケジュールの余裕がないからそうなってしまうわけですね。

開発プロセスに診断を組み込み、早い段階で脆弱性を潰すのが重要

川口:「Vuls」は、自分でビルドしたアプリの診断も出来るんですか? チェック対象となっているのはオープンソース限定ですか?

神戸:セルフビルドしたアプリも、設定ファイルに定義すれば診断できます。OSのパッケージは定義無しで検知可能です。プログラム言語のライブラリ、ネットワーク製品なんかも検知対象ですね。

川口:「パッケージ製品の脆弱性」の話と、「自分たちが作ったアプリケーションの脆弱性」は、どう切り分けて診断していったらよいでしょうか。パッケージ製品の場合は世界中の人が脆弱性をチェックしていますが、自分たちの製品は誰も知らない。自分で調べないと脆弱性が何も分からない。ゼロデイ攻撃のような状態になってしまうのではないですか?

柏崎:Webアプリケーションの場合は、攻撃する方法はある程度決まっていて、OWASP(https://www.owasp.org/index.php/Japan)がまとめていたりします。

それを元にさまざまな診断ツールがリリースされています。実際に攻撃をして、その応答から脆弱性があるかを判断するようなWebアプリケーションスキャナを使うのは、一つの方法です。有名なところだとBurp Suite(https://portswigger.net/burp)があります。あとは、CIに組み込むことのできる診断ツールもあります。開発プロセスに脆弱性診断を組み込むんです。最近Brakeman(https://brakemanscanner.org/)というものを見つけました。

神戸:これは・・・サービスですか?

柏崎:これはGemです。Railsのプロジェクトに対して実行することで、「ここに脆弱性があるよ」と教えてくれるようです。

川口:開発のプロセスの中に脆弱性診断を組み込んでいくということですね。

柏崎:今はそれが必須だと思うんですよ。「Vuls」を使うのもそうですし、Jenkinsおじさんにお願いするのもそうですよね。開発が始まった瞬間からセキュリティを計画して、どれだけ早い段階でつぶしていけるか、ということを考えないと、最後にとんでもないことが起こります。

川口:リリース直前ではなくて、普段の開発の段階からチェックしよう、ということですね。

柏崎:さまざまなツールを組み合わせれば、単純なインジェクション系の脆弱性は早い段階で取り除くことができます。

川口:「FutureVuls」はそのあたりどうされてるんですか?

神戸:「FutureVuls」では脆弱性診断をやっていますね。コンポーネント系の脆弱性は「FutureVuls」で管理して、上のアプリケーションは定期的な脆弱性診断をやっています。あとはプルリクエスト単位でのレビューと、CIで日々のチェックができるようにしています。

「FutureVuls」を作っていて難しいと思っているのは、ネットワーク系ですね。ペネトレーションテストは料金が高いし、ソースコードも日々進化していくので、どのタイミングで脆弱性診断を実施するか、皆困っているんですよ。「FutureVuls」も脆弱性を埋め込まないようにして作っています。

柏崎:Webサービスの診断に関しては、マイルストーン単位でやってほしいんです。ある機能をリリースする時には、リリースまでにいくつかマイルストーンがあると思うんですが、そういうタイミングで診断をやっておくと最後に大きな問題になることが避けられる。例えば「これだけの機能を実装した」「いくつかのAPIを実装した」というタイミングですね。

ですから、1回のリリースに1回の診断ではなく、機能を分けて3回の診断を入れるというような計画を作って欲しいですね。そうすれば最後に爆発しない。

検出される大量の脆弱性に、優先順位をつける方法

川口:リリース頻度が多い場合はどうしたらいいですか。

柏崎:・・・大変、ですね。

川口:そうですよね(笑)。例えば「FutureVuls」はリリース頻度高そうですよね。

神戸:はい、「FutureVuls」は2週間に1回リリースしています。

柏崎:1つの考えとしては、諦めてその状況を受容することです。あまりにセキュリティに悲観的になってしまうとリリースできないことも出てきます。リリースできないことで深刻な被害が出るケースもある。それなら、脆弱性によるリスクをある程度受容してリリースし、リリース後にセキュリティを担保していこう、という選択肢もサービスの内容によってはアリなんですよ。

川口:確かに、自分も「FutureVuls」によって「助かってる」と感じるのは、毎日のようにチェックしてくれてることですね。ただ、見つかる脆弱性がものすごく多いので、ちまちまと地道にチェックしていることに終始してしまうわけなんですが・・・。

神戸:「Vuls」と「FutureVuls」の違いはなにかというと、「Vuls」は脆弱性を見つけるツールで、「FutureVuls」は脆弱性を管理するツールなんですね。ですから「Vuls」で脆弱性がすごく沢山出てきても、「この環境だと、この脆弱性は刺さりそう」という限られたものだけを見て、対応して頂ければいい。仕事だって、ToDoリストが多すぎたらやる気なくなっちゃうじゃないですか。

ちなみに「FutureVuls」(https://vuls.biz/) は期間限定でサーバ1台無料キャンペーン中ですから、試しに使ってみてください!(2019年4月現在) 攻撃コードが公開されているかどうかや、サーバの置かれている環境に応じて優先順位付けして、リスクが小さいと判断したものは非表示にしてしまうこともできます。人間が判断して対応するための「助け」にして欲しいですね。

柏崎:神戸さんがおっしゃるとおり、重要度をつけて対応していくべきなんですが、「この脆弱性はこのシステムにとって危険度が高いので優先度高いです」という判定を、どうやってすればいいのか・・・というところで皆さん困ってらっしゃるんですね。

川口:見つかった脆弱性のリストをもらっても、「じゃあ、自分にとって影響があるのはどれなんだろう。どうしたらいいの」というお客さんは多そうですよね。

柏崎:全部潰すつもりであれば上から対応すればいいんですが、予算も期間も限られているので現実的には難しいですよね。それぞれの脆弱性が、システムにどんな影響を与える可能性があるのか、というのをひとつひとつ見ていき、問題を起こしそうなものから手を付けていくというのが手順です。でも、困ったらひとまずは相談して欲しいですね。そうしたら、「こういう考え方がありますよ」とお伝えすることができるので。

神戸:「FutureVuls」の画面上では、脆弱性のスコアだけではなくて、ネットワークから攻撃可能なのかどうか、権限ナシで攻撃可能かといった指標を、グリッドで出しています。攻撃コードが公開されているかどうか、JPCERT/CCから警戒情報が出ているか、などで情報をフィルターして、あぶり出しをする方法を実装しています。他の視点もあれば、ぜひ教えてください。

川口:先日相談された事例ですが、脆弱性診断をした結果、重要度が低いと書いてあった脆弱性を放置していたところ、その低いもの複数の組み合わせによって大きな問題が発生したということがあったそうです。

単独では低リスクでも、組み合わせると大きな脆弱性が発生することもありますよね。他にも、低い脆弱性に管理不備がたまたま重なったりすることで高リスクになることもありますよね。受け取る側がどう潰していくか、リスクコントロールするかも大きな問題ですね。

柏崎:やはり1つ1つの脆弱性を評価する必要がありますよね。発見された各脆弱性に、ビジネスやシステムの実装に応じた優先度を付けていくことが重要だと思います。

川口:イエラエだと、ブラックボックスの診断が主ですね。

柏崎:ソースコード診断やファームウェアを見ることもありますが、基本的にはブラックボックスですね。

弊社では見える範囲でシステムの特徴を踏まえたリスクレベルを付けるようにしてはいるのですが、とはいえ、やはり見えない部分はわかりません。ですから、そこをご存じのお客様にも一緒に、本当の優先度を考えて頂いた方がいいのかなと思います。

上司がセキュリティに興味がない。そんなときこそ脆弱性とそのリスクを可視化せよ

川口:現場担当のエンジニア自身はセキュリティに危機意識を持っていても、上司がなかなか予算や活動にOKを出してくれないという話はよく聞きます。もしお二人だったら、どうやってその上司の意識を変えると思いますか?

神戸:脆弱性スキャナを入れないと脆弱性は可視化されないし、ソフトウェアアップデートしたところで売上が上がるわけでもないし、場合によってはシステムが止まってしまうこともある。怒られたくないから「やらなくてもいいじゃないか」という結論にもなりますよね。

自分だったら「Vuls」を使って、脆弱性を可視化したものを見せます。運用中のシステムをスキャンして、その結果を上司に見せる。それでもダメだったら・・・スキャン結果の中から攻撃しやすい脆弱性を選んで、テスト環境などを使って、目の前でやってみせたらいいんじゃないでしょうか。「こうなっているんで、こういう風に攻撃できますよ。そのうちやられますよ、記者会見ですよ?」といいながら、適当なPoCを試すとか。

柏崎:危険な提案をしますね(笑)。

川口:やられる!という危機意識が一気に沸いてきそうですね(笑)。

神戸:「実際に攻撃される」というイメージがついていないから、危機感を感じていないんじゃないか、と思うんですね。「こんなに簡単に攻撃できるんだ!」ということが実感できればいいんじゃないでしょうか。

川口:確かに、デモというのはインパクトがありそうです。「この脆弱性を攻撃するとこんな状況になります」とデモしてくれるボタンを「Vuls」に実装してみてはどうでしょう(笑)。

神戸:なるほど!

柏崎:何の対策をやるにしても、まずは予算を勝ち取らなきゃいけないのが、大きなハードルですよね。

川口:堅い業界だと横並びを意識したりもしますので、他社の事例を上司に紹介したりできると、効果があるということもありそうです。

神戸:開発者も運用者もセキュリティに詳しい人ばかりじゃないですからね。むしろ少数派。

柏崎:まだ十分とは言えません。

川口:脆弱性診断をするのが最近はようやく普通になりつつありますが、その後のフォローアップに課題があるなと思っています。

柏崎:そうですね。いまようやく「脆弱性を認知しよう」というのが定着したフェーズだと思うんですよね。この後は「脆弱性の管理」が定着する段階、次は「脆弱性の対策を自動化する」段階。これが完全に定着すると、最後は「脆弱性の存在を忘れてしまう」というステージに至ります。脆弱性を忘れる段階になって初めて、脆弱性がなくなる世界観だと思います。これが理想ですね。

川口:自動化で脆弱性対策することは大事ですね。

柏崎:自動化での対策が進むと、単純な脆弱性診断サービスは存在意義を失っていくと思いますが、そういう状態を目指して仕事をしていきたいと思っています。

「枯れた技術」「ライブラリ」を過信するとケガをする

柏崎:とはいえ、ツールや自動化で発見できる脆弱性には限界がありますから、おそらく人間の診断自体はずっと必要とされ続けるでしょう。例えば今、Railsで開発していたら、XSSとかSQLインジェクションって、絶対に作り込むことはないと思うじゃないですか。・・・でも、これが、わりと、出るんですよ。

川口:・・・おお。

柏崎:Railsでは普通のコードを書いていればXSSが出るようなものではないのですが、複雑な仕様を満たすために、特別なコードを書くことがあります。先日公開された脆弱性(https://ierae.co.jp/news/vulnerability-report_20190313/)は事情が複雑でした。まず、使用しているライブラリに脆弱性がありました。それを解決するために追加したコードが仕様上の問題を引き起こし、それを直したら今度は別の脆弱性が発現。これも、直したつもりになっていたものの、十分ではなかった・・・という状況です。

川口:かなり複雑な状況ですね。

柏崎:こうやって説明していると大変複雑なんですが、攻撃コード自体は難しくないんです。ただ、対策する側は大変です。要求仕様には対応しなければなりませんから。

神戸:ライブラリ自体を直すことはできなかったんですか。

柏崎:ライブラリは開発元が別のところで、どうやら直す気が無いようです。

川口:脆弱性があっても直す気が無いサプライヤーがいると困りますね。せっかく脆弱性の発見ができても、提供元が対応してくれなければ、使う側が複雑な対応をせざるを得ないですからね。それでもたまたま認知されたものはラッキーで、認知されていないものは沢山ありそうです。

柏崎:「枯れてる技術は大丈夫」という考えも、場合によっては危険です。ただ単に直せなくなっていたり、直す気がもう無かったりするケースもあることを認識しておかないといけません。

脆弱性の可視化とアップデートの間に横たわる「溝」を超えていくために

川口:普段使っているシステムの脆弱性診断についても定期的に実施して適宜修正して欲しいですが、なかなかチェックしようという動きにならないことは多いですよね。堅い業界でも、大きいシステムは業者さんがチェックしていても、細かいところでセキュリティの甘さが見えて不安になることがあります。

他にも例えば、絶対に侵入・改竄されては困るような機関のWordPressログイン画面が、ポンとインターネットのリーチャブルな場所に置いてあったりする。そういうのを見てしまうと、他にも脆弱性があるのでは、と気になってしまいますよね。

神戸:WordPressはぜひ「Vuls」でチェックしてほしいですね。いま実装中の機能でコア、プラグイン、テーマのリストとWordPress専用の脆弱性データベースを参照したりして、ホワイトボックス的なチェックができるように改造しています。

川口:WordPressユーザーは多いですから、診断する人が多くなればなるほどセキュアになりますよね。最近は自動アップデート機能が付いているので勝手にアップデートされてることも多いですが、アップデートするとレイアウトが崩れるからと運用側でアップデート禁止している例も聞きます。

脆弱性については、「可視化してアップデートする人」「可視化してもアップデートできない人」「可視化しない人」に分かれる。可視化すらしてない人はもう救えない気がしていて、まずは可視化している人から救っていけないかなと思っているんですよね。

神戸:アップデートしやすい仕組みを作ることも重要です。

開発部隊ってスナップショットでモノを作って、その後の運用のことを考えていないことがまだまだ多いんですよ。運用者目線でアップデートがしやすいシステムを作るべきなんですが、それができていないところが多い。自動テストやアップデート、切り戻しがしやすい環境でないと脆弱性が見つかっても対応できないですから。

川口:作りっぱなしで終わりになってしまうというのは、大きな課題ですよね。脆弱性があると言われても直す予算が無かったり。でも、そういう状況は昔から変わらない中で、「可視化」については、実施しやすい環境が整ってきたように思っています。次のフェーズへ進んでいきたいですね。

脆弱性チェックを自動化して、“良い感じ”で“楽しんで”欲しい

川口:それでは最後に、システムの担当をしている方々へむけて、脆弱性とどう向き合っていくべきか、お二人からメッセージをいただけますか。

神戸:弊社はツールを提供している会社なので、様々なツールを組み合わせて自動化して、楽をしながら“良い感じで”脆弱性と向き合ってほしいですね。

川口:楽なのは大事ですよね。大変だったら向き合えない。まずは脆弱性を管理するフェーズに入ってもらうことからですね。

柏崎:神戸さんの仰るとおり、できるだけ脆弱性チェックの工程を自動化して、お茶を飲む時間を作って(笑)、脆弱性に関わることを楽しんでほしいです。

検出された脆弱性のリスクは、その原理は、攻撃方法は、と理解を深めていくことは楽しいことですし、システム運用にも役立ちます。

川口:分からなかったら診断している会社に相談すればいいですしね。神戸さん、柏崎さん、本日は長い時間ありがとうございました。

セキュリティ診断ならお任せください

Webサービスやアプリにおけるセキュリティ上の問題点を解消し、収益の最大化を実現する相談役としてぜひお気軽にご連絡ください。
国内トップクラスのセキュリティエンジニアが診断を行います。

ホワイトハッカー

セキュリティ診断
ご相談はこちら