Webサービスの脆弱性管理はなにをすればいいのか

よく聞く質問の1つにWebサービスの脆弱性管理はなにをすればいいのか？です。

脆弱性管理=パッチ適用という印象が強く、実は何のために何をするのか、を理解していない場合があります。とりあえずやる！のではなく、なぜやるのかを理解するとやりやすいと思います。

脆弱性管理とは、脆弱性を見つけて、判断して、対応する、というサイクルになります。

ではなぜ、脆弱性管理をするのでしょうか？

一言でいえば、外部の攻撃者からの攻撃を防ぐため、です。

攻撃者が使用する攻撃というのは色々ありますが、1つのパターンとして脆弱性を見つけて、そこを攻撃して、侵入したり、情報を取得したする、という方法があります。

よって自社のシステムの脆弱性を攻撃者より早く発見し、その脆弱性を塞げば、システムの防御力が上がる、ということです。

攻撃者がどのように脆弱性を活用しているのかはこの記事を見てみるとわかりやすいです。

さてなぜ脆弱性管理が必要なのかはわかったと思います。

では、実際に何をしていけばよいのでしょうか？

脆弱性を見つけて、対応判断をして、対応する、ということをやっていきます。

脆弱性を見つけると行っても、何の脆弱性を見つけるのか（システムにはOS、ミドルウェア、コードなど）、どのチームがやるのか、自動化するのか、ルール（規定）はどうするのか、といろいろ考えることはあります。

対応判断も同じくどのチームが、どのように対応判断をするのか。複数のWebサービスを持っている場合、すべて同じルールで判断するのか、などあります。

このように脆弱性を見つけて、対応判断をして、対応して、そしてこれらのサイクルを管理していきます。これを一般的に脆弱性管理を行っています。パッチ適用というのは脆弱性管理における最後の対応の部分になります。

では脆弱性を見つける全体像を考えていきます。

具体的にはどんな方法で何を対象にした脆弱性を見つけるのか、ということです。

AWS上に3層アーキテクチャで構築されているWebサービスを例に考えてみます。
この場合、シンプルに LB - EC2 - RDS という構成とします。

これに沿って、どんな方法で何の脆弱性を見つけるのか考えます。

構成要素	システム	脆弱性管理の対象	脆弱性の検出
インフラ全体	AWS	✗	-
ネットワーク	VPC	✗	-
OS	EC2	○	AWS Inspector
ミドルウェア	EC2	○	AWS Inspector
アプリケーション全体	-	○	DAST
ソースコード	PHP	○	SAST
ライブラリ	composer	○	SCA

DAST = 実際に稼働しているWebサービスに対するセキュリティテスト

SAST = エンジニアの書いたソースコードに対するセキュリティテスト

SCA = ライブラリに対するセキュリティテスト

イメージとしては下記の概念図のように自動で脆弱性をスキャンして、その結果を脆弱性を管理するシステムに自動で追加されるという流れが望ましいと考えています。

アプリケーションに関連する脆弱性でまとめて管理するなら、このような仕組みが考えられます。

12th LAB