【転載】パッチマネジメント とは？方法や必要性、注意点について徹底解説

パッチマネジメント とは？方法や必要性、注意点について徹底解説:

IT企業に限らず、ビジネスでは多くのコンピュータが使われています。そのコンピュータの管理にかかせないのが「セキュリティパッチの更新」です。

セキュリティパッチとはコンピュータに存在する脆弱性を解消するプログラムのことです。マルウェアの感染やセキュリティホールを悪用したサイバー攻撃を防ぐためには、適切なセキュリティパッチの適用が欠かせません。

今回はセキュリティパッチの更新を管理する「パッチマネジメント」について紹介します。

この記事の目次 

• 1 パッチマネジメントとは
• 2 パッチマネジメントの方法
• 3 パッチマネジメントの必要性
• 4 パッチマネジメントの注意点
• 5 まとめ

パッチマネジメントとは

パッチマネジメントとは、システムを構成しているコンピュータを管理して、脆弱性が発見されたときに適切にセキュリティパッチを適用させるための管理活動のことです。

セキュリティパッチはコンピュータに見つかった脆弱性を解消するために使用するプログラムです。ソフトウェアの中には、新しいセキュリティパッチが公開されたとき、ソフトウェアアップデート機能により自動的に更新するものもありますが、一部のコンピュータには、手動によるセキュリティパッチの適用が必要なものもあります。

しかしパッチマネジメントの導入により、セキュリティパッチの適用を効率的に漏れなく実施できます。それにより、コンピュータの脆弱性を確実に解決し、不正アクセスやマルウェアの感染のリスクを低減させられるのです。

セキュリティパッチとは？現状の確認と適用方法について徹底解説

2018.4.21

セキュリティパッチとは、公開されたソフトウェアで発見された問題点や脆弱性に対し、これらの不具合を解決するためのプログラムのことです。 WindowsなどのOSをはじめとした、お使いのソフトウェアおいて、このセキュリティパッチを更新し

パッチマネジメントの方法

パッチマネジメントは具体的には以下の3つの流れで進めます。

検知

脆弱性情報を公開しているWebサイトから、自社のシステムに関係のありそうな脆弱性情報を集めます。脆弱性情報の情報源には、具体的には以下のようなものがあげられます。

業界団体	IPA（情報処理推進機構） JPCERT/CC JVN iPedia NVD
有識者（専門家）	Twitter Facebook ブログ その他SNS
ベンダ（製品メーカー）	各ベンダのWebサイト 情報配信サービス プレスリリース メールマガジン

情報源としては上記3つがあげられますが、これらの情報を取りまとめているニュースサイトもあります。これらの情報を全て追いかけるのは手間がかかるので、自社で使っているソフトウェアや製品に関連する情報だけでも効率良く収集するように工夫しましょう。

判断

自社に関係のある脆弱性が判明したら、そのリスクの大きさと攻撃を受ける可能性を判断して、対策の緊急度と必要性を決定します。

脆弱性の緊急性の判断には「CVSS」を基準に考えるのが一般的です。

CVSS（Common Vulnerability Scoring System)とは

共通脆弱性評価システムと呼ばれ、下記3つの基準で脆弱性を評価する仕組みのことです。

• 基本評価基準（Base Metrics）
• 現状評価基準（Temporal Metrics）
• 環境評価基準（Environmental Metrics）

システムの種類や開発者、評価者などの違いに影響を受けないような、共通の尺度で深刻度を表す指標です。

自社においても脆弱性の深刻度を決定する基準として、CVSSのような指標を使い、あらかじめレベルごとの対応方針を決めておけば、迅速な対応が可能です。

対応

対策方法と対策時期を決めて、脆弱性を悪用したサイバー攻撃が発生する前に、脆弱性のリスクをできるだけ小さくします。しかし複数のシステムが混在している環境の場合、適切に対応されているのか把握しきれないことがあります。

そうならないためにも、複数のシステムを構築する際に、できるだけ共通の基盤を持つサービスを利用することがおすすめです。クラウドサービスの中には、パッチマネジメントの一連の手順を総合的に管理できるものも登場しています。

パッチマネジメントの必要性

包括的なパッチマネジメントを実施する必要性として、以下の2点があげられます。

脆弱性を悪用した攻撃を防ぐ

適切なパッチマネジメントにより、OSやアプリケーションソフトウェアにセキュリティパッチを適用することで、脆弱性を悪用した攻撃を防げます。

コンプライアンスを確保する

セキュリティパッチを適用しないと、コンピュータがマルウェアの感染するリスクが高まります。さらにマルウェアに感染したコンピュータから機密情報や個人情報が流出することで、社会的信用を失いことにもなりかねません。

パッチマネジメントを含めた情報セキュリティ対策は、コンプライアンスを確保する活動とも言えます。自社内のシステムの危険箇所を特定して、不正アクセスや改ざん、マルウェアの侵入を未然に防ぐことで、顧客情報や機密情報を守りことができます。パッチマネジメントは、情報保護ポリシーの実践や法令順守の活動の一環と言えるでしょう。

