見出し画像

【続き】セキュリティ機器とかサービスを導入するときに考えるポイントをまとめてみる


セキュリティ機器とかサービスを導入するときの面白さをまとめてみる の補足としてついでに書いてみます。
そうは言っても、上司から急に「いま入れてるオンプレ Proxy から、今度クラウド Proxy にリプレイスするから、今日からプロジェクト入って」と言われて喜ぶ御仁はそういないでしょう(私は喜びますが)。そんなお気の毒メンに向けて、考えるポイントなどを書いてみたいと思います。
はじめに言っておきますが、自分の経験も大したものではないので、すごい普通のことしか書いてません(布石)

通信機器の場合

何においても通信経路が変わるのかどうかを常に念頭に置きましょう。VPN、FireWall、Proxyなどは通信経路が変わる可能性が高いため、その経路を使っているものは最初に調べなくてはいけません。Proxyをクラウド型にリプレイスしようとしたけど、インターネットへ出ていくときのIPが固定できなくて困っちゃった、なんて話も聞いたことがあります。このへんはセキュリティ部門ではなく、ネットワーク部門の管轄になりますが、セキュリティ担当者としても通信経路がどうなっているかを把握しておくことは非常に重要です。

エンドポイント製品の場合

アンチウイルスソフト、構成管理ソフトなど、エンドポイントにインストールするタイプの製品であれば、全台に導入することが大前提です。インストールが完了していない端末があるとそこがセキュリティホールになります。100%を目指して導入すべきですが、絶対に数台は導入できない端末が出てきます。放置されて電源を入れてもらえない端末や、管理台帳が古い(SBOM早く普及して)など原因はさまざまですが、対応としては端末管理者にプッシュ、それでも回答がなければ上司経由で鬼プッシュするというドクトリンは変わりません。
どうしても配布できない端末が出てしまったら(出ます。絶対ッ)、ネットワーク側で当該端末を接続させない設定を入れておきましょう。クリーンな環境にそんな小汚い端末を繋がせるわけにはイカンのです。

Threat Intelligence(TI) を導入する場合

これ難しかったです。だって、どこのベンダの TI が自社に適合するかなんて誰にも分からないんですよ。とりあえず VirusTotal 使っとけ!というのもアリかもですが(個人的にはイヤですが)、TI をバルクで使いたいときは VT は合わないんですよね。バルクでTI を提供してくれるベンダを探したら、あとはひたすら PoC です。
必須の確認点としては、内容やデータ量はもちろんのこと、更新頻度(1日n回)、提供方法(FTP, API 等)、提供形式(JSON, CSV, XMLゥ? 等)も確認します。自動で取得する場合は、こちらからデータを取りに行く環境とプログラムも必要でしょう。組織によっては、内製部門に開発を依頼しなきゃいけないなどの手続きが必要になるかもしれません。
私が、その TI が自社に適合するかどうかを調べたときは、とにかく既存機器で観測できている攻撃情報と TI をひたすらぶつけていました。「A社が提供する1万件の IP のうち、うちの IDS が観測した IP にマッチしたのは100件なのでマッチ率1%。B社は、、、」という具合です。ただ、この考え方はデータ量が多いベンダはマッチ率が下がって不利になってしまうので、全ベンダのデータ量を均して計算していました(こういうやり方ってなんて言うの?)。また、マッチ率は日によって変動するので、1回だけではなく数日間集計する必要があります。「ぼくがかんがえた さいきょうの TI 評価手法」に近いものがありますが、当時は評価手法の正解を誰も知らなかったので、これで何とか上司を丸め込みました(今も知らんけど)。

SaaSの場合

製品自体の考慮点はオンプレとあまり変わらないのですが、SaaS と言いつつオンプレ環境が必要になることがあります。とあるメールセキュリティ製品は、送信メールを通すには特定のヘッダを入れる必要がある、ということがありました(なりすまし防止のため)。送信メールサーバ側でヘッダをカスタマイズして送ればいいのですが、あいにく送信メールサーバがヘッダのカスタマイズ機能を備えていない場合、経路の途中にMTAを挟み、そこでヘッダをいじって送ることになります。そうすると、本来は検討していなかった MTA サーバが必要になり、単一障害点も増えてしまいます。「SaaS だからサーバの管理から開放されるぜー」と思っていたインフラチームはガッカリすることでしょう。
オンプレであればインフラ部門は構成上の制約事項や運用のノウハウを持っていると思いますが、SaaS となると思わぬ落とし穴があることもよく聞く話です。

最後に

自分の導入ノウハウは完全に走りながら(泣きながら)身につけたものであり、この考え方が正解なのかどうかも分かりません。ただ、正解が分からない中でもみんなが納得できるような道筋を考え、PoCをし、導入して運用できているので、満点では無いまでも及第点はもらえることでしょう。セキュリティ業界は「正解は無いけど不正解はある」という場面が多すぎるので、困っている方が不正解に近づく前にこの記事が少しでも参考になれば幸いです。
最近は SOC の立場で製品を導入するということは無くなったので、製品導入で困っている人がいれば、お手伝いしたいなーとボンヤリ思っていたりもする日々です。


この記事が気に入ったらサポートをしてみませんか?