業務効率化・品質向上をエンジニアリングする - Flatt Security のセキュリティ診断プラットフォーム「ORCAs」

はじめに

こんにちは、株式会社 Flatt Security セキュリティエンジニアの梅内(@Sz4rny)です。

突然ですが、読者の皆様はセキュリティ診断(脆弱性診断)を提供するようなセキュリティベンダーがどのような体制で業務を行っているか、すなわち「サービスの裏側」を知る機会はあまりないのではないでしょうか。

本稿では、Flatt Security において独自に開発しているセキュリティ診断プラットフォームである ORCAs (オルカス) に焦点を当て、その概要や開発の経緯、開発チームが技術的に興味深いと感じている点について紹介します。

本稿を通して、Flatt Security がどのように本プラットフォームを活用してセキュリティ診断に取り組んでいるのか、また、なぜセキュリティベンダーとして診断サービス等だけではなく、このようなプロダクト開発にも注力しているのかについてお伝えできれば幸いです。

セキュリティ診断のサービス詳細は下記バナーよりご覧ください。

はじめに
従来のセキュリティ診断における課題
セキュリティ診断プラットフォーム - ORCAs
セキュリティ診断プラットフォームとその開発に関するトピック
おわりに

従来のセキュリティ診断における課題

従来、Flatt Security ではセキュリティ診断の進行管理や発見した脆弱性の起票に Google Sheets (以下、スプレッドシート) を、また、報告書の作成には Google Docs (以下、Docs) を利用していました。

より具体的に述べると、診断開始から報告書提出までのフローは以下のようになっていました。

セキュリティ診断用のスプレッドシートを新たに作成する。
診断対象 (例: URI と HTTP メソッドの組や機能名) を列挙したシートを作成する。なお、各行には診断対象の URI や HTTP メソッド、パラメータ、機能の概要、診断項目¹ を記述しておく。
診断員は各行に記載されている診断項目に沿った検査を実施し、その結果や発見した脆弱性を追記する。
診断が完了したら、スプレッドシートに記載された脆弱性の記述を Docs に転記する。このとき、報告内容のレビューや体裁の修正等をあわせて実施する。
すべてのレビューや修正が完了したら報告書を提出する。

さて、このようなフローで実施されていたセキュリティ診断サービスですが、診断員および診断件数の増加や診断対象の拡大²に伴って、上記のようなアドホックなフローでは対応できないさまざまな課題の存在が明らかになりました。具体的には、以下のような課題が挙げられます。

診断業務に関する情報の乱立 ... 診断に関する情報がチャットツールやスプレッドシート、Docs およびそれらのコメント欄に乱立しており、必要な情報を即座に参照することが困難である。
プロジェクト管理のコストが高い ... 診断ごとの進行状況を把握するためには、スプレッドシートを参照し、そこから必要な情報を目視で確認しなければならないため、管理コストが高い。
報告書作成のコストが高い ... 報告書作成のために、スプレッドシートに記載された脆弱性の情報を Docs へ体裁を整えながら転記するのに時間がかかる (報告書作成に必要な情報は転記時点で揃っているため、本来この作業はゼロコストで達成されるべきである)。
属人化や品質のズレ ... 事前に定義された診断項目に加えて、診断員による手動診断を行う場合、担当する診断員の知識や経験によって診断の品質が左右される恐れがある。加えて、豊富な経験を有する診断員のノウハウを共有することが困難である。

セキュリティ診断プラットフォーム - ORCAs

Flatt Security では、上記に挙げたような課題の解決や、セキュリティ診断サービスによって提供可能な価値をより高くすることを目標として、実際に診断業務に携わっていたメンバーを中心にセキュリティ診断プラットフォームである ORCAs (ORchestrated Collaborative Assessment system) の開発に着手しました。

ORCAs は既存の脆弱性管理システム³のコンセプトを参考に、ゼロベースで実装されています。以下に、ORCAs を用いたセキュリティ診断のフローを示します。

プロジェクトマネージャは診断ごとに新たに「診断」を示すエンティティを作成する。加えて、診断対象を診断内に作成する。
診断員は診断対象を確認し、その診断対象が有する特徴 (例: 認証機能、データベースアクセスを行う等) を登録する。
独自に構築した検査項目データベースから手順2で登録した特徴に該当する検査項目をインポートする。また、さらに検査が必要な項目がある場合は診断員が独自に検査項目を登録する。
検査項目をもとに検査を実施する。
脆弱性を検出した場合は「脆弱性」を示すエンティティを新たに作成する。
プロジェクトマネージャは報告書作成用の機能を用いてさまざまなフォーマットの報告書⁴を出力し、提出する。
診断中に診断員が独自に登録した検査項目のうち脆弱性の発見に寄与したものは検査項目データベースにフィードバックする。

セキュリティ診断業務を包括的に支援する ORCAs により、前述した課題の解決が実現されました。

診断業務に関する情報の乱立 → プラットフォームを用いた一元的な情報の管理により解決
プロジェクト管理のコストが高い → プラットフォームに診断の進捗状況を詳細に表示する機能を実装することにより解決
報告書作成のコストが高い → 発見した脆弱性のデータをもとに報告書作成機能を実装することで解決
属人化や品質のズレ → 検査項目の明文化やフィードバックを通して解決

セキュリティ診断プラットフォームとその開発に関するトピック

Firebase を用いた MVP 開発とフィードバックループを重視した取り組み

ORCAs の開発を開始した時期、セキュリティ診断サービスを既存の運用方法で円滑に進行させるのはすでに困難な状態となっていたため、可能な限り早く利用できるモノを開発する必要がありました。このような状況を受け、開発チームはプロダクトを MVP (Minimum Viable Product) として迅速に提供することを最優先しました。

そのような背景を踏まえ、開発チームは当時中心的にリサーチを進めていた mBaaS のひとつである Firebase を基軸に開発を進めることを決定しました。これは、 Firebase が有するドキュメント指向のデータベース (Firestore) や認証機能等が開発の要件とマッチしていたことや、プロダクト開発を迅速に開始できること等が他のプラットフォームと比較して優れていると判断したためです。

その結果、開発を開始してから3か月程度で初期バージョンをリリースし、診断員からのフィードバックを得て改善を繰り返すというサイクルを早期に形成することができました。現在では、診断員からフィードバックを得るための仕組みもプロジェクト管理ツール等によって効率化されています。

このような仕組みに加え、一般的なアプリケーションとは異なり、開発チーム自体が診断員 (すなわちユーザ) であることも合わさって、新機能の提案やバグフィックス等が非常に素早く実装されて本番環境にデプロイされる環境が構築されています。

あくまで黒子である業務支援の社内ソフトウェアですが、2020年6月の開発開始より約4万行もの規模にまで拡大され、また現在も継続して開発されています(なお、弊社は正社員25名程度の小規模なベンチャー企業です)。エンジニアリングの力でセキュリティを最大化させたいという弊社のスタンスがよく表れている部分と言えるかもしれません。

ORCAs の開発規模(`node_modules/` や `package-lock.json` は除く)

品質の標準化と継続的な向上を支えるための取り組み

ORCAs 開発チームでは、セキュリティ診断サービスの品質を向上させるためには以下の2点が重要だと考えています。

診断員のコミュニケーション不足やレギュレーションの確認不足等に伴うインシデントの発生を防止すること。
診断員がより多くの脆弱性を発見でき、かつ、発見した脆弱性の内容を適切に文書化した報告書を作成可能な環境を整備すること。

まず、上記の 1. は「診断の品質低下を防止する仕組み」と言い換えることができます。診断の品質低下を招くインシデントとして想定されるものの例を以下に示します。

ある診断対象において実施すべき検査項目を実施していなかった。
診断レギュレーションにおいて禁止されている時間や環境から検査を実施してしまった。
診断で発見した脆弱性の詳細や再現手順、対策等に誤った内容が含まれたまま報告書を提出してしまった。

これらの、いわゆる人間によるポカミスを防止するために、ORCAs には前述の検査項目データベースを活用した検査項目のオートフィル機能や診断レギュレーションに違反しない日時・環境かどうか確認する機能、報告書として提出する内容を相互にレビューするとともに、レビューにおいて承認が得られるまで報告書を提出できないようにする機能等が実装されています。

