雑記系ブログ。セキュリティとか、マイルとか、投資とか、、、 / Miscellaneous Blogs. Security, miles, investments, etc
三菱パワーがMSP(マネージドサービスプロバイダ)の不正アクセスの2次被害を受ける(転載)~サプライチェーンリスク顕在化事例~
不正アクセスで顧客情報約8.8万件が被害か(転載)~想定損害賠償額は21億円程度か~
ITセキュリティリスクアセスメントの実施 / Conducting an IT Security Risk Assessment
Conducting an IT Security Risk Assessment
企業のリスクを低減する能力を高めましょう。新しいホワイトペーパーでは、効果的なITセキュリティリスクアセスメントの実施が重要な理由をご紹介しています。ITセキュリティリスクアセスメントの実施
すべての企業は、既知のものから未知のものまで、ほとんど毎日のようにリスクに直面しています。リスク評価は、ビジネスの混乱や損害を最小限に抑えるために、テクノロジーやその他の企業資産に対する脅威を評価するのに役立ちます。
リスクは様々な形で発生するため、企業がこれらの脅威に備え、対処するための最善の方法は、事業目的に沿った強力で構造化されたリスク軽減戦略と計画を策定することです。
現在および将来のリスクを軽減し、潜在的な損害を軽減するためのリスクアセスメントを成功させるための重要なステップをより深く理解することができます。これらのステップには以下が含まれます。
- 資産の特定と評価
- 既知の脅威の識別
- 脆弱性の特定
- リスクの特定
- リスク治療の決定
このISACAホワイトペーパーは、ITセキュリティリスク評価プロセスを初めて利用する方や、ITセキュリティリスク評価プロセスに慣れていない方のための情報システムやビジネスの専門家向けのホワイトペーパーです。
【転載】「会社の看板」は早く利用して、こちらから捨てたほうが良い
日本最大の大手広告代理店が、40代以上の正社員230人を業務委託の個人事業主に切り替える制度を開始するというニュースが話題になつています。
正社員という日本型の雇用形態は、企業から見れば大きなリスクになっています。事業環境の変化が大きくなればなるほど、固定費となる社員を抱え込むのは、経営を不安定させる要因なのです。
すでに日本では、企業年金制度が確定給付型から確定拠出型(日本版401k)にシフトし、年金の運用リスクが企業から従業員に転嫁されました。
今後も大きな流れとして、会社側がリスク回避のために、従業員を実質的に切り捨てていくと思います。
であれば、会社で社員として働いている人がやるべき事は、2つです。
1つは会社の看板を可能な限り利用すること
そして
もう1つは、会社に捨てられる前に自分から会社を捨てられる力を身に着けておくことです。
会社の看板があることによる1番大きなメリットは「お金を借りる力」が持てることです。個人事業主になれば、信用力がつくまで借り入れすることができません。会社にいるうちに、お金を借りられるだけ借りておく。「信用力のマネタイズ」をできるだけ早くやっておくことです。
NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係(転載)
NIST SP800-207 「ゼロトラスト・アーキテクチャ」の解説と日本語訳
NISTによる「ゼロトラストにおける7つの基本原則」と従来の境界型防御との関係
SP 800-207は米政府がネットワークやセキュリティのモデルとしてのゼロトラストについて言及する際に、政府標準として扱われるべく提言されたものです。今後、他のSP 800シリーズ同様に、世界中の多くの組織がこのSP 800-207を参考に、ゼロトラストについて議論すると思います。
NISTによる「ゼロトラストにおける7つの基本原則」
- データソースとコンピュータサービスは、全てリソースと見なす
- 「ネットワークの場所」に関係なく、通信は全て保護される
- 組織のリソースへのアクセスは、全て個別のセッションごとに許可される
- リソースへのアクセスは動的なポリシーによって決定される
- 組織が保有するデバイスは、全て正しくセキュリティが保たれているように継続的に監視する
- リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される
- 資産・ネットワーク・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する
- 全てのリソースへのアクセスの認証と認可がリクエストごとに動的に決定される
- 全てのリソースの状態が、その判断に用いられる
- 全てのリソースの機器や通信が保護され、状態が可視化によって監視されている
【1】データソースとコンピュータサービスは、全てリソースと見なす
【2】「ネットワークの場所」に関係なく、通信は全て保護される
【3】組織のリソースへのアクセスは、全て個別のセッションごとに許可される
【4】リソースへのアクセスは動的なポリシーによって決定される
- クライアントの識別としては、ユーザーアカウントや関連属性など
- デバイスの状態では、インストールされているソフトウェアのバージョンやネットワークの場所、アクセス日時など
- 振る舞い属性として、ユーザーやデバイスの異常な振る舞いの記録の有無
- 環境属性として、ネットワークの場所や時間、報告されている攻撃など
【5】組織が保有するデバイスが、全て正しくセキュリティが保たれているように継続的に監視する
【6】リソースの認証と認可は、全てアクセスが許可される前に動的かつ厳密に実施される
【7】組織は、資産・ネットワークインフラ・通信の状態について可能な限り多くの情報を収集し、セキュリティを高めるために利用する
ゼロトラストの7つの基本原則と従来の境界型防御
「データ侵害インデックス」サイト「Cit0day[.]in」で検索する方法 / Cit0day Search Tool(転載)
After my podcast episode about the Cit0day data leaks, my colleague Jesse initiated the idea of making our own search engine. The 23,000 breached databases within this massive leak can be queried on various breach notification sites, but they all simply provided a notice of hit within the Cit0day collection. None of them identify WHICH breached database contains the exposure. We now offer a tool for this. Head over to:
Provide any email address and immediately receive notification of the specific data breach which contains the email address. I present more details on the show tomorrow.
JPCERT/CC Eyes「LogonTracer v1.5 リリース」を公開(転載)
JPCERT/CC では、イベントログの分析をサポートするツール「LogonTracer」の最新版バージョン1.5をリリースしました。これまでのLogonTracerは、セキュリティインシデントの事後調査という用途に特化していましたが、リリース直後からLogonTracerをリアルタイムログ分析にも活用したいという要望が多く寄せられていました。そのため、今回のアップデートでは、リアルタイムイベントログ分析を可能にする機能を追加しました。
今回は、このアップデートについて紹介します。その他のアップデート内容については下記のリリースをご覧ください。
https://github.com/JPCERTCC/LogonTracer/releases/tag/v1.5.0
Elasticsearchのサポート
LogonTracerは、Elasticsearchと連携することでリアルタイムログ分析が可能になります。
図1は、LogonTracerとElasticsearchを連携させた場合のイメージです。LogonTracerは、デフォルトではWinlogbeatを使用してElasticsearchに送信されたイベントログをインポートすることが可能です。
LogonTracerは、Elasticsearchからインポートしたログを分析し、結果をElasticsearchに保存することができます。イベントログを可視化して分析する場合、LogonTracerから確認する必要がありますが、不審なアカウントのランキングやサマライズしたログの分析結果はElasticsearchにも保存されるため、ElasticsearchやKibana上で同様の分析結果を確認することが可能です。
図2は、LogonTracerの分析結果をKibana上で表示した様子です。KibanaのWatcherなどを使用して、LogonTracerからレポートされた不審なログをアラートするように設定しておけば、リアルタイムで異常検知のサポートになります。
Elasticsearchからのログインポート
ElasticsearchからLogonTracerにログをインポートには、Web GUIから行うことができます。左下の「Load from ES」ボタン(図3の左)をクリックすると、インポート用の設定画面(図3の右)が表示されます。
Elasticsearchからインポートする際の、さらに詳細な設定(index名など)はコマンドラインから行うことができます。詳しくはLogonTracerのWikiをご覧ください。
https://github.com/JPCERTCC/LogonTracer/wiki
LogonTracerにログをインポートする際の注意
LogonTracerの分析機能の大きなポイントの1つにイベントログの可視化があります。可視化は、ログ分析の大きなサポートになりますが、大規模なログの可視化は、ログ表示の遅延や大規模なグラフを目視で分析することは難しいという問題があります。これは、LogonTracerに限らず大規模な情報を可視化するシステムには、共通する課題です。
そのため、LogonTracerに、長期間(1ヶ月や1年など)のログをインポートすることは、可視化速度の低下につながるためお勧めできません。1週間または1日(適切な期間はホスト数やユーザ数によって異なります)などの間隔で、必要なログをインポートして、分析することを推奨します。
LogonTracerを、ADイベントログの監視に使用する場合は、cronなどで定期的にイベントログを読み込んで分析し、分析結果をElasticsearchに蓄積することで、Kibana上でLogonTracerの分析結果を監視する運用を行ってください。確認が必要なログが見つかった場合、LogonTracerに対象期間のログをインポートしてログの可視化を行うことで、効率的な監視が可能になります。
【転載】少し前のブログ記事ですが、ここにあるコマンドの実行を検知したりブロックするするだけでも、内部侵入の気づきや阻止に役立ちそうですね…😌
(最近も傾向は変わってないのかな…🤔)
blogs.jpcert.or.jp/ja/2015/12/win…
Windows OSには標準で多数のコマンド(以下「Windowsコマンド」といいます。)がインストールされています。しかし、ユーザが実際に利用するのは多くの場合そのうちのごく一部です。一方、侵入した攻撃者も情報を収集し、あるいはネットワーク内で感染を拡大させるためにWindowsコマンドを使っていることをJPCERT/CCの調査で確認しています。ここで注目されるのは、普通の利用者が使うWindowsコマンドの集合と攻撃者が使うWindowsコマンドの集合のずれです。両者が大きく違っていれば、Windowsコマンドの実行状況を監視または管理することで、攻撃者の動きを検知あるいは抑制できることになります。
今回は、攻撃者が侵入したWindows OS上で使用するWindowsコマンドを明らかにし、攻撃者は使うが各ユーザにとっては不要なWindowsコマンドの実行を制限することで、攻撃による影響を低減する方法を示します。
遠隔操作のためのマルウエア(RAT)には、リモートからコマンド・シェルを実行する機能があります。この機能を利用すると、Windowsコマンドをリモートから実行することが可能です。
そのようなマルウエアをネットワーク内に侵入させた攻撃者は、次のような流れで侵入したネットワーク内のシステムを攻略し、機密情報の収集などを試みます。
① 初期調査 :感染した端末の情報を収集する
② 探索活動 :感染した端末に保存された情報や、ネットワーク内のリモート端末を探索する
③ 感染拡大 :感染した端末を別のマルウエアにも感染させる、または別の端末にアクセスを試みる
これらのすべての攻撃フェーズでWindowsコマンドが使用されます。以降では、各攻撃フェーズで使用されるWindowsコマンドについて紹介します。
初期調査
攻撃者が感染端末の情報収集によく使用するコマンドは、表1の通りです。なお、実行数は3つの異なる攻撃グループが使用していた各C&Cサーバで入力したWindowsコマンドの集計結果です(詳細は、Appendix A,B,Cをご参照ください)。
表1: 初期調査(上位10コマンド)
順位 | コマンド | 実行数 |
1 | tasklist | 155 |
2 | ver | 95 |
3 | ipconfig | 76 |
4 | systeminfo | 40 |
5 | net time | 31 |
6 | netstat | 27 |
7 | whoami | 22 |
8 | net start | 16 |
9 | qprocess | 15 |
10 | query | 14 |
攻撃者は、tasklistやver、ipconfig、systeminfoなどのコマンドを使用し、ネットワーク情報やプロセス情報、OS情報などを収集して、どのような端末に感染したのかを調査します。これによって、侵入した端末がマルウエア解析のためのおとり環境でないかなどを確認していると考えられます。
探索活動
機密情報の探索やネットワーク内のリモート端末の探索においては、表2のコマンドがよく使用されます。
表2:探索活動(上位10コマンド)
順位 | コマンド | 実行数 |
1 | dir | 976 |
2 | net view | 236 |
3 | ping | 200 |
4 | net use | 194 |
5 | type | 120 |
6 | net user | 95 |
7 | net localgroup | 39 |
8 | net group | 20 |
9 | net config | 16 |
10 | net share | 11 |
攻撃者は、ファイルを探索するためにdirおよびtypeを使用します。dirコマンドに適切な引数を指定することで、感染端末内のすべてのドキュメントファイルの一覧を収集することもあります。
ネットワークの探索にはnetコマンドが用いられます。特に次のコマンドが多用されます。
- net view: 接続可能なドメインのリソース一覧取得
- net user: ローカルおよびドメインのアカウント管理
- net localgroup: ローカルのグループに所属するユーザ一覧取得
- net group: 特定ドメインのグループに所属するユーザ一覧取得
- net use: リソースへのアクセス
さらに、Active Directoryを使用している環境の場合、次のコマンドが利用されることもあります(Appendix A 表5参照)。これらのコマンドは、Windows Serverに搭載されているコマンドで、本来はWindows 7や8.1などのクライアントOSには存在しませんが、攻撃者はこれらのコマンドを外部からダウンロードしインストールした上で実行します。
- dsquery: Active Directoryに含まれるアカウントの検索
- csvde: Active Directoryに含まれるアカウント情報取得
感染拡大
ネットワーク内のリモート端末への侵入・感染拡大のフェーズでは、表3のコマンドがよく使用されます。
表3:感染拡大
順位 | コマンド | 実行数 |
1 | at | 103 |
2 | reg | 31 |
3 | wmic | 24 |
4 | wusa | 7 |
5 | netsh advfirewall | 4 |
6 | sc | 4 |
7 | rundll32 | 2 |
※wmicは、探索活動などにも用いられます
atやwmicは、リモート端末上でマルウエアを実行するためによく利用されます。
atコマンドにより、次のように接続可能な端末に対してファイルを実行するタスクを登録することで、リモート端末上でコマンドを実行することができます。
at \\[リモートホスト名 or IPアドレス] 12:00 cmd /c "C:\windows\temp\mal.exe"
また、wmicコマンドにより、次のような引数を指定することで、リモート端末上のコマンドを実行することができます。
wmic /node:[IPアドレス] /user:”[ユーザ名]” /password:”[パスワード]” process call create “cmd /c c:\Windows\System32\net.exe user”
必要のないWindowsコマンドを実行制限する
これらの攻撃者が使うWindowsコマンドの中には、ユーザごとに吟味すれば、使用しないコマンドが含まれていると思います。そのようなコマンドを、AppLockerやソフトウエア制限ポリシーを使用して実行を制限することで、攻撃者の活動を抑えることができます。例えば、netコマンドを制限したい場合には、図1のようなルールを設定します。(AppLockerの設定方法について詳しくは、マイクロソフトのWebサイトをご参照ください)[1])
また、AppLockerを有効にすると、設定で指定されたWindowsコマンドが実行された、または実行しようとして拒否された事象がイベントログに記録されるようになり、マルウエア感染後に攻撃者が実行したWindowsコマンドを調査することにも活用できます。
なお、AppLockerではWindowsコマンドの実行を制限せずに監査のみを行うこともできます[2]。監査のみの場合、意図しないWindowsコマンドの実行は防げませんが、イベントログに実行の記録が残ります。攻撃に用いられるWindowsコマンドを利用者自身も使っている場合には、監査のみとするのもよいでしょう。(なお、Windowsコマンドの実行を監視するにはローカルセキュリティポリシーで、「プロセス作成の監査」を有効にすることでも記録することができます。)
おわりに
標的型攻撃においては、攻撃者は、マルウエアに組み込まれた機能だけを使って目的を遂行するわけではなく、Windowsコマンドも多用しています。そうした行為を阻むことができれば、比較的早い段階でインシデントの拡大を抑止することができます。とは言え、すぐにWindowsコマンドの使用を制限するのは難しいと思いますので、まずはAppLockerなどを使用して実行プロセスのログを取得することから始めてみるとよいでしょう。
分析センター 朝長 秀誠
参考情報
[1] Microsoft - Windows AppLocker
https://technet.microsoft.com/ja-jp/library/dd759117.aspx
[2] Microsoft - 監査を使用してどのアプリケーションが使用されているかを追跡する
https://technet.microsoft.com/ja-jp/library/dd723693%28v=ws.10%29.aspx
Appendix A 攻撃グループ別の実行コマンド一覧(攻撃グループA)
表4: 初期調査(攻撃グループA)
順位 | コマンド | 実行数 | オプション |
1 | tasklist | 119 | /s /v |
2 | ver | 92 | |
3 | ipconfig | 58 | /all |
4 | net time | 30 | |
5 | systeminfo | 24 | |
6 | netstat | 22 | -ano |
7 | qprocess | 15 | |
8 | query | 14 | user |
9 | whoami | 14 | /all |
10 | net start | 10 | |
11 | nslookup | 4 | |
12 | fsutil | 3 | fsinfo drives |
13 | time | 2 | /t |
14 | set | 1 |
表5:探索活動(攻撃グループA)
順位 | コマンド | 実行数 | オプション |
1 | dir | 903 | |
2 | net view | 226 | |
3 | ping | 196 | |
4 | net use | 193 | |
5 | type | 118 | |
6 | net user | 74 | |
7 | net localgroup | 35 | |
8 | net group | 19 | |
9 | net config | 16 | |
10 | net share | 11 | |
11 | dsquery | 6 | |
12 | csvde | 5 | /f /q |
13 | nbtstat | 5 | -a |
14 | net session | 3 | |
15 | nltest | 3 | /dclist |
16 | wevtutil | 2 |
表6:感染拡大(攻撃グループA)
順位 | コマンド | 実行数 | オプション |
1 | at | 98 | |
2 | reg | 29 | add export query |
3 | wmic | 24 | |
4 | netsh advfirewall | 4 | |
5 | sc | 4 | qc query |
6 | wusa | 2 |
Appendix B 攻撃グループ別の実行コマンド一覧(攻撃グループB)
表7: 初期調査(攻撃グループB)
順位 | コマンド | 実行数 | オプション |
1 | tasklist | 29 | /m /svc |
2 | whoami | 6 | |
3 | ipconfig | 5 | /all |
4 | net start | 4 | |
5 | netstat | 3 | -ano |
6 | nslookup | 3 | |
7 | ver | 2 | |
8 | time | 1 | /t |
表8: 探索活動(攻撃グループB)
順位 | コマンド | 実行数 | オプション |
1 | dir | 62 | |
2 | net user | 21 | /domain /add |
3 | net view | 9 | /domain |
4 | ping | 4 | |
5 | net localgroup | 4 | /add |
6 | tree | 3 | /F |
7 | type | 2 | |
8 | net group | 1 | /domain |
表9: 感染拡大(攻撃グループB)
順位 | コマンド | 実行数 | オプション |
1 | at | 5 | |
2 | wusa | 5 | |
3 | reg | 2 | |
4 | rundll32 | 2 |
Appendix C 攻撃グループ別の実行コマンド一覧(攻撃グループC)
表10: 初期調査(攻撃グループC)
順位 | コマンド | 実行数 | オプション |
1 | systeminfo | 16 | |
2 | ipconfig | 13 | /all /? |
3 | tasklist | 7 | |
4 | netstat | 5 | -ano |
5 | whoami | 2 | |
6 | net start | 2 | |
7 | arp | 1 | -a |
8 | chcp | 1 | |
9 | net time | 1 | |
10 | ver | 1 |
表11: 探索活動(攻撃グループC)
順位 | コマンド | 実行数 | オプション |
1 | dir | 11 | |
2 | net user | 1 | /all /? |
3 | net view | 1 | |
4 | qwinsta | 1 | -ano |
※ 攻撃グループCは、感染拡大を行わなかったため、感染拡大のコマンドについては省略しています。