はじめに

私が脆弱性診断を学んできた流れをまとめておきます。
これから学ぶ方の参考にでもなれば幸いです。

全体を通した学び方

私は技術単体より歴史やエピソードが好きなので、「どういう経緯で今に至るか？」を考えるようにしてきました。

脆弱性診断の仕事をする前

脆弱性診断と言っても、お仕事なので技術だけやるわけじゃないです。
診断の仕事をする前に、仕事関連では以下のことを学びました。

ビジネスコミュニケーション
資料作成
効率化

1.ビジネスコミュニケーション
エンドのお客さん、同僚、出向先の方とのやりとりです。どの仕事でも使います。
対面での会話やメールなどの文章も含みます。

最初はヘラヘラして媚びへつうのを試しました。
それなりに穏便に過ごせましたが、メンタルにきたので、この方法はだめなんだなと学びました。

その後は「この人はどんな気持ちなんだろう？」や「何を求めてるんだろう？」を考えるようにして立ち回るようにしました。

人によって正解が異なるので疲れます。

現状でも正解がわかっているわけでは無いですが、無難なテンプレはある程度わかったのでそれをいくつか使いまわしています。

PDCAを回すような感じで少しずつ学んでいきました。
ある程度形にするまでは4年くらいかかった気がします。

2.資料作成
Excelを使用した資料作成です。こちらもどの仕事でも使います。

社会人1～2年目でめっちゃ添削されたので、普通程度のものは作れるようになりました。

このスキルは助かってますが、添削されてる時はつまらなかったので、人に教育するときになんと言っていいかわからないというデメリットがあります。

こちらも結局は「相手は何を求めてるんだろう？」を考えると大きく外さないということを2年経ったくらいで感じました。

3.効率化
方法問わず効率化です。
こちらはあると便利でした。

性格上毎日単調な作業を繰り返すのが苦手なので、必死ぶっこいてなんとかならないかを調べました。

いくつか効率化に成功しましたが、だいたいが似た方法でできました。

意外と汎用的に効率化はできるということを学びました。

一方、技術面では以下を学びました。

インフラ運用
企業の情シスの立ち回り
企業のセキュリティ教育
開発のフロー

1.インフラ運用
サーバやクライアントの管理です。

セキュリティを学んでいると、問題点を報告する側になると思いますが、これは問題点を報告される側です。
なんだかんだ4～5年くらいやってました。

社内システムとかあるとパッチ当てるのも大変だなということを学びました。

私はこの仕事から始まってセキュリティ系の仕事をしているので、報告される側の感覚がないとどうなるのかというのがわかりませんが、たぶん大切なんだろうと思います。

2.企業の情シスの立ち回り
こちらも「インフラ運用」と同様です。

組織内部の管理模様が推測できるようになります。

3.企業のセキュリティ教育
IT関連ではない会社はセキュリティ教育がなかなか浸透しないことを学びました。

単純に教育に使う時間が無いんですよね。

4.開発のフロー
ウォーターフォールでの開発をやったので、だいたいフローがわかるようになりました。

レスの内容や速さ、要望でどれくらい忙しいのか予想できるようになりました。

この項目を書いていた感想ですが、全体を通して、脆弱性診断をやるために学んできたわけじゃないのがほとんどです。

学生から脆弱性診断の仕事を目指したりするとすべてすっとばすことになるんでしょうか。

組織や会社としての立ち回りって、机上の独学で学ぶの難しそうですよね。

文字が多くなってきたので、飼っている犬の写真はります。

脆弱性診断の仕事を始めてから

ルールについて
実際の技術について

ルールについて

自分なりのルールを決めて学んできました。
私が使ってきたルールは以下になります。

人に説明することを想定する
由来や歴史を楽しむ
身の丈にあったレベルを選択する

1.人に説明することを想定する
感情としての「理解した」は全く参考にならないので、人に説明できるレベルを目指しました。

実際に人に教えたり、ブログに書いたりをやりました。
個人手順書を作るのもアリです。

2.由来や歴史を楽しむ
これは私の性格によるところなのですが、技術が好きではなく、由来や歴史のほうが好きです。

例として出すと、XSSの対策回避方法とかもあまり興味が出ないタチです。

ですが、「XSSの対策機能はどう実装されたのか？」や「なぜその機能が実装されたのか？」、「現状はどうで、これからどうなっていくのか？」を考えるのは好きです。