パッチマネジメントの注意点

パッチマネジメントの必要性はご理解いただけたかと思いますが、実際にはセキュリティパッチの適用が難しいケースもあります。特に以下のような場合は注意が必要です。

システムが多い場合注意

業務で使用しているシステムの数が多い場合、それら全てに対して適切にパッチマネジメントを行うことは困難でしょう。そもそも大規模なシステムの場合、システムで動作しているコンピュータの数ですら、把握できていないこともしばしばあります。また複数の種類の異なるコンピュータが混在している場合は、適用させるセキュリティパッチも異なるため、パッチマネジメントを効率的に行うことが難しくなります。

レガシーシステムに注意

古いソフトウェアで動作しているレガシーなシステムにも注意が必要です。レガシーシステムでは、アップデートのサポートの期限切れや、アップデートできない可能性があります。レガシーシステムといえ、現役で使われていることもあり、簡単には新しいシステムに代替できないこともあります。

パッチテストが必要

最新のセキュリティパッチでも、実際に適用させる前には十分なパッチテストが必要です。しかしそのパッチテストを実施するコンピュータの選定や、業務に影響が発生しないようにテストの時間帯などの調整も必要です。

組み込みシステムに注意

機能が限定された組み込みシステムは、全体を動作させているシステムの一部として動作していることがあります。そのような組み込みシステムは365日24時間動作させていることもあり、停止させてセキュリティパッチを適用させることが困難です。またそのような長期間動作している組み込みシステムは、古いOSが搭載されている可能性もあります。

未知の脆弱性に注意

セキュリティパッチは既知の脆弱性を解消するプログラムです。そのため未知の脆弱性を解決することはできません。未知の脆弱性が知れ渡り、その脆弱性に対するセキュリティパッチが完成するまでには時間がかかります。

まとめ

脆弱性対策にかかせないセキュリティパッチの適用を効率的に実施する、パッチマネジメントについて紹介してきました。

企業内で稼働しているコンピュータの数が多くなってくると、それらを効率的に管理するにも工夫が必要です。パッチマネジメントのために高いコストを投資して、包括的に管理できるシステムを構築できれば理想的ですが、そうは言っても予算をかけられない企業もあるでしょう。

そのような状況でも、自社にとって重要な情報やデータを把握し、システムのクリティカルな箇所から段階的にでもパッチマネジメントを進めていくことがおすすめです。ベンダが提供しているツールなどを有効に活用して、賢くパッチマネジメントを導入しましょう。

「EXILE TRIBE」の公式通販サイトでクレカ情報流出～想定損害賠償額は11億円程度か～

「EXILE TRIBE」の公式通販サイトでクレカ情報流出 - 一部不正利用も

「EXILE」や「三代目J SOUL BROTHERS」など、LDH JAPANに所属するアーティストのグッズを扱う公式オンライン通信販売サイト「EXILE TRIBE STATION ONLINE SHOP」が不正アクセスを受けたことがわかった。

同サイトを運営するLDH JAPANによると不正アクセスにより、8月18日から10月15日までの約2カ月間、決済処理を行うプログラムが改ざんされたほか、個人情報を含むサーバに対してもアクセスを受けた形跡が見つかったもの。

同サイトではクレジットカード情報を保持していないが、期間中にクレジットカード情報を新規に登録したり、変更を行った場合、第三者に情報を窃取されたおそれがある。

4万4663人分のクレジットカード情報が外部に流出した可能性があり、名義や番号、有効期限、セキュリティコードが含まれる。さらに11月27日の時点で、このうち少なくとも209人分のクレジットカード情報が不正に利用をされた可能性があるとの報告をクレジットカード会社より受けたという。

またログファイルの調査により、クレジットカード情報以外の個人情報が格納されたサーバについても不正アクセスを受けていたことが判明した。流出件数などは特定できなかったとしている。

報告書バックアップ

【転載】脆弱性探しはハッカーが頼り バグ報奨金制度、新型コロナ対応が普及後押し～日本企業ではトヨタ自動車、任天堂などが活用～

脆弱性探しはハッカーが頼り　バグ報奨金制度、新型コロナ対応が普及後押し (1/2) - ITmedia NEWS:

 　自社のソフトウェアやシステムの脆弱性を発見する手段として、社外の善玉ハッカーに頼ろうとする企業が増えている。脆弱性を見つけて報告してくれた研究者などに賞金を贈呈する「バグバウンティープログラム」の制度を導入する企業が相次ぎ、Googleなど早くからこうした制度を活用していた企業は賞金額の引き上げに動く。背景には新型コロナウイルス感染拡大の影響もあるようだ。

　各国の企業と組んでこうした制度を支援してきたHackerOneがこのほどまとめた統計によると、2020年4月までの1年間でバグバウンティープログラムを通じて発見された脆弱性は20万件を超え、ハッカーに支払われた賞金の総額は、上位10種類の脆弱性の合計で2350万ドル（約24億円）に上った。

HackerOne

