Security_Engineering___Third_Edition_Chapter.21.pdf

Transcript

1. 1 Chapter 21: Network Attack and Defence @fhiyo Security Engineering Third Edition
2. 21.1 Introduction • この章ではネットワークセキュリティを一貫した枠組みで扱う • ファイアウォールとゼロトラストセキュリティ ◦ 20年間企業はファイアウォールで隔離されたイントラネットを持っていてそこは信頼できる とされていた ◦ 一方多くの企業では境界を除去する (deperimeterisation) 方向に向かっている ▪ 思想的リーダーがGoogleで、ゼロトラストセキュリティモデルというファイアウォー ルのないアーキテクチャを推進している ▪ アクセス制御をネットワーク境界から個々のユーザーとデバイスに移行 • 従来のVPNを使用せずにどこからでも安全に作業できるようになる ▪ 境界防御は依然としてあり、顕著なものはDoS攻撃対策 • それ以外の点で内部ネットワークには特権がない ◦ ゼロトラストセキュリティは現在NIST (米国国立標準技術研究所) によるドラフト標準活動の 対象になっている ▪ パンデミックによる在宅勤務の大幅増加による後押し • この章では固定ネットワークについて、次の章でモバイルネットワークにつ いて取り上げる 2
3. 21.2 Network protocols and service denial • この節ではネットワークプロトコルとそのセキュリティに関する説明をする ◦ 最も基本的な懸念事項の一つにDoS攻撃の防止と緩和がある ▪ スパムを送信するためにIPアドレス空間の一部または 1 つ以上のドメインを盗もうとす る • 取り戻したとしても、広範囲にブラックリストに登録されている可能性がある ▪ 多数の侵害されたマシンのボットネットから大量のトラフィックを送信 • 分散型サービス拒否 (DDoS) 攻撃 • DNSなどのさまざまなオンライン サービスを悪用して、大量のパケットトラ フィックを送信 3
4. 21.2.1 BGP security • インターネットの構成要素はISPなどの自律システム (Autonomous System, AS) で、それらの間でルーティングをするためのプロトコルがBGP ◦ 相互接続性は多くの独立したレイヤからなる複雑なエコシステムで、オープンで分散化され ているためにインターネットは成功し回復力を持つことができた ◦ ハリケーンの自然災害や9.11のテロなどの影響は時間的空間的に限定される ▪ しかし、Tier-1 providerが統合されていった結果、徐々にcentralizedしている ▪ 停電などの障害や攻撃に脆弱になってきている ◦ 2008年にパキスタン政府が検閲のためにYoutubeへの偽物のルートを広報、影響は世界中に 広まった ◦ 2010年に中国電信が10万の不正なルートを広報し、インターネット全体の15％を18分間ハ イジャックした 4
5. 21.2.1 BGP security • 中国とロシアは自国のインターネットを分離できるようにしておき、自国の サービスや施設に酷い影響を与えずに外側を (理論上) 攻撃できるようにして いる • 中国のBGPハイジャッキングを使った諜報活動 ◦ 2016年から6ヶ月間、カナダから韓国政府のWebサイト向きのトラフィックは中国経由に なっていた • 犯罪に悪用 ◦ スパマーによるIPアドレスのハイジャック ◦ 2018年にアメリカ空軍から奪ったアドレス空間に隠れて広告詐欺を行い、1千万ドル単位の 被害を出した 5
6. 21.2.1 BGP security • BGPを介して広報されるルーティング情報の正当性をチェックする方法はな い ◦ ISPと政府の間には不信感が蔓延しており、それが規制を難しくしている ◦ システムがどう動くかに関する適切な情報が欠如しているため、合議をするのも困難 ◦ (CloudflareがBGP route leaksの情報は出している: https://radar.cloudflare.com/routing) • BGPの主なセキュリティ機構はResource Public Key Infrastructure (RPKI) ◦ 「自律システムXが範囲YのIPアドレスを広報している」ということをレジストリが証明でき る ◦ 攻撃は防げないが大部分のミスは防ぐことができる ◦ 既に脆弱なBGPが証明書によってロバストになるのかは良くわからない ▪ 2020/02にRIPEの証明書が切れて一時的に通信ができなくなった事例がある 6
7. 21.2.2 DNS security • DNS: ドメイン名をIPアドレスに変換する分散システム • 2016年10月MiraiボットネットがDynDNSを攻撃 ◦ アメリカ東海岸のTwitterを5時間停止させた ◦ 本来DNSは大規模分散システムになっていてサービス拒否攻撃に対しては強い • DNSハイジャックは時々、様々なレベルで起こる ◦ 州が検閲目的でDNSクエリを傍受＆リダイレクト ◦ ISPがWebページの広告を自分の利益になるものに置き換える ▪ (ref: DNS Hijacking On Non-existent Domain Name (NXDOMAIN)) ◦ ISPのDNSサーバーがハッキングされ、悪質なWebサイトに誘導される ▪ ファーミングという攻撃 ▪ ドライブバイファーミング: Webページにローカルのルーターを書き換えるJavaScript を用意しておき、問い合わせるDNSサーバーを不正なものに書き換え、フィッシングサ イトのIPへ名前解決させる • 自宅のルーターのパスワードをデフォルトから変更しなければいけない理由の一 つ 7
8. 21.2.2 DNS security • DNSSEC ◦ DNSのname recordに署名を追加して、正しい権威サーバーから来ており、改竄されていない ことを検証できる ◦ 米国政府の.govのすべてやスウェーデンのほとんどのドメインは署名付きのはず ◦ (ドメインの不存在証明のため) 競合他社がゾーンを渡り歩いてサブドメインを列挙するのを 避けるためDNSSECを見送るところも ▪ NSEC3拡張でハッシュ化することでこれは避けられるが、インフラが整っていない ▪ (ref: DNSSECの現状と 普及に向けた課題, DNSSEC はなぜダメなのか) ◦ Googleなどはシステムがむしろ脆弱になるとして不採用にしているところも ◦ 検証のために通信が余計に必要なため、DoS攻撃に悪用される ▪ パケットを偽装してBobのサーバーからだと偽り、Bob宛に各地のDNSサーバーがレス ポンスを返すことでBobのサーバーの処理が追いつかなくなる • (DNS Amplification (Reflection) Attackのこと) • 署名されたDNSレコードはより長くなるので攻撃が増幅される • DNSサーバーを持っている組織としてFBIが選ばれることも (fbi.govのドメインに いるサーバーが多いので、要求できるレスポンスが長くなる) 8
9. 21.2.2 DNS security • DoH (DNS over HTTPS) ◦ DNSリクエストを平文で送信せず、HTTPSでラップしてリゾルバに送信する ◦ ISPが持つユーザーのブラウジングに関する情報を少なくできるのでプライバシーに良いとい う主張 (Torとか使ってないと特定には十分な情報があるらしい) ◦ システム管理者はDNSハイジャックを監視したり企業や組織にとって不適切なドメインをブ ロックするが、暗号化されるとそれが困難になる ◦ DoHはGoogleの広告支配を強固にする一方、AkamaiやCloudflareなどのCDN事業に悪影響を 及ぼす ▪ (DoHを促進させるGoogleのDNSサーバーが使われるようになったら、Googleだけがク エリの情報を握れてその情報で広告配信ができるから？) ▪ (CDNのルーティングやロードバランシングにDNSが使われるが、そこに悪影響？) ◦ 専門家はDoT (DNS over TLS) の方を好んだだろう 9
10. 21.2.3 UDP, TCP, SYN floods and SYN reflection • 3-way handshake ◦ A → B: SYN; my number is X (シーケンス番号) ◦ B → A: ACK; now X + 1 (確認応答番号), SYN; my number is Y ◦ A → B: ACK; now Y + 1 (start talking) • SYN flood ◦ SYNだけいっぱい送ってACKを相手に返さない → half open状態のコネクション情報を保持 する構造体がいっぱい溜まる ◦ SYN cookieによる対策 ▪ コネクション情報をパケットに乗せて返答し、相手のACKに乗って返ってきたその情報 を見てコネクションをopen • 無駄な領域がサーバーに作られない • SYN reflection ◦ 送信元を偽ってSYNパケットを送りつける→DoS攻撃 (再送があるのでその回数分増幅される) 10
11. 21.2.4 Other amplifiers • ICMP echo reply ◦ 送信元をBobと偽ってbroadcastアドレスに向けてパケットを送信→サブネット内のすべての マシンがBobに向けて応答を返す ◦ ICMPがbroadcast向けには応答しないように変更→他に使えるNTPとかDNSとかを使うよう に • パケット増幅の抜本的な対策 ◦ 利用できるamplifierはICMPやNNTP (Network News Transfer Protocol) などのUDPパケッ トで、SYN reflectionは使っていない ▪ 2000年中期にはISPは送信元を偽装したUDPパケットをフィルタリングするように ▪ Microsoftはパケットの偽装を困難にした • アプリケーションだけでなく、OSもハックしなければ偽装できないように • パケット増幅は自身がホスティングするサーバーからじゃないと難しくなった ◦ 2010年代後半はDDoS業者が台頭するように ▪ この業者を逮捕するのが一番効果的な対策 11
12. 21.2.5 Other denial-of-service attacks • 2016年以降、DDoS攻撃に使われるのはCCTV (Closed-Circuit Television) カメラなどのIoTデバイス ◦ その多くが家庭用Wi-Fiネットワークに繋がっている ▪ 適度な帯域幅 ▪ パスワードがデフォルトのまま ▪ パッチを当てることができない ◦ Miraiボットネットは2016年にその状況を利用して登場した ▪ 亜種が1000種以上あり、Hackforumsにコードが公開されている • DoS攻撃の動機 ◦ 敵チームのteamspeakサーバー (チャットサーバー) を落としたいと考える子どもがほとんど ◦ DDoS攻撃代行業者が数年前から闇市場に存在 ◦ 脅迫や政治的敵対者の抑圧 ◦ インターネット上での社会的・政治的な活動 ▪ 10万人が政策への抗議目的で一斉にメールを送ったらそれはDDoSか？ ▪ 立法上の区別をするのは難しい 12
13. 21.2.6 Email – from spies to spammers • 電子メールのためのSMTP標準には、大量の傍受や不要メール送信の防止に 関する特有の問題がある ◦ 電子メールはデフォルトでは暗号化も認証もない ◦ 何十年もの間、ネットワークの監視やメールサーバーへのアクセスができる人なら誰でも見 放題 • PGP/GPGなどのプログラムで暗号化はできるが、小規模なコミュニティ以外 では普及せず ◦ 使うのが大変 ◦ 他の友達が誰も使ってないのに自分だけ使っても無意味 ◦ ほとんど暗号化なんてされてるメールはないので、逆に目立つ ▪ 反政府活動やスパイ活動を行う人には機密性だけでなく匿名性も大事 13
14. 21.2.6 Email – from spies to spammers • 大量傍受に対する2つの対抗策 a. メールサーバー同士の暗号化通信の確立のためのstarttls ▪ 日和見TLS (接続の際に暗号化を試みるが失敗したら平文で送る) ▪ スノーデン事件以降特に使用されるように ▪ MITM攻撃でブロックされる可能性がある (暗号化通信確立までの間に通信を仲介して 相手になりすます) が、対策としてMTA Strict Transport Securityがある • Microsoft, Yahoo, Googleによってサポート • 認証された証明書によるTLSセッションを介してのみ送れるように • DNS-based Authentication of Named Entities (DANE) に取って代わるもの ◦ DANEはDNSSECに依存する仕組み ◦ メールサーバーのDNSレコード内にstarttls用のTLS証明書を置く b. 95%が5大電子メールプロバイダを使っており、多くの企業もそう ▪ 大きいところはTLSでちゃんと守られている 14
15. 21.2.6 Email – from spies to spammers • スパムには2つの要素がある a. 合法だが迷惑なマーケティング b. 犯罪目的のボットネットによる大量のトラフィック ▪ 対策は4つ 1. Domain Key Identified Mail (DKIM) ◦ ドメインのDNSレコードに置いた公開鍵で検証できる署名をメールに付けて おくことで送信元の検証ができる仕組み 2. Sender Policy Framework (SPF) ◦ ドメインのDNSレコードにメールサーバーのIPアドレスを付けておく ◦ メールの転送はできない ▪ メーリングリストのサーバーはAuthenticated Received Chain (ARC) というプロトコルを使って再度署名をすることになっている 3. Domain-based Message Authentication, Reporting and Conformance (DMARC) ◦ SPFとDKIMでの認証に失敗したときにどう振る舞うかの勧告を書いておく ▪ none / quarantine / reject 4. 機械学習システムによるスパム検知 ◦ ベイジアンフィルタとか 15
16. 21.2.6 Email – from spies to spammers • スパムはいくつかの巨大ギャングによって運営される非常に専門化されたビ ジネスとなっている ◦ 悪意のあるBGP経路広報をしてIPアドレスを盗み、数千のドメインを窃取、機械学習で弾か れる前に各ドメインから数百個くらいスパムを送りつける 16
17. 21.3 The malware menagerie – Trojans, worms and RATs • このカテゴリ分けは厳密なものではなく、コンテキストによっても変わる ◦ トロイの木馬 ▪ 無防備なユーザーが実行すると (パスワードがキャプチャされるなどの) 悪事を働くプ ログラム ◦ ワーム ▪ 他のコードに自身をフックすることで複製する ◦ リモートアクセス型トロイの木馬 ▪ リモートにいる攻撃者が感染しているデバイスにアクセスできるようにする ◦ ルートキット ▪ ルートでインストールされてデバイスを制御できるように ◦ 潜在的に迷惑なソフトウェア (Potentially Unwanted Software, PUS) ▪ よく分からないうちにインストールされて望ましくない動きをするソフトウェア 17
18. 21.3.1 Early history of malware • 1960年代、CPUが貧弱でそのサイクルが割り当てられるまで待つ必要があった ◦ 学生は優先度が低い ▪ トロイの木馬入りのコンピュータゲームを作り、ルートで起動されたことを検知すると学生が 分かるパスワードで特権アカウントを作成されるような仕組みを作った • 1970年代、大学のタイムシェアリングシステムはトロイの木馬を使ったいたずら の的だった ◦ 様々な種類のトリックがこのときに開発された • 1978年、Xerox PARCのJohn ShochとJon Huppがワームを作成 ◦ 自身を複製しながらネットワーク上でアイドルプロセスを探してタスクを実行する • 1984年、Ken Thompsonの論文 "Reflections On Trusting Trust" ◦ チューリング賞受賞 ◦ ソースコード上に痕跡がなくてもコンパイル時にバックドアが入る ▪ 誰でもログインできてしまうマスターパスワード ◦ あるシステムを完全に信用するためにはコードを自作するだけではダメで、ツールチェインやハード ウェアなどすべてを自作する必要がある 18
19. 21.3.1 Early history of malware • マルウェアは感染するように進化 ◦ 1981年、中学3年生がAppleⅡ用に作ったものが最初のコンピュータウイルス ◦ 1984年、Fred Cohenがこの分野で博士号を取得 ▪ multilevel secure systemの層を突き抜けてウイルスが侵入することを明らかにした ▪ 当時の国防コンピュータコミュニティに衝撃を与えた (cf. 9.6.4) ◦ それから約3年以内に実際にウイルスが世に出るようになった ▪ フロッピーディスクや掲示板でプログラムを共有したときに広がっていく • 1987年12月に広がった「クリスマス」ウイルス ◦ ‘Don’t read me, EXEC me’ と書かれたヘッダがあり、実行するとスクリーンにクリスマスツ リーが描かれる ▪ 連絡先全員に勝手に送付される ▪ 悪意というよりいたずら ▪ ユーザーに実行を促した点で時代を先取りしていた 19
20. 21.3.2 The Internet worm • 1988年11月のインターネットワームの登場→報道機関と一般の人々がマル ウェアに気づき始めた ◦ 432個のよくあるパスワードを試す ◦ 感染したマシンに信頼されているマシンを探し、そのマシンに対してUnixの脆弱性を試す (6.4.1に出てきたfingerdのバグを含む) ◦ 自身の名前をshにしており、データの文字列をシーザー暗号で暗号化するカモフラージュも していた ◦ 作者はこれは攻撃ではなく、コードがマシン間で複製されるかの実験だったと主張 ◦ Arpanet上の6万台のマシンのうち10%が影響を受けた 20
21. 21.3.3 Further malware evolution • 1990年代初頭までにPCウイルスは大きな問題となり、ウイルス対策ソフト の業界が誕生した • 21世紀の初めまでに主な攻撃のベクトルはWordなどの製品のマクロ言語 に、感染のメカニズムはインターネットになった • 2000年の "Love Bug" ◦ アドレス帳にいる人に"I Love You"と書かれた件名のメールを送って開封を促す ◦ 作者はマニラのコンピュータサイエンスの学生で、他人のISPのアカウントを不正利用するた めのパスワードを集めるためにやった ◦ 止めるために100万ドル規模のコストがかかった ◦ カナダの85,000人の会社の従業員同士が"I Love You"を送り合う事態になったり • フラッシュワーム ◦ インターネット上の脆弱なマシンを探して乗っ取る ◦ 数時間から数分のうちにすべてのマシンに感染する 21
22. 21.3.3 Further malware evolution • 2000年代初頭：スパイウェア、アドウェアが現れる ◦ スパイウェア: 所有者の承認なしに行動を監視して情報を集める ▪ 親やパートナーの虐待に関係 ▪ 線引きは難しく、立場によって見方も違う ◦ アドウェア: 広告を表示させて収益を得る ▪ 自分たちをブラックリストに入れたウイルス対策ソフトの会社をベンダーが訴えた事例 も • 2004〜6年 ◦ 今まではアマチュアによる作成が主だったのが、マルウェアビジネスがアンダーグラウンド の市場や犯罪フォーラムの登場により伸びた • 2000年代以降 ◦ 大規模ボットネットがオンラインマーケティング戦略で拡大、トロイの木馬感染を誘発 ◦ 初期の巨大ボットネットのStormはP2Pで感染してSPOFを無くした ◦ 2016年以降Miraiワームとその亜種が出現してフラッシュワームが再び増加、IoTデバイスが 攻撃されるように 22
23. 21.3.4 How malware works • マルウェアのコンポーネント ◦ 複製メカニズム ▪ ワーム：パスワードの推測やリモートコード実行の脆弱性を使って侵入した別のシステム内で 自身を複製 ▪ ウイルス：文書内のマクロなどとして拡散 ▪ トロイの木馬：被害者によって実行される ◦ ペイロード ▪ 悪さをする部分 • 秘密データを盗む、暗号化、他者の監視、暗号通貨マイニングなどのタスク実行、ルー トキットやRATのインストール • 標的が個人でなく会社の場合、攻撃は数週間から数ヶ月単位に及ぶ ◦ 標的のネットワーク上にあるデバイスを支配下におくとそこから認証サーバーやメールサーバーなど の重要な資産を見つけ、侵害を拡大してRATを設置してマルウェアを永住させる ◦ 平文で通信していたときはネットワークのパケットを収集してパスワードを盗み見たり ◦ NFSなどの共有リソース ◦ 大規模な組織ではSSH鍵が大量にあり、そこが攻撃されうる 23
24. 21.3.4 How malware works • 攻撃者がどんなツールを使っているかはエドワード・スノーデンが公開した NSA文書や、Vault 7の暴露で漏洩したCIAツールキットを見ると良い • ネットワークへの侵入の被害は、ネットワーク内のマシンがそのネットワー クをどれだけ信頼しているかで決まってくる ◦ ローカルネットワーク内でもクライアントサーバー間で認証をさせる動機の一つ 24
25. 21.3.5 Countermeasures • 初期のウイルス対策ソフトはスキャナとチェックサマーの2種類がある ◦ スキャナ: 特定のウイルスのバイト列を検索することで侵害しているかをチェック ▪ バイト列はindicator of compromise (IoC) という ▪ マルウェア側はポリモーフィズムという方法で対処 • コードを暗号化し、復号用の鍵をヘッダに付ける ◦ 複製のたびに異なる鍵で暗号化することでバイト列を変更 • 現代のマルウェアは6回再帰的に繰り返す ◦ VM上で解凍され調べられるのを防ぐため、VM検出コードを含む ◦ 何とか解凍できれば解凍したコードをIoCとして使える ◦ チェックサマー: システム上で認可された全実行ファイルのホワイトリストとそこから作った チェックサムを確認する ▪ マルウェア側はステルスという方法で対処 • チェックサマーが使っているシステムコールを監視して、それが呼ばれたときに 隠れる 25
26. 21.3.5 Countermeasures • マルウェアを防ぐにはツール、インセンティブ、管理の3つを組み合わせる 必要がある ◦ インシデントを報告する先と組織のマシンにあるすべてのソフトウェアを制御するのが昔か ら重要 ▪ 主なリスクは家庭用と仕事用の両方で使うマシンと、他組織から来るファイル ◦ 今でも変わらないが、昔よりも難しくなっている ▪ 背景にウイルス対策ソフトの効果が段々低下していることもある • 2000年台初めはマルウェアをほとんど検知できていたが、2010年には1/3に、 2020年には感染を事後に検出してクリーンアップすると予想されている • ルートキットベンダはその除去ツールを作られてもすぐに対策版を出す • ウイルス対策ソフトで検知できるようなものは残さず、SSH鍵だけ残して自由に サーバーに入れるようにしている 26
27. 21.4 Defense against network attack • 第2版出版時の2008年では、ネットワークへの攻撃の対策は3つだと主張した ◦ システムを最新にして、適切に設定をし続けるための十分な管理 ◦ トロイの木馬などの侵入を止めるためのファイアウォール ◦ IoCを監視するための侵入検知システム • 2020年でも大枠は同じだが、事態が複雑になっている ◦ 複雑すぎて自動化は必須 • ITセキュリティに真剣な企業である大企業、銀行、軍隊などは脆弱性を根本から止 めたい ◦ パッチを常に最新状態にする → パッチ管理の自動化をしたい ▪ ネットワーク内の全デバイスの全構成要素を把握しなければならないので、思ったより大変 ▪ 従業員のデバイスを厳格に管理しようとすると抜け道を探されるので、ネットワーク内に脆弱 な箇所がないかをスキャンすることも必要 ◦ すべてのセキュリティホールを塞ぐにはコストがかかりすぎる ◦ パッチはアプリケーションを壊すかもしれず、アップグレードでサービスがロストするのを恐れた結 果、組織内で最も重要なシステムが最もセキュリティが甘いマシンで動いていることはよくある 27
28. 21.4.1 Filtering: firewalls, censorware and wiretaps • ファイアウォール: プライベートネットワークとインターネットの境界で有 害と思われるパケットをフィルタリングするシステム ◦ 飛行機などの火災から乗客を保護するための客室とエンジンルームを隔てる金属製の隔壁が 由来 ◦ 1990年中頃に登場 ▪ 企業内のマシンをすべて保護するべきという批判があったが、ファイアウォール支持者 はそれは非現実的だと反論 • 今でも議論されている ◦ パケットを調べてフィルタリングしたりログを取ったり ▪ 非常に良く似た仕組みのシステムがインターネットの検閲や法執行機関などへの盗聴に 使われる ◦ 動作する階層によって分けられる ▪ IPレベル ▪ TCPレベル ▪ アプリケーションレベル 28
29. 21.4.1.1 Packet filtering • 一番シンプルなタイプのフィルタリングはパケットのIPアドレスとポートの検査 ◦ 標準のルータ、Linux、Windowsで使える ◦ IPスプーフィングしているパケットをブロックできる ▪ ローカルのパケットしか外に出られなくしたり、外側のパケットしか入ってこれなくしたり ◦ IPフィルタリングは検閲にもよく使われる ▪ 中国のGreat Firewall • ルータ内にIPアドレスのブラックリストを持っておき、そこ宛のパケットを落とす • 基本的にパケットフィルタリングは特定のポート宛以外のパケットをすべて落とす ◦ email, web traffic など必要なポートへのパケットだけ通す • パケットフィルタリングはいろいろな方法で破られる ◦ パケットのフラグメント化を利用して、最初のパケットだけ書き換えて通過させ、後続のパケットの ルールに違反している送信元アドレスに上書きして通信する ◦ ブラックリストの維持が困難 ▪ フィッシング側はWebサイトのIPアドレスを1時間に何度も変えるfast-fluxなどの方法を使う • 短いTTLでキャッシュさせない ＆ Aレコード/AAAAレコードを頻繁に変更 29
30. 21.4.1.2 Circuit gateways • サーキットゲートウェイ: TCPセッションでパケットを再構成＆検査する ◦ (パケットそのものではなく、セッションレベルでの通信のフィルタを行う) ◦ 単純なパケットフィルタリングの機器より高価だができることも多い ◦ TCPレベルのフィルタリングはDNSフィルタリングなど別の機能を実行するために使用でき る ▪ アプリケーションレベルでフィルタしたい場合は別のフィルタに誘導する 30
31. 21.4.1.3 Application proxies • アプリケーションプロキシ ◦ サービスレベルの内容を理解するファイアウォール ▪ スパムを除去するメールフィルタ ▪ 望ましくないコンテンツをブロックするwebプロキシ ◦ 古典的な利用目的はコードの除去 ▪ 実行可能ファイル、webページ内の動的コンテンツ、Word文書のマクロなど ◦ メールサービスのwebへの移行とhttpsの普及によりメールフィルタの作業は大幅に減り、 サービス企業がプロキシを防ぐために証明書の透明性などの基準を採用したことでフィルタ リングは通信のエンドポイントに移る必要が出てきた ◦ 中国のGreat Firewallの例 ▪ 2000年代はコンテンツを見て問題のあるメールやwebサイトをブロックしていた ▪ HTTPSの採用とGoogle Docsなどのコミュニケーションに使われるサービスの登場によ り、中国は単純にGmailやFacebookなどのサービスを国民が使うことを禁止した 31
32. 21.4.1.4 Ingress versus egress filtering • ほとんどのファイアウォールは外から内に悪い物が入らないように防ぐが、 内から外に出ないようにするものもある ◦ その先駆けは軍のメールシステムで、機密情報が平文のまま送られないよう外向きのトラ フィックを監視 ◦ 2005年頃、一部のISPでスパムを検知するために外向きのトラフィックを監視 ◦ 現在ではほとんどのISPが、顧客が送信元アドレスを偽造したパケットを出さないように見 張っている ▪ この監視により、UDPリフレクション攻撃を行うDDoS実行者はボットネットを使用で きなくなり、データセンタでサーバーをレンタルする必要が出た ◦ 2020年におけるegressフィルタリングの使用例が増えているところはデータ漏洩防止 (data leakage prevention, DLP) のため ▪ 'phone's home' (インストール済みのソフトウェアが製造元などに勝手に通信すること) をするソフトウェアは機密性が高い情報を漏洩する可能性があるのでこの手のトラ フィックは監視したい ▪ HTTPSの普及のため、DLPシステムは通信経路の途中に置くmiddleboxではなく、終端 にインストールする必要がある 32
33. 21.4.1.5 Architecture • 軍事産業の請負業者の本格的なファイア ウォールを見ると非武装地帯 (DMZ) とし て知られる隔離されたサブネットと外側を つなげるパケットフィルタで構成されてい る ◦ 機密情報が外部にも下位にも漏れないように、 異なるクリアランスレベルのネットワークを分 離する箇所もあるだろう • 別のアプローチとして、ネットワークセグ メントを細かく分けるものもある ◦ 著者の大学では学部ごとにファイアウォールを 分けている ◦ 別で共通のネットワークバックボーンやロギン グなどの共通サービスもある ◦ それぞれのネットワークを小さくして侵害時の スコープを抑え、システム管理者が防御をする インセンティブを作る 33 https://www.cl.cam.ac.uk/archive/rja14/Papers/SEv3-ch21.pdf
34. 21.4.1.5 Architecture • ネットワークセキュリティアーキテクチャの考慮事項 ◦ シンプルさ、ユーザビリティ、非境界化 対 再境界化、アンダーブロッキング 対 オーバーブ ロッキング、保守性、インセンティブ辺り ◦ ファイアウォールは機能が少ないので、脆弱性やエラーが起きにくいようにシンプルにして おける ◦ 組織に様々なマシンがある場合はセキュリティタスクを行うマシンをなるべく少数に留める ◦ コールセンターのような同じ構成のPCが何千台もあるような環境ではこの構成を厳重に保つ ことが合理的 (セキュリティ対策やアップデートを一元管理できるのが良い？) ◦ 複雑な中央インストールは運用コストを増大させるし従業員がファイアウォールをバイパス するようになる ◦ ゲスト用のネットワークを用意しておく ◦ ネットワークの実際の設定を監視しておく ◦ ファイアウォールは迂回する手段が発見されるまでの間しか機能しない ▪ PCゲームや匿名プロキシアプリの制作者は通常のwebトラフィックに似せたクライアン トサーバーの通信をするようにプロトコルを再設計することでファイアウォールの検知 を回避するように 34
35. 21.4.1.5 Architecture • 非境界化 ◦ GoogleのBeyondCorp: ゼロトラストセキュリティの提唱 ▪ 境界ですべてを守ることがどんどん難しくなった • かつてはデスクトップコンピュータで済んでいた機能を司る電話やPDA (Personal Digital Assistant, 個人向けの小型電子デバイス) の普及 • 機能のアウトソーシング (下請けや広告付きの無料アプリ(？)) ▪ 2000年代初頭はJavaScriptを多くの企業がブロックしようとしたが、多くの人気Web サイトがJavaScriptを使うようになったので諦めた ▪ 今日ではセキュリティ保護できない大量のIoTデバイスを従業員がネットワークに接続 することを防ぐのは不可能かもしれない • ROC曲線 ◦ overblockingとunderblocking ▪ 言論の自由を保証するようなサイトはファイアウォールにブロックされがちで、彼らは ベンダを批判して迂回方法を教えている 35
36. 21.4.2 Intrusion detection • 攻撃の全てを防ぐよりも、一部の攻撃を防いで残りを検出するほうが安上がり→侵 入検知システム (Intrusion Detection System, IDS) ◦ ネットワークに常駐し、進行中の攻撃や侵害されたマシンを探す • 検知するものの例: ◦ ボットネットの制御に使用されるIRC (Internet Relay Chat) チャネルなどの既知の不正サービスや 不正IPアドレスに接続しようとするマシンや、不正なDNS名を解決しようとしているマシン ◦ 送信元アドレスを偽装しているパケット ◦ ネットワーク内のマシンから来るスパム • このような兆候がある場合、IDSはシステム管理者に特定のマシンを調べる必要が あることを伝える • 他のIDSの例: ◦ ペイメントカードの不正検知メカニズム ◦ 株式価格に影響を与える発表の直前の取引量の増加などによるインサイダー取引の検知システム • 現在活発な分野で、2012年以来のAIブームより、パターンマッチング問題を解こ うとするスタートアップが多く誕生した 36
37. 21.4.2.1 Types of intrusion detection • 侵入検知システムの最もシンプルな方法は閾値を超えたときにアラームを鳴 らすこと ◦ 3回以上のログオン失敗 ◦ 過去3ヶ月の移動平均の2倍を超えるクレジットカードの支出 ◦ 6時間を超える携帯電話の通話 37
38. 21.4.2.1 Types of intrusion detection • より高度なシステムは主に2つに分類される ◦ 不正検出 (misuse detection) ▪ 侵入者の行動モデルに似ているかで検知 • 銀行システムで3日間連続で限度額まで引き出した場合アラートが鳴る • Unixの侵入検知システムでは急にコンパイラなどの高度なツールを使用するようになったユー ザーを検知するとアラートを鳴らす • ウイルス対策スキャナなどの単純な不正検出システムではシグネチャ (特定の攻撃の既知の特性) を探す ◦ マルウェアの実行ファイルのsubstringなどのデータ、IPアドレスが割れているC&Cサー バへの通信などの振る舞いを見る • より複雑な不正検知システムでは機械学習で分類器を作る ◦ カード詐欺を検出するシステムではfalse positiveを十分減らすために数十程度のシグナ ルを使って判定する ◦ 異常検出 (anomaly detection) ▪ 攻撃者の手口の明確なモデルが無い中で異常な動作を探す • 不正検出よりはるかに難しい • 以前に認識されておらず、カタログ化されていない攻撃の検出を期待される • 1990年以降はAI技術を使っているが、一部の企業は避けている ◦ Googleは閾値や因果関係の検出を避けて単純にエンドユーザーのリクエスト率の変化を 検出するようにしている 38
39. 21.4.2.1 Types of intrusion detection • 不正検出と異常検出の境界は曖昧 ◦ 境界の例 ▪ 乱数の数字の分布を説明するベンフォードの法則 • 数値が対数的に分布しているなら最初の桁は1の方が9より多い ◦ 帳簿の改竄に一様乱数を使うとベンフォードの法則から外れるので検出でき る ▪ ハニーポット • 一部の病院では患者の機密を漏らす従業員を罠にかけるために有名人の名前のダ ミーレコードを持っている • 特定のデバイスを攻撃対象とする相手を広く罠にかけるために多くの種類のデバ イスをエミュレートする 39
40. 21.4.2.2 General limitations of intrusion detection • 侵入検知は簡単なものもあるが、一般には困難 ◦ 停止性問題と同程度に難しいので完璧に解くのは無理 • 侵入検知システムの定義 ◦ 疑わしい行動をブロックするように構成されているものもある ◦ 著者はログを監視して疑わしい行動を報告するシステムを侵入検知システムと定義すること を好んでいる • false alarmの問題 ◦ 機械学習の研究者はよくfalse positiveが0.1%だったら上手くいったと判断するが、Gmail サービスの10億人の認証を扱っている場合は高すぎてダメ ◦ 大規模なシステムではfalse positiveの割合を非常に低く抑える必要がある • 機械学習の分類器の問題 ◦ 未知の攻撃を検知するのが得意ではない ◦ ユーザーが分類器を悪用する ◦ 訓練データの偏見が反映される 40
41. 21.4.2.3 Specific problems detecting network attacks • ネットワークへの侵入検知は難しく、false positive, false negativeが多い ◦ 侵入は後から検出されることが普通 ◦ パフォーマンスが低い理由 ▪ インターネットがノイジーすぎる • ランダムなゴミのパケットがどんなサイトにも届き、誤報を誘発する • ソフトウェアのバグのせいでおかしくなったパケットが多い ▪ 攻撃の割合が少なすぎる • S/Nが小さすぎる ◦ たとえば (多く見積もって) 100万セッションに対して10の本物の攻撃があ るとして、0.1%のFPRだとしても1000個誤検知するので本物に対して100 倍の誤報が出る ▪ 侵入は不正な状態を起こさないようにするので検出が難しい • 銀行からの盗難は不正な状態を起こすので相対的に検出が楽 41
42. 21.4.2.3 Specific problems detecting network attacks • パフォーマンスが低い理由 (続き) ◦ 多くのネットワークへの攻撃は特定のソフトウェアのバージョンに対するものなので、新た な脆弱性に対して追従させるのが大変 ▪ IDSを設置している人の多くはモチベが高くないので頻繁なアップデートをしない ◦ トラフィックが暗号化されてきているのでコンテンツを見て判断がしにくい ▪ DoHが普及したらDNSトラフィックの解析ツールは有効性が大幅に低下する ◦ パケットレベルのフィルタは見逃しが多く、アプリケーションレベルのフィルタはコストが かかる ◦ 侵入検知はローカルとグローバルの両方で行う必要がある ▪ 暗号化のせいで暗号終端でパケットを見る必要がある一方、ネットワーク上の大量のホ ストに数パケットずつ送る攻撃を検知するには中央でパケットをカウントして送信元と 送信先を確認するモニターが必要 42
43. 21.5 Cryptography: the ragged boundary • ネットワークのセキュリティに暗号化は密接に関わる ◦ SSH, WiFiやBlueToothやHomePlugにあるローカルリンク保護、IPSec, TLS, PKIについて見 ていく • 製品のベンダが気にかけないために暗号化の管理ができなくなっている問題 ◦ Internet of Thingsの一部として市場に出た何千ものデバイスはユーザーが利用できる管理機 能がない ◦ ベンダーは製品のアップデートを行わないことがよくある ◦ ユーザーインターフェースがないため、認証はせいぜい場当たり的 • 問題の最も中心にあるPKIは政府の命令で破壊されることがよくある 43
44. 21.5.1 SSH • 1995年にヘルシンキ工科大学の研究者であるTatu Ylönenによって開発された • マシン間の暗号化された接続を確立し、ログインパスワードなどが平文でネット ワークを流れなくなった • それぞれのマシンがpublic-privateキーペアを持つ構成が一般的 ◦ プライベートキーはユーザーがキーボードでタイプするパスフレーズで守られている ◦ Diffie-Hellman鍵をセットアップして接続を暗号化 ◦ プライベートキーは中間者攻撃を防ぐために公開鍵に署名するためにある ◦ 通信は暗号化されるし認証もされている ◦ 手動で公開鍵をインストールする方法は分かりやすいがスケールはしない • 問題 ◦ キーボードで1文字打つたびにパケットが送信されるので、そのタイミングから何を打っているかの 情報の多くが漏れる ◦ サーバー間通信で使っているSSHキーのほとんどが平文で保存されており、何のパスワードもかけら れていない ▪ サーバーが侵害されるとそこにあるSSH鍵を信頼しているマシンはすべて同じ目に遭う ◦ 多くのIoTデバイスはSSHで、パスワードを知っていれば誰でもリモートログインできる ▪ パスワード推測攻撃の標的になり、弱いパスワードの場合はMiraiなどのツールのボットネッ トになる可能性がある 44
45. 21.5.2 Wireless networking at the periphery • 多くのネットワークではデバイスまでの数メートルでワイアレス技術を使用 している • Wifi, Bluetooth, HomePlugといったプロトコルはすべて暗号化を提供して いる ◦ 不正使用や盗聴に対する保護ができる ◦ 一方、デバイスにパッチが適用されていなかったり、ユーザーインターフェースが無かった りするせいでローカルでの攻撃に脆弱なものがほとんどである 45
46. 21.5.2.1 WiFi • 1997年の登場以来暗号化プロトコルが付属している ◦ WEP (Wired Equivalent Privacy) ▪ アメリカ政府が輸出向けの暗号技術を制限していたことやプロトコル設計が良くなかったた め、簡単に破ることができた ◦ 2004年以降、WPA2ではAESが使われるようになっている • WiFiのセキュリティはやや脆弱 ◦ UPnPで機器が自動でネットワークに参加できるようになっているとルータのファイアウォールに穴 を空けることができる ▪ DHS (アメリカ合衆国国土安全保障省) は2013年以降UPnPの機能はオフにするよう推奨してい るが、多くのデバイスや電化製品がクラウドサービスに紐づいているので難しい • 2007年、アメリカの百貨店のTJ Maxxで約4,570万件のクレジットカード番号が盗 まれた ◦ 安全でないWiFiの接続方式を使っていたことが原因と報じられ、銀行が同社を訴えて4,100万ドルで 和解 • パッチ適用の問題 ◦ 2020年3月にBroadcom WiFiチップのKr00k脆弱性が判明 ▪ MacやiPhoneではパッチが適用されるが、ルータや古いAndroidスマートフォン、大多数のIoT デバイスではパッチは適用されないだろう 46
47. 21.5.2.2 Bluetooth • 近距離無線通信の規格 ◦ ヘッドセットに電話をリンクしたり、電話を車のハンズフリーI/Fに接続したり • WiFiと同様、初期のプロトコルには欠陥があったが2007年のバージョン2.1 以降はSecure Simple Pairingという楕円曲線Diffie-Hellman暗号を使って盗 聴を阻止する仕組みを使う ◦ (共通鍵から導出する？) 6桁の数値を生成して比較することで中間者攻撃を防ぐ ◦ 中間者攻撃を防がない "just works" モードもある ◦ データには署名をする場合としない場合があり、機密性や整合性、完全性、中間者攻撃耐性 のあるなしなど組み合わせは10種類 ◦ スノーデン事件に触発された攻撃もいくつか発見されている • やはりパッチ適用が課題 ◦ 2018年にEli Bihamが認証に無効な楕円曲線暗号を使って中間者攻撃を行う脆弱性を発見 ◦ 2020年にDaniele Antonioliと同僚が中間者攻撃の亜種を発見 ◦ →パッチが適用されていないデバイスはこれらの攻撃に脆弱である可能性 47
48. 21.5.2.3 HomePlug • 電源ケーブルを介した通信を行うためのプロトコル • HomePlug AV (という規格) はWiFiの中継機で広く使用されている ◦ 親機をルーターに接続して子機からWiFiアクセスポイントを提供する • Bluetoothと同じ設計上の制約がある ◦ すべてのデバイスにキーボードやディスプレイといった入出力装置があるわけではない ◦ コストを低く抑える必要がある ◦ 2つのモードを提供することにした ▪ セキュアモード • デバイスラベルに印字されているAESキーをネットワークコントローラーに入力する ▪ シンプル接続モード • 認証なしでキーを交換する。キーは暗号化もされていない ◦ 暗号化を提供することが目的ではなく、デバイスが誤って隣の部屋のネットワー クに接続することを防ぐことが目的 ◦ が、多くのベンダーは後者しかサポートしておらず、初回に信用するポリシーを採用している ▪ もしくはキーをインストール済みの状態にして売っている ◦ 変電所と通信するスマートメーターや、電力線を通して家庭にブロードバンドを提供する電力会社の サービスにもHomePlugの亜種が使われている ▪ 無線周波数干渉のため広くは使われていない 48
49. 21.5.2.4 VPNs • Virtual Private Networkは (通常) IP層での暗号化と認証を行うプロトコル スイートであるIPSecを使う ◦ パケットは認証だけされることもあれば、暗号化までされることもある ▪ 認証のみならAHヘッダを用いてデータの完全性が保証される ▪ 暗号化までされるなら外側のパケットにカプセル化されて送られる ◦ キーとパラメータをやり取りするためのInternet Key Exchange (IKE) プロトコルがあるが、 スノーデン事件の公開から標準のデフォルト設定である1024ビットのDiffie-Hellmanは安全 ではないと推測できる • 中国やイランなどの国家レベルのファイアウォールを回避するための方法で もある 49
50. 21.6 CAs and PKI • (5.7.4で述べたように) 公開鍵暗号の発明者は秘密鍵を管理する組織や人、 デバイスの名前や役割に公開鍵を紐づける証明書の仕組みを構想した ◦ 当初は政府や電話会社が証明を行うと考えられていたが、動きが遅くその間に認証局 (Certificate Authority, CA) が立ち上がった ▪ マイクロソフトやNetscapeなどの企業は自社のブラウザにCAの公開鍵を埋め込んだ ◦ 政府が諜報、監視の目的で独自CAのルート証明書をブラウザに入れる方向に向かった ▪ Gmailのようなwebサービスに人々が移行すると、セキュリティ機関は中間者攻撃をす るためのツールを開発 • ブラウザが受け入れるセキュリティ機関の証明書をwww.google.com上で発行す るCAが必要 ▪ (実際どのくらいこういうことが行われているんですかね？) ◦ 証明書のガバナンスは政治的に難しい ▪ 著者がトルコの諜報機関の証明書をMozillaのブラウザから削除したが戻された 50
51. 21.6 CAs and PKI • DigiNotarのスキャンダル ◦ オランダのCAで、Gmailの偽のワイルドカード証明書を発行していたことが判明 ▪ 2011年にイランによってハッキングされたため ▪ これによりイランは30万人のGmailのイランユーザーを監視していた ◦ イランはトルコとは異なり、制裁措置で主要ブラウザに政府証明書をインストールすること ができなかった ◦ MozillaとGoogleはDigiNotarの証明書をすぐにブラウザから削除、MicrosoftとAppleもすぐ に行った ▪ オランダではDigiNotarの証明書を多くのオンライン政府サービスで使っていたため混 乱 • ComodoというCAが攻撃を受けていたことが後に判明 ◦ Comodoは発行された証明書をミスで全て消したと主張している ◦ この事件以降、ブラウザのルートストアからCAとその監査人に対する圧力が高まっている 51
52. 21.6 CAs and PKI • 'public (key infrastructure)' と '(public key) infrastructure' の違い ◦ 前者：Open PKI ▪ どのアプリケーションでも利用可能 ◦ 後者：Closed PKI ▪ 企業内など、特定の範囲でのみ限定的に使用される ▪ 認証局をプライベートネットワーク内で構築する ▪ 政府機関が攻撃する可能性があるサービスを構築するならばPKIをクローズドにしてお くのが良いだろう • 令状を取らせることができる ◦ 何百万のマシンにインストールされるソフトウェアを保守する企業はコード署名にプライ ベートCAを使用することをお薦めする 52
53. 21.6 CAs and PKI • PKIには固有の制限がある ◦ 命名が難しい ▪ (証明書に紐づけるidentificationに何を使うのかの問題?) ◦ 一つの証明書に依存するアプリケーションが多くなると証明書の有効期限が短くなる ◦ 一つの鍵でいくつのアプリケーションを証明するかの問題 ▪ (多分アプリケーションごとに) 複数のキーを管理する方が顧客を守れる • 家を抵当に入れるためのキーでランチを買いたくない 53
54. 21.6 CAs and PKI • 様々な信用問題 ◦ Firefoxからルート証明書を削除すると、Mozillaが勝手に置き換えるし、Windowsでは削除 できない ▪ いずれにせよ証明書が信頼できないものとしてマークする方法を知る必要がある ◦ Windowsには証明書があるが他のブラウザにはない政府がMacユーザーに対して別の監視方 法に頼らざる負えなくなった ▪ 2014年の軍事クーデター後のタイなど ◦ 多くの企業の証明書が期限切れだったり別会社のものだったりする ▪ プロモーションの請負会社に任せた結果 ▪ その結果、多くのユーザーがセキュリティの警告を無視するように訓練されてしまった ▪ 最近では警告を無視してクリックすることが難しくなった ◦ 証明書は会社名とDNS名を紐づけるが、どちらの権威でもないので完全に保証することはで きない ▪ EV証明書はまだマシだがそれでも完全ではない 54
55. 21.6 CAs and PKI • 様々な信用問題 (続き) ◦ 認証局運用規程でCAはあらゆる責任はないとしている ◦ 証明書の失効確認 ▪ 証明書失効リスト (certificate revocation list, CRL) をダウンロードして依存しようと している証明書をチェックできる • オンライン操作が必要なため公開鍵暗号の利点が大きく損なわれる (本来はオフラ インでも証明書確認ができるから？？) • システムを起動するたびに大きなCRLをダウンロードする必要があり、遅延や ネットワークの混雑を引き起こした ◦ 2013年ごろからはOnline Certificate Status Protocol (OCSP) という効率 的なプロトコルを使っている 55
56. 21.6 CAs and PKI • 執筆時点での大きな論点 ◦ 証明書の有効期限 ▪ 最大有効期間はどんどん減っている • 8年→3年→27ヶ月 • 2020年にAppleのデバイスは398日を超える証明書を受け入れないと宣言 ▪ 多くの企業が証明書を更新せざるを得ないが、どうやってやるのか ◦ Let's Encrypt ▪ 以前は証明書の取得は困難で、購入、ドメイン管理証明、証明書の取得、サーバーへの アップ、構成変更、テストとやることが多かった ▪ Internet Security Research Group (ISRG) がLet's EncryptのCAを設立 • 証明書を無料にすることで完全な自動化が可能に • 年間300万ドルで1億サイトをサポート • ブラウザの接続は4年前は60%が平文だったが、20%に減った • 証明書管理方法はRFC8555 (Automatic Certificate Management Environment, ACME) として標準化されているため、商用でも利用されている • 上位100万サイトの35%を占めるので、同社がミスしたときの影響が大きい ◦ 2020年3月にソフトウェアのバグで1200万のサーバーに影響する300万の 証明書を交換する必要が起きた 56
57. 21.6 CAs and PKI • 執筆時点での大きな論点 (続き) ◦ 証明書の透明性 ▪ ComodoとDigiNotarへの攻撃を受けて、悪意を持って発行された証明書をブロックす るメカニズムを作るように ▪ 各ドメインの全ての証明書のログを管理し、発行されるべきでない証明書を迅速に発見 ▪ Googleは2013年に最初に証明書の透明性ログを開始、Chromeは2015年にEV証明書に 対して透明性ログを要求するように • 2018年にはすべてのCAに証明書の透明性ログを義務付けるようになった ◦ Symantecがドメイン所有者が認識していない証明書発行をしていたことが 契機 57
58. 21.7 Topology • ネットワークのトポロジー: ノードが接続されるパターンのこと ◦ セキュリティアーキテクチャにおいて重要な要素となり得る • トポロジーの例 ◦ 電力会社 ▪ 複数の島からなる ▪ それぞれ島に発電機や変電所があり、信頼されたネットワーク上で数十から数百のデバイスに 接続されている • ネットワークは専用のファイアウォールとVPNを介してネットワークコントロールセン タに接続されている ◦ クラウドサービスプロバイダ ▪ データセンタに何万台ものマシンを所有している • プロバイダと顧客が発行する証明書の階層によってどのマシン上のどのVMやコンテナが 互いに通信できるかが決まる • ネットワーク上の位置がアクセス制御に影響を及ぼさない • フロントエンドシステムによってDDoS攻撃から保護されている場合もある ◦ 政府が使用する機密システム ▪ 建物内に個別のLANがある • (異なる建物や部署への漏洩を防ぐ？) ▪ 高いレベルで運用されている非常に大規模な信頼されるネットワークがある 58
59. 21.7 Topology • より複雑なトポロジとしてソーシャルネットワークがある ◦ 人がノードでエッジが互いの連絡先を交換していること ◦ ソーシャルネットワーキング分析: 疫学、犯罪学、新しいテクノロジーがどう普及するかの研 究、マクロウイルスなどのユーザー間で伝達される危害の研究など ◦ 頂点次数についてのべき分布でモデル化できる ▪ 少数の次数が高いノードの存在がランダムな障害に対して回復力をもたらす ▪ 標的型攻撃に弱く、次数が高い少数のノードを除去するとネットワークの連結性が弱ま り分断される • 独裁者は本能的にこれを知っており実行していた ◦ スターリン: 裕福な農民を殺害 ◦ ポルポト: 知識人を殺害 ◦ ウィリアム征服王: サクソン貴族を殺害 • 現在では定量的なモデルがあり、なぜ革命家が細胞単位 (少数の独立したグルー プ？) で組織される傾向にあるのかを説明するのに役立つ • 反体制組織の中の数人の有力者のトラフィックを分析するだけで驚くほど多くの メンバーを特定することができる ◦ 反体制派が最初から少数のグループに分かれている場合はダメ 59
60. 21.8 Summary • ネットワークを経由して行われる攻撃を防ぎ検知することが現代のCISOの責 務の中核 ◦ 膨大な範囲の攻撃の種類とセキュリティ技術があるため困難な仕事 ◦ ニュースに出るような失敗につながることもあり得る ◦ 技術的な進歩があるごとに何かしら懸念事項が発生する ▪ 例: クラウドサービスはネットワークのセキュリティ問題の多くをプロバイダに投げる ことができるようになったが、設定管理はより大きな問題になった ▪ 問題は複雑で厄介なので、それらを管理するためには自動化によるシステム全体のアプ ローチが必要 • ハッキング技術 ◦ 以下に部分的に依存 ▪ 偶然ベンダにより導入された脆弱性が出るのを待ってそれを利用する手法 ▪ ソーシャルエンジニアリングで不正なコードを実行させるよう誘導する技術 ◦ これらは悪者のエコシステム全体の中で発展している ▪ セキュリティエンジニアはこのことを研究して理解する必要がある 60