freee、パスワード付き添付ファイルのメール受信を廃止(転載)~ハンコ文化と並ぶ悪しき風習のPPAP根絶へ!~



freee、パスワード付き添付ファイルのメール受信を廃止 - ITmedia NEWS:

  クラウド会計ソフトを提供するfreeeは11月18日、メールに添付されたパスワード付きファイルの受信を12月1日に廃止すると発表した。メールを受信した場合、メールサーバで添付ファイルは自動的に削除される。メール本文は維持したまま受信できるが、ファイルが削除された旨が本文に追記されるという。

 

freeeは「パスワード付きファイルはマルウェア検査を迂回(うかい)してしまうことからセキュリティリスクを増大させる」と指摘。パスワード付きファイルの受信をやめることで、添付ファイルを通じて感染するマルウェア「Emotet」などを防ぎたい考え。

効果が薄いとわかっていてもなかなか仕組みを変えられないのが日本企業の特徴だが、いかにして廃止を実現したのか。

今回、パスワード付きファイルのメール受信廃止を決めたfreeeでは、どのように社内の理解を取り付け、実現させたのか。話を聞くと、以前から行ってきたセキュリティに対する意識の醸成が大きな影響を与えていることがわかった。

 freee CIO(Chief Information Officer:最高情報責任者)の土佐鉄平氏によれば、セキュリティ上の観点から、これまでもfreeeからの送信メールにはなるべくファイルを添付しない方針だったそうだ。

 同社はGoogle Workspace(旧G Suite:Gmailやカレンダー、ドライブ、ドキュメント、スプレッドシートなどのツールを含むクラウド上のワークスペース)を利用しており、従業員にはGoogle ドライブを使ってファイル共有を行うことを推奨。個人情報を含むものなど特に重要な情報は、メールではなくドライブを利用するよう指示してきた。

 ただし、取引先のポリシーによってはドライブへのアクセスが制限されていることもあるため、その場合は別の手段を選択。ほかに選べる手段がなければ、例外的にメールにファイルを添付して送信するという運用だった。

 その一方、これまで外部からのメール受信の際には添付ファイルの受け取りは制限されていなかった。パスワードが後送される、いわゆるPPAP方式のファイル受信も行っていたという。

 ここ数年、不審メールの検知が増えていたfreee。土佐氏は「幸い、実害を受けることは今までなかったが、やはりパスワードで暗号化されてスキャンツールが効かない状態で受信しているケースは結構あった。以前からずっと、これは課題だと認識していた」と語る。

 具体的に、パスワード付きファイルをメールで受け取らないことを検討し始めたのは、米CISAによりEmotetへの注意喚起が出たことがきっかけだった。ウイルス対策ソフトやファイアウォールの設定、電子メールに添付された実行ファイルのブロックなど、これまでも対策を講じるよう推奨されてきた項目に加えて、「ウイルス対策ソフトでスキャンできないタイプのメール添付ファイル(zipファイルなど)のブロック」が対策として推奨されていたからだ。

「公的な機関からの注意喚起という後ろ盾を得て、これを機に廃止を進めてしまおうということになった」(土佐氏)

 土佐氏らはパスワード付きファイルを受信しない設定方法と、受信廃止による影響について調査を進め、11月2週目まで社内で検証を実施。11月18日、取引先への周知のために廃止をアナウンスした。この日はちょうど平井大臣からPPAP廃止の方針が出た翌日で、タイムリーな発表となったが、テストも含めた準備自体は1カ月ほどかけて行ってきたものだった。

「調査により、Google Workspaceを利用する企業ユーザーなら、Gmailの添付ファイルに関するコンプライアンスルールの設定が管理画面から比較的簡単にできることがわかった。暗号化されたファイルをメールから削除することも容易で、かつ送信元による例外処理の設定も可能だとわかったので、原則としてパスワード付きファイルは受信しないルールとし、仕組み上、どうしてもパスワード付きファイルをメールで送らざるを得ない相手については例外処理とすることにした」(土佐氏)

 同社CSIRT(Computer Security Incident Response Team:コンピュータセキュリティ問題への対応チーム)の吉本真一氏は「Gmail以外のメールサービスでも、同様の設定は技術的には対応可能」として、「設定の難易度はサービスによって違いがあると思うが、いずれもさほど難しくないのではないか」と語る。

 freeeでは、取引先やパートナーに、パスワード付きファイルをメールで送らないよう依頼する際、外部にも説明しやすいようにと対外的なアナウンスを実施。社内への告知は外部への公表の前日だったそうだが、大きな反発はなかったという。

