サービス価値向上に、脆弱性診断を活用できていますか？
Visionalグループでは、事業とセキュリティの真の「共存」を実現するため、全社横断組織としてセキュリティ室があります。セキュリティ室では、様々な事業部を巻き込み、脆弱性診断を通して事業部に寄り添ったリスクコントロールを実践しています。そして、「事業部の仲間たちが実現したいことに全力で挑戦できる、安心・安全な環境づくり」 を目指しています。
皆さんの職場ではどのように脆弱性診断と関わっていますか？
「監査対応の要件として実施している」「リスクを抑止するための根拠を提供してもらっている」だけでしょうか。
私たちセキュリティ室も、はじめは在り方が定まっておりませんでした。しかし、様々な課題を乗り越え、現在では事業部との適度な抑止関係でスピード感のあるリスクコントロールができるようになりました。
2021年4月22日に上場を果たすまでの約1年間、数名からなるチームでVisionalグループの全サービスの脆弱性診断を行いながら、どのような課題にぶつかり、アジャイル開発に寄り添うリスクコントロールを実現できるようになっていったのかを紹介します。
内製での脆弱性診断との関わり方や事業のリスクへの向き合い方の参考になれば幸いです。
失敗談「内製の脆弱性診断に求められることは外部ベンダーの脆弱性診断の発展系？」
私はCEH(Certified Ethical Hacker)の認定資格を取得しているホワイトハッカーです。これまで6年間で国内外200社、350以上のサービス・アプリケーションをベンダーの立場で診断してきました。ベンダーの立場よりも踏み込んだリスクコントロールを実現するため、コロナ禍直前の2019年12月に株式会社ビズリーチにジョインしました。
そして業務に就いてすぐに診断環境を構築し、診断や報告も、ベンダーで提供される品質と遜色ないレベルで提供しました。 しかし、提供した内容には開発組織から大きな反発を生むことになりました。 当初はこの反発について、エンジニアのプロダクトへの思いや背景を汲み取らずに診断環境を提供していたから起こってしまったのだと思い、GitHub上のコードを読み込んだ上で、実現可能なコードや実装も対策として提案するようにしました。
すると、対策の実現性に対する反発自体は抑えられましたが、一方で対策の優先度に対して、機能開発や事業のスピードを落としてでも対応する根拠がわからないとの理由で、提案が却下されるようになりました。 提案しては却下、再提案しては却下と、是正は遅々として進まず、セキュリティ対策について消極的な姿勢の事業部への提案作業がセキュリティ室の工数を逼迫するようになりました。 Visionalグループではどの事業も年々拡大し続けている中、このままでは翌年にでもセキュリティ室の作業が回らなくなることは目に見えていました。
そこで、セキュリティ関連のコミュニケーションが開発組織のコミュニケーションに比べ明らかに遅いことに着目して、コミュニケーションチャンネル(手段)の強化、打ち合わせによる認識のすり合せ、ステークホルダーの巻き込みなど、是正への取り組みを進めました。 しかし、これらの取り組みを進めても工数は削減するどころかやるべきタスクばかり増大し、何か「根本的な間違い」があるのではないかと考え、方向性を改める必要に迫られました。 一緒に頑張ってくれているメンバーに対しても感謝の気持ちと同時に申し訳なさが募りました。
元々「エンジニアをよく見て考えなさい」との上長からのアドバイスを理解した上でこれらの対策を打っていたつもりでしたが、 前職の立場でのバイアスから 「外部ベンダーとしての延長線」を前提に考えていたのが「根本的な間違い」の原因 ではないかと考えるようになりました。
突きつけるではなく寄り添う
「エンジニアをよく見て考えなさい」の言葉を振り返り、相手の立場で置き換えるとしたらどのような状況なのかを考えてみました。
エンジニアにとってプロダクトは一緒に苦楽を歩んできた存在 です。そのプロダクトに対し問題点を淡々と指摘する行為は、「心」動かされない「よそ者」の行為と受け取られたのでしょう。
Visioanlは「事業づくりは、仲間づくり」というバリューを掲げています。
しかし、「ベンダーで提供される品質と遜色ないレベルで診断結果を提供する」ことだけに目が向いてしまい、「仲間として共に事業づくりをする」ことを疎かにしてしまっていたのだと気がつきました。
そして、この気づきを行動に変えるべく次のことを考え、取り組みを開始しました。
- セキュリティという価値を「一緒に作る」状態にするにはどのような方法があるのか
- 開発組織とセキュリティ室が苦楽を共にしながら「セキュリティ」という価値を自分たちの手で作り出したと実感してもらえるには何をすべきなのか
「一緒に作る」ための運用変更
まず、すべきことから逆算して弊害となっていることを見直すと、 脆弱性に対する対策を「セキュリティ室が定める」ことは不要 とわかりました。
対策を「定めず」に記載欄をあえて空欄にして、打ち合わせの場で意見を持ち寄り一緒に作っていくこととし、既存の運用を変更することを決断しました。
この決断は、10以上の事業部で扱われる別々の言語やフレームワーク・インフラ環境ごとに最適化された解決方法を、リアルタイムの打ち合わせで一緒に作れるだけの知識と実用的な理解が求められます。
そして起こりうるリスクを説明する責任が要求されます。ここに関しては勉強と事前のシミュレーションを頑張ればいい話です。しかし、「寄り添う」存在になるためには、それではまだプロダクトへの理解は浅いと思いました。
エンジニアと同じ視点で設計段階から参画
次に、開発現場への理解を深めようと考えました。いくつかの企画段階の開発のミーティングに参加し 「何がそのプロダクトにとって重要か」 の理解に努めました。
アジャイル開発では世の中のフィードバックを第一に大切にします。
その開発スタイルと共に歩むため、「脆弱性診断」という切り離された物言いではなく、 セキュリティレビューアとして、「言いにくいフィードバックを言う」立場に努めることにしました。
手戻りさせるのは同じエンジニアとして心苦しいですし、開発工数も大きくなります。そこで、実装してできたモノに対してではなく、その前段階の企画・設計段階から指摘を行うようにしました。すると、実装の前段階の相談が徐々に増えてくるようになりました。
また、同じ目線に立つため、実装やスケジュールの現実性の課題を共有しつつも、お客様に提供する立場として妥協せず答えを出すことに拘りました。
なぜなら真の「共存」を目指すためには 言いにくいことも言い合える「寄り添う」仲間を目指さなくてはならないからです。
訊(き)かねば聞くことすらかないません
ところで、 ヒアリングの品質がテストの品質を決めることはQAもセキュリティも変わりありません。 本質的な課題に踏み込むべく、掘り下げる質問を妥協なく行う必要があります。つまり、「常識的に」やってくれているだろうと暗黙に進めることは怠惰と言わざるを得ません。
セキュリティレビューアとして、 「私がお客様の立場で今の話を納得するだろうか」「聞きたいことはないだろうか」 と自問自答しなければ、脆弱性診断の報告に対し「サービスの仕様上直せません」の壁を超えるのは極めて困難です。
例えば、現状のパスワードでのログインをパスワードレス化する場合のセキュリティ的懸念を教えてほしい、と質問が来たとしましょう。
教科書的に調べた内容をまとめて懸念点を列挙することは容易です。
しかし、ここでそのような仕様を検討する背景を訊いていくと、ユーザが登録時に入力する文字を一文字でも減らしたい、そんな思いで削れる方法としてパスワードレスが有効なのかと相談したとわかりました。
するとパスワードレスを許可するしないの対立ではなく、要望を踏まえた上で実装する場合、本当に他の道がないのか模索することで納得感のある他の道を見出すことができます。
訊(き)かねば聞くことすらかないません。 本質的な課題に当たるまで批判を恐れず訊くことに努めていくようになりました。
このようなやりとりを重ねていくことで、業務自体は増えました。しかし、 脆弱性診断に拘らず事前相談を増やした結果、「リスクの高い脆弱性は1年で50％以上減少させることができました。 また、一緒に決めた是正方法は確実に実行されるだけでなく 圧倒的に是正スピードを向上する結果にもつながりました。
次の挑戦へ
この約1年を振り返ると、前職でのベンダーとしての脆弱性診断では経験できなかった様々な再発見がありました。 発見されたリスクを受け取り一緒にコントロールしていくことや、設計や企画段階からリスクになりうるシナリオに対策を考えること、どれも外部ベンダーとして診断を行った際には経験できなかったことです。 まだ道半ばですが、 事業に寄り添い「一緒に」品質価値を創造していく脆弱性診断に変わっていく過程はかけがえのない経験になりました。
ベンダーとしての脆弱性診断では、自分にとってはできることの行き詰まり感を感じることがありましたが、今の「寄り添う」脆弱性診断は、先に道が続いていると感じています。 諦めずに「寄り添う」ことに向き合い続けて良かったと実感しています
脆弱性診断は「品質価値」を創造しLTV(サービス寿命)を延ばす仕事 です。 エンジニアと寄り添って失敗から学び「内製の」脆弱性診断を見出したことで、事業とセキュリティの真の「共存」を実現していくために次に挑戦すべきことが2つ見えてきました。
1つ目は、 プロダクトのあらゆるライフステージに寄り添うことへの挑戦です。 具体的には、要望が要件になるところから、サービスが統合・廃止になるまでをいかにカバーする仕組みを構築するかという挑戦です。
2つ目は、 事業とセキュリティの真の「共存」をベースに一緒に事業づくりや価値創造を目指していく未来を考えていくことです。
これらに挑戦し、今後も大きく変わり続けるためには仲間を増やしていく必要があります。
セキュリティ室では、セキュリティエンジニアとして事業とセキュリティの真の「共存」を実現していくため、多数のプロダクトのリスクに最後まで一緒に併走し、事業づくりをしたい仲間を募集しています。
ここまで読んでいただきありがとうございました。この記事が皆さまの挑戦のきっかけにつながりましたら幸いです。
