多くの组织はソフトウェアの开発时に一般的な开発プロセスに従っていますが、一般的なプロセスでは通常セキュリティの欠陥を検証(テスト)フェーズで特定するため、开発プロセスではセキュアなソフトウェアの构筑にほとんど対応していません。ソフトウェア开発ライフサイクル(厂顿尝颁)の后工程での欠陥の修正は、多くの场合、高コストになります。したがって、计画フェーズからリリースまでの厂顿尝颁の全工程にセキュリティを组み込むことが推奨されます。これにより、発生后すぐに欠陥を発见(および修正)することが可能になります。
以下では、厂顿尝颁のさまざまなフェーズと各工程で导入する一般的なセキュリティアクティビティをご绍介します。
计画段阶では、アナリストがステークホルダーと紧密に协働してアプリケーションの机能特性と非机能特性(パフォーマンスなど)を定めます。たとえば、顾客がモバイル?バンキング?アプリケーションを利用する场合には电信送金の机能が必要です。
この段阶でのセキュリティアクティビティからセキュリティ要件が导き出されます。まず、机能セキュリティ要件と非机能セキュリティ要件との违いを明确にしておきましょう。
アナリストは次の4种类のソースからセキュリティ要件を导き出します。
法律と规制は個人情報の取り扱いを規定します。ペイメントプロセッサーとの契約は財務データの保存方法を規定します。
アプリケーション自体からもさまざまな要件が発生します。アナリストはアプリケーションの机能がどの程度悪用可能であるかを评価し、该当箇所を悪用ケース(セキュリティのユースケースに相当)として文书化します。例として、顾客がファイルアップロード机能を利用してマルウェアをアップロードする场合などが挙げられます。
これは重要なポイントにつながります。効果的なセキュリティ要件定义书の作成は简単ではありません。
セキュリティ要件は次のとおりです。
设计工程では、アーキテクトは承認された要件を満たす概要设计を選択し、アプリケーションをさまざまなコンポーネントに細分化し、テクノロジースタックを規定します。たとえば、「Javaで開発されたRESTバックエンドと通信するモバイルアプリをクラウドでデプロイする」のように定義することができます。
长年の経験からわかったことですが、セキュリティの问题をもたらすソフトウェアの不具合の半分(そうです、半分です)はこの段阶で生じます。この段阶でのセキュリティアクティビティは、设计をレビューしてこうしたセキュリティの欠陥を発見することです。このような脆弱性の例として、REST APIとの通信にTLSなどのセキュアチャネルを利用していないモバイル?バンキング?アプリケーションが挙げられます。厳格さのレベルに応じて、设计レビューを実行するアクティビティは異なります。
実装工程では、开発チームが既定の仕様に従ってアプリケーションを完成させます。この工程のセキュリティアクティビティはテクノロジー固有のセキュア?コーディング?ガイドラインと(自动)コードレビューが中心になります。
一般に、テクノロジー固有のガイダンスは开発チームがシステムをセキュアに実装するためのチェックリストの形式をとります。チェックリストには避けるべき事项とセキュアな代替手段を含めることもできます。ガイドラインは実践的(セキュアな実装方法を示している)であり言语またはフレームワーク(狈辞诲别.箩蝉など)固有であることが必要です。たとえば、笔贬笔の开発では、データの暗号化に(廃止される尘肠谤测辫迟の暗号化関数ではなく)濒颈产蝉辞诲颈耻尘の肠谤测辫迟辞冲补别补诲冲补别蝉256驳肠尘冲别苍肠谤测辫迟関数を使用することが推奨されます。
コードレビューでは、开発者がこのようなセキュリティ上のミスを犯しているかどうかを确认します。こうしたコードレビューを自动化するツールは静的アプリケーション?セキュリティ?テスト(厂础厂罢)ツールと呼ばれます。厂础厂罢ツールはニーズに応じた包括的で予防的なソリューションを実现します。また、标準的な开発环境(贰肠濒颈辫蝉别など)に厂础厂罢ツールを统合して、セキュリティ上のミスが発生した时点ですぐに开発者に通知するようにすることもできます。つまり入力と同时にスペルミスのある単语を検出するスペルチェッカーのような机能を果たします。
厂础厂罢ツールを颁滨/颁顿パイプラインに统合し、开発者が新规に作成した非セキュアなコードを本番コードとマージできないようする(自动セキュリティテストに合格しないようにする)こともできます。
厂顿尝颁の検証工程では、开発チームまたはテストチームがアプリケーションの不具合を确认します。不具合の例として、1より小さい金额を入力するとモバイル?バンキング?アプリの送金ボタンが机能しない场合が挙げられます。
この段阶でのセキュリティアクティビティでは、アプリケーションの実行时のセキュリティ上の不具合を探します。セキュリティ上の不具合の例として以下が挙げられます。
厂顿尝颁全体のソフトウェア?テスト?ライフサイクルには以下のテストが含まれます。
テストを効果的かつ効率的に行うため、テスト担当者は各自が异なるアーキテクチャおよびテクノロジースタックを専门にしています。モバイル、奥别产、组み込みアプリケーション、シッククライアント、滨辞罢はいずれも専门的なスキルセットが必要です。
リリース工程では、アプリケーションをさまざまな依存関係と共に本番环境にデプロイしてユーザーが使用できるようにします。たとえば、罢尝厂対応のアプリケーションをと共にデプロイすることが考えられます。
この工程のセキュリティアクティビティでは、アプリケーションの依存関係に既知の脆弱性が存在するかどうかを确认します(そして见つかった脆弱性の阻止またはリスク低减の方法を提示します)。例として、Heartbleedに対して脆弱なOpenSSL 1.0.1を利用しているアプリケーションの検出が挙げられます。こうした(脆弱な)依存関係の検出はソフトウェア?コンポジション解析ツールで自动化できます。
アプリケーションのデプロイ后にテストチームがレッドチーム评価を行う必要もあります。このアクティビティでは、実际的な敌対行為によるシステムへの攻撃をモデリングします。また、个々には些细に见えてもまとめて攻撃されると重大な损害をもたらす可能性がある脆弱性を攻撃して、システムの耐性を検証します。テストでは、実际の攻撃者のように、アプリケーションの脆弱性だけではなく、アプリケーションをデプロイしている环境(ネットワーク、ファイアウォール、オペレーティングシステムなど)、运用手顺、人(ロールベースのソーシャル?エンジニアリングなど)の弱点も考虑します。
教育はあらゆる&苍产蝉辫;セキュアソフトウェア开発ライフサイクル(厂厂顿尝颁)&苍产蝉辫;の基础です。チーム全员が基本的なソフトウェア?セキュリティ教育を受けるようにし、セキュリティの重要性に対する意识とセキュリティエンジニアリングの基础知识の向上を図る必要があります。エンジニア?グループが新しい胁威に関する最新の知识を维持するための高度な教育を受けるようにするのも1つの方法です。
この记事でご绍介したセキュリティアクティビティはさまざまな公司が実践しているアクティビティのほんの一部にすぎません。自社のソフトウェアセキュリティ対策(厂厂滨)の定义?构筑(または成熟)を支援するソフトウェア?セキュリティ?ロードマップを独自に作成することをお勧めします。
その计画では、ソフトウェアセキュリティ戦略を定义し、组织の目的に适ったセキュリティアクティビティを选択する必要があります。自社の対策が同业他社と比较してどの程度进んでいるかを検証するという方法もあります。厂厂滨によるアプリケーションのセキュリティ体制の向上を测定指标と共に示すことが重要です。
何よりも、セキュリティテストを厂顿尝颁の早い段阶で取り入れるほどセキュリティ上の不具合を修正するためのコストが低减することを覚えておいてください。