【セキュリティ事件簿#2022】大阪急性期・総合医療センター 情報セキュリティインシデント調査委員会報告書について 2023年3月28日


大阪急性期・総合医療センターは令和4年10月31日早朝に発生したサイバー攻撃により電子カルテを含めた総合情報システムが利用できなくなり、救急診療や外来診療、予定手術などの診療機能に大きな支障が生じました。地域における中核的な役割を担う病院として、府民の皆様、とくに患者さんをはじめとする関係者の皆様に多大なるご迷惑、ご心配をおかけいたしましたことを、改めて深くお詫び申し上げます。また、さまざまな形でご支援をいただいた多くの皆様に厚く御礼申し上げます。

事件発生当日、電子カルテの異常を覚知し、ランサムウェアによる重大なシステム障害が発生していることが判明したため、幹部職員を招集して状況把握と紙カルテの運用など当面の診療体制の方針を決定しました。また、大阪府立病院機構本部、大阪府、大阪府警、大阪市保健所、内閣サイバーセキュリティセンター、厚生労働省医政局などの各方面に連絡をしました。特に厚生労働省からはサイバーセキュリティ初動対応支援チームの専門家が派遣され、発災当日からWEBを通じて多くの支援・有益な助言をいただき、ベンダーの方々の協力を得て、原因の究明に努めるとともに、職員および関係者が一丸となって復旧に取り組みました。

サイバー攻撃によるシステム障害を想定したBCP(事業継続計画)はそれまで策定されていませんでしたが、当センターは大阪府の基幹災害拠点病院であり、さまざまな災害に対応するためにBCPを整備、更新しており、これまでの災害対応の経験を生かして、発災当日の正午には第1回の「大規模システム障害における事業継続対策本部会議(BCP)会議」を開催し、医療現場の状況の把握、当面の医療継続の方針の決定などを行いました。BCP会議は当初は連日、3週目以降は数日おきに開催し、紙カルテの運用方法など診療現場での各部門間の対応のすり合わせを行いました。このようにして一部の入院診療を継続するとともに、外来診療を再開・漸増させることができました。また、BCP会議とは別に病院、基幹ベンダー、ネットワークベンダー、専門家チーム等の関係者によるシステム復旧会議が連日開催され、初動対応、進捗状況および復旧スケジュールの協議等が行われました。

地域における中核的な役割を担う病院で診療継続に障害が生じたという社会的責任から、発生当日に第1回目の記者会見を行い、以降も状況の進展に応じて記者会見や報道資料提供等により情報発信を行いました。

職員、関係者の皆様のご尽力により、障害発生から約6週間後に電子カルテシステムを含む基幹システムを再稼働させることができ、外来での電子カルテ運用が再開しました。12月中には病棟での電子カルテ運用を再開し、続いて通常診療に係る部門システムも令和5年1月11日に再開して、診療体制が復旧しました。 

システムの再開にあたっては、計2,000台以上のサーバーおよび端末を初期化してクリーンインストールを行うとともに、今回指摘された脆弱性の改善を実施し、今後の更なるサイバー攻撃に対しても対応できるための対策に取り組みました。

そして、このような事態を招いた原因究明と再発防止について検討いただくために外部有識者による情報セキュリティインシデント調査委員会を設置しましたところ、猪俣委員長をはじめ委員各位にご尽力いただき、多角的な視点からなる報告書と提言をまとめていただきました。今後、本提言を真摯に受けとめ、「ITガバナンスの確立」に全力で取り組んでいく所存です。また、本提言を公表することにより、全国の医療機関においてセキュリティ対策強化の取り組みに役立てていただければと存じます。

今回のシステム障害を通じて痛感したのは、電子カルテを含む情報システムなしでは診療のみならず医事、会計などすべての部門で病院の運営が立ち行かなくなってしまうこと、そして、それを支える医療情報システムには数多くの脆弱性が存在していることです。今後は各病院がセキュリティ強化に自ら取り組むとともに、厚生労働省をはじめとする行政からの具体的な支援、指導が不可欠であると考えています。



【セキュリティ事件簿#2023-100】株式会社ベビーランドタマベビー 弊社が運営する「ECサイト」への不正アクセスによる個人情報漏えいに関するお詫びとお知らせ 2023年3月23日


このたび、弊社が運営する「ECサイト ベビーランド」におきまして、第三者による不正アクセスを受け、お客様のクレジットカード情報(5,246件)が漏洩した可能性があることが判明いたしました。

お客様をはじめ、関係者の皆様に多大なるご迷惑およびご心配をおかけする事態となりましたこと、深くお詫び申し上げます。

なお、個人情報が漏洩した可能性のあるお客様には、本日より、電子メールにてお詫びとお知らせを個別にご連絡申し上げております。

弊社では、今回の事態を厳粛に受け止め、再発防止のための対策を講じてまいります。

お客様をはじめ関係者の皆様には重ねてお詫びを申し上げますとともに、本件に関する概要につきまして、下記の通りご報告いたします。

1.経緯

2022年12月16日、一部のクレジットカード会社から、弊社サイトを利用したお客様のクレジットカード情報の漏洩懸念について連絡を受けました。該当するECサイトは2022年11月4日に閉鎖し、新サイトへ移行しておりましたがお客様の安全を考え2022年12月21日に新サイトでのカード決済を停止いたしました。

同時に、第三者調査機関による調査も開始いたしました。2023年2月24日、調査機関による調査が完了し、2021年3月9日~2022年10月28日の期間に「ECサイト ベビーランド」で購入されたお客様クレジットカード情報が漏洩し、一部のお客様のクレジットカード情報が不正利用された可能性があることを確認いたしました。

以上の事実が確認できたため、本日の発表に至りました。 

2.個人情報漏洩状況 

(1)原因
弊社が運営する「ECサイト ベビーランド」のシステムの一部の脆弱性をついたことによる第三者の不正アクセスにより、ペイメントアプリケーションの改ざんが行われたため。

(2)個人情報漏洩の可能性があるお客様
2021年3月9日~2022年10月28日の期間中に「ECサイト ベビーランド」においてクレジットカード決済をされたお客様5,246名で、漏洩した可能性のある情報は以下のとおりです。
    • カード名義人名
    • クレジットカード番号
    • カード有効期限
    • カードセキュリティコード
    • 顧客情報(会員登録時にご入力頂いたお名前、お名前(フリガナ)、会社名、住所、メールアドレス、電話番号、FAX番号、パスワード、性別、職業、生年月日)
上記に該当する5,246名のお客様については、別途、電子メールにて個別にご連絡申し上げます。

3.お客様へのお願い

