「システムはハッキングできないので、なぜ脆弱性にパッチを当てるのですか？」
オペレーティングシステムがサポート終了（EoS）に達したため、OSのセキュリティパッチは今後リリースされません。このOSを実行している組み込みデバイスは、新しいバージョンに更新する必要があります。ただし、元の製品を設計したエンジニアは、マシンがハッキング可能ではないため、パッチを適用する必要がないと感じています。デバイスにはWiFi、イーサネット、USBポート、およびEoSに達したOSが搭載されています。
私が毎日尋ねられる質問：
- アプリケーションのホワイトリストがあるのに、なぜ脆弱性にパッチを適用する必要があるのですか？
- ファイアウォールがあるのに、なぜ脆弱性にパッチを適用する必要があるのですか？
そして私が得るコメント：
私たちの計画は、システムをさらに強化することです。これを行う場合、OSを更新してパッチを当て続ける必要はありません。だれもこの脆弱性に到達することはできません。また、OSの外側に面する部分の脆弱性を修正し（脆弱性自体にパッチを適用する機能がない場合でも）、外側に面していない脆弱性にパッチを適用しないでおくことができます。
Nessusクレデンシャルスキャンについて詳しく説明しました。これらのエンジニアに自分のポイントを伝える方法がわかりません。これをどのように説明できるかについての考えはありますか？
PDATE：システムにパッチを適用しています。みんなの反応と助けをありがとう。
（あなたがそれを報告しているように）状況の問題は、多くの意見で多くの仮定がなされていることです。あなたはあなたの意見を持っていて、彼らにあなたの意見を共有してもらいたいのですが、彼らは彼ら自身の意見を持っています。
みんなが何かに同意するようにしたい場合は、共通の根拠を見つける必要があります。あなたはそれぞれの仮定に挑戦して確認し、あなたの意見や彼らの意見を裏付けるハードデータを見つける必要があります。共通の基盤があれば、すべて一緒に前進できます。
- あなたはホワイトリストに登録しています：すばらしい、それはどういう意味ですか？それを回避する方法はありますか？ホワイトリストに登録されたアプリケーションが破損することはありますか？
- ファイアウォールは何をしますか？設定方法は？ファイアウォールはポートのブロックを意味しますが、許可ポートも意味します。これらの許可されたポートが悪用される可能性はありますか？
- 誰もアクセスできませんか？誰がデバイスにアクセスできますか？あなたはそれを安全に保つためにインサイダーまたはユーザーの無知を信頼していますか？
- 誰かがデバイスへのローカルアクセスを取得するとどうなりますか？それはどのくらい可能性がありますか？
情報セキュリティの専門家としてのあなたの仕事は、「ベストプラクティス」で人々を打ち負かすのではなく、リスク分析を実行し、費用効果の高い方法でリスクしきい値を下回るリスクを制限する方法を設計することです。 notベストプラクティスを採用して正当化する必要がありますが、正当化が有効であれば、それは有効です。
誰かが彼らのマシンがハッキング可能ではないと私に言って、私がそれらを信じるべきであるなら、私はすぐにそれを結論付けます
- この機械は、フォートノックス/高セキュリティの刑務所の条件下で、24時間年中無休の警備員と防犯カメラで監視されています。
また、次のいずれか：
マシンはいかなる種類の情報も交換しません（USB、イーサネット、ファイアワイヤー、シリアル、パラレルなど、いかなる種類もありません）。
マシンの電源は完全にオフになっています。
多層防御のセキュリティ戦略が必要なため。ファイアウォールがありますが、ファイアウォールにセキュリティの脆弱性がある場合はどうなりますか？アプリケーションのエクスプロイトがユーザーレベルのOSアクセスを許可し、パッチされていないOSの脆弱性によりルートアクセスにエスカレートされる場合はどうなりますか？適切なセキュリティを確保するには、パッチを適用する必要がありますallシステムで悪用される可能性があると考えられる脆弱性だけでなく、既知の脆弱性も修正する必要があります悪用されると、それ自体ではできない場合でも妥協できる可能性があり、未知の脆弱性に対してパッチを適用することはできません。
その理由は単純です。セキュリティがレイヤーで適用されています。たとえば、重要なデータベースに接続するには、まずデータベースのネットワークにアクセスし（ファイアウォールを通過）、接続を許可するクライアントのリストに独自のIPアドレスを追加してから、ユーザー名とパスワードで接続を開始する必要があります。レイヤーのいずれかは、他の2つを冗長にします。問題は「what if」です。古いOracleのデフォルトのscott/tigerログイン、または従業員がうっかりポートをパブリックインターネットに転送したとしましょう。ファイアウォールがTCPのみをブロックしている可能性がありますが、サーバーもUDPでリッスンしているか、IPv6が正しく構成されておらず、セキュリティはIP4にのみ適用されます。これが、適切なセキュリティが層状になり、試行が監視され、セキュリティの専門家が試行された（できれば失敗した）攻撃から学ぶか、ハニーポットのアクティビティを検査する理由です。また、攻撃者は各レイヤーのエクスプロイトを必要とするため、ゼロデイエクスプロイト（最新のパッチにも適用されるエクスプロイト）がレイヤード環境で成功する可能性は低くなります。
どのデバイスもハッキング可能ではありません。以前にハッキングされたことがないだけです。デバイスにほとんど関心がないか、ペイオフが非常に低いかのどちらかです。ゼロデイエクスプロイトがまだ存在する可能性があります。
また、一部のAndroidデバイスは単に特定のバージョンを超えてアップグレードすることはできません。デバイス名/ブランドがどのように正確にレシピを運ぶので、敵がそのようなデバイスを持っていることを知っていることは、ハッキングのオープンな招待です。それをハックする。
アクティブサポートなしでデバイスを維持することは、機能の観点からも危険です。
セキュリティは、部外者（ファイアウォール）だけでなく内部者からも保護するように設計されている必要はありません。デバイスが実行されているコンテキストはわかりませんが、あなたが書いた内容を考えると、ファイアウォールの内側にすでにいる誰かに対して脆弱である可能性があります。
ハッキングできないシステムはありません。エアギャップについて言及している人のために、エアギャップシステムでの実際のハックまたは潜在的なハックの例がたくさんあります。 Stuxnetはおそらく最も有名な（そして最も極端な）例です。その他には、ファン・エック・フリーキング、音響分析、またはその他のサイド・チャネル攻撃が含まれます。
パッチを必要としない脆弱性を軽減する方法があります。たとえば、システムがKRACKに対して脆弱である場合、単にWiFiを無効にすることは可能ですか？ WiFiが永続的に無効になっている場合、WiFiに関連する更新を適用する必要はありません。同様に、脆弱性をもたらす特定のアプリケーション（Java、.NET、Flash、ブラウザーなど）がシステム上にある場合、それらのアプリケーションをアンインストールするだけで済みます。インストールされていない場合でも、Javaを更新する必要はありません。
OSのアップグレードでは、これは確かにより困難です。潜在的な脆弱性を認識してから、それらを軽減する必要があります。サポートされているOSを使用する利点は、他の誰かが（おそらく）最初の部分と2番目の部分の半分をすでに実行していることです。
完全に更新またはアップグレードされたシステムは、安全なシステムやハッキングできないシステムではありません。しかし、既知の脆弱性のリスクを最小限に抑える傾向があります。 Schroederをエコーするには、リスク分析は「強化/ロックダウン」または盲目的に「アップグレード」することよりも重要であり、どちらかがより安全になることを期待しています。
真に「ハッキングできない」システムはありません。ただし、システムが十分に「ハッキング不可能」であると判断したら、セキュリティパッチのチャネルを維持する必要はありません。
具体的な例として、「ハッキングできない」システムが防犯カメラを制御しています。カメラの仕事は、固定された場所を見ることです。すべての設定は一定であるか、システムはそれ自体で調整できるほどスマートです。システムはビデオデータをストリーミングし、ユーザーからの入力を必要としません。
定期的にログインしてセキュリティパッチを適用できるようにシステムにsshを実行させることができますが、実際には（非常に小さな）セキュリティホールが開かれます。攻撃者はsshを使用してカメラをハッキングする可能性があります。 （sshをハッキングする幸運）。
したがって、それはトレードオフです。セキュリティパッチを適用する必要がないと正直に信じる場合、そのチャネルを開いたままにしておくことは価値がないと判断するかもしれません。
私が出席したプレゼンテーションから、政府のために構築しているシステムについて誰かが説明したところから、このアイデアを得ました。システムのコンポーネントは、寿命の短い仮想マシンでした（通常は1日未満）。各仮想マシンは不変で使い捨てでした。計画では、セキュリティパッチを適用する必要がある場合は、マシンを規則正しく廃棄し、新しいマシンを作成するだけでした。仮想マシンにはsshがありませんでした。
政府のセキュリティ監査人がガスケットを吹き飛ばし、セキュリティパッチを適用できるようにsshをインストールさせました。 sshサーバーはセキュリティ上の価値を提供せず、実際にはホールでした。
しかし、考えてみると、この（そして私のカメラ）の例は、従来のチャネル以外のセキュリティ更新プログラムにすぎません。
どうですか
- 火星に配備されたカメラ...誰もがカメラについて知っていて、誰もがカメラのデータを見ることができます
- 敵の背後に密かに存在するカメラ（敵がカメラについて知っていれば、簡単にそれを取得できます...セキュリティ更新のためのチャネルを維持したいですか？）.
彼らがそれをハッキングする方法について（今のところ）考えることができないという事実は、それが「ハッキング不可能」であることを意味しません。これが、原則として、アクセスできないはずのコンポーネント上であっても、すべてのセキュリティパッチを適用するためです（たとえば、攻撃者がユーザーアクセスさえもしなければ、特権昇格の脆弱性にパッチを適用するのはなぜですか？）。
さて、それらはmayであり、パッチを適用しないことが実際のケースでは正しい決定である可能性があります。しかし、私がそれを全面的に受け入れる人はほとんどいません。そして、それらのエンジニアはおそらく実行中のセキュリティ監査について特に知識がありません。
それらを説得するための議論として、私は彼らに、ジューシーな賞金に興味がある人（例えば、彼らは家に賭けるのか？）にこれらのデバイスの1つへのアクセスを提供するように依頼します。
彼らがそれを行うことに不快であれば、まあ、彼らは実際にはそれがハッキング不可能だとは考えていません。そして、そうすることで重要な情報が明らかになると彼らが考える場合、それは彼らが無名によるセキュリティに依存していることを意味します。攻撃者がその仕組みについてすべて知っていれば、実際のハッキングできないシステムはハッキングされる可能性があります。
PS：彼らが家を賭けていない場合でも、バグ報奨金プログラムを実装することは本当に有益です。
「システムはハッキングできないので、なぜ脆弱性にパッチを当てるのですか？」あなたの質問では、あなたは間違いと証明不可能な議論（「どうやってあなたは知っているそれが「ハッキング不可能」であると知っていますか？あなたはそれをハッキングできないので、他の誰もハッキングできないと思いますか？」）しかし結局のところ、リスクの受容性と、誰がそのリスクを受け入れようとするかについての議論に行き着くと思います。このように彼らに説明してみてください
"アプリケーションのホワイトリストがあるため、なぜ脆弱性にパッチを適用する必要があるのですか？"
アプリケーションのホワイトリストは、ホワイトリスト自体、つまりそのホワイトリストにないアプリをブロックするツールと同じくらい優れており、アプリケーションのホワイトリストツール自体に障害や脆弱性がないことを前提としています。また、未知の/信頼できないアプリケーションからのみ保護します。攻撃者が「陸地に住み」、システム自体のツールを使用することを決定した場合はどうなりますか？ OSの一部としてホワイトリストに登録したアプリケーションの1つに脆弱性がある場合
"ファイアウォールがあるので、なぜ脆弱性にパッチを適用する必要があるのですか？"これは事実上、前のものと同じ議論です。ネットワークスタックやファイアウォール自体、またはそのネットワークスタックを介してリッスンしている、またはアクセス可能なアプリケーションやサービスに脆弱性がないことは、疑いの余地なく、確実に100％確実ですか？
上記に対する彼らの回答が彼らの選択と決定について100％肯定的であるというものである場合、私はそのリスクの彼らの受け入れを詳述する文書を書き、CIOに至るまで彼らのリーダーシップチームによって承認されます。最終的には、システムが侵害された場合に問題を抱えているのは彼ら（CxOレベル）であり、議会（または政府が監督する機関）の前に呼び出される可能性があるのは、経営幹部です。エクイファックスでは。システムを更新し、パッチを適用するために力を尽くしているわけではない（多くの異なる資格認定および監視グループ/法律で必要とされる）こと、および彼ら（CxO）が責任ある態度を保つことができると経営幹部に説明したときしばしばシフトします。
元の製品を設計したエンジニアは、マシンがハッキング可能ではないと感じています
タイタニック号を設計したエンジニアは、それを沈めることはできないと感じました。
ITの問題は、システムを更新する必要がないことです。なぜ稼働中のシステムを変更するのでしょうか。次に、これらの企業が見出しを出します。「4件の工場がxの発生により閉鎖された」または「x社が侵害され、y万人の顧客の個人情報が漏えいした」。
IBMのクラウドが最近すべての顧客を強制的にTLS 1.1（はい、すでに廃止されたバージョン）に移行し、一部の顧客が不満を言っていると想像してみてください...彼らの言い訳は何ですか、彼らはどこでもTLS 1.2を実行しているはずです！ IBMは行進しました、受け入れられません！
これで、厩舎の黒いユニコーンがすべてをTLS 1.2に移動するのを妨げていることを教えてくれます。それを処分して、黒いユニコーンを販売している会社とは取引しないでください...私たちは業界としてこれをしていませんそして、違反は見出しを作ります、違反は私たちがレッスンを学ぶまで見出しを作り続けます。
マシンはハッキング可能ではないと感じる
気持ちは関係ありません。事実はそうです。
リスク評価や脅威モデルに戻ります。ソフトウェアにパッチを当てるか、ソフトウェアを最新の状態に保つことがリスク治療計画の一部であったかどうかを確認します。古いソフトウェアがリスク分析または脅威モデルの一部であったかどうかを確認します。
これらのファクトを使用してエンジニアに戻り、ソフトウェアが古くなっていないという事実に基づいて、リスクがどのように変化するか、どの脅威が未処理になるかについて、彼らと話し合います。また、悪用される可能性のある欠陥が発見される可能性が高まるため、この特定のリスクが時間の経過とともに増加することも考慮してください。だからあなたの製品の合理的な寿命が尽きるまで先を見てください。
彼らの緩和行動はリスクを許容できるものにするかもしれないことに注意してください。しかし、これは議論され、リスク計画が更新される必要があります。また、今日ではリスクを許容できるようになった可能性もありますが、数年後にはそれが不可能になります。それで？エンジニアに対する議論を探すのではなく、彼らと同じページに行きましょう。あなたは少なくとも、緩和行動が必要かもしれないことを理解しています。
これは技術的な決定ではないかもしれません。外部から提供されたコンポーネントを使用することは、一般に、そのコンポーネントを製造元のガイドラインに厳密に従って使用する必要があること、またはallでスタックされるリスク、およびそれが関与する可能性のある障害から生じる結果と責任を意味します。
したがって、デバイスが正常に動作せず、誰かが怪我をした場合（または他の何らかの責任が発生した場合）、元のOSメーカーは「サポートされていないソフトウェア-私たちの問題ではない」と言います。そして、あなたの会社の保険会社は「サポート対象外の時代遅れのソフトウェアを使用する-それは過失であり、私たちの問題ではない」と言うでしょう。
したがって、個人的な観点から、サポートされていない古いコンポーネントを引き続き使用するという肯定的な決定を下しているユーザーに確認してください。
- 彼らがそうしていることが示されています（そしてあなたはそれを書面で持っています）
- アップグレードが不要であると断定的に主張した（そして彼らはそれを書面で作成した）
「このアップグレードを行う必要はない」と「このアップグレードを行わない責任は個人的に認めます」との間には大きなギャップがあります。
実際には、実際に技術的な必要がない場合でも、コンポーネントがEOLに移行することによって義務付けられているアップグレードが頻繁に行われます。これは、複雑な製品のエンジニアリングに必要な部分です。
デバイスにWi-Fi接続がある場合、ネットワークを介して攻撃される可能性があります。その攻撃は成功しますか？これは、デバイスを攻撃することの利点と、必要な労力のレベルの問題です。時代遅れでサポートされていないOSをベースにすることで、攻撃方法が確実に簡素化されます。
アプリケーションのホワイトリスト登録は保護ではなく、小さな障害です。あなたは、ハッカーがアプリのホワイトリストの1つになりすましているアプリを開発できないと思いますか？もちろん、彼らはできます...最初の試みが実行されない場合、彼らは調査するかもしれません。
Equifaxにはかなりのファイアウォールが設置されていました。 EquifaxのITマネージャーがパッチを当てることができなかったStrutsホールを、ハッカーが不必要に開いたままにされたポートを介して悪用するのを阻止しませんでした。ファイアウォールは、以前の明らかな攻撃の一部を阻止するだけです。
ターゲットのハックを思い出してください-CEOとCIOはその仕事を失いました。それは、ターゲットが古いWindowsバージョンを使用していて、更新されていないことに加えて、インサイダーによって実行されました。 POSデバイス。疑いもなく、CIOはPOSデバイスでWinバージョンを更新するのは非常にコストがかかると結論付けました。これは非常に間違っていることが判明した判断です。
組み込みファームウェアはハッキングの影響を受けないと思いますか？ HPプリンターハックを検討してください。 HPは、簡単に開始できる印刷ジョブを通じてプリンターファームウェアを更新するという賢いアイデアを持っていました。それまでは...誰かがプリンタをスパムリレーに変えるファームウェアバージョンを思いつき、それをマルウェアの印刷ジョブで配信していました。
ファームウェアのアップデートはどのように行いますか？ wi-fiを通じて？はい、ハッカーはそれを複製することができます...十分な理由がある場合。
ネットワークに接続されたデバイスは、ハッキングされてボットネットの一部になる可能性があります。DOS攻撃を開始する一般的な方法です。ハッカーは脆弱性を発見し、それが会社の評判を損なうことを知っている場合、会社の株を短絡させると同時に攻撃を仕掛けることができます。それが起こりました... PIIおよびCC情報を盗むことは、ハッキングから利益を得る唯一の方法ではありません。
さて、自問してみてください-個人的にあなたにとってのリスクは何ですか？システムがハッキングされた場合、特に更新されていないOSをベースにしているため、潜在的な脅威を特定して軽減するために十分な注意を払ったことを会社の幹部に示すことができますか？ヒント：システムが「ハッキング不可能」であると言うエンジニアの言葉を取ることは、おそらくデューデリジェンスとはみなされません。
さらに言えば、エンジニアがハッキング不可能だと言った場合、おそらく彼らは潜在的な脆弱性を探していないだけでなく、それらを緩和することもしていません。
システムをハッキングできないと言う人は現実的ではありません。この日と年齢ではありません。
私には簡単に思えます。ハッキングできないと思われるシステムにパッチを適用しないことについて、議論の中でどのようにポイントを獲得するかという問題に戻ります。そのシステムが侵害された場合に起こり得る最悪のシナリオは何ですか？配置されているすべての保護が失敗するか、同様に違反すると想定します。あなたはそれが違反される可能性があるか、または違反されるとは思わないので、結果を排除することによってこの演習にバイアスをかけないでください。
次に、この最悪のケースのシナリオを、収益の損失、法的/規制上の罰金、または業界における会社のイメージへの損害という形で、ビジネスに影響を与えるコストの条件に入れます。
その影響が深刻な場合は、エンジニアを目で見て、「あなたは、あなたの仕事、そしておそらくあなたの全キャリアを、これが決して起こらないであろう方向に進んでいますか？それがどのように起こったかを説明し、EOLオペレーティングシステムを引き続き使用し、パッチ適用が不要であると見なすという意識的な決定は、リストの最上位ではないにしても、リストの近くになります。」
一方、ビジネスへの影響がそれほど大きくない場合は、EOL OSの使用を継続することは理にかなっています。しかし、それをリスク管理の行き届いた方法で最適に行う方法は、別のトピック全体です。
あなたが利用できるリソースに応じて、「ばか証明」（すべての同僚に敬意を払って）の方法は、システムがハッキング可能であることを証明することです。できる人を雇って、その人にシステムの弱点を実演させてください。私の推測では、WLANを使用することは、それほど難しくはないはずです。 WLANとファイアウォール？これは形容詞の矛盾です。
後付け：おそらく、成功した場合の支払いに同意することは可能です（私の辞書では「緊急時の手数料」と呼んでいます）。そうすれば、（ハッキング）サービスは常にお金の価値があります。