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

 


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

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

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/

【転載】できる人のGoogle検索テクニック



🧐やらないけどけど:

🧐やらないけどけど

EjN7EPWVkAA85k7.png:large



できる人のGoogle検索テクニック



 インターネットで何か調べようとするとき、まず「Google検索」、という人が多いのではないだろうか。中でも、単語を入力する、もしくは複数の単語をスペースを空けて入力して検索するだけという人が多いようだ。
 実はGoogle検索には、「検索演算子」と呼ばれる、特殊な検索条件の指定方法があり、これらをうまく使うと、より効率的な検索も行える。他にも、知っておくと便利な検索テクニックが幾つかあるので、ここでまとめて紹介しよう。

検索演算子を使いこなそう

●「+」/「AND」で複数キーワードを含むWebページを検索
 AND検索を行うのに、「スペース(空白文字)」を空けて複数キーワードを並べて検索、というのは、ごく普通に利用しているテクニックだろう。さらに明示的にAND検索をするには、キーワードを「+」または「AND」で追加していくとよい(「AND」は大文字にして、単語間にはスペースを空けること)。
 例えば、「ITmedia AND @IT」といった具合に検索すると、両方のキーワードを含むWebページが検索対象となる。単に「スペース」を空けた場合と、「AND」で挟んだ場合では、同じAND検索のはずなのだが、検索結果が微妙に異なることがある。単にスペースを空けた検索でうまく絞り込めない場合は、「AND」を使ってみるとよい。
「AND」を使った複数キーワードの例「AND」を使った複数キーワードの例
●「OR」でいずれかのキーワードが含まれているWebページを検索
 Google検索では、検索キーワードの補完機能があるため、例えば大文字と小文字や平仮名と片仮名などは、どちらでも同じような検索結果が得られることが多い。例えば、「マイクロソフト」と「Microsoft」では、ほぼ同じような検索結果となる。そのため、わざわざ両方のキーワードを「OR」で並べるOR検索の必要性はそれほど高くないかもしれない。
 ただ「ITmedia」と「@IT」のように異なるキーワードのどちからを含むWebページを検索したいような場合、OR検索を使うと、両方の検索キーワードを検索した結果を合わせたものが得られる(「OR」は大文字で、キーワード間に「スペース」を空けること)。
「OR」を使った複数キーワードの例「OR」を使った複数キーワードの例
●「-」で特定の検索キーワードを含まないWebページを検索
 複数の検索キーワードのうちで、特定の検索キーワードを含まないような結果を得たい場合、除きたいキーワードの前に「-(半角マイナス)」を付けるとよい。
 例えば、「マック」について調べたいが、「マクドナルド」については除外したいような場合、Googleの検索ボックスに「マック -マクドナルド」と入力すれば、「マック」の検索結果から、「マクドナルド」が含まれるWebページが除外されるため、1回で検索結果の絞り込みが行える。
「マック」のみで検索すると「マクドナルド」に関するWebページも検索対象となる「マック」のみで検索すると「マクドナルド」に関するWebページも検索対象となる
「マック -マクドナルド」と検索することで「マクドナルド」に関するWebページを検索対象から外す「マック -マクドナルド」と検索することで「マクドナルド」に関するWebページを検索対象から外す
●「*」で検索キーワードを補完して検索
 人の名前や地名など、うろ覚えで正確に思い出せないような場合、検索キーワード内に「*(アスタリスク)」を挿入するとよい。アスタリスク(*)の部分が適当に補完されて検索が実行される。
●「"<キーワード>"」で複数語の完全一致検索
 キーワードにスペースが含まれるような場合、そのまま検索してしまうと、上述の通り、AND検索になってしまい、思ったような検索結果が得られないことがある。
 例えば、「Windows 10」を検索するような場合、そのまま検索すると「Windows」と「10」を含むWebページが検索結果として得られてしまい、「Windows 10」以外にも、「Windows」と「10年」といった「Windows 10」に関係ないWebページも対象となってしまう。
 このような場合、キーワード全体を「"」で挟んで「"<キーワード>"」といったように検索すると、スペースを含む語句の「完全一致」で検索が行われる。
 例えば、「"Windows 10"」として検索を行えば、「Windows 10」が完全一致で含まれるWebページが検索結果として得られる。ただし、「Windows 10」のような「メジャーなキーワード」は、Google検索側で適宜補完処理され、完全一致として優先して検索される。そのため、あえて「"」で挟まなくても、ほぼ同じ結果が得られるようだ。
●「@」でソーシャルメディアを検索する
 Twitterやインスタグラムなど、ソーシャルメディアを情報の入手先とする人も多くなっている。そのためソーシャルメディアを優先した検索を行いたいという場合もあるだろう。そのような場合、検索キーワードの後にスペースを空けてから、ソーシャルメディアの名前の前に「@(半角アットマーク)」を付けて指定すると、そのソーシャルメディアが優先された検索が行われる。
 例えば、「山手線 遅延 @twitter」と検索すると、山手線の遅延に関するTwitter上のツイートなどが優先されて検索される。同様に「@instagram」とすれば、インスタグラム上の画像なども検索可能だ。
「@」を使ってTwitterを検索した例「@」を使ってTwitterを検索した例


意外と便利な特別構文検索

●「site:<URL>」でサイト指定の検索
 「site:」は、すでに使っている人も多いだろう。 「site:」に続けてURLを指定すると、そのURLのサイトまたはドメイン内だけを対象とした検索が行われる。例えば「Windows site:http://www.atmarkit.co.jp/」と指定すると、@ITサイト内だけで「Windows」というキーワードが検索される。特に、検索機能がないWebサイト内を検索する際に便利な機能だ。