既に弊社では、クレジットカード会社と連携し、漏洩した可能性のあるクレジットカードによる取引のモニタリングを継続して実施し、不正利用の防止に努めております。

お客様におかれましても、誠に恐縮ではございますがクレジットカードのご利用明細書に身に覚えのない請求項目がないか、今一度ご確認をお願いいたします。万が一、身に覚えのない請求項目の記載があった場合は、たいへんお手数ですが同クレジットカードの裏面に記載のカード会社にお問い合わせいただきますよう、併せてお願い申し上げます。

なお、お客様がクレジットカードの差し替えをご希望される場合、カード再発行の手数料につきましてはお客様にご負担をお掛けしないよう、弊社よりクレジットカード会社に依頼しております。

4.公表が遅れた経緯について

2022年12月16日の漏洩懸念発覚から今回のご案内に至るまで、時間を要しましたことを深くお詫び申し上げます。

本来であれば疑いがある時点でお客様にご連絡し、注意を喚起するとともにお詫び申し上げるところではございましたが、不確定な情報の公開はいたずらに混乱を招き、お客様へのご迷惑を最小限に食い止める対応準備を整えてからの告知が不可欠であると判断し、発表は調査会社の調査結果、およびカード会社との連携を待ってから行うことに致しました。

今回の発表までお時間をいただきましたこと、重ねてお詫び申し上げます。

5.再発防止策ならびに弊社が運営する新サイトのカード決済の再開について 

弊社はこのたびの事態を厳粛に受け止め、調査結果を踏まえてシステムのセキュリティ対策および監視体制の強化を行い、再発防止を図ってまいります。

「ECサイト ベビーランド」での再開日につきましては、決定次第、改めてWebサイト上にてお知らせいたします。

また、弊社は今回の不正アクセスにつきまして、監督官庁である個人情報保護委員会には2022年12月16日に報告済みであり、また、所轄警察署にも2022年12月20日被害申告しており、今後捜査にも全面的に協力してまいります。

【セキュリティ事件簿#2023-099】東京都 ホームページ掲載データへの個人情報の誤掲載について 2023年03月23日


当局において、以下の通りホームページに掲載したアンケート調査結果への個人情報の誤掲載が発生しましたので、お知らせします。

関係者の皆様には、多大なご迷惑をおかけし、深くお詫び申し上げます。

1 概要

当局が、都の施策の認知状況や都に求める取り組み等、スタートアップとの協働に関するアンケート調査の結果を、東京都オープンデータカタログサイトに掲載した際、データに個人情報(会社名、氏名、メールアドレス)が含まれていた。

サイト上の画面では、漢字や仮名文字のデータは記号等に変換され、判読できない状態であった。メールアドレスについても、セルの操作をしなければ判読できない状態であった。しかし、サイトからデータをダウンロードすると、データ末尾の個人情報が判読可能な状態であった。

2 経緯

  • 令和4年2月4日(金曜日)午後に、会社名等を含むデータを東京都オープンデータカタログサイトに掲載。約230名分の会社名、氏名、メールアドレスがダウンロード可能な状態となっていた。

  • 令和5年3月13日(月曜日)午後に、デジタルサービス局職員が当該サイト上のデータを点検したところ、個人情報が含まれていることを発見し、当日中に当該データを削除した。
3 その後の対応

該当の方々には、謝罪を行っています。
なお、現時点で、被害の報告はありません。

4 再発防止策

今後、このようなことを起こさないよう、掲載するデータに個人情報が含まれないことを、複数の職員でチェックすること等を徹底します。

【セキュリティ事件簿#2023-098】株式会社TRINUS 不正アクセスによる個人情報漏えいに関するお詫びとお知らせ 2023年3月22日


このたび、弊社が運営していた「TRINUS STORE」におきまして、第三者による不正アクセスを受け、お客様のクレジットカード情報(402件)が漏洩した可能性があることが判明いたしました。

お客様をはじめ、関係者の皆様に多大なるご迷惑およびご心配をおかけする事態となりましたこと、深くお詫び申し上げます。

なお、個人情報が漏洩した可能性のあるお客様には、本日より、電子メールにてお詫びとお知らせを個別にご連絡申し上げております。

弊社では、今回の事態を厳粛に受け止め、再発防止のための対策を講じてまいります。

お客様をはじめ関係者の皆様には重ねてお詫びを申し上げますとともに、本件に関する概要につきまして、下記の通りご報告いたします。

1.経緯

2022年7月27日、一部のクレジットカード会社から、弊社サイトを利用したお客様のクレジットカード情報の漏洩懸念について連絡を受け、同日中に弊社が運営する「TRINUS STORE」でのカード決済を停止いたしました。

同時に、第三者調査機関による調査も開始いたしました。2022年11月9日、調査機関による調査が完了し、2021年4月22日~2022年7月27日の期間に「TRINUS STORE」で購入されたお客様クレジットカード情報が漏洩し、一部のお客様のクレジットカード情報が不正利用された可能性があることを確認いたしました。

以上の事実が確認できたため、本日の発表に至りました。

2.個人情報漏洩状況

(1)原因
弊社が運営していた「TRINUS STORE」のシステムの一部の脆弱性をついたことによる第三者の不正アクセスにより、ペイメントアプリケーションの改ざんが行われたため。

(2)個人情報漏洩の可能性があるお客様
2021年4月22日~2022年7月27日の期間中に「TRINUS STORE」においてクレジットカード決済をされたお客様402名で、漏洩した可能性のある情報は以下のとおりです。

・カード名義人名
・クレジットカード番号
・有効期限
・セキュリティコード

その他、データベース管理用ツール”Adminer”の設置により、データベース内の顧客情報の漏えいの可能性もあります。

上記に該当する402名のお客様については、別途、電子メールにて個別にご連絡申し上げます。

3.お客様へのお願い

既に弊社では、クレジットカード会社と連携し、漏洩した可能性のあるクレジットカードによる取引のモニタリングを継続して実施し、不正利用の防止に努めております。

お客様におかれましても、誠に恐縮ではございますがクレジットカードのご利用明細書に身に覚えのない請求項目がないか、今一度ご確認をお願いいたします。万が一、身に覚えのない請求項目の記載があった場合は、たいへんお手数ですが同クレジットカードの裏面に記載のカード会社にお問い合わせいただきますよう、併せてお願い申し上げます。

なお、お客様がクレジットカードの差し替えをご希望される場合、カード再発行の手数料につきましてはお客様にご負担をお掛けしないよう、弊社よりクレジットカード会社に依頼しております。

4.公表が遅れた経緯について

2022年7月27日の漏洩懸念から今回の案内に至るまで、時間を要しましたことを深くお詫び申し上げます。

