私は 2012 年に、Taniumの最初の2名のテクニカル・アカウント・マネージャー（TAM）の1人として入社しました。 IT業界で働く多くの人たちと同様、私も長年にわたり、ヘルプデスクから運用、セキュリティ、ソフトウェアに至るまで、IT分野のさまざまな役割を担ってきました。 セキュリティ分野に携わる者として、私はTaniumが開発の初期段階にあった頃からその製品を目にして、その機能と可能性にすっかり魅了されました。
長年にわたり、ITチームやセキュリティチームが、時間的制約があり、独特で、かつ絶えず変化する課題に対応していく上で、ブラックボックス型のソリューションに頼ることはできないということが、私には明らかになってきました。 組織がベンダーの技術を採用する際には、その技術が、中核となる業務、セキュリティスキル、および能力を補完し、その効果を倍増させるものでなければなりません。
この記事では、これがどのような意味を持つのか、そしてそれがTaniumでの開発にどのようなインスピレーションを与えているのかについて、私の見解をいくつかお伝えしたいと思います。 私が自社に勤めていることを一旦忘れていただき、この業界に関心を持つ一市民としてお話ししているかのように振る舞わせていただきますので、どうかご容赦ください。
困難な問題を解決するための柔軟性
小規模な場合でも、ほとんどの組織におけるIT環境の管理や監視は、非常に困難です。 ネットワークに追加される独自のソフトウェアや、それぞれ異なるシステム構成は、いずれもネットワークの複雑さを著しく増大させます。 ユーザー、エンドポイント、デバイスを追加するにつれて、その複雑さは線形ではなく、対数的に増大していきます。 人手不足のチームは、欠陥のあるソフトウェア、誤解されがちなシステム、そして脅威アクターによる混乱に立ち向かっています。 セキュリティとリスクは、単なるマルウェアの問題にとどまりません。
まさにこの理由から、私やこの業界の他のベテランたちは、セキュリティ脅威の全領域を解決しようとする「特効薬」的な単一の解決策に対して懐疑的であるのです。 いくらその考えが魅力的であっても、セキュリティやIT管理の基礎という、華やかさはないものの極めて重要な業務を行う必要性を免除してくれるようなものは、何一つ購入することはできません。
私が4年以上前に入社して以来、Taniumは大きく成長してきました。 当社は、ユーザーが基盤となるアーキテクチャやソフトウェアの仕組み（ ）を気にすることなく、セキュリティおよびIT運用タスクを大規模かつ容易に実行できるワークフローの開発に多大な投資を行ってきました。 「Comply」、「Protect」、「IOC Detect」、「Trace」、「Patch」、「Trends」といった当社の製品モジュールは、すべてその理念に基づいて構築されています。
製品モジュールにとどまらず、私たちは常に、Taniumが単なる静的な機能の「ブラックボックス」を提供するだけでなく、「作り手」や「構築者」を力づける存在でありたいと考えています。 Taniumは当初から、プラットフォームの拡張性を確保し、コアクライアントを可能な限りシンプルに保ち、プラットフォーム全体を無限に拡張できるようにするという基本理念に基づいて設計されました。 その根底にある柔軟性こそが、私がTaniumがまだ創業間もない頃に同社に入社した理由です。 現在、当社のTAMは、お客様それぞれの環境における独自のニーズに応えるため、カスタマイズされたコンテンツやソリューションを迅速に提供しています。 そうしたお客様は自立性も高く、ベンダー独自の言語に頼ることなく、独自のセンサーやパッケージ、ダッシュボード、統合機能を頻繁に構築されています。 これまで、 について、多くの (新しいタブで開きます) シンプルな (新しいタブで開きます) 事例 (新しいタブで開きます) を紹介してきました。これらは、Taniumのオープンな姿勢が、過去の 技術ブログ (新しいタブで開きます) 記事で取り上げられた、重要かつ緊急性の高い問題に対する解決策をもたらした事例です。
理想的なチームの構築
Taniumでの仕事を通じて私が最も興味深く感じている点の一つは、数多くの組織のセキュリティチームが直面している課題、特に各チームの人員構成や組織体制の違いについて、ほんの少しですが垣間見ることができることです。 お客様から学ぶことに加え、私は幸運にも、TAM組織内の同僚たちからも多くのことを学ばせていただきました。この組織には、脅威の検知と対応、フォレンジック、IT運用、システム管理、ソフトウェア開発、トラブルシューティング、統合など、幅広いスキルを持つメンバーが集まっています。
こうした経験を通じて、今日の環境下で最も成功する可能性が高いと考える、セキュリティチームの「理想的な」構成像についての私の見方が形作られました。 言うまでもなく、専門知識は極めて重要です。CIRTチームには、ネットワークやエンドポイントのフォレンジックに精通した、優れたインシデント対応（IR）の専門家が必要です。また、評価チームには、経験豊富なレッドチームメンバーが不可欠です。 しかし、高度に専門化された人材を求める過程で、しばしば見落とされがちなのが、スクリプト作成やコーディングのスキルを持つチームメンバー（たとえそれが他の分野に応用されている場合でも）や、ITやセキュリティ運用に精通したメンバーです。 それは、グループの能力を拡大するだけでなく、多くの大企業においてセキュリティ部門とIT部門の間にしばしば見られる縦割り構造を解消することにもつながります。
業務のベテラン――特にその組織に長く在籍している方であれば――は、ロンドンのタクシー運転手のように社内ネットワークに精通しており、どのような用件であれば誰に相談すべきかを知っています。 （もしその方が社内で広く好かれているのであれば、それは確かにプラスになりますね！） その人物が、何年も前に何か大きな失敗を犯したか、あるいは他人の危機を収拾した経験があり、そのおかげで「恐怖心」を身につけていることを確認してください。 スクリプトや自動化を恐れてはいけません。 彼らの仕事は、お客様がどのような設備をお持ちか、それがどのように機能するかを把握し、適切な作業が安全かつ迅速に行われるよう確認することです。
優秀なプログラマーは、セキュリティチームのツールやスキルセットの効果を倍増させる存在となります。 情報セキュリティに関する深い知識は必要ありませんが、チームメンバーから学びながら、同時に自身の知識も共有することができます。 カーネルハッカーである必要はありませんが、セキュリティやDevOpsで最も一般的に使用されている言語のうち、少なくとも1つを扱える必要があります。具体的には、Python、Ruby、Golang、PowerShellなどです。また、かつてPerlやシェルスクリプトを扱った経験があり、少なくともC++のコードは読めることが求められます。 これらは、専門担当者の業務プロセスを自動化したり、APIやTaniumのようなプラットフォームを通じて既存のシステムを連携させたり、企業全体にわたる中核的なセキュリティ業務を拡張・簡素化したりするのに役立ちます。 同様に、実務に精通した担当者が、こうした取り組みを適切に管理し、安全な方法でテストおよび導入されるよう確保することができます。
セキュリティ業界には非常に多くの専門的なスキルがありますが、意外なことに、チームが見落としがちになるのは、これら2つの極めて幅広いスキルセットのうち、どちらか一方、あるいは両方であるようです。 コードを迅速かつ安全に作成・展開できるチームには、大きな強みがあります。
真の自給自足
Taniumの使命の中核をなすのは、組織が自社のシステムを管理・保護できるよう支援し、真に自立的かつ効果的な体制を築けるようにすることです。 つまり、使いやすく、小規模なチームが早期に成果を上げられるようなソリューションを構築しつつ、経験豊富なユーザーが新しいユースケースやワークフローに迅速に適応できるよう、十分な柔軟性を確保する必要があるということです。 「新しい」セキュリティ問題の多くは、エンタープライズ規模で、迅速かつ安全に、そしてクロスプラットフォームで、そのコードを確実にテストし、実行し、結果を収集することができれば、ほんの数行のコードで解決できるものです。 Taniumプラットフォームにより、センサー作成者は、従来のセキュリティ製品では検出できなかった状況を数秒で検知し、その日の問題――それがどのようなものであれ――の是正に役立つアクションを展開することができます。
その一方で、多くのセキュリティ製品は、あらかじめ用意された概念実証（PoC）デモを実行する際には見事な性能を発揮しますが、それぞれの環境特有の幅広いユースケースに合わせて調整や拡張が必要になった場合、あるいは大規模に適用された場合には、すぐにその限界が露呈してしまいます。 Taniumのオープンプラットフォームは、後付けのアイデアではなく、当初からの設計目標として掲げられたものであり、あらゆるベンダーの限界を熟知し、そのようなプラットフォームを備えた世界クラスのチームが、単なる機能一覧に挙げられた機能を超えて何ができるかを深く理解している人々によって構築されました。
著者「」について：ロリー・プレンダーガスト氏は、タニウムのエメリービルオフィスに所属するシニア・テクニカル・アカウント・マネージャーです。
