を記載しました。結果的に脆弱性話題になりましたが、連載（２）では、どのような話を記入しようかな…
サイバー攻撃対策として、１つ目のネットワークが侵入されても、もう１つのネットワークがある。この２つのネットワークで侵入を防ぐ！という設計を考えた経緯があります。例えば、インターネットゾーンはCriticalな脆弱性の頻度が少ないPaloaltoにして、２番目の社内ネットワークは、インターネットゾーンに置いたUTMとは別のメーカーのものを置かなくては意味がないよね、という構築ベンダーからの指摘がありました。
確かにそうですよね。
設計イメージは、インターネットゾーンのUTM①と社内ネットワークのUTM②を、unnumberedで結合するという仕組みです。このメリットは、UTM①とUTM②がまるで1つのUTMのかのように動くという仕組みです。この場合だと、UTM①から脆弱性等で侵入された場合、そのままUTM②まで通信が走り、社内ネットワークに入り込まれてしまうというリスクがあって、UTM１台と対して変わらないんじゃ？ということとなり、結果的にボツとしました。
unnumberedで行うケースとして、PaloaltoはIPv4 over IPv6の設定ができないため、ONUの下に対応のUTMを置いて、unnumbered接続でPaloaltoを置くというシーンを考えたケースがありました。結果的には、PPPoE接続で今は留まっています。
過去に、某メーカのルータの下に、SonicWallを置いて管理したケースがありました。この場合、フロントのルータに通信ログが溜まり、SonicWall側のログは社内アクセスのログだけとなり、ログを調査するには2種類の機器にアクセスしなくてはいけないという問題点や、ルータログだとあまりにもシンプルすぎて脅威が分からないといったケースを経験したためです。そのため、社内外の通信を1台（１組）で管理することで、時間軸からログを相関分析をかけ、どのように異常通信が発生しているのか、分析しやすくするには、シンプルな構成が重要ではないかと考えます。
このunnumberedで接続する方式ではなく、UTM①とUTM②をUTMとして繋げる、という構成も考えた経緯もあります。危険なネットワークとして位置付けさせたUTM①と安全なネットワークUTM②の2台のUTMの脆弱性を管理をしなくてはいけない問題と、UTM②からきた通信はUTM①は安全として見なして通信を流さないといけないという、例外設計が必要になってしまうため、UTM②内のネットワークが侵された場合は、この接続方式だと、UTM二重化を行なったところで、今回目的のセキュリティ対策の効果は得られにくいよね…という思いから、結果的にボツとなりました。
いずれにせよ、UTMを2台で冗長化させることは最低限必要なため、①2台・②2台の形４台必要となり、コスト面・運用面から1〜2人程度の少人数管理で行うには、運用不可能という理由からでもあります。
結局、多段UTMの構成において、それぞれのUTMを違うメーカーで組み合わせなくては、セキュリティ対策として、あまり意味がなされないという問題がある中で一方、複数のメーカーのUTMで組み合わせるには、ForiGate・Paloalto・F5・Cisco・WatchGuard・Juniper・SonicWall・Sophos・CheckPoint等、多数のUTM製品があるものの、例えばログ監視代行のSOCを利用する場合には製品が限られることから、製品選定に自由がないのも原因も１つ。
インターネットゾーン沿いに置くUTMは１台とした従来方式を、そのまま継続する方向で考えました。おそらく、この構成の方が、ミスがなくシンプルでかつトラブル時の切り分けがシンプル、そして運用しやすいというが最も話です。
サイバー攻撃は平日日中にだけ起きるのではなく、業務時間外でも攻撃されるということです。業務時間帯内でも通信ログを常時監視しているわけではないので、Criticalなアラートを通知してくれるというSOC（Security Operation Center）サービスというのがあります。様々なベンダーがサービス展開されていますが、例えばUTMからポリシーによって出力されたアラートログを解析し危険性が高いログのみ通知してくれるサービスです。これはUTMの運用というより、アラートログを見落とすことなく管理してくれるサービスとなり、UTMに脆弱性があるかどうかは、管理対象外という問題があります。アラートログの管理代行ですので、それ以外はサービス外ですよね。
アラートログとして24時間365日管理しなくてはいけないのは、エンドポイント（PC等の端末）のセキュリティログでしょうか。これもまた、24時間365日監視することは不可能です。勤務先では、Cylance MDR（Cylance Guard）を利用しています。Cylance MDRについては、また日を改めて説明することにしましょう。
UTMのSOCサービス、Endpoint SecurityのMDRサービスを活用し、第三者のログ分析サービスを活用することで、早期の異常発見・早期対応が可能になるため、これはこれで効果的です。ただ、最終判断はこういう外部委託を行なっている側、内側の人間です。ここがSOCサービス・MDRサービスの重要ポイントです。最終的なアラート情報を提示してくれるまでは、外部機関で対応してくれますが、それを判決するのは利用者側なのです。言い換えると、危険かどうかわからないけど、あとは判断は自由にどうぞ、という世界ですので、外部サービスを利用したとしても、それなりの知識が必要でもあります。
最終的な判断は、出力されたログを見て分かる能力が必要。セキュリティ向上かと思って、やたらに複雑に機器を設置し、迷路状態にした場合、かえって原因調査が難しく脆弱性を生みやすい。シンプルな設計にし、その通信機器の脆弱性をなくし、守り通すことが、セキュリティ向上となり、結果的にサイバー攻撃対策にも繋がるのではないか、と思っています。
最近のコメント