JNSAの損害賠償額算出式は正しいのか?~実際の判例をもとに検証してみる~


 企業が情報漏洩を起こした際、JNSAの損害賠償額算出式を用いた想定損害賠償額を算出しているが、これって妥当なのだろうか?

先日、とある判例の話を聞けたので、それを基に検証してみたい。

【インシデント概要】
不正アクセスによる個人情報流出

 -最大1万6798件の個人情報、うち7316件はクレジットカード情報

・流出した情報(赤字個所は特に損害賠償額に大きく響く項目)

-名前

-住所

-電話番後

-メールアドレス

-クレジットカード番号(番号、名義、有効期限セキュリティコード含む)

-性別

-生年月日

-パスワード

JNSAの損害賠償額算出式を用いた想定損害賠償額

・カード流出に関わる1件当たりの想定損害賠償額:78,000円
 ⇒7,316件なので、計570,648,000円(約5.7億円)


【流出企業における実際の損害額】

・SQLインジェクションを抱えたポンコツシステムの開発費:約2,100万円

・顧客への謝罪費用(クオカード):約1,900万円

・顧客からの苦情処理費用:約500万円

・調査費用(主にフォレンジック):約400万円

・営業損失:約6,000万円

・その他:約50万円

------------------------------

計約1.1億円


ん~。損害賠償額算出式の方がかなり上振れているな。。。

とはいえ、クレジットカードの有効期限とセキュリティコードまで流出しているので、この金額で済んだのは不幸中の幸いともいえるかもしれない。

裁判になるといろいろと細かいことが明らかになるので、興味深い。

ちなみに判例の詳細はこちら(バックアップ)

シングルサインオン(SSO)とは~概要と実装方法を簡単に整理してみる~


 先日、「こんなシングルサインオンの実装を検討しているのだが意見が欲しい」と言われ、資料を見ていたのだが、その内容はシングルサインオンとは遠くかけ離れた、ただの認証省略の仕組みだった。苦言を呈すことになったのは言うまでもないが、そんこともあり、簡単にシングルサインオンについて整理してきたい。

シングルサインオン(SSO)とは?

シングルサインオン(SSO)とは、1組のID・パスワードによる認証を1度行うだけで、複数のWebサービス・クラウドサービス・アプリケーションにログインできるようにする仕組み。

パソコンやスマートフォン、インターネットが普及し、1人でいくつものWebサービスやクラウドサービスを利用する方が増えています。以前は、これらを利用する際、サービス・アプリケーションごとに認証を行っていました。一方、これらのサービス・アプリケーションがシングルサインオンに対応していれば、認証が1回ですむようになります。

シングルサインオン(SSO)を実現する方法

代行(代理)認証方式

クライアントのパソコンにインストールした専用のエージェントが、ユーザーの代理でID・パスワードを打ち込む方式です。エージェントはパソコンに常駐し、各サービス・アプリケーションのログイン画面が起動するのを検知し、自動的にID・パスワードを入力します。

リバースプロキシ方式

リバースプロキシと呼ばれる中継サーバー上で認証を行う方式です。リバースプロキシ上で認証を追加した場合に、その後ろにあるサービスにログインができるようになります。


エージェント方式

Webサービスの専用のエージェントモジュールを組み込んで、シングルサインオンを実現する方式です。エージェントはシングルサインオン用の外部サーバーと連携し、認証やアクセス権限のチェックを行います。

SAML認証方式

SAML(Security Assertion Markup Language)認証では、IdP(Identity Provider)とSP(Service Provider)と呼ばれる2つの構成要素で、シングルサインオンを実現する方式です。

ユーザーが対象のWebサービス(SP)へアクセスすると、SPはIdPへ認証要求(SAML)を送信します。すると、IdPがユーザーのパソコンやスマートフォンに専用のログイン画面を表示させ、認証を促します。認証が成功すれば、IdPはSPに対して認証応答(SAML)を送信し、SPがそれを受け取ると自動ログインを実行するという流れです。これによって1度認証が成功すれば、SAMLに対応する別サービスへ自動でログインできるようになります。


メリット

メリット1.利便性が向上する

たくさんのWebサービス・アプリケーションを使っていると、認証の際に利用するID・パスワードの組み合わせもそれだけ増えることになり、管理に手間もかかります。また、各サービス・アプリケーションを利用する際に、いちいちログイン作業をしなくてはなりません。

一方、利用するWebサービス・アプリケーションがシングルサインオンに対応していれば、ID・パスワードの組み合わせは1つですむようになります。その上、それらWebサービス・アプリケーションの認証は1回だけ行えばよいので、より便利に利用できるようになるのです。

メリット2.パスワード漏洩のリスクが低くなる

利用すべきID・パスワードの組み合わせが増えると、その管理がおろそかになるものです。たとえば複数のサービス・アプリケーションで同じID・パスワードを使い回したり、付箋などに書いてパソコンに貼ったりする方も多いでしょう。覚えるのが面倒になり、推測されてしまいやすい簡単なパスワードを設定している方もいます。

一方、シングルサインオンを利用すれば、管理すべきID・パスワードの組み合わせは1つだけですむので、覚えるのも簡単になり管理の手間もかからなくなるわけです。そのため付箋に書いたメモを誰でも見られるようなところに置いたりすることはなくなり、適切に管理されやすくなります。ある程度複雑なパスワードを作成したとしても、1つだけなら覚えるのは苦ではないでしょう。

これらのことから、シングルサインオンを導入することによって、パスワード漏洩のリスクが減るわけです。

デメリット

デメリット1.パスワードが漏えいすると重大なセキュリティリスクにつながる

シングルサインオンで利用するID・パスワードが万が一漏洩してしまうと、そのID・パスワードを利用するサービス・アプリケーションが全て不正利用されるリスクにさらされることになります。

デメリット2.システムが停止すると関連するサービスにログインできなくなる

シングルサインオンは、特定のシステムによって認証情報が管理されています。そのため仮にその管理システムがダウンした場合、シングルサインオンでログインできるように設定している全てのサービス・アプリケーションが使用できなくなる可能性があります。

デメリット3.コスト

シングルサインオンを実現するためには、自社サーバーに専用のソフトウェアをインストールするオンプレミス型のタイプと、専用のクラウドサービスを利用するタイプがあります。オンプレミス型は特に初期導入時のコストが高額となる可能性がある一方、クラウド型は導入時のコストは少なくてすむものの、毎月の費用がかかるため利用期間が長くなれば、それだけコストがかさむことになります。

保険見直し~がん治療は通院がメインなので通院保障が重要!?~


 昔、保険会社による保険金未払い事件が多発した影響からか、毎年契約しているすべての保険会社から、現在の保険内容の確認やら、見直しやら、住所が変わっていないかやらの手紙が送られてくる。

そんな中、医療保険を契約している会社から保険内容の見直しの案内があり、がん保険の通院保障オプションの案内を見て、2019年に参加したお金のEXPOのことを思い出した。

がん保険は、昔は長期入院の伴う長い闘病生活のイメージだったが、今は長期入院せず、通院による治療がメインとなっていることから、入院保障だけではなく、通院保障が重要だという話を元SKE48の矢方 美紀さんが自身の闘病経験を踏まえて話してくれていたのだった。

やばい。今2021年なので、2年も放置してしまっていた。

幸いまだガンにはなっていない模様なので、とっとと入っておこう。

さっそく保険会社に電話して、契約内容見直しの依頼をかけた。

人生40年近く生きてきて、何となく保険との付き合い方が分かってきた気がする。

保険は早く入っておいたほうがいいとか、生涯で払う保険金は同じなのでいつでもいいとか、そもそも入る必要がないとか、いろいろ意見があるが、個人的な今のスタンスは下記である。

ちなみに掛け捨ての医療保険の話ね。

保険は若いうちに(安い保険に)入るべきである。

保険は若いうちに入ったほうが良い。高齢になってから入っても生涯で払う保険金は同じだが、若いうちに入ったほうが保険料が安く、精神的な負担額は軽く済む。

保険は入る必要がないという人がいるが、そういう意見もアリだと思う。個人的にはお守り替わりで済む程度の金額にし、万一保険料が支払われない事態になっても「しゃーない」と思える金額(=月額2000円以下)で保険に入った。

また、当然ながら保険会社の選択に際してはネットライフ生命のようなオンライン保険会社にするべきである。

テレビで有名人を起用したCMを放送しているような保険会社は厳禁である。

理由は簡単で、CM代金や有名人のギャラが保険料の跳ね返って非常に割高だからである。

かしこい人はオンラインの保険会社を選択し、情弱者はCM等で知名度の高い(割高な)保険会社を選択するのである。

諸々の情勢変化で年1.5%の保険料増加は見込むべき

医療は進歩している。

それに伴い、保険は変わる。

自分が初めて保険に入った際には無かったが、その後出てきたキーワードとして、「先進医療」とか「通院保障」がある。

これらは保険加入時には無かったため、結果として追加の保険料を払って追加する形態となる。

最初の保険加入時は1,800円/月くらいだったが、先進医療特約を付けたり、がん通院保障をつけたり、必要なオプションを追加していった結果、約15年の時を経て2,500円/月となった。

オプションで保険料が上がっていくことを考慮し、最初の保険加入時は必要最小限の保険にしておいたほうが良い。

保険は保険料控除の枠で十分

自分は若い頃にバイクで事故った際、保険が期待した働きをしなかったことから、基本的には保険に対して懐疑的な立場である。

そのため、最初の保険に入る際、どの程度の掛け金にすべきを考えた際に、たどり着いた一つの結論が「保険料控除の枠で十分」である。

つまり、介護医療保険、生命保険、年金保険、共に、それぞれ80,000円/年で十分である。

これ以上は保険料控除の枠から外れるし、保険料を払いすぎていると考えてもよいのではと思っている。

DDoS攻撃(SYN/ACK Reflection攻撃)の仕組み(転載)


Masafumi Negishi retweeted: 「IIJのSOCアナリストが検知と分析のサイクルを回すわけ DDos攻撃検知にAIを選ばなかった理由」 logmi.jp/tech/articles/… 昨年9月開催のIIJ Technical NIGHT vol.9で登壇した #セキュリティ 本部 守田 瞬の講演がログミーの記事になりました。 全2回で、後半はDDos攻撃の観測方法について紹介。:
Masafumi Negishi retweeted:
「IIJのSOCアナリストが検知と分析のサイクルを回すわけ DDos攻撃検知にAIを選ばなかった理由」
logmi.jp/tech/articles/…
昨年9月開催のIIJ Technical NIGHT vol.9で登壇した #セキュリティ 本部 守田 瞬の講演がログミーの記事になりました。
全2回で、後半はDDos攻撃の観測方法について紹介。

SYN/ACK Reflection攻撃はTCPの3wayハンドシェイクを悪用したものになります。リフレクション型の攻撃なので登場人物は3人。攻撃者とリフレクターと、被害者にあたる攻撃対象です。

攻撃者は何をするかというと、3wayハンドシェイクをしようと試みます。SYNパケットの送信元はIPスプーリングになるんですが、これは攻撃するサーバーのIPアドレスとか、ルーターだったら、そのルーターだったりとかに偽装されています。

リフレクターは、送信元が偽装されたSYNパケットが悪性かどうかというのは基本的に判断できないので、3wayハンドシェイクのルールに則って、素直にそのSYN/ACKパケットを偽装されたIPアドレス宛に応答として返送します。

攻撃者がスプーフしたSYNパケットをリフレクターに送ることで、スプーフされたサーバーやルーターにSYN/ACKパケットが集中してしまうというのが、DDoS攻撃の原理になっています。量が多いとDDoS攻撃が成立しちゃうよね、というのが脅威のポイントです。