●「cache:<URL>」でキャッシュに保存されたバージョンを表示
 <URL>で指定されたWebページを、Googleに保存されたキャッシュの中から探して表示する。場合によっては、修正前のWebページや削除されたWebページを見ることができる。
「cache:」を使った検索出力例「cache:」を使った検索出力例
●「link:<URL>」で被リンクを検索
 <URL>で指定したバックリンク(被リンク)情報を表示する(指定された<URL>をリンク先として含むページを表示する)。リンク元ページは、サンプルで抽出されたごく一部だが、そのURLがどのページからリンクされているのか調べることができる。
「link:」を使った検索例「link:」を使った検索例
●「intitle:<検索キーワード>」/「allintitle:<複数の検索キーワード>」でタイトルを対象に検索
 Webページのタイトルを対象にキーワード検索を行う場合、「intitle:」を使うとよい。例えば、製品名などはWebページのタイトルとなっているケースが多いので、こうした製品紹介ページなどを検索するような場合は、「intitle:<製品名>」で検索すると、目的にWebページが見つかりやすいだろう。
 「allintitle:」は、指定した複数の検索キーワードが全て含まれているWebページのタイトルの検索を行う。
●「inurl:<検索キーワード>」/「allinurl:<複数の検索キーワード>」でURLを対象に検索
 URLを対象に指定したキーワード検索を行う場合、「inurl:」を使う。例えば、「Windows inurl:wiki」と検索すると、URLに「wiki」が含まれたWebページだけを対象に、「Windows」というキーワードで検索が行われる(「Windows」と「inurl:wiki」のAND検索が行われる)。特定のドメイン名の下のみを検索したいような場合に便利だ。
 複数のキーワードが全て含まれたURLを対象したい場合は、「allinurl:」を使う。
「inurl:」を使った検索例「inurl:」を使った検索例
●「intext:<検索キーワード>」/「allintext:<複数の検索キーワード>」で本文を対象に検索
 Webページの「<body>タグ」~「</body>タグ」で挟まれた本文のみを対象に、指定したキーワードで検索を行う。「intext:」は単一のキーワード、「allintext:」は複数のキーワードが全て含まれたWebページを表示する。「intext:」を使うと、本文以外の部分に、キーワードを埋め込んだSEO対策を行っているようなWebサイトを除外することができる。
●「inanchor:<検索キーワード>」/「allinanchor:<複数の検索キーワード>」でリンクを検索
 「inanchor:」「allinanchor:」は、リンクのテキスト(いわゆるアンカーテキスト)に指定のキーワードが含まれているWebページを検索するのに用いる。例えば、自社のWebページのタイトルにリンクしているようなWebページを調べたいような場合、「inanchor:<対象ページのタイトルテキスト>」というように指定して検索してみるとよい。
●「related:<URL>」でサイトテーマが近いものを検索
 「related:」は<URL>で指定したサイトとテーマが似たWebサイト(Webページ)を検索するのに用いる。例えば、「related:www.atmarkit.co.jp」と検索すると、IT系メディアのWebサイトが一覧表示される。自社と競合するWebページ(サイト)を調べる際などに利用できる。
「related:」を使った検索例「related:」を使った検索例
●「filetype:<ファイルタイプ>」でPDFなどを対象に検索
 「filetype:pdf」や「filetype:doc」などとすれば、PDFファイルやDOCファイルを対象とした検索が行われる。「pdf」「doc」「docx」「ppt」「pptx」などのファイルタイプを指定して検索できる。
「filetype:」を使った検索例「filetype:」を使った検索例
●「info:<URL>」で指定したWebページの情報へのリンクを表示
 <URL>で指定したWebページ(Webサイト)の「Googleに保存されているキャッシュ」「類似したページの検索」「ウェブページを検索」「含むページの検索」といった情報へのリンクが表示される。
「related:」を使った検索例「related:」を使った検索例

Google検索の検索オプション/検索ツールを使おう

 上述の検索演算子などは、検索時に指定して絞り込み検索を行うものだが、「検索オプション」や「検索ツール」を使うと、検索後に検索結果の絞り込みが行える。
●「検索オプション」を使う
 以下のURLで「検索オプション」を開いて、必要な項目に入力して[詳細検索]ボタンをクリックすれば、上述の検索演算子を使ったのと同様の検索が行える。検索演算子を覚えてなくても、簡単に絞り込み検索が可能だ。
 検索を実施後にGoogle検索のメニュー(検索入力ボックスの下)の[設定]-[検索オプション]を選ぶと、入力済みの検索キーワードが「すべてのキーワードを含む」に入力された状態で「検索オプション」が開く。さらに、他の項目を追加すればよい。
「検索オプション」の画面「検索オプション」の画面
●「検索ツール」を使って結果を絞り込む
 検索結果をWebページの公開された日付に基づいて検索結果で絞り込んだり、対象の言語(日本語環境のデフォルトは「すべての言語」と「英語と日本語のページを検索」の切り替え)や検索キーワードの「完全一致」などで絞り込んだりすることが可能だ。
 なるべく新しい情報が記載されたWebページを見つけたいといった場合は、「24時間以内」「1週間以内」など期間を指定するとよい。
「検索ツール」の画面「検索ツール」の画面



【転載】セキュリティ関連資格チャート表



【まとめ】セキュリティ資格の合格記・受験記:

