日々発見される新たな脆弱性と攻撃手法への対処
～Webアプリの安全性を維持し続けるために～

＜脆弱性検査をしたシステムがなぜ侵害され続けるのか＞

脆弱性テストをしたシステムが依然として侵害される理由は3つあり、1点目は実施時点で脆弱性を検出しても、その後も新たな脆弱性が発見される可能性があることだ。攻撃者は常に新たな攻撃手法を見つけ出したり、研究者の情報を利用したりすることがある。非常に有名な「WannaCry」は、一般的にはそれまで安全と思われてきたWindowsの標準プロトコルの脆弱性を悪用したケースだ。

2点目の理由は脆弱性に対応するアップデートや修正が間に合わないことだ。脆弱性が発見されても必要な対応が取れない限り、その脆弱性は悪用される。Equifax社データ漏洩の事例では、2017年3月にApache StrutsフレームワークのRCE脆弱性の修正パッチが公開されたが、同社が対処までに2カ月間を要した間に不正アクセスによって1億4,000万人の個人情報が流出してしまい、CEOの引責辞任や約600億円の保障という事態に追い込まれた。

3点目の理由はヒューマンエラーが原因の脆弱性が存在することだ。コロニアルパイプライン社の事例では、攻撃者はダークウェブに流出した他のシステムのクレデンシャルを入手し、VPNへの侵入を試行した。本来禁止されていたと思われるクレデンシャルの使いまわしが行われており、なおかつ2段階認証も有効とされていなかったため、侵入が成功してしまった。さらにIT部門ではこのVPNの存在を認識していなかったことも迅速な対応には不利となったと思われる。パスワードの漏洩や設定ミス、権限やアクセス制御の設定の不備、思い込みから生じる各種のミス等、ヒューマンエラーを原因とした不備が攻撃を容易にし、侵害を引き起こすことがある。

＜侵害に対処できない理由1. 機能の追加や環境の更新時の脆弱性混入＞

確かに、多くの組織はリリース前に脆弱性検査を実施しているが、ソフトウェアが運用される期間の方が開発期間よりも長い。そしてその間にさまざまな事象が発生する可能性がある。リリース時の脆弱性スキャンだけでは侵害に対処できない理由の1点目は、その長い期間において新しい機能実装や環境の変更が行われる際、新たな脆弱性が混入する可能性があることだ。

このような変更があった場合、本来は既存の機能を含めて再度システム全体の脆弱性テストをするべきだが、実際は難しいケースもあるのではないだろうか。例えば大規模なシステムや特殊な環境を完全に再現することは困難であり、実際の運用環境でのテストが難しい場合がある。プロジェクトには限られた予算やリソースがあり、新しい機能や変更部分に対するテストだけのリソースしかない場合もある。また、既存部分と新規部分で異なる会社が担当する場合、契約や法的な制約があり、全体の再テストが難しいケースがあるかもしれない。

＜侵害に対処できない理由2. リリース後の利用モジュールの脆弱性の悪用＞

OSSや外部モジュールは参照先が枝葉状に伸びており、通常の管理では想像が難しい範囲に広がっていることがある。各モジュール依存関係によっては予期せぬモジュールの脆弱性の影響を受け、提供システムへの侵害に繋がる可能性がある。攻撃者は提供システムを直接攻撃しなくても、利用している外部モジュールの依存関係のどこかに脆弱性を発見できれば、提供システムの機能に影響を及ぼすことができてしまう可能性がある。

OSSなどの外部モジュールは、しっかりとメンテナンスされているものもあれば、逆にメンテナーが既におらず放置されているものもある。また、仮にしっかりとメンテナンスされていても、パッチを適用するという作業が行われなければどこかに脆弱性が残ったままになってしまう。この状況に対処するためには、完成時や納品時における脆弱性のチェックだけでなく、SBOMと呼ばれる利用しているソフトウェア・モジュールの部品表を作成することが重要だ。

