通信やファイルが検査できないことの危険性と対処方法について

[khayakawa]

　ネットワークセキュリティ対策としての「ゼロトラスト」に対して理解が広がってきておりますが、具体的な実装方法についても理解はまだまだ十分であるとは言い難い状況です。ゼロトラストを実現するために次世代FWやSASE/PrismaAccessの導入を検討していただいているお客様も多いですが、技術的な理解に基づいて、適切な設定やポリシーを適応しないと、十分なネットワークセキュリティ対策ができているとは言えない状態になります。具体的な検査できない危険性とは何を意味しているのかについて以下に説明します。

1. SSL通信
   　今やインターネットの通信の９割以上がSSLによる暗号化通信です。暗号化された通信はそのままでは通信内容の検査が行えず、マルウェアファイルのダウンロードや機密情報のアップロードを行われても、まったく検知できません。宛先IPやFQDN/SNIでの可視化やフィルタリングができる程度です。この課題を解消するためには「SSL復号」機能が有用です。しかし、一般的にSSL復号の導入の足かせになるのが、クライアント端末にSSL復号用のルート証明書のインポートが必要になる点とSSL復号の処理を考慮したサイジングです。
   　このルート証明書をインポートしなければ、Webブラウザーがセキュリティ警告が出てしまいます。これは組織における端末に対するガバナンスにも関係し、BYODではルート証明書のインポートが困難であるケースも少なくはありません。しかし、SSL復号しなければ、インターネットや外部ネットワークとファイルやデータのやり取りをされているかもまったく検査や確認ができないため、危険性は高いと言わざるを得ませんので、端末に対するガバナンスやセキュリティポリシーの検討を是非お願いします。
   　また、PAシリーズのアプライアンスの場合、SSL復号による処理負荷を考慮したモデル選定を行う必要があり、将来的なトラフィック増加も考慮したモデル選定が少し難しくなりますが、Prisma Accessのモバイルユーザの場合、オートスケールの仕組みがあるため、サイジングを考慮することなくSSL復号が利用が可能です。
   
   
2. パスワード付きZIP
   　従来一般的に外部に気密性の高いファイルをメール添付する場合には、パスワード付きZIP形式を使うことをポリシーとして来ていた歴史もありますが、昨今ではEmotetなどのマルウェア自身もパスワード付きZIPファイルを利用します。パスワード付きZIPの場合、ファイルに対する検査が行えませんので、マルウェアファイルの侵入の検知/防御ができませんし、機密情報のファイルを外部に送信されても検知できません。そのため、米国や日本政府でもパスワード付きZIPの利用を廃止するようになってきています。また、それに伴いメールのファイル添付をやめ、クラウドサービスを利用してのファイルの受け渡しを行う方法を推奨しています。ですので、今後セキュリティポリシーの見直しを行っていただき、パスワード付きZIPの利用を制限することをご検討いただければと思います。
   　尚、PAシリーズやPrisma Accessでのファイルブロッキング機能にて、パスワード付きZIPの検知やブロックが可能ですので、強制的にSMTPのメールの添付ファイルがパスワード付きZIPであった場合などにはメールをブロックすることも可能です。
3. TLS 1.3/Encrypted SNI
   　現状のインターネットでのWebサイトの多くがTLS 1.2ですが、TLS 1.3が標準化され、徐々にTLS 1.3も普及し始めています。このTLS 1.3の規格でリスクがあるのが「Encrypted SNI」というSSL接続開始時のネゴシエーションを省略し、SNI(Server Name Identifier)さえも最初から暗号化する通信方式です。この通信を行われると、通信内容の検査ができなくなるだけではなく、アプリケーション識別やURLフィルタリングなどの制御も不可能となり、通信先のFQDNなどの確認もできなくなります。このEncrypted SNIの通信を行うための前提として「dns over https」（移行はDoHと表記）の利用があります。このDoHの通信により、従来SSL接続時のネゴシエーション時に行っていた暗号化に関するネゴシエーション処理を行うことで、SSL通信の最初から暗号化の通信を開始します。DoHは既にGoogle ChromeなどのWebブラウザーに実装されており、利用者が意識しなくとも利用してしまう状況になってきており、マルウェアもこの方法を悪用が始まるとまったく検知、防御が不可能となります。以下の英語サイトでもこの危険性について説明が参照していただけます。
   　https://live.paloaltonetworks.com/t5/blogs/new-advanced-url-filtering-pandb-category-encrypted-dns/b...
   　このリスクに対する対応方法としては、次世代FWやPrismaAccessにて、このDoHを遮断する対策となります。DoHを遮断した場合、Webブラウザなどは従来のudpベースのdnsに自動的にFallbackしますので、インターネット利用に関して利用者への弊害は基本的にありません。具体的な設定としては、App-IDではdns-over-httpsを禁止、URLフィルタリングで「Encrypted-DNS」のカテゴリをブロックポリシーを設定することで対策可能です。
   
   

インターネット上で利用される技術は変化しており、サイバー攻撃者はそれらの新しい技術を悪用した攻撃を仕掛けてきます。防御する側である我々も、その変化や技術を理解し適切な対処を行う必要があります。今後のセキュリティ対策の参考になれば幸いです。