先日、Ciscoの認定資格「CCNA」を受験してきまして、無事合格できました。

私にとっては1年半ぶりに新しく取得した資格であり、久しぶりに資格を取得する楽しさを味わうことができました。

私は資格勉強をする際によくその資格の合格記を読んでいます。

合格記は受験者の目線で書かれており、実際に行っていた勉強法や参考書・資料、役立ったことと逆に役立たなかったことを紹介しており、勉強のとっかかりや受験時期を決めるのにとても参考になります。

そこで、今回は私が受験予定・興味を持っている資格の合格記・受験記について参考になりそうな記事を各資格ごとにまとめてみました。

(情報は随時追加予定です)

【目次】



参考までにセキュリティの認定資格のチャート表が公開されていますので、リンクを貼っておきます。

CISSP(Certified Information Systems Security Professional)

CISSPは(ISC)² が認定を行っているセキュリティの国際資格です。


SSCP(Systems Security Certified Practitioner)

SSCPはCISSP同様、(ISC)² が認定を行っているセキュリティの国際資格です。

SSCPはCISSPの方が有名で難易度高いためか、受験記・合格記が少なく、参考になるのは以下の記事になります。


OSCP(Offensive Security Certified Professional)

OSCPは、Offensive Securityのベンダー資格でペネトレーションテストに関する資格です。


CEH(Certified Ethical Hacker)

CEHは、EC-Councilが提供するホワイトハッカーの認定資格です。


【蓄えた知識の集大成】認定ホワイトハッカー試験(CEH:Certified Ethical Hacker)に合格できた勉強法


おわりに

セキュリティの資格はまだまだいっぱいあるので、合格された方々の記事を参考に自身の興味ある資格の取得に挑戦してみてはいかがでしょうか。

【参考】

【転載】以外にちゃんと理解していなかった、パスフレーズとパスワードの違い。。。



パスフレーズとは?パスワードとの違いやメリットデメリット、注意点について解説:

SNSやWebサービスなどを利用するためにIDとパスワードによる認証が使われています。通常使われているパスワードは、使い方や設定する文字列によっては強度が弱くリスクが高いため、実際に不正アクセスなどの被害に遭う可能性があります。

そこでパスワードよりもさらにセキュリティを高くした技術として「パスフレーズ」が誕生しました。パスフレーズはパスワードとはどのように異なるのでしょうか。メリットとデメリット、そして使用時の注意点などのも含めて徹底解説します。

パスフレーズとは

パスフレーズとは、パスワードと同様に使われる文字列ですが、概ね10文字から数十文字以上の長い文字列から構成されているものを指します。1つの単語ではなく、複数の単語の組み合わせや、1つのまとまった文章として設定されています。

パスフレーズとパスワードの違い

パスフレーズとパスワードは、以下の2点の違いがあります。

文字数

一般的にパスワードの文字列は8桁から10数桁程度の長さが上限となっています。利用者は上限以上の桁数のパスワードの設定は不可能です。しかしパスフレーズで設定できる文字列は数十桁以上の長さを持つ文字列が設定可能です。

スペースの有無

パスワードとして設定できる文字種は、「アルファベットの大文字と小文字」「数字」「記号」であることが一般的です。しかしパスフレーズでは、これらに加えて「スペース(空白)」の利用が可能です。これはパスフレーズが複数の単語を組み合わせる「文章」であることを前提としているため、単語と単語をつなげる役割として、スペースの利用が可能とされています。なお実際にパスフレーズを設定する場合、必ずしもスペースを使用することが強制されているわけではありません。

パスフレーズのメリット

パスフレーズには以下の2つのメリットがあります。

総当たり攻撃の対策になる

パスフレーズを使用することで、総当たり攻撃(ブルートフォース攻撃)の対策となります。総当たり攻撃とは、あらゆる文字の組み合わせをパスワードとして連続で使い続け、特定のIDに対して不正アクセスを仕掛ける攻撃のことです。

攻撃対象となったアカウントが、桁数や使用文字種の少ない弱いパスワードを使用している場合、総当たり攻撃による不正アクセスが成功しやすくなります。

しかしパスワードではなくパスフレーズを利用することで、設定される文字列の桁数が長くなり、総当たり攻撃による不正アクセス成功確率が下がり、セキュリティ面で安全になります。

覚えやすくセキュリティ強度が高い

強いパスワードと言えるのは、アルファベットや数字だけでなく記号も含めたある程度の長さを持つ文字列です。そのため文字列としては意味不明なものになりがちで覚えにくいというデメリットがあります。

さらにパスワードの文字列として固有名詞や有名な単語を使用する場合、利用者は覚えやすいのですが、辞書攻撃の対象となるリスクが高まります。

しかしパスフレーズの場合、利用者にとってなじみのある単語を選択しても、それらを複数組み合わせて使うため、結果としてセキュリティ強度の高い文字列になります。覚えやすい文字列でも長文となることで、ある程度のセキュリティ強度となるわけです。

パスフレーズのデメリット

有用なパスフレーズですが、パスワードにはないデメリットもあります。

パスワードに比べ利便性が低下する(入力する文字数が長いと)

パスフレーズは設定する文字列が長いため、パスワードと比べて利便性が低下することがあります。例えば、パスフレーズを設定できるサービスを初めて使う場合、設定したパスフレーズの文字列を正確に覚えきれてなくて、ログインできなくなったりすることもあるでしょう。使い続けていれば、このような問題は解決しますが、当面はある程度の利便性が低下する可能性もあるわけです。

パスフレーズを使用する際の注意点