当時、攻撃者はボットネットなのか攻撃ツールなのかわからないところから、実際はリフレクターなので裏にサーバーがいるんですが、我々のお客さまのファイアウォールを通過するように、SYNパケットを投げつけてきました。先ほども言った通り、SYNパケットは攻撃対象側の宛先にスプーリングされているんですが、リフレクターはSYNパケットが悪性かどうかを判断することはできません。

なので、素直に被害者側にSYN/ACKパケットを応答していたという事象を我々は1年半前ぐらいに観測しました。ファイアウォールを通過しているので、ログは情報分析基盤のデータベースに集約されています。情報分析基盤から分析をすることで、この事象を発見したというのが、スタートになります。


2019年は、ひどいときには日に数件(通知が)上がっていたんですが、どんどん観測が増えてきて早く検知を自動化したいなということで、検知コードを情報分析基盤に仕込みました。こうすること自分が能動的に「今日はSYN/ACK Reflection攻撃あったかな?」と探さずに済むような仕組みが整ったわけです。

そうすることでこの図の通り、それ以降SYN/ACK Reflection攻撃されると自動的にログが情報分析基盤に集約されて、検知コードが反応すれば私に通知が来るようになりました。通知が来たら詳細な分析を行います。

もちろん、誤検知もたまにはあるので、しっかり調査していきながら、裏付けができたものに関してはみなさんのところに(情報が)届くようにwizSafe Security Signalで紹介しています。ブログを書いているだけではなくて、裏ではこういった検知ロジックも考えながら、調査もしながらやっていたというのが実はの話です。

中国の個人や企業の調査に役立つサイト / Useful websites for your investigation on Chinese individuals and companies(転載)


中国語のウェブサイトを調査するときの資料メモ archive.vn/3mqrm archive.vn/L0f4P: 中国語のウェブサイトを調査するときの資料メモ
archive.vn/3mqrm
archive.vn/L0f4P

中国の法制度やオンライン情報プラットフォームに関する知識が不足しているため、多くの欧州企業は、中国の個人や企業に関する調査をどこから始めればよいのかわからない。ここでは、中国に関する調査に役立つウェブサイトをいくつか紹介したいと思います。これらのサイトは、ほとんどの人がアクセス可能であり、情報のほとんどは無料です。

1.National Enterprise Credit Information Publicity System (国家企业信用信息公示系统)


この政府のウェブサイトは、私のお気に入りのウェブサイトの一つに属しています。あなたが調査している会社が中国で合法的に登録されている場合は、ここで見つけることができるはずです。登録資本金、法定代表者、設立日などの基本的な情報はもちろん、罰則履歴や業務不正記録などの情報も掲載されているので、この会社の基本情報をいくつか見つけることができます。このサイトに掲載されている情報はかなり信頼性が高いです。素敵な資料が必要な場合は、報告書全体をダウンロードすることもできます。欠点は、特に海外からアクセスしようとした場合、ウェブサイトへの接続が時々不安定になることがあることで、これは多くの中国政府のウェブサイトで共通の問題のようです。

2.Court Enforcement Information Publicity (中国执行信息公开网)


裁判所から不正な営業活動を行っていると認定された中国の個人や企業をまとめて検索できるサイトです。労働者に借金をしている企業かもしれないし、債権を滞納している人かもしれない。すでに債務を履行している人や企業は、ここにはもう出てこないだろう。問い合わせで対象物のID番号を追加しておくと、より正確な結果が得られます。

3.China Judgements Online (中国裁判文书网)


ここでは、中国の異なる地域の裁判所によって発行された現在の判決についての詳細な情報を見つけることができます。特定の裁判所の種類、特定の地域、さらには弁護士の名前を指定して検索することができ、特定の弁護士が扱った事件に興味がある場合に便利です。少数民族自治区の判決の中には、中国語以外の言語(モンゴル語、チベット語、ウイグル語、韓国語、カザフ語)での判決もあります。

4.Cninfo (巨潮资讯网)


中国のすべての公開企業は、財務報告書と定期的な発表をこのウェブサイトで公開することを義務付けられています。そこで、あなたの対象が中国本土の2つの証券取引所(上海証券取引所と深圳証券取引所)に上場している中国企業であれば、その企業のここ数年の最も重要な数字を見つけることができるはずです(香港に上場している中国本土企業の報告書もここで見つけることができます)。また、役員名で検索することで、上場企業に採用されているかどうかを確認することもできます。

5.QCC (private, qichacha, 企查查)


企業情報を提供する民間プラットフォームです。基本的な登記情報の他に、株主構成、受益者、営業許可証、特許情報などを見つけることができます。これは中国最大の情報提供者の一つです。彼らは、異なる権威のあるウェブサイトからデータをクロールして情報を収集し、はるかに良い方法で情報を可視化します。無料で登録して、ほとんどの情報を見ることができ、時には会員登録をして、よりカスタマイズされたサービスを受けることもできます。

6.Qixin (private, 启信宝)


QCCのプラットフォームとかなり似ていますね。企業によっては、給与分布や健康保険の加入者数などが掲載されている場合があります。しかし、このような情報は企業によっては常に入手できるわけではないし、あまり信頼性が高いとは言えません。

7.Tianyancha (private, 天眼查)


こちらも同様に信用情報の非公開プラットフォームです。ただ、海外のIPは専用のVPNを設定していないとアクセスできないようになっています。

これらの個人のウェブサイトは、オープンソースから情報をクロールするために非常に似た方法を使用しています。彼らは彼らのウェブサイト上でさえ非常に似たようなカテゴリを持っています。あなたが感じることができる最大の違いは、そこに異なるアルゴリズムを使用しているため、キーワードで情報を検索するときに表示される結果の数かもしれません。彼らは間違ったデータをクロールしている可能性がありますので、世界のすべてのそのような民間情報プロバイダと同様に、あなたはそこに取得した結果について注意する必要があります。上記の3つは、この分野での主要なものであり、より少ないミスをするが、どれもないわけではありません。あなただけのいくつかの基本的な情報を探している場合は、あなたが使用する1つの違いはあまりありません。しかし、株主構成や会社の家族構成など、より複雑な情報については、政府機関のサイトと比較して情報を検証した方が良いでしょう。そしてもちろん、会員価格も考慮すべき要素です。

しかし、中国に関する調査の最大の課題は、情報の入手のしやすさよりも言語だと思います。この課題を克服するためには、合理的な文章を得るために高度な翻訳者を必要とするだけでなく、彼らの名前がどのように構築されているか、どのように企業があなたの国と比較してどのように異なる構造を持っているかなどを理解する必要があります。あなたが中国の信用調査のための異なる方法とソースを持っている場合は、私と共有することを歓迎します。

マーケティングプラットフォームApollo.ioが不正アクセスを受け、1,100万件の個人情報が盗取&販売される / 11 million records of French users stolen from marketing platform and put for sale online(転載)~日本で起きた場合、想定損害賠償額は110億円程度か~


11 million records of French users stolen from marketing platform and put for sale online:

今回の流出により、数百万人のApollo.ioユーザーとその雇用者が、フィッシングやソーシャルエンジニアリング攻撃、ブルートフォース攻撃などの危険にさらされる可能性があります。

人気のハッキング・フォーラムのユーザーが、米国のセールス・エンゲージメントおよびデジタル・マーケティング企業であるApollo社から盗まれた約1,100万件のユーザー記録を含むとされるデータベースを販売しています。

流出したアーカイブに含まれるファイルには、データが盗まれたとされるフランス在住の10,930,000人のユーザーに関する、フルネーム、電話番号、位置座標、職場情報、ソーシャルメディアのプロフィールなど、さまざまな情報が含まれています。

この投稿者は、データがどのようにしてApollo社から流出したのかについて、追加情報を提供していません。また、Apollo社の顧客データベースのうち、フランス国内の部分だけでなく、それ以外の部分も脅威となる人物が保有しているのか、あるいは、以前にApollo社が被った不正アクセスから盗まれたデータなのかは不明です。

Apollo社に、このリークが本物であることを確認できるかどうか、また、ユーザーや顧客に警告を発しているかどうかを尋ねましたが、このレポートを書いている時点では、同社からの回答は得られていません。

自分のオンラインアカウントが他のセキュリティ侵害で公開されていないかどうかを確認するには、150億件以上の侵害記録を収録した個人情報漏洩チェックツールをご利用ください。

何が漏洩した?

流出したアーカイブから見たサンプルによると、Apollo社がLinkedInのプロフィールから収集した可能性のある、ユーザーの様々な主に職業上の情報が含まれているようです。

  • フルネーム
  • 個人および仕事上のEメールアドレス
  • 電話番号
  • ユーザーとその雇用者の位置座標
  • 現在および過去の雇用形態、詳細な雇用主情報などの職業データ
  • LinkedInプロファイルへのリンク

流出したデータの一例:

漏洩した会社はどこですか?

Apollo社は、サンフランシスコを拠点とするソフトウェア企業で、企業がマーケティング目的でコンタクトを取るべき新しい見込み客を識別、分析、発見するためのデジタルプラットフォームを開発しています。

Apollo社自身によると、同社は四半期ごとにセキュリティ監査を実施し、定期的に侵入テストを行い、侵入検知システムをオンラインで運用しているとのことです。そうは言っても、Apollo社がデータを流出させたのは今回が初めてではありません。2018年には、2億人のユーザー記録を含むデータベースが脅威主体に侵入されたことで、同社は批判にさらされました。

漏洩の影響は?

Apollo社のデータベースで見つかったデータは、情報が流出したユーザーや雇用者に対して様々な形で使用される可能性があります。

  • ターゲットを絞ったフィッシング攻撃の実施
  • 1,100万件の電子メールおよび電話番号へのスパム送信
  • 個人の電子メールアドレスやLinkedInのプロフィールのパスワードを強制的に変更する行為
  • 勤務先の企業ネットワークに侵入するために、勤務先の電子メールアカウントに侵入しようとする行為

今回流出したアーカイブには、社会保障番号、文書スキャン、クレジットカード情報などの機密情報は含まれていないようですが、電子メールアドレスだけでも、脅威をもたらすには十分な情報となります。

特に決意の固い攻撃者は、流出した情報を他の侵害事件のデータと組み合わせて、潜在的な被害者のより詳細なプロファイルを作成し、被害者やその雇用者に対してフィッシングやソーシャルエンジニアリングの攻撃を仕掛けたり、あるいは個人情報の窃盗を行ったりすることができます。

Next steps

フランスにお住まいの方で、今回の漏洩事件でご自身のデータが流出した可能性があると思われる方は、以下の点にご注意ください。

  • アポロの個人データ削除ページにアクセスし、プロのプロフィールを削除するよう依頼します。
  • 個人用と仕事用のメールアカウント、およびLinkedInアカウントのパスワードを変更します。
  • 強力なパスワードを作成し、それを安全に保管するために、パスワードマネージャーの使用を検討する。
  • すべてのオンラインアカウントで2ファクタ認証(2FA)を有効にする。

フィッシングの可能性のあるメールやテキストメッセージに注意してください。怪しいものをクリックしたり、知らない人に返信したりしないでください。

ロシアのサイバー犯罪のトップ3フォーラムがハッキングされる / Three Top Russian Cybercrime Forums Hacked(転載)


Three Top Russian Cybercrime Forums Hacked krebsonsecurity.com/2021/03/three-…: Three Top Russian Cybercrime Forums Hacked
krebsonsecurity.com/2021/03/three-…

過去数週間の間に、何千人もの経験豊富なサイバー犯罪者にサービスを提供しているロシア語のオンラインフォーラムのうち、最も長く運営され、最も称賛されている3つのフォーラムがハッキングされました。2つの侵入では、攻撃者は、電子メールやインターネットアドレス、ハッシュ化されたパスワードを含むフォーラムのユーザーデータベースを盗み出しました。3つのフォーラムのメンバーは、この事件が、複数の犯罪フォーラムにまたがる同じユーザーの実生活のアイデンティティを接続するための仮想的なロゼッタストーンになるのではないかと心配しています。

