アプリケーションのセキュリティを基本路線に引き戻すには

Getting Application Security Back on the Rails

2021/08/09 StateOfSecurity — 米国の National Institute of Standards and Technology (NIST) は Interagency Report 7695 において、アプリケーションを「コンピュータを用いてデータを収集/保存/処理/表示するためのシステム」と定義している。この広範な用語には、エンタープライズ・アプリケーションと、コンシューマ・アプリケーション、さらにはモバイル・アプリも含まれる。セキュリティは、これらすべてのタイプのアプリケーションで重要だが、その焦点は必ずしも同じではない。以下、その理由を見ていこう。

アプリケーションの種類によるセキュリティの違い

エンタープライズ・アプリケーションは、企業や法人が使用するアプリケーションであり、PCI DSS や HIPAA などのコンプライアンス基準を求められることが多い。そのため、ソフトウェアが安全でないことを知りながら放置された場合、法律上および財務上の問題が発生する可能性がある。例として、企業の POS (Point-of-Sale) システムを挙げてみよう。組織によっては、適切な PCI 保護が施されていない他のエンタープライズ・アプリケーションと、POS システムをリンクさせている場合がある。このような場合、罰金や評判の低下などの、ペナルティが課せられる可能性がある。

エンタープライズ・アプリケーションの別の例として、患者の健康情報 (PHI) の保護に責任を負う組織を考えてみよう。PHI を安全に保管し、許可されていない人が、それらのデータにアクセスできないようにすることが、HIPAA に基づく義務となる。PHI を公衆回線の FAX や、暗号化されていない電子メールで送信することは、コンプライアンス上の義務を果たすことにはならず、HIPAA 違反の罰金を科せられる危険性がある。これらのセキュリティ要件は、コンシューマ・アプリとモバイル・アプリでは変化していく。前者のプログラムは、一般的に、エンタープライズ・アプリケーションほどのセキュリティの精査を受けないため、コンプライアンスの義務が少なくなる。そして、モバイル・アプリのセキュリティは最も低いものとなっている。

アプリケーションのセキュリティが不十分な理由

最近では、すべての企業が、アプリケーションのセキュリティに関心を持っているわけではないようだ。その理由をいくつか挙げてみまよう。

・市場投入までの時間が勝負:IoT ブームが続く中で、想像し得る限りのデバイスが、インターネットを介してリモート・アクセスできるようになってきた。これらのデバイスを管理するアプリは短時間で作られるが、往々にして、セキュリティは後回しにされる。それは、IoT アプリケーションに限ったことではない。つまり、数多くのショッピングアプリ、ビジネスアプリ、フードデリバリーアプリでも、同じことが起こっている。

・セキュリティ専門家の不足:最近、セキュリティの専門知識やバック・グラウンドを持つ人材が求められている。Tripwire の 2020年の調査では、セキュリティ専門家の 83% が、1年前よりも過労を感じていることが判明した (パンデミックの前の話であり、1年後の惨状を想像してほしい!)。ほぼ同じ割合である 85% の回答者が、この数年の間に、熟練したセキュリティ専門家の雇用が難しくなったと答えている。このようなスキル・ギャップにより、アプリケーションのセキュリティ確保を主導できる専門家を、企業が採用することが難しくなっている。

・役割の誤解:多くの新しいアプリケーションはクラウド・サービスに依存しており、関連するセキュリティの役割/責任の理解について、ギャップが存在することが多い。クラウド・ベンダーが、すべてのセキュリティ・ニーズに対応する責任を負っていると思われがちだ。また、モバイル・アプリでも、携帯電話の OS が全てを保護していると思われがちだが、それらは誤りだ。

アプリケーション・セキュリティのベスト・プラクティス

難しく考える必要はない。企業は、いくつかの重要なベスト・プラクティスに従うことで、アプリケーションのセキュリティを強化できる。たとえば、アプリケーションをリリースする前には、自社のコードだけでなく、サードパーティのコードやパッケージの脆弱性についても、詳細なセキュリティ評価を行う必要がある。もちろん、既知の脆弱性の全てが、高い優先度/深刻度を持つわけではないので、セキュリティ上のリスクの優先順位付けが、企業にとって必要な検討事項となる。その上で、既知の脆弱性の優先順位に基づき対処するための、パッチ適用スケジュールを作成する。悪用される可能性のある、優先度の高い脆弱性を持つアプリケーションは、絶対にリリースすべきではない。

その一方で、データの漏洩やデバイスの悪用に利用できない、優先度の低い脆弱性に関しては、次のリリースまでパッチの適用を延期することも可能だ。脆弱性は、組織にとって、必ずしも最大の関心事ではない。特にクラウド環境では、安全な設定のほうが、より広範な問題となる。Black Hat USA 2019 の参加者を対象とした調査では、回答者の 84% が Tripwie に対し、組織がクラウドで安全な設定を維持することは困難であると回答している。また、それらの調査参加者の 5分の1近くである 17% が、極めて難しいと答えている。これらの調査結果は、調査に参加したセキュリティ専門家の 4分の3が、クラウドを通じて誤ってデータを公開することは、容易に生じてしまうと答えた理由を、十分に説明できるもと考えられる。

Tripwie の支援方法

すべての組織が、自社のアプリケーションの脆弱性や安全な設定を、自分たちで管理できるわけではない。そのため、企業は、顧客の環境全体におけるセキュリティ機能について、管理の実績のあるベンダーを探すことも可能である。

文中のリンクから NIST Interagency Report 7695 を開いてみましたが、2011年に発行された Common Platform Enumeration : Naming Specification というドキュメントでした。ひとことで言うと、10年前に書かれた、命名のためのガイダンスなのでしょう。この記事の言う、基本に戻って見直すというスタンスは、いつの時代にも必要なことだと思います。急がば回れも、転ばぬ先の杖も、急いては事を仕損じるも、きっと同じことを言っているはずです。先日の「サプライチェーン・セキュリティ:見た目ほど簡単ではない」というポストも、俯瞰を推奨する良い記事です。まだの方は、あわせてお読みください。この記事のスポンサーだと思われる、Tripwie に感謝です。

%d bloggers like this: