freeeの脆弱性診断と管理のこれから

この記事はfreee Developers Advent Calendar 2019 の 22 日目です。

酒飲みエンジニアのlivaです。今年の健康診断で尿酸値が8.6という高数値になりました。まだ痛風発作は出ていませんが、いつ出るかヒヤヒヤしながらお酒を飲んでいます。

普段はCSIRT専属エンジニアとして、各プロダクトに対する脆弱性診断やペネトレーションテストなどの作業を行いつつ、検出された脆弱性のトリアージや修正対応などの業務を行っています。

毎年春に新卒研修で行っている研修のおかげか、社内では攻撃者として名が通っています。今年の研修では物理的な攻撃を受けそう*1でしたが、居場所を隠していて事なきを得ました。なかなか物騒な新卒たちです。

さて、この記事では今社内で静かに進めている脆弱性診断や管理の刷新プロジェクトを紹介します。

現在持っている課題感

脆弱性診断や管理では以下のような課題感を持っています。

脆弱性診断結果が活用できていない
ライブラリに存在する脆弱性が管理されていない
Kubernetes(以下K8s)やDockerなどのコンテナ類に対して脆弱性スキャンが回っていない
インフラ周りの脆弱性診断が実施されていない

特にライブラリに存在する脆弱性が管理されていない、K8sを利用したサービスやその他インフラに対する脆弱性スキャンが実施されていないのはまずいと考えました。このあたりに手を入れる過程で、日常的に回している脆弱性診断の結果も活用していこうとプロジェクトにまとめていきました。

プロジェクトの概要

以下のレイヤーに分けてスキャンを実施します。

Webアプリケーション
サーバー/ミドルウェア
コンテナ/K8sクラスタ
脆弱性管理

Webアプリケーションはさらに2つ*2に分けています。

ブラックボックステスト(動的診断)
ホワイトボックステスト(静的診断)

これらのスキャン結果はAPIを介してAWSのS3に集約します。 S3に集約した結果はKibanaで作成したダッシュボード上で一元的に表示し、これまでの推移や各プロダクトの現在と過去、脆弱性への対応状況が分かる状態を作ります。

また、各ツールはGitHubActionやAWS Lambdaを利用して自動化し、なるべく人が介在しない状況を作ります。

各レイヤーごとにやること

Webアプリケーション

HCL社の提供するAppScan Standard*3を使っており、引き続き使います。しかし、こちらはブラックボックス診断しかサポートできず、ホワイトボックス診断がサポートできません。そのため、Cloud版であるAppScan on Cloudを利用します。 AppScan on Cloud*4はブラックボックス診断とホワイトボックス診断に加え、iOSやAndroidアプリケーションのスキャナとしての使用もできます。 StandardとCloudを併用する理由は、Standardと連携できるのとCloudではAPが使えるためにスキャン作成から結果取得までAPIで完結させることができるためです。そもそもfreeeでは以下のような流れでAppScan Standardを使用していました。

AppScan Standardを使ってスキャンシナリオを作成する
作成したスキャンシナリオを使ってスキャンを行う
結果を出力してGoogleDriveに保存

3で結果を保存するのはいいのですが、膨大な量のスキャンファイルを一つずつ見ていくのはとても労力のかかる上に非効率でした。ここにAppScan on Cloudを導入することで、結果をブラウザ上で一覧できるようになります。

サーバー/ミドルウェア

オープンソーススキャナであるOpenVAS*5を使用します。スキャナとしては老舗であり、品質は安定しています。専用のEC2インスタンスを構築し、そこから弊社が提供しているプロダクト・サービス全体に対して定期的なスキャンを実行します。

コンテナ/K8sクラスタ

記事執筆(12/13)時点ではまだ未定ですが、候補の絞り込みは終わっていてその中のプロダクトを使います。どちらもコンテナとK8sクラスタを網羅してスキャンを実施できる見込みです。上記以外にECRに存在するイメージに対して定常的にtrivy*6を使用します。すでに特定サービスのCIには埋め込んでいて、GitHub上でPullRequestを作成する度にスキャンを走らせていますが、結果は活用できていません。今後は各PullRequestに流すのではなく、ECR上にUploadされたタイミングで回します。

脆弱性管理

ビズリーチ社の提供しているyamory*7というサービスを利用します。本サービスの良いところとしては「公開されているPoCを収集してくれる」「自動トリアージが実態に即している」点が挙げられます。どちらも担当が手動でやろうとすると膨大な時間がかかるため、スキャンの段階でこれらが終わっているのはとても助かります。ただ、全ての結果を素通りさせるわけにはいかないので、適宜CSIRTの担当(私)がチェックする必要はあります。結果は過去分から全て集約されるため、yamory内で情報管理できるのもメリットです。対応状況もこちらでわかるようになっています。「脆弱性対応時のコミュニケーションをどうするか」という課題はまだ残っていますが、叩き台だけ作ってあとは実際に動かしつつ最適解を見つけていくことになるかと考えています。