本来であれば疑いがある時点でお客様にご連絡し、注意を喚起するとともにお詫び申し上げるところではございましたが、不確定な情報の公開はいたずらに混乱を招き、お客様へのご迷惑を最小限に食い止める対応準備を整えてからの告知が不可欠であると判断し、発表は調査会社の調査結果、およびカード会社との連携を待ってから行うことに致しました。

今回の発表までお時間をいただきましたこと、重ねてお詫び申し上げます。

5.再発防止策ならびに弊社が運営するサイトの再開について

弊社はこのたびの事態を厳粛に受け止め、調査結果を踏まえてシステムのセキュリティ対策および監視体制の強化を行い、再発防止を図ってまいります。

なお、「TRINUS STORE」はすでにサービスを終了しておりますので、再開はいたしません。

また、弊社は今回の不正アクセスにつきまして、監督官庁である個人情報保護委員会には2022年7月28日に報告済みであり、また、所轄警察署にも2023年2月1日に被害申告しており、今後捜査にも全面的に協力してまいります。


【TryHackMeウォークスルー】Nmap Advanced Port Scans

 

Task 1  Introduction

ここは、Nmapシリーズ(ネットワークセキュリティ入門モジュールの一部)の3つ目です。

  1. Nmap Live Host Discovery
  2. Nmap Basic Port Scans
  3. Nmap Advanced Port Scans
  4. Nmap Post Port Scans
Nmap Basic Port Scansでは、TCPフラグについて説明し、TCPの3ウェイハンドシェイクを復習しました。接続を開始するために、TCPは最初のパケットにSYNフラグを設定する必要があります。その結果、受信した応答に基づいて、TCPポートが開いているかどうかを判断することができます。

セキュリティ研究者やハッカーは、下図と前回説明したTCPフラグを熟考し、実験を開始しました。TCPパケットを送信した場合、どのようなことが起こるのか、また、どのTCPコネクションにも属さないのに、1つまたは複数のフラグが設定されているのかを知りたいと考えました。


例えば、ACKフラグは、受信したデータを承認したいときに設定します。ACKスキャンは、そもそも送信も受信もされていないデータを承認しようとするようなものです。例えるなら、何も言っていないのに突然「はい、聞こえます、続けてください」と言われるようなものです。

ここでは、高度なスキャンの種類とスキャンオプションについて説明します。これらのスキャンの種類には、特定のシステムに対して有効なものもあれば、特定のネットワーク設定に有効なものもあります。ここでは、次のようなタイプのポートスキャンを取り上げます。

  • Null Scan
  • FIN Scan
  • Xmas Scan
  • Maimon Scan
  • ACK Scan
  • Window Scan
  • Custom Scan

さらに、以下を取り上げます。

  • Spoofing IP
  • Spoofing MAC
  • Decoy Scan
  • Fragmented Packets
  • Idle/Zombie Scan

ファイアウォールやIDSシステムを回避するためのオプションやテクニックについて説明します。また、Nmapからより詳細な情報を取得するためのオプションについても説明します。

■question

 ※無し


Task 2  TCP Null Scan, FIN Scan, and Xmas Scan

まずは、次の3種類のスキャンをご紹介します。

  • Null Scan
  • FIN Scan
  • Xmas Scan

Null Scan

Nullスキャンでは、フラグは設定されず、6 つのフラグビットはすべて 0 に設定されます。このスキャンは、-sN オプションを使用して選択することができます。フラグが設定されていないTCPパケットは、下図に示すように、オープンポートに到達しても何の応答も引き起こしません。したがって、Nmapの観点では、nullスキャンで応答がないのは、ポートが開いているか、ファイアウォールがパケットをブロックしているかのどちらかであることを示しています。


しかし、ポートが閉じている場合、ターゲットサーバーはRSTパケットで応答することが想定されます。その結果、RSTの応答がないことを利用して、閉じていないポートすなわちopenまたはfilteredを把握することができます。


以下は、Linuxサーバーに対するnullスキャンの例です。実施したnullスキャンでは、ターゲットシステム上の6つのオープンポートを正常に識別しています。null スキャンは、これらのポートが開いていることを確実に示すことはできず、ポートがファイアウォール ルールに起因して応答しない可能性もあります。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sN MACHINE_IP

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:30 BST
Nmap scan report for MACHINE_IP
Host is up (0.00066s latency).
Not shown: 994 closed ports
PORT    STATE         SERVICE
22/tcp  open|filtered ssh
25/tcp  open|filtered smtp
80/tcp  open|filtered http
110/tcp open|filtered pop3
111/tcp open|filtered rpcbind
143/tcp open|filtered imap
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 96.50 seconds

多くのNmapオプションはroot権限を必要とすることに注意してください。Nmapをrootで実行しているのでなければ、上の例のように-sNオプションを使用してsudoを使用する必要があります。

FIN Scan

FINスキャンは、FINフラグが設定されたTCPパケットを送信します。このスキャンタイプは、-sF オプションを使用して選択できます。同様に、TCPポートが開いている場合、応答は送信されません。ここでも、Nmapは、ポートが開いているか、ファイアウォールがこのTCPポートに関連するトラフィックをブロックしているかどうかを確認することはできません。


しかし、ポートが閉じられている場合、ターゲットシステムはRSTで応答します。その結果、どのポートが閉じられているかを知ることができ、この知識を使って開いているポートやフィルタリングされているポートを推測することができるようになります。ファイアウォールの中には、RSTを送信せずにトラフィックを「静かに」ドロップするものがあることは注目に値します。


以下は、Linuxサーバーに対するFINスキャンの例である。この結果は、先にnullスキャンを使用して得た結果とよく似ています。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sF MACHINE_IP

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:32 BST
Nmap scan report for MACHINE_IP
Host is up (0.0018s latency).
Not shown: 994 closed ports
PORT    STATE         SERVICE
22/tcp  open|filtered ssh
25/tcp  open|filtered smtp
80/tcp  open|filtered http
110/tcp open|filtered pop3
111/tcp open|filtered rpcbind
143/tcp open|filtered imap
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 96.52 seconds

Xmas Scan

Xmasスキャンは、クリスマスツリーのイルミネーションにちなんで名づけられました。Xmasスキャンは、FIN、PSH、URGフラグを同時に設定します。Xmasスキャンは、オプション-sXで選択することができます。

NullスキャンやFINスキャンと同様に、RSTパケットを受信した場合、そのポートはクローズされていることを意味します。それ以外の場合は、open|filteredと報告されます。

次の2つの図は、TCPポートが開いている場合と閉じている場合を示しています。


