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

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

なぜ脆弱性管理をするのか

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

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

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

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

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

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

攻撃者は脆弱性を探している

脆弱性管理とはなにをするのか

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

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

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

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

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

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

Webサービスの脆弱性管理の全体像を考える

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

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

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

  • Webサービス
    1. インフラ
      1. ネットワーク
      2. OS
      3. ミドルウェア
    2. アプリケーション
      1. ソースコード
      2. ライブラリ

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

構成要素システム脆弱性管理の対象脆弱性の検出
インフラ全体AWS
ネットワークVPC
OSEC2AWS Inspector
ミドルウェアEC2AWS Inspector
アプリケーション全体DAST
ソースコードPHPSAST
ライブラリcomposerSCA

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

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

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

脆弱性を見つけるには

脆弱性を見つけるにはいろんな方法がありますが、ここではシステムで自動化できるという観点から整理します。

インフラの脆弱性

このケースの場合、インフラはAWSを使っているのでAWSのマネージドサービスが使えます。具体的にはAWS Inspectorになります。

アプリケーションの脆弱性

アプリケーションの場合、DAST(アプリ全体)、SAST(ソースコード)、SCA(ライブラリ)があります。これらは手法ですが、PHPだとSemgrepというツールでソースコードおよびライブラリの脆弱性を見つけることができます。

どうやって脆弱性を管理するか

見つけた脆弱性を管理するにはどうすればいいでしょか。すべての脆弱性を1つに集めて管理するのもいいですし、インフラとアプリケーションでそれぞれ脆弱性を管理するのもよいと思います。

ただこれもスプレッドシートなどでやるのではなく、システムで自動化するのがよいと思います。

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

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

まとめ

  • 脆弱性管理をする理由はWebサービスの防御力を上げるため
  • 脆弱性管理でやることは、脆弱性を見つけて、判断して、対応する、そして一連のサイクルを管理できるルールやシステムを作り、運用すること