パスフレーズを使用する際には以下の3つの点に注意しましょう。

推測可能なフレーズは使用しない

まず推測可能なパスフレーズの使用は避けましょう。例えば有名な歌の歌詞の一部をパスフレーズとしてそのまま使ったり、同じ単語や固有名詞を繰り返した文字列などをパスフレーズとして設定したりすると、攻撃者に推測される可能性が高くなるため、おすすめできません。

パスフレーズの使い回しをしない

たとえ複雑で推測困難なパスフレーズでも、使いまわすことはおすすめできません。パスフレーズとして強い文字列を設定していても、脆弱性のあるSNSやWebサービスから設定したパスフレーズが漏洩する可能性がないとも言えず、別のSNSやWebサービスへの不正アクセスに使われることがあるからです。

悪意のある攻撃者が、どこかから入手したIDとパスワードのリストを使って不正アクセスする攻撃のことをパスワードリスト攻撃と言います。

例えば、サービスAとサービスBで「X」というパスフレーズを設定していたとしましょう。この時、攻撃者がサービスAに侵入してパスフレーズのリストの入手に成功して、サービスBに対して入手したパスフレーズのリストを使って不正アクセスを試みるとします。サービスAで使用していた「X」というパスフレーズは流出しているため、攻撃者はサービスBに対しても「X」のパスフレーズで不正ログインを試みることは容易に想像できます。

つまり複数のSNSやWebサービスで同一のパスフレーズを使っていると、パスフレーズの強度に関係なく不正ログインの原因となってしまいます。パスフレーズがいかに強固であっても、パスワードと同様に使いまわしをしないというのは鉄則です。

公衆無線LAN(Wi-Fi)でむやみにパスフレーズを入力しない

公衆無線LAN(Wi-Fi)ではむやみにパスフレーズを入力しないほうが良いでしょう。特にパスワード不要の暗号化されていない場合は要注意です。悪意のある攻撃者が公衆無線LANの通信を盗聴して、やり取りされている情報が窃取している可能性があります。もしパスフレーズを入力すると、その文字列も盗聴されてしまうかもしれません。

公衆無線LANは便利ですが、プライベートな通信環境ではありません。ちょっとしたネットサーフィン程度なら問題ないかもしれませんが、IDとパスワードが必要なWebサイトへのログインや、重要な情報のやり取りは控えた方が良いでしょう。

まとめ

パスワードをさらに強固にしたものとして、パスフレーズを紹介しました。長い文字列で構成されるパスフレーズは、特に総当たり攻撃に対して有効な対策となります。

しかしパスワードと同様のデメリットがあることは無視できません。

パスフレーズは推測困難な文字列を設定し、使いまわさない、そして公衆無線LANでは入力を控えるなどは、パスワードと同様の注意点です。「自分はパスフレーズを使っているから安心だ」思い込まずに、適切な管理を心がけることを忘れないようにしましょう。

NISTからランサムウェア等の感染からのデータ復旧に関するドキュメントがリリース(NIST SP 1800-11)

SP 1800-11

データの整合性:ランサムウェアやその他の破壊的なイベントからの回復

概要

キーワード

事業継続データの整合性データ復旧マルウェアランサムウェア

バックアップ

【転載】ATT&CK の入門:アセスメントとエンジニアリング


ATT&CK の概要: 評価とエンジニアリング:

ここ数週間、脅威インテリジェンス、検出と分析、および敵対エミュレーションのためにATT&CKを使用してATT&CKを始める記事を公開しました。Miniシリーズの第4部では、評価とエンジニアリングについて説明し、ATT&CKを使用して防御を測定し、改善を可能にする方法を示します。多くの点で、この投稿は以前のものに基づいているので、まだチェックしていない場合はチェックしてください!

このプロセスをよりアクセスしやすくし、他の投稿と共にフォローできるように、この投稿は洗練されたリソースの可用性に基づいて 3 つのレベルに分かれています。

  • 多くのリソースを持っていない可能性がある人のためのレベル1、
  • 成熟し始める中堅チームのレベル2
  • より高度なサイバーセキュリティチームとリソースを持つ人のためのレベル3。
「評価」を始めるのは、最初は恐ろしいことに聞こえるかもしれません - 誰が評価されることを楽しんでいますか?— しかし、ATT&CK 評価は、セキュリティ エンジニアやアーキテクトに対して、脅威に基づくセキュリティの改善を正当化する、有用なデータを提供する大規模なプロセスの一部です。

  1. あなたの防御が現在ATT&CKの技術と敵対者にどのように積み重ねしているかを評価し、
  2. 現在のカバレッジで最も優先度の高いギャップを特定し、
  3. 防御を変更するか、新しい防御を取得して、これらのギャップに対処します。
Image for post 評価とエンジニアリングのプロセス。

評価とエンジニアリングのレベルは累積的であり、互いに構築されます。高度なサイバーセキュリティチームと考えても、レベル1から始め、より大きな評価を容易にするためにプロセスを進めることをお勧めします。

多くのリソースにアクセスできない小さなチームで作業していて、完全な評価を行うことを考えている場合は、しないでください。カバレッジを視覚化する ATT&CK 行列の色分けされたヒートマップをすぐに作成するという考えは魅力的ですが、ATT&CK で使用することに興奮するよりも、燃え尽きる可能性が高くなります。代わりに、小規模から開始: 1 つのテクニックを選択して、そのテクニックのカバレッジを決定し、適切なエンジニアリング機能強化を行って検出を開始します。この方法を開始することで、より大きな評価を実行する方法を練習できます。

