で、どうやったら SecuriST に合格できるか教えてもらえませんか上野さん ～ 非エンジニア文系ライター受験記 [後編]

　本記事は、SecuriST「認定ネットワーク脆弱性診断士」講座受講、認定資格受験をしたイチ非エンジニア、ド文系ライターによる「SecuriST 受験記」だ。受講決定から受験に至るまでをタイムラインでレポートした前編では、反省も踏まえ「こうしたら良かった」も書かせていただいた。

　続く後編となる本記事では、認定試験受験結果を恥も外聞もなく大公開！　更に、脆弱性診断の第一人者であり、この SecuriST を全面的に監修している上野 宣 氏（トライコーダ）をお迎えし、受講・受験経験を踏まえた質問をぶつけてみた。これから受験される皆様は、これらを参考にして、共に SecuriST へ挑戦して頂ければと、切に願っている。

●試験結果は「5 項目」での判定。蓋を開けてみれば……納得の結果。

── 上野さんとは、Hardening Project を始めとしたセキュリティ関連イベントにて同席させて頂いてきましたが、インタビューの機会はなかなかありませんでした。改めまして、本日はよろしくお願いします。まずは、SecuriST「認定ネットワーク脆弱性診断士」認定試験の結果をお伝えしたいと思います。……えー、不合格でした！

上野：あ～（笑）。

── 試験結果は 5 項目に分かれた評価となっていて、それぞれの点数の分布が興味深かったので公開したいと思います。

　SecuriST 認定ネットワーク脆弱性診断士
　1. 基礎知識（技術）　33.3％
　2. 基礎知識（脆弱性）　66.6％
　3. 基礎知識（診断業務）　33.3％
　4. レポーティング・リスク算出　0.0％
　5. 関係法令　100.0％
　総合スコア　36.6％（不合格）

── 脆弱性診断業務の「実務」に関わる項目の点数が悪いという、非常に腑に落ちる内容でした。

上野：まぁ、かのうさんの場合、そもそも、業務上でレポートとかに接する機会がないよね。

── ちなみに講座の中では、資格試験の話が殆どなかったんです。そこで私が空気を読まずに「どのような勉強をしたらいいですか」と聞いたんです。

上野：それは、とてもよく、質問されます（笑）。

── 講師の方からは「自分は設問を作っている側なので、何も言うことが出来ない」と言われまして……ただ、「情報安全確保支援士の過去問が近い」とのことだったので、参考程度に 1 回分だけ解いてから試験に向かいました。

上野：基本的には、2 日間の講座でやった内容が理解できていれば、受かるハズなんです。まぁなかなか、内容的に大変だと思うんですが。情報安全確保支援士は、広く満遍無くセキュリティを学ぶことの出来る資格で、SecuriST は個別の技術について問う試験内容かな、と思いますね。

── 情報安全確保支援士の過去問をやってみて、この資格も自分は勉強すべき内容だったんだなと反省しました。……ただ、情報安全確保支援士をレコメンドされたことで、「えっ、じゃあ、SecuriST の資格としての価値とは？」と、ちょっと混乱してしまったところがあったんです。上野さんは、SecuriST の「資格」というところについて、どのようなお考えをお持ちでしょうか。

上野：何かしら専門の“資格”について私が思っているのは、それを持っていることで「共通言語」が分かるようになる、ということですね。例えば、SecuriST 認定脆弱性診断士の資格をお持ちの方がいたとしたら、お話をする時に最初からディテールの説明をする事が出来る、ということです。あとは、この資格をお持ちの方が脆弱性診断テストをした、ということであれば、ある程度以上のクオリティがある、信頼がおける、という判断が出来ます。

　……とか言ってますが、僕、資格試験受けるの、めちゃくちゃ、大嫌いなんですよね（笑）。

── 上野さんと言えば、「鍵師」という物理的なセキュリティ資格しか持っていない、というのが長いこと業界で有名なネタでしたが、最近ようやくセキュリティ関連の資格を取得されていましたね。

上野：それが、先ほど話題に出た情報安全確保支援士です。私、この資格を作る時からカリキュラム検討委員に入っていて、公式の集合研修の講師もやってるんですが、突然、資格を持っていないとこの業務をしてはいけないって法律になって……「え、カリキュラムつくってんのに？　なんで？」ってなりましたよね……。ちゃんと勉強して、取りましたけど（苦笑）。

●品質を重要視する「日本発の脆弱性診断方式」を、世界に広めていきたい

── SecuriST の講座と認定試験をつくった経緯や意図について、改めてお話し頂けますか。

　「Web アプリケーション脆弱性診断士」「ネットワーク脆弱性診断士」という講座は、私が代表を務める株式会社トライコーダでやっていたものなんです。これを GSX と組んで、資格にしようと動き始めたのがきっかけです。

