Network haker

【セキュリティ】OSINTとアタッカーサーフェスマネジメント(ASM)|ネットワーク構成図の管理イコールセキュリティ対策なのか

投稿日: カテゴリー: セキュリティ
Pocket

年末になったのを思い出したかのように急冷却を始めた12月ですが、セキュリティは年中無休なので年末感出されるとより仕事が増えます。
年末休業など書かれればその期間を狙われますし、波風立てたくない平常性バイアスも高くなりガチです。
忘年会などの飲みが減少した結果か、社用携帯などの情報端末紛失は一時期より減った感がありますが、リモートが当たり前になった働き方ゆえ情報がインターネット上に置かれることが当たり前になっています。
インターネット上に置かれているものが、コロナ禍という時代の強制イベントにより関所のキャパを圧倒的に超えてまともな審査も行えず実態も把握できずの状態になっている企業も少なくありません。
だからこそ時代はゼロトラストじゃないかと、なんでもAIが解決すると言い張る人種に近い方々が意見らしいことを言ってきそうですが、役割と実行責任(Role and Responsibility)の明確化が前提となるゼロトラストの前提すっ飛ばして方法論のバズワードを言ってきているだけなので生暖かい目で、華麗に流す技術がセキュリティのプロの皆さんには求められます。
冗談はさておき、信用できないリソースを前提に「セキュリティ=社会責任」を実現するため」、経済産業省 商務情報政策局 サイバーセキュリティ課の出している🔗ASM (Attack Surface Management)導⼊ガイダンスを参考にOSINTを通じたサイバー攻撃に筋道立てながらあるべき、アタッカーサーフェスマネジメント(ASM)とネットワーク構成図管理を考えてみたいと思います。

事業リソースは無制限ではないので、ネットワーク構成図のあるべきからよりセキュリティ要求として必要な最低限の管理を考えていきたいと思います。

OSINTの歴史と定義

OSINTは「合法的に入手できる資料を調べて突き合わせる手法」と辞書的にはググれば出てくるが歴史もしっかりセットで抑えましょう。OSINTの歴史は、国際弁護士として情報収集を行っていたWilliam Donovanの活動を国家の正式な活動とするべく、1941年7月11日戦略諜報局(OSS)に世界中から新聞、雑誌、ラジオ放送のレポートを収集し、オープンソースインテリジェンスを活用した「Coordinator of Information」という部門を設けたのが始まりといわれます。OSSは1945年終戦の1ヵ月後に解散しましたが、後継の国務省情報調査局(INR)と独立した中央情報局(CIA)に引き継がれインテリジェンス業務はすぐに再開され現代まで至ります。現在は世界中で公式・非公式でOSINT活動は実施されていますが、印刷物なども収集しますが、インターネットで収集がメインとなりCIAの情報収集もググるが9割と言われます。ググって見つからないのは技量の問題かもしれませんね。OSINT活動は、みんな大好きサイバーキルチェーンの偵察の段階がメインとなります。偵察と公開されたIT資産の関係を見ていきたいと思います。

サイバーキルチェーンとデータソースのマッピング

サイバーキルチェーンの偵察に対応するデータソースは、IT Infrastructure, Arhive(第三者アクセス範囲にある意図せずアップロードしアーカイブされた情報), Social Media(不特定多数の第三者が入るメディアでの情報発信)とあり、今回はIT Infrastructureに焦点を当てれば良いことになります。監査的な観点では以下に示す方法などで管理漏れや制御漏れの対象がないかテスト(ペンテスト)を行い、管理状況や制御状況を見直すと良いでしょう。

IT Infrastructureの情報の確認方法

Shodan:IoT(Internet of Things)/OT(Operational Technology)システム、公開されたポート、バグを検索する方法としてよく用いられているツール
Google Hacking Database Google Dorks(グーグルドーク)検索コマンドを活用し、意図せずインターネット検索可能なシステム、データなどを探す方法をまとめたサイト

Arhive(第三者アクセス範囲にある意図せずアップロードしアーカイブされた情報)に関連したツールも一件だけ
Metagoofil:公開されたファイルからメタデータを抽出し、ディレクトリ構造やサーバー名といったIT資産の情報をユーザーに提供する。

アタッカーサーフェスマネジメント(ASM)の定義

🔗経済産業省の資料ではASM(Attack Surface Management)とは組織の外部(インターネット)からアクセス可能な IT 資産を発⾒し、 それらに存在する脆弱性などのリスクを継続的に検出・評価する⼀連のプロセスとしています。