火曜日、何者かが何千ものユーザー名、メールアドレス、難読化されたパスワードをダークウェブ上に暴露しました。これは、10年以上にわたり、最も経験豊富で悪名高いロシアのサイバー窃盗団のホストを務めてきた排他的な犯罪フォーラム、Mazafaka (通称 "Maza", "MFclub")から盗んだものと思われます。

オンラインで流出した35ページのPDFのトップには、Mazaの管理者が使用したとされる秘密の暗号化キーがあります。データベースには、多くのユーザーのICQ番号も含まれています。ICQは、"I seek you "としても知られており、JabberやTelegramのようなプライベートネットワークが普及するまでは、このような古い犯罪フォーラムの初期の住人たちから信頼されていたインスタントメッセージのプラットフォームでした。

これは、特定のアカウントに紐付けられたICQ番号は、多くの場合、セキュリティ研究者が複数のアカウントを多くのフォーラムや異なるニックネームで同じユーザーに紐付けるために使用できる信頼性の高いデータポイントであることが多いため、注目すべき点です。

サイバーインテリジェンス企業のインテル471は、流出したMazaデータベースは合法的なものだと評価しています。

"ファイルは3,000行以上で構成され、ユーザー名、パスワードハッシュ、電子メールアドレス、その他の連絡先の詳細が含まれています。" インテル471は、Mazaフォーラムの訪問者が違反の発表ページにリダイレクトされていることを発見したと指摘しています。"流出したデータの初期分析では、流出したユーザー記録の少なくとも一部が当社の保有データと関連していたことから、その信憑性の高さが指摘されています。"

Mazaへの攻撃は、ロシアの犯罪フォーラムが略奪された数週間後に行われました。1月20日、ロシア語フォーラム「Verified」の長年の管理者が、コミュニティのドメイン登録機関がハッキングされ、サイトのドメインが攻撃者の管理するインターネットサーバーにリダイレクトされたことを明らかにしました。

"私たちの[ビットコイン]ウォレットがクラックされてしまいました。幸いなことに、多額の資金を保管していたわけではありませんが、いずれにしても不愉快な出来事です。状況が明らかになると、管理者は、理論的には、フォーラムのすべてのアカウントが侵害された可能性があると仮定しました(確率は低いですが、それはあります)。私たちのビジネスでは、それは安全に遂行する方が良いです。だから、私たちは全員のコードをリセットすることにしました。これは大したことではありません。単純にメモして、これから使うだけです。"

しばらくして、管理人はこう投稿を更新した。

"フォーラムのデータベースがハッキングされた時に 結局 除去されたというメッセージを得ています 全員のアカウントパスワードは 強制的にリセットされた あなたが知ってる人に この情報を渡して下さい フォーラムはドメインレジストラを通してハッキングされました。レジストラが最初にハッキングされた その後 ドメイン名サーバーが変更されて トラフィックを嗅ぎつけられた"

2月15日、管理者は、1月16日から20日の間にVerifiedのドメインレジストラをハッキングしたと主張する侵入者の代理として送信されたとみられるメッセージを投稿した。

"フォーラムの管理者がこの全体のセキュリティで許容できる仕事をしなかったことは、今までに明らかであるべきである "攻撃者は説明した。"ほとんどの場合、怠惰や無能のために、彼らはすべてを放棄しました。しかし、私たちにとっての主な驚きは、クッキー、リファラー、最初の登録のIPアドレス、ログイン分析、その他すべてのユーザーデータを保存していたことです。"

他の情報源によると、ビットコインの入出金に関する情報やJabberのプライベートな連絡先など、検証済みユーザー間の数万通のプライベートメッセージが盗まれたとのことです。

MazaとVerifiedの危殆化、そして3つ目の主要なフォーラムの可能性もあり、多くのコミュニティメンバーは実生活のアイデンティティが暴露されるのではないかと心配しています。Exploit - おそらくVerifiedに次ぐ規模と人気を誇るロシアのフォーラムも今週、明らかな漏洩が発生しました。

Intel 471によると、2021年3月1日、Exploitサイバー犯罪フォーラムの管理者は、同フォーラムが分散型サービス拒否(DDoS)攻撃から保護するために使用していたプロキシサーバーが未知の人物によって侵害された可能性があると主張しました。管理者は、2021年2月27日に監視システムがサーバへの不正なセキュアシェルアクセスとネットワークトラフィックのダンプを検出したと述べています。

一部のフォーラムの狂信者は、これらの最近の妥協は、いくつかの政府のスパイ機関の仕事のように感じると推測しています。

"諜報機関かサーバーの場所を知っている人だけが、このようなことができる "とExploitの大黒柱の一人はつぶやいています。"1ヶ月に3つのフォーラムというのは奇妙なことだ。通常のハッカーではないと思います。誰かが意図的にフォーラムを台無しにしているのです。"

他の人は、どのフォーラムが次に落ちるのか声を大にして疑問に思っており、ビジネスのために悪いかもしれないユーザー間の信頼の損失を嘆いています。

"おそらく、彼らは以下のロジックに従って動作します "とあるエクスプロイトユーザーは書いています。"フォーラムがなくなり、皆の間に信頼関係がなくなり、協力関係が希薄になり、パートナーを見つけるのが難しくなり、攻撃が減る。"

Update, March 4, 6:58 p.58 p.m. ET: Intel 471によると、最近攻撃を受けた第4の犯罪フォーラムがあったとのことです。これらの出来事について彼らが公開したばかりのブログ記事から。"2月には、別の人気のあるサイバー犯罪フォーラム、Crdclubの管理者は、フォーラムが攻撃を受け、その結果、管理者のアカウントが侵害されたと発表しました。そうすることによって、攻撃の背後にある行為者は、フォーラムの管理者によって保証されたとされる送金サービスを使用するために、フォーラムの顧客をおびき寄せることができました。それは嘘であり、フォーラムから流用される未知の金額をもたらしました。フォーラムの管理者は、だまされた人に返済することを約束しました。他の情報は攻撃で危険にさらされたように見えなかった"

インテリジェンスをうまく活用してる犯罪グループの事例(転載)~このメモの画像は中々に勉強になる~



インテリジェンスをうまく活用してる犯罪グループは対処するのがすごく大変そう。そしてこのメモの画像は中々に勉強になる。 《2階○金》《妻50代パート基本的に家》新手プロ窃盗グループの綿密「予習メモ」公開 「家族構成」から「間取り図」も #窃盗団 #文春オンライン bunshun.jp/articles/-/437…: インテリジェンスをうまく活用してる犯罪グループは対処するのがすごく大変そう。そしてこのメモの画像は中々に勉強になる。
《2階○金》《妻50代パート基本的に家》新手プロ窃盗グループの綿密「予習メモ」公開
「家族構成」から「間取り図」も #窃盗団 #文春オンライン bunshun.jp/articles/-/437…

「一家を丸裸にするような内容で、被害者が見たら震え上がるだろう。今の窃盗グループは昔の泥棒とは根本的に違う。高級住宅を狙って綿密に下調べをし、確実に大金を得られるように動いている」

メモには部屋の配置だけでなく、テレビの位置や扉の形状まで


2月にメモを公開した愛知県警の関係者はそう語る。メモには別居する娘が実家に帰る頻度や勤務先、乗っている車の特徴、ナンバーまで書かれていた。間取り図も詳細で、部屋の配置だけでなくテレビの位置や扉の形状まで網羅している。狙っていたのは金庫だろうか。「2階 ○金」という書き込みまであった。



県警は防犯の呼びかけなどを目的に公開したというが、一般人にこうしたプロの手口を防ぐ手立てがあるとは容易に想像しがたい。犯行は、綿密で大胆だ。

公開された資料の中には、押収メモだけでなく犯行グループを映した防犯カメラの映像もある。午前4時、愛知県内の真っ暗な住宅街にヘッドライトを消した1台の白い車が止まる。出てきた2人の男は1軒の豪邸の塀にとりついて中をうかがうと、1分ほどで立ち去った。そこにもまた、犯罪者たちの周到な準備の様子が見て取れる。

「犯行の下見と思われます。人目に付かないように深夜から早朝にかけて行うことが多いようですが、これとは別に昼間の明るい時間にスマホで撮影する場面を映したものもありました」

狙われるのは医者や会社役員、風俗店経営者たち


愛知県は長年、住宅を狙った侵入盗の被害件数が全国ワーストだった。昨年、件数こそワーストを脱却したが、被害総額6億円は全国最多。1件当たりの被害が大きく、それだけ高所得者が被害に遭っている実態がある。

「犯行グループが狙うのは、医者や会社役員、風俗店経営者たちです。所得が高く、自宅に多額の現金や貴金属、高級腕時計などがある場合が多いからでしょう。こうしたリストなどを扱う『情報屋』は闇で出回っている名簿や被害者の関係者や内部からの情報を犯行グループに流し、成果の一部を対価として受け取っているわけです」

投資用マンションや別荘購入者など高所得層が並ぶ名簿は闇で流通し、しばしば振り込め詐欺グループが使うこともある。愛知県警が押収した犯行メンバーのスマートフォンには、情報屋から実行犯に向けたSNSのやり取りも残されていた。

「一軒家80代のばあさん一人暮らし」

「200万で50%ずつです」

「空き案件で東京ですが、誰か行く人いませんか」

窃盗グループはこうした情報をもとに狙いを定め、下見などの準備に入る。使う車には偽造ナンバープレートを取り付け、バールなどの侵入のための工具や目立ちにくい黒の服、連絡用のインカムを用意する。そして実行に移すわけだが、実行犯同士のやり取りもまた生々しい。

「現金の有無とか分かるわけではないから、基本は数をこなさないと(利益は)上がらない」

「北の内偵入っているから市内合流でいい?」

室内で犯行グループとばったり鉢合わせたら……


実際の犯行は、短時間で手際よく済ませることが重要だ。こうしたグループによる事件を分析すると、見張り役が車の中で待機し、侵入役が玄関をバールでこじ開けたり、窓ガラスを割ったりして中に入るケースが大半だという。あとは金庫を丸ごと運び出し、装飾品や腕時計など値の張る小物貴金属をまとめて袋に詰めて逃げるだけだ。

窃盗犯罪の手口に詳しい別の警察関係者は「奴らは綿密で細かい準備をするが、犯行は大胆でもある。警備会社が提供するセキュリティーシステムがあっても平気で侵入する。警報が作動しても短時間でやれば逃げられる。それが一番効果的だと知っているのだろう」とうなる。

こうした手練れのグループは、暴力団と通じているとの指摘もある。そして先のSNSのやり取りにもあったように、利益を得るために次々とターゲットを見つけては組織的に犯行を繰り返す。


定価制フルリフォームプラン『ワンルームリノベ』販売開始(転載)~フルリノベが定額でできるのはイイネ!~


定価制フルリフォームプラン『ワンルームリノベ』販売開始

「人生100年時代」を見据えながら、不動産の資産運用コンサルティングを行う総合不動産商社の株式会社ランドネット(本社:東京都豊島区/代表取締役社長:榮 章博)は、賃貸マンションの空室問題を抱えるオーナー様向けに安心の定価制によるリフォームプラン『ワンルームリノベ150』、『ワンルームリノベ180』を2021年3月2日より販売開始致します。

概要

当プランは、25㎡までのワンルームを対象に、表層や設備交換も含めたフルリフォームを定価制で施工するサービスです。

通常同規模の標準工事費用は250~300万円程度ですが、「ワンルームリノベ150」では定額150万円※1で追加費用も一切発生しないので、賃借人退去時に要する高額な費用負担を軽減することが出来ます。
また「ワンルームリノベ180」では、3点ユニットバスをバストイレ別の仕様にする等、間取りの変更も可能となり用途に合わせたプランを選ぶことが出来ます。

