ランサムは重要施設と相性が良い

当たり前の事ではあるのでしょうが、ハッカーは重要インフラだろうが関係なく襲ってきます。9/26に攻撃を受けたサンディエゴ港の攻撃は、日本でも警戒すべき事がありそうです。

jp.cointelegraph.com

サンディエゴ港のシステムがランサムウェアによるサイバー攻撃を受け、連邦捜査局（FBI）および米国国土安全保障省（DHS）が捜査を開始した。AMBクリプトが伝えた。

犯人はビットコイン（BTC）で身代金を要求。その金額は明らかにされていないが、FBIとDHSが動いたという事実が事の重大性を示唆している。

最初の報道は25日のことで、「同港の情報技術システムが攻撃された」と報じられた。しかし、サンディエゴ港側は「被害を受けたのは管理機能のみで、港は通常通り運営している」と発表。現在、沿岸警備隊の協力のもとで各分野の専門家を集めてシステムの復旧を進めているという。

同港は米国の中でも最大規模の取引量を誇り、毎年扱う積荷はおよそ300万トン以上。攻撃を受け、現在はセキュリティの観点から関連システムを事前にシャットダウンするとともに、業務関連サービス、記録要求、上陸許可証の発行を一時停止している。

（Cointelegraph Japan記事より引用）

 

■公式発表

　Port of San Diego Issues Statement on Cybersecurity Incident

 

◆キタきつねの所感

この少し前（9/20）には、バルセロナ港もサイバー攻撃を受けています。この際は、陸上での操業に影響は出たようですが、大きな被害まではいかずにすんだようです。

www.ara.cat

同じ攻撃キャンペーンであるかどうかは分かりませんが、同じ週に起きている事件を考えると港湾施設に対して、他のハッカーも、世界の有名な港の脆弱性を探してくる可能性は高いかも知れません。

ランサムウェア（ビットコイン要求）の影響としか、報道されている事はありませんので想像になりますが、こうした事件の背景には、IoT機器の普及もランサム感染端末（事件の影響）の拡大に影響していそうです。

ZDnetの記事には、

Updated on September 27, 14:00 ET:

A Port of San Diego spokesperson confirmed via email that the cyber-attack was a ransomware infection.

今回の攻撃は、Eメール経由（誰か添付ファイルを開いてしまった・・という事でしょう）が追加発表されています。ハッカー側のビットコインの要求額は公表されていませんが、どうやらサンディエゴ港は身代金（ランサム）は支払わずに復旧を目指しているようです。

身代金額が公表されなかった事は、重要施設であるがゆえにかなり高額な要求であったのかも知れません。港でのオペレーションが止まる事の影響を考えると、事件の混乱が長引けば長引くほど、次の港湾施設への攻撃の可能性が高くなる気がします。

とは言え、10/4時点ではまだ復旧中との記事がありましたので、かなり影響を受けている可能性が高そうです。

ランサムという意味では、2017年のNotPetyaで海運大手のMaerskが大きな被害を受けた事を思い出します。

japan.zdnet.com

この時は、船は医療機器と同じく安定運用が重要なので、パッチ当てなどが難しい面があるという記事をいくつか見かけました。船と港湾は違うかも知れませんが、パッチ当てが出来ない事を受容するのであれば、襲われる（被害を受ける）事を前提とした、検知・回復策へのウェイトを高めていくしかないのではないでしょうか。

更新履歴

• 2018年10月7日AM（予約投稿）

郷に入っては郷に従え

中国人旅行客のスウェーデンでの騒乱について、日経ビジネスの記事が出ていました。

business.nikkeibp.co.jp

・中国人親子3人（“曽”姓の息子とその両親）が到着したのは、9月2日の午前0時過ぎだった。

・同日の宿泊予約をしているので、直ちに部屋を手配するよう要求した。職員はこれに対し、今は満室で用意できる部屋がないし、確かに9月2日の予約はあるが、9月2日のチェックインは午後2時からなので13時間半後に出直して欲しいと応じた。

・彼らはロビーの大きなソファーに横たわって就眠しようとし始めたのだ。

