## page was copied from DnsTemplate ##master-page:HelpTemplate <> <> 出発点として参考にする。-- ToshinoriMaeno <> ---- https://twitter.com/58_158_177_102/status/1287582571690303488 2020年7月27日 [重要なこと・意識変革] ・ 攻撃者の価値はシステムにある 今までは、情報資産を価値としてとらえていたから、うちは狙われる情報なんて、となっている組織もあったが、 攻撃者にはシステムが資産であり、攻撃者はシステムを狙っていると認識すること {{{ ・ 基本は総合力向上・あらゆるセキュリティ対策要素が求められる }}} 根本的に対策するなら、システムをインターネットから分離する覚悟で。 それがビジネスやコストでできないのではあれば、様々なポイントを弥縫する覚悟が重要。 総合力でなんとかするしかない。 午前11:56 · 2020年7月27日 == 全ての根源は侵入防止(侵入) == 　バックアップが、とか言う前に、どんな攻撃者であろうが進入路があるため、そこを突破されないことに注力すべき。(とはいえ一番大変である) 　狙われルートと対策は以下 === === 　クリティカルなパッチは絶対にすぐ適用する 　管理コンソールを外部にあけない(その他のNW機器もすべて)。MSPなどでメンテナンスが必要な場合はIPを絞る 　認証は多要素認証で 　機器の接続ポリシー(AV等の導入) 　VPNで入ったレンジからアクセスできるサーバやサービスを絞る 管理者アカウントやビルトインアカウントでVPNを使えないようにする(adminなど) 　認証ログを分析する(海外アクセス・認証失敗・ポリシー違反など) === === 　クリティカルなパッチは絶対にすぐ適用する 　(リモートワークで必要だからあけている場合)メンテナンスで必要な場合はIPを絞る 　認証は多要素認証で 　管理者アカウントやビルトインアカウントでVPNを使えないようにする(adminなど) 　認証ログを分析する(海外アクセス・認証失敗) === <シンクライアント> === (外部から端末やレシーバ等でアクセスを許可している場合) 　クリティカルなパッチは絶対にすぐ適用する 　認証は多要素認証で 　管理者アカウントやビルトインアカウントでVPNを使えないようにする(adminなど) 　認証ログを分析する(海外アクセス・認証失敗) === <メール> === 　基本はマルウェアメール対策なので書ききれないので、 いろいろ参照で(危険な拡張子を制限する、ローカルで関連付けを変える、不審メールを開かないよう教育するなど) 　サンドボックス系の製品によるチェックは有効 === === 　他拠点や海外拠点からの接続は、アクセス可能なサーバやポートを絞る 　ログを分析する(Denyログの増加など) <その他> 　過去に別サービスで流出したアカウントが不正侵入に使われている可能性がある。個人使用のサービスに組織のアカウントを使わせないよう周知。 ※流出したアカウントの叩き潰しは、その情報収集の難度や適法性からもユーザ企業には困難 == 侵入を防止し気づく仕組みを(攻略) == 　一般的な標的型攻撃と同様で、システム侵入型ランサムに特化したわけではない 　ただし、これらの攻撃者の傾向としては、重要な情報を窃取・破壊し、システム全体を停止させた方が効果が高いことから、まあまあ派手に全体探索を行うことが特徴的ではある。 　内部へのポートスキャンを検知する (ハニーポットサーバを置いて、通信があったら検知するなど、手法はいろいろ) 　サーバセグメントからのインターネットへの通信を制限する(All Deny 必要なものをAllow) 　サーバセグメントからイントラネットへの通信を制限する(All Deny 必要なものをAllow) 　クリティカルなパッチは絶対にすぐ適用する 　RDPはIPを絞る -> 許可されない端末からRDPが来たら検知する 　RDPのポートを変更する -> 3389の通信が来たら検知する　 リモートアクセスの機能を絞る 　管理者ログインを多要素認証にする) ADを含めサーバにAVやEDRを導入する(かつ、検知されたらリアルタイムで反応できる監視体制をひく) 　あとは、様々なADのセキュリティ対策を(不要なビルトインアカウントは停止する。 アカウントの管理者権限は最小限に。管理者権限の付与は最小に、などなど) <端末> 　AVでは検知できないツールを使うことが多い。 特に、リモートデスクトップサービス製品(TeamViewerやAnyDeskやクラックしたRDP製品)を、端末にRDPをインストールさせない (もしくは実行制限する)ことや、これらの通信先を制限するなどの措置も効果あり。(在宅勤務で難しいか。。。) == 被害の早期検知・最小化(軽減・回復) == 　外部に送信されるサイズの大きいファイルの通信をとらえる(送信完了しないとログに載らないので注意) 　イベントログの削除を検知する 　GPOの変更を検知する <バックアップ> 　攻撃者はバックアップをランサム化することで大ダメージを与えるため、バックアップのランサム化を狙ってくることを意識する。 ・ バックアップサーバが壊される ・ 正副で同期兼バックアップをとっている場合は、暗号化されたデータが複写されてしまう ・ シャドウコピーは消される テープなどの物理的に別な方式で取得する 　NASやUSBでストレージに定期的にバックアップして、普段は切り離しておく 　 ドメインから切り離したサーバとアカウントでバックアップする などなど、世代管理も含めリスクに応じたバックアップ自身のシステムとライフサイクルを再設計する <インシデントハンドリング> 　もしランサム化された場合、攻撃者が再感染のためのコネクションを残している可能性がある。 　 そのため、バックアップから復元する際には、侵入経路と、外部との通信経路が残留していないかを早期に確認すること。 <その他> 　暴露(もしくは、データ復元できず業務影響が大きい時)を止めるために、攻撃者に支払うか。。。 　 経営判断。 　倫理的には(更なる攻撃を誘発するため)、支払いは避けてほしいが。。。 == 今後 == クラウドの管理者アカウントが乗っ取られるとか、クラウド側を攻撃される可能性もあると思っています。 クラウド管理コンソールはインターネットに開いていることも多いので、 認証情報やログインログがオンプレと同様に管理・監視できているか見直す必要があると考えています。 いくら対策をしようが安心できないリスクのため、正直、この一年くらい、この話題についてはアタマから離れません。 実際の事案対応や、共有された外部事案から、少しずつ対策を積み増している状況ですが、 同じリスクを抱えていらっしゃる方々の何かの参考になればという思いです。(長文だなぁ。。。) (管理者が手薄な時間のケア : 業後や休日を攻撃者が狙っている傾向があるため、 そのような時間に対応した監視ルールや、異常アラートを受けて対応できる仕組み作り、 も書きながらいれようと思っていたけれど、忘れていた。。。 とはいえ、この対応はユーザサイドは求められても辛い) ---- CategoryDns CategoryWatch CategoryTemplate