　実は、脆弱性診断、特に Web アプリケーションの脆弱性診断って、海外ではそんなに重要視されていないんです。私が日本チャプターの代表をやっている OWASP（The Open Worldwide Application Security Project）のテスティングガイドでも、脆弱性テストの手法は公開されていますが、現場では基本的に自動ツールでスキャンすることを中心とした診断をしてるんです。あとは、ちょっと極端な言い方をすると「完成したモノを走らせて、ぶつけてみようぜ」というテストをすることが多い。これがいわゆるペネトレーションテストと言われるもので、日本語では「貫通テスト」と訳します。

　一方で、日本でやっている「脆弱性診断」は、ひとつひとつのパラメータに対して可能性のある脆弱性を全てチェックしようといった、網羅的なチェックのことを指します。このやり方は、クルマ業界等のものづくり分野のやり方に近いんですね。例えば自動車メーカーさんが出荷前に「ネジの強度は OK か」「ネジはちゃんと締まっているか」「フレームの設計強度は OK か」など、部分ごとに細かいチェックを行っていると思うんです。

　日本は元々、ものづくりが非常に盛んな国ですし、世界的に見ても日本のものづくりの品質というのは高い評価を得て信用を得てきたという歴史があります。この、日本式の脆弱性診断、テスト方式は世界的に余りなく、ほとんど知られていないと言ってもいい状態なんですが、ソフトウェアの品質に非常に影響してくるものです。

　だから、例えばトヨタさんの「カンバン方式」が「ＫＡＮＢＡＮ」とアルファベットで世界で使われるように、日本式の脆弱性テスト方式を「ＳＨＩＮＤＡＮ」というような名前で世界中で使ってもらいたい、そういうことが出来ていければいいなぁ、というのはありましたね。現状の SecuriST は、まだ国内のみでの展開に留まっていますが、今後はアジアを中心に広く展開していきたい、ということも話しているんです。

── そんな熱い話が裏にあったとは！　アプリケーションソフトウェア品質の標準化が日本発で実現したら、かっこいいですね！

●ツールの有無に左右されないスキルは、原理原則を知ることで身につく

── ここからは私が受講した、SecuriST「ネットワーク脆弱性診断士」オフィシャル講座の内容についてお伺いしていきたいと思います。講座の冒頭では、結構長い時間を使って「 OSINT（オシント）」つまり、一般に公開されている情報を集めて分析する手法について学びます。Kali Linux みたいな専門ツールを用いなくても、誰もが見られる公開情報からかなりの深度でいろいろ分かってしまうものなんですね。

上野：便利ツールやサイトは講座でも紹介していますが、なるべく後の方で紹介するようにしていますし、基本的に「このツールが無いと出来ない」ということは避けています。そのツールが無くなったら出来なくなっちゃったり、バージョンが変わったら出来ることが変わってしまったりする可能性もありますからね。まずは基本原理を知ってもらう。何故そうなるのか理解してもらう。そうでないと、ツールの出してきた結果も、分からないんですよね。

　例えば Nmap というポートスキャナーを使ったと思いますが、ポートが空いてる、もしかしたら空いてる、空いてない、フィルターはこうなってる……といったスキャンの「結果」しか出して来ないんですよね。ツールが何故そう判断したのかは、原理を知っていないと読み解けないんです。

　UDP スキャンについても、「ポートが開いているか開いていないか、どちらとも捉えられるけれども、他のポートがこの状況であれば多分これは開いている」というような場合があることを聞いたと思います。こういったジャッジというのは、「一般的な管理者の 8 割位は、こう設定するだろうな」という想像が出来る人間だからこそ、出来るものなんですよね。

──　whois 等の、業務上日常的に見ているサイトや、存在さえ知っていれば普通に見られるサイトで、まさかこんなことまで……！　という情報が収集されているのを目の当たりにして、個人的には、恐ろしさすら感じてしまいました。

上野：そういえば僕、少し前に、近所でやっていたハッキング勉強会に行ったんです。最近はいつも環境を構築する側だったんで、ハッキング側で勉強会に参加するのは久しぶりでした。でも、事前アナウンスをちゃんと見てなくて CTF があると知らなくて……何も入ってない MacBook Air を持っていっただけだったんです。

　そんなわけで何のツールも無かったんですが、結構いっぱいハッキングしまして（笑）。周囲の人たちはみんな、Kali Linux とか入れてましたけどね。ツールは在れば便利なんですけれど、無くても出来るということですね。原理原則を知ることで診断精度が上がっていくと思いますし、エンジニア自身の信頼性に繋がっていくと思うんです。

●「運用に付随する脆弱性」対策には、企業内での網羅的な調査が不可欠

