溝を埋める: 柔軟性とセキュリティ

2 つのものが必要なのに、その 2 つが相互に排他的であることが「誰もが知っている」場合はどうすればよいでしょうか。

ネットワークとセキュリティのコミュニティには、安全なソフトウェア アーキテクチャは柔軟性に欠け、アジャイルで提供されるソフトウェアは安全性が低いという長年の誤解があります。  しかし、ちょっと待ってください。反復モデルを使用して開発されたソフトウェアは本質的に安全性が低いということを裏付ける証拠はあるのでしょうか? もしあるなら、私の「研究」（読み： グーグルで検索しても、実際には見つかりません。   

実際、配信サイクルの高速化と自動化および合理化されたリリース プロセスにより、全体的な脆弱性露出時間が短縮され、リスクが軽減されるという説得力のある主張をすることができます。    

では、柔軟性とセキュリティの間には本当に隔たりがあるのでしょうか? 悲しいことに、私はまだ「はい、あります」と言います。 

ただし、アジャイル ソフトウェア ライフサイクルによって、固有のコード脆弱性がさらに導入されるとは考えられません (ただし、コンテナー管理システムなどの新しいプラットフォームの一部では、攻撃を受ける新しい領域が確実に導入されます)。アプリケーション コードは、組織の全体的なセキュリティ体制の一部にすぎないためです。

すべてのソフトウェアには欠陥があることを認識し、IT テクノロジー スタックには、ネットワーク ファイアウォール、侵入検知システム、Web アプリケーション ファイアウォールなど、アプリケーション コードの外部のセキュリティ制御も含まれます。 これらのシステムの多くは、アプリケーションの動作を追跡し、フレームワークやオペレーティング システムで新たに発見された脅威に対応する必要があります。 理想的には、これらのシステムはソフトウェア配信ライフサイクルと同じくらい俊敏である必要があります。 そうでない場合、セキュリティ制御が配信速度と価値実現時間に影響を与えていると見なされるか、セキュリティ制御が導入した目的どおりの保護を提供できなくなるかのどちらかが発生します。 どちらも必ずしも最適というわけではありません。  

明らかな解決策は、セキュリティ制御モデルをソフトウェア配信ライフサイクル モデルに近いものに移行することです。実際、DevSecOps の動きでは、深い専門知識が経験豊富な専門チームに残っていても、セキュリティ制御の提供とチーム全員でのセキュリティの責任の共有にソフトウェア エンジニアリングと DevOps のプラクティスを適用し始めています。

この文化的変革に合わせて技術も進化し、セキュリティ制御の実装がソフトウェア配信パイプラインに統合されるようになります。 セキュリティ制御は、最後に追加されるのではなく、テスト、ステージング、展開を通じて新しいソフトウェアの各反復に付随します。 テレメトリと追跡可能性の要素がスタック内の複数のポイントに挿入され、追跡される場所。 敵対者を識別、追跡、報告するのに役立つ新しい指標を迅速に収集および分析できます。 

これを実現するには、テクノロジー スタックがチームと同じくらい連携する必要があります。 これは、将来の F5 + NGINX 組織における最も興味深い可能性の 1 つです。 ネットワーク ファイアウォールからアプリケーション サーバー、そしてその間のすべてのレイヤーにわたるポートフォリオにより、より俊敏で統合された、より情報豊富なセキュリティ制御セットの可能性が大きく広がります。 エンタープライズ クラスのセキュリティと可視性に軽量な俊敏性が加わることで、チームの全員が求めているツール、情報、そして (相対的な) 安心感を得られる可能性が生まれます。

F5 と NGINX を組み合わせることの利点の詳細については、F5 の CEO による「Bridging the Divide」ブログ シリーズを紹介する投稿をご覧ください。