セキュリティーにまつわる、AppScan シリーズの 3 回目です。HCL AppScan: Intensify Continuous Security の翻訳版です。
HCL AppScan: 継続的なセキュリティの強化
2020年8月24日
著者: Rob Cuddy / HCL
第 1 回目のブログ「継続的セキュリティ」では、3 つのテーマ分野の概要を説明しましたが、それぞれに 2 つの重要な能力が含まれています。このシリーズの第 3 回目のブログでは、「Intensify」というテーマと、「Educate」と「Govern」の能力に焦点を当てています。
継続的セキュリティに関連するテーマに「強化」という言葉を使うのは変だと思われるかもしれません。結局のところ、「激化」という言葉を調べてみると、その定義は簡単に言うと、"become or make more intensify"となります。
では、どのような意味でしょうか。
多くの組織が DevOps のプラクティスを採用している、あるいは採用中であり、それらのプラクティスにセキュリティを組み込むことにも取り組んでいます。これは素晴らしいことなのですが、それだけの取り組みやプロジェクトではありません。パイプラインにセキュリティテストを追加し、結果を共有して「完了」と呼ぶようなものではありません。そうではなく、最初に行った努力を積み重ね、そこから学び、コース修正をしていかなければなりません。さらに、セキュリティチームを超えてセキュリティプログラムを拡大し、組織の開発プラクティスに組み込むことで、セキュリティプログラムを強化することも視野に入れています。
リスクを発見し、軽減する能力を継続的に向上させていく必要があります。要するに、強化するための取り組みは、アプリケーションをより健全に、そして時間をかけてより安全にするために行われているのです。
セキュリティを本当に継続的なものにするためには、セキュリティパラダイムを増幅して拡張する必要があり、その結果、より安全なコードが書かれ、より良いセキュリティプラクティスが守られるようになります。そのためには、より良い教育とより良いガバナンスが必要です。
教育
教育というと、いくつかの異なる側面があり、それぞれが重要である。教育はセキュリティプログラム全体を超越しており、セキュリティが開発、テスト、運用、セキュリティとどこで連携するかによってニーズが異なります。何よりもまず第一に、コードを書いて作業をしているチームのためのものです。
正直に言うと、開発者は通常、安全でないコードを書こうとしているわけではありませんが、何が本当に脆弱なのか、どのようにして悪用が起こるのかについての認識不足に悩まされていることが多いのです。開発者は一般的に、最初から安全なコードを作れるようになりたいと考えています。これには正式なトレーニングが必要になりますが、クラスと並行して開発者は、組織内のチームが実施した脆弱性修正のリポジトリなど、具体的で文脈に沿った例を必要とし、他の人がその恩恵を受けられるようにします。結局のところ、これだけ多くのコードが共有されているのですから、もしあなたが脆弱性に遭遇した場合、他の誰かが脆弱性を持っている可能性は十分にあります。このことは、理想的には、セキュリティプログラムのガバナンスと連携した安全なコーディングガイドラインに反映されるべきです。
組織におけるより広範なセキュリティプログラムを真に推進する明確なステップは、開発チーム内で独立したセキュリ ティチャンピオンを育成し、成長させることです。これを成功させるには、セキュリティ意識とベストプラクティスに関する教育が鍵となります。セキュリティチャンピオンを独立させ、セキュリティチームとの連携を強めることで、企業ベースのセキュリ ティポリシーと実践が確実に管理されるようになる。セキュリティチャンピオンは、より広いチームとして協力し、お互いに学び合うこともできます。
第二の側面は、ツールとプロセスに関するものである。DevOps が要求するペースを維持するためには、コーディング時に支援を提供できるツールを用意することが不可欠である。リリースサイクルの最後に重要なセキュリティ問題が特定され、修正に対応するためにピボットが必要になると、チームはイライラしてしまいます。それよりも、コードがコミットされたときにコードの健全性についての洞察を得ることの方がはるかに有益です。DevSecOps では、自動化と統合が非常に重要です。各チームは通常、微妙に異なる方法でアプローチしているため、ベストプラクティスと統合するための手順についての教育は非常に有益です。
そして、最後に取り組むべきことは予算です。より良く、より安全になるためには投資が必要です。トレーニングを受け、リスクを低減している人に報酬を与えることです。そして、それは単に良い習慣ではなく、実際にはビジネスの全体的な士気を高めることになります。Sonatype による最近の調査では、定期的にセキュアなコーディングトレーニングを受けている開発者は、仕事に満足している可能性が5倍高いという結果が出ています。
ここまで人の話をしてきましたが、次はプロセスの話をしましょう。
統治 (ガバナンス)
継続的セキュリティモデルでは、ガバメントは後回しにされていますが、実際には、セキュリティプログラムが始まるのはここからであることが多いのです。多くの組織がアプリケーションセキュリティを追求するのは、外部からのコンプライアンス要件からくるやむを得ない必要性があるためです。Payment Card Industry Data Security Standard (PCI DSS) やSarbanes-Oxley Act (SOX) は、一般的なコンプライアンスの推進要因の例であり、セキュリティガバナンスと整合性があり、最初の段階で優れた方向性を提供してくれます。課題は、継続的な改善と継続的なセキュリティという目標に到達できるように、プログラムを確実にその先に進めることです。
理想的な世界では、完全に柔軟なポリシーと実践があり、それが完璧に機能して、必要とされる卓越した運用を実現できるでしょう。方針と手順はビジネスの目標に沿ったものであり、自然と便利で安全な結果に向かって進んでいきます。
あまりにも多くの場合、私たちが持っているのは、多くのアラート、通知、監視、優先順位のジャグリングを生み出す、十分な量の自動化です。実際、CriticalStart が実施した 2019 年の調査では、セキュリティ担当者の 70%が1日に10件以上のアラートを調査しなければならないことがわかりました。受信するだけではなく、調査する 誰もが「左遷」する方法を模索している世界では、それらの調査には通常、開発チームが関与しています。そのような場合、35%がスタッフを増やそうとしているか、または大量のアラート機能をオフにしていることが同じ調査でわかりました。
これは、私たちが求めていたものとは正反対の結果です。
前述したように、適切なガバナンスはビジネスを可能にするものです。それはちょうど十分なルールを提供し、ポリシーの遵守、コンプライアンスへの対応、ビジネス目標の達成を確実にします。では、実際にどのようにしてそれを達成するのでしょうか。行動よりも結果を測定することから始めるのです。
簡単な例を挙げてみよう。休日の週末の金曜日の午後遅くです。コードはコミットされ、ビルドプロセスが実行されています。プロセスの一部には、新しいコードの変更を検証するためのセキュリティスキャンが含まれています。そして、それが起こります。クリティカルテストが失敗し、ビルドプロセスが開始され、メールが飛び交い始めます。次に何が起こるのでしょうか。
もしあなたが行動を測定しているのであれば、最初の質問は「いったい誰が悪いコードをチェックインしたのか」、「誰がコミット前にスキャンを実行しなかったのか」、「誰がそのライブラリを追加したのか」などです。この人が修正する必要がある人だという前提があるので、PERSONを見つけることに焦点が当てられています。
代わりに結果を測定しているのであれば、最初の質問はより可能性が高い"What?"です。何が悪かったのか」「何を見逃したのか」「どんなテストを行ったのか目標は、何が起こったのかを理解し、将来的にそれを防ぐことができるようにすることです。ビルドが始まる前に、より多くのスキャンを促すようにプロセスを調整する必要があるかもしれませんし、コードが消費されてレビューされる方法を変更する必要があるかもしれません。
重要なのは、ガバナンスがシステムのコントロールに影響を与える必要があるということです。ガバナンスは、アプリケーションのセキュリティに関する標準とルールの概要を説明しなければなりません。ガバナンスは、「当社の安全なコーディングガイドラインは何か」という質問に効果的に答えなければなりません。ガバナンスとは、ソフトウェアに関して意思決定を行い、期待されることを定義するための構造を形成する、ポリシー、標準、およびプロセスのフレームワークです。本質的には、ガバナンスは、セキュリティテストがなぜ、どのように全体的に行われているかを概説します。
まとめ
今回のブログでは、「Intensify」のテーマと「Educate」と「Govern」の能力に焦点を当てました。このシリーズの最終回では、「保証」のテーマと「測定と監査」の機能を見ていきます。
最後に、このシリーズの過去の記事を見逃してしまった方は、こちらからご覧いただけます。