2023 年クラウド脆弱性レポート

脆弱性に対するコードを強化するための迅速な推奨事項を解き放ちます。 このクイック リファレンス ガイドには、開発者が一般的なセキュリティの落とし穴を回避し、回復力のあるアプリケーションを構築するのに役立つ実用的な分析情報が満載です。

セキュリティ・バイ・デザインとは? [Security by Design]

セキュリティ・バイ・デザインは、セキュリティを後付けではなく柱として確立することを目的としたソフトウェア開発アプローチです。つまり、設計段階からセキュリティ制御をソフトウェア製品に統合することです。

Wiz エキスパートチーム
8 分で読めます

セキュリティ・バイ・デザイン (SbD) の説明 

セキュリティ・バイ・デザインは、セキュリティを後付けではなく柱として確立することを目的としたソフトウェア開発アプローチです。つまり、設計段階からセキュリティ制御をソフトウェア製品に統合することです。 SbDは、企業がセキュリティ機能の追加コストを発生させることなく、すぐにデプロイできる安全なソフトウェアを作成します。 

SbDをよりよく理解するために、数百万ドルの商品のための安全な倉庫を構築する必要があるシナリオを想像してみてください。 侵入しやすい木材で建物を建てたり、センサーやCCTVなどのセキュリティ機能で強化したり、セキュリティ会社を雇ったりすることもできます。 または、レンガで倉庫を建て、重い金属製のドアを使用し、同じセキュリティ機能をインストールすることもできます。 

レンガ倉庫は、もちろん、セキュリティ機能に関係なく、侵入不可能なシステムを持つ方が良いため、より安全になります。これはSbDを例示するアプローチです。

なぜセキュリティ・バイ・デザインなのか? 

Web向けアプリは、ソフトウェアベンダーがセキュリティを組み込む前にソフトウェアを出荷していたため、設計上脆弱(VbD)でした。 つまり、企業はセキュリティ機能をアドオンとして購入し、主要な脆弱性が発生したときにパッチを当てる必要がありましたが、機能が増えればより多くの費用がかかるため、ベンダーにとっては有益なアプローチでした。 

しかし、サプライチェーン攻撃の主な標的である企業は、侵害が発生したときに法的、財務的、評判的な結果に直面する企業です(多くの場合、実際に直面します)。 

SbDは、ユーザーとベンダーの両方が自分の行動または不作為に対して責任を負うソフトウェア開発の文化を促進することにより、この「エンタープライズユーザーにペナルティを課し、ベンダーを惜しむ」問題に対処します。 これにより、ベンダーとユーザーの両方のソフトウェアが向上します セキュリティ体制 これにより、攻撃対象領域が縮小され、他の主要な結果が促進されます。 

より簡単で安価なパッチ適用 

ソフトウェアの使用中にセキュリティ修正を急いで適用すると (データ侵害やそれに伴う財務的および評判の低下を防ぐため)、手間がかかり、コストがかかり、エラーが多発する可能性があります。 

最初から安全を確保するように設計された製品は、必要なパッチがますます少なくなるため、プロセスが大幅に安価で簡単になります。

費用対効果の高い製品

脆弱な設計上のシステムを保護する唯一の方法は、複数のアドオンをボルトで固定することです。 ただし、攻撃者は引き続き バックドア VbDの欠陥によって作成され、システムに侵入します。 

デフォルトでシステムを保護することは、データ侵害とそれに関連するコスト、訴訟、罰金のリスクが高くなるよりも費用対効果が高くなります。 

法規制の遵守

SbDアプローチを使用して開発されたソフトウェアは、その中核にセキュリティがあるため、デフォルトで準拠している可能性が高くなります。 これにより、さまざまなソフトウェアコンポーネントをチェックして確認するプロセスが容易になります コンプライアンス さまざまな規制があります。 

セキュリティ・バイ・デザインの仕組み

SbDのアプローチには4つの主要な段階があり、以下で説明します。 

ステージ 1: セキュリティ要件を定義する

SbDは、開発するソフトウェア、その潜在的な脆弱性、および対応するセキュリティ要件の明確な調査から始まります。 データベース サービスの場合、セキュリティ要件には、暗号化、ロールベースのアクセス制御 (RBAC)、およびその他の承認手法が含まれます。 