以下のコンソール出力は、Linuxサーバーに対するXmasスキャンの例を示しています。得られた結果は、nullスキャンやFINスキャンの結果とよく似ています。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sX MACHINE_IP

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:34 BST
Nmap scan report for MACHINE_IP
Host is up (0.00087s latency).
Not shown: 994 closed ports
PORT    STATE         SERVICE
22/tcp  open|filtered ssh
25/tcp  open|filtered smtp
80/tcp  open|filtered http
110/tcp open|filtered pop3
111/tcp open|filtered rpcbind
143/tcp open|filtered imap
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 84.85 seconds

これら3つのスキャンタイプを効率的に使用できるシナリオの1つは、ステートレス(非ステートフル)ファイアウォールの背後にあるターゲットをスキャンする場合です。ステートレスファイアウォールは、着信パケットにSYNフラグが設定されているかどうかをチェックし、接続の試行を検出します。SYNパケットと一致しないフラグの組み合わせを使用すると、ファイアウォールを欺き、その背後にあるシステムに到達することが可能になります。しかし、ステートフルファイアウォールは、このような細工を施したパケットをすべて実質的にブロックし、この種のスキャンを無意味なものにしてしまいます。

■question

In a null scan, how many flags are set to 1?
0


In a FIN scan, how many flags are set to 1?
1

In a Xmas scan, how many flags are set to 1?
3

Start the VM and load the AttackBox. Once both are ready, open the terminal on the AttackBox and use nmap to launch a FIN scan against the target VM. How many ports appear as open|filtered?
7

Repeat your scan launching a null scan against the target VM. How many ports appear as open|filtered?
7


Task 3  TCP Maimon Scan

Uriel Maimonは1996年にこのスキャンを初めて説明しました。このスキャンでは、FINビットとACKビットが設定さ れます。ターゲットは、応答としてRSTパケットを送信する必要があります。しかし、ある種のBSD由来のシステムでは、オープンポートを公開している場合、パケットをドロップします。このスキャンは、現代のネットワークで遭遇するほとんどのターゲットでは機能しません。しかし、ここではポートスキャンの仕組みとハッキングの考え方をより理解するために、取り入れています。このスキャンタイプを選択するには、-sM オプションを使用します。

ほとんどのターゲット・システムは、TCPポートが開いているかどうかに関係なく、RSTパケットで応答します。このような場合、開いているポートを発見することはできません。下図は、TCPポートが開いている場合と閉じている場合の両方で期待される動作を示しています。


以下のコンソール出力は、Linuxサーバーに対するTCP Maimonスキャンの一例です。前述の通り、オープンポートとクローズドポートは同じ動作をするため、Maimonスキャンではターゲットシステム上のオープンポートを発見することができませんでした。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sM 10.10.252.27

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:36 BST
Nmap scan report for ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27)
Host is up (0.00095s latency).
All 1000 scanned ports on ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27) are closed
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.61 seconds

このタイプのスキャンは、システムを発見するために最初に選ぶスキャンではありませんが、いつ役に立つかわからないため、知っておくことは重要です。

■question

In the Maimon scan, how many flags are set?
2


Task 4  TCP ACK, Window, and Custom Scan

このタスクでは、TCP ACKスキャン、TCPウィンドウスキャンの実行方法、およびカスタムフラッグスキャンの作成方法について説明します。

TCP ACK Scan

まず、TCP ACKスキャンから説明します。その名の通り、ACKスキャンはACKフラグがセットされたTCPパケットを送信します。このスキャンを選択するには、-sAオプションを使用します。下の図に示すように、ターゲットはポートの状態に関係なく、ACKに対してRSTで応答することになります。この挙動は、ACKフラグが設定されたTCPパケットは、今回のケースとは異なり、何らかのデータの受信を確認するために、受信したTCPパケットに応答してのみ送信されるはずであるために起こります。したがって、このスキャンでは、単純なセットアップでは、ターゲット・ポートが開いているかどうかはわかりません。


次の例では、ファイアウォールをインストールする前にターゲットVMをスキャンしています。予想通り、どのポートが開いているのかを知ることはできませんでした。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sA 10.10.86.220

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:37 BST
Nmap scan report for 10.10.86.220
Host is up (0.0013s latency).
All 1000 scanned ports on MACHINE_IP are unfiltered
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.68 seconds

このようなスキャンは、ターゲットの前にファイアウォールがある場合に有効でしょう。その結果、どのACKパケットがレスポンスになったかに基づいて、どのポートがファイアウォールによってブロックされなかったかを知ることができます。つまり、このタイプのスキャンは、ファイアウォールのルールセットと構成を発見するのに適しています。

ターゲットVM 10.10.86.220にファイアウォールを設定した後、ACKスキャンを繰り返しました。今回、興味深い結果が得られました。下のコンソール出力に見られるように、ファイアウォールによってブロックされていないポートが3つあります。この結果は、ファイアウォールがこの3つのポート以外のすべてのポートをブロックしていることを示しています。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sA 10.10.86.220

Starting Nmap 7.60 ( https://nmap.org ) at 2021-09-07 11:34 BST
Nmap scan report for 10.10.86.220
Host is up (0.00046s latency).
Not shown: 997 filtered ports
PORT    STATE      SERVICE
22/tcp  unfiltered ssh
25/tcp  unfiltered smtp
80/tcp  unfiltered http
MAC Address: 02:78:C0:D0:4E:E9 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 15.45 seconds


Window Scan

もう1つの類似のスキャンは、TCPウィンドウ・スキャンです。TCPウィンドウ・スキャンは、ACKスキャンとほぼ同じですが、返されたRSTパケットのTCPウィンドウ・フィールドを検査するものです。特定のシステムでは、これによってポートが開いていることが判明することがあります。このスキャン・タイプは、オプション -sW で選択することができます。下図に示すように、ポートが開いているか閉じているかにかかわらず、「招かれざる」ACKパケットに対する返信としてRSTパケットを受け取ることが予想されます。


同様に、ファイアウォールのないLinuxシステムに対してTCPウィンドウ・スキャンを起動しても、あまり情報は得られません。以下のコンソール出力でわかるように、ファイアウォールのないLinuxサーバーに対するウィンドウスキャンの結果は、先に実行したACKスキャンと比較して、余分な情報を与えていないことがわかります。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sW 10.10.86.220

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:38 BST
Nmap scan report for 10.10.86.220
Host is up (0.0011s latency).
All 1000 scanned ports on ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27) are closed
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