設計・工事・管理を一貫して社内で内製化することで、お客様にとって「安い・安心・丁寧」の信頼と定評を頂いております。今後も企業目標である「不動産流通業を革新する世界No.1企業」を目指し、不動産価値の向上を図るためサービスの拡充に努めて参ります。

【3点ユニットバスを間取り変更した写真イメージ】 ※実際の物とは異なる場合がございます。

【3点ユニットバスを間取り変更した写真イメージ】 ※実際の物とは異なる場合がございます。

『ワンルームリノベ150』 標準仕様

(標準仕様以外はオプションも可能)

玄関
土間: 既存シート剥がしクッションフロア貼
上り框: 塗装仕上げ or 清掃
ドア(内側): 塗装仕上げ or 清掃
玄関収納扉・内部: 塗装仕上げ or 清掃

壁・天井
塗装仕上げ or クロス貼り・デザインクロス(一部)
廻り縁​
塗装仕上げ
巾木

新規ビニル巾木交換 or 塗装仕上げ

室内及び廊下部分: フロアタイル張り
建具
扉・枠: 塗装仕上げ 収納扉・枠: 塗装仕上げ
収納内部: 塗装仕上げ + クロス張り
キッチン
ミニキッチン新設(W=900)
UB
3点式UB(1014サイズ・浴槽・洗面台・便器・鏡)※浴室乾燥機無し
UB枠新設

電気工事
スイッチプレート、コンセントプレート交換、
既存配線切回し 火災報知器(電池式)、インターホン新設
廊下・室内:レール2本、スポット照明4台新設
設備工事
設備交換に伴う、既存給排水管切回し・給湯配管切回し
(既存配管に漏水が無いか確認し、切回し配管を行います。漏水時は別途)
その他
養生 ルームクリーニング 洗濯機パン交換
給湯器交換※給湯専用

ワンルームリノベ150_標準仕様イメージ

ワンルームリノベ150_標準仕様イメージ

ワンルームリノベ150・180の標準仕様イメージ(共通)

ワンルームリノベ150・180の標準仕様イメージ(共通)

ワンルームリノベ180』 標準仕様

(標準仕様以外はオプションも可能)

玄関
土間: 既存シート剥がしクッションフロア貼
上り框: 塗装仕上げ or 清掃
ドア(内側): 塗装仕上げ or 清掃
玄関収納扉・内部: 塗装仕上げ or 清掃
壁・天井
塗装仕上げ or クロス貼り・デザインクロス(一部)
廻り縁​
塗装仕上げ
巾木
新規ビニル巾木交換 or 塗装仕上げ

室内及び廊下部分: フロアタイル張り
建具
扉・枠: 塗装仕上げ 収納扉・枠: 塗装仕上げ
収納内部: 塗装仕上げ + クロス張り
キッチン
ミニキッチン新設(W=900)
UB
2点式UB(1014サイズ・浴槽・洗面台・便器・鏡)※浴室乾燥機無し
UB枠新設
電気工事
スイッチプレート、コンセントプレート交換、
既存配線切回し 火災報知器(電池式)、インターホン新設
廊下・室内:レール2本、スポット照明4台新設
設備工事
設備交換に伴う、既存給排水管切回し・給湯配管切回し
(既存配管に漏水が無いか確認し、切回し配管を行います。漏水時は別途)
その他
養生 ルームクリーニング 洗濯機パン交換
給湯器交換※給湯専用

以下180プランでの追加部分
トイレ

洗浄便座付便器、タオルリング、ペーパーホルダー、トイレ扉新設
収納
クロゼットドア、枕棚、ハンガーパイプ新設
洗濯機置場
洗濯機置場を室内に新設 洗濯機パン新設
間取り変更
ユニットバス解体とクロゼット増設に伴う間取り変更実施

※1 税別価格となっております。2021年4月1日より「総額表示義務」により、プラン名が変わる場合がございます。

ワンルームリノベ180の標準仕様イメージ

ワンルームリノベ180の標準仕様イメージ

会社概要
名称: 株式会社ランドネット
代表者: 代表取締役社長 榮 章博
所在地:東京都豊島区南池袋1-16-15 ダイヤゲート池袋7階
設立:1999年
資本金:1億円
事業内容:不動産投資事業/投資用中古マンションの売買/売買仲介・賃貸・賃貸仲介・賃貸管理/不動産コンサルティング/不動産投資セミナーの開催/不動産賃貸事業/リノベーション事業・リフォーム事業/不動産クラウドファンディング事業
WEBサイト:https://landnet.co.jp
リフォーム・リノベーションサイト:https://landnet.co.jp/reform

タイ国際航空、500億バーツの資金調達と50%の人員削減を目指してリハビリ計画を実施 / Thai Airways Seeks To Raise 50 Billion Baht And Reduce Staff By 50% Through Rehabilitation Plan(転)

Thai Airways Seeks To Raise 50 Billion Baht And Reduce Staff By 50% Through Rehabilitation Plan
:

タイ国際航空は今週、債権者に事業再生計画を提出し、コスト削減策と、早期退職募集や運営コストの支払いのために金融機関から500億バーツを調達する意向を明らかにした。

タイは債権者に債務削減を提案しておらず、代わりに3年間の借金返済モラトリアムを提案しています。

今は債権者に債務減免を求める代わりに、タイ航空はさらに500億バーツ(約16.5億米ドル)もの借金を背負い、3年後には奇跡的に返済して黄金時代を迎えようと計画しています。

今週のバンコクポスト紙がこれらの計画について報じたとき、それはほとんどパロディのように聞こえました。

タイ航空インターナショナル(THAI)は、財政的に苦戦しているフラッグキャリアが火曜日に事業再生計画を提出したことから、今後2年間で約500億バーツの資金調達を計画しているという。

タイ航空の財務経理部のチャイ・エームシリ副社長代行は、運営費や退職した従業員への補償のために、今年6月までに300億バーツの初期資金を調達しなければならないと述べた。

この資金は、金融機関からの借入、投資先を探す、あるいは負債から株式への転換によって調達することができる、と同氏は述べています。

再生計画をめぐる債権者との交渉では、債権者が再生計画を承認しないことを恐れて、同社は債務削減を求めていない。その代わりに、タイ航空は3年間の債務のモラトリアムを求めており、その後は債務を返済していくとチャイ氏は述べた。

タイ航空のチャンシン・トレヌチャグロン社長代行は、同社の再生計画を法務執行部に提出したところ、負債額は約4100億バーツ、債権者は合計1万3000人に上ったという。

タイ航空の債権者は5月12日に再生計画の採決を行い、過半数の債権者が賛成すれば、中央破産裁判所に提出され、検討されるとチャンシン氏は述べている。

裁判所は6月から7月の間に承認するかどうかを決定する見込みであると、彼は計画が承認された場合、同社は計画に沿って事業を行うと付け加える前に言った。

同氏によると、タイ航空の会社自体もダウンサイジングを行っており、2019年には約29,000人の従業員が現在21,000人にまで減少しているという。

また、今年は6,000人から7,000人の従業員が相互分離計画に参加する予定で、これにより、同社の今後の事業計画に適した年内に約14,000人から15,000人の従業員を削減することになるとシャンサン氏は述べている。

これを踏まえ、再生プランナーは航空機リース会社である債権者とリアルタイムの利用状況に応じて柔軟にリース料を交渉してきた。これにより、タイ航空は効率的なコスト削減が可能になるとチャンシン氏は述べた。

従業員の数を50%削減することは、彼らのスタッフの数がいかに長年にわたって膨れ上がっていたかを示しています。これは主に地上スタッフに関係していますが、年配の客室乗務員や、勤務時間が大幅に短縮されたパイロットも含まれています。要するに、タイ航空は、特定のコネを持つ多くの人々の駐車場としてしばしば利用されてきた会社であり、雇用状況に関して言えば、まだ切り詰めるべき脂肪がたくさんあります。楽な仕事が必要ですか?タイ航空に影響力のある人を知っていればラッキーです。

管財手続き中のタイ航空が今の状況(4,100億バーツの借金)で、債権者に債務削減を求めないというのは、絶対にクレイジーなことです。それはむしろ、タイの特定の影響力のあるビジネスパーソンや機関が、タイ航空との債務を帳消しにすることを余儀なくされた場合、自分たちの帳簿上で大きな損失を被らないように保護するための意図のように聞こえる。

もし債権者が本当にカットを受けたくないのであれば、もう一度リストラをしてさらに借金を背負うのではなく、破産裁判所でチャンスを掴んで、会社全体を再スタートさせた方がいいと思います。

金融機関は、政府が保証しない限り、タイ航空にこれ以上お金を貸すことはないだろう。タイ航空は、一部の株式の所有権を移転した後、もはや国営企業ではありません。

まだ15,000人以上の従業員が、航空会社に依存していることを忘れないようにしましょう。

結論

タイ航空とその財政難の話は終わりのない武勇伝になりつつあり、航空会社の倒産やリストラには通常時間がかかりますが、昨年の春以来、ほとんど達成されていません。この「再生計画」は、名前の約束とは全く違います。タイ航空が今抱えている最も根本的な問題である負債を減らすことはできません。

世界中のあらゆるリストラを行っても、同社は蓄積された借金の山を返済することができないだろう。どちらにしてもビジネスにならない今のうちにこのことを認識し、債務を大幅にカットするか、会社を清算することで航空会社の財務をリセットすることが正しいことだろう。私は破産裁判所がこの計画を実行不可能なものとして却下することを期待している。

電子機器大手のAcer、ランサムウェア攻撃で情報を盗取され、5,000万米ドルの身代金を請求される / Electronics Giant Acer Hit by $50 MIllion Ransomware Attack(転載)

Electronics Giant Acer Hit by $50 MIllion Ransomware Attack:

 REvilと呼ばれるランサムウェア・ギャングは、コンピュータ大手のAcerから機密ファイルを盗み出し、5,000万米ドルという前代未聞の身代金を要求しました。このグループは、台湾企業のネットワークに侵入したことを証明するために、盗んだとされる表計算ソフト、銀行残高、銀行のメールなどの画像をネット上に掲載しました。

セキュリティ研究者によると、ハッカーはMicrosoft Exchangeの脆弱性を悪用して同社のネットワークに侵入した可能性があるとのことです。カロー氏によると、Acer社の5,000万ドルの要求は、公になっている身代金要求としては過去最大のもので、REvilがニッキー・ミナージュ、マライア・キャリー、レブロン・ジェームズなどを顧客に持つ著名な法律事務所Grubman Shire Mieselas & Sacks社に要求した4,200万ドルよりも大きいという。

この状況について尋ねられた際、Acerはランサムウェアによる攻撃であることを認めず、Bleeping Computer社の声明の中で "最近観測された異常な状況を複数の国の関連する法執行機関およびデータ保護当局に報告した "とだけ答えました。さらなる詳細を求めたところ、エイサーは "現在進行中の調査があり、セキュリティのために詳細についてはコメントできない "と答えた。

Record誌の報道によると、Acerの名前は、ランサムウェアグループ「REvil」の恐喝料を支払わない企業のリストに掲載されていました。マルウェア・インテリジェンス・アナリストのMarcelo Rivero氏の協力を得て、Record社は同グループの別のダークウェブポータルを追跡することに成功しました。このポータルには、同グループがAcer社に要求している5,000万ドルの身代金と、同社の代表者とのコミュニケーションに使用しているオンラインチャットが明確に表示されていました。

攻撃の前に、アドバンスド・インテルのAndarielサイバーインテリジェンス・プラットフォームは、REvilギャングが最近、エイサーのドメインにあるMicrosoft Exchangeサーバーを標的にし、ProxyLogonの脆弱性を利用してランサムウェアをインストールしたことを検出しました。

マレーシア航空、フリークエントフライヤーのデータが9年間流出 / Malaysia Airlines Frequent Flyers Data Exposed in Nine-Year Breach(転載)

malaysia-1-1000x600.jpg