・これに驚いた職員は、3人に対して安全上の観点からロビーでの就眠は許されないと伝えて、直ちにホステルから退去するよう要求した

・息子は憤然と「どうしてロビーで寝てはいけないのか。俺たちは予約を持っている客だぞ。チェックインするまで、ここで待っていて何が悪い」

・自分の両親は病気持ちなので、この寒空（当時の気温は10℃以下）に追い出されて何かあったら、どうしてくれるのだ。お前に責任を取ってもらうぞ」と脅しをかけた

・職員はこのまま無益な交渉を続けてもらちが明かないと判断して、不法滞在を理由に事態を警察へ通報した。スウェーデン警察の警官数名がホステルへ到着したのは午前1時43分と警察の記録にあるから、3人はホステルのロビーに1時間半以上滞在し、その間に息子が職員と揉めていたことになる。

・3人は懸命に抵抗したが、⼤柄な警官たちによって力ずくで次々とホステルの出入口から運び出され、ホステルに面した歩道上に放置された。

・すると、父親が突然路上へ倒れ込み、それを見た母親が大きな身振りと大声で泣き叫び始めた。

・「皆さん見て下さい。スウェーデン警察は人殺しだ」

 （日経ビジネスオンライン記事より引用）

◆キタきつねの所感

この事件について、断片的にニュースが出ていましたが、この記事は情報がよくまとまっており、情報が正しければ、事件についてスウェーデン政府に公式なクレームを出した中国政府が真っ青になる内容です。最初のニュースでは『ホテル』と報じられていたのですが、より格安な『ホステル』が正しかったようです。

だとすれば、上記記事でも分析されていましたが、夜中にやってきた不審な客（クレーマー）に対してセキュリティ上の理由で滞在を許可しないのも妥当性があるのではないでしょうか？

ホテルの値段をTripadvisorで見てみると、1泊1万円（3人）くらいでした。

www.tripadvisor.jp

どういった部屋を予約していたか分かりませんが、高級ホテルという訳でなく、こうした格安な部屋を持つ宿泊施設です。経費も考えると、一流ホテルほどに深夜にフロント・警備スタッフが居るとは思えません。

（下記写真はいずれもTripadvisorから引用）

ホテル内写真で見る限り、奥左がフロントで、くだんの中国人旅行客が寝ようとしていたのが、この右下側のソファーという感じだったのかなと思いました。

大手ホテルとは違い、ソファーの数が少ないホステルでは、、こんな所に大きな荷物を抱えた不審な客が寝ていたら、宿泊客が不審な客を怖がる（※私が宿泊客だったら嫌です）のもあるでしょうし、朝食やチェックアウトの時間帯も寝ていたら、それこそ宿泊施設としての評判が下がる事も考えるかと思います。

ホテル側がダブルブッキングでもしていたのなら、ホテル側に講義する事もあるでしょう。ですが、今回の事件、どう考えても自分たちが宿泊時間のミスをしておいて、ホテル側に責任がないのにも関わらずクレームをつけているだけにしか思えません。 

foxsecurity.hatenablog.com

韓国のことわざには、『泣く子は多く餅を貰う』というものがある（※その代償として好意を失っている気がするのですが・・・）そうですが、同じ匂いを感じました。

そう思っていたら、記事の後半に中国ネットユーザの人肉検索（ネット民による調査）に基づく情報が載っていました。

　要するに、曽驥という人物は札付きの悪であり、その両親も同類であることが判明したのである。さらに悪いことには、事件発生から2週間後の9月17日に、彼ら3人が事件後もストックホルムにとどまり、市内を楽しく観光して回っていた事実が、ネット上に写真付きで暴露されたのだった。こうなると、スウェーデン政府に対して拳を振り上げた中国外務省も駐スウェーデン中国大使館も立つ瀬がない

 （日経ビジネスオンライン記事より引用）

人殺し！と叫んでいた親子3人（※一部情報では、ホテル代を節約するために後から登場した息子の嫁も居たらしいとの記事も有）は、何で2週間以上も旅行を楽しむのか・・・やはりクレーマー旅行客の一方的な言い分に基づく政府間の公式なコメントを出した中国政府が悪かったのかなと思います。

