インサイダーが不正になり、重要なインフラストラクチャに悪影響を与えることに対して企業は何ができますか？
2013年に Citibankの従業員 は、彼を怒らせた悪い業績評価をしました。結果は壊滅的でした：
具体的には、午後6時3分頃です。その夜、ブラウンはコードとコマンドを意図的に10基のシティバンクグローバルコントロールセンタールーターに送信し、そのコードを送信することで、9台のルーターの実行中の構成ファイルを消去し、すべてのシティバンクネットワークの約90％への接続が失われました。北米中。
さて、 内部からの攻撃に対してネットワークを保護する についての質問がありますが、その質問は内部者が不正になることを明示的に除外しています。 データベースを内部者から保護する についての質問もありますが、それは上位層の問題に関するものです。
私も セキュリティ違反に対して従う手順は何ですか？ を読みますが、そこで行われるほとんどの回答は、内部関係者が解雇された従業員であることに基づいて行動します。私はまだ解雇されていない人について尋ねています。彼らは貧弱なパフォーマンスレビューを行った可能性がありますが、まだ終了していません。彼らはパートナーがしたことに不満を抱いているだけかもしれませんし、何かに腹を立てているかもしれません。
ここで私が説明している問題は、仕事に不満を抱いているユーザーが特定の日にスナップし、発行する完全な特権を持っているシステム破壊コマンドを発行する大企業です。マシンの拭き取り、重要なインフラストラクチャの物理的な損傷など...純粋に技術的な干渉、電子メールや秘密の漏洩のようなものはありません。目的は、インフラストラクチャにできる限り多くのダメージを与えて、強打で外に出ることです。
この記事では、やるべきことについておおまかに言及していますが、具体的な内容はありません。突然の不正なインサイダーが、特権的な手法を使用して重要なインフラストラクチャに悪影響を及ぼさないようにするには、どのようなことができますか？
Two-man rule-すべての特権アクセスに2人が必要になるようにシステムを構成します。
これは物理的な制御である可能性があります-特権アクセスはNOCからのみ行うことができ、NOC内では人々が物理的にルールを施行します。
より実用的なのはスクリプトシステムです。システム管理者はrootアクセス権を直接持っていませんが、rootとして実行するスクリプトを送信できます。スクリプトは、別のユーザーがスクリプトを確認して承認した後にのみ実行されます。緊急時にSSHアクセスするための方法が依然として必要です。この場合、物理的な制御を使用して2人ルールを維持できます。
NSAはこれを実装しました Snowdenがリークした後。私は、監査した商用または政府のシステムで完全な2人構成のシステムを見たことはありません-さまざまな部分的な試みを見てきました。
更新- 別の質問 にこれを実装する方法の詳細があります。
突然の不正なインサイダーが、特権的な手法を使用して重要なインフラストラクチャに悪影響を及ぼさないようにするには、どのようなことができますか？
実際には、ほとんどありません。しかし、その理由を説明するために、あなたが何ができるかについてお話しさせてください。
ここでの問題は、ユーザーが「特権」を持っていることです-彼らは正当に権限を与えられています。
権限のある管理者であっても、正当なユーザーに与えられる権限を制限するためにできることがいくつかあります。
- SudoやPowerBrokerなどを使用して、使用可能なコマンドを制御します。
- デュアルコントロール（「2人ルール」@ paj28は、
- ワークフローコントロール（多くの場合、デュアルコントロールの形式です）
現在、これらのコントロールは、実際よりもはるかに少ない頻度で使用されています。どうして？ 特権ユーザーは定義によって信頼されているためです。したがって、私は非常に少ないと言いますそれ。
また、ここでの攻撃ベクトルは「配管工事」であったことにも注意してください。シティバンクにデュアルコントロールがある場合、おそらく送金などに集中していますが、この攻撃はひざまずいて、基盤となるネットワークをダウンさせました。これらの重要でありながら静かなシステムは、多くの場合、特権ユーザーの小さな輪を持ち、過度の制御はあまりありません。
ここでの実際の失敗は、技術的な制御がなかったことではなく、人事管理が惨めに失敗したことでした。以前に特権のある従業員のアクセスを取り消すのは標準的な方法ですそれらは終了します。特権のある従業員との紛争を導入するときにそのような予防策は必要ないと決定した人は誰でも、貧弱な判断をしました。
（同社は懲罰的管理も行った-攻撃者は今や約2年の懲役を言い渡され、約8万ドルを支払わなければならない。記事が指摘しているように、これらのことはこれを修正するものではない。）
1つのアプローチは、不正行為を防止できないことを受け入れ、損害を確実に修復できるようにすることです。たとえば、ルーターに、オンラインに戻すための個別のコントロールプレーンがあることを確認します。読み取り専用のバックアップ（オフサイトのテープなど）があることを確認してください。誰かがすべてのハードドライブを消去した場合でも、データを回復できます。データとコードを既知の良好な状態にすばやくロールバックできることを確認します。
これらの保護手段は、意図しないミスがあった場合にも役立ちます。
監査。特に、ネットワークトラフィックと、特定のマシンで実行されたアクション/操作。キャプチャしたいwhoしたwhat、いつしたかそしてwhereから。これは攻撃を防ぐことはできませんが、インサイダーがそれらを特定して捕まえると信じている場合、そのようなアクションを阻止するのに役立ちます。
次に、改ざん防止監査メカニズムの問題に取り組む必要があります
システムまたはネットワークを内部関係者から、最も具体的には自分の仕事の説明から、そのようなシステムの作成と管理を含む人々から保護するという問題は、常にトリッキーなものでした。
まず、理解しておく必要があるのは、結局のところ、内部からのインフラストラクチャに対するあらゆる種類の攻撃を防ぐことは完全に不可能であることです。インフラストラクチャとのすべての接触を制限することを意味し、インフラストラクチャを特に役に立たなくします。
ただし、システムの損傷を防止および最小限に抑える方法はいくつかあります。このプロセスに対して、私は3つの段階があることを個人的に認識しています。
- 二人のルール
- 説明責任ルール
- 分業
これらのプロセスは互いに補完しあい、システムが内部から侵入者から安全に保護されるようにします。
二人のルール
最も明白なものである二人ルールから始めましょう。 ITおよびインフラストラクチャのセキュリティにとって重要な部分は、システム内のすべての動作が識別可能であり、望ましいものであることを確認することです。これは、システム内で行われるすべてのアクションがtrustedであることを意味します。
この例を示すとき、私のお気に入りの説明方法は、フォークとプルのGitシステムです。 Gitでは、リポジトリ（この場合はインフラストラクチャ）にアクセスできるすべてのユーザーがコピーを作成できます。その後、アクセス権を持つユーザーは、自分のコードをリポジトリーにプルするように要求できます。ただし、これが発生するためには、プルされたコードが分析され、互換性があるとマークされて、他の誰かによって承認される必要があります。
安全なインフラストラクチャについても同じことが言えます。すべての管理担当者がコードを変更できますが、変更を本番環境に移行するには、1人以上のスタッフによる承認が必要です。
説明責任ルール
特定のタイプのシステムとネットワークに関するもう1つの一般的な問題は、1つの管理アカウントがあり、アクセス権を持つすべてのメンバーがパスワードを知っていることです。説明責任に関する最初の問題はここで発生します。多くの企業は、不正なメンバーがサーバーに不正な変更を加えた場合、マシンのIPアドレスをチェックするなどの基本的な方法を使用して、システムに変更を公開した可能性のあるユーザーを特定します。これは、全員が自分のアカウントを持っていることを確認し、変更がログに記録されていることを知らせることで簡単に修正できます。
前の段落で述べたように、ロギングは2番目の問題です。この場合、trustの問題が再び表面化します。メンバーはシステムに特定の変更を加えるためにtrustedであるため、ほとんどの場合、システムはユーザーのアクションを適切にログに記録していません。
この状況は、アクションアカウンタビリティを実装するのに最適なポイントです。管理ユーザーは、インフラストラクチャの変更中に常に自分のアクションが追跡されるだけでなく、契約に基づく責任と意図的なアクションに対するペナルティもあることに注意する必要があります。
労働部門
これは、ほとんどのITインフラストラクチャの管理職で見落とされているもう1つの概念です。 ITチームはタスクを分割する傾向がありますが、ほとんどのユーザーがanyタスクを実行するためのアクセス権を持つことは珍しくありません。
これを防ぐ最善の方法は、特定のシステム管理タスクを2人の個人のみに割り当てることです（1人の個人が利用できない場合を防ぐため）。他のユーザーはTwo-Manルールを使用して変更を確認および承認できますが、実際に最初に変更を開始できるのはごく一部のユーザーのみです。
個人的な提案
特に大規模なビジネス環境でシステム全体のセキュリティを実装する個人的なお気に入りの方法は、3つのサーバーセットを使用することです。アルファ、ベータ、プロダクション。最初の2つは後者のクローンです。誰でも変更をAlphaに移行できます。このシステムを使用して、本番環境での反応をテストします。ベータ版は、テスト済みで展開の準備ができている変更用です。この段階に到達するには、IT部門の複数のメンバー（〜5）が変更を承認する必要があります。この段階で、IT部門は変更も文書化し、それらを経営陣に、メモとしてITに送信します。 Productionに到達するには、3人の著名な管理メンバーが、IT部門からアクセスできない自分のアカウントを使用して変更を承認する必要があります。
最後のメモ
お気づきかもしれませんが、これは簡単なプロセスではありません。これらのアイデアの多くを実装すると、生産が遅くなります。これは、セキュリティの典型的な質問の1つです。システムが安全であるほど、変更や修正が難しくなります。ビジネスの生産性を高めるには、SecurityとTrustのバランスをとる必要があります。
インフラストラクチャに悪影響を与えるコマンドがリモートからアクセスできないようにすることで、ローカルでのみ実行できるようになります。
これは複数の方法で実現できます。たとえば、shutdownコマンドを禁止します。もう1つの方法は、上記のインフラストラクチャを再起動するか、インフラストラクチャが到達不能になった場合に回復手順を実行するウォッチドッグ（可用性の変化を検出するハードウェアデバイス）を使用することです。
3番目の方法は、たとえばKVM-Over-IPソリューションを使用してリモートアクセスを確保し、これらのリソースをオンサイトでのみ操作できるコントロールに結び付けることです。したがって、インフラストラクチャがダウンした場合でも、リモートで簡単に復元できます。
もちろん、構成ファイル、重要なシステムなどのバックアップをとることは重要です。構成ファイルが変更されることはめったにないので、コミットすることが決定された構成変更ごとに、構成ファイルのバックアップを作成することをお勧めします。
重大なセキュリティイベントのためにインフラストラクチャを切断する必要がある場合、緊急システムを使用できます。これにより、現場に出向くことなく、管理者がインフラストラクチャを簡単に復旧できる方法でインフラストラクチャを切断できます。
ここでの問題は、実際にはその不正な従業員ではありませんでした。その従業員が同じことをしたが、間違いだったとしたらどうでしょう。彼の意図は、設定が消去された後に機器がオフラインになることを認識せずに、誤動作しているネットワークデバイスを修復することであり、質問に記載されている特定のコードとコマンドを実行した後で、設定ファイルを再作成することを意図しているとしましょう消去されましたが、コマンドを実行した後、「おっと、もうデバイスに接続できません」と認識しました。
そして、このように同じ種類の損傷を引き起こしますか？私を信じて、私は同じ間違いを、主に自分のシステムで行いました。そのため、機器の物理的な場所に行く必要がありました。 （しかし、その場合、物事は重要ではありませんでしたが、システムが重要である場合、あなたはそれに何かをすべきです）
それが安全性が存在しなければならない理由であり、そのため、そのような種類の損傷をリモートで、意図的に、または意図的に引き起こすことは不可能です。
ここで良い答えはたくさんありますが、欠けているように見えるのはPrinciple of Least Privilege（PoLP）を採用することです。ルーター設定ファイルを消去する正当なユースケースがない場合は、誰もがそれを実行するためのアクセスを許可しないでください。正当なユースケースはあるものの、日常の運用には関係がない場合は、その特権を取得するために承認プロセスを要求（および監査）します（これは、実際には、以下にのみ適用される2人ルールのバリエーションです）特に機密性の高い操作）。
バックアップとフェイルセーフもあります。元の例をとると、ルーターの構成が消去された場合、ルーターは取り外し不可能なフェイルセーフ構成に戻る（そしてアラームが発生する）必要があります。これは、内部ヘルスチェックに失敗した場合にも発生します。または、ヘルスチェックを行っている場合は、システムを「最新の既知の正常な」構成に戻し、何か問題が発生した場合は基本的にバックアップから自身を復元することができます。これらのフェイルセーフ/バックアップ/ヘルスチェックへの書き込みアクセスは、非常に厳しいセキュリティの下にある必要があります-nobodyは、それらに対する日常の特権を持っているか、またはそのような特権を簡単に取得するには-最も信頼できるインサイダーでさえ、一方的にそれらをバイパスしたり上書きしたりすることはできません。
明らかに、これらすべてのソリューションにはコストがかかります。ほとんどの場合、セキュリティとリソースの消費の間にはトレードオフがあります（通常、「便利さ」と表現されますが、リソースは時間やお金にもなり得ます）。本当に良いPoLPとは、誰もが何かに真のルート（神レベル）アクセスを取得できないことを意味します。たとえば、おそらくその多くのアクセスで信頼できる人（本当に知りません）。フェイルセーフコードは、そのコマンドが HCF であっても、「信頼できる」ソースからのコマンドを信頼するだけのコードよりも書くのが困難です。パラノイアには価格があります...しかし、ネットワーク接続の90％が失われた場合、その価格はそれよりもはるかに安いかもしれません。
1人の従業員がそのような広範囲にわたる損害を実行する力を決して持つべきではありません。このような管理アクションでは、2人以上の個別の管理者による認証が常に必要であり、認証システムを無効にできるのは最上位の管理者だけです。
それがすでに起こった場合、雇用主は従業員を解雇するあらゆる権利を持っているでしょう。
私が見たすべての会社で、非常に厳しい内部セキュリティルールもありました。他のプロジェクトからは何も見えず、実際のタスクしか見えませんでした。
プロジェクト/部門間を移動する場合、許可は常に正確に調整されました。
限られたシステム管理者だけがインフラストラクチャの大部分にアクセスでき、全員が少なくとも5〜10年働いていました。おそらく誰もネットワーク全体にアクセスできませんでした。
anythingを明示的な許可なしに会社のネットワークに接続すること（それを要求することさえも絶望的でした）は常に厳密に禁止されていました。スマートフォンをusbポートに接続すると（それをロードするためだけ）、5分後に同僚から自分に何をしているのか尋ねられました。
私たちのコンピューター/ラップトップは、会社の証明書がプレインストールされた状態で私たちに与えられました。退社後、お返しいたしました。
定期的なセキュリティチェックがあり、これらは外部の会社によって行われました（->誰も、何をどのように行うかを知りませんでした）。また、私たちが作成したソフトウェアも彼らによって検討されました。
私たちが企業ネットワークで行ったことは、おそらく、記録され、ethernityまでバックアップされました。
疑わしいことがあったとしても、ログがどのように保存および検査されるかはわかりませんでした。会社を辞めた後、私たちのコンピューターは外部の会社によってセキュリティチェックも行われ、後で発生する「問題」の証拠として、セクターレベルでバックアップされた可能性があります。