Malaysia Airlines Frequent Flyers Data Exposed in Nine-Year Breach
:

マレーシア航空のマイレージプログラム「エンリッチ」の会員が、2010年3月から2019年6月の間のどこかで個人情報が流出した可能性があると警告されている。同航空会社は、未知数のフライヤーの名前や生年月日、連絡先などが流出した可能性があると発表した。

2010年3月から2019年6月までの間のどこかでマレーシア航空のエンリッチプログラムの会員だった場合、個人を特定できる情報が漏洩した可能性があると航空会社は述べています。Channel Asiaによると、航空会社は現在、最大9年間続いた可能性のあるデータ侵害を公開しているという。

曝露データには、氏名、生年月日、ステータス、連絡先が含まれています。

報告書によると、フライヤーの身元の重要な詳細が期間中にハッカーに暴露された可能性があるという。そのデータには、以下のようなものが含まれています。

  • 会員氏名
  • 生年月日
  • 性別
  • 連絡先情報
  • フリークエントフライヤー番号
  • フリークエントフライヤーエリートのステータス
  • ロイヤリティ層のレベル情報

しかし、航空会社によると、ハッカーに旅程情報が流出したことはなかったという。また、予約、発券情報、身分証明書、クレジットカード情報はすべて安全に保たれていた。

航空会社は、今回のデータ流出によって影響を受けた可能性のあるフライヤーの数については明言していない。メディアの声明では、航空会社は、盗まれたデータがフライヤーに悪用されたとは考えていないとしています。エンリッチの会員には、2021年3月1日(月)に送信された電子メールで初めて侵害の事実が知らされました。

"マレーシア航空は、個人情報が悪用されたという証拠はなく、今回の事件ではアカウントのパスワードも開示されていません。"と、航空会社の声明文は、チャンネル・アジアによると読み上げられています。"それにもかかわらず、エンリッチ会員には、予防措置としてアカウントパスワードの変更を奨励しています。今回の事件は、マレーシア航空自身のITインフラやシステムに影響を与えるものではなかった"

データ侵害が大手ロイヤリティプログラムを悩ませ続ける

ロイヤリティプログラムは、個人情報を盗むために使用できる多くのデータポイントが含まれているため、ハッカーの主要な標的となり続けています。とはいえ、データ侵害の犠牲者は航空会社だけではありません。2020年3月、マリオット リワードはデジタル攻撃を受け、500万人以上のフライヤーの情報が流出したと発表しました。

インターンの設定ミスがSolarWinds侵害の原因か / Former SolarWinds CEO blames intern for 'solarwinds123' password leak(転載)

インターンの設定ミスがSolarWinds侵害の原因か
Former SolarWinds CEO blames intern for 'solarwinds123' password leak

SolarWindsの現在および元トップ幹部は、明らかに何年も診断されなかったパスワードセキュリティの重大な過失について、会社のインターンを非難しています。

問題のパスワード「solarwinds123」は、2019年に公開されたインターネット上で、独立したセキュリティ研究者によって発見されたもので、この漏洩によってSolarWindsのファイルサーバーが公開されたと同社に警告を発した。

複数の米国の議員が金曜日、下院の監督委員会と国土安全保障委員会の合同公聴会で、パスワードの問題でSolarWindsを怒鳴りつけました。

"私は子供がiPadでYouTubeを見過ぎないように、『solarwinds123』よりも強力なパスワードを持っています」とKatie Porter議員。"あなたとあなたの会社は、ロシア人が国防省の電子メールを読むのを防ぐことになっていました!"

マイクロソフトのブラッド・スミス社長は、金曜日の公聴会でも証言していたが、その後、国防総省が実際にロシアのスパイ活動の影響を受けたという証拠はないと述べた。マイクロソフトは、ハッキングキャンペーンのフォレンジック調査を主導してきた企業の一つです。

"私の知る限りでは、国防総省が攻撃を受けたという証拠はない "とスミス氏はポーター氏に語った。

SolarWindsの代表者は金曜日に、パスワードの問題が報告されるとすぐに、数日以内に修正されたと議会関係者に話しました。

新しいCISベンチマークでセキュアなクラウド製品・サービスを実現 / Secure Cloud Products and Services with New CIS Benchmarks(転載)

Blog | Secure Cloud Products and Services with New CIS Benchmarks:

クラウドは、クラウドサービスプロバイダ(CSP)が絶えず新製品やサービスを導入し、拡大を続けています。CISは、これらの機能をクラウドで安全に保護するためのより多くのリソースを提供しています。『The Beginner's Guide to Secure Cloud Configurations』では、ユーザーがパブリッククラウドのアカウント、製品、サービスなどを安全に保護する方法を説明しています。

CISベンチマーク・コミュニティからの新しいガイダンス

CISは、有志のネットワークに呼びかけて、パブリック・クラウドのガイダンスを拡大してきました。この取り組みの結果、CISはクラウドのCSP製品やサービスに特化したベンチマークを作成することができました。

CIS は、リソースを磨き、独自のサービスごとに CIS ベンチマークを作成するのではなく、CSP に倣い、CSP の製品ごとにサービスを分類した。その代わりに、CISはCSPに倣い、CSPの製品ごとにサービスをグループ化しました。各CSPは数十の製品を提供しており、提供する機能に基づいてクラウドサービスをグループ化しています。

3つのレベルのCISクラウドベンチマーク

このガイドでは、クラウドに適用可能な3つのCIS Benchmarkカテゴリを紹介しています。

  1. CIS Foundations Benchmarks
  2. Cloud product-level CIS Benchmarks
  3. Standalone cloud service CIS Benchmarks

各ベンチマークレベルでは、CIS Foundations Benchmarksから始まり、CIS Hardened Imagesを介して仮想マシンのセキュリティを確保することで、セキュリティの追加レイヤーを提供しています。

CIS-Foundations_Benchmarks-Products_and_Services.png

  1. CIS Foundations Benchmarks は、パブリック・クラウドで安全に構成するためのアカウントレベルの出発点を提供します。これらのリソースは、アイデンティティとアクセス管理、ログと監視、ネットワークなどをカバーしています。基礎的なガイダンスは、AWS、Azure、Google Cloud Platform、Oracle Cloud、IBM Cloud、およびAlibaba Cloudで利用可能です。

  2. Cloud product-level CIS Benchmarksは、CSPの製品およびサービス構成のガイダンスを提供し、コンピュート、データベース、ストレージ、コンテナなどの分野が含まれています。これらのCISベンチマークにより、ユーザーは該当するクラウドサービスを選択し、環境に応じてクラウドを構成することができます。製品レベルのCISベンチマークは、クラウドアカウント内で使用されるクラウドサービスに組み込まれたセキュリティの追加レイヤを提供することで、CIS Foundations Benchmarksを補完します。

  3. Standalone cloud service CIS Benchmarksは、より広範な構成ガイダンスを必要とするCSPサービスに特化したものである。これらの場合、製品レベルのCISベンチマークにはサービスのセクションがあり、サービスのスタンドアロンCISベンチマークを指し示します。

CIS AWS End User Compute and Kubernetes Benchmarks

クラウド製品レベルのCISベンチマークの第一弾としてリリースされたのが、CIS AWS End User Compute Services Benchmarkです。これには、Amazon WorkSpaces、Amazon WorkDocs、Amazon AppStream 2.0、Amazon WorkLinkの構成推奨が含まれています。ユーザーは、該当するサービスを選択し、自分の環境で稼働しているものに合わせて構成することができます。

CIS-AWS_End_User_Compute_Services_Benchmarks-Cloud_Products.png

場合によっては、サービスに必要な設定が、1つのクラウドサービスに特化したCISベンチマークを必要とすることがあります。この場合、製品レベルのCISベンチマークには、クラウドサービスのセクションが含まれますが、サービスのための別のCISベンチマークを指すことになります。スタンドアロン型のクラウドサービスのCISベンチマークの例としては、CIS Kubernetesベンチマークがあります。

CIS-Amazon_Elastic_Kubernetes_Service_Benchmark-Cloud_Services.png

CIS currently offers multiple CIS Benchmarks for Kubernetes:

  • Amazon Elastic Kubernetes (EKS)
  • Google Kubernetes Service (GKE)
  • Oracle Container Engine for Kubernetes (OKE)

CISは、Azure Kubernetes Service、Alibaba Kubernetes、Red Hat OpenShift KubernetesのCIS Benchmarksを今後数ヶ月のうちにリリースする予定です。

Secure Configurations with CIS Hardened Images

仮想イメージは、物理コンピュータと同じ機能を提供する仮想マシン(VM)のスナップショットです。仮想イメージはクラウド上に存在し、ユーザーはローカルのハードウェアやソフトウェアに投資することなく、日常的なコンピューティング操作をコスト効率よく実行することができます。

ハードニングとは、システムをサイバー攻撃に対して脆弱にする潜在的な弱点を制限するプロセスです。標準イメージよりも安全性の高いハードニングされた仮想イメージは、システムの脆弱性を軽減し、マルウェア、不十分な認証、およびリモートからの侵入からシステムを保護します。

CIS-Hardened_Images-Products_and_Services.png

安全に構成されたCIS Hardened Imagesは、クラウド上でのOSのセキュリティ確保を支援します。CIS Hardened Imagesは、CIS Benchmarksの要件を満たしており、4つの主要なクラウドコンピューティングマーケットプレイスで利用できます。AWS、Azure、Google Cloud Platform、Oracle Cloudの4つの主要なクラウド・コンピューティング・マーケットプレイスで利用できます。

Additional Layers of Cloud Security

CISは、CSPと直接協力して、各プラットフォームで最も利用されているクラウド製品やサービスを特定します。その情報をもとに、今後のCISベンチマークの開発計画を策定していきます。

すべてのCIS Benchmarksの推奨事項は、他のガイドラインや追加リソースを参照しています。これらのクラウドガイドにより、CISは、CIS BenchmarksとCSPの文書との関係を示している。その意図は、CSP が提供するガイダンスを、セキュリティの面でもそうでない面でもユーザに知らせることにある。この文書は、ユーザが、サービスを実行する際に、CSP が負う責任と、それを支援する責任を認識するのに役立つ。

クラウドの拡大が急速に進むということは、それだけ多くの製品やサービスが間もなく登場することを意味しています。CISは、CSPと緊密に連携して、開発の一歩先を行くようにしています。これにより、グローバル・ユーザー・コミュニティにコストをかけずに、タイムリーで効果的なガイダンスを提供することを計画しています。

バックアップ

NSA、ゼロトラストセキュリティモデルに関するガイダンスを発表 / NSA Releases Guidance on Zero Trust Security Model(転載)


NSA Releases Guidance on Zero Trust Security Model:

ゼロ・トラスト・セキュリティ・モデルの採用

エグゼクティブサマリー

サイバーセキュリティの専門家が、ますます分散した複雑な企業ネットワークを高度なサイバー脅威から守るためには、ゼロトラストのセキュリティモデルと、ゼロトラストの原則に基づいて設計されたシステムを展開し、運用するために必要な考え方を採用することで、機密データ、システム、およびサービスを安全に保護することができるようになります。

ゼロトラストは、従来のネットワークの境界線の内側と外側の両方に脅威が存在することを認識した上で、セキュリティモデル、一連のシステム設計原則、および協調的なサイバーセキュリティとシステム管理戦略です。ゼロトラストのセキュリティモデルでは、1つの要素、ノード、またはサービスに対する暗黙の信頼を排除し、代わりに、アクセスやその他のシステムの反応を決定するために、複数のソースから供給されるリアルタイムの情報を介して、運用状況を継続的に検証することを要求します。