しかし、ファイアウォールの背後にあるサーバーに対してTCPウィンドウスキャンを繰り返すと、より満足のいく結果が得られると思われます。以下のコンソール出力では、TCPウィンドウスキャンによって3つのポートがクローズドとして検出されたことが指摘されています。(これは、同じ3つのポートがフィルタリングされていないとラベル付けされたACKスキャンとは対照的です)。これらの3つのポートが閉じられていないことは分かっていますが、ファイアウォールがそれらをブロックしていないことを示す、異なる反応を示していることに気付かされます。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sW 10.10.86.220

Starting Nmap 7.60 ( https://nmap.org ) at 2021-09-07 11:39 BST
Nmap scan report for 10.10.86.220
Host is up (0.00040s latency).
Not shown: 997 filtered ports
PORT    STATE  SERVICE
22/tcp  closed ssh
25/tcp  closed smtp
80/tcp  closed http
MAC Address: 02:78:C0:D0:4E:E9 (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 14.84 seconds


Custom Scan

内蔵のTCPスキャン・タイプを超える新しいTCPフラグの組み合わせを実験したい場合は、-scanflagsで行うことができます。例えば、SYN、RST、FINを同時に設定したい場合は、-scanflags RSTSYNFINを使用して設定することができます。下図に示すように、カスタムスキャンを開発する場合、異なるシナリオでの結果を正しく解釈するために、異なるポートがどのように動作するかを知っておく必要があります。


最後に、ACKスキャンとWindowsスキャンは、ファイアウォールルールをマッピングする上で非常に効率的でした。しかし、ファイアウォールが特定のポートをブロックしていないからといって、必ずしもそのポートでサービスが listenしているとは限らないということを覚えておくことが重要です。例えば、サービス変更に伴い、ファイアウォールルールを更新する必要がある可能性があります。したがって、ACKとWindowsスキャンは、サービスではなく、ファイアウォールのルールを公開していることになります。

■question

In TCP Window scan, how many flags are set?
1

You decided to experiment with a custom TCP scan that has the reset flag set. What would you add after --scanflags? 
RST


The VM received an update to its firewall ruleset. A new port is now allowed by the firewall. After you make sure that you have terminated the VM from Task 2, start the VM for this task. Launch the AttackBox if you haven't done that already. Once both are ready, open the terminal on the AttackBox and use Nmap to launch an ACK scan against the target VM. How many ports appear unfiltered?
4

What is the new port number that appeared?
443

Is there any service behind the newly discovered port number? (Y/N)
N


Task 5  Spoofing and Decoys

一部のネットワーク設定では、なりすましIPアドレスやなりすましMACアドレスを使ってターゲットシステムをスキャンすることができます。このようなスキャンは、応答をキャプチャできることを保証できる状況でのみ有益です。詐称したIPアドレスを使ってどこかランダムなネットワークからターゲットをスキャンしようとすると、自分にルーティングされたレスポンスがない可能性があり、スキャン結果も信頼できないものになる可能性があります。

次の図は、攻撃者がnmap -S SPOOFED_IP MACHINE_IPというコマンドを実行しているところです。その結果、Nmapは提供されたソースIPアドレスSPOOFED_IPを使用してすべてのパケットを作成します。ターゲットマシーンは、受信したパケットに応答して、宛先IPアドレスSPOOFED_IPに返信を送信します。このスキャンが機能し、正確な結果を得るためには、攻撃者はネットワークトラフィックを監視して、返信を分析する必要があります。


簡単に説明すると、詐称したIPアドレスでのスキャンは3ステップです:
  1. 攻撃者は、送信元IPアドレスを詐称したパケットを対象マシンに送信する。
  2. ターゲットマシンは、偽装されたIPアドレスを宛先として返信する。
  3. 攻撃者は返信をキャプチャしてオープンポートを把握する。
一般的に、-eを使用してネットワーク・インターフェイスを指定し、明示的にpingスキャン -Pn を無効にすることを想定しています。したがって、nmap -S SPOOFED_IP MACHINE_IPの代わりに、nmap -e NET_INTERFACE -Pn -S SPOOFED_IP MACHINE_IPを実行して、Nmapに使用するネットワークインターフェイスとping応答の受信を期待しないことを明示的に伝える必要があります。攻撃側のシステムが応答についてネットワークを監視できない場合、このスキャンは無意味となります。

ターゲットマシーンと同じサブネット上にいる場合、MACアドレスも偽装することができます。送信元MACアドレスは、-spoof-mac SPOOFED_MACで指定することができます。このアドレススプーフィングは、攻撃者とターゲットマシンが同じイーサネット(802.3)ネットワークまたは同じWiFi(802.11)上にある場合のみ可能です。

なりすましは、一定の条件を満たした最小限のケースでしか機能しません。そのため、攻撃者は囮を使うことで、ピンポイントで発見されることを防ぐことができます。コンセプトは簡単で、多くのIPアドレスからスキャンが行われているように見せかけ、攻撃者のIPアドレスがその中に紛れ込むようにするのです。下図のように、ターゲットマシンのスキャンは3つの異なるソースから送られているように見え、その結果、返信は囮にも送られることになります。


-D の後に特定またはランダムな IP アドレスを指定することで、おとりスキャンを起動することができます。例えば、nmap -D 10.10.0.1,10.10.0.2,ME MACHINE_IPは、MACHINE_IPのスキャンがIPアドレス10.10.0.1, 10.10.0.2 から来るように見せ、さらにMEで自分のIPアドレスを3番目に表示すべきことを指示します。別のコマンド例としては、nmap -D 10.10.0.1,10.10.0.2,RND,RND,ME MACHINE_IPがあり、3番目と4番目のソースIPアドレスはランダムに割り当てられ、5番目のソースは攻撃者のIPアドレスになる予定であることがわかります。つまり、後者のコマンドを実行するたびに、2つの新しいランダムなIPアドレスが3番目と4番目のおとりソースになると予想されます。

■question

What do you need to add to the command sudo nmap MACHINE_IP to make the scan appear as if coming from the source IP address 10.10.10.11 instead of your IP address?
-S 10.10.10.11

What do you need to add to the command sudo nmap MACHINE_IP to make the scan appear as if coming from the source IP addresses 10.10.20.21 and 10.10.20.28 in addition to your IP address?
-D 10.10.20.21,10.10.20.28

Task 6  Fragmented Packets

Firewall

ファイアウォールとは、パケットの通過を許可したり、遮断したりするソフトウェアやハードウェアのことです。ファイアウォールのルールに基づいて機能し、例外を除いてすべてのトラフィックをブロックしたり、例外を除いてすべてのトラフィックを許可したりすることができます。例えば、Webサーバーへのトラフィックを除き、サーバーへのトラフィックをすべてブロックすることができます。従来のファイアウォールは、少なくともIPヘッダーとトランスポート層ヘッダーを検査します。より高度なファイアウォールは、トランスポート層で運ばれるデータも検査しようとします。

IDS

侵入検知システム(IDS)は、ネットワークパケットを検査し、特定の行動パターンや特定のコンテンツシグネチャを検出します。IDSは、悪意のあるルールに合致した場合に警告を発します。IDSは、IPヘッダーとトランスポート層のヘッダーに加え、トランスポート層のデータコンテンツを検査し、悪意のあるパターンに一致するかどうかをチェックします。従来のファイアウォール/IDSがNmapの活動を検出する可能性を低くするには、どうすればよいのでしょうか。これに答えるのは簡単ではありません。しかし、ファイアウォール/IDSの種類によっては、パケットをより小さなパケットに分割することでうまくいく場合があります。

Fragmented Packets

Nmapには、パケットを断片化するためのオプション-fが用意されています。一度選択すると、IPデータは8バイト以下に分割されます。さらに-fを追加すると(-f -fまたは-ff)、データは8バイトではなく16バイトの断片に分割されます。デフォルト値は--mtuを使用して変更できますが、常に8の倍数を選択する必要があります。

フラグメンテーションを正しく理解するためには、下図のIPヘッダを見る必要があります。最初は複雑に見えるかもしれませんが、ほとんどのフィールドがわかっていることに気がつきます。特に、送信元アドレスは4行目に32ビット(4バイト)、宛先アドレスは5行目にさらに4バイトを占めていることに注目してください。複数のパケットに分割されるデータは、赤でハイライトされています。受信側での再組み立てを支援するために、IPは下図の2行目に示す識別(ID)とフラグメントオフセットを使用します。


sudo nmap -sS -p80 10.20.30.144 と sudo nmap -sS -p80 -f 10.20.30.144 を実行して比較してみましょう。もうお分かりのように、これはポート80でステルスTCP SYNスキャンを使用します。しかし、2番目のコマンドでは、NmapにIPパケットの断片化を要求しています。

最初の2行では、ARPクエリと応答が確認できます。ターゲットが同じイーサネット上にあるため、NmapはARPクエリを発行しました。2行目には、TCP SYN pingとその応答が示されています。5行目はポートスキャンの始まりで、Nmapはポート80にTCP SYNパケットを送信しています。この場合、IPヘッダは20バイト、TCPヘッダは24バイトである。TCPヘッダの最小サイズは20バイトであることに注意してください。


-f でフラグメントを要求すると、TCPヘッダーの24バイトは8バイトの倍数に分割され、最後のフラグメントにはTCPヘッダーの8バイト以下が含まれます。24は8で割り切れるので、3つのIPフラグメントが得られました。それぞれが20バイトのIPヘッダーと8バイトのTCPヘッダーを持ちます。5行目から7行目にかけて、3つのフラグメントが確認できます。


なお、-ff(または-f -f)を付けた場合、データの断片化は16の倍数になります。つまり、この場合、TCPヘッダーの24バイトは、2つのIPフラグメントに分割され、最初のフラグメントは16バイト、2番目のフラグメントはTCPヘッダーの8バイトを含みます。

一方、パケットのサイズを大きくして無難に見せたい場合は、オプション --data-length NUM を使用することができ、num にはパケットに追加したいバイト数を指定します。

■question

If the TCP segment has a size of 64, and -ff option is being used, how many IP fragments will you get?
4

Task 7  Idle/Zombie Scan

送信元IPアドレスを偽装することは、ステルススキャンを行う上で非常に有効な手段です。ただし、スプーフィングが機能するのは、特定のネットワーク設定に限られます。また、トラフィックを監視できる位置にいることが必要です。これらの制限を考慮すると、IPアドレスのスプーフィングはほとんど役に立ちませんが、アイドルスキャンでこの方法をアップグレードすることは可能です。

アイドルスキャン(ゾンビスキャン)には、ネットワークに接続され、通信可能なアイドルシステムが必要です。実際、Nmapは各プローブをアイドル(ゾンビ)ホストから発信されているように見せかけ、ゾンビホストが偽装されたプローブに対して何らかの応答を受け取ったかどうかを指標にチェックします。これは、IPヘッダーのIP識別(IP ID)値をチェックすることで実現されます。nmap -sI ZOMBIE_IP MACHINE_IP(ZOMBIE_IPはゾンビのIPアドレス)を使用して、アイドルスキャンを実行することができます。

アイドル(ゾンビ)スキャンでは、ポートが開いているかどうかを発見するために、次の3つのステップが必要です:
  1. アイドルホストの現在のIP IDを記録できるように、アイドルホストが応答するようにトリガーをかける。
  2. ターゲットのTCPポートにSYNパケットを送信する。このパケットは、アイドルホスト(ゾンビ)のIPアドレスから送信されているように見えるように偽装する必要があります。
  3. アイドルマシンを再度トリガーして応答させ、新しいIP IDと先に受信したIP IDを比較できるようにする。
図を使って説明しましょう。下の図では、攻撃者システムがアイドル状態のマシンであるマルチファンクションプリンターを探っているところです。SYN/ACKを送信すると、新たにインクリメントされたIP IDを含むRSTパケットで応答しています。


攻撃者は、次のステップでターゲットマシンのチェックしたいTCPポートにSYNパケットを送信します。ただし、このパケットは、アイドルホスト(ゾンビ)のIPアドレスを送信元として使用します。このとき、3つのシナリオが発生します。下図に示す最初のシナリオでは、TCPポートが閉じられているため、ターゲットマシンはRSTパケットでアイドルホストに応答します。アイドルホストは応答しないので、そのIP IDはインクリメントされません。


2番目のシナリオでは、以下に示すように、TCPポートが開いているため、ターゲットマシンはアイドルホスト(ゾンビ)に対してSYN/ACKで応答します。アイドルホストはこの予期せぬパケットにRSTパケットで応答し、IP IDをインクリメントします。


3つ目のシナリオでは、ファイアウォールルールによりターゲットマシンが全く応答しない。この応答の欠如は、閉じたポートの場合と同じ結果を招きます。アイドルホストはIP IDを増加させません。

最後のステップとして、攻撃者はアイドルホストに再度SYN/ACKを送信する。アイドルホストはRSTパケットで応答し、IP IDを再び1つ増加させる。攻撃者は、最初のステップで受信したRSTパケットのIP IDと、この3番目のステップで受信したRSTパケットのIP IDを比較する必要があります。その差が1であれば、ターゲットマシンのポートが閉じられたかフィルタリングされたことを意味します。しかし、その差が2であれば、ターゲットのポートが開いていたことを意味します。

このスキャンがアイドルスキャンと呼ばれるのは、スキャンの精度を上げるためにはアイドルホストの選択が不可欠であるためです。繰り返し述べておきます。もし「アイドルホスト」がビジーであれば、返されたIP IDはすべて無駄になってしまいます。

■question

You discovered a rarely-used network printer with the IP address 10.10.5.5, and you decide to use it as a zombie in your idle scan. What argument should you add to your Nmap command?
-sI 10.10.5.5

Task 8  Getting More Details

Nmapにその理由と結論に関する詳細を提供させたい場合は、--reasonの追加を検討することができます。後者の例では--reasonを追加しています。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sS 10.10.252.27

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:39 BST
Nmap scan report for ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27)
Host is up (0.0020s latency).
Not shown: 994 closed ports
PORT    STATE SERVICE
22/tcp  open  ssh
25/tcp  open  smtp
80/tcp  open  http
110/tcp open  pop3
111/tcp open  rpcbind
143/tcp open  imap
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.60 seconds

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sS --reason 10.10.252.27

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:40 BST
Nmap scan report for ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27)
Host is up, received arp-response (0.0020s latency).
Not shown: 994 closed ports
Reason: 994 resets
PORT    STATE SERVICE REASON
22/tcp  open  ssh     syn-ack ttl 64
25/tcp  open  smtp    syn-ack ttl 64
80/tcp  open  http    syn-ack ttl 64
110/tcp open  pop3    syn-ack ttl 64
111/tcp open  rpcbind syn-ack ttl 64
143/tcp open  imap    syn-ack ttl 64
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds

--reason フラグを指定すると、Nmap がシステムが稼働している、または特定のポートが開いていると結論づけた明確な理由が表示されます。上のコンソール出力では、Nmapが「arp-responseを受信した」ため、このシステムがオンラインと判断されたことがわかります。一方、Nmapが "syn-ack "パケットを受信して戻ってきたため、SSHポートが開いていると判断されたことがわかります。

より詳細な出力を得るには、-vで冗長な出力を、-vvでさらに冗長な出力が可能です。

Pentester Terminal
pentester@TryHackMe$ sudo nmap -sS -vv 10.10.252.27

Starting Nmap 7.60 ( https://nmap.org ) at 2021-08-30 10:41 BST
Initiating ARP Ping Scan at 10:41
Scanning 10.10.252.27 [1 port]
Completed ARP Ping Scan at 10:41, 0.22s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 10:41
Completed Parallel DNS resolution of 1 host. at 10:41, 0.00s elapsed
Initiating SYN Stealth Scan at 10:41
Scanning ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27) [1000 ports]
Discovered open port 22/tcp on 10.10.252.27
Discovered open port 25/tcp on 10.10.252.27
Discovered open port 80/tcp on 10.10.252.27
Discovered open port 110/tcp on 10.10.252.27
Discovered open port 111/tcp on 10.10.252.27
Discovered open port 143/tcp on 10.10.252.27
Completed SYN Stealth Scan at 10:41, 1.25s elapsed (1000 total ports)
Nmap scan report for ip-10-10-252-27.eu-west-1.compute.internal (10.10.252.27)
Host is up, received arp-response (0.0019s latency).
Scanned at 2021-08-30 10:41:02 BST for 1s
Not shown: 994 closed ports
Reason: 994 resets
PORT    STATE SERVICE REASON
22/tcp  open  ssh     syn-ack ttl 64
25/tcp  open  smtp    syn-ack ttl 64
80/tcp  open  http    syn-ack ttl 64
110/tcp open  pop3    syn-ack ttl 64
111/tcp open  rpcbind syn-ack ttl 64
143/tcp open  imap    syn-ack ttl 64
MAC Address: 02:45:BF:8A:2D:6B (Unknown)