「折に触れて、PPAPやパスワード付き添付ファイルの問題点については社内へアピールしていたので、そのこと自体は浸透していたのだと思う。金融機関とのやり取りが多い部署などとは『もし廃止することになったら、結構影響を受けそう』といった対話もしていたが、そこでも大きな反発はなく、せいぜい『大胆なことを考えますね』という感じ。そのため、社内的には“行ける”という感触をつかんでいた」(土佐氏)

 発表後の社外からの反響もおおむね好意的だ。「スタッフからは、ほとんどのところで先方に対応いただけていると聞いている」と土佐氏。「12月1日の廃止に向けて、もっと例外設定の依頼がたくさん来るものと構えていたが、思ったより依頼は来ていない」という。

「セキュリティポリシーの一環として、送信ファイルが自動的にパスワード暗号化されるソリューションが入っている相手なら仕方がないと思っていたが、Google ドライブが使えない相手先からも『別のストレージなら対応できる』と提案をいただくなど、社内外ともに賛同が多い」(土佐氏)

 freee社内のセキュリティへの理解度、認識の高さは、これまでの教育のたまものでもある。

「従業員には入社初日のセキュリティ研修で、なぜメールでのファイル送信はいけないのか、クラウド上のドライブによるファイル共有の方が望ましいのはなぜか、説明している。また四半期に1度は、セキュリティに関する理解度チェックをeラーニングで実施するなど、コツコツと活動している」(土佐氏)

 理解度テストは全5問。復習していれば100点が取れる内容で、「テストの点数が上がることよりも、選択肢を読むことが大切で、全員に受けてもらうことにこだわっています」と土佐氏は言う。



 またfreeeでは、新たなセキュリティ上の問題(インシデント)についての情報を、経営陣とともに従業員にも共有している。

「話題になっているインシデントについては、CSIRTから経営陣向けに定期的に報告をしている。インシデントに対してfreeeではどういう対策がとられているか、また足りない部分については『このように対策すべき』という取り組みを説明するが、その報告の様子を全社にも動画で配信している」(土佐氏)

 取り上げるインシデントは世間で起きているニュースなので、従業員にも興味を持ってもらいやすい。専門的な難しい用語は避け、こちらも少なくとも四半期に1度は配信するようにしているという。セキュリティインシデントの社内理解が進むとともに、経営者がセキュリティに関心を持つ姿勢もアピールできる点で、実に優れた取り組みと言えるだろう。

 こうしたセキュリティに関する啓蒙活動により、「メールにファイルを添付しないことについても、freeeでは社内の共通認識となっていた」と土佐氏。パスワード付きファイルの受信廃止が他社より比較的進めやすかったのは、これまでの教育の成果と言って過言ではないだろう。

【参考】
無意味な「パスワード付き添付ファイル」受信をfreeeが廃止できた理由(ダイヤモンド・オンライン)

三菱パワーがMSP(マネージドサービスプロバイダ)の不正アクセスの2次被害を受ける(転載)~サプライチェーンリスク顕在化事例~



三菱パワーは、マネージドサービスプロバイダ(MSP)経由で不正アクセスを受けたことを明らかにした。一部情報の流出が確認されているが、機微な情報や個人情報は含まれていなかったとしている。

9月初旬より約1カ月間にわたり、同社や同社子会社のパソコン、サーバが不正アクセスを受けたもの。サーバの設定情報やアカウント情報、認証プロセスにおけるメモリダンプなど、システム関連の情報が窃取された。

