【転載】既存機能を活用したマルウェア感染対策の考察~Windows Defender、レジストリのマクロ自動実行無効化、子プロセスの生成停止の3点がポイント~



こんな機能知らなかったので、とりあえず設定してみる https://t.co/b4gU74ehx0

Quoted tweet from @nknskn:

はてなブログに投稿しました
ぼくのかんがえたさいきょうのマルウェア感染対策(EmotetのVBAを覗いて、VBAマクロに対する防御を考える) - news-nknsknの日記 news-nknskn.hatenablog.com/entry/2020/10/…
: こんな機能知らなかったので、とりあえず設定してみる https://t.co/b4gU74ehx0

はてなブログに投稿しました

ぼくのかんがえたさいきょうのマルウェア感染対策(EmotetのVBAを覗いて、VBAマクロに対する防御を考える) - news-nknsknの日記 news-nknskn.hatenablog.com/entry/2020/10/…



ーーーー

Emotetが(何故か)再流行したみたいですね。
本当になぜ再流行したかイマイチわからず、「そもそもどんな感じで書かれているのか」「検知はそんなに難しいのか」「止める方法ってマクロ無効化とかファイル開かない、みたいなのしかないの?」とかちょっと考えてみたくなったので、知ってる範囲でEmotetを止めるための設定を書いてみました。他にこんな方法もあるよ、とかあればコメントいただけると嬉しいです。コマンド一発でグループポリシーに適用させられるやつだとより大勢の管理者の方が幸せになれる気がします。「この設定ファイルイカしてるからグループポリシーにインポートしてみなよ!」みたいのでも可(血涙)DoDのSTIG良いですよねえ...
以下、TOC

最近のマルウェアについてコメント

オンメモリでpowershellが実行されるーとかダウンローダを何回も重ねてるーとか、攻撃に使われているマルウェアにはいくつも特徴がありますが、まあ冷静に考えてオンメモリでpayloadを展開&実行していても結局やってるのはプロセス生成のためのコマンド実行なわけです。要は「最悪このプロセス生成を止めりゃいいんでないの?」という発想です。
Emotetに関して細かいことを言うと、観測範囲内においては以前から最近のものまで全てVBA内にどうにかこうにかpayloadを隠し持たせ、(見づらくしただけっぽい)難読化コードからpowershellを実行するものが多い印象です。ちなみにいくつかのEmotet解析ブログを見たり自分でもEmotetのVBAコードを見たりしましたが、powershell実行時に使用されているのはたいていWin32_Process.Create()のようでした(下記リンクのうち下二つはその辺書いてない)。直近のEmotetについては以下すぐに触れますが、やっぱりWin32_Process.Create()でpowershellを叩くようになってました。

比較的最近のEmotet VBA(2検体)について

