DevSecOpsにより開発コスト削減&利用者が安心できるセキュリティ品質を実現

開発工程において、脆弱性が発見されるタイミングが下流になればなるほど、手戻りは多くなり、コストも増加してしまいます。
そこで要件定義~設計、実装、運用まで、すべての開発工程(DevOps)にセキュリティプロセス(Sec)を組み込むことで、下流工程にたどり着くまでに脆弱性を発見し、システムのセキュリティ品質を担保する「DevSecOps」というモデルがあります。

DevSecOpsによって「手戻り減によるコスト削減」と「利用者が安心できるセキュリティ品質」を両立するには、各工程で適切なセキュリティプロセスを実施しなければなりません。

image1

まず、上手右側の手戻りを軽減するためのセキュリティプロセスで重要なポイントとなるのは、「下流工程にたどり着くまでに、脆弱性をつくりこまない施策をいくつ打てるか」という点です。そのために「要件定義や設計時にセキュリティベンダーからレビューを受ける」「ガイドラインに準拠した設計をする」「コーディング時にソースコードレベルのセキュリティテストを組み込む」などの施策を行うことで、脆弱性をつぶしながら実装することが可能になります。

一方、上図左側の下流工程のセキュリティプロセスで重要なポイントとなるのは、「最終的にリリースされたもののセキュリティの品質が担保できているか」という点です。DevSecOpsというと「開発工程にセキュリティ工程を組み込むこと」をイメージしがちですが、実際には開発工程だけではなく、第三者が実際に触れる環境に対して行うセキュリティチェックも含まれます。こちらは「上流工程で実施した施策が正しく適用できているか」といった監査的な側面からのチェックや、「攻撃者と同じ目線でのセキュリティテストを実施する」ことで利用者にシステムの安全性を提供することができます。

セキュリティ品質を確認するために、攻撃者と同じ目線でテストができるDAST

本記事では、攻撃者と同じ目線でセキュリティテストを実施するための「DAST」という手法について解説していきます。

一般的にセキュリティテストの手法には「SAST」「IAST」「DAST」の3種類があり、それぞれ異なる特徴を持っているため、DevSecOpsの工程ごとに適切な手法を選択する必要があります。

image2

SASTはソースコードを解析して脆弱性をチェックするもので、アプリケーションが動作していなくてもソースコードに対して素早くセキュリティテストができるので開発工程に組み込みやすい手法です。
次に、IASTはアプリケーション動作環境にインストールしたエージェントが、データの流れを監視して脆弱性をチェックするものです。動作テストと同時にセキュリティテストできるのが特徴です。(※IASTの仕組みや導入メリットについては「セキュアアプリケーション開発を高速化させるContrast Assessを選ぶ理由」をご参照ください)
SAST、IASTは開発工程に組み込むことで早期に脆弱性を発見して潰しこみができるので、手戻りが少なくなり、全体的な修正コストを削減する効果が期待できます。

一方でDASTは、アプリケーションが動作するサーバーに疑似攻撃リクエストを送り、返ってきたレスポンスを見て脆弱性をチェックします。アプリケーションの利用者と同じ環境に、攻撃者と同じ視点でセキュリティテストを実施できるため、セキュリティ品質の担保や最終的な品質監査にも有効な手段として利用できます。

DASTツールの活用には、運用ルールの整備が重要なポイントに

DASTツールは、「検査パターンの網羅性」「開発言語の制限がないこと」などの特長を持ち、誰が操作しても品質にバラつきなく同じようにテストが行えます。一度設定すれば何度でも再利用できるため、効率的にセキュリティ品質を担保することができます。そして、DASTツールの効果を最大限に享受するためには、検査結果をどのように扱うかが重要なポイントです。
セキュリティテストを実施するためのルールと、テスト結果を受けての脆弱性改修ルールなど、実施~実施後のルールを定め、DASTツールを効果的に使っていきましょう。

image3

ルールについては、「誰がどんな体制で」「いつ、どのタイミングで」「どんなアプリに対して」テストを実施するのかを決めます。

誰がどんな体制で 多くの場合は会社のセキュリティ部門や外部のセキュリティベンダーに依頼。
最近は開発者自身がチェックをすることも。
いつ、どのタイミングで リリース前や機能追加を行うタイミングでの実施は必須。
日々進化する脆弱性に対応するため定期的な実施を推奨。
どんなアプリに対して 外部向けアプリケーション
内部向けアプリケーション

次に脆弱性が見つかった後の改修ルールを「何を」「いつ」直すのか、「どうやって確認するか」についてもポリシーを定めておきます。

多くの企業では「外部向けアプリケーションは対応するが、内部向けは対応しない」「危険度:高~中はすぐに改修するが、危険度が低いものは次のリリースまでに直せば良し」と定められていることが多いですが、内部向けであるがゆえに重要なデータを保持していたり、危険度が低くてもリスクがあったりするので、定期的なテスト実施~脆弱性改修を行うことをおススメしています。(※内製診断のメリットやポイントについては、「セキュリティ診断を内製化してみよう!~外部診断サービスとの比較や診断体制づくりの方法を具体的に解説します~」をご参照ください)

強力なテストシナリオ再現能力と分かりやすいレポート、純国産のDASTツール「Vex」

最後に当社の提供するDASTツール「Vex」について説明いたします。
「Vex」は、正確な検査と脆弱性検出において最大のポイントとなる強力なテストシナリオの再現能力が特徴で、診断対象アプリケーションの性質や診断実施者のスキルに合わせて最適なシナリオが作成できるWebアプリケーション脆弱性検査ツールです。
ユービーセキュアの診断サービスチームをはじめ、各セキュリティベンダーや国内大手企業でもご利用いただいており、数千サイトにおよぶ診断結果をフィードバックしながら進化を続けている、脆弱性診断のためのプロツールです。
検出性・網羅性が高いだけではなく、純国産ツールならではの「読みやすい日本語」によるレポート機能があり、エグゼクティブ、テクニカル、担当者それぞれの目的に合わせたレポートの出力も可能です。ぜひご検討いただけましたら幸いです。

新規CTA