中国語のことわざ『入郷随俗』（郷に入っては郷に従え）、やはりこれに尽きるのではないでしょうか。

更新履歴

• 2018年10月7日AM（予約投稿）

PCI DSSはやはり準拠維持が難しい

日本語版は最近は出てなかった気がしますが、ベライゾンのレポートは、セキュリティ関係の方であれば目を通しておいても良いものだと思います。

news.mynavi.jp

ベライゾンジャパンは10月1日、「2018年版ベライゾンペイメントセキュリティ報告書」を発表した。同報告書は、2016年から2017年にかけて、同社の認定セキュリティ評価機関が、PCIデータセキュリティスタンダード(PCI DSS)の評価を行う過程で収集したデータを基に分析を行ったもの。

調査の結果、PCI DSSへの完全準拠の割合が、前回は55.4%だったところ、今回は52.5％と減少したことが明らかになった。この結果は地域によって差異があり、77.8％のアジア太平洋地域の企業が完全準拠を達成する一方、ヨーロッパ（46.4％）や北中南米（39.7％）の準拠率は低調となっているという。

業種別では、ITサービスが最も準拠率が高く、4分の3を超える企業（77.8％）が完全準拠を達成している。また、小売業（56.3％）および金融サービス（47.9％）は、準拠状態の維持率が最も低かったサービス業（38.5％）を大きく引き離している。

ただし、米Verizon Executive Director, Global Security ServicesのBrain Sartin氏は「PCI DSSに基づくコンプライアンスは、必ずしも安全であることを意味しない」と指摘する。なお、同社が調査したペイメントカードのデータ漏洩においては、2010年以来、情報漏洩を起こした企業・組織は漏洩した時点でPCI DSSへの準拠が完全ではなかったという。

（マイナビニュース記事より引用）

◆キタきつねの所感

ベライゾンは、レポートの日本語完全翻訳はしてないのですが、エグゼクティブサマリーがドリームニュースなどで紹介されていました。

2018年版ベライゾンペイメントセキュリティ報告書を発表 PCIコンプライアンスの完全準拠率6年ぶりの低下を報告 | ベライゾンジャパン | プレスリリース配信代行サービス『ドリームニュース』

いかにも英語から翻訳された文章なので、日本語が読みづらいのですが、サマリーを読むと昨今のセキュリティインシデントの動向と乖離してないデータが出てきたと言えそうです。

まず注目すべきなのは、完全準拠の比率が落ちたことかも知れません。

全世界のデータとして、２つの要素があるかと思います。１つがサイバー攻撃が、小学生がハッカーとなる位に一般（コモディ）化していて、防衛側が追いついて無い事の影響です。もう１つが特に新たに認定を受けた組織が、その維持（正確には更なるセキュリティ対策）の意味を真剣に考えて無いという事です。

アジアではPCI DSS準拠組織は増えており、高い準拠維持率を誇りますが、日本の組織（加盟店）の多くはカード情報非保持に舵を切ったので、この数字の中にあまり含まれません。

サービス業の維持率が低いのは、EquifaxやUber、Facebookなどカード情報だけでなくあらやる情報が集約されるプラットフォーム事業者を狙ってハッカーが攻撃している部分もあるでしょう。またFinTech系の企業は自社のサービス立ち上げに一生懸命ではありますが、Zaif（テックビューロ）やコインチェックの例を見るまでもなく、そのセキュリティは公表している事を真摯に実施してない所、例えばホットウォレットを狙われて大きな事件を起こしています。

事故までは至らないまでも、ヒヤリハットまで考えるともっと多いでしょうし、カード情報漏えい事件（の可能性）が発生しても『報告してない＝隠蔽している』組織も結構あると思います。