──　こういった OSINT 部分について、企業内の危機意識みたいなものは、上野さんの危機意識とどのくらい差があると感じられていますか。

上野：まぁ、今は全くやらないというか、問題意識そのものが無いんじゃないかな。

──　ゼロ、ですか（笑）。

上野：そう、ゼロ（笑）。外部業者に頼む時、そもそも OSINT しないと思うんですよ。……あ、そもそも OSINT というのは、脆弱性診断を頼んだ会社は“してくれない”ところなんです。

── えっ、OSINT は、脆弱性診断では、やらないんですか？

上野：そう、しないんですよ。脆弱性診断をしている会社に頼むのは、IP アドレスベースでの依頼なんですよね。普通、クライアント企業がわざわざお金を出して脆弱性診断してもらいたい対象物って、だいたいはリリースしたばかりのサービスが多いんです。つまり公開するサービスに付随する IP アドレスしかチェックしない。すると、セットアップしたばっかりなのでパッチは全部当たっているし、設定もちゃんとしてるから、あまり脆弱なところが見つからないということが多かったりするんですね。そうすると、そこって結局、攻撃者も狙わないところになってくる（笑）。

　ただ、脆弱性診断の本来の目的は何か、というところに立ち返ってみると、「自分の会社の事業を守りたい」「顧客情報を守りたい」「会社自体を守りたい」というところだと思うんですね。そういう時に、一つのある IP アドレスだけを診断したからといって、それで安全であるかどうかというのは、分かりませんよね。攻撃者がどこから入ってくるのか、どこを弱点と見てくるのかという視点で、自分たちのリスクを洗い出すということがどうしても必要になってくるんです。それを身に付けるための技術が、OSINT、フットプリンティングです。

── 脆弱性診断には OSINT が入ってない、と今知ってビックリしているんですが、何故そこを講義で重要視してらっしゃるのでしょうか。

上野：それは、私自身が「ペネトレーションテスト」をやっているからこそ、ということはあると思います。ペネトレーションテストでは、「サービスの顧客情報を 2 週間で盗めたらゴール」といったシナリオを、お客さんとの間で契約します。我々はあらゆる手を使ってそのゴールを達成するわけですが、最初にやるのが「どこから侵入できるのか」という調査です。

　決められた期間内に目的を達成しなければいけないので、弱そうな経路を探すのは当然ですよね。堅牢なサーバに侵入しようとしても出来ない可能性が高いので、侵入し易そうな場所、弱点ぽい場所を探すことに時間をかけるわけです。

　運用から 1 年経ってログインアカウントが運用しやすいように変更されてしまったサーバ、IoT 機器のルータを経由したり、会社の VPN 経由で開発者の PC に侵入したり……。社内デスクトップ PC からなら、誰でも会社のサーバにアクセスできてしまったり、いろんな経路が考えられます。つまり、ターゲットとなる端末は社外に公開されている端末、サーバだけではなくて、VPN などのネットワーク機器、社内システム、社内デスクトップパソコンなども対象になるわけです。

　ペネトレーションテストでは「運用の脆弱性」ということをよく言うんです。だいたい構築したてホヤホヤは「本当に閉域網」だったものが、1 年、2 年と経っていくと、境界が曖昧になって「実は閉域網じゃなかった」となってしまったりしますね。メンテナンスの都合でパスワードが簡単なものに変わっていたり、設定ミスがあったり、パッチが当たっていなかったり、ということが出てくる。これは全て、運用に付随する脆弱性ですよね。

　でもこの辺りは通常見逃されがちというか、脆弱性診断をやろうとも思わない。VPN 端末や社内システムなんか、ほとんどテストされないんです。そういうのも含めてリスクを洗い出すということをして欲しい、という思いを込めて、フットプリンティングを講座に入れています。脆弱性診断から「運用自体そのものの脆弱性」は見つかりづらいんですが、これら「運用に付随する脆弱性を見つけること」は可能なんです。

●マイカー整備のような診断

── 非エンジニアであっても、サーバやドメインを契約したり、アカウントの設定など周辺業務に関わる人は沢山いると思います。企業規模にもよりますが、エンジニアよりも総務部の人の方が、これらの業務をされている場合もあるかもしれません。そういう方々には、OSINT の部分だけでも、受講すべきじゃないかと感じてしまいました。

上野：最近、私の子供が車の教習所に通っていて、久しぶりに教本をパラパラと見ていたんです。それで思い出したんですが、車は、日々の点検というのは、本当は自分で毎日やらなきゃいけないんですよね。乗る前に車の前後を見て、ボンネット開けて、とか、書いてあるんですよ。自分でやってないなー、って思って（笑）。

