安全な開発プロセスを支えるアプリケーションセキュリティポリシーの策定

アプリケーションセキュリティポリシーとは？

アプリケーションセキュリティポリシーは、新しいソフトウェアを開発する際に、開発者とセキュリティチームが業務を進められるセキュリティと保護の許容範囲を定めます。多くの場合、ポリシー機能を備えたアプリケーションセキュリティソリューションを活用します。ソフトウェアセキュリティポリシーによって作業開始前に一貫して自動的に境界が設定されると、効率的なアプリケーション開発プロセスに不可欠な情報を得られます。

すべての組織に適合するアプリケーションセキュリティポリシーはありません。AppSecポリシーは、組織の規模やビジネスモデルに合わせる必要があります。そのため、確立されたアプリケーションセキュリティのベストプラクティスに従いながら、脆弱性保護の適切なレベルを設定し、使用するサードパーティ製アプリケーションやオープンソースコンポーネントを決める、効果的なポリシーを策定する必要があります。組織の方針に加え、OWASP Top 10などの標準にも十分に準拠しなければなりません。

こうした点をすべて考慮しても、保護とパフォーマンスのバランスを効果的に取るAppSecポリシーの策定は容易ではありません。ここで紹介する情報を参考に、脆弱性を減らしながら、開発者が革新的なソフトウェアを継続してリリースできるエンタープライズセキュリティポリシーを策定しましょう。

アプリケーションセキュリティポリシーが重要な理由

ソフトウェア開発は変化しました。迅速なデプロイが標準となり、多くのDevOpsチームがプロジェクトを支えるためにオープンソースコードを活用しています。こうした新しいデプロイ環境は、主に企業、特に大企業におけるCI/CDプロセスの導入によって発展してきました。

このスピードの速いエンタープライズ環境では、単純な設定ミスから脆弱性が発生することもあります。Snykのクラウドネイティブアプリケーションセキュリティの現状レポートによると、セキュリティインシデントの主な原因は、設定ミス（45%）と既知の未修正脆弱性（38%）でした。

Snykの「State of Cloud Native」レポートに掲載された、種類別のセキュリティインシデント。

ある最近の調査では、分析対象となった85,000件のアプリケーションのうち、83%に少なくとも1つのセキュリティ上の欠陥があり、そのうち20%には深刻な脆弱性が見つかりました。これらすべてが重大なセキュリティリスクとなるわけではありませんが、ハッカーは巧妙な回避策を用いてソフトウェアに侵入しようと、攻撃を進化させ続けています。

アプリケーションセキュリティポリシーは、脆弱性の防止に役立つ境界を定めます。

脆弱性がもたらすコスト

2017年、EquifaxはJava Apache Strutsライブラリの古いバージョンを使用していたため、システムへの侵入を許しました。この悪名高いハッキングにより1億4,300万人の個人情報が流出し、集団訴訟に発展。Equifaxは3億8,050万ドルで和解しました。

Equifaxは脆弱性の悪用がもたらす極端な事例ですが、どのようなセキュリティ侵害にもビジネスへの悪影響があります。深刻なセキュリティインシデントから立ち直れない企業も少なくありません。そのため、特に金融機関、政府機関、医療機関など、極めて機密性の高いデータを扱う企業にとって、アプリケーションセキュリティポリシーは不可欠です。

アプリケーションセキュリティポリシーを策定することで、企業はソフトウェア開発ライフサイクル（SDLC）のあらゆる段階で、開発者が脆弱性に先手を打って対処する方法を定めるAppSecプログラムの構築に着手できます。ただし、慎重に検討し、プロセスに組み込まなければ、アプリケーションセキュリティポリシーが不満の原因となることもあります。

AppSecポリシーに「コードとしてのコンプライアンス」を取り入れる

企業は開発期間の短縮とビジネスの俊敏性向上のためにDevOpsの実践を取り入れます。AppSecプログラムも、保護とパフォーマンスのバランスを取るアプリケーションセキュリティポリシーを策定し、開発のペースを維持することで、こうした目標を支援する必要があります。

効果のないアプリケーションセキュリティポリシーは、開発者に貴重な時間を費やしてコードを書き直させ、セキュリティチームにはアラート、通知、修正チケットを大量に発生させます。こうしたポリシーは、最終的に開発を遅らせ、企業をより大きなリスクにさらします。一方、効果的なアプリケーションセキュリティプログラムは、DevOpsのワークフローを妨げずに導入でき、開発者の力を引き出します。ソフトウェア開発ライフサイクル（SDLC）にコード化されたポリシーを組み込み、継続的な開発を支えるのが、こうした効果的なフレームワークです。

コードとしてのコンプライアンスとは？

コードとしてのコンプライアンス（またはコードとしてのポリシー）は、DevOpsに組み込まれた効果的なツールでセキュリティプロセスを自動化し、手作業で時間のかかる手順をなくして人的ミスの可能性を最小限に抑えます。アプリケーションセキュリティポリシーに基づくこれらの自動化セキュリティツールは、開発プロセスに組み込まれます。

たとえばビルドプロセスでは、開発者は自動スキャンツールを使って既知の脆弱性を特定し、デプロイ前に修正できます。デプロイ後は、自動監視ツールが本番環境で新たに検出されたリスクをAppSecチームに通知します。コードとしてのコンプライアンスを実践するには、アプリケーションセキュリティポリシーで、導入するツールと修正が必要な脆弱性やリスクの種類を定義する必要があります。

コードとしてのコンプライアンス、またはテスト駆動型コンプライアンスのポリシーは、Googleのような大規模なソフトウェア主導型企業で採用され、より自然なビルドプロセスを支え、安全なビジネス環境でイノベーションを継続できるようにしています。これらのプロセスにより、次のことが実現します。

• 標準化されたレポートと透明性

• 失敗の理由の説明

• 統制テストの独立性

• CI/CDプロセスとの容易な統合

効果的なアプリケーションセキュリティポリシーを構成する7つの要素

すべての企業に適したポリシーはありませんが、セキュリティに必要なツール、管理策、システムをAppSecポリシーで明確に定義することが重要です。こうすることで、テクノロジーとプロセスの両面にセキュリティを適用し、両者をシームレスに結び付けられます。

効果的なアプリケーションセキュリティポリシーを策定するには、次の要素にも取り組む必要があります。

• 脅威の履歴 - テクノロジースタックで最も大きな影響をもたらした脅威や脆弱性を特定します。これを基準として、ポリシーに含める内容を決めます。

• 脆弱性の優先順位付け - ポリシーでは、高・中・低のリスクを判断する基準を定めます。これにより、対処すべき脆弱性と、検討事項として記録すべき脆弱性を判断できます。

• 修正と緩和 - 脆弱性の優先順位付けと密接に関連しますが、より具体的な内容です。修正が必要な脆弱性は誰が判断するのでしょうか。開発プロセスのどの段階で修正すべきでしょうか。許容できるリスクはあるでしょうか。

• プロセス - アプリケーションコードにセキュリティを適用する手順を、アプリケーションセキュリティポリシーで定義します。たとえば、ビジネスでSASTとDASTを適用するかどうかを決めます。

• 役割と責任 - SDLCのどの段階で、誰がアプリケーションセキュリティの確保に責任を持つのかをポリシーで定義します。

• ツール固有の要件 - 多くの企業がセキュリティ自動化ツールを使用しています。SDLCのどの段階でどのツールを使用するかをポリシーで定義します。

• 監視 - アプリケーションの脆弱性は、コードが本番環境にデプロイされた後に発見され、悪用されることが少なくありません。効果的なポリシーでは、デプロイ済みアプリケーションの監視方法を定め、前述の優先順位に基づいて是正措置を決定します。

効果的なポリシーが、効果的な開発を実現

明確なアプリケーションセキュリティポリシーは、AppSecチームと開発者の双方が、ソフトウェアとプロセスへの信頼を確保するために必要なツールと境界を定めるフレームワークとなります。強固なアプリケーションセキュリティは、後付けの対策や付け足しのツールではありません。組織の開発スピードを維持し、顧客の信頼を高める、十分に練られたプロセスです。アプリケーションセキュリティポリシーは、効果的なコードを組織としてどのように開発するかを定義します。