では何故、PCI DSSの準拠維持が難しいのか、、、やはり監査を通す為の活動になっているからだと思います。IT監査に携わった事がある人ならお分かりになるかも知れませんが、監査員が限られた時間でチェックされた結果でしかありません。言い方を変えれば、監査員に事前に揃えられた『綺麗な証跡』を見せるかインタビューで『やってます』と答え続ける事で、監査は通ってしまう事もあります。優秀な監査官であれば、それを踏まえた上で様々なチェックをする訳ですが、残念ながら年1回の監査で出チェックできる事は限られており、それだからこそ、日常のルーチンワークにおけるセキュリティ維持（PCI DSSではBusiness As Usualという言葉で説明されています）が重要なのです。

監査員をごまかして、あるいは自己問診表（SAQ)を適当にやっていますと書いた回答を通す事で、準拠はできるかも知れませんが、外部のハッカー（あるいは内部犯行者）は脆弱点を探して攻撃をしてくるのであり、そこには形式上、セキュリティをやってますという認定や証明は意味をなさなくなってきているのです。

そうした意味において、

「PCI DSSに基づくコンプライアンスは、必ずしも安全であることを意味しない」と指摘する。

というベライゾンの言う事は正しく、『少なくてもやっておくべき事』、この考え方でPCI DSSに取り組む事が重要なのだと思います。

日本は・・・PCI DSSの概念（要求されている背景）を理解せずに、安易にカード情報非保持を選択している組織が多く、実装ミスや、どこかに消し忘れのデータがある事が事件になる事が未だに続いてます。

つまり、もっと大きな事件が出てきてしまう可能性は高いかも知れません。

参考：レポート（英語）はこちら。

www.verizonenterprise.com

更新履歴

• 2018年10月7日AM（予約投稿）

最悪なパスワード設定はメーカー責任

カリフォルニアだから法案が成立すれば影響が出るかも知れません。　※10/1追記（法案通ったようです）

forbesjapan.com

カリフォルニア州ではこの状況を見かねた議員が、メーカーに対策を講じることを迫る法案を提出し、注目を集めている。州知事のジェリー・ブラウンに提出された法案は、デバイスメーカーらに2つの対策を要求している。

その1つは、セットアップ段階でユーザーにパスワードの変更を強制するもので、一般的に「最悪のパスワード」として知られる123456やpasswordを認めないよう求めている。また、もう1つの要求として議員らは、カリフォルニア州で販売される全てのネット接続デバイスの初期IDとパスワードの組み合わせを、ユニークなものにすることを求めている。

（Forbes記事より引用）

 

◆キタきつねの所感

注目したい法案の動きです。シリコンバレー等、ITベンチャーやFinTechが多く拠点を置くカリフォルニア州の法案です。最悪なパスワード、ニュース等で聞いた事がある方も多いかも知れませんが、最近だとSplashDataが毎年発表するリストが有名です。

gigazine.net

『123456』『password』『admin』といったパスワードは未だに多く使われており、APT攻撃だのリスト型攻撃だの言われる不正アクセス事件において、実はこうしたパスワードが設定されている事に起因していた被害というのは未だに多いようです。※背景としてIoT機器のBot化も影響してそうです。

容易に推測できるパスワードを設定するのは、ユーザの選択とはいえ、事件が多発している現状を考えると、メーカー側が対処すべきと、

• 　初期ID/パスワードが全ての機器で同じにしない（例 ID=Admin Pass=Admin)
• 　機器毎に個別のパスワードを設定するか、ユーザ側の変更を義務づける
• 　少なくても危ないと言われるパスワード（位）はセットできないようにする

を要求しているIoT機器向けの法案のようですが、極めて現実的で効果が高い要求かと思います。

最悪なパスワードとしてSplash Dataが毎年発表するリストですが、実際には上位のパスワードは毎年ほとんど同じです。これはつまり、実際に漏洩事件で痛い目にあっているはずのユーザが、結局は同じ脆弱なパスワードを使っている（使いまわししている）事なのだと思います。

ユーザへの啓蒙は限界がある、のだとすれば、それを提供する側に求める。今回の対象は主にIoT機器ですが、私個人としては日本でも同じ事をベンダーやサービスプロバイダーにも要求して欲しいと思います。

■10/1追記（法案がどうやら通ったようです）