こう考えている過程に回避方法も含まれている、みたいな感じで学んできました。

当初はこのような考え方ではなく、単純に技術を調べたり、回避方法をメモしたり、情報収集したりしていました。

ある時、単純に調べているだけでは知識が定着していないことに気づきました。
定着したと感じたものは、感情に任せて「なぜこの機能はあるのだろう？」と調べたものだけでした。

この考え方にするまで1.5年くらいかかりました。

3.身の丈にあったレベルを選択する
ゲームで例えると、レベル1の状態でレベル30のドラゴンを倒せるよう努力したり、レベル30なのにレベル1のスライムをひたすら倒すようなものです。

つまらんですよね。

SNSを見るとここらへんの感覚がブレるので、最近は見ていないです。

実際の技術について

私個人のWeb脆弱性診断勉強おすすめフローを書いておきます。

なぜ学びたいか理由を定義する
Webのクライアントとサーバの概念を学ぶ
法律関連を学ぶ
脆弱性の一覧などをざっくり見て学びたい脆弱性を決める
やられサイトを使用して脆弱性を再現する
自分でやられサイトをプログラミングして「なぜ脆弱なのか？」を考える
飽きたらバグハントでもする
3～7を繰り返す

1.なぜ学びたいか理由を定義する
学びたい理由がないと飽きます。

私個人の感想ですが、金や名誉と言った結果を理由にしても飽きが来ました。
意外と定義するのは難しいです。

2.Webのクライアントとサーバの概念を学ぶ
ブラウザってなんなのか、ボタン押したらどんな処理がされているのかざっくりでもいいかなと思います。

このあたりがわかっていないと、流石にWeb脆弱性診断は始められないかなという気がします。

実際にWebアプリを作ると手っ取り早い気がします。
人に聞いちゃうのもアリです。

3.法律関連を学ぶ
個人情報や公開されているものを取り扱うので、基本的な法律を学びます。
資格の勉強するのが手っ取り早いです。

この項目がクリアできないからと言って技術ができないのはつまらないので、最低限やってはいけないことを学んで次にいきます。

この項目から繰り返す項目に含まれるのは、机上で法律をひたすらやっていてもどうせわからないからです。
少しずつやっていきます。
4.脆弱性の一覧などをざっくり見て学びたい脆弱性を決める
OWASPとか本とか買ってざっくりみます。

本をひたすら読んだって脆弱性については理解できないので、ざっくりでいいと思います。

5.やられサイトを使用して脆弱性を再現する
やられサイトを使用して、実際に脆弱性を再現してみます。

この時に、4で見たサイトや本をもう一回見て、脆弱性がどういうものなのかの内容を確認してみると良いです。

6.自分でやられサイトをプログラミングして「なぜ脆弱なのか？」を考える
自分自身で作り込んで、なぜ脆弱なのか？を考えます。

何人かに教える機会がありましたが、攻撃方法だけを学んでいても限界が来ます。

「なぜ脆弱性になるのか？」、「どう直せばいいか？」、「どんなリスクがあるか？」を考えると定着しやすいです。

非常に難しい項目なので、人に聞きながらやるのが良いと思います。
7.飽きたらバグハントでもする
6は難しいし、ずっとやっていると飽きます。
実践をしましょう。

脆弱性診断を学ぶのであればバグハントがおすすめです。

hackeroneとかなんでもいいので使いましょう。

英語ですが、セキュリティ関連の資料はだいたい英語です。

この時、初心者であるなら成果をだすことは考えないほうが良いです。
メンタルにきます。

実際のサイトに攻撃をするわけなので、厳密なルールもあります。
そのあたりも含めて実践的なので、良い練習になります。

個人的には、CTFは脆弱性診断の練習にはならないかなと考えています。

理由としては、CTFは脆弱性があることが確定しているからです。
実際のサイトはあるかどうかわかりませんからね。
技術力向上には適していると思います。

8.3～7を繰り返す
飽きたら次の項目をやる、でどんどん回していきます。

飽きてるのにひたすら続けても辛いだけで意味無いです。

使えるサイト

portswigger Web Security Academy

pentesterlab

終わりに

人に教える機会が多くなってきたので、考えていることをまとめました。
頭の中に残って、悶々とするのは嫌ですからね。

長々と書きましたが、一番良いのは「今気になっていることを何も気にせず調べまくる」な気がするんですよね。

脆弱性診断を学んできた流れをまとめてみた