機微な情報や機密性の高い技術情報、取引先に関する重要な情報、個人情報の流出などは確認されていないという。また親会社である三菱重工グループなどへの不正アクセスについても否定した。

同社によると、9月7日に同社のサーバ1台がマネージドサービスプロバイダ経由でマルウェアに感染。同プロバイダが提供するソフトウェアに修正プログラムや対策など用意されていないいわゆる「ゼロデイ脆弱性」が存在し、悪用された。

その後、ネットワークの偵察を経て断続的に感染を拡大する活動が行われ、同月22日には同社子会社のサーバに攻撃の起点を移すなど横展開されている。


不正アクセスで顧客情報約8.8万件が被害か(転載)~想定損害賠償額は21億円程度か~


顧客管理システムが不正アクセスを受けた保険代理店のライフィは、データベースに保存されていた顧客情報8万8564件が被害に遭った可能性があることを明らかにした。

今回の問題は、同社サイトを通じて顧客情報の管理システムにおける脆弱性を突かれ、データベースが不正アクセスを受けたもの。10月13日に判明し、流出した顧客情報を特定するため、調査を進めていた。

調査の結果、保有する顧客情報が不正アクセスを受けたものの、流出した具体的な情報の特定はできず、攻撃を受けたファイル内に保管されている全顧客情報8万8564件が流出したと結論づけた。

具体的には、同社サイトを通じて保険商品のパンフレットを請求したり、同社スタッフと面談、メール、電話を通じてやり取りした最大8万8111件の顧客に関しては、氏名、住所、電話番号、生年月日、メールアドレス、対応履歴などが記録されていた。

ITセキュリティリスクアセスメントの実施 / Conducting an IT Security Risk Assessment

Conducting an IT Security Risk Assessment

企業のリスクを低減する能力を高めましょう。新しいホワイトペーパーでは、効果的なITセキュリティリスクアセスメントの実施が重要な理由をご紹介しています。ITセキュリティリスクアセスメントの実施

すべての企業は、既知のものから未知のものまで、ほとんど毎日のようにリスクに直面しています。リスク評価は、ビジネスの混乱や損害を最小限に抑えるために、テクノロジーやその他の企業資産に対する脅威を評価するのに役立ちます。

リスクは様々な形で発生するため、企業がこれらの脅威に備え、対処するための最善の方法は、事業目的に沿った強力で構造化されたリスク軽減戦略と計画を策定することです。

現在および将来のリスクを軽減し、潜在的な損害を軽減するためのリスクアセスメントを成功させるための重要なステップをより深く理解することができます。これらのステップには以下が含まれます。

  • 資産の特定と評価
  • 既知の脅威の識別
  • 脆弱性の特定
  • リスクの特定
  • リスク治療の決定

このISACAホワイトペーパーは、ITセキュリティリスク評価プロセスを初めて利用する方や、ITセキュリティリスク評価プロセスに慣れていない方のための情報システムやビジネスの専門家向けのホワイトペーパーです。

バックアップ(非公開)

【転載】「会社の看板」は早く利用して、こちらから捨てたほうが良い

「会社の看板」は早く利用して、こちらから捨てたほうが良い


 日本最大の大手広告代理店が、40代以上の正社員230人を業務委託の個人事業主に切り替える制度を開始するというニュースが話題になつています。

正社員という日本型の雇用形態は、企業から見れば大きなリスクになっています。事業環境の変化が大きくなればなるほど、固定費となる社員を抱え込むのは、経営を不安定させる要因なのです。

すでに日本では、企業年金制度が確定給付型から確定拠出型(日本版401k)にシフトし、年金の運用リスクが企業から従業員に転嫁されました。

今後も大きな流れとして、会社側がリスク回避のために、従業員を実質的に切り捨てていくと思います。

であれば、会社で社員として働いている人がやるべき事は、2つです。

1つは会社の看板を可能な限り利用すること

そして

もう1つは、会社に捨てられる前に自分から会社を捨てられる力を身に着けておくことです。

会社の看板があることによる1番大きなメリットは「お金を借りる力」が持てることです。個人事業主になれば、信用力がつくまで借り入れすることができません。会社にいるうちに、お金を借りられるだけ借りておく。「信用力のマネタイズ」をできるだけ早くやっておくことです。


NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係(転載)


NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係:働き方改革時代の「ゼロトラスト」セキュリティ(6) - @IT:

NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳

NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係

 SP 800-207は米政府がネットワークやセキュリティのモデルとしてのゼロトラストについて言及する際に、政府標準として扱われるべく提言されたものです。今後、他のSP 800シリーズ同様に、世界中の多くの組織がこのSP 800-207を参考に、ゼロトラストについて議論すると思います。

 今回はSP 800-207から、「ゼロトラストにおける7つの原則」といえる部分を解説していきます。

NISTによる「ゼロトラストにおける7つの基本原則」

 SP 800-207には、ゼロトラストが生まれた背景、基本的な考え方、そして実践の方法がまとめられています。これからゼロトラストを学ぶ上で非常に良質なドキュメントといえるでしょう。
 中でも第2章冒頭に掲げられた、「ゼロトラストにおける7つの基本原則」は、ゼロトラストを実現する上での理想的な考え方がまとめられています。
  1. データソースとコンピュータサービスは、全てリソースと見なす
  2. 「ネットワークの場所」に関係なく、通信は全て保護される
  3. 組織のリソースへのアクセスは、全て個別のセッションごとに許可される
  4. リソースへのアクセスは動的なポリシーによって決定される
  5. 組織が保有するデバイスは、全て正しくセキュリティが保たれているように継続的に監視する
  6. リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される
  7. 資産・ネットワーク・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する
 これらの7つの基本原則をまとめ、以下を満たした状態が理想的なゼロトラストであると提言しています。
  • 全てのリソースへのアクセスの認証と認可がリクエストごとに動的に決定される
  • 全てのリソースの状態が、その判断に用いられる
  • 全てのリソースの機器や通信が保護され、状態が可視化によって監視されている
 では、これらの7つの基本原則について詳しく見ていきましょう。

【1】データソースとコンピュータサービスは、全てリソースと見なす

 アクセスする側/される側に関係なくネットワークに接続されている全ての機器をリソースとして見なします。
 小型のストレージ機器、IoTデバイスなど、あらゆる大きさや機能を持っているデバイスもリソースとして考えます。もちろん、クラウドサービスもリソースの一つとして考えます。さらに、個人が所有している機器であっても組織のリソースにアクセスするのであればリソースとして考えます。

【2】「ネットワークの場所」に関係なく、通信は全て保護される

 この原則における「ネットワークの場所」とは、社内ネットワークやプライベートネットワークといった、一般的に「従来の境界線の内側や外側」とされる範囲を指しています。
 従来の境界型セキュリティモデルでは、ネットワーク境界線の内側は安全であり、暗黙的な信頼を付与していました。ゼロトラストの基本原則では、「セキュリティシステムで保護されたネットワーク境界範囲内であっても、インターネットと同様に利用可能な最も安全な方法で通信を保護すべきである」としています。

【3】組織のリソースへのアクセスは、全て個別のセッションごとに許可される

 従来のネットワークアクセスの考え方では、一度行われた認証や認可を一定時間キャッシュし、パフォーマンスを効率化します。しかし、ゼロトラストでは「全て個別のセッションやリクエストごとに許可されるべき」とされています。さらに、「アクセス時に許可される権限は、そのアクセスに必要最小限の権限にすべき」とされています。
 セキュリティよりもパフォーマンスを優先した設計が招く、横展開によるアクセス侵害を防ぐための、極めて重要なコンセプトです。