ヒント: どの手法で始めるのか分かりませんか?AtT&CK と脅威インテリジェンスを使用して出発点を選択する方法についてのヒントについては、Katie のブログ記事を参照してください。
テクニックを選んだら、そのテクニックのカバレッジが何であるかを把握したいと思うでしょう。独自のルーブリックを使用できますが、カバレッジの次のカテゴリから始めることをお勧めします。

  • 既存の分析では、この手法が検出される可能性があります。
  • 分析ではこの手法は検出されませんが、適切なデータ ソースを取得して検出します。または
  • 現在、この手法を検出するために適切なデータソースを利用しているわけではありません。
ヒント: 最初に開始するとき、スコアカテゴリをシンプルに保ちます:あなたはそれを検出することができますか?
カバレッジの測定を開始する優れた方法は、すでにテクニックをカバーしている可能性のある分析を探す方法です。これは時間がかかるかもしれませんが、多くのSOCには、最初に設計されていなかったとしても、ATT&CKにマップできるルールと分析がすでにあります。多くの場合、このテクニックの ATT&CK ページまたは外部ソースから取得できる、その技法に関する他の情報を取り込む必要があります。

例として、リモート デスクトップ プロトコル (T1076) を見ていると、次のアラートがあります。

  1. ポート 22 を介するすべてのネットワーク トラフィック。
  2. AcroRd32.exe によって生成されたすべてのプロセス。
  3. tscon.exe という名前のプロセス。
  4. ポート 3389 を経由するすべての内部ネットワーク トラフィック。
リモート デスクトップ プロトコルの ATT&CK テクニック ページを見ると、ルール #3が "検出" ヘッダーの下で指定された内容 #4と一致することがすぐにわかります。

Image for post リモート デスクトップ プロトコルの検出テキスト。

あなたの分析がすでに技術を拾っているなら、素晴らしいです!そのテクニックのカバレッジを記録し、新しいカバレッジを選択してプロセスを再開します。しかし、この問題を扱っていない場合は、この手法の ATT&CK ページに記載されているデータ ソースを調べ、新しい分析を構築するために適切なデータを既に取得しているかどうかを確認します。あなたがそうなら、それは1つを構築するだけの問題です.

しかし、適切なデータソースを利用していない場合は、どうすればよいでしょうか。ここがエンジニアリングの場です。この手法の ATT&CK ページに記載されているデータ ソースを出発点として見て、各データの収集を開始する難しさと、それらを使用する方法の有効性を測定します。

ヒント: 頻繁に引用されるデータ ソースは、多くの ATT&CK 技術を可視化する Windows イベント ログです。イベント ログを使用する際に適したリソースは、マルウェア考古学の Windows ATT&CK ログ チート シートです。
Image for post プロセス コマンド ライン パラメーターで検出できる 244 の ATT&CK 技法のうち 97 件 (Windows イベント 4688 を使用して取得可能)。

次のレベルに進む: 1 つのテクニックで停止しない — このプロセスを数回実行し、各実行の各戦術で新しいテクニック (または 2 つ) を選択します。ATT&CK のカバレッジのヒートマップを生成する場合に最適な ATT&CK ナビゲーター を使用して、結果を追跡します。プロセスに慣れたら、データソース分析を実行し、取得するデータソースを使用して検出できる手法のヒートマップを考え出します。ここで始めるのに役立つリソースには、オラフ・ハートンのATT&CKデータマップ・プロジェクト、DeTT&CT、およびMITRE独自のATT&CKスクリプトなどがあります。

レベル2

このプロセスに慣れ、さらに多くのリソースにアクセスできれば、分析を拡張して、ATT&CK マトリックスのかなり大きなサブセットに広げるのが理想的です。さらに、より高度なカバレッジ スキームを使用して、検出の忠実度も考慮する必要があります。ここでは、SOCのツールまたは分析がテクニックに警告する可能性のある低、一部、または高い信頼性のいずれかにカバレッジをバケットすることをお勧めします。

Image for post 最終的な評価の例を示します。

ヒント: カバレッジを評価する際に、正確なポイントを気にしないでください — 評価の目標は、一般的に技術を検出するエンジニアリング機能があるかどうかを理解することです。より正確に見るため、敵対エミュレーション演習を実行することをお勧めします。
この拡張された範囲により、分析の分析が少し複雑になり、各分析は以前の1つの手法とは対照的に、多くの異なるテクニックにマッピングされる可能性があります。さらに、手法が分析対象の場合は、分析の忠実度もいじめたいと思うでしょう。

ヒント: 各分析について、キーイングの内容を見つけて、ATT&CK にマップする方法を確認することをお勧めします。たとえば、特定の Windows イベントを調べ、分析を行う場合があります。この分析対象を特定するには、Windows ATT&CK ロギング チート シートまたは同様のリポジトリでイベント ID を検索します。ATT&CK Web サイトを使用して分析を分析することもできます — 下の図は、ポート 22 の検出の検索例を示しています。
Image for post ATT&CK サイトでポート 22 を検索

考慮すべきもう 1 つの重要な側面は、一覧に記載されているグループとソフトウェアの例と技術です。これらは、敵対者がテクニックを使用した手順、または特定の方法を記述しています。多くの場合、それらは既存の分析でカバーされる場合とカバーされない可能性のある技術のバリエーションを表し、技術をどれだけうまくカバーしているかの信頼度評価にも考慮する必要があります。

Image for post Windows 管理者の共有の例セクション