www.technologyreview.jp

更新履歴

• 2018年9月30日PM（予約投稿）
• 2018年10月1日AM　法案成立の記事を追記

配達の安全性は性悪説で

米国Amazonの記事が気になりました

www.businessinsider.jp

アマゾンは、配送トラックに偽ラベルを貼った空の荷物を仕掛けていると情報提供者はBusiness Insiderに語った。
もし、ドライバーが偽の荷物をアマゾンの配送センターに戻さなければ、ドライバーには盗みの疑いがかけられる。
｢これは、いわば罠。ドライバーの正直さをチェックすることが目的｣とアマゾンの元ロジスティクス・マネージャーはBusiness Insiderに語った。

（Business Insider Japan記事より引用）

◆キタきつねの所感

日本では（まだ）起きないケースかも知れません。米国では配送中に配達員が荷物を盗んでしまうような事件が頻発している、そんな風に考えるとこの記事の重みが出てくる気がします。配達員が偽荷物を配送した際に貼られたパッケージラベルがエラーだった場合、上長に報告するか、配送センターに戻す事になっているようですが、これを偽荷物のラベルがエラーだった事から、荷物が行方不明な（管理されてない）荷物だから盗んでしまおうと考えてしまう・・・そんな盗みを働いている、あるいは盗みを将来的に働く可能性がある配達員を捕まえる事を主眼とした施策のようです。

そんな必要が？とも思えるのですが、WallMartなどでは以前から倉庫においてあるはずの商品在庫が日本以上の比率で行方不明になっている（内部不正）とも聞きますし、海外移民の方なども多い米国や欧米諸国では郵送物の事故というのも高いと聞きますので、こうした事をAmazonが考える事は一定の背景事情があるのだと思います。

それ以外に考えられるのは・・・この記事も影響しているのではないでしょうか？電子鍵を貰って車（コネ区テッドカー）のトランクに配達するサービスを考えた際に、

japan.cnet.com

極論を言えば、トランクに爆発物を仕掛けてしまう事もできる訳ですし、あるいは車自体を盗もうとする人もいるのかも知れません。こうした新しいサービスが成立するためには、車（コネクテッドカー）の普及と共に、安心して車の鍵を配送業者（Amazon等）に預けられる環境が出来ている事が重要だと思います。

そうした意味では、配達員（人）の安全性というのもサービスの売りになっていく時代なのかも知れません。

更新履歴

• 2018年9月30日PM（予約投稿）

簡単なIDであるのはリスクになりつつある

Facebookの記事を調べようかな・・と思い、小さな記事の方に目が留まりました。

www.kahoku.co.jp

　同課によると、容疑者は他にも約１８０人のアカウントで約１８００回の不正アクセスを繰り返した。容疑者が入手したメールは約８０００件に上り、個人情報も含まれていたが、悪用された形跡はないという。
　容疑者は学生や職員に発行される初期設定のＩＤとパスワードの規則性に基づき、他人のアカウントを入手したとみられる。「学生気分を味わいたかった」と供述しているという。

（河北新報）

 

■公式発表

　外部からの情報システムへの不正アクセス事件について

◆キタきつねの所感

自分が学生だった頃は・・・こうした甘いIDとパスワード管理というのは、その辺の教育機関にゴロゴロしてた気がしますが、少なくても東北学院大学のID付与に関しては、私の学生だった頃と似た様な管理だったようです。

例えば東北学院大学の職員の方のIDは、『お名前』から推測が出来そうです。

例えば鈴木一郎さんであれば、『I-SUZUKI@mail.tohoku-gakuin.ac.jp』か『ISUZUKI@mail.tohoku-gakuin.ac.jp』。という感じ。あるいは『ISUZU@mail.tohoku-gakuin.ac.jp』といった短縮形も検索でひっかかりましたので、ご自分でIDを決められるルールですが、お名前が分かるものがIDとして選定されていると思われるので、設定申請のガイドライン例示がそうなっているのかも知れません。