【4】リソースへのアクセスは動的なポリシーによって決定される

 従来のネットワークアクセスの考え方では、あらかじめ決められたポリシーによってアクセス許可が決定されていました。例えばユーザーIDとパスワードの組み合わせやクライアント証明書の確認などです。
 ゼロトラストでは、さまざまな属性をパラメーター化し、都度ポリシーに従って計算を行い、アクセスを許可します。下記が要素として扱われます。
  • クライアントの識別としては、ユーザーアカウントや関連属性など
  • デバイスの状態では、インストールされているソフトウェアのバージョンやネットワークの場所、アクセス日時など
  • 振る舞い属性として、ユーザーやデバイスの異常な振る舞いの記録の有無
  • 環境属性として、ネットワークの場所や時間、報告されている攻撃など
 これらの状態や属性を基に、データのリスクレベルに応じて許可すべきアクセスルールを決定し、その一連のセットがポリシーとなります。これらの状態や属性は時間によって常に変化するため、データへのリクエストを行うたびに最新の状態を基にアクセスの許可を決定します。

【5】組織が保有するデバイスが、全て正しくセキュリティが保たれているように継続的に監視する

 この基本原則では、組織内に存在する全てのデバイスがセキュリティを保って正常に動作している状況を監視し、必要に応じてタイムリーなアップデートや修正の実施を求めています。これは、「どのデバイスも本質的には信頼できない」という考えに由来します。
 脆弱(ぜいじゃく)性が発見されているにもかかわらず修正が行われていないようなデバイスを、セキュリティが保たれたデバイスと同じ扱いにしません。組織に接続する個人のデバイスも含めて常に監視を行い、セキュリティを保持することが求められます。

【6】リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される

 従来のモデルでは、ユーザーにおける認証・認可は一度認証された結果の使い回しが想定されていました。再認証によるユーザーの手間の省略やパフォーマンスの向上を求めた結果です。
 しかし基本原則では、現在実行中の通信においても継続的に信頼性の再評価を行い、場合によっては再認証の実施を求めています。

【7】組織は、資産・ネットワークインフラ・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する

 この基本原則では、資産のセキュリティ状況、トラフィックの状態、アクセス要求のログなど、組織のネットワークやデバイスにまつわる情報を常に取得し、さらに分析した結果を活用したポリシーの作成やセキュリティの改善を求めています。
 これは、組織の成長やテクノロジーの進歩によって変化し続ける組織のネットワーク形態やデバイス、ユーザーの利用状況に応じて、ポリシーの作り方やセキュリティの在り方を常にアップデートし続けるという考えです。

ゼロトラストの7つの基本原則と従来の境界型防御

 これらの7つの基本原則は、実現する技術にとらわれない普遍的な書き方です。いままでのネットワークセキュリティの考え方に基づいて提供されているさまざまなセキュリティソリューションが、ゼロトラストにおいても活用が可能なのは、そのためです。
 過去のゼロトラストの議論では、「ゼロトラストは従来の境界型防御を除去する」という部分が強調されてきました。しかし境界型防御の機能は、ゼロトラストを実現する機能の一部として、「マイクロセグメンテーション」「マイクロペリメタ」の形で取り入れられています。
 重要なのは、従来の境界型防御の排除ではなく、これらの7つの基本原則が満たされた状態が理想的なゼロトラストであると定義されていることです。
 また、「Never trust, always verify.」という言葉に代表されるように、暗黙的な信頼をゼロにするために、「全て(All)」という言葉が多用されているのが分かります。
 ただし、これらはあくまで理想的な目標であって、「現実的には全てが純粋な形で完全に実装されるとは限らない」とも書かれています。
 NISTが提言したSP 800-207 Zero Trust Architectureでは、現時点で理想的なセキュリティの姿を基本原則によって定義付けました。またSP 800-207では、これらの原則を実現するアイデアやコンセプトの集まりを「ゼロトラスト」とし、ゼロトラストのコンセプトやアイデアを利用する組織のサイバーセキュリティのプランを「ゼロトラストアーキテクチャ」として説明しています。
 ゼロトラストは、境界型防御の単純な否定ではなく、テクノロジーの進化に沿ったモダンなITアーキテクチャと共存可能なセキュリティコンセプトであると、SP 800-207からは読み解けます。

「データ侵害インデックス」サイト「Cit0day[.]in」で検索する方法 / Cit0day Search Tool(転載)

Cit0day Search Tool:

