セキュリティトレンドは開発手法に伴って日々変化しており、セキュアなアプリケーション開発の実現には、従来の脆弱性に加えて、新たな脆弱性も含めた幅広い観点での対策・対応が必要です。
本記事では、新たな脆弱性を知るために欠かせないトレンド情報を活用するための「OWASP TOP 10」と「データから見る日本の脆弱性トレンド」について説明します。
OWASP TOP 10から見る脆弱性トレンド
Webアプリケーションセキュリティに関する流行の脆弱性ランキング『OWASP TOP 10』をご存じでしょうか？ ソフトウェアのセキュリティ環境の現状、またセキュアなソフトウェア開発を促進する技術・プロセスに関する情報共有と普及啓発を目的としたオープンソース・ソフトウェアコミュニティであるOWASP（Open Web Application Security Project）に所属する脆弱性診断士が、リスクのある脆弱性の上位10項目をランキング形式でまとめたドキュメントです。
あくまでも今の脆弱性のトレンドを示したものであり、網羅的な対策やテストを行うためのものではありませんが、方針検討の際などには、「OWASP TOP 10で挙げられている観点を自社のプロセスに盛り込めているか？」、「新たな変化への対応が既存プロセスでできているか？」といった見直しに活用することができます。
OWASP TOP 10は、3、4年に一度のペースで更新が行われており、最新バージョンは＜2021年版＞となっています。今回は、一つ前のバージョンである＜2017年版＞からの変更点を確認しながら、脆弱性トレンドを3つのポイントで読み解いていきましょう。
POINT 1. 個別の脆弱性から大きな枠組みへ観点が変化
OWASP TOP 10＜2017年版＞から＜2021年版＞にかけての最も大きな変更は、個別の脆弱性からより大きな枠組みへと観点が変化したことです。
＜2017年版＞は調査対象が30個のCWE（Common Weakness Enumeration）に限定されていたため、個別の脆弱性を中心にランキングが作成されていました。しかし、＜2021年版＞は対象数に制限を設けず調査が実施され、400個のCWEに関する報告がありました。ランキングに反映すべき脆弱性の多様化により、これまでよりも抽象度が高いカテゴリとしてまとめられるようになりました。
このように観点が変わった背景は、個別の脆弱性だけではトレンドを表現できなくなっているからでしょう。
約10年前は「Webサーバ＋RDBサーバ」構成が主流でしたが、近年は開発方法の選択肢が多く、ニーズに合わせて様々な手段を組み合わせて設計を行います。つまり、システム構築の方法・手段が多様化したことに伴い、脆弱性のバリエーションが増加したのです。
さらに考慮すべき観点も増えています。今までは実装段階やテスト段階において、アプリケーションの実装を起因とする脆弱性に対する対策をしてきましたが、それだけでは設計を起因とした脆弱性に対する対策が不十分になってしまいます。
例えば、エラー情報を全て表示する設計の場合、一般ユーザなど公開すべきでない対象にも表示してしまいます。設計通りの実装のため、実装自体に問題はありませんが、エラー情報から情報漏洩につながる可能性があります。
このように、たとえ完璧な実装であったとしても、設計を起因とした脆弱性は修正することはできないのです。そのため、これからの観点として、従来のような実装段階やテスト段階における観点だけではなく、それ以前の設計工程も含めてチェックする必要があります。
POINT 2. コンポーネントの活用に伴ったリスクの変化
＜2021年版＞では、「1位：アクセス制御の不備」、「6位：脆弱で古いコンポーネント」の2カテゴリが＜2017年版＞と比較して大きく上昇しています。システムのすべてを独自開発で実装するケースが減り、代わりに既存ライブラリやクラウドサービスを活用するケースが増えたことでリスクが変化したと考えられます。
例えば、脆弱なバージョンのライブラリを使って運用していたり、不適切な設定のまま運用していたりすると、インシデントに繋がることがあります。
過去にはAWS（Amazon Web Services）が提供するオブジェクトストレージ「Amazon Simple Storage Service」（Amazon S3）においてアクセス制御の設定ミスがあり、格納されているデータが公開状態になっていたことがありました。
IPAが公開している情報セキュリティ10大脅威2022では、クラウドの運用を含む技術者300人の内、83％が企業においてクラウドの設定ミスに関連する重大なデータ侵害に対して脆弱であることを懸念していると述べています。
また、2021年12月にはLog4Shellという脆弱性が話題になりました。 この脆弱性はLog4Jと呼ばれるライブラリが引き金となって発生したものですが、広く使われているライブラリであり、比較的攻撃が容易であったことから注目を集めました。
このようなクラウドサービスやライブラリなどのコンポーネント利用によって発生する問題は、今後も増えていくと考えられますが、問題への対応は利用者側の責務でもあります。
自分たちが実装した開発コードだけを確認するのではなく、「利用しているライブラリやクラウドサービスなどのコンポーネント設定が適切になっているか？」、「脆弱なバージョンのまま運用していないか？」、「使用しているライブラリに関する脆弱性情報が更新されていないか？」といった情報収集を行い、早期に反応できる体制づくりをすることがサービスを利用する側にも求められます。
POINT3. 構造の複雑化で増えるサーバサイドリクエストフォージェリ
先ほど個別の脆弱性から大きな枠組みへ観点が変化したと説明しましたが、＜2021年版＞で唯一、個別の脆弱性としてランクインした「サーバサイドリクエストフォージェリ」についても確認しておきましょう。
サーバサイドリクエストフォージェリとは、公開サーバを経由して内部サーバに対してアクセスできる脆弱性です。
例えば、攻撃者が内部サーバ内の機密データにアクセスしようとしても、インターネットから直接アクセスすることはできません。 そのため、まずは公開サーバに対してアクセスを行います。もし公開サーバにサーバサイドリクエストフォージェリという脆弱性が存在してしまうと、 公開サーバから内部サーバに対して意図していない不正なアクセスを飛ばすことが可能となります。内部サーバ側から見ると、このアクセスは「イントラネット内のサーバ＝信頼できるサーバ」のリクエストと判断されるため、本来外部からアクセスできないリソースやAPIに対して、攻撃者がアプローチできてしまいます。
従来はそれぞれが一台のマシンで完結する単一構成である「モノリシックアーキテクチャ」が一般的でしたが、現在はクラウドサービスやAPIがそれぞれ独立して存在し、必要な時に互いに互いを呼び合うような構成の「マイクロサービスアーキテクチャ」の採用が増えています。
複雑な構造で内部通信が発生するマイクロサービスは、サーバサイドリクエストフォージェリが発生しやすい状態になっています。そのため、個別のサービスごとに問題はなくても、複数のアプリケーション結合した際に発生する内部通信等に問題がないか、サーバ間を連結した設計観点について意識的に確認する必要があります。
日本企業の事例から見る日本の脆弱性トレンド
ここからは日本で開発されているソフトウェアの脆弱性情報をまとめているポータルサイト「JVN（Japan Vulnerability Notes）」の登録情報と、当社診断サービスにおける集計データから日本独自の脆弱性トレンドを見ていきましょう。
こちらは2018年から2021年の4年間の報告データをOWASP TOP 10のカテゴリに割り当てたJVNのグラフです。それぞれCWE-IDを基準にして紐付けています。このグラフから「アクセス制御の不備」、「インジェクション」、「不適切なセキュリティ設定」の3カテゴリが大半の割合を占めていること、また、2021年で新しい観点として「安全が確認されない不安な設計」、「サーバサイドリクエストフォージェリ」が追加されていることが分かります。
JVNでの報告データ（2018-2021）
次に、当社の診断情報から見ていきましょう。こちらは、先ほどのJVNと大体同じような形であるものの、違いとして「脆弱で古いコンポーネント」というカテゴリがあり、まだ脆弱なコンポーネントを使用して運用しているアプリケーションがあるということがこのグラフから分かります。
弊社診断データの集計（直近1年）
脆弱性トレンドへの効率的で効果的な対応とは
日本で多くみられる「アクセス制御の不備」、「インジェクション」、「安全が確認されない不安な設計」、「不適切なセキュリティ設計」といった脆弱性に、どのように対応して行くべきなのでしょうか？
「インジェクション」や「不適切なセキュリティ設定」は、昔から注目されている脆弱性で全体の54％を占めるコモディティ領域、「アクセス制御の不備」、「安全が確認されない不安な設計」はトレンドを受けて増えつつある変化領域と言えます。
コモディティ領域については、昔から注目され今も検知される脆弱性であるため、既にチェックプロセスが存在します。残る課題は「どのように数を捌くか」という点ですが、脆弱性診断・セキュリティ診断ツールである「Vex」やセキュリティテスティングツールである「komabato」など、診断を内製化・効率化できるツールを使うことで効率化を図ることが可能です。
コモディティ領域のツール活用による効率化で生まれた時間を使って、新しく対応が必要な変化領域のスキルやプロセス構築に着手していきましょう。こちらは、まだチェックプロセスが整っていないことが多いため、人間の目と手を使って実際に確認しながら対応を徐々に進める必要があります。また、確認する人のスキルが必要になるため、必要に応じてプロによるサービスの利用も検討することをオススメします。
以上で見てきた通り、セキュリティのトレンドは開発手法の変化によって生まれています。
今後、開発手法がどう変わっていくかをチェックしながら、従来の脆弱性と合わせて幅広い観点での対応を行っていけるよう、ツールや外部サービス、トレンド情報を活用しながらセキュアなアプリケーション開発を目指して行きましょう。
