Webセキュリティはどこから手をつければよいのか?
yamory セキュリティエンジニアの佐々木です。
今回は、セミナーでお話する方、またyamoryをご利用されているお客様より「Webセキュリティはどこから手をつければよいのか?」というご質問をいただくことがあり、その問いにお答えしたいと思います。
この記事を通じて、Webアプリケーションセキュリティを向上させる一助になれば幸いです。
Webアプリケーションのセキュリティを高める手法
少し遠回りしますが、Webアプリケーションのセキュリティを高める手法の全体像を整理したいと思います。
Webアプリケーションにおけるセキュリティテストの種類
Webアプリケーションのセキュリティをテストする手法は、テストの視点・テスト対象の状態によって大きく2種類に分けることができます。
ブラックボックステスト
攻撃者の視点で、動いている状態のWebアプリケーションにテストする手法
ホワイトボックステスト
開発者の視点で、ソースコードなど、アプリケーションの問題点を検査する手法
※上記以外に、両方を組み合わせたグレーボックステストという手法も存在します。
手法 |
テストの対象 |
目的 |
|
---|---|---|---|
ブラックボックス |
脆弱性診断、動的アプリケーションセキュリティテスト(DAST / Dynamic Application Security Testing) |
OSやミドルウェア、アプリケーション |
Webアプリケーションに到達可能な脆弱性やセキュリティ実装不備がないことを確認する |
ペネトレーションテスト |
ネットワーク、運用体制を含めたシステム全体 |
情報資産が攻撃を受けるかどうか、対処可能かどうかを確認する |
|
ホワイトボックス |
ソフトウェアコンポジション解析(SCA / Software Composition Analysis) |
アプリケーションを構成しているOSSの脆弱性 |
利用しているOSSに脆弱性がないかを確認する |
静的アプリケーションセキュリティテスト(SAST / Static Application Security Testing) |
開発者が自ら実装したコード |
開発者の実装にセキュリティ上の問題点がないかを確認する |
脆弱性診断、動的アプリケーションセキュリティテスト(DAST / Dynamic Application Security Testing)
多くの方が脆弱性を検出する方法として利用されているかと思います。
脆弱性診断では、Webアプリケーションに脅威となる擬似攻撃の実施、既知の脆弱性を行い、攻撃・悪用できる脆弱性、情報漏洩に繋がる恐れのある問題点(ロジック)を見つけることができます。
メリット
- 緊急度の高い脆弱性を洗い出せる
- (診断サービスなどを利用すれば)セキュリティの知見がなくてもテスト可能
- 網羅的
デメリット
- 診断自体に時間がかかる
- 問題箇所を特定しなければならず、修正が難しい場合がある
- アプリケーションが動いていなければならず、脆弱性の作り込みから修正までの時間が長い
ソフトウェアコンポジション解析(SCA / Software Composition Analysis)
近年OSSのエコノミーが急拡大(50%以上)していることを受け、数年前から出てきたツールです。
SCAは、Webアプリケーションが使用しているOSSの一覧を可視化し、脆弱性が存在するOSSを見つけることができます。
他の手法との大きな違いとして、SCAは突発的に公表される脆弱性がアプリケーションに組み込まれているかどうかを知ることができます。
メリット
- ソースコードの提示やアプリケーションを動かさなくて済むので、簡単に検査可能
- ほぼ全ての開発フェーズで検査できるため、脆弱性の組み込みを早い段階で防げる
- すでに組み込まれたOSSの脆弱性を把握することができる
- OSSの脆弱性を網羅的に検知できる
デメリット
- フレームワークなどのOSSが使用しているOSSも検知するため、検知量が膨大
- 開発者が実装した部分を検知できない
静的アプリケーションセキュリティテスト(SAST / Static Application Security Testing)
IDEのプラグインや専用のサーバにてソースコードを分析し、SQL Injectionやバッファオーバーフローに繋がるコードを見つけることができます。
実装から脆弱性の発見までサイクルが短く、開発者にとって使用しやすいツールだと思います。
メリット
- 脆弱性の作り込みから発見までのサイクルが短い
- 修正が容易
デメリット
- 誤検知が多い
- 開発者が実装する部分のみの検査
- 実際に脆弱性となるかの判断が必要
yamoryとしてのベストプラクティス
DAST vs SCA vs SAST
一長一短ある各セキュリティ対策ですが、それぞれの得意な範囲、各検査が網羅しているサイクルをまとめると以下の図のようになります。
それぞれ得意分野は大きく異なるため、包括的にセキュリティレベルを向上させるためには、特徴を理解した上で組み合わせて利用する必要があります。
何からはじめれば良いか?まずは脆弱性診断、その次にSCA
包括的にセキュリティレベルを上げることができていると考えても、コスト・運用負荷まで考慮すると、すべてを入れることはできないのが現状ではないでしょうか。
そこで、冒頭のご質問に対する見解として、yamoryが考えるお勧めの導入順序を紹介します。
1. 脆弱性診断、動的アプリケーションセキュリティテスト(DAST / Dynamic Application Security Testing)
一番目に実施すべきは脆弱性診断/DASTです。
脆弱性診断/DASTでは、実際に外部に公開した場合に攻撃される可能性のある脆弱性がピックアップされます。
そのため、リリース前、定期的に実施しましょう。
なお、脆弱性診断はツールを用いて自動的に行うこともできますが、誤検知や設定など運用負荷が高いことから、脆弱性診断サービスを利用することをお勧めします。
ツールよりもはるかに精緻な診断結果を得ることもできますし、報告会などを通じて不明点・心配なことを相談することもできます。
2. ソフトウェア コンポジション解析(SCA / Software Composition Analysis)
二番目に実施することをお勧めするSCAは、アプリケーションの約90%を占めるOSSの脆弱性を見つけることができます。
以前「なぜ、オープンソースの脆弱性管理と対策が重要なのか」でもご紹介した通り、OSSの脆弱性は、以下の特徴を持つことから、いつ攻撃可能な脆弱性が見つかるかわかりません。
「利用しているOSSに攻撃できる脆弱性が見つかるかも!」と心配しないために、本来は毎日脆弱性があるかどうかを確認しなければなりません。
その運用負荷はとても高く、脆弱性診断/DASTで日々確認することはほぼ不可能だと思います。
そのため、これを自動的に行ってくれるSCAを二番目に導入することをお勧めします。
ここまで実施すれば、セキュリティの安全性はおおむね維持できると思います。
- 突発的に公開される
- コードが公開されている特性上、攻撃が始まるまでの時間が短い
以上のことが特徴として挙げられます。
3. 静的アプリケーションセキュリティテスト(SAST / Static Application Security Testing)
最後に導入をお勧めするSASTは、開発者が危ない脆弱性を作り込みする可能性を教えてくれるなど、潜在的なセキュリティリスクを低減させるために有用です。
また、ソフトウェア開発ライフサイクル(SDLC / Software Development Life Cycle)の早いタイミングで脆弱性を発見できるため、開発者の負担軽減に繋がると思います。
SASTを最後にご紹介したのは、誤検知や表出しない脆弱性への対応が増え、優先度付けが困難と想定されるためです。
最後に
なかなかセキュリティ対策の優先度を決めることが難しいと思いますが、もしこの記事が少しでも参考になったならとても嬉しいです。
今後も適切なセキュリティレベルを決める参考情報、また最も大事なセキュアコーティングやセキュリティ観点でのレビューなども取り上げたいと思います。
最後になりますが、yamoryは上記のSCAに該当するツールです。
無料でも使えるのでSCAの理解を深めるために、是非試してみてください。