SIEMはIBM i サイバーセキュリティの一部に過ぎない
IBM i ビジネスのオーナーたちから、このような話を聞くことがよくあります。SIEM（Security Information and Event Management: セキュリティ情報およびイベント管理）は、IBM i 向けのサイバーセキュリティ ソリューションである。しかし、そんなはずはありません。ここでは、SIEMがどうしてセキュリティ防御策のあくまで一部分であって、そのすべてではないのかということについて説明しようと思います。
まずは、SIEMとはどのようなものかについて、そしてSIEMがどのようにサイバーセキュリティ フレームワークに組み込まれているかについて見てみましょう。SIEMは、PCIの付録の中で触れられていますが、250件以上あるPCI DSS要件の中心部に置かれたことは一度もありません。同様に、NISTサイバー セキュリティ フレームワークでは、ほぼすべてのフレームワークがそうしているのと同様に、イベント監視をNISTコア要件の約100項目のうちの1つ（約1/100）としてリストしています。したがって、SIEMは、どのサイバーセキュリティ フレームワーク（PCI、SOX、HIPAA、NISTなど）においても、それらの一部分でしかありません。
IBMでは、世界中のクライアントで発生している1日当たり1,500億件のイベントを監視 して、 「脅威インテリジェンス・インデックス」を開発しています。皆さん、1日当たり1,500億件です。1,500億という数との脈絡で言うと、その数は、私たちのいる天の川銀河にある星の数とおおよそ同じくらいです。こうして収集されたログ データはすべて、私たちサイバーセキュリティの専門家が「Alert Fatigue（アラート疲れ）」と呼んでいるものをもたらします。
脈絡と言えば、脅威を特定するためには、 脆弱性 データを現実的 リスクに関連付けて、そうしたログ データすべてが具体的な何かを意味するようにさせることが必要です。そして、ノイズを小さくするための1つの方法は、脆弱性および脅威の数を少なくすることです。脅威は、脆弱性を悪用して 財務上および企業イメージ上のリスクをもたらします。別の言い方をすれば、しかるべき脅威のコンテキストなしでは、イベントの属性の特定は、ひいき目に見ても、難しいか不可能です。
IBM i の脅威を特定できるように、SIEMアナリストに、 正常な挙動 とはどのようなものなのか尋ねると、彼らはおそらくこう答えます。IBM i のログには、脅威とみなすためのコンテキストがない、と。さらに言えば、読者の皆さんは、すべての適正なデータのログを記録してさえいないかもしれません。要は、IBM i における多くの昇格特権および脆弱性を適正に使用するということがどういうことなのか分かっているとしたら、私たちがそれらの特権および脆弱性をすでに修正しているということです。まさにその通りです。皆さんのIBM i プラットフォームには、脆弱性および脅威が存在している可能性があるのです。IBM i は、最も セキュアにすることができる システムの1つですが、開発者がトレーニングされておらず、セキュアなコーディングを実践していない場合は、思っているほどシステムはセキュアでないかもしれません。
私たちが頻繁に検出する多くの脆弱性の1つに、DDM/DRDAが*USRIDに設定されているというものがありますが、これはセキュアな値である*ENCUSRWDへ修正されるべきです。けれども、どうして出荷値の*USRIDPWDから変更されたのか誰も分からないというケースもよくあります。 *PUBLICおよび専用権限が設定されたプロファイル、特殊権限、デフォルト パスワード、アクセス制御分類、借用権限、システム値などについても同様です。私たちBFB Security社のようなSME（Subject Matter Expert）による専門的な分析なしでは、そうしたセキュリティ対策をきちんと行うにはどうすればよいかは誰も分からないでしょう。そして、私たちは、まさに前述したように、アラート疲れのSIEMおよびスタッフにとっての、サイバーセキュリティのごみ埋め立て地を造っているのです。
それでは、サイバーセキュリティ フレームワークに戻りましょう。IBM i も、これらのフレームワークから免除されません。フェラーリが道路交通法から免除されないのと同じです。これらのスーパーカーが法律に従わなければならないのと同じように、IBM i はサイバーセキュリティ フレームワークに準拠する必要があります。SIEMSおよび監視ソリューションは、もちろん、上述したように、すべてのフレームワークの要件の一部分であり、サイバーセキュリティにおける不可欠な1つの歯車ですが、これらのフレームワークには、イベント監視だけでなく、それぞれ何百もの前述したような標準が含まれています。
私たちも「why monitor a problem if you don't fix it.（問題を修正しないなら、どうして監視するのか）」というCMフレーズの意味は分かっています。最後に、データ漏洩を止めるためにはゼロ トラストおよびリスク管理が必要だと、どうしてSplunk社（世界トップ レベルのイベント監視システムを提供）が言うのでしょうか。普通なら、Splunk社はサイバーセキュリティの完全なソリューションとして自社のツールを宣伝しようとするだけで、脆弱性、脅威、リスク、ゼロ トラストなどについて語ることはしないと思うでしょう。おそらく、Splunk社はそのことをある程度分かって言っているのかもしれません。そう思いませんか。
このこともお伝えしておきたいと思います。IBM i 脆弱性診断の後の現実世界での侵入テストでは、パスワード（*USRID）なしで、DDM/DRDAを通じて開発システム上にセキュリティ管理者（*SECOFR）クラス プロファイルを作成する侵入テストを行いました。問題なく、*SECOFRプロファイルを作成できました。SIEMアナリストがそのテストを検知していたかどうか尋ねたところ、彼らは肩をすくめるだけで、私たちの狙いは何かと尋ね返されました。1週間後、電話があり、SIEMアナリストはアラートを出さなかったということでした。そうして、もうひとつの大規模なIBM i エンタープライズ リスク管理プロジェクトが始まりました。
繰り返します。サイバーセキュリティのごみ埋め立て地を造ってはなりません。 サイバーセキュリティは人員とプロセスとテクノロジーが3本柱です 。適切なコンテキストを持たないSIEMは、1本柱のサイバーセキュリティであるに過ぎません。他の2本の柱なしでは倒れてしまうのです。そして最後に、皆さんもご承知でしょうが、サイバーセキュリティというのは1度やっておけばそれで済むというものではないのです。