リリースに備えて脆弱性テストを行ったシステムであっても、そのテストが終了した瞬間から新しい脆弱性がシステムに内包される可能性はある。既知の脅威を防ぐ仕組みに加え、脆弱性モニタリング・脅威者や攻撃に関する情報収集・ソフトウェア構成管理等、将来発生しうる脅威を防ぐ仕組みも導入することが必要だ。

＜継続的な脆弱性管理を使った、Webサービスを安全に保つ方法＞

脆弱性を継続的に検査することで、侵害リスクの低減が可能となる。Webシステムの脆弱性を継続的に検査することで、内部的なリスク要因であるシステム変更による脆弱性の混入と、外部的なリスク要因である新しい攻撃手法の発生の双方を迅速に検知し、適切に対処することが可能だ。

継続的な脆弱性管理を行わない場合、改修やリリースなどが行われた直後から、安全を保障できない状態で運用している期間ができてしまう。大規模リリースでは検査が行われることも多いが、リソースとの兼ね合いから小規模改修では検査なしのケースも多いのではないだろうか。継続的に脆弱性の管理がされていない場合、ある一定の期間、Webサービスは侵害リスクに晒されることになる。

継続的な脆弱性管理を行う場合、まず新しい攻撃手法を取り入れた脆弱性検査を実施することが重要で、Webシステムの侵害リスクを極小化できる。そして脆弱性が発見された場合、組織は5つの対応方法から最適な対応を選択することになる。具体的にはビジネスリスクの評価、WAF等による代替対応可能性の検討、修正にかかるリソースやコストの検討、修正完了までのスケジュールの評価、システムの廃止や代替も含む検討だ。

＜シノプシスの脆弱性検査サービス「WhiteHat Dynamic」＞

当社のWhiteHat Dynamicは、SaaS型のウェブアプリケーションの脆弱性検査サービスだ。運用中のアプリケーションを継続的にモニタリングし、機能追加や修正などの変更箇所には自動で検査を拡張し、新たな攻撃手法やリリース後に公表された脆弱性にも対応する。検査結果はTRCと呼ばれるエキスパートがマニュアルで確認する。そのため理論上、誤検知は存在しないため、これまで必要とされてきた検証時間や人的リソースを節約可能だ。

最大の特徴は、本番環境であっても安全なテストを実行できることだ。20年、4千万回以上のテストにおいて無事故であり、9割に近いお客様が本番環境でのテストを希望されている。

＜マネージドセキュリティサービス＞

全てのアプリケーションでWhiteHat Dynamicを使って継続的な脆弱性検査を24時間365日行うのが理想だ。しかし一般的には数百あると言われる全てのアプリケーションでの利用が難しい場合は、当社のDASTやSASTなどマネージドセキュリティサービスの利用もシステムの重要度やリスクの度合いから現実的な選択肢となる。

当社には3Dアプリケーション・セキュリティテスト（AST）バンドルがあり、固定価格の年間契約ができる。マネージドサービスの全てのテストが実行可能で、テスト対象システム/アプリ、テストの種類、テストの深さを都度選択可能だ。1回につき、1つのテストの実行ができる。イメージとしては、パイプラインにシリアルにテストを詰めて流していくイメージで、並行しての実行はできない。

＜まとめ＞

システムへの変更は運用上避けられないことだが、脆弱性が混入する原因となり得るという認識を持って欲しい。そして攻撃者は常に新しい攻撃手法を発見しておりリリースした時の脆弱性テストが有効な期間は短い。またシステムが利用する外部モジュールの脆弱性は今後大きな問題となる可能性がある。実際の運用はモジュールの依存関係が枝葉のように広がることもあり難しいが、システムを安全に保つうえで非常に重要だ。これらに対して継続的な脆弱性管理は非常に有効な対策の一つとなりえる。システムの状態を常に最新の情報で把握し迅速な意思決定と対応をし続けることを可能とする。一度の検査で脆弱性を発見して終わりではなく、常に適切な対応を取り続け、製品をEOLまで安全に保つようにすることをゴールとしてほしい。継続的な脆弱性管理で、当社のWhiteHat Dynamicをご活用いただけたら幸いだ。

◆講演企業情報
日本シノプシス合同会社：https://www.synopsys.com/ja-jp/software-integrity.html