分析を見る以外に、ツールの分析も開始します。これを行うには、各ツールを反復処理し、それぞれに個別のヒートマップを作成し、次の質問をすることをお勧めします。

  • ツールはどこで実行されますか?ツールが実行されている場所 (境界や各エンドポイントなど) によっては、特定の戦術で良くも悪くもなります。
  • ツールはどのように検出されますか?「既知の悪い」指標の静的なセットを使用していますか?それとも、何か行動をしていますか?
  • ツールはどのデータ ソースを監視しますか。ツールが監視するデータ ソースを知ることで、検出する可能性のある手法を推測できます。
これらの質問に答えるのは難しいかもしれません!すべてのベンダーがこの種の情報を公開しているわけではないし、多くの場合、それを探すときにはマーケティング資料を見つけることが起きます。一般的なカバレッジパターンに関する幅広いストロークをペイントすることを選択し、詳細に悩まされてあまりにも多くの時間を費やしないようにしてください。

カバレッジの最終的なヒートマップを作成するには、ツールと分析のすべてのヒートマップを集約し、各テクニックで最高のカバレッジを記録します。これを行うと、改善に向けて進みます - 最初のステップとして、先ほど述べた分析開発プロセスのより高度なバージョンをお勧めします。

  1. 短期的に注目する優先度の高いテクニックのリストを作成します。
  2. 適切なデータを取得して、対象となる手法の分析を開始します。
  3. 分析の構築とカバレッジ チャートの更新を開始します。
Image for post 現在のカバレッジから開始し、分析を追加し、それに応じてカバレッジを更新します。

ツールのアップグレードを開始することもできます。ドキュメントを分析する際には、カバレッジを増やすために使用できるオプションのモジュールを追跡します。ツールの追加モジュールが見つからない場合は、代替データ ソースとして使用することもできます。たとえば、各エンドポイントに Sysmon をインストールできない場合がありますが、既存のソフトウェアでは、他の方法ではアクセスできない可能性がある関連するログを転送できる可能性があります。

次のレベルに進む: これらの変更の実装とカバレッジの向上を開始したら、次のステップは、敵対エミュレーション、特に原子テストを導入することです。新しい分析を試作するたびに、一致するアトミックテストを実行し、それをキャッチしたかどうかを確認します。あなたがした場合は、素晴らしいです!見逃した場合は、見逃したものを確認し、それに応じて分析を調整します。また、ATT&CK ベースの分析でサイバー脅威を検出するに関する論文を参照して、このプロセスに関する詳細なガイダンスを参照することもできます。

レベル 3

より高度なチームを持つ人にとっては、評価を増幅する素晴らしい方法は、軽減策を含める方法です。これにより、ツールや分析を見るだけで、検出した内容から SOC 全体を見るだけの評価が進みます。

テクニックを軽減する方法を特定するには、SOC の各ポリシー、予防ツール、およびセキュリティ コントロールを調べ、そのポリシーを ATT&CK の手法にマップし、その手法をカバレッジのヒートマップに追加します。最近の軽減策のリストラでは、各軽減策を実行し、その対応先の手法を確認できます。軽減策を使用する手法の例を次に示します。

Image for post ブルート フォース (左) と Windows 管理者の共有 (右) の軽減策。

評価を拡張するもう 1 つの方法は、SOC で働く他の人にインタビューをしたり、非公式にチャットしたりすることです。これは、ツールの使用方法を理解するうえで役立つだけでなく、他の方法では考慮しない可能性のあるギャップや強みを強調するのに役立ちます。次のような質問の例を挙げられます。

  • 最も頻繁に使用するツールは何ですか?彼らの長所と短所は何ですか?
  • 表示されたいデータ ソースを確認できないデータ ソースは何ですか。
  • 検出の観点から見た最大の長所と短所はどこにありますか?
これらの質問に対する回答は、先ほど作成したヒートマップを強化するのに役立ちます。

例: 以前に ATT&CK 関連の機能が多数あるツールを見つけたが、そのツールを使用して Windows レジストリを監視している場合は、そのツールのヒートマップを修正して、その使用方法を適切に反映する必要があります。
同僚と話す際に、以前に作成したツールのヒートマップを確認します。ツールが提供しているカバレッジにまだ満足できない場合は、新しいツールを評価する必要があります。各新しいツールのカバレッジのヒートマップを考え出し、それを追加するとカバレッジを強化する方法を確認します。

ヒント: 特に十分なリソースがある場合は、代表的なテスト環境を立ち上げて、ツールをライブでテストし、ツールがどこでうまく機能しなかったか、そして追加が既存のカバレッジにどのような影響を与えるのかを記録できます。
さらに、より多くの緩和策を実装することで、ツールや分析への依存度を低くすることができます。ATT&CK の軽減策を確認して、実際に実装できるかどうかを測定します。このプロセスの一部として、検出ヒートマップを参照してください。検出の良い仕事をしている手法を防ぐ高コストの緩和策がある場合、それは良いトレードオフではないかもしれません。一方、分析の記述に苦労している手法に対して低コストの緩和策を実装できる場合は、それらを実装することがリソースの適切な使用である可能性があります。

ヒント: 検出を削除して軽減策を使用する場合は、常に可視性の損失の可能性を比較検討してください。軽減策や制御がバイパスされ、イベントが見逃されにくい場合は、ある程度の可視性を確保してください。検出と緩和の両方を効果的なカバレッジのためのツールとして使用する必要があります。
最後に:評価とエンジニアリングが適合する場所

防御を評価し、エンジニアリングを指導することは、ATT&CK を開始する際に最適な方法です: 評価を実行すると、現在のカバレッジがどこであるかを理解できます。

