新卒3年目の私が、新しく脆弱性診断のOJTプログラムを作った話

さかのぼること4月。我が診断チームに3名の新メンバーが加わりました。

従来のOJTは、他の先輩メンバーと一緒に実案件を診断しながら覚えてもらう方法で実施していましたが、この方法では診断業務を一人立ちして遂行できるようになるまで時間を要するという課題がありました。

筆者である私は、このOJTプログラムを改善できないかと思っていました。そこで未経験ながらOJTを担当することに手を挙げ、新しいOJTプログラムを作って実践してみることにしました。今回のプログラムでは、自分自身の経験を振り返りながら「弊社の脆弱性診断に必要な知識を体系的に学んでから、実案件に携わってもらう」という流れにしました。

OJTの期間と概要

今回基本の「き」を伝える最初のOJTの期間は1ヶ月ほどを予定してました。この1か月をどのような期間にしたいかということを考えたのですが、まずは脆弱性診断を行う上で必要な知識を学習することに専念してもらいたい、と思いました。
そこで、

• 前半2週間：「基礎知識の学習期間」
• 後半2週間：「実際に模擬診断してみる期間」

として設定しました。

OJTの内容とまとめ

前半と後半の研修内容を具体的に紹介します。

前半：「基礎知識の学習期間」の内容

前半の期間では、基礎知識の学習として教材を活用しました。以前インターンで活用していた「脆弱性を体験できるデモアプリ」を使い、実際に操作してもらうことで、脆弱性がある場合の挙動を直感的に理解できるようにしました。

また、「安全なWebアプリケーションの作り方（通称：徳丸本）」（https://wasbook.org/）の書籍を併用して学習してもらいました。こちらの書籍はWebアプリケーションに作りこまれた脆弱性・設定の不備などが日本一詳しく解説されている名著です。かなり分厚い本ではありますが、「この本を読まずして脆弱性診断士を名乗るべからず」と思い、OJTの前半期間に自己学習の時間を取り入れ、1周読んでもらう時間を設けました。

後半：「実際に模擬診断してみる期間」の内容

後半の期間でも実際の案件ではなく、わざと脆弱に作った攻撃が通りやすいサイト、通称「やられサイト」を対象に診断してもらいました。念のため補足しますが、やられサイトは練習用に自身のPC内（ローカル環境）で立てているものであり、実際に稼働しているサイトではありません。

脆弱性診断初心者の悩みとして「自分の行った検証手法が正しいか分からない」というものがあります。これは問題が出ないことが、「攻撃の刺し方が間違っていたのか」「本当に問題のない造りになっていたのか」のどちらなのかを自身では判別できないためです。そこで攻撃が刺さりやすいサイトを対象にすることで、攻撃が刺さることを実体験してもらいました。その上で、脆弱性診断の検証手法を試して理解してもらうようにしました。

また模擬診断では、「なるべく実際の案件と近しい作業工程を体験してもらうこと」を重要視しました。これは「体験はしたけど実践は初めて」だと、いざ実際の案件に従事した際に「実際にすべきこと」が分からず混乱が生じるためです。脆弱性診断の検証作業だけでなく、ツールの使い方を教えたり、速報・報告書を実際に書いてもらい、それらの内容をFBするなど一連の作業を行うようにしました。

まとめ

結局1か月では期間が足りず、1ヶ月半まで延長してもらうことになったのですが…（関係者の皆さんごめんなさい！）内容としては以前よりよくなったのではと感じています。まだ改善点があるので、現時点で満足はしていません。

今回のOJTを実践してみて、学んだ点・改善点

今回、私が人に業務を教える経験が初めてだったこともあり、まずはやってみようのスタンスで臨みました。そのため粗削りな部分も多く、いくつか改善点があると感じました。具体的には以下の3点です。

1点目：模擬診断の方法について

1点目は、模擬診断の方法についてです。今回は脆弱性が多く存在する「やられサイト」を使用しましたが、結果として「脆弱性が検出されすぎる」という問題に直面しました。脆弱性診断は見つかった問題を全て報告するため、それに則ると時間がいくらあっても足りません。結局「同様の問題が複数見つかった場合は、代表として1件を検証・報告する」「報告書に書く問題を絞る」という形で対応しました。今後はやられサイトの中でも対象機能を絞ったり、機能数の少ないやられサイトを作ってもいいかもしれないと思いました。

2点目：OJTの在り方について

2点目は、OJTの在り方についてです。OJTの目的は「チーム内の業務を自力遂行できるようになること」。ですが、当初私は「初学者にもWebセキュリティの面白さや楽しさを伝えたい！」「〇×をつけるだけの作業員としてのエンジニアにはなってほしくない！」と考えていました。それはOJT担当者である私の好み・志向の問題に過ぎません。要素として取り入れるのは良いですが、そこが目的になると本来の目的とは逸脱した期間を過ごすことになってしまいます。なので、途中からは「完了時点でどの状態になるのが望ましいのか」「本来の目的・本質は何か？」を常に自身に問いかけて工程を進めるよう心がけました。

3点目：OJTに必要な期間について

3点目は、期間の見積が甘かったことです。実際に作業を行ってもらう中で、自身で作業工程のマイルストーンを定義しきれていなかったため、「この作業が完了した時点でFBを返す」「この作業には何日かかる」という点が弱く、作業の締切提示や適切なタイミングでの声掛けが少なかったと反省しています。指示をする側が全体の把握をしていないと、従事する側は「いつまでにやればいいのか」「今やっていることが適切か」に不安を感じると思います。これらは作業自体のモチベーションにも直結するため、一連の流れをシミュレーションしたうえで指示を出せるとよりよくなるかと思いました。

OJTを受けたメンバーからの感想

OJTを受けてもらったメンバーに感想をもらったので、あわせて紹介させてください。

OJTを通して

OJTを担当する1ヶ月半は大変考えることが多く、目まぐるしい期間でした。ただ学べることも多く、充実した期間でもありました。チームの皆さんにはOJTの期間中、案件を調整してくださったり、OJTをサポートしていただいたりと大変ご協力いただきました。改めて感謝申し上げます。

なお弊社の脆弱性診断をご検討いただいている皆様への補足ですが、本OJTの終了後は先輩社員と一緒に作業しながら少しずつ一人立ちしていく体制としています。この期間が終わればいきなり一人で案件を担当するということではありませんので、ご安心ください。

最後に徳丸本は偉大なので、ぜひ皆様お手に取って読んでみてください！

著者：閑戸 理帆
VAT（脆弱性診断）チーム所属。脆弱性診断や標的型攻撃メール訓練を主に担当。新米セキュリティエンジニアとして日々勉強中。