close search bar

Sorry, not available in this language yet

close language selection

御社のセキュリティはDevOps環境のペースに後れを取っていませんか?

Taylor Armerding

Mar 08, 2021 / 1 min read

今日のソフトウェア開発のスピードを10年前と比較することは、新幹線と自転車の速度を比較するようなものです。CI/CDとDevOpsが主流になった現在では、そのスピードは桁違いに速くなっています。Puppet Labsの2015年のレポートによると、「高業績のIT組織はデプロイ頻度が30倍多く、リードタイムが200倍短い」ということです。

それは5年前のことです。現在はさらに迅速化しています。それに追いつくにはセキュリティをどのようなものにすればよいでしょうか。

シノプシスの政府および重要インフラ・プログラム担当部長Joe Jarzombekは、ご質問いただいたことを喜んでいます。簡単な答えは、ソフトウェア開発ライフサイクル(SDLC)全体にわたってDevOpsにセキュリティを組み込み 、DevSecOpsにすることです。これを行うには、セキュリティ文化の向上、自動化ツール、そしてJarzombekの言葉を借りれば「エクスプロイトの可能性があるソフトウェアに起因するリスクへの対処に必要な時間と労力を削減する」プロセスを組み合わせるという方法があります。

その実現には数多くの細かい事項が関係しますが、それについてはJarzombekが最近のWebセミナー「Key Steps for Integrating Software Application Security Testing in DevSecOps(DevSecOpsでソフトウェアのアプリケーション・セキュリティ・テストを統合するための重要なステップ)」で取り上げています。

防衛関連企業を対象としたWebセミナーですが、DevSecOpsの原則はどの業界にも当てはまります。

セキュリティの責任を共有する

セキュリティの責任を共有する

セキュリティカンファレンスでスローガンになっている最も重要なステップの1つは「セキュアな方法を簡便にする」です。DevSecOpsの場合、セキュリティは全員の責任ですが、全員がセキュリティの専門家である必要はありません。

「ツールをセキュリティチェッカーと一緒に使用すると、スペルチェッカーを使用した場合と同様にセキュリティ上の欠陥を内部的に捕捉できます」とJarzombekは言います。「入力中に警告が表示され、緩和策へのパスが示されます。セキュリティチェッカーは、時間とリソースの節約を促進すると同時に、開発チームがセキュリティ上の欠陥自体を完全に把握していない場合でも、リスクを迅速に軽減します。ツールが自動的にその処理を行います。

ソフトウェアアシュアランスの実現

Jarzombekによれば、DevOpsにセキュリティテストを組み込むという目標は「ソフトウェアアシュアランス」であり、ソフトウェアが意図したとおりに機能し、エクスプロイトの可能性がある脆弱性が存在しないというレベルの信頼を示すものです。

Jarzombekはこうも言います。「実際には、ソフトウェアは我々が懸念しているデータを処理しており、システムを有効化して制御するソフトウェアを通じて、システムからデータが漏洩していないように確実な対策を講じる必要があります」

脆弱性が全く存在しないソフトウェアはあり得ないので、ソフトウェアアシュアランスのもう1つの鍵は、攻撃者によってエクスプロイトされる可能性が特に高い欠陥または特に多くの損害を与える可能性のある問題を見つけて修正することです。

これを行うには、米国標準技術研究所(NIST)が管理する標準ベースの脆弱性管理データを保存した米国政府のリポジトリ、国家脆弱性データベース(NVD)の一部である共通脆弱性識別子(CVE)および共通脆弱性タイプ(CWE)一覧で既知の脆弱性や弱点を探すことが1つの方法です。

弱点(Weakness)、脆弱性(Vulnerability)、露出(Exposure)の違いを知る

しかし、これらの一覧があっても、特に重要な脅威に絞り込む必要があります。そして、Jarzombekが指摘したように、弱点、脆弱性、露出には重要な違いがあります。

  • 弱点は、「情報通信技術(ICT)/IoTアーキテクチャ、設計、コード、またはプロセスにおける誤りや欠陥のある状態であり、対処しなければ、条件が整った場合にエクスプロイトに対して脆弱になる可能性があります。CWEによると、弱点はゼロデイエクスプロイトの潜在的なソースベクトルを表しています」とJarzombekは言い、さらに「これらの弱点の3分の2はコードレベルに存在し、自動化ツールを使用するだけで検出と軽減が可能です」と付け加えています。
  • 脆弱性とは、ハッカーがシステムやネットワークにアクセスするために直接利用することが可能なソフトウェア上の誤りです。
  • 露出とは、不正アクセスやエクスプロイトを可能にする構成上の問題やロジック上の誤りです。

攻撃者の目標は、もちろん、それらの一部またはすべてのエクスプロイトを試みることです。一般的な攻撃には、Webページの生成時に入力を不適切に無害化するクロスサイト・スクリプティング(XSS)や、SQLコマンドで使用される特殊な要素を不適切に無害化するSQLインジェクションなどがあります。

「しかし、ここでツールの出番です」とJarzombekは言い、優れたテストツールがオブジェクト・マネジメント・グループ(OMG)の自動ソースコード品質対策(ASCQM)に含まれる数百の既知の弱点や脆弱性にフラグを立てることができると指摘しました。ASCQMには次のカテゴリーがあります。

  • セキュリティ:CWE/SANS Instituteの最も危険なセキュリティエラーTOP25およびOpen Web Application Security Project(OWASP)Top 10を含む、ソフトウェアの最も明白なセキュリティの弱点を示すソースコード内の74個のCWE
  • 信頼性:ソフトウェアの可用性、フォールトトレランス、回復性に影響を与えるソースコード内の74個のCWE
  • パフォーマンス効率:応答時間とプロセッサやメモリなどのリソースの使用率に影響するソースコード内の18個のCWE
  • 保守性:ソフトウェアのわかりやすさ、変更性、拡張性に影響するソースコード内の29個のCWE
  • データ保護:データの漏洩や破損に影響するソースコード内の89個のCWE:データの不正な読み取りや変更を可能にする可能性のあるベクトル