ステージ 2: リスク評価と脅威モデリングを実施する 

この段階では、状況依存の 脆弱性スキャナー ソフトウェアの潜在的な攻撃パスをマッピングします。 

たとえば、データベースサービスプロバイダーは、データベースに保存されている機密性の高い個人識別情報(PII)や保護医療情報(PHI)により、パブリックIPや特権アカウントなどの攻撃パスにさらされる可能性があります。 

ステージ 3: コードの記述とセキュリティ対策の構築を同時に行う 

この段階では、エンジニアリングチームは従来のコーディング手順を放棄し、ネイティブの セキュリティ対策. データベース プロバイダーの場合、これには次のようなコードを記述することが含まれます。

  • データベースがデフォルトで公開されないようにします

  • エンタープライズユーザーがアドオンを購入することなく、ユーザー入力を自動的に検証します

  • 何らかの形式のアクセスが許可される前に、複数の認証メカニズムが必要です 

  • 特権アカウントのアクセスポイントを制限

ステージ 4: 継続的な監視とパッチ適用

最後に、ソフトウェアがテストされ、設計上安全であると判断された場合は出荷されます。 ユーザーがソフトウェアをデプロイすると、ベンダーは継続的に監視、監査を行い、新しい脅威としてSbDアップデートを送信します。 脆弱 性 現れる。 

セキュリティ・バイ・デザインの原則 

CISA(Cybersecurity and Infrastructure Security Agency)は、ソフトウェアメーカーが製品を開発する際に3つの基本原則を採用することを奨励しています。 

責任の共有

ベンダーと顧客の両方 セキュリティの負担を分担する必要があります。 ソフトウェアメーカーは、脅威の状況が進化するにつれて、安全な製品を構築し、ソフトウェアに定期的にパッチを適用することが期待されています。 一方、お客様は、このソフトウェアを使用して製品を安全に構成し、データを安全に保つことが期待されています。

徹底的な透明性

ソフトウェアメーカーは、自社製品の設計上の安全性を確保するための情報を共有する必要があります。 SbD製品に期待されることのいくつかを挙げると、正確な脆弱性アドバイザリ、関連するCommon Vulnerability and Exposure(CVE)レコード、認証メカニズムについて、顧客に対して説明責任を負っています。

組織体制

SbDには、経営幹部レベルのコミットメントとすべてのステークホルダー間のコミュニケーションが必要であり、ベンダーと顧客、さらには開発者とセキュリティチームとの間のコラボレーションが重要です。 これにより、ほぼ侵入不可能なセキュリティ制御の実装が容易になり、洞察に基づく予算計画とリソース割り当てが可能になります。 

セキュリティ・バイ・デザインの実装における課題

SbDを採用する際の3つの重要な課題について説明しましょう。

ChallengeDescription
Short-term costs vs. long-term profitsThe cost of restructuring legacy software and switching programming languages to embed security—rather than bolt it on—is discouraging for most vendors. Even in modern systems, embedding security is a complex and costly process. Still, in the long run, fewer and less complicated patches, fewer attacks, etc. will mean the initial cost pays for itself.
MarketabilityThe motivation—for cloud vendors—to implement SbD is low, as there are no direct monetary returns for them. It is difficult to market restructured SbD products on the “now secure-by-design” premise, as this will leave enterprise users with the presupposition that the products weren’t properly built and secured earlier on. It is easier to sell legacy software as is, alongside aftersales/add-on security products like firewalls and antivirus.
Third-party vendor liabilityAn important implication of SbD is that software vendors are liable for supply chain vulnerabilities. For example, a single security flaw can affect several enterprise customers who would want the vendor to take the blame, i.e., face the financial and reputational consequences. Getting all parties onboard with the shared responsibility model is thus critical, as discussed above. This makes it clear that security is in fact a shared burden between the vendor and the customer.

セキュリティ・バイ・デザインのベストプラクティス

CISAは、 セキュアソフトウェア開発フレームワーク(SSDF) 米国国立標準技術研究所(NIST)の:NISTの SP 800-218. 組織は、これらのプラクティスをソフトウェア開発ライフサイクル(SDLC)のすべての段階に統合する必要があります。

安全なソフトウェアコンポーネントを使用する