しかしながら、将来的に診断チームが認識できていなかった要因によってインシデントが発生することは想定されます。このような場合に備えて、ORCAs 開発チームでは診断におけるインシデントを吸い上げ、それを防止するための機能を実装し、迅速にデプロイするという運用体制を整備しています。

また、上記の 2. は「診断の品質向上を促進させる仕組み」と言い換えることができます。ORCAs 開発チームは、診断員がより多くの脆弱性を発見できるようにするために、発見した脆弱性を標準化するための仕組みや、診断員が過去の診断案件において発見した脆弱性を用いて知識共有を図れる仕組みが整備されています。

たとえば、以下の図に示すように、発見された脆弱性の中で興味深いものに関して診断員が :+1: できる機能が実装されており、これらの技術的に知見が得られる脆弱性の情報をもとに社内勉強会が開かれるケースもあります。

セキュリティベンダーとしてのプロダクト開発への向き合い方とビジョン

セキュリティベンダーとして、開発するソフトウェアに脆弱性が混入していないかについては特に注意しながら開発を進めています。

前述の通り、ORCAs はバックエンドのデータストアとして Firestore を採用しています。以前の記事⁵でも紹介したとおり、Firestore では CEL (Common Expression Language) のスーパーセットであるセキュリティルール言語を用いて、アクセス権限の管理やスキーマのバリデーションチェックを実現します。

ORCAs の開発チームは独自のリサーチや Firebase診断で培ったノウハウを活かして、非常に大規模なセキュリティルールの運用を実現するとともに、独自の静的チェックツール等の開発も実施しています。

また、ORCAs 開発チームではセキュリティ診断サービスと ORCAs 開発のシナジーを重視した取り組みを行っています。

具体的には、セキュリティ診断サービスで得たセキュリティ上の知見をもとに ORCAs 自体をよりセキュアにする取り組みや、ORCAs 開発で得たセキュリティ上の知見をセキュリティ診断サービスに還元するといった取り組みを実施しています。これらの取り組みにより、セキュリティ診断サービスとプロダクト開発がお互いにお互いの品質を高め合うというサイクルの形成を実現しています。

さて、言わずもがなですが、Flatt Security はサイバーセキュリティ企業です。ところで、皆さんはサイバーセキュリティ企業と聞くと「セキュリティ診断サービスを中心に提供する組織であり、プロダクト開発に注力しているわけではなさそう」というイメージを持つのではないでしょうか (筆者の入社前のイメージはそうでした)。

Flatt Security では、セキュリティ診断サービスの提供だけではなく、KENRO や Shisho Cloud、そして ORCAs 等のさまざまなプロダクト開発にコミットしています。

もちろん、これらのプロダクトそれぞれのコンセプトは異なりますが、Flatt Security がこのようなプロダクト開発にコミットする理由は、その根底に「開発者のための次世代セキュリティサービスを届け、世界中のプロダクト開発を加速する」というビジョンを実現するために、エンジニアリングのスキルを最大限に活かしてシステム化を進めることを厭わないという姿勢が存在するためです。Flatt Security は、今後もサイバーセキュリティ企業としての強みを活かしたプロダクト開発を推進していきます。

おわりに

本稿では、Flatt Security において独自に開発しているセキュリティ診断プラットフォームである ORCAs について紹介しました。

今後も Flatt Security はサイバーセキュリティのプロフェッショナルとして、開発者に寄り添ったセキュリティ診断サービスの提供に加えて、「開発者のための次世代セキュリティサービスを届け、世界中のプロダクト開発を加速する」というビジョンを実現すべく、プロダクト開発にもコミットしていきます。

そして、ORCAs 開発チームは今日も「ORCAs 無しでは生きていけない人」を増やすべく、また、セキュリティ診断サービスの品質を最大限に高めるために、業務プロセスやプロダクトの改善に注力しています。

Flatt Securityではセキュリティ診断サービスを提供しています。一般的なWebアプリケーションだけでなく、SPAやGraphQLのようなモダンなWeb技術、AWSのようなクラウドプラットフォーム、FirebaseのようなmBaaSまで幅広く専門家による調査を提供可能です。また、事後的な診断に限らず開発段階でのコンサルティングも対応可能です。