一方で学生・・・こちらの方は、推定になりますが、かなり分かりやすい気がします。頭に学部の識別記号があり、その後ろは、、、恐らく学生番号ではないでしょうか。研究レポートなどがGoogle検索でひっかかりましたが、

このID付与のルーリングは・・・数字入れればそれなりに当たってしまう（数字自体にも入学年度を表す数字が入っている気がしますが）ものだと思います。

恐らく初期パスワード・・簡単なものであったのではないでしょうか？よくありがちな初期IDと初期パスワードの組み合わせであるのが、

• ID=Admin　PASS=Admin

というものですが、これがあまり考えない教育機関であれば、

• ID=学籍番号（A123456）　PASS=学籍番号（A123456）

などという設定になっている事も珍しくないかも知れません。（私が学生の頃は・・・このパターンでした）情報リテラシー教育の一環であると考える事もあるかと思いますので、こうしたIDとパスの配布が必ずしも間違っているとは思いませんが、前提として、『短期間しか有効でない初期パスワード』であるべきではないでしょうか。例えばパスワード有効期間を短期間に限定し、初期パスワードは最初のログインの際に強制的に変更させる・・・そんなに難しいシステム設定ではないはずです。

今回の犯人が、ログインしている期間は、河北新報の記事によると

逮捕容疑は３月７日～７月１日ごろ、同大の専用ウェブシステムに学生や教職員計１０人のアカウントで不正にアクセス・・・

とあるので、新入生の初期パスワードがそのまま使われていた、あるいは脆弱な初期パスワード（共通パスワード含む）がそのまま変更されずに残っていた・・そんなオチでないかなと推測します。

今回の事件では、不正アクセスにより盗聴された個人情報を含むメール情報は外部に漏洩しなかったようですが、少数ではありますが職員情報まで漏洩してしまっている事を考えると、ID付与の仕組みであったりを再考するのも必要かも知れません。

しかし、既に付与してしまったIDを急に変えるのは難しいかも知れません。抜本的には本人以外の不正アクセスを許してしまっている部分が問題だと思いますので、、、ICカードの学生証を使っているならば、カードを使った2要素認証なども一考ですし、スマホを使ったワンタイムパスワード（OTP）や生体認証などの追加認証を、学外からのアクセスに対して要求する、こうした手法も良いのではないでしょうか？

教育機関ではありませんが、（不正アクセスに教育機関以上に悩まされている）ヤフーが生体認証の標準的規格、FIDOを近日中に導入するニュースが出ていました。今回の不正アクセスはパスワードリスト攻撃ではありませんでしたが、根底部分は同じ脆弱性なのだと思います。

about.yahoo.co.jp

更新履歴

• 2018年9月30日PM（予約投稿）

Apache Struts2は狙われている

GMO-PGやぴや等、大きな事件となったのは去年の3月ですが、Apache Struts2 は狙われている。そうした前提で使用を考える方が良いのかも知れません。

www.security-next.com

「Apache Struts 2」に深刻な脆弱性「CVE-2018-11776」が見つかった問題で、ロシアを発信元とした探索行為が確認された。攻撃グループ「BOLIC14」が攻撃ツールの開発や探索行為に関わっているとの指摘が出ている。

ロシアの特定IPアドレスを発信元とし、脆弱性が解消されていないシステムを探索する活動が検知されたもの。攻撃グループは、地下フォーラムで脆弱なアプリケーションを3万4000件以上把握しているなどと主張していた。

攻撃対象としては、米国、イギリス、日本、韓国、インド、ブラジル、アイルランド、ドイツ、オーストラリア、スペインなど、13カ国が上がっていたという。

（Security Next記事より引用）

◆キタきつねの所感

一度導入したプラットフォームはなかなか移行できない。そんなビジネス側の都合すら攻撃する側は利用しているとも言える程に、Strutsは狙われている感があります。逆に言えばそれほど多くのサイトが使う程に優れたプラットフォームであるとも言えるのですが、フリーのフレームワークで全世界で幅広く使われているものは、ここ数年脆弱性が狙われ続けているのは間違いありません。

Apache Struts1ですら未だに日本企業は使っている訳ですが、今回の記事の元となる、IPAの脆弱性発表でも、