　脆弱性の種類別に見ると、支払われた賞金の総額が最も多かったのは、前年に続いてクロスサイトスクリプティング（XSS）の脆弱性だった。

　XSSはWebアプリケーションを脅かす脆弱性で、悪用されればユーザーのアカウントを制御され、パスワードや銀行口座番号、クレジットカード番号などの情報が盗まれることもある。この脆弱性に対して支払われた賞金の総額は420万ドルと、前年比で26％増えた。

　深刻度で分類すると、XSSは一般的に、高～中程度に分類される脆弱性。1件当たりの賞金は平均で501ドルと、最高レベルの脆弱性の3650ドルに比べてかなり安い。「つまり組織は、このよくありがちな、痛みを伴うバグを安上がりに緩和できている」（HackerOne）

　こうした脆弱性の発見を外部のハッカーに頼るやり方が改めて注目されるようになったのは、新型コロナウイルスの影響でデジタルトランスフォーメーションが加速したことも一因だとHackerOneは解説する。

　「自分たちのリソースを補うための手早くコスト効率が高い解決策として、ハッカーの力を借りるセキュリティ対策への関心が高まり、予算が縮小する中で結果に対して対価を支払うアプローチが正当化しやすくなった」

　新型コロナウイルスの影響は、バグバウンティー制度に詳しい別の専門家も指摘している。

　2012年からこうした制度を推進してきたBugcrowd創業者のケイシー・エリス氏は、threatpostのインタビューの中で、 「外の世界のセキュリティ専門家の助けを借りることに対して、企業の抵抗感が少なくなった」と語る。

threatpost

　同氏によると、新型コロナ対策としてテレワークを余儀なくされたことで、組織内に物理的に存在していない人物に協力してもらうやり方が、企業にとって受け入れやすくなった。外出や通勤時間が減って自由に使える時間が増えた若者などが、賞金稼ぎに時間をかける傾向も見られるという。

　Zoomのようなデジタルプラットフォームに対してはセキュリティ強化圧力が強まり　相次ぐ問題が発覚したZoomは、4月にバウンティープログラムの強化を発表した。中国ByteDance傘下のTikTokは米政府との対立が深まる中で、10月にHackerOneと組んでバウンティープログラムを立ち上げた。

　ただし制度を導入しても利用してもらえなければ意味はない。脆弱性情報を闇サイトで売った方が稼げるのであれば、そちらに流れるハッカーもいるかもしれない。そこで早くからバウンティープログラムを導入しているGoogleなどは、インセンティブを高める狙いで賞金の額をどんどん引き上げている。Facebookは常連ハッカーをランク付けして貢献度に応じてボーナスを上乗せする制度「Hacker Plus」を導入した。

　消極的だったAppleも、2019年からバウンティープログラムを拡充してiOSやmacOSの脆弱性にも賞金を支払うようになり、賞金の金額も増額した。今年10月には、研究者グループが3カ月で55件の脆弱性を発見し、総額28万8500ドルの賞金を獲得したと発表して話題になった。

　ハッカーの力を借りているのはIT企業だけにとどまらない。トヨタ自動車は今年3月、中国Tencent Keen Security Labの報告を受けてレクサス車の脆弱性を修正したと発表した。HackerOneのプラットフォームを利用している顧客は米国防総省やStarbucks、任天堂、Uberなど多岐にわたる。

　HackerOneのレポートによると、バグバウンティープログラムを通じてハッカーが受け取った賞金は世界全体で前年より87％増えた。特にアジア太平洋地域は前年比で131％の大幅増だった。Tencentなどの中国勢は、GoogleやAppleといった大手の製品の脆弱性を次々に発見している常連で、この世界での存在感を増している。

■■■■HackerOneのレポート（機械翻訳）■■■■

HackerOne のレポートでは、クロスサイト・スクリプティング、不適切なアクセス制御、情報開示など、最も一般的で影響力のある脆弱性のトップ・リストが明らかになっています。

不確実性の高い時代にあって、セキュリティはこれまで以上に緊急の優先事項となっています。組織はこれまで以上にテクノロジーへの依存度を高めており、テクノロジーに依存している人は誰でもデータ漏洩ですべてを失う可能性があります。しかし、最近の脆弱性の中には、攻撃者のように考えることができる友好的なハッカーによって発見、発見、報告されたという共通点があります。

"今年は、世界中の企業が製品やサービスのデジタル化を余儀なくされました」とHackerOneの製品管理担当シニアディレクターであるMiju Han氏は述べています。"企業は新たな収益源を求めて、ライフスタイルが劇的に変化した顧客のためにデジタル製品を開発しました。何千万人もの労働者が、準備ができているかどうかに関わらず、リモートワークを始めました。このようなデジタルトランスフォーメーションの加速化に伴い、CISO は既存システムのセキュリティを確保しつつ、新たなニーズに迅速に対応しなければなりませんでした。このような障害に直面したセキュリティリーダーは、自社のリソースを増強し、厳しい予算の下でより正当化できる成果報酬型のアプローチを提供するために、軽快で拡張性があり、コスト効率の高いソリューションとして、ハッカーを活用したセキュリティを新たに評価するようになりました。