長期的には、毎週、あるいは毎月評価を実行していると思い描くべきではありません。代わりに、前回の評価内容に関する実行中のタブを維持し、新しい情報を取得するたびに更新し、定期的に敵対エミュレーション演習を実行して結果をスポットチェックする必要があります。ネットワークの時間の経過と経過に伴う変更と収集されたものは、以前にテストされた防御の有効性を低下させる意図しない結果をもたらす可能性があります。ATT&CK を活用して防御が実際の脅威にどのように積み重なっているのかを示すことで、防御姿勢をより深く理解し、改善点を優先することができます。

Image for post ATT&CKユースケースの可視化

©2019ザ・ミトレ株式会社すべての権利が予約されています。一般公開が承認されました。分布無制限 18–3288–12.

【転載】ATT&CK の入門:脅威インテリジェンス



ATT&CK の概要: 脅威インテリジェンス:

昨年、Mediumブログを始めて以来、ATT&CKcon 2018、2019年の計画、ロードマップのクールな視覚化などのトピックについて、かなりの数の投稿をあなたと共有してきました。しかし、お話ししたように、私たちは一歩下がって、多くの皆さんの質問に焦点を当てるのに役立つことを認識しました: どうすればATT&CKを使い始めるのですか?

このことを念頭に置いて、脅威インテリジェンス、検出と分析、敵対エミュレーションと赤いチーミング、評価とエンジニアリングの4つの主要なユースケースに対する質問に答えることを目的とした新しいミニシリーズのブログ記事を見つめています。あなたがそれを見ていない場合は、これらのユースケースに基づいてコンテンツを共有するためにウェブサイトを再編成し、私たちの希望はこれらのブログ記事がそれらのリソースに追加されます。

ATT&CK は、脅威に基づく防御に向けたい組織に役立つ可能性があるため、チームの高度化に関係なく、開始方法のアイデアを共有したいと考えています。これらの投稿をそれぞれ異なるレベルに分割します。

  • 多くのリソースを持っていない可能性がある人のためのレベル1、
  • 成熟し始める中堅チームのレベル2
  • より高度なサイバーセキュリティチームとリソースを持つ人のためのレベル3。
今日は、それが最良のユースケース(冗談、私のチームの残りの部分)なので、脅威インテリジェンスについて話すことによって、このシリーズを開始。昨年の夏、ATT&CK を使ってサイバー脅威インテリジェンスを高める方法について概要を説明し、この記事では、その上に基づいて、実践的なアドバイスを紹介します。

レベル 1

サイバー脅威インテリジェンスは、敵対者が何をするのかを知り、その情報を使用して意思決定を改善することです。脅威インテリジェンスに ATT&CK を使用する必要がある 2 人のアナリストがいる組織では、1 つの方法は、関心のあるグループを 1 つ作成して、ATT&CK で構造化された行動を見ることです。以前にターゲットを絞ったユーザーに基づいて、当社のウェブサイトにマッピングしたグループからグループを選択できます。また、多くの脅威インテリジェンス サブスクリプション プロバイダーも ATT&CK にマップするため、その情報を参照として使用することもできます。

例: 製薬会社の場合は、検索バーまたはグループページで検索して、APT19 が貴社のセクターをターゲットにしたグループの 1 つであることを確認できます。
Image for post 「医薬品」の検索 Image for post APT19グループの説明

そこから、グループのページを表示して、(マップしたオープンソースのレポートのみに基づいて)使用した手法を確認して、グループの詳細を知ることができます。あなたがそれに精通していないので、テクニックに関するより多くの情報が必要な場合は、問題ありません - それはATT&CKのウェブサイト上にあります。この手順は、ATT&CK Web サイトで個別に追跡する、グループを使用してマッピングした各ソフトウェア サンプルに対して繰り返し実行できます。

例: APT19 で使用される方法の 1 つは、レジストリ実行キー/スタートアップ フォルダ です。
Image for post

では、脅威インテリジェンスの全体のポイントであるこの情報を実行可能にする方法を教えてください。これは私たちのセクターをターゲットにしているグループであり、我々は彼らに対して守りたいので、我々のディフェンダーとそれを共有してみましょう。この場合、ATT&CK の Web サイトで、テクニックの検出と軽減を開始するためのアイデアを確認できます。

例: APT19 が使用した特定のレジストリ実行キーについて、防御者に知らせてください。ただし、変更して別の実行キーを使用する場合もあります。この手法の検出アドバイスを見ると、環境で予期しない新しい実行キーについてレジストリを監視することをお勧めします。これはあなたのディフェンダーとの素晴らしい会話になります。
Image for post Image for post レジストリ実行キー/スタートアップ フォルダテクニックの検出アイデア

要約すると、脅威インテリジェンスに ATT&CK を使用する簡単な方法は、関心のある 1 つの敵グループを見ることです。彼らが使用したいくつかの行動を特定することは、彼らがそのグループを検出しようとする方法についてあなたの擁護者に知らせるのに役立ちます。

レベル2

敵対者に関する情報を定期的に確認している脅威アナリストのチームがある場合、次のレベルのアクションは、他のユーザーが既にマップしたものを使用するのではなく、自分で ATT&CK にインテリジェンスをマップすることです。組織が行ったインシデントに関するレポートがある場合は、ATT&CK にマップする優れた内部ソースとして使用することも、ブログ記事のような外部レポートを使用することもできます。これを簡単にするために、単一のレポートから始めることができます。