Read data files from: /usr/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 1.59 seconds
           Raw packets sent: 1002 (44.072KB) | Rcvd: 1002 (40.092KB)

もし、-vvで満足できない場合は、-dでデバッグの詳細を、-ddでさらに詳細な情報を得ることができます。dを使えば、1画面を超える出力が得られます。

■question

Launch the AttackBox if you haven't done so already. After you make sure that you have terminated the VM from Task 4, start the VM for this task. Wait for it to load completely, then open the terminal on the AttackBox and use Nmap with nmap -sS -F --reason MACHINE_IP to scan the VM. What is the reason provided for the stated port(s) being open?(AttackBoxのターミナルを開き、Nmapをnmap -sS -F --reason MACHINE_IPで使用して、VMをスキャンします。指定されたポートが開いている理由は何ですか?)
syn-ack

Task 9  Summary

ここでは、次のようなスキャンの種類を扱いました。

Port Scan TypeExample Command
TCP Null Scansudo nmap -sN MACHINE_IP
TCP FIN Scansudo nmap -sF MACHINE_IP
TCP Xmas Scansudo nmap -sX MACHINE_IP
TCP Maimon Scansudo nmap -sM MACHINE_IP
TCP ACK Scansudo nmap -sA MACHINE_IP
TCP Window Scansudo nmap -sW MACHINE_IP
Custom TCP Scansudo nmap --scanflags URGACKPSHRSTSYNFIN MACHINE_IP
Spoofed Source IPsudo nmap -S SPOOFED_IP MACHINE_IP
Spoofed MAC Address--spoof-mac SPOOFED_MAC
Decoy Scannmap -D DECOY_IP,ME MACHINE_IP
Idle (Zombie) Scansudo nmap -sI ZOMBIE_IP MACHINE_IP
Fragment IP data into 8 bytes-f
Fragment IP data into 16 bytes-ff
オプション目的

--source-port PORT_NUM

specify source port number

--data-length NUM

append random data to reach given length
これらのスキャンタイプは、TCPフラグを予期せぬ方法で設定し、ポートに応答を促すことに依存しています。Null、FIN、Xmasスキャンは閉じたポートからの応答を、Maimon、ACK、Windowスキャンは開いたポートおよび閉じたポートからの応答を誘発します。

オプション目的
--reasonexplains how Nmap made its conclusion
-vverbose
-vvvery verbose
-ddebugging
-ddmore details for debugging

■question(無し)

第3回九州サイバーセキュリティシンポジウム振り返り

 

第3回九州サイバーセキュリティシンポジウム(3/16~3/17)に参加してきた。

昨年は北九州開催で1日のみだったが、今回は長崎開催で2日間。

2日目は午前中でシンポジウム終わりなので、金曜午後と土、日は長崎観光にして地域経済にも貢献することを試みる。

では講演メモ