HackerOneは、業界で最も信頼性の高い脆弱性のデータベースを維持しています。ハッカーが発見した有効な脆弱性は20万件を超え、HackerOneはこのデータを調査して、最も影響力があり、報酬が得られる脆弱性のトップ10のタイプから洞察を導き出しました。

HackerOneが発表した2020年の最も影響力があり、報われる脆弱性の種類トップ10は、降順に以下の通りです。

1. Cross-site Scripting (XSS)

2. Improper Access Control 

3. Information Disclosure

4. Server-Side Request Forgery (SSRF)

5. Insecure Direct Object Reference (IDOR)

6. Privilege Escalation

7. SQL Injection

8. Improper Authentication 

9. Code Injection

10. Cross-Site Request Forgery (CSRF)

2019年の脆弱性トップ10と比較して今年のトップ10を詳しく見てみると、主な調査結果は以下の通りです。

クロスサイトスクリプティングの脆弱性は、XSS攻撃を悪用した攻撃者がユーザーのアカウントを制御し、パスワード、銀行口座番号、クレジットカード情報、個人を特定できる情報（PII）、社会保障番号などの個人情報を盗み出す可能性があるため、ウェブアプリケーションに対する大きな脅威であり続けています。2年連続で最も表彰された脆弱性であるXSSの脆弱性は、組織の懸賞金総額が420万米ドルに達し、前年比26%増となっています。これらのバグは報告されたすべての脆弱性の18%を占めていますが、平均的な懸賞金はわずか501米ドルです。 重要な脆弱性に対する平均懸賞金が3650米ドルであることから、組織はこの一般的で痛みを伴う可能性のあるバグを安価に緩和していることになります。

不適切なアクセス制御（2019年の9位から上昇）と情報開示（依然として3位をキープ）は依然として一般的です。Improper Access Controlの受賞は前年比134%増の400万ドル強でした。情報開示は前年比63%増と、それに遠く及ばなかった。アクセス制御の設計決定は、技術ではなく人間が行わなければならず、エラーの可能性が高く、どちらのエラーも自動化されたツールを使って検出することはほぼ不可能です。

ファイアウォールの背後にある内部システムを狙って悪用される可能性があるSSRFの脆弱性は、クラウド移行のリスクを示しています。以前は、SSRFのバグはかなり良性で、内部ネットワークのスキャンや、時には内部の管理パネルへのアクセスを許可するだけだったため、7位の座を守っていました。しかし、デジタルトランスフォーメーションが急速に進むこの時代では、クラウドアーキテクチャと保護されていないメタデータエンドポイントの出現により、これらの脆弱性はますます重要になってきています。

SQLインジェクションは前年比で減少しています。OWASP などによって、ウェブアプリケーションのセキュリティに対する最悪の脅威の一つと考えられていますが、SQL インジェクション攻撃の規模は、ビジネス情報、知的財産、重要な顧客データを含む機密データが、これらの攻撃の影響を受けやすいデータベースサーバに保存されているため、壊滅的なものになる可能性があります。過去数年の間、SQLインジェクションは最も一般的な脆弱性の種類の1つでした。しかし、当社のデータによると、2019年の第5位から2020年には第7位まで、前年比で低下しています。セキュリティを左遷することで、組織はハッカーなどを活用して攻撃面を積極的に監視し、バグがコードに侵入しないようにしています。

"最も一般的な脆弱性の種類を見つけることは、安価である "とハン氏は続けた。"賞金を獲得した脆弱性の上位10種類のうち、平均賞金額が10%以上上昇したのは、不適切なアクセス制御、サーバー側リクエストフォージェリ（SSRF）、情報開示のみでした。その他は平均値が低下するか、ほぼ横ばいでした。目標が変化し、攻撃対象が拡大するにつれて、高価で煩雑になる従来のセキュリティツールや手法とは異なり、ハッカーを活用したセキュリティは、時間が経つにつれて、実際にはより費用対効果が高くなります。ハッカーがいれば、悪質な行為者が最も一般的なバグを悪用することを防ぐためのコストが低くなってきています。"

HackerOne Top 10 Most Impactful and Rewarded Vulnerability Types - 2020 Editionの詳細については、https://www.hackerone.com/top-10-vulnerabilities をご覧ください。

Fire Eye のレッドチームツールが盗まれた・・・/ Unauthorized Access of FireEye Red Team Tools（転載）

Fire Eye のレッドチームツールが盗まれた・・・:

Fire Eyeのレッドチームツールが盗まれたとFire Eyeのブログで書いていますね。。。

● Fire Eye Blog - Threat Research

・2020.12.08 Unauthorized Access of FireEye Red Team Tools

簡単にまとめてみると・・・

---

