ツールありきではなく、運用ありきで――DeNAがEDRを導入した理由と製品選定のポイント：特集：EDRの理想と現実（2）（1/2 ページ）

　セキュリティ対策に銀の弾丸はない。何か1つ新しいソリューションを入れれば、即、問題が解決するわけではなく、運用可能な体制や手順を整えなければどこかで破綻する。ディー・エヌ・エー（DeNA）ではそんな考え方に立ち、少しずつセキュリティ対策を強化してきた。

　Webサービスやアプリの開発者が多数を占める同社では、エンドポイントPCはWindowsとは限らないし、利用するアプリケーションやツール類も多彩だ。Mac、Linuxといった複数のプラットフォーム上でさまざまな統合開発環境やオープンソースのツール、ライブラリなどがインストールされては試され、日々開発とリリースが繰り返されている。

ディー・エヌ・エー システム本部 セキュリティ部 松本隆氏

　一方、サービスの可用性を維持し、多くのユーザー情報を守るためにも、セキュリティ対策は必須だ。DeNAでは2011年12月に自社グループのComputer Security Incident Response Team（CSIRT）として「DeNA CERT（Computer Emergency Response Team）」を設立。エンドポイントにはアンチウイルスや資産管理ツールの導入、脆弱（ぜいじゃく）性管理やパッチ管理の仕組みの導入を行った。またゲートウェイ部分ではWeb Application Firewall（WAF）やネットワーク可視化ツールも導入し、適用範囲を広げてセキュリティ対策を行ってきた。NIST（米国立標準技術研究所）のサイバーセキュリティフレームワークでいう「防御」のプロセスだけではなく、「検知」「対応」も見据えた対策を進めてきた。

　その次に検討したのが、Security Operation Center（SOC）の立ち上げだった。「ユーザー企業としてやるべきことはかなりやってきた。その上で、足りない部分を補うためにSOCを立ち上げるため、DeNAに入社した」と、同社 システム本部セキュリティ部 松本隆氏は振り返った。

自社でSOCをきちんと運用するためのEDR製品を模索

　もちろんDeNAは以前から、エンドポイント向けのアンチウイルス製品を導入していた。だが、誤検知の多さに悩まされていたという。

　「最近ではシグネチャベースの製品に加え、機械学習を活用した振る舞い検知的な機能を搭載するものも増えています。しかし、こうした製品の多くは、一般的な事業会社の環境をベースに作られたもので、DeNAのような開発用の環境は学習しておらず、不具合や誤検知が多いことが課題でした」（松本氏）

　こうした背景から、エンドポイントをプロセスレベルでしっかりモニタリングしていきたいと考え、EPP（Endpoint Protection Platform）機能も付いたEDR（Endpoint Detection and Response）の導入を検討したという。

　このとき重視したのは、性能、機能もさることながら、DeNAならではの運用体制に合わせた運用ができるかどうかだった。他のセキュリティ製品同様、EDRも「運用」がキモだ。それだけに、マネージドサービスやSOCの外注サービスと組み合わせての導入を検討するケースは少なくない。だが、「一般ユーザーの権限では普通使わないような開発環境なので、一般的なサービスを買っても、なかなか運用できない可能性がありました」（松本氏）

　加えてDeNAの場合、開発スピードや品質といった要件を満たすため、アプリケーションの脆弱性診断を100％内製化していたという成功体験があった。そこで「EDRもWAFも、業者を入れず自分たちでやろうと考えました」（松本氏）

　それまでに運用サイクルがある程度形になっていたことも大きい。「可視化を実現し、誰がどう対応するかというドキュメントをきちんと作り、それをきちんと運用し、トレーニングして、振り返るというサイクルが必要なのですが、DeNAではその辺りがチームとしてきっちりできており、完璧とまではいかないですがドキュメントも出来上がっており、良いタイミングでした」（松本氏）

「ぱっと見て全体が分かる」ことを重視、良い意味での「運用でカバー」を実現

　DeNAではEDRの導入に向け、5つほどの候補の中からMacにも対応し、EPP機能を搭載している製品、2種類に絞って検証を実施した。「やはり触ってみないと分からない部分はあります」と松本氏。セキュリティ部を率いる茂岩祐樹氏の理解もあって、約2カ月じっくり時間をかけて、運用を見据えて検証を実施したという。

絞り込んだ2つのEDR製品（AとB）で何を検証したか（出典：ディー・エヌ・エー）

　繰り返しになるが、その際に何より重視したのは、「DeNAの実情に合わせて運用できるか」ということだ。SOCの運用には6〜7人が携わっているが、全員が全員セキュリティ監視業務に専念できるわけではなく、基本は「兼業セキュリティ」だった。

　「ユーザー企業としては、そんな運用でも回ることがけっこう大事でした。兼業で、時間を有効に使う必要がある以上、1つの動きを深く掘り下げていくよりも、可視性が高く、ぱっと見て全体で何が起きているかが直感的に分かる方が大事です。こうした観点から、現場のオペレーターの評価が高い、直感的に分かる製品を選択しました」（松本氏）

　松本氏は、以前はシステムインテグレーターなどでセキュリティ製品を提供する側に立ち、フォレンジック業務も行っていた経験もある。従って「フォレンジッカー」の観点からは、最終候補のうちもう一方の方が、状況の深掘りができ、「推し」製品だったそうだ。だが「日々運用し、トリアージする観点では、親子プロセスのつながりや全体の流れを追いやすく、理解しやすいという観点が大事だと考えました」（松本氏）

　DeNAでは、もしオペレーターが全体像を見て「より深い調査が必要だ」と判断すれば、別のツールを組み合わせて補う形にした。「運用プロセスがしっかり作られていれば、1個のツールで全てまかなう必要はありません。むしろ、それぞれに使いやすいツールを採用する方が運用が回るでしょう」（松本氏）

　運用プロセスの作り込みが必要なのは、同社のように自力でセキュリティ運用に取り組む企業に限った話ではないだろう。マネージドサービスや常駐エンジニアに任せるにしても、「何をどうするかをしっかり設定しないと、エンジニア側も動けません。依頼する側が何をどうするかを分からないまま丸投げしても、やはり運用は回らないでしょう」（松本氏）