ゼロ・トラスト・セキュリティ・モデルでは、違反は避けられないか、すでに発生している可能性が高いと想定しているため、常に制限をかけています。必要なものだけにアクセスし、異常な活動や悪意のある活動を探します。ゼロトラストは、包括的なセキュリティを組み込んでいます。監視、粒度の高いリスクベースのアクセス制御、およびシステム・セキュリティの自動化を、すべての 動的な脅威の中で、重要な資産(データ)をリアルタイムで保護することに集中するために、インフラストラクチャの側面に注目しています。環境を提供します。このデータ中心のセキュリティモデルでは、最小特権アクセスの概念をすべてのアクセスに対して適用することができます。

ゼロトラストの原則を用いて設計されたシステムは、既存の脅威に対処するために、より良い立場にあるはずですが、そのようなシステムに移行するには、途中でセキュリティ態勢を弱めないように、慎重な計画を立てる必要があります。

リスクを最小限に抑え、ロバストでタイムリーな対応を可能にするためには、ゼロトラストの原則とコンセプトがネットワークとその運用エコシステムのほとんどの側面に浸透していなければなりません。 最高経営責任者からエンジニア、オペレータに至るまで、組織はゼロ・トラストの道に乗り出す前に、ゼロ・トラストの考え方を理解し、それにコミットしなければなりません。

以下のサイバーセキュリティガイダンスでは、ゼロトラスト・セキュリティモデルとその利点、および導入のための課題について説明しています。詳細な戦略を構築し、必要なリソースを投入し、実装を成熟させ、望ましい結果を得るためにゼロ・トラスト・モデルに全面的にコミットすることの重要性を論じています。以下の推奨事項は、この最新のサイバーセキュリティモデルの採用を検討しているサイバーセキュリティリーダー、企業のネットワーク所有者、管理者を支援するものです。

Falling behind

今日のIT環境は、接続性、ユーザーの多様性、豊富なデバイス、グローバルに分散されたアプリケーションやサービスにより、悪意のある活動の影響を受けやすくなっています。システムとユーザーは、悪意のある行為者を遠ざけつつ、組織のリソースに接続して相互作用するためのシンプルで安全な方法を必要としています。現在および新興のクラウド、マルチクラウド、ハイブリッドネットワーク環境の複雑さが増していることに加えて、敵の脅威が急速にエスカレートし、進化していることから、従来のネットワークサイバーセキュリティ防御の有効性の欠如が露呈しています。従来の境界線ベースのネットワーク防御は、何層にもわかれたセキュリティ技術で構成されていますが、現在の脅威環境のため、サイバーセキュリティのニーズを満たすことができないことが証明されています。サイバー犯罪者から国家権力者に至るまで、現代の脅威行為者は、より執拗で、よりステルス性が高く、より繊細になってきている。規則性があります。これらの脅威行為者は、インサイダーの脅威行為者と同様に、そのアクセスを利用して国家や経済の安全保障を脅かし、危害を加えることに成功しています。最も熟練したサイバーセキュリティの専門家であっても、分散した企業ネットワークをこれまで以上に洗練されたサイバー脅威から守ることは困難です。組織は、インフラストラクチャを保護し、データ、サービス、アプリケーション、およびインフラストラクチャへの統一的かつ粒度の高いアクセス制御を提供するためのより良い方法を必要としています。

複数の視点からの可視性を統合し、リスクを考慮したアクセス決定を行い、検出と対応のアクションを自動化する最新のサイバーセキュリティ戦略を実装することで、ネットワーク防御者は、機密データ、システム、アプリケーション、およびサービスを安全に保護するために、はるかに優れた立場に立つことができるようになります。ゼロトラストは、サイバーセキュリティのアーキテクト、インテグレータ、実装者が、異なるが関連するサイバーセキュリティ機能を統合して、サイバーセキュリティの意思決定のためのまとまりのあるエンジンに統合する際の指針となることを目的とした「想定違反」セキュリティモデルです。しかし、完全に効果を発揮するためには、ゼロ・トラストの原則をネットワークとその運用エコシステムのほとんどの側面に浸透させ、リスクを最小限に抑え、ロバストでタイムリーな対応を可能にする必要があります。ゼロ・トラスト・ソリューションへの移行を選択した組織は、このセキュリティモデルと、このセキュリティモデルの下でサイバーセキュリティを達成するための計画、資金調達、運用に必要な考え方を完全に受け入れるべきです。

Increasingly sophisticated threats

ゼロトラスト・セキュリティモデルを採用し、このセキュリティモデルに基づいて既存の情報システムを再構築する。は戦略的な取り組みであり、完全な利益を得るまでには時間がかかる。新しい敵対ツールへの戦術的な緩和対応ではありません。戦術、および技術。しかし、最近のいくつかの非常に公開されたシステム侵害は、広範囲に及ぶ システムの脆弱性、システム管理や防御的なネットワーク運用の欠陥などがあります。これらの 事件は、純粋に戦術的な対応では不十分な場合が多いことを示しています。成熟したゼロトラスト環境では サイバーセキュリティの防御者は、新たな脅威行為者を検出する機会を増やし、迅速に対応できる選択肢を増やすことができます。洗練された脅威に対処するために配備されています。ゼロトラストの運用を成功させるために必要なマインドセットの採用 このような環境では、サイバーセキュリティの防御者は、これまで以上に微妙な脅威の指標を認識することができるようになるでしょう。戦術的な ゼロトラスト環境であっても、適切なセキュリティモデル、マインドセットがあれば、対応が必要になる可能性が高い。と応答ツールを使用することで、防御者はますます高度化する脅威に効果的に対応できるようになります。

What is Zero Trust?

ゼロトラストは、セキュリティモデル、システム設計の原則、および協調的なサイバーセキュリティとシステムのセットです。ネットワークの内外を問わず脅威が存在することを認識した管理戦略 の境界線を越えてはいけないという前提に疑問を投げかけます。ゼロトラストは、ユーザー、デバイス、ネットワークコンポーネントが ネットワーク内の位置情報に基づいて暗黙のうちに信頼されています。ゼロトラストは、包括的なセキュリティ監視を実現します。粒度の高い、動的でリスクベースのアクセス制御、システムセキュリティの自動化を、ネットワーク全体で協調的に実施します。インフラストラクチャのすべての側面で、重要な資産(データ)をリアルタイムで保護することに特化しています。動的な脅威環境。このデータ中心のセキュリティモデルでは、最小特権アクセスの概念を適用することができます。誰が、何を、いつ、どこで、どのようにして、どのようにして、という質問への回答が、あらゆるアクセスの意思決定のための重要な鍵となります。

NSA は、国家安全保障システム(NSS)、国防総省(DoD)ネットワーク、および防衛産業基地(DIB)システムを含む重要なネットワークに対して、ゼロトラスト・セキュリティモデルを検討することを強く推奨しています。これらの原則を特定の環境、特に大企業内で統合することは、複雑になる可能性があります。これらの課題に対処するために、NSA は、ゼロトラスト設計アプローチを整理、指導、簡略化するための追加のガイダンスを開発しています。

Adopt a Zero Trust mindset

現代のダイナミックな脅威環境に適切に対処するためには、以下のことが必要です。

  • 協調的かつ積極的なシステム監視、システム管理、防御的運用能力。
  • 重要なリソースへのすべての要求とすべてのネットワークトラフィックが悪意のあるものである可能性があることを想定しています。
  • すべてのデバイスとインフラストラクチャが危険にさらされている可能性があることを想定する。
  • 重要なリソースへのすべてのアクセス承認にはリスクが伴うことを受け入れ、迅速な損害評価、制御、復旧作業を実行できるように準備していること。

Embrace Zero Trust guiding principles

ゼロトラストソリューションには、以下のような運用能力が必要です。

  • 信用してはいけない、常に確認すること:すべてのユーザ、デバイス、アプリケーション/ワークロード、データフローを信頼できないものとして扱う。動的なセキュリティポリシーを使用して、必要最小限の権限で認証し、明示的に権限を付与する
  • 違反を前提とする:敵対者がすでに環境内に存在することを前提に、意識的にリソースを運用し、防御する。デフォルトで拒否し、すべてのユーザー、デバイス、データフロー、アクセス要求を精査する。すべての構成変更、リソースアクセス、ネットワークトラフィックをログ、検査し、継続的に監視して、不審な活動がないかどうかを確認します。
  • 明示的な検証:すべてのリソースへのアクセスは、複数の属性(動的および静的)を使用して、一貫性のある安全な方法で実施され、リソースへの文脈に基づくアクセス決定の信頼度を導き出すべきである。

Leverage Zero Trust design concepts

ゼロトラストソリューションを設計する場合

  • ミッションの成果を定義する:重要なデータ/アセット/アプリケーション/サービス(DAAS)を特定する組織固有のミッション要件からゼロトラストアーキテクチャを導き出します。
  • 内側から設計:まず、重要なDAASを保護することに集中してください。第二に、それらにアクセスするためのすべてのパスを保護します。
  • アクセス制御ポリシーを作成するためにDAASへのアクセスを必要とする人/物を決定する:セキュリティポリシーを作成し、すべての環境(LAN、WAN、エンドポイント、境界線、モバイルなど)に一貫して適用する。
  • 行動する前にすべてのトラフィックを検査し、ログを取る:エンドポイントとネットワークからすべてのレイヤーにわたるすべてのアクティビティの完全な可視性を確立し、疑わしいアクティビティを検出できる分析を可能にします。

Examples of Zero Trust in use

ゼロトラストの基本的な目的は、ユーザー、プロセス、およびデバイスがどのようにして データ、ユーザー、デバイス、およびその他のセキュリティ関連のコンテクスト情報の組み合わせ(例えば、位置情報、時刻 日、ユーザーまたはデバイスの以前のログに記録された動作)をアクセス決定に使用することをタプルと呼びます。の一部として このタプルの中に信頼できる情報を持つためには、ユーザとデバイスの両方の明示的な認証が必要です。このタプルには ゼロトラスト決定エンジンは、アクセス要求のタプルを検査し、データのセキュリティポリシーと比較します。または要求されているリソースにアクセスすることができます。そして、アクセスを許可するかどうかをリスクを考慮した上で決定し、以下のログエントリを送信します。そのアクセス要求と決定が将来の不審な活動分析の一部になるようにします。このプロセスは、すべての 各センシティブなリソースへの個別のアクセス要求が可能であり、拡張アクセスの間も定期的に繰り返されます。

以下に、成熟したゼロトラスト実装が、従来のアーキテクチャが通常可能な場合よりも悪意のある活動を検出することができるいくつかの例を示します。

Compromised user credentials

この例では、悪意のあるサイバー・アクターが正当なユーザーの資格情報を侵害して 組織のリソースを使用しています。この場合、悪意のある行為者は不正なデバイスを使用しており、リモートアクセスや不正なデバイスを使って組織の無線LANに接続しています。従来のネットワークでは、ユーザーの資格情報だけでは 多くの場合、アクセスを許可するには十分ですが、ゼロトラスト環境ではデバイスが知られていないため、認証に失敗します。と認証チェックを行うため、アクセスが拒否され、悪意のある活動がログに記録されます。さらに、ゼロトラストでは ユーザーとデバイスのアイデンティティのための強力な認証 ユーザーの強力な多要素認証を使用することで ゼロトラスト環境で推奨されている、ユーザーの資格情報を盗むことをそもそも難しくすることができます。

Remote exploitation or insider threat