• FBI、マイクロソフト等主要なパートナーと協力して、調査を行っている。
• 国家が資金提供した高度に洗練された攻撃者によるものである。
• 攻撃は斬新な技術が利用されている。
• 攻撃者は、当社が顧客のセキュリティテストに使用している特定のレッドチームの評価ツールを標的にしてアクセスしたことがわかった。
• これらのツールは、多くのサイバー脅威行為者の行動を模倣している。
• これらのツールには、ゼロデイ エクスプロイトが含まれていない。
• コミュニティを保護するという当社の目標に沿って、盗まれた ツールの使用を検出するための方法や手段を積極的に公開している。
• 攻撃者が盗んだツールを利用するつもりなのか、それとも公開するつもりなのかはわからない。
• Fire Eyeは、これらのツールが盗まれた場合の潜在的な影響を最小限に抑えるために、顧客やコミュニティ全体が使用できる300以上の対策を開発してきた。
• これまでのところ、攻撃者が盗んだツールを使用したという証拠はない。
• Fire Eyeは、セキュリティ・コミュニティの他の人々と同様に、盗んだツールを利用した活動がないかどうかを監視していく。
• 盗まれたツールの使用を検出したり、ブロックしたりできる対策を用意している。具体的には、
  
  • 当社のセキュリティ製品に対策を施している。
  • セキュリティ・コミュニティがセキュリティ・ツールを更新できるように、これらの対策を共有している。
  • 対策は、ブログ記事「Unauthorized Access of FireEye Red Team Tools 」で公開している。
  • レッドチームツールの追加的な緩和策については、今後も、公開されたものと直接セキュリティパートナーとの間で共有し、改善していく。
• 攻撃者は国家レベルでのサイバースパイ活動の一環として、主に特定の政府機関の顧客に関連する情報を求めていた。
• 攻撃者はFire Eyeの内部システムの一部にアクセスすることができたが、攻撃者がFire Eyeのインシデント対応やコンサルティング業務から得た顧客情報を保存している主要システムや、ダイナミック脅威インテリジェンスシステムで製品が収集したメタデータからデータを持ち出したという証拠はない。
• 顧客情報が持ち出されたことが判明した場合は、直接顧客に連絡する。

---

サイバーセキュリティの領域は、人々の生命、財産にも繋がっている問題ですので、ライバルと切磋琢磨することも重要ですが、全体の危機に際しては協力して対応することが重要ですよね。。。

ー以下ブログ原文ー

Overview

A highly sophisticated state-sponsored adversary stole FireEye Red Team tools. Because we believe that an adversary possesses these tools, and we do not know whether the attacker intends to use the stolen tools themselves or publicly disclose them, FireEye is releasing hundreds of countermeasures with this blog post to enable the broader security community to protect themselves against these tools. We have incorporated the countermeasures in our FireEye products—and shared these countermeasures with partners, government agencies—to significantly limit the ability of the bad actor to exploit the Red Team tools.

You can find a list of the countermeasures on the FireEye GitHub repository found HERE.

Red Team Tools and Techniques

A Red Team is a group of security professionals authorized and organized to mimic a potential adversary’s attack or exploitation capabilities against an enterprise’s security posture. Our Red Team’s objective is to improve enterprise cyber security by demonstrating the impacts of successful attacks and by showing the defenders (i.e., the Blue Team) how to counter them in an operational environment. We have been performing Red Team assessments for customers around the world for over 15 years. In that time, we have built up a set of scripts, tools, scanners, and techniques to help improve our clients’ security postures. Unfortunately, these tools were stolen by a highly sophisticated attacker.

The stolen tools range from simple scripts used for automating reconnaissance to entire frameworks that are similar to publicly available technologies such as CobaltStrike and Metasploit. Many of the Red Team tools have already been released to the community and are already distributed in our open-source virtual machine, CommandoVM.

Some of the tools are publicly available tools modified to evade basic security detection mechanisms. Other tools and frameworks were developed in-house for our Red Team.

No Zero-Day Exploits or Unknown Techniques

The Red Team tools stolen by the attacker did not contain zero-day exploits. The tools apply well-known and documented methods that are used by other red teams around the world. Although we do not believe that this theft will greatly advance the attacker’s overall capabilities, FireEye is doing everything it can to prevent such a scenario. 

It’s important to note that FireEye has not seen these tools disseminated or used by any adversaries, and we will continue to monitor for any such activity along with our security partners.

Detections to Help the Community

To empower the community to detect these tools, we are publishing countermeasures to help organizations identify these tools if they appear in the wild. In response to the theft of our Red Team tools, we have released hundreds of countermeasures for publicly available technologies like OpenIOC, Yara, Snort, and ClamAV.

A list of the countermeasure is available on the FireEye GitHub repository found here. We are releasing detections and will continue to update the public repository with overlapping countermeasures for host, network, and file-based indicators as we develop new or refine existing detections. In addition, we are publishing a list of CVEs that need to be addressed to limit the effectiveness of the Red Team tools on the GitHub page.

FireEye Products Protect Customers Against These Tools

Teams across FireEye have worked to build the countermeasures to protect our customers and the broader community. We have incorporated these countermeasures into our products and shared these countermeasures with our partners, including the Department of Homeland Security, who have incorporated the countermeasures into their products to provide broad coverage for the community.