※専門家の知見のもと安全に十分配慮して(ry
細かいところは省略して、重要だと思ったところだけ載せます。難読化している箇所なんていくらでも変えられるから変えているのであって、そこに注目するのは時間の無駄です。想定している動作をさせる上で変えようがないところを見ていきます。
  • 9c6f98f54b5f8b43d3ced2c547a09d7ea30578c696263ad60666ea9e75a22daa
Private Sub _
Document_open()
F5rwxzbfuowsqkbdt.Xbq37kxh8w2e
End Sub

Function Xbq37kxh8w2e()
   On Error Resume Next

'(snip)

Jpfgivlyicd99r9 = Array(Y6gqr6abanqlu + "Wyvln5tc5eq37uvul1 Pdetuctodf7fClhqmwed17ab_10rrr Se951ebi5pq", CreateObject(Bqqta6d91epi).Create(Bqf_3mrtgx7xegw45i, Z_qxvnehzwd7iesunu, Whewr2ng_0nf6zf), Qy4p7grrmlokyk0cbt + "Jenkodabwww Wks5jgvvqe737k Lwkcqakg5joom D6615tagrz7r0wjiv")

'(snip)

End Function

'(snip)
  • 9140dd246193f4397044dce4c62930cb81b729b3900b10c5e9ecf6778a077648
Private Sub Document_open()
Rt055d5md2s7_.Tv2ghyjqs9ofp1
End Sub

'(snip)

Function Tv2ghyjqs9ofp1()
On Error Resume Next

'(snip)

S_widwqm3orw6j3ur.Create CVar(Fq4_elcsi9j), Uc3rl8girme, Qtx_okh1te1i98

'(snip)

End Function

'(snip)
どちらの検体もみて分かる通り、マクロ有効時(Document_open)に、プロセスを生成する(.Create)ことがわかります。 その後、メモリ上に展開されたpowershellダウンローダとして機能して、exeを4-5 URLから取ってこれるか確認して、ダウンロードできたら実行して〜みたいな流れになりますが(メールでの感染拡大はexeでやってる)、このブログでは「そこまで行ったら負け」という考えでいきます。

アンチウイルスソフトについてコメント

で、Anti-Virus software(以降、AV)関連の話に移ると、(細かいところは省きますが)最近のWindows Defenderさん(以降、Defender)は大変にやっか...優秀になっていて、初弾にあたるVBAマクロに「コマンド実行をするための関数」(Wscript.ShellのRunとかExecとかWin32_ProcessのCreateとかCreateRemoteThreadだとか)が含まれていると、「Defenderが有効」かつ「Defenderのクラウド保護機能が有効」な場合(デフォルト設定ではどちらも有効)に、実行前のOfficeファイルごと削除するようになってたりします。
上記のようなEmotetのマクロには見た通り.Create()が入っているので、上記を満たす端末においては、ファイルを開く前にDefenderがそのファイルを削除してくれるはずです(ブログ執筆時は消されてるものの今後はわからない)。
そんなわけで、現時点における個人の印象としては(Defenderに頼っているので)「Emotetなぞ恐るるに足らず。なんでざわざわしてるのかよくわからん」という感じですが、まあEmotetに限らず攻撃者は手を変え品を変え、検知されないようバレないようにやってくるものです。どうやったら作れるんですかねぇ...最近は開発方針が今一つ(ry。そんなわけでAV以外の設定でなんとか止められないかをみてみます。

Office 365 webでのファイルオープンについて

いつぞやにTwitterで呟いた気もしますが、Office 365を利用している場合、Webベース(ブラウザ)でWordやExcelを使用することができます。またそこでdoc等のファイルを開こうとすると互換性エラーが発生して、強制的にdocx等に変換、その後マクロがないファイルを開くことになります。そのため、Webベースでファイルを開くように徹底することでマクロを一切排除できることから、WebベースでOfficeファイルを扱うことは、VBAマルウェアに対して有効な手段と考えられます(あれ?ローカルのOfficeソフトウェアをなくしてしまえば。。。)。
ただし個人でOffice 365買うの?とか、企業でもすぐにOffice 365へ移行できないよ、、、みたいな話は往々にあることだと思います。なので今回はそれ以外の方法で止められないか、というところを引き続きみます。
不採用:Office 365 WebでOfficeファイルを開くポリシーにする

マクロの自動実行無効化について

では、マクロを業務で利用することがない場合。そんな時はマクロを止めちゃうのが手っ取り早いでしょう。一番声高に推奨されている方法だと思います。
f:id:news-nknskn:20201007200032p:plain
OfficeTrustCenter
ただし、上記のリンク中にもある通り、自動実行を止めたとしてもユーザがマクロを有効にする可能性は大いにあります。というか、感染するケースはユーザが実行する方が多いと思います。なのでpowershellが実行されることを想定して、そこでブロックできないかを考えてみます。

Powershellの実行制限について

Powershellなど不要ら!という前提で考えてみます。その場合、Powershellのプログラムが実行されること自体を止めることが可能です。具体的には、Active Directoryのグループポリシー、ローカルの場合はローカルセキュリティポリシーからPowershellの実行を禁止します。
以下のようにフルパスで設定したとしましょう。
f:id:news-nknskn:20201007194031p:plain
securitypolicy
その後再起動などをしてコンピュータに反映すれば、以下のような形でpowershellの実行を止めることができます。これで、powershell -enc ...のようなプロセス生成は止めることができます。
f:id:news-nknskn:20201007194424p:plain
psblocked
しかしこの場合、Powershellのバイナリを%temp%とかにコピーした上でrenameされたら?とかUnmanaged powershellをダウンロードされて実行される場合は?cmdで頑張ってexe実行までいくケースもあるよね?って話になります。そもそも私はPowershellは日常的に使うので止めたくないです。

それならもうWord.exeからのプロセス生成止められない?Wordで子プロセス生成するケースってどんな場合よ、っていう話があります。
※なお、バイナリファイルの実行をホワイトリストレベルで制限をかける運用を考えている場合、セキュリティポリシーでのブロックは非常に有効な手段になると思います。AppLockerとかAppLocker bypassだとかその辺の話です。興味がある方は調べてみてください。

Officeプログラムからの子プロセス生成を止める

ようやく言いたいところにたどり着きました。Officeから子プロセスを生成する処理というのは、よほどマクロで変態的なことをしない限りないはずです。
以下はWord/Excelに関して、ドキュメントおよびワークブックを複数開いた際に生成されるプロセスおよびそのプロセスツリーを確認した画面です。通常時、子プロセスを生成することはなさそうに思えます(あったら完全に調査不足ですごめんなさい指摘してください)。
f:id:news-nknskn:20201007201155p:plain
OfficeProcesses
Windows 10からはWindows Defenderへの追加機能として、Exploit Guardというものが実装されています。どんな機能があるのか、という点は以下の記事を参照するのが一番良いと思うので適宜見ていただくとして、ここではそのうち一つの機能である「子プロセスを許可しない」設定に注目します。
いろいろggったり資料を見たりするとMS ATPとの組み合わせの記事も多く、「ATPお高いんでしょう?」みたいな印象を持たれがちがもしれませんが、実は(知ってる人は多いかもしれないですけど)Exploit protection自体はATPを導入しなくても普通の市販PCで設定することが可能です。実際に設定して、どう動くのか確認してみます。
Windows セキュリティ > アプリ&ブラウザコントロール > Exploit protection settings(最下部)
f:id:news-nknskn:20201007201849p:plain
EndpointProtection1
プログラム設定 > プログラム名を追加
f:id:news-nknskn:20201007202017p:plain
EndpointProtection2
タスクマネージャ(とかtasklist)からWordやExcel等Officeソフトの正式プログラム名を確認しておきます(なぜ統一感がないのか)。
f:id:news-nknskn:20201007202308p:plain
f:id:news-nknskn:20201007202311p:plain
それぞれに対し、以下のような感じで「子プロセスの生成を許可しない」設定にし、適用します。設定後、Word、Excelは再起動します(not コンピュータ)。
f:id:news-nknskn:20201007202649p:plain
winword-Disallowchildprocesses
それでは以下のようなサンプルマクロを書いて、実行してみます。
※ここでは動作確認のためWordにブロック設定、Excelにはブロックしない設定にしています。
Private Sub Test()
    'On Error Resume Next
    CreateObject("WScript.Shell").Run "cmd.exe"
    CreateObject("WScript.Shell").Exec "powershell.exe"
    e = GetObject("winmgmts:\\.\root\cimv2:Win32_Process").Create("notepad.exe", null, null, intProcessID)
End Function
Excelで実行、cmd, powershell, notepadが動いていることが確認できます。
f:id:news-nknskn:20201007204931p:plain
execviaexcel
Wordで実行
  • Runがめでたく死亡
f:id:news-nknskn:20201007205257p:plain
ErrorInRun
  • Execも同様に死亡
f:id:news-nknskn:20201007205351p:plain
ErrorInExec
※.Createの部分はOn Error Resume Nextをなくした状態でエラー出力なし、ただしプロセスも起動しないため画面キャプチャはなし。気になった方は試してみてください。
採用:Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

その他のファイルについて

攻撃者は他にもWSH(.js, .vbs)やらexeやらを送ることでどうにかこうにか端末を感染させようと試みたりしますが、その辺に関してはまた別のポリシー設定であったり、外から送られてきたexe実行するの?みたいな話があったりしてまた長くなるので以下省略

採用した項目一覧

上記の内容から以下の項目を採用しました。これでEmotetのようなVBAマルウェアは、プロセス生成までの流れのどこかしらでシステム的にも止められるはずです。
  • Windows Defender(クラウド保護有効)によるプロセス生成系マクロを含むOfficeファイルの削除
  • マクロの自動実行完全無効化(レジストリ
  • Exploit ProtectionによるOfficeファイルからの子プロセス生成停止

今回不採用だったけど手としてはアリだと思う項目

所感

  • これで取り合えずマクロを開いて即感染!みたいなことは防げると思われ
  • 正直最後のEndpoint protectionだけ有効にすればいいんじゃないかな、みたいな話はありますが、Officeファイル以外からの攻撃手法もあるので複合的に守っていきましょう
  • あれ?Windows Defenderここまで強くなってたの?
  • 侵入後の話でZerologonとかありますけど、どうやって打ち込むところまで辿り着くんでしょうね

追記1:Endpoint protection bypass

Twitterで以下のコメントをいただきました。
全くその通りで、特定のプログラムからのプロセス生成が止められるなら、それ以外のプログラムから実行すりゃええやんって話です。これでEndpoint protection bypassは可能です(ババーン)
ただし今回の設定においては以下が有効であるため、残念ながらこの.shellexecute入りのマクロ付きOfficeファイルは、クラウド保護機能によって消される、もしくはAMSIによってマクロの実行が止められる結果になります。
  • Windows Defender(クラウド保護有効)によるプロセス生成系マクロを含むOfficeファイルの削除
AMSIによってマクロの実行が止められる場合、AMSI bypassテクニックを使うことで検知回避が部分的に可能ですが、bypassテクニックのほとんどはamsiScanBufferに対してアクションを起こすもので、クラウド保護もまるごと回避できるものは寡聞にして知りません。
ここらへんいじくってbypassできれば楽なんだけど誰かブログに書いてくれたりしないかな。日本じゃ無理なのか?
そんなわけで今コメントいただいている方法では、まだ上記の設定でプロセス生成までの流れの中で止めることが可能です。

  • 10/8 AM, 2020: 誤字脱字修正, 「今回不採用だったけど手としてはアリだと思う項目」を追加
  • 10/8 PM, 2020: 追記1



以上

【転載】永久不滅ポイント、JALマイル交換でレートアップ(2020年9月15日から2020年11月15日)



セゾン・UCの永久不滅ポイント、JALマイル交換でレートアップ:


セゾンカードとUCカードは、永久不滅ポイントからJALマイレージバンクのマイルへの交換で、レートアップキャンペーンを9月15日から11月15日まで実施している。

エントリーの上、セゾンカードとUCカードの永久不滅ポイントをJALのマイルに交換すると、通常は200ポイントが500マイルになるところ、600マイルになる。通常分のマイルは手続き後3〜4週間、ボーナスマイルは2021年1月下旬頃に付与する。

両カードは、利用金額1,000円(税込)ごとに1ポイントを付与している。一部のセゾンカードでは、同10マイルを自動付与する「SAISON MILE CLUBショッピングマイルプラン」の利用ができる。

【転載】ポイント&Amazonギフト券がどんどん貯まってしまう?



【無限祭り再来】ポイント&Amazonギフト券がどんどん貯まってしまう?:

久々に来たか?大ポイント祭り?!無限にポイント・マイル・Amazonギフト券が貯まる?リピート可のレビュー案件の利用で、1回ごとに2,000円がもらえるという衝撃の緊急案件登場中! 久々すぎる祭り案件かもしれません。 祭...

The post 【無限祭り再来】ポイント&Amazonギフト券がどんどん貯まってしまう? first appeared on すけすけのマイル乞食.

ーー

久々に来たか?大ポイント祭り?!無限にポイント・マイル・Amazonギフト券が貯まる?リピート可のレビュー案件の利用で、1回ごとに2,000円がもらえるという衝撃の緊急案件登場中!

お祭り案件って何かというと、利用すると月給のような額のポイントがもらえるような可能性のあるとんでもないやつです。数年に1回くらい登場するんですよ・・・祭り案件。なんか、それが来たのかもしれません。

紹介しておきましょう! 

ポイントサイト「モッピー」経由で「ITトレンド」にレビューするごとに1,000P&Amazonギフト券1,000円もらえる!商品ごとに何度でもレビューOK!

今回、マジで強烈なポイ活が利用できるのは、ポイントサイト「モッピー」です。

あなたの1か月分のお小遣いを超える額を簡単に稼げてしまう可能性を秘めているので、マジで注目してください。

 

手順は簡単。

まず、モッピーに下記のバナーからアカウントを作成してください。

モッピー!お金がたまるポイントサイト

今なら、上記バナーからのアカウント作成で2,000Pがもらえる入会キャンペーンもやっているので、ぜひそちらの詳細も上記バナーでチェックしてください!

モッピーポイントの使い方

モッピーのポイントは1P=1円で複数のポイントに交換も可能です

  • 1P=1円で銀行振込、Amazonギフト券、dポイント、楽天スーパーポイントなど
  • ANAマイルは、TOKYUルートで交換レート75%。例えば20,000P=15,000ANAマイル
  • JALマイルは、モッピーのドリームキャンペーンで交換レート最大で80%。例えば20,000P=16,000JALマイル
  • ウェル活なら1ポイント=1.5円で利用可能

ポイントの使い方が超魅力的なのが、モッピーの強みです。現金で受け取りもOK、ANAマイルやJALマイルにも交換可能です。JALマイルにも高レートで交換できるポイントサイトはモッピーしかありません

【モッピーとは】陸マイラーが徹底解説。ポイントの稼ぎ方~ANAマイル・JALマイルへの交換方法まで。

2019-10-08

登録が完了したら、モッピーにログインして「ITトレンド」と検索しましょう。

上記の「ITトレンド」が表示されたら、「POINT GET!」をクリックして、レビュー投稿をしましょう。すると、レビューを投稿する毎にモッピーから1,000P=1,000円がもらえます!

 

しかも、しかも、しかも、これ「リピートOK」って書いてありますよね?

ポイント付与条件に、

【獲得条件】
IT製品のレビュー投稿完了
※1製品について1回のレビュー投稿完了
※別製品であれば、同一ユーザーでも1製品1回までは承認対象となります。

なんと、1製品ごとにレビュー可能で、レビューごとにポイントが付与されます!!

 

何製品あるのか見ておくと、

なんか、500製品くらいありそうだ・・・これ全部レビューできる人は・・・強烈・・・。1,000円×500・・・・。レビューできそうなものがあるといいですね!一つくらいはみなさんあるかもしれませんし、ごにょごにょ・・・。 

レビューする毎に1,000Pもらえるという強烈な内容ですが、ポイント付与条件にある

【獲得対象外】
※レビュー投稿内容の不備
※同一製品に対して複数回投稿
※不備・不正・虚偽・重複・いたずら・キャンセル
※その他お申込内容に不備がある場合
※本キャンペーンページ以外からの投稿

という項目には注意しておきましょうね。自分が全然詳しくないものに関して投稿レビュ―すると虚偽と判断されるかもしれませんからね・・・。 

しかも、まだ話があります。

なんと、モッピーも1,000Pとは別に、レビューするとITトレンドからもAmazonギフト券1,000円ももらえるんですよ!!!

つまり、レビューする毎に、、、、

  • モッピー1,000P
  • Amazonギフト券1,000円

2,000円が魔法のようにどんどん増える。このポイ活強烈すぎます。モッピーのポイントはANAマイル・JALマイルにも交換できますし、dポイントやTポイントにも交換可能、またまた現金にも交換可能なので、使い方は無限です。

とにかく、モッピーに下記のバナーからアカウント作成をして、レビューしましょう。

【転載】セキュリティ企業のインテリジェンス情報の偏りをなくした最強のFirewall構成!?

EjxxtnyUwAIwzW3.png:large
本気でセキュリティ企業のインテリジェンス情報の偏りをなくそうとするとこういうことになりかねない:

本気でセキュリティ企業のインテリジェンス情報の偏りをなくそうとするとこういうことになりかねない



【転載】サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ


サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ OPSEC for hackers <- これは実質聖書 slideshare.net/grugq/opsec-fo… Threat Intelligence: My opinion on what it is and isn't linkedin.com/pulse/threat-i…: サイバーな方のインテリジェンスをやっているorやろうとしてる人に読んでもらいたい記事のメモ

OPSEC for hackers <- これは実質聖書

slideshare.net/grugq/opsec-fo…

バックアップ

--

Threat Intelligence: My opinion on what it is and isn't

linkedin.com/pulse/threat-i…

(以下機械翻訳)

脅威インテリジェンスに関しては、多くの組織がそれを行っていると主張しています。この投稿では、脅威インテリジェンスとは何か、脅威インテリジェンスではないものについての私の意見を取り上げます。脅威インテリジェンスではないものから始めましょう:
  • ブランドの監視、または私がクラウド(他の誰かのコンピューター)でのインシデント対応と呼んでいるもの。これは、組織に類似した偽のドメイン、App Storeの偽のアプリ、Playストア、偽のソーシャルメディアプロファイルを探しています。脅威インテリジェンスチームがこれを任務に持っている場合(私の意見では、ブランド保護チームのような別のチームがこれを処理する必要があります)、真の脅威インテリジェンス機能になる時間がない可能性があります。
  • 侵害された資格情報またはクレジットカード。上記のように。
  • 自動ブロックと検出のために、インジケーターまたは侵入の痕跡(IOC)またはシグニチャを環境に取り込む。行うのは良いことですが、脅威インテリジェンスではありません。
それでは、「脅威インテリジェンス」という用語を見て、それを定義しましょう。脅威はマルウェアではありません。脅威はマルウェアを使用している人です。この人または潜在的にグループには、動機、目標、およびTTP(戦術、技術、および手順)があります。脅威インテリジェンスとは、人やグループを追跡/調査することです。

インテリジェンスの定義。インテリジェンスは長い間存在しており、インテリジェンスの収集またはスパイは売春に次いで2番目に古い職業であると言われています。インテリジェンスは、インテリジェンスサイクルと呼ばれるプロセスの出力です。このサイクルは次のとおりです。要件->収集->処理->分析->配布。その後、プロセスは要件段階で再開されます。このプロセスの出力(インテリジェンスの顧客または利害関係者に配布されるもの)はインテリジェンスであり、コンピューターではなく人によって行われます。

要件段階では、ここでインテリジェンスプログラムの優先順位が設定されます。その前に、インテリジェンスの顧客または利害関係者がインテリジェンスチームのメンバーであるかどうかを特定する必要があります。米国政府では、情報消費者の第1位は大統領府です。商用スペースには、CISO /エグゼクティブ(脅威インテリジェンスチームの第1の顧客である必要があります)、セキュリティオペレーションセンター(SOC)、インシデント対応、サードパーティのリスク、脆弱性管理(パッチの優先順位付けを可能にする)など、従来のインテリジェンスの顧客プロファイルが多数あります。 、レッドチーム、ハントと詐欺(銀行の場合)が他にもあります。これは、潜在的なインテリジェンスの顧客/利害関係者のタイプすべてではありませんが、最も一般的なタイプです。インテリジェンスの顧客を特定したら、次に、顧客と協力して、顧客のインテリジェンス要件/ニーズを理解し、優先順位を付ける必要があります。これは難しいプロセスです(ほとんどの人はインテリジェンス機能を使用する方法や優れたインテリジェンスの顧客になる方法を知りません)が、これの最終結果は組織の優先インテリジェンス要件またはPIRです。PIRの開発については、下部にあるリンクを参照してください。

PIRを文書化したら、利害関係者のインテリジェンスのニーズに答えるのに役立つもの/データを観察できる可能性のある場所を確認できます。典型的なソースは、内部テレメトリ(ネットワーク全体で起こっていること、以前のインシデントなど)、オープンソース(Pastebin、ソーシャルメディア、ニュース記事など)、クローズドソース(犯罪者の地下または「ディープアンドダークウェブ」ですが、情熱を持ってその用語は嫌いですが、犯罪者との直接的なオンラインエンゲージメント)、あなたのセクターの他の組織との共有(直接またはISACを介したものなど)など。これは、研究者またはインテリジェンスコレクターがインテリジェンスプロセス内に位置する場所です。

たくさんのコレクションを入手したら、なんとかして処理する必要があります。多くの組織(多くのソースがある)は、脅威インテリジェンスプラットフォーム(TIP)または分析プラットフォームを使用してこれを管理しています。

次に、インテリジェンスサイクルの分析部分があります。これは、人々が収集されたものと、それが何が起こったのか、推定確率のレベル(可能性が高い、可能性が高い、可能性があるなど)を付けて将来起こりそうなことの全体像を形成するのにどのように役立つかを見る場所です。100%事実に基づくものを調べるために分析チームは必要ありません。次に、アナリストはさまざまなタイプのインテリジェンス製品を作成し(オーディエンスに基づいてさまざまなタイプのインテリジェンス製品、つまりCISOはセキュリティオペレーションセンターとは異なるインテリジェンスニーズと配信形式を持ちます)、適切な利害関係者に配布します。その後、フィードバックが受信され、それに基づいて、インテリジェンスサイクルがいくつかの追加要件で再開される可能性があります。

これにより、典型的なサイバー脅威インテリジェンスチーム内で次のような役割が与えられます。
  • インテリジェンスリーダーまたはマネージャー。彼らはプロセスをエンドツーエンドで担当します。関係者と協力してインテルのニーズを理解し、フィードバックを受け取り、チーム/機能を管理するなど。

  • 技術研究者/アナリスト。通常、インテリジェンスサイクルの収集部分に含まれますが、分析部分にも含まれる場合があります。技術的な消費者(SOC、ハント、IRなど)向けに技術データを収集したり、技術に焦点を当てたインテル製品を作成したりします。通常、TIP、統合などの技術ツールの実行/構成にも関与します。

  • 従来の情報アナリスト。通常、インテリジェンスサイクルの分析部分に含まれます。通常、経営幹部向けのインテル製品の作成、戦略的インテルタイプの製品、戦術的でない聴衆へのプレゼンテーションなど、より伝統的なインテリジェンス分析タスクに関与します。伝統的に、政府、法執行機関、諜報機関などでの経験があります。
私たちが書いた他のブログ(Intel 471)は、もっと読みたい人のために書いています。

【転載】闇サイトで不正操作プログラムを販売 容疑の男を逮捕



闇サイトで不正操作プログラムを販売 容疑の男を逮捕:

【ニュース】

◆闇サイトで不正操作プログラムを販売 容疑の男を逮捕 (朝日新聞, 2020/11/04 19:17)
https://www.asahi.com/articles/ASNC4663DNC4OIPE00K.html?iref=comtop_BreakingNews_list


【関連まとめ記事】

全体まとめ

◆闇サイト / ダークウェブ (まとめ)
https://malware-log.hatenablog.com/entry/Dark_Web

ーー

 パソコンに感染して遠隔操作するマルウェア(悪意あるプログラム)を、闇サイトで専用ソフトを使わないと閲覧できないネット空間「ダークウェブ」の掲示板サイトで購入者を募り、販売したとして、愛知県警は4日、自称フリーカメラマンの沢田海成容疑者(21)=千葉県白井市=を不正指令電磁的記録保管・提供などの疑いで逮捕し、発表した。容疑を認めているという。


 サイバー犯罪対策課によると、沢田容疑者は6月3日~8月13日、マルウェアの一つ「DarkComet(ダークコメット)」の圧縮ファイルを、自らが所有する外付けのハードディスクに保存したほか、6月3日にはこの圧縮ファイルの購入を希望した男性に販売した疑いがある。


 ダークコメットは、感染したパソコンを不正に操作し、データ閲覧や改ざん、外部への送信、カメラの起動などを行う。同課によると、沢田容疑者は何らかの方法でファイルを入手したとみられ、マルウェアを1ファイル3万円で販売するという趣旨を掲示板に書き込んでいたという。


 この書き込みを県警の捜査員が5月中旬に発見。沢田容疑者は、同じ掲示板に違法薬物や架空口座の販売をほのめかす書き込みもしていたといい、県警はマルウェア以外にも5~7月に少なくとも90万円を売り上げていたとみている。

【転載】IPAが「ソフトウェア脆弱性関連情報管理シート」を公開。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。

EjUy10CVgAA7vfz.jpg:large
さとっぺ retweeted: 「ソフトウェア脆弱性関連情報管理シート」を公開しました。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。 ipa.go.jp/security/techn…:

さとっぺ retweeted:

「ソフトウェア脆弱性関連情報管理シート」を公開しました。社内で利用しているソフトウェアの情報と公表された脆弱性情報を一元管理するためのツールで、「どのレベルの脆弱性ならいつまでに対策する」といった社内ルールを決め、対策を実施するのにお役立ていただけます。

ipa.go.jp/security/techn…

EjUy10CVgAA7vfz.jpg:largeEjUy3fpU4AEfnoh.jpg:large



バックアップ

【転載】トランプ大統領のパスワード

 


トランプ大統領のパスワード

トランプ大統領は大統領選挙での劣勢が伝えられていますが、逆転に向けてこの脇の甘さが問題となるかも知れません。

jp.techcrunch.com

オランダのセキュリティ専門家が、トランプ大統領のTwitter(ツイッター)アカウント、@realDonaldTrumpのパスワードを推測してアクセスすることに成功したという。パスワードは「maga2020!」だった(パスワードはすでに変更されている)。

GDI Foundationのセキュリティ研究者でセキュリティ脆弱性を見つけて報告するDutch Institute for Vulnerability Disclosure(オランダ脆弱性公表機関)の代表を務めるVictor Gevers(ビクター・ゲバーズ)氏はTechCrunchに、大統領のアカウントパスワードを推測し、5回目の試みで成功したと語った。

アカウントは2段階認証で保護されていなかったため、ゲバーズ氏のアクセスを許してしまった。

(Tech Crunch記事より引用)

 

 

キタきつねの所感

ホワイトハッカーによる疑似ハッキングは、ホワイトハウスの副報道官は「まったく真実でない」と否定していますが、大統領のSNSセキュリティのコメントを拒否した様ですので、疑似ハッキングは成功してしまったのかと思います。

とは言え、大統領選の終盤のこの時期にこうした「ニュース」をぶつけてくる事に、何かの”意図”を感じなくもありません。

 

それはさておき、仮にこの件が本当だったとして、ホワイトハッカーに突破されたパスワードは、何故5回の試行で破られてしまったのでしょうか?少し真面目に漏えいしたとされる、パスワード強度を考えてみます。

 

「maga2020!」

 

パスワードの構成上は、英小文字、数字、記号が使われており、パスワード長は9文字とまずまずの長さです。しかし、”2020”と”!”はパスワード保有者にとってユニーク(特有なもの)とは言えません。

”2020”は誰でも「今年」の事を指す事は分かると思いますので、パスワード桁数を増やす事には貢献しても、構成要素とては弱いかと思います。記号の”!”もユニークではありませんので、このパスワードの肝となるのは、【maga】となる事は明らかです。

 

この単語・・・どこかで見覚えがあるなと思った貴方!正解です。

 

『Make America Great Again』の頭文字以外の何物でもありません。

 

そりゃ・・・パスワード破られても不思議ではないですね。

 

(ホワイト)ハッカーは、攻撃をする際に、対象者(トランプ大統領)のSNS等から情報を拾い、例えば誕生日であるとか、ペットの犬の名前であるとか、今回の様に『選挙キャンペーンフレーズ』をパスワード候補として攻撃してきます。

 

今回の【maga】は、「容易に推測できるパスワード」(の一部)だったと言えるのです。

 

とは言え、このパスワード(mage2020!)、強度がすごく弱いという訳ではありません。仮に、大統領選の対立候補であるバイデン氏が使っていたとしたら、ホワイトハッカーは恐らく破れなかったと思います。

 

参考まで、パスワードチェッカーとして有名な「How Secure Is My Password?」では、16時間で解読されるとの評価です。

f:id:foxcafelate:20201024062301p:plain


同じく、パスワードチェッカーとして評価が高い「Kaspersky Password Checker」では、28日の評価結果です。

f:id:foxcafelate:20201024062504p:plain

 

もう1つ。過去の漏えい事件で流出したパスワードかどうか分かる「Pwned Passwords」では、驚くべき事に『流出したという事実が無い』と評価されました。

f:id:foxcafelate:20201024062358p:plain

 

 

私でしたらどうやってトランプ大統領のパスワードをベースを変えずに強化するか、と考えると・・・

 

単純な手法としては、記号を増やします。(最初に入れると見破られそうですが)これだけでも意外とホワイトハッカーの攻撃は凌げたと思います。

 例)『maga20!20!』『ma#ga2020!』

 

記号を2つ使うと(その記号を置く位置も併せて)試行すべき組み合わせが膨大に増えますので、ハッカー側は結構大変かと思います。単語(magaや2020)の間に挟むとより複雑性が増しますのでオススメです。

 

もう1つの手法として、(私のオリジナルという訳ではありませんが)、他の要素と関係性の無い単語を増やします。

 例)『mage2020!JAPAN』『mage2020!yankees

 

日本やニューヨークヤンキース(出来ればファンでない所が望ましい)といった、選挙やトランプ大統領とあまり関係が無くSNS上でも出てこない単語(※ここが重要です)が1つ入っただけで、例えツール攻撃したとしても、ハッカーがパスワード解読にかかる時間は膨大なものとなるかと思います。 

トランプ大統領アカウントのハッキング、事実だとすれば、非常に重要なTwitterアカウントであるが故に(下手な事をつぶやくと国際問題や世界の株価に大きく影響する)、大統領や大統領陣営はもっとSNSのセキュリティにも気を遣うべきだったかと思います。もし何でしたら酒席セキュリティ担当として雇って下さい。

とは言え、パスワード強化よりも先に『2要素認証』を設定すべきだとは思いますが。

 

※どこがオリジナルか分からないのですが、複数の関係ない単語を使った強力なパスワード作成手法について、英語圏で広く出回っている説明イラストを参考まで貼っておきます。

XKCDマウスオーバー:情報理論とセキュリティを理解していて、そうでない人(おそらく混合ケースを含む)と腹立たしい議論をしている人には、心からお詫び申し上げます。

 

 

余談です。日本だとオランダのセキュリティ専門家(ホワイトハッカー)の『疑似ハッキング』行為は、不正アクセス禁止法(3年以下の懲役または100万円以下の罰金)に引っかかります。

その事自体は当然の事とは思いますが、私は認められたホワイトハッカー企業や個人に、制約付きで同様な脆弱性調査を認めるべきでないかと思います。

【転載】コインチェックのインシデント対応レポート~AWSのイメージが良くなり、ドメインレジストラのイメージ悪化~


ある日突然、自社ドメインが乗っ取られた――“原因も手口も不明”の攻撃に、セキュリティチームはどう立ち向かったか - ITmedia エンタープライズ

 2020年6月、仮想通貨取引所「Coincheck」を運営するコインチェックのコーポレートサイトに、あるセキュリティインシデントの報告書が掲載された。当時、重要な事例として筆者のセキュリティ連載「半径300メートルのIT」でも取り上げたことから、記憶に残っている読者もいるのではないだろうか。


 インシデントのあらましを簡単に説明しよう。これは、コインチェックが利用する外部のドメイン登録サービスにおいて、コインチェックのネームサーバ(DNS)情報が、何者かに書き換えられたものだ。これにより、同社のドメインのレコードが偽のDNSに登録され、同社にメールで問い合わせた顧客のメールアドレスと本文が第三者に流出する可能性があった。コインチェックはインシデント発生後、対応についてのレポートを公開するとともに、利用するドメイン登録サービスを変更したと発表した。


 このインシデントは、一般に「不正アクセス」という言葉から連想する事件とは異なり、一見地味な印象を受けてもおかしくないものだ。しかし、報告書には、セキュリティ担当者ならば誰でも青ざめるような展開が赤裸々につづられていた。

コインチェックによるインシデントの第1報(出典:コインチェック)

 ITmedia エンタープライズ編集部は、実際に同社でインシデント対応に当たった喜屋武 慶大氏(サイバーセキュリティ推進部長)に講演を依頼。2020年9月に開催したオンラインイベント「ITmedia Security Week 秋 - ITmedia エンタープライズ」の特別講演として、当時の様子を当事者の目線で振りかえってもらった。その内容は、セキュリティ担当者だけでなく組織でITに関わる人ならば誰もが非常に参考になるものだった。本稿は喜屋武氏の講演の内容をレポートする(注)。

注:本稿はITmedia エンタープライズ主催「ITmedia Security Week 秋」の講演「ドメインが乗っ取られた!!そのとき我々はどう対応したか」を基に再構成した。

 読者の皆さんには「自分がもしもセキュリティ担当者なら、気付くことができただろうか」と問いかけながら、目を通していただきたい。

2020年6月1日正午ごろ:「何かがおかしい」という報告から全てが始まった

 その日(インシデント発生当日)、最初に違和感に気付いたのは、社内のSRE(Site Reliability Engineering:サイト信頼性エンジニアリング)チームだった。

「ITmedia Security Week 秋 - ITmedia エンタープライズ」に登壇し、インシデント対応の様子を語ったコインチェックの喜屋武 慶大氏(サイバーセキュリティ推進部長)

 2020年6月1日正午ごろ、コインチェックで通常の監視業務に当たっていたSREチームは、普段と異なる状況を察知した。前日に比べて自社サービスに対するリクエスト数が異常に少なかったのだ。

 「『何かがおかしい。怖い』という報告が、SREチームから社内で使う『Slack』のワークスペースに上がってきた。それが発端だった」(喜屋武氏)

 SREチームはまず、リクエスト数の激減以外にも何か異常がないかどうかをチェックした。すると、前日の5月31日を境にサービスのレスポンスタイムが遅延していることが分かった。「この時点では誰もDNSの書き換えという結論は想像していなかった」と喜屋武氏は振り返る。

 「Slackでのやりとりをはた目で見ながら『何か障害でも起きたのだろう、あとで共有してもらえばいい』と思っていた」(喜屋武氏)
リクエスト数が減少し、レスポンスタイムが遅延していたことが、インシデント検知につながった(出典:コインチェック)

 この違和感をきっかけに、SREチームは本格的な調査に乗り出した。しかし原因はなかなか見つからない。アプリケーションには異常がなく、サーバもロードバランサーも問題がないように見える。ただし、喜屋武氏によれば、ユーザーの感覚としては普段と変わらないように見えても、モニタリングダッシュボードに示されるレスポンスタイムはどんどん遅延していったという。リクエスト数は減っているにもかかわらずだ。

6月1日午後:レスポンス遅延が悪化 「障害ではなく、攻撃だ」と気付いたきっかけ

 6月1日の午後になると、レスポンス遅延はさらに進み、体感で分かるレベルになってしまった。また、全ての社員ではなく、特定のメンバーに限ってレスポンス遅延が発生していることも分かってきたという。

 原因を突き止めようと、SREチームは、遅延が確認できた環境から経路を確認するtracerouteコマンドを実行した。すると、通常ならば数ホップで同社が利用する国内のAmazon Web Services(AWS)まで到達するはずのリクエストが、なぜかアムステルダム(オランダ)のリージョンにあるAWSのCDN(Content Delivery Network)サービス「Amazon CloudFront」を経由していた。

 これこそがレスポンスの遅延の原因と思われたが、そもそもなぜリクエストがオランダを経由するのかが分からない――。不審に思った喜屋武氏は、AWSのサポートに連絡を取った。コインチェックがインシデント対応に奔走する“長い夜”は、この時点で既に始まっていた。

 喜屋武氏が「権威DNSに何か問題があるのでは」とAWSのサポートに確認したところ、返ってきた答えは「これはAWSのDNSではない」だった。同氏はその際の反応について「『えっ!』と驚くしかなかった」と話す。このやりとりをきっかけに、AWSのCDN(Content Delivery Network)サービス「ns-1515.awsdns-61.org」に0を足して「ns-1515.awsdns-061.org」にすり替える、一見しただけでは気付かないような手口だった。

whois情報を見るとDNSの指定が書き換わっていた(出典:コインチェック)

 この時点からインシデントが一段落するまで、SREチームはAWSのサポートとのやりとりを重ねることになった。

 「(違和感に気付いた当初は)ひょっとしたらAWSの障害が原因ではないかと思って問い合わせたことをきっかけに、結果として別の原因が判明した。しかし、その後もAWSのサポートは(インシデント対応に)付き合ってくれた。こういうときに素早く反応してもらえたので、サポート契約していて良かったと感じている」(喜屋武氏)

2020年6月1日夕方:レジストラが乗っ取られていたことが判明

 6月1日夕方ごろ、本格的なインシデント対応が始まった。まずは、システム担当の執行役員に対して、これまでのいきさつを報告した。また、状況報告に使うコミュニケーションツールをSlackからWeb会議サービス「Zoom」に切り替えた。「Zoomが詰め所のような形になり、そこに参加する形で執行役員に指揮を執ってもらった」と、喜屋武氏は語る。

 状況を報告されたシステム担当の執行役員は、想定しない報告に当初「えっ!」と驚くのみだった。後日、役員は喜屋武氏に「重めのシステム障害を想定していたため(サイバー攻撃を受けたと報告が来た際は)何を言われているのかさっぱり分からなかった」と明かした。

 DNSが改ざんされたと分かった以上、初動対応として、コインチェック側はレジストラにログインし、DNSを元に戻そうとした。しかし、IDとパスワードを使ってもログインできない。パスワードをリセットしようとすると、今度はリセットのためのメールがコインチェックに届かない――。つまり、この時点で、レジストラのIDは完全に乗っ取られてしまっていた。

 喜屋武氏がドメイン名を検索して状況を確認すると、日本時間で5月31日の深夜にDNSレコードがアップデートされていた。もちろん、コインチェック社内でその時間に当該の操作をした者はいなかった。5月31日深夜を境にレジストラの登録情報が乗っ取られ「coincheck.com」が奪われてしまった。コインチェックがこの事実を把握したのは、6月1日の19時過ぎだった。

調査の過程で見覚えのないMXレコードが見つかったことで、レジストラが乗っ取られていたことが判明した(出典:コインチェック)

 タイミングの悪いことに、新型コロナウイルス感染症(COVID-19)の影響でレジストラの電話サポートなどが縮小されていた。コインチェックはレジストラにメールで対応を依頼したが、その時点でレジストラの営業時間外だったため、最悪対応が翌日になってしまうことも考えられた。このタイミングで、コインチェックは社外のセキュリティアドバイザー2人にも状況を報告し、インシデント対応に参加してもらうことになった。

2020年6月1日夜:なぜ、どうやって攻撃された? 長い捜索が始まる

 DNSが不正に書き換えられてしまった場合、それを元に戻せるのはレジストラだけだ。レジストラの対応を待つ間、コインチェックは、今回のインシデントの根本原因を探る調査を開始した。

 この時、真っ先に疑われたのはマルウェア感染による不正アクセスだった。しかし、喜屋武氏がログを確認したところ、社内の端末にマルウェア感染は確認できなかった。不審なアクティビティーがないかどうか、未知のマルウェア攻撃がある前提で調査を継続したが、エンドポイントからのアラートも上がっていない。操作ログや通信ログ、プロセスログにも、それらしい痕跡はなかった。喜屋武氏は「マルウェア攻撃が原因である可能性は低い」と判断し、次の調査に移ることにした。

 マルウェア以外に、アカウント乗っ取りやパスワードクラック、セッションハイジャックなどが原因になっている可能性もあった。このうち、アカウント乗っ取りが発生していれば、他のサービスを攻撃されている可能性も高い。しかし、シングルサインオン(SSO)ログやSaaSのログイン履歴に不審な点はなかった。セッションハイジャックの可能性も低かった。レジストラに最後にログインした日時がかなり前であり、5月31日時点では有効ではないことが確認できたためだ。

 「パスワードに関しては、サービスで設定できる最長の文字数を、パスワードジェネレーターで生成している。それなりの強さであり、総当たりでパスワードクラックを行うことは不可能。使い回しもしていない」(喜屋武氏)

 残された可能性は、レジストラの脆弱(ぜいじゃく)性だった。調査に参加したセキュリティアドバイザーからは「海外でもレジストラの脆弱性をきっかけとした攻撃が発生している」というコメントを得ていた。この時点では可能性の一つでしかなかったが「結果的には、レジストラの脆弱性が原因だった」と、喜屋武氏は話す。

 「もしレジストラの脆弱性が原因だったなら、(他の事業者も対象にした)攻撃キャンペーンがあるはずだと考えたが、当社以外に攻撃されているという情報がなかった。念のためレジストラにログインした端末は隔離し、他のサービスにもサインオンできないようにした」(喜屋武氏)

 調査が進む中、2020年6月1日20時52分ごろ、レジストラから「DNSの情報を元に戻した」という連絡が来た。この時点で、コインチェックではシステム担当執行役員から社長にインシデント発生の報告を上げていた。同社は社内で制定済みの対応フローに従い、緊急事態対策本部を設置した。

2020年6月1日深夜:ドメインがついに回復 判明した衝撃の手口とは

 DNSは元に戻ったものの、この時点では、インシデントが社内やユーザーを含めてどの程度の範囲に影響を与えたのか、明確に見えていなかった。影響範囲の確認を兼ねて調査を続けていると、DNSに不審なMXレコードが設定されていることが判明した。攻撃者は、コインチェックのメール情報を盗もうとしていたのだ。

 「不正に設定されたIPアドレスを確認すると、coincheck.comを返すメールサーバが動いていた。しかし、SPFレコードの設定が書き換えられていなかったため、coincheck.comを送信元とするメールを送信することが狙いではなさそうだった」(喜屋武氏)

 この動きを確認した時点で、時刻は6月2日の深夜1時を過ぎようとしていた。DNSは無事に取り戻せたが、インシデントを引き起こした攻撃の詳細や原因はまだ分かっていなかった。この状況では、攻撃者が再びDNSを改ざんできてしまう可能性もある。喜屋武氏は自分とSREチームの1人を残して他のメンバーを解散させ、2人体制の監視に入った。そして、全社員のメールボックスをくまなくチェックし始めた。

 すると、重大な事実が見えてきた。複数の社員のメールボックスの中に「GitHub」をはじめとする複数のサービスからパスワードリセットのメールが大量に届いていたのだ。該当の社員にヒアリングしたところ、彼らは一様に「パスワードをリセットするような操作はしていない」と答えた。実際に、喜屋武氏は社員の操作履歴を精査し、成功したパスワードリセットのリクエストがなかったことを確認した。

 ここまでの状況から、初めて攻撃の全体像が見えてくる。

 「レジストラの情報を書き換えることで、攻撃者が用意したサーバに問い合わせさせ、偽のレコードを引いてくる。これにより、攻撃者がcoincheck.comに届くメールを不正に取得した」(喜屋武氏)

 攻撃者はDNSを直接攻撃せずに、レジストラを攻撃することでDNSを乗っ取ったのだ。

判明した攻撃の全体像(出典:コインチェック)

2020年6月2日:プレスリリース第一報を公開、そして……

 翌日の6月2日、コインチェックは、朝、昼、夕方の定期Webミーティングを設定した。Web会議には指揮官であるシステム担当の執行役員に常にオンライン状態でいてもらい、進捗(しんちょく)を報告した。Web会議を対策本部にするスタイルはあくまでもCOVID-19対策だったが、これが意外な効果を生んだ。

 「リアルな会議室でホワイトボードを前にするようなこれまでの会議スタイルとは異なり、Web会議なら作業をしながらでも報告ができる。そこに入れば誰かがいて、助言をもらえる。振りかえると、この体制はとてもやりやすく、メンバーのから評判も良かった」(喜屋武氏)

 ユーザーのサポート窓口となるメールアドレスで利用しているドメインは、すでに攻撃の対象となっていた。ユーザーへの悪影響を防ぐため、コインチェックは新たに「coincheck.jp」のメールアドレスを設定し、動作を確認した上で、インシデントについて記したプレスリリースを公開した。その後の展開は、ITmedia エンタープライズやその他の報道で皆さんもご存じのことだろう。

被害を増やさないために――担当者が語る予防策

 喜屋武氏は今回のインシデントを振り返り「本物に酷似したドメイン名をDNSに設定されてしまう攻撃例は、知る限り世界初ではないか」と話す。この攻撃の恐ろしい点は、いったんドメインを乗っ取られ、MXレコードを書き換えられてしまうと、自分が正規のユーザーであることを証明する手段がほとんどなくなってしまうところだ。このような手口は、社内で使うサービスのパスワードがメールを使ってリセットされる設計の弱みを突いたようにも見える。

 視聴者に向けたメッセージとして、喜屋武氏は「(今回のインシデントからは)ドメイン乗っ取りの被害が甚大であることを確認できた。DNSはとても大事なサービスだ。このインシデントを参考にし、レジストラに登録したDNSの設定はしっかり監視してほしい。また、権威DNSに使っている関連サービスのアカウント管理情報やレコードは定期的にチェックしてほしい」と話し、講演を締めくくった。


サイバー保険でインシデント対応の費用が賄えるのか?

記事を読んでいたら、相反する2つトピックを見つけた。

1つ目が、サイバー保険を付帯した標的型攻撃メール訓練のニュースで、インシデント費用を最大600万円補償するというもの。

2つ目は、インシデント発生時における対応費用の実態が約1.5億円となっているというもの。

1件目のサイバー保険を付帯した標的型攻撃メール訓練で、インシデント対応費用が最大600万円で全然足りないのは何となく理解できる。

グリコのおまけ的な扱いであることを認識していれるか、とりあえず「サイバー保険導入」の事実を成立させたい組織には向いているが、リスクファイナンスを真剣に考えるとあり得ない選択だと思う。

■記事1

サイバー保険を付帯した標的型攻撃メール訓練をOEM供給:

ラックは、パートナー向けにサイバー保険を付帯したトレーニングサービス「サイバー保険付き標的型攻撃メール訓練 プレミアム」を提供開始した。

同製品は、疑似的な標的型攻撃メールを従業員へ送付する体験学習型の訓練プログラム「ITセキュリティ予防接種」にサイバー保険を付帯したもの。

同社の販売パートナーチャネル向けにOEM供給し、パートナーは自社製品やサービスに組み込んだり、オリジナルサービスとして販売することができる。

損害保険ジャパンを引き受け保険会社とするサイバー保険を付帯。訓練を実施した企業において、サイバー攻撃に関する調査費用をはじめ、復旧や再構築費用、損害賠償金について最大600万円まで補償する。

■記事2

約4割でインシデント被害、対応費用は約1.5億円 - 4.4%が「Emotet」経験:


国内法人における約4割のセキュリティ担当者が、セキュリティインシデントに起因する被害を経験したとする調査結果をトレンドマイクロが取りまとめた。被害への対応や改善策の導入などで約1億4800万円の費用が生じていたという。


同社が6月に国内法人においてインシデント状況を把握しているリスク管理、ITシステム、情報セキュリティなどの担当者1086人を対象にインターネット調査を実施し、結果を取りまとめたもの。所属組織の内訳を見ると民間企業が980人、官公庁自治体が106人となっている。


2019年4月から2020年3月の1年間に被害の有無に関係なく、何かしらのインシデントを経験した回答者は78.5%だった。インシデントの内容を見ると、「フィッシングメールの受信」が42.8%でもっとも多い。


ついで「ビジネスメール詐欺のメール受信」が29.1%と多く、「不正サイトへのアクセス(26.5%)」「標的型攻撃(22.2%)」「ランサムウェア感染(17.7%)」と続いた。

約1割で「DDoS攻撃」「内部不正」が発生していたほか、「システムの脆弱性の悪用(11.4%)」や「システムの設定ミスの悪用(7.6%)」などシステムの問題を突く攻撃なども見られる。さらに4.4%は、マルウェア「Emotet」を経験していた。一方、21.5%はインシデントが発生していないと回答している。


【転載】イミュータブルインフラストラクチャとは?


イミュータブルインフラストラクチャってご存じだろうか?

【解説】

「イミュータブル」とは「変更不可能な」という意味で、言い換えると「一度作成したら、その状態を変えることができない」と表現することもできます。反対語は「ミュータブル (変更可能な)」となります。

現実世界の例を出してみましょう。例えば「重要な書類を書く場面」を想像してみるのはいかがでしょうか ? ボールペンで書類を書くことを「イミュータブル (変更不可能な)」だとすると、鉛筆で書類を書くことを「ミュータブル (変更可能な)」と考えることができます。

 【メリット】

1. 書類を書き換えられなくなる

ボールペンで書類を書くことにより、書類を書き換えられなくなるというメリットがあります。重要な書類のほとんどはボールペンで書くことにより、書いた内容を保証しています。これは「一度書いた書類の状態を変えることができない」と言い換えることもできます。提出した重要な書類を勝手に書き換えられてしまったら困ります。

2. 書類が汚れない

例えば、住所を書き間違えてしまうこともあります。そのときに鉛筆で書類を書いていれば、繰り返し書き換えられるため便利に感じるかもしれません。しかし、実際には消しゴムを使って消すことになります。消そうと思っても「キレイに消えなかったり」、消えるには消えたけど「消しカスが大量に出てしまったり」、繰り返し書き換えることにより、書類が汚れてしまいます。書き換えによって書類が汚れないという点もメリットの 1 つと言えます。

【まとめ】

本記事では、重要な書類を書く場面を比喩に「イミュータブル」を紹介しました。実際のワークロードでは、例えば Amazon EC2 インスタンスを「イミュータブル」に運用し、修正をする場合には新しくインスタンスを作り直せる仕組み作りが重要です。

【所感】

イミューダブルインストラクチャとは、インフラ(OS、ミドルウェア)へのパッチ適用は一切行わず、脆弱性が見つかったら、脆弱性対策が行われた最新版のインスタンスに移ることで脆弱性対策を行うということである。

つぎはぎでパッチ適用を行う事が将来的なシステムの安定化に危害を及ぼすという考え方で、IaaSならではの発想である。

実際はOSやミドルのバージョンが変わっちゃうとその上のアプリも影響を受けてしまうため、運用工数といった観点では地道にパッチ適用するのと変わらない気がする。

ただ、脆弱性対策の観点でこのようなアプローチがあるというのはとても勉強になった。

【参考】

https://aws.amazon.com/jp/builders-flash/202005/metaphor-immutable/

【転載】IT技術用語における「疎結合」とは?


 【例文】

アプリケーションを「疎結合」にする

マイクロサービスは「疎結合」な特性を持っている

【解説】

「疎結合」とは「結合度を緩める」という意味で、言い換えると「独立性を高める」と表現することもできます。反対語は「密結合」となります。

現実世界の例を出してみましょう。例えば「年賀状など、手紙を送る場面」を想像してみるのはいかがでしょうか ? 手紙を郵便ポストに投函することを「疎結合」だとすると、郵便局で配達員に直接手渡しすることを「密結合」と考えることができます。

【メリット】

では、現実世界の例をさらに深堀り、メリットを考えましょう。

1. 郵便局の営業時間を気にせずに手紙を送れる

郵便ポストに投函することにより,郵便局の営業時間を気にせずに手紙を送れるというメリットがあります (24 時間営業ではないという前提とします)。郵便ポストさえあれば、好きなときに投函できますよね ! これは「手紙を送ること」と「配達をすること」の「結合度を緩めている」と考えることもできます。

2. たくさんの手紙を投函できる

年賀状の時期など、たくさんの手紙を送る場面もあるでしょう。もし郵便局で配達員に直接手渡しをしてしまうと、もしかしたら配達員の手が回らなくなってしまう可能性もあります。さらに受付に順番待ちができてしまうかもしれません。郵便ポストさえあれば、たくさんの手紙も投函しておくことができます。これも「結合度を緩めている」からこそ得られるメリットと考えることができます。

3. 定期的に回収できる

配達員の視点で考えると、手紙を直接手渡しで受け取るよりも、好きなタイミングに郵便ポストから回収できた方が柔軟です。「結合度を緩めている」からこそ、配達員の「独立性を高められている」と考えることができます。

【まとめ】

実際のワークロードでは「レポート生成処理」や「画像変換処理」において「疎結合」を意識すると良いでしょう。AWS では、例えば Amazon SQS を活用した「疎結合アーキテクチャ」を構築することができます。アプリケーション A と アプリケーション B の「結合度を緩める」というイメージです。

【所感】

所謂3層構造と言われる、Web、アプリ、DBサーバをそれぞれ分離して構築することも「疎結合」の範疇に入る。

セキュリティ的な要素のイメージが強いが、システムの安定稼働(障害発生時の影響範囲を限定する)の観点でも意味のあるポイントと言える。

【参考】

https://aws.amazon.com/jp/builders-flash/202003/metaphor-loose-coupling/