www.ipa.go.jp

影響を受けるバージョン

• Apache Struts 2.3 から 2.3.34
• Apache Struts 2.5 から 2.5.16

Apache Software Foundation によると、サポートされていない Struts のバージョンも影響を受ける可能性があるとのことです。

なお、「Apache Struts 1」は既に2013年4月5日を以ってサポートが終了しています。
一般的にサポートが終了した製品は脆弱性が判明した場合でも脆弱性対策の修正対応は実施されず、影響等の情報も公開されません。
サポート終了している「Apache Struts 1」をご利用の場合は利用を停止し、早急に移行をご検討ください。

（IPA発表より引用）

その使用についての危険性を警告しています。

記事を受けてGoogle検索（ファイルタイプ）で改めてみてみたのですが、Struts2に関してはGoogleで全てが引っかかる訳ではないのですが、日本語サイトはかなり減っています。ではありますが・・・Struts1を使っていると思わしきサイトは、まだ結構あります。

具体的な方法はかけませんが、特徴的な拡張子が使われますので、公開情報（Google）だけで私でも簡単に、つまりハッカーも簡単に、脆弱性を使えそうなサイトを調べる事ができます。

ハッカーは、こうしたサイトを平時でも調べてリスト化しており、大きな脆弱性が出て、攻撃ツール（Exploit）が（主にダークウェブや海外サイトで）出て、すぐに攻撃してくる傾向があります。特にここ数年、Struts2は大きな脆弱性が公表され続けており、他のフレームワークに比べて潜在的な脆弱性を多く抱えている（出きってない）と言う方も多いので、他のフレームワークへの乗り換え、あるいは使用に関しても、開発元のパッチ情報（英語）をウォッチする事が望ましいといえます。

JPCERTやIPAの発表を待つとどうしても時差が出る場合があります。特に昨年3月のGMO-PGの事件の際は、日本での（翻訳時差などを含めた）脆弱性情報にすぐに気づいたとしても、間に合わなかったと報告されています。

余談にはなりますが、今年の事故対応アワードはぴあが受賞したようですが、時系列から考えるとその対応は表彰される程に良かったとは思いません。（先に事故情報を公開したGMO-PGの方がはるかに迅速に対応している印象です）

情報セキュリティ事故対応アワード―受賞企業に聞く、事故対応の実際―｜2018-08-22｜ITセミナー・製品情報

IPAの脆弱性情報は、下の方にリンク先をつけており、Apacheの脆弱性公開されているサイト（英語）も載っています。ここを見る、あるいはここをウォッチしていて迅速に情報を展開くれる日本語サービスを受ける事が、Apache利用では有効だと思います。

とは言え・・・凄く探しずらいです。Struts2はこんな感じで脆弱性情報がS１からリスト化されています。

今回発表があった脆弱性は、このリストの一番下にあります。ソート順を逆にしてくれれば良いのですが・・

更に英語で情報が掲載されているので、英語に抵抗感がある方には少しとっつきずらいかも知れません。しかし、Struts2を使う＝無料フレームワークを使う、ためには必要な作業であると私は思います。

講演でこの事を調べた事もあるのですが・・・私の助言としては、全ての技術担当の方がここを見るのではなく、例えば、普通の社員の方に、

• 『S2-057』より新しい情報が掲載されてないか見る

　　　＞見つけたら報告

• 新しい情報が出ていた場合に、以下の部分が『Critical』になっているかを見る　

　　　＞見つけたら即時報告

このオペレーションをお願いできれば、かなり楽に情報収集ができるかと思います。

本筋としては、Struts程に脆弱性が出ないフレームワーク（有償かも知れません）に移行していくのが良いかも知れませんが、急には難しい場合で、自社でStruts脆弱対応を考える際は、JPCERTのメーリングリストに登録する事に加えて、上記の運用（あるいは同等なサービスを提供してくれる日本語脆弱性サービスと契約する）が良いかと思います。

JPCERT コーディネーションセンター メーリングリスト

更新履歴

• 2018年9月29日PM（予約投稿）