一方でNIST SP800-53の定義では攻撃⾯の対象として組織の外部・内部については⾔及されていないとなっており、攻撃者の立場からアプローチ可能であればAttack Surface

 

The set of points on the boundary of a system, a system component, or an environment where an attacker can try to enter, cause an effect on, or extract data from, that system, component, or environment.

いずれの場合もASMは①攻撃⾯の発⾒、②攻撃⾯の情報収集、③攻撃⾯のリスク評価の手順になります。

リスクの検出・評価が存在する故、脆弱性診断との違いを聞かれることがありますが、IT 資産に含まれている可能性のある脆弱性情報を提⽰する。脆弱性診断と違い情報を突合しただけであり、攻撃条件を満たしているかも攻撃により被害が発生するかも特定しているわけではありません。

アタッカーサーフェスマネジメント(ASM)から見るネットワーク構成管理

セキュリティ要求に於けるネットワーク構成図の目的は、管理下にある情報資産に関係するコンポーネントに接続する対象から影響があり得るか否かを判断できるようにすることです。

ネットワーク管理には物理構成管理(ルータ・サーバ・パソコン端末などの配線、ポートなどの制御状態を示したもの)と論理構成管理(ネットワーク内の識別子に基づき、それらが付与された対象のネットワーク内に於ける情報の流れと、その制御を示したもの)がありますが、AWS環境などパブリッククラウドサービスでは責任分担モデルから事実上、物理構成管理は対象外とでき論理構成管理に注力すれば良くなります。

物理構成管理は資産台帳チックな表で、会社ごとに独自の管理文化が存在するかと存じますので不要な争いを避けるため、皆さんの所属組織のネットワーク考古学者にお尋ねすることをオススメします。

論理構成管理に関しては「これが書けていれば十分でしょう」という6項目を以下に紹介させて頂きます。

※AWS・Google Cloud・Azureが混在するではVPC(AzureではVnet)やサブネット、AZの制御・構成範囲が異なりますので外から内に書いていくか、図示して違いを可視化しておくことをオススメします。

1.クラウドサービスの差異を考慮して仮想マシンが設置されているリージョン・VPC・AZ・サブネットとクラウドサービス名を記載する

2.VPC(VNet)やサブネットにはCIDRを記載する、対応するEIPが存在する場合は記載する

AWSでCIDRを取得するコマンド例(サブネットはそのまんまaws ec2 describe-subnets

aws ec2 describe-vpcs --query "Vpcs[].[{CIDR:CidrBlock,Name:Tags[0].Value}]" --out table

3.コンポーネントに設定されているアクセス制御の設定(ACL、Policy、Security Groupなど)の「識別子」を記載します(直接書かないのがポイント)

aws ec2 describe-network-acls

4.アクセス制御の設定の「識別子」ごとにアクセス制御の設定(ACL、Policy、Security Groupなど)の「内容」を記載します(JSON形式で有効期限と変更管理責任者(ロールやアカウントグループ)も併せて記載します)

5.コンポーネントに適応されているセキュリティサービスと運用状況を記載する(無効化、有効化、運用(〇〇責任)・・)

6.外部API(Webhook含む)やサービス連携などを記載

アタッカーサーフェスマネジメント(ASM)から見るネットワーク構成管理としてはこれで良いのですが、アーキテクチャ図のような可視化も併せて要求されることが多いかと存じますので、TerraformからAWSのアーキテクチャ図を可視化したい場合の便利ツールや、そもそもTerraformにしてなかった環境をTerraformに出力するツールや方法なども存在します。

マイクロサービス化などますます最近では、木を見て森を見ないと有効なセキュリティが実現できない世の中になりつつありますので、アタッカーサーフェスマネジメントを意識したネットワーク構成図を実現し、一歩時代をリードしましょう。また、文中でアタッカーサーフェスマネジメントでは脆弱性診断のようなリスクによる被害の確認までは行っていないとお伝えしましたが、リスクマネジメントの要求からリスクによる被害の確認までを行う必要がある場合は先日私が投稿した以下の記事をご参考頂きクラウド診断を実施頂けましたら幸いです。

🔗【全モジュール解説】AWS特有のセキュリティリスクとPacuでクラウド診断/ペネトレーションテストの実施(2023年12月更新)

以上です。来年も皆様の企業が平安に過ごせますことを祈りまして締めとさせて頂きます。