More information on the detection signatures available can be found in the GitHub repository.

【転載】「お金を無限に増やせるバグ」を銀行に報告したホワイトハッカーが自身の受けた仕打ちについて解説

「お金を無限に増やせるバグ」を銀行に報告したホワイトハッカーが自身の受けた仕打ちについて解説 - GIGAZINE:

 「残高をマイナスにしてから帳消しにして無限にお金を増やせる」というバグをJPモルガン・チェース銀行に報告したセキュリティ研究者が報告後に敵対的な仕打ちを受けたとして、「銀行がセキュリティ研究者をどのように扱うのか知っておくべき」と警告を発しています。

DISCLOSURE: Unlimited Chase Ultimate Rewards Points | Chad Scira
https://chadscira.com/post/5fa269d46142ac544e013d6e/DISCLOSURE-Unlimited-Chase-Ultimate-Rewards-Points

JPモルガン・チェース傘下の商業銀行であるJPモルガン・チェース銀行にお金の無限増殖バグを報告したのは、セキュリティ研究者のChad Scira氏。コンピューター上で並行して行われる処理のタイミングの違いによって最終的な結果が変化してしまうという現象が生じる「競合状態」に関するバグがJPモルガン・チェース銀行のシステムに存在していると知ったScira氏は、JPモルガン・チェース銀行の許可を得た上で複数のアカウントを使って不安定なインターネット環境下でポイントの送付を繰り返すという実験を行いました。

この実験の結果、実験に使用したアカウントの間で、「ポイント残高がマイナスになるまで送付できる」という現象が確認されました。その結果、ポイント残高が512万698ポイントのアカウントと、ポイント残高がマイナス500万ポイントの口座を作成することができたとのことです。500万ポイントは現金に還元すると5000ドル(約52万円)ですが、航空券費用として使った場合には7万6810ドル(約800万円)相当とのこと。

JPモルガン・チェース銀行のアカウントには、「アカウント削除時にはポイントを全額消去する」という仕様が存在しました。この仕様について、「マイナスのポイントも全部消去されるのでは？」とにらんだScira氏が実験を行ったところ、予測通りにマイナスのポイントまで全額消去されたことが確認されました。

さらにScira氏は、丸もうけした512万698ポイントを現金に還元するという実験も敢行。512万698ポイントのうちの500万ポイントを現金化したところ、見事5000ドルに還元されたことが確認され、潜在的に「現金の無限増殖が可能」であることが立証されました。

Scira氏が一連の実験を行った2016年当時はJPモルガン・チェース銀行は脆弱性の責任ある開示プログラムを実施していなかったため、Scira氏はJPモルガン・チェース銀行のカスタマーサービスチームの公式Twitterアカウント(@ChaseSupport)に状況を逐一報告しながら実験を進めていました。Scira氏の報告によって一連の問題は修正されたそうですが、報告からおよそ一週間後にScira氏はJPモルガン・チェース銀行から「非常に敵対的なメール」を受け取ったとのこと。

さらに、JPモルガン・チェース銀行はScira氏が同銀行に保有していたプライベートなアカウントを全て削除し、当座預金口座と普通預金口座を全て解約。「あなたのアカウントを削除しました」という手紙を送りつけました。

Scira氏によると、Scira氏だけでなく、Scira氏の家族も口座解約などの仕打ちを受けたとのこと。Scira氏は「銀行が助けてくれる人々にこのような仕打ちをしたがるというのはとても残念です。このような仕打ちを続けるということは自社の評判を傷つけるというだけでなく、バグ報告などを減らすということにつながると気がついてくれることを願っています」とコメントしています。

【転載】「パスワード付き添付ファイル」が無意味どころか社会の害になる理由

「パスワード付き添付ファイル」が無意味どころか社会の害になる理由 | 及川卓也のプロダクト視点 | ダイヤモンド・オンライン:

 日本では広く採用されている「メール添付ファイルのZIP暗号化」はセキュリティ的にはほとんど意味がないことをご存じだろうか。そればかりか「受け手の体験を損ない、社会の効率を下げる行為だ」と指摘するのは、マイクロソフトやグーグルでエンジニアとして活躍し、現在は複数の企業で技術顧問を務める及川卓也氏だ。及川氏が、相手のユーザー体験、社会全体の効率化を考える必要性を説く。

添付ファイルのZIP暗号化だけでは
セキュリティ的には意味がない

　企業にとって、重要なファイルを外部と共有する際に、その内容を第三者の誰かに盗み見られないようにすることは、取引上の機密やコンプライアンスを守るためにも、個人情報保護などの観点からも不可欠です。そのための漏えい防止策のひとつとして、メールで送付したいファイルを「パスワード付きの暗号化ZIPファイル」に加工してから添付して送信するという方法が、日本ではよく採用されています。

　読者の皆さんの所属する組織でも、メールでのファイル送信時にそうしたルールが設けられているかもしれません。また自身の職場でルール化されていなくとも、相手方から暗号化ZIPファイルが送られてきた経験は、どなたにもあるのではないでしょうか。しかし、その暗号化ZIPファイルのセキュリティは、ほとんどのケースで守られているとは言いがたいのです。なぜなら多くの場合、その添付ファイルを送信したメールと同じ経路、つまりメールでZIPファイルのパスワードが送られているからです。