After my podcast episode about the Cit0day data leaks, my colleague Jesse initiated the idea of making our own search engine. The 23,000 breached databases within this massive leak can be queried on various breach notification sites, but they all simply provided a notice of hit within the Cit0day collection. None of them identify WHICH breached database contains the exposure. We now offer a tool for this. Head over to:

https://breach.myosint.com/

Provide any email address and immediately receive notification of the specific data breach which contains the email address. I present more details on the show tomorrow.

 

JPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開(転載)


sugimu retweeted: 公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…:
sugimu retweeted:
公式ブログJPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開。これまで最もご要望の多かった、リアルタイムイベントログ分析を可能にする機能を追加しました。お試しください。^YK blogs.jpcert.or.jp/ja/2020/10/log…

ーー

JPCERT/CC では、イベントログの分析をサポートするツール「LogonTracer」の最新版バージョン1.5をリリースしました。これまでのLogonTracerは、セキュリティインシデントの事後調査という用途に特化していましたが、リリース直後からLogonTracerをリアルタイムログ分析にも活用したいという要望が多く寄せられていました。そのため、今回のアップデートでは、リアルタイムイベントログ分析を可能にする機能を追加しました。
今回は、このアップデートについて紹介します。その他のアップデート内容については下記のリリースをご覧ください。

https://github.com/JPCERTCC/LogonTracer/releases/tag/v1.5.0

Elasticsearchのサポート

LogonTracerは、Elasticsearchと連携することでリアルタイムログ分析が可能になります。
図1は、LogonTracerとElasticsearchを連携させた場合のイメージです。LogonTracerは、デフォルトではWinlogbeatを使用してElasticsearchに送信されたイベントログをインポートすることが可能です。

LogonTracerとElasticsearchの連携イメージ
図 1:LogonTracerとElasticsearchの連携イメージ

LogonTracerは、Elasticsearchからインポートしたログを分析し、結果をElasticsearchに保存することができます。イベントログを可視化して分析する場合、LogonTracerから確認する必要がありますが、不審なアカウントのランキングやサマライズしたログの分析結果はElasticsearchにも保存されるため、ElasticsearchやKibana上で同様の分析結果を確認することが可能です。
図2は、LogonTracerの分析結果をKibana上で表示した様子です。KibanaのWatcherなどを使用して、LogonTracerからレポートされた不審なログをアラートするように設定しておけば、リアルタイムで異常検知のサポートになります。

LogonTracerの分析結果をKibanaで表示
図 2:LogonTracerの分析結果をKibanaで表示

Elasticsearchからのログインポート

ElasticsearchからLogonTracerにログをインポートには、Web GUIから行うことができます。左下の「Load from ES」ボタン(図3の左)をクリックすると、インポート用の設定画面(図3の右)が表示されます。

Elasticsearchからログをインポートする設定画面
図 3:Elasticsearchからログをインポートする設定画面

Elasticsearchからインポートする際の、さらに詳細な設定(index名など)はコマンドラインから行うことができます。詳しくはLogonTracerのWikiをご覧ください。

https://github.com/JPCERTCC/LogonTracer/wiki

LogonTracerにログをインポートする際の注意

LogonTracerの分析機能の大きなポイントの1つにイベントログの可視化があります。可視化は、ログ分析の大きなサポートになりますが、大規模なログの可視化は、ログ表示の遅延や大規模なグラフを目視で分析することは難しいという問題があります。これは、LogonTracerに限らず大規模な情報を可視化するシステムには、共通する課題です。
そのため、LogonTracerに、長期間(1ヶ月や1年など)のログをインポートすることは、可視化速度の低下につながるためお勧めできません。1週間または1日(適切な期間はホスト数やユーザ数によって異なります)などの間隔で、必要なログをインポートして、分析することを推奨します。
LogonTracerを、ADイベントログの監視に使用する場合は、cronなどで定期的にイベントログを読み込んで分析し、分析結果をElasticsearchに蓄積することで、Kibana上でLogonTracerの分析結果を監視する運用を行ってください。確認が必要なログが見つかった場合、LogonTracerに対象期間のログをインポートしてログの可視化を行うことで、効率的な監視が可能になります。