HCL Software ではコラボレーション領域に限らずさまざまな製品やサービスを手がけています。今回は、アプリケーションのセキュリティーを確保するための AppScan に関するブログ記事です。
これに関連して、動的アプリケーションテスト (DAST) についての Webinar のご案内です。
How to Optimize DAST for Your DevOps Program
アプリケーション・セキュリティー・プログラムにおける速度とセキュリティーのバランスの取り方
原題: How to Balance Speed and Security in Your Application Security Program
Joseph Coletta / September 30, 2019
今日の進化し続けるデジタル信頼の世界では、DevOpsという用語は速度と同義語になっています。競争したい場合は、高品質のコードを迅速に構築する必要があります。しかし、企業が革新できるようになるとすぐに、悪者は脆弱なアプリケーションを悪用する新しい方法を絶えず開発してきます。
そのことを念頭に置いて、ビジネス・リーダーとセキュリティー・マネージャーは、市場投入までの速度を維持を実現するために、ソフトウェア開発ライフサイクル（SDLC）を統合管理できるアプリケーション・セキュリティー・ソリューションを必要としています。ただし、セキュリティーと速度の間には微妙なバランスがあります。目標とリスクを理解し、開発者が担当範囲をリードしていけるように支援していくことこそ、そのバランスを実現する取り組みになります。
アプリケーションのセキュリティー目標を理解する
規制要件を満たすために単にボックにチェックを入れることを優先する場合は、コンプライアンス準拠が必ずしもセキュリティー確保となるとは限らないことをしっかり認識、考慮しておく必要があります。コンプライアンスを達成することは短期間だったり簡単な作業ではありません。しかし、安全なソフトウェアを作成して、ソフトウェアへの攻撃・侵害を防ぐことが目標であれば、コンプライアンスだけにとどまらないようにする必要があります。
ほとんどの規制要件は「幅広いブラシ」で描かれており、アプリケーションのニュアンスまでは考慮されていません。コンプライアンスは、アプリケーション開発のペースが非常に速いことを考えると、すぐに無関係になるかもしれないある要件セットをチェックするための「ある時点での」努力といえるでしょう。ですので、まずは開発パイプライン全体でセキュリティーを確立することが、安全なコードを時間通りに提供するために不可欠です。セキュリティーが最初からアプリケーションのDNAに組み込まれていれば、コンプライアンスへの対応が容易になります。さらに、自社のビジネス・ニーズに基づいてセキュリティー・ポリシーを確立することで、他のビジネス市場のニーズに巻き込まれずに済みます。
バランスのとれたアプリケーション・セキュリティー・プログラムができること
ある特定の種類のアプリケーション・テストのみがアジャイルやDevOps方法論が要求する速度を満たせる、という誤解があります。このため、多くの組織では、納期を満たすであろうと見込んだアプリケーション・テスト・ソリューションの種類を利用することになります。 アプリポートフォリオ全体にエンド・ツー・エンドのセキュリティー・カバレッジを提供できる「魔法の弾丸」は存在するわけがありません。動的分析が安全でないデータ・フローについてテストできないように、静的分析は壊れている認証機構についてテストできません。完全に成熟したアプリケーション・セキュリティー・プログラムを実現するには、さまざまなテクノロジーをテストおよび活用するバランスの取れたアプローチが必要になってきます。
幸いなことに、アプリケーション・セキュリティーテクノロジーは過去10年間で飛躍的に進歩し、業界の残りの部分に移りつつあります。静的分析は開発ライフサイクルの初期段階で統合でき、動的分析はQAテストや、特定のコード変更のみをチェックする機能テストにも適用できます。時間をかけてリスク許容度を理解し、適切な技術の組み合わせを採用することで、品質の高い安全なコードを予定通りに納品できるようになります。
開発者がセキュリティー標準に準拠したコードを作り出すようにするために
セキュリティーと速度のバランスをとることの微妙な点のひとつは、セキュリティー上の欠陥をすばやく見つけて迅速に修正できるようにすることです。失敗から学ぶために、失敗する方法を教えてくれた高校のコーチや教師がいたかもしれません。セキュリティーにも同じことが当てはまります。
実際のセキュリティー脆弱性を早期に認識し、本番環境にプッシュされる前に修正するためのアクション・プランを用意することが重要です。このアプローチの主要なコンポーネントは、徹底したセキュリティー・トレーニング・カリキュラムに支えられた開発チームであり、独自の手で修復を行う権限を与えられています。手始めに、SQLインジェクションやクロスサイト・スクリプティング（XSS）など、アプリケーション全体で最も一般的に繰り返し発生するセキュリティー上の欠陥を考慮し、適切なトレーニング・カリキュラムを開発して、それらの欠陥を発見、修正する方法について開発者を教育します。
さまざまな種類の脆弱性と、アプリケーションの設計におけるそれらのコンテキストに時間をかけて理解してください。当然、重大度の高い欠陥には対処する必要がありますが、攻撃者がそれらを悪用できるかどうかも検討する必要があります。これは重大な脆弱性なのか。関数はアプリケーションの呼び出しパス内にあるのか。重大度が中程度の脆弱性が多数あると、たったひとつの重大度の高い脆弱性よりも悪用されるリスクが高くなります。
すべてのアプリが「均等に」作成されるわけではない
すべてのアプリケーションが同じように作成されるわけではありません。なぜなら、すべてのアプリケーションについて同じレベルのリスクが課せられているわけではないからです。限られたリソースのなかで、数あるアプリケーションすべてについてリスクを管理し優先順位を付ける方法が必要です。
残念ながら、私たちは完璧な世界に住んでいません。ただし、アプリケーションの状況を把握し、適切なテクノロジーを適切な場所に適用し、開発者が安全なコーディング手法の実際を完全に身につけることで、速度とセキュリティーのバランスがうまく取れるようになります。 このようなアプリケーション・セキュリティー・コンテンツについては、ブログを購読して、Twitter、YouTube、LinkedIn、BrightTALK でフォローしてみてください。