「内部にセキュリティチェッカーがあるので、これらすべてを知っている必要はありません」とJarzombekは言います。「品質の欠陥として扱い、処理するだけで済みます。そこが利点です。」

自動化に歩調を合わせる

自動化に歩調を合わせる

しかし、それですべてが単純になるわけではありません。Jarzombekは、最新のアプリケーションの複雑さと開発/デリバリーのスピードにセキュリティのペースが遅れないようにするためには、自動テストツールが必須であると指摘します。

そして「最新のアプリケーションは、データストレージ、データアクセス、フレームワーク、ビジネスロジック、UI/API、クラウド/モバイルを含むテクノロジースタックです」とも言います。「ソフトウェアは重要インフラです。言語、プラットフォーム、オープンソース、サードパーティー・ライセンスのコード、自社開発コード、コンテナ、クラウドなど、複雑さは増しています。」

「その複雑さのレベルは自動化を活用しなければ対処が困難です」とJarzombekは言います。「たとえば、ソースコードが20GBのアプリケーションの場合、その約70%がオープンソース、67%が相互ライセンス、2%がパーミッシブライセンス、30%が自社開発コード、6%がライセンスを取得したサードパーティー製コードである可能性があります。その中の脆弱なコンポーネントのうち6件は重大度が高、13件は中、19件は低である可能性があります。」

しかも、アプリケーションが主要なアタックサーフェスとなっているため、これらの脆弱性を検出して修正することはこれまで以上に重要です。Jarzombekによると、複数の研究で、すべてのサイバー攻撃の約84%がアプリケーションレベルで発生し、エクスプロイトの可能性がある脆弱性の90%がアプリケーションに存在することが判明しました。

しかし、組織は依然としてネットワークセキュリティへの支出を増やそうとしています。「ネットワークも保護する必要がありますが、アプリケーション自体のセキュリティへの注力を強化する必要があります。ハッカーは、狙いやすくなっているアプリケーションの脆弱性を標的にしているからです。」

適切なセキュリティツールを選択する

適切なセキュリティ・ツールを選択する

アプリケーションは高級ワインのようには熟成しないということがその理由の一部です。「アプリケーションは牛乳のように腐敗します」とJarzombekは言います。「時間が経つほど、ますます多くの脆弱性が発見されます。デプロイ後も検査と更新を続ける必要があります。そのため、DevSecOpsチームがソフトウェアの脆弱性スキャンを自動化して、後れを取らないようにすることが重要です。他に攻撃を回避する方法はありません。」

シノプシスのアプリケーションテスト製品群はSDLC全体を網羅しているとJarzombekは指摘します。該当するツールには以下があります。

「SDLCの段階に応じて異なるツールを使用します。その利点は、最高のツールの組み合わせを取り入れれば、全体として最適なソリューションを得られるということです」とJarzombekは言います。

これらのツールは、Black Duck SCAとCoverity静的解析の両方をサポートするIDEプラグイン、Code Sight™を搭載したPolaris Software Integrity Platform™に統合されています。

市場にはさまざまなツールがあり、その中には無料のツールもあります。「しかし、すべてのツールが対等なわけではありません」とJarzombekは言います。「1つのスペースにあるツールで何でも探せるわけではありません。実際、使用しているツールを伝えれば、多くの人はあなたが探していないものは何かがわかります。利用するツールの機能を知っておく必要があります。」

DevSecOpsの文化に移行する

また、効果的なDevSecOpsには文化の変化が必要だとJarzombekは言います。また、「DevOpsチームは開発・運用と同様にセキュリティにも責任を負うことを認める必要があります」とも言います。「アプリケーションセキュリティは、リリースおよびテストとパラダイムが一致している必要があります。それは付加的なものではなく、ビジネスのやり方そのものです。それを私たちの行動に組み込む必要があります。」

DevSecOpsを適切に行うことは、「セキュリティを欠陥追跡と事後対応に統合する」ことを意味するとJarzombekは言います。その内容を以下に示します。

  • 開発チームがアクセスできるバグ追跡システムでセキュリティの問題を追跡する
  • 問題を繰り返すことを防ぐための適切な手順を検討し、実行する
  • 共通ダッシュボードのすべてのツールでメトリックを追跡する
  • 機能ブロッカーとセキュリティブロッカーでビルドを分割する
  • 自動アラートを設定する
  • DevSecOpsの文化でチームのトレーニングを行う
  • ロールベースのトレーニングを実施する
  • トレーニングプログラムの成果を測定する

もちろん、それには時間と費用がかかりますが、見返りのある投資です。「ソフトウェアのデプロイ後に脆弱性、インシデント、侵害に対応するよりもはるかに費用対効果が高くなります」とJarzombekは言います。「DevSecOpsチームは未知の脆弱性がもたらす新たな脅威のみに対処すればよいのです。既知の脅威に対応する必要はなく、開発中に対処されていなかった脅威の対処に専念できます。」

要するに、DevSecOpsとは、セキュアで高品質なソフトウェアの構築にかかる期間を短縮する道筋です。

Continue Reading

トピックを探索する