この例では、悪意のあるサイバーアクターが、インターネットベースのモバイルコードを悪用してユーザーのデバイスを侵害しています。あるいは の場合、アクターは悪意のある内部の認可されたユーザです。典型的な、ゼロトラストではないシナリオでは、アクターは ユーザーの資格情報を取得し、ネットワークを列挙し、特権を昇格させ、ネットワークを介して横方向に移動して危殆化させます。膨大なデータを蓄積し、最終的には永続化します。ゼロ・トラスト・ネットワークでは、侵害されたユーザの資格情報とデバイスの は、証明されるまではすでに悪意のあるものとみなされ、ネットワークはセグメント化されているため、列挙と 側方移動の機会。悪意のある行為者はユーザーとデバイスの両方として認証することができますが、その一方で データは、セキュリティポリシー、ユーザの役割、ユーザとデバイスの属性に基づいて制限されます。成熟したゼロトラスト 環境では、データの暗号化とデジタル著作権管理により、どのデータが使用できるかを制限することで、さらなる保護を提供することができます。また、アクセスが許可されていた場合でも、機密データにアクセスされた場合の対処方法を説明しています。さらに、分析的な 機能は、アカウント、デバイス、ネットワークアクティビティ、データアクセスの異常なアクティビティを継続的に監視します。検知されている間は このシナリオでは、このレベルの侵害が発生した場合、被害は限定的であり、防御システムが検出して開始するまでの時間は 適切な緩和対応が大幅に減少する。



Compromised supply chain

この例では、悪意のある行為者が悪意のあるコードを一般的な企業のネットワークデバイスやアプリケーションに埋め込みます。この例では、悪意のあるアクターは デバイスまたはアプリケーションは、ベストプラクティスに従って、組織のネットワーク上で保守され、定期的に更新されます。従来のネットワーク・アーキテクチャでは、このデバイスやアプリケーションは内部にあり、完全に信頼されています。このタイプの ゼロトラストの成熟した実装では、暗黙のうちに信頼されているため、妥協は特に深刻なものになる可能性があります。アーキテクチャを採用することで、デバイスやアプリケーションが本質的に 信頼されています。その特権とデータへのアクセスは厳重に管理され、最小限に抑えられ、監視されます。マイクロ)はポリシーによって実施され、異常な活動を監視するために分析が使用されます。さらに デバイスが署名されたアプリケーションの更新プログラムをダウンロードできる可能性があります (悪意があるかどうか)、デバイスの許可されたネットワーク接続 に接続しようとすると、ゼロトラスト設計ではデフォルトによる拒否のセキュリティポリシーが採用されるため、他のリモートの アドレスがブロックされる可能性があります。また、ネットワーク監視によって 許可されたアクセス要求に関連付けられていないデバイスまたはアプリケーションからの横方向の移動

Zero Trust maturity

ゼロトラストの導入には時間と労力がかかります。多くのネットワークでは、既存の インフラストラクチャを活用し、ゼロトラストの概念を組み込むために統合することができますが、成熟したゼロトラストへの移行が必要となります。トラストアーキテクチャでは、ゼロトラスト環境のメリットをフルに享受するために、追加の機能が必要になることがよくあります。移行 を成熟したゼロトラストアーキテクチャに一度に変更する必要はありません。ゼロトラストの機能を段階的に を戦略計画の一部として活用することで、各段階でそれに応じてリスクを低減することができます。ゼロトラストの実装が時間の経過とともに成熟していくと 可視性を高め、自動化された対応により、防御者は脅威に追いつくことができるようになります。

NSA は、ゼロトラストの概念を既存の環境にどのように統合するかを検討する際には、ゼロトラストのセキュリ ティモデルを採用することを推奨している。ゼロトラストの取り組みは、初期準備から基本、中間、上級の段階まで、継続的に成熟していくロードマップとして計画され、サイ バーセキュリティの保護、対応、運用は時間の経過とともに改善されていくべきである。


Potential challenges on the path to Zero Trust

企業ネットワークにゼロトラストを導入する際には、いくつかの課題が発生する可能性があります。のソリューションを提供します。最初の潜在的な課題は、企業全体での完全なサポートが不足していることです。管理者、ユーザーのいずれかが、ゼロトラストを実現するために必要な考え方を完全に受け入れなければなりません。ゼロ・トラストに必要な考え方は、どのようなソリューションも成功させるために完全に受け入れなければなりません。もし 管理者やネットワークディフェンダーがそうしないと、リーダーは構築と維持のために必要なリソースを使いたくありません。賛同者や必要な専門知識がない場合や、ユーザーがポリシーを迂回することが許されている場合、ゼロトラストのメリットは は、その環境では実現できません。基本的な、あるいは中間的なゼロ・トラスト機能でさえも、いったん ネットワークを利用しているため、実装を成熟させ、十分な利益を得るためには、フォロースルーが必要です。

ゼロ・トラストの概念を環境全体に適用する必要性が広まっているため、機能のスケーラビリティが不可欠です。以前は各アクセスに対して一度しか発生しなかったアクセス制御の決定が、リソースへのアクセスが使用されると継続的に実行されるようになるため、これらのアクセス決定を行い、強制し、ログに記録するための堅牢なインフラストラクチャが必要になります。さらに、データタグや追加のネットワークセンサーなど、これまでアクセス制御の決定に含まれていなかったネットワークの要素が、信頼性と一貫した使用が必要とされる重要な要素になる可能性があります。

マインドセットを継続的に順守し、ゼロトラストセキュリティモデルを長期的に適用することも重要な要件です。管理者や防御者は、デフォルトディニーのセキュリティポリシーを常に適用し、常に違反が発生していると仮定することに疲れてしまうかもしれませんが、ゼロトラストのアプローチが失敗した場合、サイバーセキュリティのメリットが著しく低下したり、排除されたりします。

Carefully minimizing embedded trust empowers a more secure mission

ネットワーク環境がますます複雑化していることと、それを危うくする敵対者の能力には、以下のような対策が必要になります。防御の焦点を変更します。ゼロトラストの考え方では、信頼を排除することで重要なデータとアクセス経路の安全性を確保することに焦点を当てています。可能な限り、すべての許可されたアクセスを検証し、定期的に再検証します。しかし、ゼロ 信頼は軽々しく引き受けてはならず、達成するためには多大な資源と粘り強さが必要になります。適切に ゼロトラストが完全に実装されていれば、侵入の防止、検出、阻止をより速く、より確実に行うことができるようになります。従来のあまり統合されていないサイバーセキュリティのアーキテクチャやアプローチよりも効果的です。

バックアップ

元SKE48メンバーら逮捕 投資助言詐欺疑い(転載)~SKE48は知らないが、自身の経験から保険の重要性を説く立派な卒業生もいれば、詐欺に勤しむカスな卒業生もいる~


為替相場の変動を予想して投資する金融商品「バイナリーオプション」の助言名目で金をだまし取ったとして、愛知県警は16日、詐欺や特定商取引法違反(不実告知)などの疑いで、アイドルグループ「SKE48」元メンバーの無職、山田樹奈(じゅな)容疑者(22)=名古屋市中区=ら男女4人を逮捕した。

 他に逮捕されたのは自営業の車館宙生(くるまだち・ひろむ)容疑者(24)=同市中区、自称店員の高橋美琴容疑者(23)=同市中区、大学生の田口零朗容疑者(22)=同市中区。車館容疑者と高橋容疑者はいずれの容疑も否認、山田容疑者と田口容疑者は詐欺容疑について否認している。

 県警は100人以上から約5800万円をだまし取った疑いがあるとみて全容解明を急ぐ。山田容疑者は会員制交流サイト(SNS)や出会い系アプリで勧誘する役割で、偽名を使い、SKEのメンバーだったことは伏せていた。

米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳(転載)

piyokango retweeted: @piyokango 米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳 qiita.com/todkm/items/6f… #Qiita:
piyokango retweeted:
@piyokango 米CISA/MS-ISAC発行「ランサムウェアガイド 2020年9月」ランサムウェア対応チェックリスト試訳 qiita.com/todkm/items/6f… #Qiita

はじめに


以下は、米サイバーセキュリティ・インフラストラクチャー・セキュリティ局(CISA)と州横断ISAC(Multi-Sate ISAC)が2020/09/30に共同でリリースした ‘RANSOMWARE GUIDE SEPTEMBER 2020’ の後半部分 Part 2: Ransomeware Response Checklist で、ランサムウェア被害にあったときのチェックリスト形式の対応マニュアルです。一般的な企業なら必要十分でコンパクトな内容だと思います。

直訳で意味が通りづらい部分は適宜意訳しています。米国特有の固有名詞は正確な翻訳を意図していません。

また見出しが長文で書かれている個所は、独自に簡潔な見出しに変更し、見出しだった文章をそのセクションの最初の文にスライドさせています。

Part 2: ランサムウェア対応チェックリスト


万一あなたの組織がランサムウェアの被害者になった場合、CISAは以下のチェックリストを利用して対応することを強く推奨する。最初の3つのステップ(訳注:下記1.~3.のこと)は必ず実施すること。

検知と分析


1. 影響を受けたシステムの特定と即時の隔離


  • 複数のシステムまたはサブネットが影響を受けたと思われる場合、ネットワークをスイッチレベルでオフラインにする。インシデント発生中にシステムを個別に切断できない場合があるため。

  • ただちにネットワークを一時的にオフラインにすることができない場合は、ネットワークケーブル(例. イーサネット)の場所を特定し、感染を封じ込めるために、影響を受けたデバイスのプラグを抜くかWi-Fiから切断する。

  • 最初に侵入した後、攻撃者はあなたの組織の活動や通信を監視して、自分たちの攻撃が検知されていないかを知ろうとする。したがって、組織で協力して、攻撃を検知したことや対策を取ろうとしていることを攻撃者に知られないように、電話などネットワーク以外の通信手段でシステムを隔離すること。さもないと攻撃者は横展開して攻撃を続けようとしたり(これはすでにありふれた戦術になっている)、ネットワークをオフラインにされる前にランサムウェア感染を拡大しようとする。

2. デバイスの電源を落とす例外的なケース

ネットワークからデバイスを切り離せない場合のみ、ランサムウェアのさらなる感染拡大を防ぐため電源を落とす

3. リストアとリカバリの優先順位付け


  • リストアすべき重要システムの特定と優先順位付けをおこない、影響を受けたシステム内のデータの性質を確認する。

  • リストアやリカバリの優先順位付けは、あらかじめ定義しておいた重要情報資産リストに基づいて行う。そのリストには安全衛生、収益源となるシステム、他の重要な情報システムや、それらシステムが依存するシステムも記載しておくこと。

  • 影響を受けていないと思われるためリストアやリカバリの優先順位を下げたシステムやデバイスも記録しておくこと。そうすればあなたの組織はより効率的に業務を再開できるようになる。

4. 初期分析の文書化


あなたのチームと話し合って、起こった事実について最初の分析にもとづく最初の理解を文書化しておく

5. 利害関係者と今後の対応についての合意形成


社内外のチームや関係者がインシデントによる被害の低減や対応、リカバリのために何ができるかを合意しておく。

  • あなたが入手できる情報を共有して、インシデントに関係する支援をいちばんタイムリーに受けられるようにすること。状況の変化に応じて、マネジメントや管理職に定期的に情報提供すること。関係者の中には、IT部門、マネージド・セキュリティサービスプロバイダー、サイバー保険会社、各部署の選任されたリーダーを含めること。

  • 関係する政府機関や、ISAC、地方や国家の司法機関などの支援をうけることも考慮すること。下記連絡先リストを参照。

  • 必要に応じて、広報部門と連携して社内および社外に正確な情報が伝わるようにすること。

  • 'Public Power Cyber Incident Response Playbook' には組織としてのコミュニケーション手順の指針や、対外的なセキュリティインシデント発表のひな型があるので、あなたのチームと協力してできるだけ早く同様の手順や公式発表の草稿を作っておくこと。インシデント発生中に公式発表文を作成するのは最善策ではない。社内外とどの程度詳細に情報共有するのが適切か、情報をどのように流すのかは、このPlaybookを参照すれば事前に決めておくことができる。

封じ込めと除去


6. システムイメージとメモリキャプチャの採取


影響を受けたデバイス(例 ワークステーションやサーバ)のサンプルからシステムイメージとメモリのキャプチャを採取する。