ライブラリ、フレームワーク、ミドルウェアなど、十分に保護されたソフトウェアコンポーネントは、検証済みのプロバイダーからのみデプロイします。 また、暗号化と認証の失敗、アクセス制御の失敗、インジェクションの脆弱性、ログの問題など、既知の脆弱性を持つソフトウェアは避けてください。 

クラウドネイティブなアプリケーション保護プラットフォーム (CNAPPの) は、セキュリティで保護されていないコンポーネントを検出するのに便利です。

優れた設計手法を採用する

組織は、多層防御を実装することで、ソフトウェアシステムのリスクを軽減できます。 セキュリティ対策を複数重ねる. 一方、サンドボックス化は、ソフトウェアとセキュリティコンポーネントを分離して、単一のコンポーネントの侵害がシステム全体に影響を与えるのを防ぎます。 

ベンダーは、パッチ適用を容易にするソフトウェアも設計する必要があります。ソフトウェアの更新によるダウンタイムを最小限に抑えることで、企業ユーザーはパッチをより迅速に適用できるようになります。 

メモリセーフなプログラミング言語を利用する 

NISTは奨励しています 開発者 制御フロー整合性 (CFI) やアドレス空間レイアウトのランダム化 (ASLR) など、一般的なメモリを対象とした軽減策を実装します。 しかし、これを超えて、NISTは、Rust、Go、Java、C#、Swift、Pythonなどの最新のメモリセーフ言語を採用し、メモリセーフでない言語であるCおよびC ++は避けるべきであるとも述べています。 

これにより、SlammerWorm、Ghost Engine、Stagefrightなどのメモリ安全性の脆弱性を軽減できます。

パラメーター化されたクエリと Web テンプレート フレームワークを採用する 

パラメータ化クエリは、ユーザー入力をクエリ自体から分離するパラメータを持つ SQL クエリです。 Web テンプレート フレームワークには、疑わしいユーザー入力を自動的に防止するコンテキスト依存情報が含まれています。 これらのメカニズムを組み合わせることで、SQL インジェクションと クロスサイトスクリプティング(XSS)攻撃.

SBOMの提供 

ソフトウェアベンダーは、ソフトウェアの開発に使用したプロプライエタリおよびサードパーティのソフトウェアコンポーネント、ライブラリ、およびツールのリストをユーザーに提供する必要があります。 このリストは、 エージェントレスSBOMスキャナー—脆弱性の解決を容易にします。 

デフォルトのパスワードを削除する

プロバイダーは、デフォルトのパスワードで製品を展開することを避ける必要があります。 それよりも、多要素認証を採用し、ソフトウェアを設定した直後にユーザーに強力なパスワードを設定するように要求する必要があります。

ソフトウェア認証プロファイルの提供 

これらのプロファイルは、ユーザー・データおよび特権アカウントへの不要なアクセスを制限するためのユーザー・ロールおよびユースケースを指定します。 ソフトウェア製造元は、詳細なソフトウェア承認プロファイルを提供し、最小特権の原則を実装し、指定された制限からの逸脱に対して警告を発行する必要があります。 

結論

セキュリティ・バイ・デザイン:ソフトウェア設計の段階からセキュリティプロトコルをプロアクティブに実装します。 CISA やその他の主要な業界関係者が推進している SbD は、脆弱性評価、攻撃パス分析、およびソフトウェア コンポーネント分析を実施して、アプリが出荷される前や SDLC のすべての段階で潜在的なソフトウェアの脆弱性を特定して解決することを奨励しています。 

目標は、高価な追加セキュリティツールや、システムがすでに設計上脆弱であるためにシステムを攻撃から適切に保護できない複雑なアフターセールスコード変更を削減することです。 

SbDは、アプリの構築と保護のための、より安価で、より速く、より堅牢なアプローチです。 これが、Wizが主要な支持者である理由です。 安全なコードの配送. その解決策:

  • エンドツーエンドのソフトウェアの可視性を促進

  • 最新のSBOMを提供

  • 可能 攻撃パス分析 

にサインアップする パーソナライズされたデモ では、Wizがセキュア・バイ・デザイン製品への道をどのように始めることができるかをご覧ください。 

See for yourself...

Learn what makes Wiz the platform to enable your cloud security operation

デモを見る