例: ATT&CK ( https://www.fireeye.com/blog/threat-research/2014/11/operation_doubletap.html ) にマップされた FireEye レポートのスニペットを次に示します。
Image for post

何百ものテクニックを知らないときにATT&CKにマップしようとすると、威圧的になることは分かります。これを支援するために従うことができるプロセスを次に示します。

  1. ATT&CK — ATT&CK の全体的な構造(戦術(敵対者の技術的目標)、テクニック(目標の達成方法)、手順(テクニックの特定の実装)を理解してください。はじめにページと哲学のペーパーをご覧ください。
  2. 動作を見つける — 敵の行動は、敵の指標 (IP アドレスなど) だけではなく、より広い方法で考えます。たとえば、上記のレポートのマルウェアは「SOCKS5接続を確立する」とします。接続を確立する行為は、敵対者が取った行動です。
  3. 動作を調べて - その動作に慣れていない場合は、さらに調査を行う必要があります。この例では、少しの研究では、SOCKS5がレイヤ5(セッションレイヤ)プロトコルであることを示しています。
  4. 動作を戦術に変換する — 敵対者の技術的な目標を考慮し、適した戦術を選択します。良いニュースは、エンタープライズATT&CKで選択する12の戦術が存在することです。SOCKS5 接続の例では、後で通信への接続を確立すると、コマンドと制御の戦術に該当します。
  5. 動作に適用されるテクニックを理解する - これは少し難しいかもしれませんが、分析スキルとATT&CKウェブサイトの例では可能です。当社のウェブサイトでSOCKSを検索すると、標準非アプリケーション層プロトコル(T1095)というテクニックがポップアップ表示され、テクニックの説明を見ると、これが私たちの行動に合っている可能性があります。
  6. 結果を他のアナリストと比較する - もちろん、他のアナリストとは異なる動作の解釈があるかもしれません。これは正常であり、ATT&CK チームでは常に発生します。ATT&CK の情報マッピングを別のアナリストと比較し、違いについて話し合うことを強くお勧めします。
2 人のアナリストがいる CTI チームにとって、ATT&CK に情報をマッピングすることは、組織の要件を満たすために最も関連性の高い情報を確実に得るための良い方法です。そこから、ATT&CK マップの敵対者情報を防御者に渡して防御を伝えることができます。

レベル 3

CTI チームが高度なチームである場合は、ATT&CK に詳細な情報をマップし、その情報を使用して防御方法に優先順位を付けることができます。上記のプロセスを実行すると、内部情報と外部情報の両方を ATT&CK (インシデント対応データ、OSINT からのレポート、脅威インテルサブスクリプション、リアルタイムアラート、組織の履歴情報など) にマッピングできます。

このデータをマップしたら、グループを比較し、一般的に使用される手法に優先順位を付けるために、いくつかのクールなことを行うことができます。たとえば、以前に ATT&CK Web サイトでマッピングしたテクニックで共有した ATT&CK ナビゲーターからこのマトリックス ビューを使用します。APT3 でのみ使用されるテクニックは青で強調表示されます。APT29 でのみ使用されるものは黄色で強調表示され、APT3 と APT29 の両方で使用されるものは緑色で強調表示されます。(すべては、マップした一般に公開されている情報のみに基づいており、これはそれらのグループが行ったことのサブセットにすぎません)。

Image for post APT3 + APT29 テクニック

組織の最も脅威に基づいて、関心を持つグループと手法を置き換える必要があります。上記のように独自の Navigator レイヤーを作成するために、上記のマトリックスを作成するための手順のステップバイステップガイドと、Navigator の機能の概要を示すビデオ チュートリアルを紹介します。

Image for post レイヤーの比較のステップ バイ ステップ チュートリアル ナビゲータを紹介するビデオとレイヤーの比較方法を説明する

その後、情報を集約して、一般的に使用される手法を判断し、ディフェンダーが何を優先するかを知るのに役立ちます。これにより、テクニックを優先し、ディフェンダーが検出と緩和に焦点を当てるべきものを共有することができます。上記のマトリックスでは、APT3とAPT29が組織に対する脅威が高いと考えられる2つのグループであった場合、緑の技術は、軽減と検出方法を決定する最優先の優先順位かもしれません。我々の擁護者がCTIチームに防衛のためのリソースをどこに優先順位付けすべきかを把握する必要がある場合は、この情報を彼らが始める場所として彼らと共有することができます。

当社の擁護者が検出できる内容(今後の投稿で取り上げる)の評価を既に行っている場合は、その情報を脅威について知っていることをオーバーレイすることができます。あなたが気にしているグループがそれらの技術を使用し、それらを検出できないので、これはあなたのリソースに焦点を当てるのに最適な場所です!

あなたが持っているデータに基づいて敵対者を観察したテクニックを引き続き追加し、頻繁に使用される技術の「ヒートマップ」を開発することができます。ブライアン・ベイヤーと私はSANS CTIサミットで、MITREキュレーションとレッドカナリアキュレーションデータセットに基づいて異なる「トップ20」技術を考え出した方法について話しました。ATT&CK のテクニックをマッピングするこのプロセスは完璧ではなく、バイアスを持っていますが、この情報は敵対者が何をしているのかを明確に把握するのに役立ちます。(このスライドデッキでのバイアスと制限の詳細を読むことができます。

CTI に ATT&CK を使用しようとする上級チームにとって、さまざまなソースを ATT&CK にマッピングすることで、敵対者の行動を深く理解し、組織の防御に優先順位を付けたり、情報を提供したりすることができます。