さらに関連するログと、先行して侵入しているマルウェアのバイナリ、それに関連する観測事項やセキュリティ侵害インディケーター(IoC)をすべて収集すること(例. 疑わしいコミュニケーション・アンド・コントロールのIPアドレス、疑わしいレジストリエントリ、その他の検知された関連ファイル)。下記連絡先リストはこれらの作業を支援してくれる。

  • 非常に消失しやすい性質のエビデンスや、一部しか確保できないエビデンスについては、損失や改ざんを防ぐために十分注意して保存すること(例. システムメモリ、Windowsセキュリティログ、ファイアウォールのログバッファ内のデータ)

7. 法執行機関への相談


入手可能な復号方法があるかもしれないので国の法執行機関に相談する。セキュリティー・リサーチャーはすでにいくつかのランサムウェアの暗号化アルゴリズムを解明している。

引き続きインシデントの封じ込めと被害の低減のため、以下のステップを続けること。

8. 影響を受けたシステムの特定と封じ込め


特定のランサムウェアについて信頼できるガイダンスを調査し(例. 政府や各種ISAC、著名なセキュリティーベンダー等)、追加の推奨手順を実施して、影響を受けたことが確定しているシステムを特定し、封じ込める。

  • 既知のランサムウェアのバイナリの実行を停止、または無効化し、システムに対する被害や影響を最小化する。その他、関連する既知のレジストリ値やファイルを削除する。

9. 最初に不正侵入を受けたシステムとアカウントの特定


電子メールアカウントも含む。

10. 関連システムの封じ込め


ここまでで特定された不正侵入や侵害にもとづいて、さらなる不正侵入に継続的に悪用される可能性のある関連システムをすべて封じ込める。

不正侵入は機密情報の大量窃取をともなうことが多い。引き続き認証情報の悪用による不正アクセスから、ネットワークやその他の情報源を守るには、以下の対策を含めてもよい:

  • VPN、リモートアクセスサーバー、シングルサインオン、クラウド、その他の外部公開されている情報資産の無効化。

11. 推奨する追加対策:サーバ側データ暗号化の迅速な特定


  • 感染したワークステーションによってサーバ側のデータまで暗号化されてしまった場合、それを素早く特定する手順は以下のとおり。
  1. 関連するサーバーで「コンピュータの管理」>「セッション」および「開いているファイル」をチェックし、それらのファイルにアクセスしているユーザーやシステムを特定する。

  2. 暗号化されたファイルやランサムノートのファイルプロパティーをチェックし、それらのファイルの所有者となっているユーザーを特定する。

  3. ターミナルサービスのリモート接続マネージャーのイベントログをチェックし、成功しているRDP接続がないか確認する。

  4. Windowsセキュリティログ、SMBイベントログ、関連するすべてのログをチェックし、重要な認証イベントやアクセスイベントがないか確認する。

  5. 影響を受けたサーバーでWiresharkを実行し、ファイルの書き込みや名前の変更に関係するIPアドレスをフィルタで特定する(例 “smb2.filename contains cryptxxx”)。

12. 侵入検知・防止システムのログ精査

組織にある既存の検知システムまたは防止システム(ウイルス対策、エンドポイント検知対応(EDR)、IDS、侵入防止システム(IPS)等)およびログの精査をする。

それによって攻撃の初期段階に関係していた、別のシステムやマルウェアについてエビデンスを明らかにできる。

  • 先行して侵入している「ドロッパー」マルウェアのエビデンスを探す。ランサムウェア感染はそれ以前に起こっていた未解決のネットワーク不正侵入の証拠かもしれない。ランサムウェア感染は、TrickBot、Dridex、Emotetといったランサムウエアがすでに存在していた結果であることが多い。

  • これら最新のマルウェアのオペレーターはネットワークへのアクセス方法を販売していることが多い。場合によっては、攻撃者はそうしたアクセス方法を悪用してデータを窃取してから、データを公開するぞと脅迫した後で、さらに被害者を脅迫して支払いを迫ろうとネットワークをランサムウェアに感染させる。

  • 攻撃者はネットワークに手動でランサムウェアをドロップし、不正侵入後の活動を分かりにくくする場合がある。継続的な侵入を防ぐには、バックアップから復旧させる前にそのようなドロッパーを注意して特定しておく必要がある。

13. 継続的攻撃の分析

外部から内部、内部から外部への継続的攻撃のメカニズムについて踏み込んだ分析を行う

  • 外部から内部(outside-in)の継続的攻撃には、不正アカウントによる外部システムへの認証済みアクセスや、境界システムのバックドア、外部システムの脆弱性の不正利用などが含まれることがある。

  • 内部から外部(inside-out)の継続的攻撃には、内部ネットワークに埋め込まれたマルウェア、または環境寄生(自給自足)型のシステム変更(例. Cobalt Strikeのような市販の侵入テストツールの悪用、PsExecを含むPsToolsの悪用、マルウェアを遠隔インストールし制御することによるWindowsシステムの情報収集や遠隔管理操作、PowerShellスクリプトの悪用)が含まれることがある。

  • これらを特定する方法として、エンドポイント検知・対応(EDR)ソリューションの導入や、ローカルとドメインのアカウント監査、集中ログ収集システムで見つかったデータの精査、環境内での動きが一度でも特定された場合は、その該当するシステムのより深いフォレンジック分析が含まれることがある。

14. 優先順位に基づくシステム復旧


重要なサービスの優先順位付けに基づいてシステムを復旧する。(例:安全衛生または収益源となるサービス)

できればあらかじめ設定済みの標準イメージを利用する。

15. パスワードリセットと未対応部分への対処


環境が完全にクリーンにされ復旧した後(影響を受けたすべてのアカウントや継続的な不正メカニズムの除去を含む)、影響を受けたすべてのシステムのパスワードリセットを行い、セキュリティ面や可視化されていなかった部分の脆弱性や未対応部分に対処すること。

パッチの適用、ソフトウェアのアップグレード、その他それまで講じていなかったセキュリティ予防策の実施が含まれることもある。

16. インシデント終了宣言


上述の手順を踏むことや外部の支援を得ることも含め、確立された規準にもとづいて、所定のIT部門またはITセキュリティ責任者がランサムウェア・インシデントの終了を宣言する。

復旧とインシデント終了後の活動


17. システムの再接続とデータのリストア


システムを再接続し、重要なサービスの優先順位付けにもとづいてオフラインで暗号化されたバックアップからデータをリストアする。

リカバリー中にクリーンなシステムを再感染させないように注意すること。例えば、リカバリのために新たなVLANを構成する場合、確実にクリーンなシステムのみを追加すること。

18. 学びや対応結果の文書化


インシデントからの学びや関連するインシデント対応活動を文書化することで、組織のポリシー、計画、手順を更新・改善するための情報源として活かし、同様のインシデントについて今後の演習のガイドとする。

19. 当局や業界団体などとの情報共有


インシデントからの学びや関連する侵害インディケーター(IoC)を当局に共有し、さらに業界ISAC、情報共有分析機関(ISAO)にも共有し、コミュニティー内部の他の人々や組織の利益にもなるように考慮する。



インターネットに晒されている機器を調べるサイト【SHODAN】


SHODANという検索エンジンがある。

一時期はIoT検索エンジンとか言われていたが、ネット上に晒されている機器を検索することができるサービスである。

https://www.shodan.io/

アクセスすると、検索ウィンドウがあると思うので、IPアドレスやポート番号等のキーワードを入れて検索する。

※注:罠の可能性もあるので、脆弱っぽい機器を見つけたとしても安易にアクセスしないでください。

【インターネット直結のプリンタでパスワード設定が無い機器を調べるときの例】
printer password is not set

【日本国内でtelnetがオープンになっているインターネット機器を調べるときの例】
country:"JP" port:23

【日本国内のAnonymous FTPを調べるときの例】
country:"JP" Anonymous FTP

【日本国内でインターネットにポート445がオープンになっているWindows PC(Windowsサーバは除外)を調べるときの例】
port:445 country:"JP" OS:"Windows" country:"JP" !OS:"Server"

【既知の脆弱性(例:CVE-2019-0708)を持つデバイスを検索するときの例】
vuln:CVE-2019-0708
            ※フリーアカウントでは不可。

Onion Address(v2/v3)を検索するときの例
"Onion-Location"

【参考】
日本国内で接続されている IoT 機器数(IPA)
https://www.ipa.go.jp/security/iot/20170417.html

増加するインターネット接続機器の不適切な情報公開とその対策(IPA)
https://www.ipa.go.jp/files/000052712.pdf

Exchange Serverの脆弱性まとめとSHODANでの観測状況(マクニカネットワークス)
https://blog.macnica.net/blog/2020/06/exchangeserver-shodan.html

OSINT 用検索エンジンあれこれ
https://ninoseki.github.io/2018/12/03/osint-search-engine.html

-2020/7/11追記-
【ダークウェブのIPアドレス調査の例】

-2020/8/26追記-

【特定のドメイン(証明書のコモンネーム)を調べる場合の例】

-2020/9/1追記-
【IPで検索する場合の例】
net:115.165.122.0/24

-2021/3/16追記-
【検索フィルタ一覧】
filterdesc.
asnThe Autonomous System Number that identifies the network the device is on.
beforeOnly show results that were collected before the given date (dd/mm/yyyy.
cityShow results that are located in the given city.
countryShow results that are located within the given country.
geoThere are 2 modes to the geo filter: radius and bounding box. ex: geo:50,50,100. or geo:10,10,50,50.
hashHash of the "data" property
has_ipv6If "true" only show results that were discovered on IPv6.
has_screenshotIf "true" only show results that have a screenshot available.
hostnameSearch for hosts that contain the given value in their hostname.
ispFind devices based on the upstream owner of the IP netblock.
linkFind devices depending on their connection to the Internet.
netSearch by netblock using CIDR notation; ex: net:69.84.207.0/24
orgFind devices based on the owner of the IP netblock.
osFilter results based on the operating system of the device.
portFind devices based on the services/ ports that are publicly exposed on the Internet.
postalSearch by postal code.
productFilter using the name of the software/ product; ex: product:Apache
stateSearch for devices based on the state/ region they are located in.
versionFilter the results to include only products of the given version; ex: product:apache version:1.3.37
bitcoin.ipFind Bitcoin servers that had the given IP in their list of peers.
bitcoin.ip_countFind Bitcoin servers that return the given number of IPs in the list of peers.
bitcoin.portFind Bitcoin servers that had IPs with the given port in their list of peers.
bitcoin.versionFilter results based on the Bitcoin protocol version.
http.componentName of web technology used on the website
http.component_categoryCategory of web components used on the website
http.htmlSearch the HTML of the website for the given value.
http.html_hashHash of the website HTML
http.statusResponse status code
http.titleSearch the title of the website
ntp.ipFind NTP servers that had the given IP in their monlist.
ntp.ip_countFind NTP servers that return the given number of IPs in the initial monlist response.
ntp.moreWhether or not more IPs were available for the given NTP server.
ntp.portFind NTP servers that had IPs with the given port in their monlist.
sslSearch all SSL data
ssl.alpnApplication layer protocols such as HTTP/2 ("h2")
ssl.chain_countNumber of certificates in the chain
ssl.versionPossible values: SSLv2, SSLv3, TLSv1, TLSv1.1, TLSv1.2
ssl.cert.algCertificate algorithm
ssl.cert.expiredWhether the SSL certificate is expired or not; True/ False
ssl.cert.extensionNames of extensions in the certificate
ssl.cert.serialSerial number as an integer or hexadecimal string
ssl.cert.pubkey.bitsNumber of bits in the public key
ssl.cert.pubkey.typePublic key type
ssl.cipher.versionSSL version of the preferred cipher
ssl.cipher.bitsNumber of bits in the preferred cipher
ssl.cipher.nameName of the preferred cipher
telnet.optionSearch all the options
telnet.doThe server requests the client to support these options
telnet.dontThe server requests the client to not support these options
telnet.willThe server supports these options
telnet.wontThe server doesnt support these options