HEIST はリスクか脅威か?
セキュリティ専門家の役割は、リスクと脅威の違いを理解し、それに応じて行動することです。 素人（つまり私たちのほとんど）にとっては、この 2 つの違いは存在しないように見えるかもしれません。 結局のところ、それらは意味的に同等ではないでしょうか? 脆弱性や DDoS 攻撃、最新のゼロデイ攻撃を説明するときに、これらを同じ意味で使用していませんか?
そうかもしれませんが、セキュリティのプロは、多くの場合、それよりもはるかに厳密です。主な理由は、そうでない場合、防御を破るために使用されるツール、テクニック、テクノロジーの蓄積の増加に対してデジタル戦争を繰り広げる際に、予算が IT 全体を上回ることになるからです。 すべての脅威が同じリスクを伴うわけではないからです。
リスクとは、発生の可能性や悪用された場合の影響など、さまざまな要因を考慮して計算された測定値です。 私たちは、今日、道路を横断中にバスに轢かれて悲惨な結果に遭う可能性があると知っていますが、その可能性は非常に低いため、ほとんどの人はそれを非常に低いリスクだと考えています（リスクメーターで測定した場合ですが）。 逆に、ウィスコンシン州の真冬に、接地面のない 3 インチのヒールを履くと、転倒して好ましくない結果を招く可能性が高くなるため、個人的には、冬の間はかなりリスクが高いと考えています。
それはリスクです。
脅迫はまた別の話です。 他にも、天気やバスの路線、攻撃者が今日私たちのウェブサイトにボリューム型攻撃を仕掛けるかどうかなど、私たちが制御できないことがあります。
セキュリティ専門家とその組織の目標の 1 つは、脅威を軽減し、悪用される可能性を減らすことでリスクを最小限に抑えることです。 気温が零下20度で、私道が氷で覆われている場合は、平らで靴底のしっかりしたブーツを履きます。 脅威は軽減されます（完全に排除されるわけではありません）。したがって、リスクは軽減されます。 新たな脆弱性が突然発見された場合、その新たな脅威が組織にどのようなリスクをもたらすかを判断する必要があります。
実際、これはリスクを評価するための方法論として広く受け入れられており、業界ではこれを数学的に説明しています。
A(セット) + V(脆弱性) + T(脅威) = R(リスク)
これにより、個々の組織は、ビジネス要件とリスク許容度に応じて個々の要素に重み付けするだけでなく、一貫した行動をとることができます。 これにより、特に評価されたリスクが組織の許容範囲内であることが判明した場合に、新たな脆弱性が発表されたときにパニックに陥ったり、反射的に反応したりすることを防ぐことができます。
それで、HEISTはどうですか?
ここで、HEIST について説明します。HEIST は、HTTP 暗号化情報が TCP-Windows 経由で盗まれる可能性があることを意味します。 HEIST の方が明らかに言いやすく、まるで Mission Impossible のように聞こえませんか? この脆弱性はBlackHatで発表され、現在でもArs TechnicaやEngadgetの記事を通じてインターネット上で広まっています。 今のところ、野生では目撃されていない。 これは簡単に悪用できる脆弱性ではなく、私たち自身を含む研究者は、HEIST を悪用するのは簡単な作業ではないと指摘しています。 これは、ブラウザ API の動作 (応答の時間を計測できるブラウザ API を使用して TCP が通常どのように動作するかを観察します)、Webapplicationの動作、コンテンツ圧縮、TCP、暗号化を組み合わせた複雑なサイドチャネル攻撃です。
この攻撃は、複数のリクエストを完了する必要がある場合はネットワークに負荷がかかる可能性がありますが、「ノイズの多い」カテゴリに適しています。 どちらも、注目されたくない悪質な行為者にとっては魅力的ではありません。 しかし、もしこの脆弱性が悪用されれば、攻撃者はこれをBREACHやCRIME と組み合わせてペイロードを復号化し、いわゆるデジタルジャックポットを獲得して、機密性の高い（おそらくは重要な）個人情報やビジネスデータを公開する可能性があります。 その場合、彼らは、個人を特定できる情報 (PII)、つまりデジタルジャックポットを入手することに成功すれば、どれほど騒がしくても気にしない可能性が高いでしょう。
これは脅威です。 データの流出に使用される可能性があります。 それは違反行為と呼ばれ、非常に悪いことです。 問題は、この脅威がいつ本当のリスクになるのかということです。
さて、今日（正確には、私がこれを書いたとき）、この脅威は実存的なものではありませんでした。 つまり、野生では見られなかったのです。 しかし、それは野生に存在しないという意味ではなく、野生では見られていないというだけです。 まだ。 今日。 今すぐ。
頭がくらくらしてきましたか? これで、セキュリティ専門家がいつもぼんやりとした表情を浮かべている理由がお分かりいただけたと思います。 なぜなら、彼らは常にこのような思考プロセスと意思決定を管理しなければならないからです。
そこで疑問になるのは、この脅威が実存的なものになった場合、どのようなリスクがあるかということです。 その答えを得るには、脆弱性が悪用された場合にどのような影響が出るかを判断する必要があります。 誰かがあなたのアプリやサイトからデータを盗み出すことに成功した場合、どのような影響があるでしょうか? 費用はいくらになりますか？ ブランドの影響も忘れずに考慮してください。これは（ますます複雑になる）方程式の一部です。 緩和のコストも同様です。 緩和コストが比較的影響の少ない解決策に比べて高い場合、方程式は変わります。 脅威を軽減するために、データセンター（およびクラウド）内のすべての Web サーバーにアクセスし、設定を 1 つ調整する必要がある場合、存在を脅かす可能性のあるものに多くの時間（および結果的に費用）を費やすことになります。 リスクが低ければ、少年が「狼だ」と叫んだからといって慌てふためくのではなく、当然ながら「様子を見る」という態度を取るでしょう。
軽減策の実装コストへの影響が比較的小さい場合、たとえば、返されるデータのサイズを変えることで攻撃者を混乱させ、HEIST の実行を困難にする単純なスクリプトなどであれば、先に進んで導入することを検討してもよいでしょう。 結局のところ、リスクをさらに下げるためのコストは最小限であり、将来この HEIST が実行された場合の結果よりもはるかに少ないことはほぼ間違いありません。
絶え間ない（再）バランス調整
現実には、セキュリティとは、ほとんどの IT 組織が抱える政治的な地雷原をくぐり抜けながら、脅威を軽減してリスクを最小限に抑えるための絶え間ない戦いなのです。 IT が機能ごとにサイロ化されているため、セキュリティ専門家は、リスクの可能性が変動する脅威に対して、単純な緩和策を実装する取り組みさえも行わないと決めることがよくあります。
彼らは、積極的に脅威を軽減するのではなく、リスクが高まり、対応を余儀なくされるまで待ちます。 たとえば、過去 2 年間で最も話題になったエクスプロイトの多くは、applicationに重点を置いたものでした。 これらを軽減するには、applicationの上流のデータ パスにソリューションを展開する必要があります。これは、最も効率的かつ効果的な場所は、拡張と配信のためにapplicationsが最終的に集約されるポイントであるためです。 しかし、その戦略的な制御ポイントは、セキュリティ チームではなく、application配信チームによって管理されます。 こうした脅威を早期に軽減するために必要な努力は、リスクを上回ります。 いわば、2 つのグループが中間点で出会う能力は組織にとって常に課題であるため、application層でリスクを積極的に軽減し、脅威を緩和することは簡単には実現しません。
現時点では、HEIST はほとんどの組織にとってリスクが低いと考えられています。 しかし、誤解しないでください。これは脅威であり、実行に移される前にその存在について私たち全員が知らされている今こそ、検討する価値があります。 脅威が現実のものとなり、悪用されるリスクによって誰もがその対処に多額の費用のかかる活動や実装に追われる前に、HEIST のこの緩和策のような「サーバーレス」セキュリティ ソリューションを導入できるように、相互調整が必要です。