7 Application Security Best Practices 2022

AppSecが重要な理由

組織にデプロイされたアプリケーションは、デジタル攻撃対象領域の大部分を占めています。 一般向けのアプリケーションは、社内で開発されたものかサードパーティによって開発されたものかにかかわらず、機密情報を盗んだり、マルウェアを展開したり、組織に対してその他のアクションを実行したりするために悪用される可能性があります。

AppSecは、組織のアプリケーションがもたらすリスクをライフサイクル全体にわたって管理できるようにするため、重要です。 AppSecは、開発のベスト・プラクティスと安全なアプリケーション構成、デプロイメント、管理を組み込んで、組織のアプリケーションに存在する脆弱性の数を減らし、攻撃者がこれらの脆弱性を悪用するのを防ぎます。

アプリケーションセキュリティのベストプラクティス

効果的なアプリケーションセキュリティプログラムは、アプリケーションがライフサイクル全体を通じて直面する潜在的なリスクと脅威に対処します。

アプリケーションセキュリティのベストプラクティスには、次のようなものがあります。

#1.脅威評価から始める

アプリケーションは、さまざまな脅威に対して脆弱である可能性があります。 アプリケーションがさらされる可能性のある潜在的な攻撃を理解することは、修復アクションに適切な優先順位を付けるために不可欠です。

脅威評価は、組織にとって最も可能性の高い脅威、その潜在的な影響、および組織がすでに導入しているセキュリティソリューションを特定するための優れた方法です。 この情報を使用して、組織はこれらの潜在的なリスクと脅威に対処するための戦略を策定できます。

#2.DevSecOpsのベストプラクティスの実装

DevSecOps( Shift Security Left )の動きは、ソフトウェア開発ライフサイクル(SDLC)の早い段階でセキュリティを統合することに焦点を当てています。 セキュリティをSDLCのテストフェーズに委ねる代わりに、 DevSecOps には次のものが含まれます。

• セキュリティ要件の定義: SDLC の要件段階では、開発チームはアプリケーションに含める必要のあるさまざまな機能を定義します。 これには、機能とパフォーマンスの要件に加えて、実施する必要があるセキュリティ制御と、コードで軽減する必要がある潜在的な脆弱性を概説するセキュリティ要件も含める必要があります。
• テストケースの作成: 開発者は通常、定義された要件へのアプリケーションの準拠を評価するテストケースを作成します。 セキュリティ要件が作成されたら、チームはテスト ケースを作成して、それらが適切に実装されていることを検証できます。
• テストの自動化: 可能な場合は自動化することが、DevOps と DevSecOps の中核となる原則の 1 つです。 セキュリティ・テスト・ケースと、静的アプリケーション・セキュリティ・テスト(SAST)、動的アプリケーション・セキュリティ・テスト(DAST)、インタラクティブ・アプリケーション・セキュリティ・テスト(IAST)などのアプリケーション・セキュリティ・ツールの使用の両方を含むセキュリティ ・テスト を自動化することで、摩擦を減らし、SDLC中に セキュリティ が実際に実行されるようにすることができます。

脆弱性は本番コードでは一般的であり、その主な理由の1つは、開発プロセス中にセキュリティが過小評価されていることです。 DevSecOps の原則を実装することで、これに対処し、組織のアプリケーションに対するリスクを軽減できます。

#3.権限の管理

特権アクセス管理 (PAM) は、開発プロセス中に不可欠です。 組織の開発環境にアクセスできる攻撃者は、次の可能性があります。

• 機密情報を含むアクセスポリシーとプロセスドキュメント。
• アプリケーション コードを変更して、脆弱性、エラー、または悪意のあるコードを導入します。
• テストケースとテストコードを変更して、セキュリティギャップを生じさせます。
• 自動セキュリティー・テストーを無効化します。
• セキュリティツールの設定を変更します。

これらのイベントはいずれも、組織のデータとアプリケーションのセキュリティに悪影響を与える可能性があります。 最小特権の原則に基づいて強力なアクセス制御を実装し、多要素認証 (MFA) を使用した強力な認証によってサポートすることで、攻撃者が開発環境にアクセスできるリスクと、そのアクセスによって得られる損害を軽減できます。

#4.ソフトウェアサプライチェーンの監視