①産業分野におけるサイバーセキュリティ政策

いざというときに備えて、平時からインシデント対応ベンダーの確保をしておきましょうという話があったが、自分はあまり考えていなかった。

冷静に考えると、コロナ過の初期にPCR検査や発熱時の相談先でかかりつけ医がいる人はかかりつけ医に相談できたのに対して、かかりつけ医がいない人は右往左往したのと同じ理屈なのかもしれない。

インシデント対応が自組織で完結できれば良いが、そんな組織はほとんどなく、日ごろから特定のセキュリティベンダーとの付き合いは必要であることを学んだ。

最近セキュリティにおけるサプライチェーンリスクの顕在化事例が多くなってきている(個人的にはメタップスペイメントショーケースなどがそうだと思っている)が、特に中小企業に対するセキュリティ対策について独禁法や下請け法的な観点でどこまで求めるべきなのかという相談が経産省に対して多く寄せられているらしい。

サイバーセキュリティ対策の要請自体は直ちに問題になることはないというのが後援での見解で、関連文書が出ていることを教えてもらった。

サプライチェーン全体のサイバーセキュリティの向上のための取引先とのパートナーシップの構築に向けて

また、近年ITマネジメントがロクに出来ない企業がEC-CUBEのようなオープンソースに手を出して大やけど(クレカ流出被害)する事例が続出しているが、OSS管理手法に関する事例集についてのリマインドがあった。(自分もすっかり存在を忘れていた・・・)

SBOMについてはその重要性が取りざたされているが、SBOMを食品の成分表に例えた話はとても分かりやすかった。

最後に、「ECサイト構築・運用セキュリティガイドライン」のリリースの共有があった。

先日、被害事例が絶えないEC-CUBEの自組織への導入を阻止したところ、「じゃー何ならいいんだ」みたいな話になっているので、参考にしようと思う。

②TOTO株式会社におけるセキュリティ対策について

TOTOが北九州に本社がある会社であることをこの時初めて知った。

個人的にはユーザー企業の事例紹介が一番好き。

いくつも参考になる話があったが、何点か感じたことをあげてみる。

・EDRはMDRとセットにしないと、正直役に立たないのではないかと感じた。

・グローバルでのインシデント対応体制の確立
 ⇒緊急時に現地の専門家の支援を受けられるようにする
  ⇒ユーザー企業で社員を現地に向かわせるのはいろいろハードルが高い。

・セキュリティツールは全端末に導入
 ⇒未導入端末は検出して督促し、確実に穴を塞ぐ

・EPPとEDRは相性問題が発生する可能性も考慮する
 ⇒相性問題発生時はどちらかをチューニングする必要がある

・リモートワークの常態化を踏まえるとVPNは無くしたい
 ⇒業務がブラウザベースであればSWGに移行

・ホワイトリスト運用は破綻するリスクが高い

・ログ分析で使えるツール
 ⇒CDIRコレクタ
 ⇒CyberChef

・セキュリティ対策は終わりも完成もない

③地域医療における医療DX ~長崎県@あじさいネットの取り組み~

(略)

④パネルディスカッション

FFRI前田氏、サイボウズ松本氏、EY松下氏、LAC西本社長による地域セキュリティコミュニティに関するパネルディスカッション。

西本社長が司会をするパネルディスカッションは毎回聞いていて面白い。

「公助」という言葉を強く意識させられたパネルディスカッションだった。

特に中小企業や一人情シスの組織なんかは「公助」が命綱に近い存在なのかもしれない。

一つ私が知らなかったのは、Grafsecという組織の存在。

こういうのに参加することで、日本のセキュリティレベルの底上げに貢献できるのではと思った(活動時間をどうねん出するかは悩ましいが・・・・)

食事・ナイトセッション

参加者には長崎名物卓袱(しっぽく)弁当とドリンクが振舞われた。


ご当地ドリンク、クラフトチューハイはアルコール度8%。


酔いが回ってナイトセッションはほとんど記憶がありません・・・

⑤業務執行としての情報セキュリティ再考

二日目の最初のセッション。

視点が重要。セキュリティ担当者は特損の発生を防ぐために日々頑張るが、経営層はDX(セキュリティ含む)で事業に対してプラスの効果を出したい。

机上演習は重要で、実施後の評価とフィードバックが重要(社長の発言内容が一般常識から乖離していないかのチェック。記者会見で「寝てないんだよ!」とかの失言はないか、とか)

インシデント対応を進めていくと、「原因究明派」と「拡大防止派」との派閥争いが起きるらしい(すごくわかる気がする・・・)

個人情報保護委員会のサイトによると、全てのケースが必ずしも公表しなければならないわけではない(公表しない方が良いケースも存在する)

参考:サイバー攻撃被害に係る情報の共有・公表ガイダンスのポイント

⑥なぜ、Zホールディングスはバグバウンティを推進するのか

バグバウンティの最大のデメリットの一つがハッカーの身元保証をどうするかであるが、セキュリティプラットフォーム(HackerOne、Synack)を活用、というか信用することにしているらしい。

2019年~2022年までの実績のデータはとても興味深いものだった(その場限りの情報だと思うので、ここでは控えることにする)。

バグバウンティは開催期間が長くなると参加者が減る傾向にあるが、報奨金を増やすことで参加者も増えるらしい。

⑦船舶を取り巻くサイバーセキュリティの現状について

外航海運は貿易量の99.5%を占める。それを担う隻数は2,000超で、日本の人口が急減しない限り、輸入大国の日本はこの規模の船が必要。

にもかかわらず、海運は重要インフラの14分野に入っていない。

船も今後自動航行等の技術革新が起きるが、それに伴ってサイバーセキュリティの問題が起きる(2017年にはGPSスプーフィングにより、黒海で別の位置に誘導されるインシデントが発生)

⑧サイバー犯罪の現状と対策

(略)

--

2022年は参加者全員にお土産が配られたが、今年は抽選に変わっていてちょっと残念だった。

九州サイバーセキュリティシンポジウムは毎年開催場所が変わるということで、毎年参加できると必然的に九州の様々な地を旅することができる。

これは素晴らしい企画である。是非継続してほしい。

強いて難点を言うとすれば、チケットがやや争奪戦気味になっている点。ふつーに開催1週間前でもチケットが購入できるような環境になると嬉しい。

あと、小耳にはさんだ話、九州域内には数百人規模でカンファレンスを行う様な場所(ハコ)が少ないらしい。

ちなみに今回の会場となった出島メッセ長崎もつい最近できた施設の様である。

主催者の皆様、ご苦労様です。応援しています。

参考:第3回九州サイバーセキュリティシンポジウムアーカイブ