　この方式はセキュリティに明るい人たちの間で、皮肉を込めて「PPAP」と呼ばれています。日本情報経済社会推進協会（JIPDEC）の大泰司章氏が名付け親で、「Password（パスワード）付きZIP暗号化ファイルを送ります」「Passwordを送ります」「Aん号化（暗号化）」「Protocol（プロトコル）」を略したものです。

　なぜPPAP方式ではセキュリティが保持されないのか、もう少し詳しく見てみましょう。ファイルをZIP暗号化する目的は大きく2通りあります。1つは“Man in the Middle”、すなわち送信者と受信者との間で悪意を持った第三者がデータを盗む、中間者攻撃を防ぐこと。添付ファイルが送信経路のどこかで不正に取得されたとしても、パスワードでファイルを暗号化することで、中身を確認できなくするという考え方です。

　もう1つは、送信者が送り先を間違えた場合。パスワードを暗号化ファイルと別々に送信するので、両方の送り先が違ってさえいれば、つまり2度送り先を間違えなければ、誤送信された第三者がファイルの中身を見ることはできません。

　PPAP方式では、この両方のパターンでセキュリティ保護の効果はありません。悪意の第三者がファイルが添付されたメールを盗み見ることができた場合、パスワードが書かれたメールも見ることができるはずです。こうしたケースでは、メールアカウントとそのパスワード自体が既に不正に取得されていることも多く、暗号化ファイルのパスワードは電話やチャットツールなど別の経路を使って伝えない限り、意味はありません。

　また2つ目のパターンについては、パスワードを手動で、正しい宛先に送っていれば、確かに情報漏えいの危険性は下がります。しかし実際のところ、かなり多くの企業が添付ファイルのZIP暗号化とパスワードの発行・送信を自動化するシステムを取り入れています。これは送り手側の手間を楽にするためですが、このシステムを使っている限り、添付ファイルを送った先のアドレスが間違っていても、必ず同じアドレスへパスワードを送ってしまうことになります。これでは、もとの「ファイルの内容を漏えいさせない」という目的は決して果たすことができません。

PPAP方式の暗号強度は低く
むしろセキュリティ的には悪影響

　そもそも、一般的に使われているパスワード付きZIPファイルの暗号強度は、それほど強くありません。現在普及しているパソコンのCPU、GPUの性能でも、パスワードの総当たり攻撃をかければ、英大文字・小文字と数字を組み合わせた8桁のパスワードが半日程度で解析できてしまうようなものなのです。

　しかも、せっかくメールサーバー側で添付ファイルのウイルス検知が行えるシステムが導入されていたり、マルウェアフィルターが設置されていたりしても、添付ファイルにパスワードがかかっていると、これらをすり抜けてメールが届いてしまうため、逆効果になることさえあります。

　普段からPPAP方式でファイルのやり取りをしている組織の場合、標的型攻撃にも弱くなります。標的型攻撃とは、機密情報を盗み取ることなどを目的に、特定の組織・個人を狙うもの。業務に関係のあるメールを装ってウイルスが含まれる暗号型ZIPファイルが攻撃者から送られてきても、常にPPAP方式でファイルのやり取りをしていれば、受け取る側は疑問を持たずに開いてしまうことでしょう。

　ちなみに海外では、機密性の高いファイルのやり取りにPPAP方式は基本的に使われていません。日本の企業とファイルのやり取りをすることになって、暗号化ZIPファイルを受け取ったり、PPAP方式での送信を指定されたりした相手側は、戸惑うケースがほとんどです。

　この何の意味もないPPAP方式に代えて、外部とのファイルのやり取りを比較的安全に行う方法がないわけではありません。グーグルドライブやマイクロソフトのOneDrive（ワンドライブ）をはじめとする、インターネット上のフォルダー（オンラインストレージ）を利用する方法です。このやり方なら、ファイルやフォルダーにアクセス制限をかけてダウンロードができるユーザーのみに権限を付けることで、安全にファイルのやり取りが可能です。万が一、間違ったユーザーに権限を与えてしまうようなことがあっても、ストレージから速やかにファイルを削除することで被害の広がりを防ぐことができます。

受け手の痛みを考えない一方的な暗号化が
社会全体の効率を下げる

　では、なぜ日本からPPAP方式のファイルのやり取りはなくならないのでしょうか。ひとつは社会にあまりにもこの方法が定着してしまったので、企業が別の方法への切り替えができなくなっている、という理由があります。そしてもうひとつ、最大の理由は「送り手に痛みがないこと」だと私は考えています。