　でも、実はそれは、やるという前提なんですよね。これが、今言っている脆弱性診断に近いと思うんです。年に 1 度、ディーラーやプロの目で定期点検してもらうのが、外部の診断業者への依頼。そういう違いがあると思います。ですから、SecuriST の資格を取った人が多くなったから脆弱性診断事業者が必要なくなる、というようなことは無くて、両方必要だなと思いますね。

── その比喩は、分かりやすいですね。

　まぁ IT 業界も自動車も、皆ユーザーレベルでは自己点検やってない、ってことなんですけどね（笑）。ただ、車は 2 年ごとに定期的に必ず点検するように法律で決められていますからね。でも、Web サイトやサービスには点検を義務づけるような法律がありませんから、無法地帯ということですね。

　最近は国が色々、ガイドラインとかをつくっていて、私も IPA が出している EC サイトの運用・構築のガイドラインの委員会に携わったりしています。ただ、ガイドラインまでしか出せないんですよね。PCI DSS など業界で頑張っているものはありますが。

●何のために、誰がために、脆弱性診断は在るのか

── 脆弱性診断で定められている評価軸で見えてくる“脆弱性”と、本質的な意味でのリスクが別である、ということはよくあると思うんですが、その辺りは脆弱性診断を学ぶ上で、どう考えたら良いのでしょうか。

上野：そうですね、脆弱性診断って、あくまで調査でしかない、何かをジャッジするための材料でしかないんですよね。リスクというのは、そのサーバにどういう脆弱性があるのか、どういう資産があるのかによって、それぞれが判断するべきことですよね。我々は「リスクをゼロに出来る」と言っているわけでは無くて、高いリスクを抑えたり、リスクはあるけれども悪用され辛くするだとか、リスクマネジメントということをしようとしている。

　例えば「このサーバには脆弱性が 10 個あります」という診断レポートを貰っときに、レポートを読んだ多くの人は「全部脆弱性を無くさないとマズイんじゃないか」と考えてしまうんですね。危険度の高いやつ、中くらい、低いものがいくつというように書いてあるんですけどね。どうしても今すぐサーバ止めてでも対応しなきゃいけないのか、定期メンテナンスの一週間後でいいのか、1 ヶ月後でいいのか。ひとまずそのまま置いておいても大丈夫、という脆弱性もあります。

　他にも、国家機密を運用しているサーバと、かのうさんの会社のホームページだと、それぞれのセキュリティにかける投資というのは自然と違ってきますよね。「中位のリスク」が出てきた時に、かのうさんの会社のホームページなら「このくらいのリスクヘッジでいいかー」という判断があったとして、国家機密を扱っているサーバも同じでいいわけではないですよね。

　同じツールを回して同じ結果が出てきても、みなさんそれぞれ、置かれている状況も違いますし、ネットワーク構成も違う、それぞれ自分で考えるしかないんです。

　講座の中で「トリアージ」という言葉が出てきたかと思いますが、リスクのトリアージの基準というものは、世界的にも明確にあるものではないんですよ。今ちょうど OWASP の脆弱性診断士プロジェクトでは、トリアージのことをやろうとしています。普段業務をしている方に何を把握しておいてもらうといいのか、脆弱性をどう扱うのがいいのか、今後はそういうガイドラインを出していければいいなと思っています。

●で、どうやったら ScuriST に合格できるの？

── えー、ここまで話を聞いて来まして、SecuriST と情報安全確保支援士、この 2 つの資格は絶対合格しないとヤベーな、という気持ちになっております（笑）。では最後に、真面目な質問として、どうやったら SecuriST に合格出来るか、教えてもらえませんか。

上野：そうだなぁ、やっぱりこの資格は実務者向けの資格というところがあるので、一度、実務をやってみるべきです。講座の最後に「今後の自己トレーニングについて」という項目が 1 ページ入っていて、バグバウンティ・プログラム等について紹介があったと思うんですね。演習環境を自分で用意して、脆弱性を見つけて、実際にレポーティングして、修正してもらうというところまでやってみて欲しいですね。そうしたら合格しますよ（笑）。

── なるほど！？　実務環境を得るのが、1 番、大変そうですが……。

上野：あと、私が SecuriST 認定試験の問題監修の際に意識しているのは、なるべく暗記問題にしない、ツールの利用方法を問うモノにはしない、ということです。脆弱性診断の必要性そのものだとか、何を求められているのか理解出来ているか、またレポートを見た時に「今、こういう脆弱性がある」と判断出来るか、ということを問うようにしています。

SecuriST の資格は「脆弱性診断ツールが使える人間ですよ」ということを証明しているのではなく、何故脆弱性診断が必要なのかという原理原則や、内容を本当に理解しているかどうか、そのようなことを証明するための資格になっている、ということですね。そう思って、取り組んでみてください。

── が、頑張ります……。本日はとても興味深いお話を、沢山伺うことが出来ました。また資格試験合格の際には報告させてください！