すべてではないにしても、ほとんどのアプリケーションは、特定の機能を実装するために外部ライブラリとコンポーネントに依存しています。 ゼロからコードを記述すると時間がかかり、パフォーマンスと安全性が低下する可能性があるため、安全なコードの再利用が一般的な開発のベスト プラクティスです。 しかし、ソフトウェアサプライチェーンはますます攻撃の標的になっています。 サイバー脅威アクターは、広く使用されているライブラリの脆弱性を標的にしたり、これらのライブラリ自体に脆弱性や悪意のあるコードを挿入したりする可能性があります。

ソフトウェアサプライチェーン管理は、強力なアプリケーションセキュリティに不可欠です。 ソフトウェア・コンポジション解析(SCA)ソリューションは、アプリケーション内で使用されるライブラリやサードパーティ・コードを特定することで、サプライチェーンのリスク管理に役立ちます。 このリストを使用して、開発チームは既知の脆弱性を特定して修正し、古いコンポーネントに更新プログラムを適用できます。

#5.自動化とAIの活用

開発チームとセキュリティチームは、通常、広範囲にわたる責任と厳しいスケジュールを背負っています。 多くの場合、開発プロセスでは、リリース期限に間に合わせるために時間とリソースが必要になる可能性があるため、セキュリティが過小評価されています。

人工知能 (AI) とセキュリティの自動化は、開発プロセスにおける セキュリティの リソース要件を軽減するのに役立ちます。 AIは、アラートとログファイルの解析を支援し、誤検知を最小限に抑えながら、開発者やセキュリティ担当者に注意を喚起します。 セキュリティの自動化により、テストが開発者やリリース タイムラインに与えるオーバーヘッドと影響を最小限に抑えながら、テストを確実に実行できます。

#6.修復の優先順位付け

本番アプリケーションの脆弱性の数は膨大で、圧倒される可能性があります。 ほとんどの場合、組織には、展開されたソフトウェア内のすべての脆弱性を修正するためのリソースが不足しています。 その結果、企業は脆弱性管理に追いつこうとしているのに遅れをとっています。

効果的な脆弱性管理には、適切な優先順位付けが不可欠です。 悪用可能な脆弱性はごく一部です。 サイバー脅威アクターによって積極的に悪用されるのは、さらに少数です。 アクティブなエクスプロイトを伴うこれらの脆弱性は、組織に非常に異なるレベルのリスクをもたらす可能性があります。

セキュリティテストプロセスでは、自動化ツールを使用して脆弱性を特定するだけでなく、その深刻度と悪用可能性を追跡する必要があります。 これらの自動化された指標は、必要に応じて自動分析によってバックアップされ、組織にとって真の脅威となる脆弱性を特定するために使用できます。 これに基づいて、チームは、脆弱性管理に費やされた時間とリソースが組織に真の価値と大きな投資収益率 (ROI) をもたらすことを保証する修復戦略を開発できます。

#7.AppSecの結果の追跡

ビジネスが行うすべてのことと同様に、アプリケーションセキュリティには時間とリソースがかかります。 しかし、アプリケーションセキュリティのサクセスストーリーは、組織にとって損害と費用のかかるサイバーセキュリティインシデントにつながる脆弱性をクローズすることであるため、アプリケーションセキュリティのメリットとROIを理解するのは難しい場合があります。

ネガティブなことを証明することは難しいため、アプリケーション・セキュリティ・プログラムの価値を実証するには、プログラムが明確で測定可能な違いを生み出しているメトリックを特定して追跡する必要があります。

たとえば、次のようなものがあります。

• 開発中に検出された脆弱性の数。
• 本番アプリケーションで検出された脆弱性の数。
• 脆弱性の悪用によるセキュリティインシデントの数。
• 内部AppSecポリシーの違反の数。
• 企業および規制のコンプライアンス要件の違反の数。

理想的には、AppSecプログラムによって、安全な開発プラクティスとAppSecポリシーが開発チームに根付くにつれて、これらの指標がすべて時間の経過とともに低下します。 しかし、セキュリティインシデントの一部として、開発中から本番環境で検出される脆弱性から移行したとしても、脆弱性が組織にもたらすコストと損害を削減できるため、成功です。