　1998年から使用許諾が開始されたプライバシーマークの取得などで要件を満たすために、多くの企業が添付ファイルのZIP暗号化を採用し、確実にファイルの暗号化が行われるように、パスワードの発行・送信とセットで自動化を進めてきました。その結果、今ではファイルを送信する側は手間をかける必要なく、ZIP暗号化ファイルを送ることができるようになっています。このため、自分たちが面倒に感じたり、困ったりすることがなくなり、ファイルを開封する受信者の手間、相手の体験が悪くなっていると思い至りにくくなっています。

　一方でファイルを受け取る側は、暗号化ZIPファイルが届く度に、別のメールで送信されてくるパスワードを確認してコピー・ペーストして、開封する手間がかかります。私などは研修で20人ほどの受講者から課題の提出を受けることがありますが、おのおののファイルがZIP暗号化されていると20回分、この作業を繰り返すことになります。

　送り主はエンジニアなど技術に詳しい方が多く、PPAP方式の無意味さはよく分かっている方ばかりなのですが、組織でシステムが導入されているなど、仕組み上、この方法でしかファイルを送れないといいます。会社も社員も思考停止してしまっているために、受け手の体験まで考慮されなくなってしまい、結果として社会全体では効率が悪くなっているのです。

マイナンバーにオンライン会議
受け手の体験を無視した強要は他にも

　受け手の体験を考えない仕組みやコミュニケーションの強要は、PPAP以外にも数多くあり、それぞれが社会全体の効率を下げる結果を招いています。例えば、企業が取引先の個人事業主（フリーランス）に求めるマイナンバーの提出方法などもそれに当たります。

　企業は取引先のフリーランスへ支払いを行った場合、税務署に提出する支払調書に相手のマイナンバーの記載が義務付けられています。このため、マイナンバーの提出が企業からフリーランスに依頼されることになるのですが、知人に聞くと「提出方法が各社各様で、委託元によって全く異なる様式で送付が求められるので、とても不便である」とのこと。中にはマイナンバーのコピーを印刷した指定の用紙の指定の場所に、切って貼って郵送するような「工作」をしなければならないケースもあるそうです。

　これが長期契約での業務であればともかく、単発の講演などを依頼されて引き受けたような場合でも、各企業で異なる様式の書類提出を毎度やり取りしなければなりません。このケースでも企業の側はそれほど痛みはなく、「国の決まりだから仕方がない」「業務委託先だから引き受けてくれるだろう」と思考停止して依頼しているに過ぎないのですが、受ける側は手間が大変かかり、痛みを全て引き受ける形になります。

　今後、ITでやり取りが完結するようになればよいのですが、マイナンバーのやり取りも受け手の体験を依頼する側が考慮していないことで、社会全体の効率が悪くなっている例のひとつです。

　私が「受け手の体験を考えない」コミュニケーションとして、PPAP以外に最近気になっているのは、オンライン会議でプレゼンテーションをする際、資料を全画面のスライドショーではなく編集画面のまま画面共有するパターンです。送信者は大きな画面で操作をしているのかもしれませんが、出先などで、小さな画面でミーティングに参加せざるを得ない人はプレゼン資料が小さく見にくくなってしまいます。

　これも正当な理由があればよいのです。プレゼン用途で資料を表示するのではなく、参加者全員で議論をしながら資料を共同で作っていくための話し合いの場としてオンライン会議が実施されているのなら、編集画面で問題ないのです。

　しかし「スライドショー表示のやり方が分からないから」「以前やってみたけれどもうまくできなかったから」というのでは言い訳でしかありません。それなら事前にどうやれば操作できるのかを確認したり、勉強したりすればいいだけの話です。相手のことを考えていない自分だけの理由、送り手側の怠慢で、自分は困っていないかもしれないですが、見ている側はストレスがたまります。

　こうしたケースでも、まずは相手の体験を良くすることを考えるべきです。それは相手の体験を良くすることが、コミュニケーションをスムーズにすることにつながり、最終的には情報を共有する対象者全体の効率化につながるからです。社会全体の効率化を考えれば、自分の都合で作業や不自由を相手に押しつけるのではなく、受け手の体験も含めて考える必要があるのです。

クリップボード履歴機能はWindows10に標準装備されていた！！

先日、新規に購入したPCが到着し、セットアップを進めている。

基本的にデータはクラウドにあるため、アプリケーションを入れるだけで済むのだが、毎回フリーソフトを導入することに違和感を感じ、Windowsの標準機能でこなすことができないかを考える。

最近のWindowsは意外に進化が目覚ましく、Snipping Toolsとか、Stickey Notesとか、WSLとか、標準機能ながら個人的な要望を十分満たせるモノがそろいつつある。

PC購入前までフリーソフトで頑張っていたのはクリップボードの履歴ツール（所謂キーロガーツール）である。

ダメもとで調べてみると実装されていることを知り、びっくりした。

使い方もいたって簡単で、「Windowsキー」+「v」キーを押すと初期設定画面が出てくるので、「有効化する」ボタンをクリックするだけである。

以降は自動的に（最大25件だっけかな？）保存し、履歴を使いたければ「Windowsキー」+「v」で呼び出すことができる。 

Windows10は意外な便利機能が標準でどんどん増えているので、ちゃんとキャッチアップせねばと思った。