HCL AppScan: 継続的なセキュリティーの確保
2020/9/2 - 読み終える時間: 2 分
継続的なセキュリティーに関する連載の最終回、HCL AppScan - Assure Continuous Security の翻訳版です。
HCL AppScan - 継続的なセキュリティーの確保
2020年9月1日
著者: Colin Bell / SALES DIRECTOR 共著: Rob Cuddy / Global Application Security Sales Evangelist, Kristofer A Duer / Architect for research projects at HCL AppScan
第 1 回目の継続的セキュリティーに関するブログでは、3 つのテーマ分野の概要を説明し、それぞれに 2 つの重要な機能が含まれていることを説明しました。シリーズ最終回となる今回のブログでは、「保証 (Assure)」のテーマと、「測定 (Measure)」と「監査 (Audit)」の能力に焦点を当てていきます。
では、なぜ「アシュア」を選んだのでしょうか？ それは、あまりにも多くの場合、セキュリティーがプロアクティブよりもリアクティブであることに気づいたからです。実際、Ponemon Institute の 2018年の調査によると、サイバーセキュリティーおよび情報セキュリティーチームの 78%が誤ったアラートに対処するために週に 250時間以上（合計で）を費やしていたという驚くべき結果が出ています。私たちはより良い方法で対処する必要があります。正しく行われている適切なセキュリティープログラムは、ビジネスに付加価値を与え、システムへの信頼感を高め、非生産的なことに費やす時間を減らすことができます。すべてのアラートが実際に問題なのかどうかを理解しようとして時間を無駄にするのではなく、セキュリティープログラムの真の保証が必要です。
継続的なセキュリティーでは、プロセスから学び、改善することを目的としています。例えば、あるチームが継続的なサニタイズの問題に悩んでいるとしたら、安全なコーディング教育を強化する必要があるかもしれません。また、ある脆弱性が多くのチームに渡って暴露されている場合は、コーディングガイドラインを修正する必要があるかもしれません。成功するためには、ガイドラインと基準を満たすための管理が確実に行われていることを確認する必要があります。成功を測定するためにはメトリクスが必要であり、目標を確実に達成するためには監査が必要です。
測定
測定能力は、継続的なセキュリティーを成功させるための重要な側面の一つです。このケイパビリティでは、セキュリティーの具体的な側面である測定値と、それらの測定値が互いに関係している関係、およびビジネスとの関係である測定値の両方を調査します。この両方に注意を払い、プロセスの成熟と進展に合わせて正しく適用する必要があります。この能力は、多くの組織でアプローチが異なる点でもあります。例えば、私は、リリース前にアプリケーションをスキャンすることが最も重要な測定値であるというケースを見てきました。残念なことに、これは、スキャンによって発見された結果を重視していません。そう、スキャンは実行されましたが、もし、その結果が何も行われなかった場合、それはビジネスにどのような価値を与えるのでしょうか？一般的に、このアプローチの根本的な理由は、プログラムが PCI DSS などのコンプライアンスのニーズから推進されていることです。
その他の企業は、ポートフォリオ内のアプリケーションの総数と比較して、テストされたアプリケーションの数をコアメトリクスとして評価しています。これらの組織では、多くの場合、「王冠の宝石」や最も重要な重要アプリケーションから開始し、それらがある程度のレベルのセキュリティーポリシーを満たしていることを確認しています。おそらく、アプリケーションが次のフェーズに進む前に、すべての高リスクの問題が緩和されているものと思われます。
より成熟した組織は、脆弱性を修正するための時間を短縮するために測定値を使用し、チームベースの測定値を使用して、脆弱性がどこに出現したか、あるいはどこで作成されたかを判断します。このことは、第５話「アプリケーションパラノイア」のポッドキャストシリーズで、HCL Software の CISO である Joe Rubino 氏とのディスカッションを通じて強調されました。ルビノ氏が重要視していた主要なメトリクスは、カバレッジエリアと範囲、ソース別の脆弱性の特定、特定された脆弱性の種類、過去の傾向と比較して時間の経過とともに新たに出てきたもの、そしてそれらの発見に対してチームがどのように対応していたか、というものでした。
Joe氏はまた、彼のチームにとって重要な指標が「開発チームから何を聞いているか」に関連していることにも言及しています。開発チームからは、脆弱性やセキュリティー全般についての懸念があり、その懸念が彼らの作業負荷にどのような影響を与えているか？セキュリティーチームは、その負担を軽減するために、どのようにプロセスを改善できるのでしょうか？彼の指摘は、これが単なる一方向的なコミュニケーションフローではないことを確認する必要があり、全員が同じチームの一員であると感じていることを確認するための指標を使用する必要があるということです。
どのようなアプローチであれ、最終的に重要なのは、メトリクスがセキュリティーガバナンスの観点から推進されることであり、その逆ではないということです。例えば、ビジネスリスクに基づいてアプリケーションのテストプロセスの概要を説明したり、スキャンにどのようなタイプのポリ シーが適用されるかを決定する安全なコーディングガイドラインを含めることができます。これは、どのようなリスクを受け入れ、どのようなリスクを修正する必要があるかについての決定に直接つながります。ガバナンスがうまくいっていれば、何を測定すべきかをよりよく知ることができ、その情報を使って、私たちが望む結果に影響を与えることができます。
監査
これは、セキュリティー監査の活動にうまく連れてきてくれます。多くの組織では、これは独立した機能であり、重要なアプリケーションのセキュリティーテストやアプリケーションのペンテストを担当しているかもしれません。過去にこのような活動をしてきた経験から、これらのチームは非常に熟練しており、脆弱性を探すことになると、岩が発見されないようにする能力に誇りを持っていることを知っています。
問題は、彼らの作業が長く、何百ものアプリケーションを持っている会社にとっては、規模が大きくならないことです。SDLC で行われたセキュリティーテストを常に活用しているとは限りません。また、実施されているテストの種類をレビューすることもありません。
継続的なセキュリティーでは、監査も重要な要素であり、企業のセキュリティーは、開発から運用に至るまでのセキュリティープログラム全体に責任を持つべきである。監査は、一連の規則や規則に対するコンプライアンスを検証するだけのものではありません。監査とは、ビジネスが健全に機能するように、ポリシー、慣行、手順が正しく実行されているかどうかを検証することです。ペンテストは一つの機能ですが、単独で行うべきではありません。むしろ、収集したメトリクスを見直し、脆弱性の知見を報告書に反映させるなど、企業の全体的なセキュリティー戦略の中に収めるべきです。
SIEM を使用している場合、その情報は、アプリケーションとその露出リスクに関する意思決定を行うためにも活用されなければなりません。すべての活動から情報が収集されると、この情報は、必要に応じてプロセスを変更するためにガバナンスにフィードバックされることがあり、また、フィードバックされるべきである。これは、チームに教育を提供して、セキュリティー意識を強化したり、脅威モデルに影響を与えたり、セキュリ ティ基準やガイドラインを変更したりすることができるかもしれません。このことが意味するのは、監査は、アプリケーションの全体的なリスクを決定する上で重要な側面であるということです。
まとめ
つまり、継続的なセキュリティーの成功を保証するための柱は、監査、測定、ガバナンスが共に働くことである。本質的には、ガバナンスは、プロセス全体でセキュリティーテストがなぜ、どのように行われているかを概説し、メジャーはテストに関する事実を示し、監査は、それが望ましいレベルで機能しているかどうかを確認することです。
今回のブログでは、Assure のテーマと Measure と Audit の機能に注目しました。これで、継続的なセキュリティー連載は終了です。
このシリーズの以前の記事を見逃してしまった方は、こちらからご覧いただけます。
第1回: AppScan - そろそろセキュリティも継続的に行う必要があります