Chatwork株式会社

属人的だった脆弱性管理を標準化、Log4Shellも横断検索で影響調査

2000年に創業したChatworkは、メール・電話・会議に代わるビジネスコミュニケーションツール「Chatwork」を提供し、343,000社（2021年12月末日時点）に導入されています。Chatworkでは、セキュリティ対策として脆弱性管理クラウドyamoryを導入し、プロダクトの安全性を強化しています。yamory導入の経緯、活用状況について、プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャーである田中佑樹氏、およびプロダクトセキュリティ部の新沼孝之氏にお話をうかがいました。

Chatwork株式会社
業務の効率化と会社の成長を目的としたメール・電話・会議に代わるビジネスコミュニケーションツール「Chatwork」を提供

業種　　　SaaS

従業員数　247名（2021年10月末日時点）

掲載日　　2022年1月

課題

• 手動で脆弱性管理をしていたため、手間も時間もかかっていた
• 脆弱性有無の判別が人の知識に依存、属人化していた
• 利用しているソフトウェアを把握できず、重大な脆弱性を見過ごす可能性があった

• ダッシュボードが非常に見やすくシンプルで、何をすべきかわかりやすい
• Jiraへのタスク連携ができ、既存の業務プロセスとの親和性が高かった
• 自動的かつ網羅的に脆弱性リスクを可視化でき、属人性の問題を解決できた
• オートトリアージ機能で、一次トリアージを自動化できた
• Log4jの脆弱性（Log4Shell）対策も、横断検索機能で影響調査できた

活用シーン

•  
• GitHubスキャンとコマンドラインスキャンを活用、定期的にスキャンしている
• プロダクトセキュリティ部で週に一度yamoryのアラートを確認し、対応指示している
•  

田中氏：
プロダクト本部の副本部長として組織開発や採用などを行っています。また、プロダクトセキュリティ部を立ち上げてマネージャーを兼任しており、セキュリティの向上に取り組んでいます。

新沼氏：
yamoryの検知状況の確認などを行うほか、プロダクトセキュリティ部として2週間単位で実施しているスクラムで、セキュリティ施策に関するタスクを担当しています。

 

田中氏：
プロダクトセキュリティ部という、プロダクトに関するセキュリティの向上をミッションにしている部署があります。マネージャーである私を含めて3人体制ですが、2人は鹿児島にいますので、ChatworkによるチャットとWeb会議でコミュニケーションをしています。

それまでセキュリティ専門の組織がなかったため、各部署が個別にセキュリティ対応を行っていました。しかし、それではどうしても片手間になってしまいます。サイバー攻撃を受けたとしても、主体的にレスポンスを行うチームがいない状況が続いていたわけです。

この状況に対し、経営層を含めて漠然とした不安を感じており、私としても何か重大な事故が起こってからでは遅いという思いがありました。そのためまずは専任をたててしっかりとセキュリティの課題に対して向き合おうと思い、プロダクトセキュリティ部を立ち上げました。そして、社内でセキュリティ業務に関心のある人を募ったところ、新沼さんが手を挙げてくれました。それが始まりです。

新沼氏：
もともとはSREというインフラのチームに所属していたのですが、プロダクトセキュリティ部の設立のお話を聞いて、セキュリティに興味がありましたし、力になりたいと考えて立候補しました。

田中氏：
セキュリティ専門のチームができたことで、Chatworkのセキュリティ向上に貢献できているという実感があります。これまでは開発メンバーが自分で考えてセキュリティを担保せざるを得ない状況でした。やっと相談先ができたことで、開発メンバーも安心感を得られたのではないかと思っています。

 

田中氏：
何も軸がない状態で始まりましたので、まずは社内にあるプロダクトとそこに存在するセキュリティリスクを把握することから始めました。具体的には、脆弱性診断やツールによるスキャンを定期的に実施し、リスク管理や運用を定義しました。これにより社内のリスクの棚卸しができ、戦略的に動けるようになりました。

長期的な視点では、指針を決めて戦略を立て、それに沿って効果を考えながら投資をしていくことを目指しています。短期的な視点では、スクラムの枠組みを採用し、基本的に私がプロダクト・オーナー、新沼さんがスクラムマスターとして動くようにしています。

具体的には、セキュリティに関する課題をバックログとして順番に対応したり、バックログリファインメントというイベントでバックログを整理してタスクを洗い出し、対応する。これを2週間に1回のスプリントで回しています。

 

プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャー 田中佑樹氏

 

新沼氏：
プロダクトの脆弱性情報の管理に課題を抱えていました。というのも、当時はJVNやJVN iPediaをRSSで購読しスプレッドシートに転記、週次で確認して対応可否を判断するという手作業の運用でした。

しかも、プロダクトセキュリティ部のメンバーの得意分野が人により異なっているので判断が属人化してしまうという課題もありました。使用しているソフトウェアやバージョンも把握できていなかったので、まずは重要な脆弱性情報に絞り、それを取り逃さないようにする運用となっていました。

 

新沼氏：
2021年の1月末に「オートトリアージ機能のある脆弱性管理ツールがある」という情報が社員から共有されました。それがyamoryだったのです。ちょうど課題を洗い出していた時期だったので、「これは良さそうだ」と思い、グループチャットで共有しました。

yamoryについてさらに調べた結果、解決したい課題とyamoryが持っている機能がマッチしていました。ただ、選定ポイントとして「運用に乗るかどうか」を懸念しており、それは田中さんも同じ認識でした。そこで、しっかりと運用していけそうか、トライアルをすることで詳細を確かめました。その結果、懸念が払拭できたため導入を決定しました。

 

田中氏：
yamoryは、脆弱性を自動的に網羅してくれて、重要なものを絞り込んでリストアップしてくれることが大きなメリットでした。特にオートトリアージ機能は、重要度を独自のアルゴリズムで得点をつけて可視化し、その根拠も確認できますからyamoryだけで一次トリアージが完結します。

また、社内ではJiraを利用していたので、Jiraと連携登録できる機能があることも決め手の一つになりました。既存の運用や業務プロセスとの親和性が高く、運用に乗るイメージがつきました。

新沼氏：
ダッシュボードが非常に見やすいことも決め手の一つになりましたね。優先度を色分けして表示してくれるので、一目でざっくりと状況を把握でき、今何をすべきかがわかります。

また、今後のロードマップで、OSレベルやコンテナイメージなどもトータルで見ることができるようになること、競合のサービスと比較して現実的な金額だったことも決め手になりました。

実際に導入した効果としては、脆弱性情報を手動で収集して重要度を判断していた業務が自動化され、属人化の問題を解消できました。次に、色と数値で重要度を可視化してくれるのでトリアージが非常に便利になりました。以前に挙がっていた課題は、yamoryで解決できたと考えています。

今後はもっと社内に働きかけてyamoryのプレゼンスを上げていき、全てのプロジェクトにyamoryを導入するなど、各チームの活用度を上げて完全に定着するような運用にしていきたいですね。

加えて、プロダクトセキュリティ部では、週に1回の運用の中で挙がったyamoryに関する要望をまとめて、御社にフィードバックとして送っています。それをちゃんと機能開発して、反映していただいていることは非常に嬉しく思っています。

 

新沼氏：
はい、Log4jの脆弱性（Log4Shell）対策でもyamoryを活用させていただきました。Log4jはさまざまなソフトウェアに内在していて間接依存も多く検知が困難です。しかし、yamoryでは間接依存の脆弱性も検知でき、横断検索機能で脆弱性のあるLog4jの存在の有無を確認することができます。yamoryで網羅的にこの脆弱性の存在有無を確認でき、非常に助かりました。
※ yamoryを利用したLog4Shellの対策はこちらをご参考ください。

 

左：プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャー 田中佑樹氏
右：プロダクトセキュリティ部 新沼孝之氏

 

田中氏：
実際の運用は、CIに組み込むかどうかといった細かい設定方法を含めて、現場に任せています。GitHubリポジトリスキャンで定期チェックを行っているチームが多い印象です。Scalaの一部、AndroidはコマンドラインスキャンをCIに組み込んでやっています。

各チームごとにアカウントが発行されており、プロダクトセキュリティ部のメンバーは全員、全チームの脆弱性を確認できるようにしています。また、プロダクトセキュリティ部の定常業務として週に1回yamoryが検知した脆弱性の棚卸しを実施しており、緊急度に応じてJiraでチケット管理しながらチームへ脆弱性対応の依頼をしています。

Chatworkではバグバウンティも運用しており、その報告のトリアージや、海外からの攻撃のログを調査しIPブロックなどの対策も一緒にしています。いずれはチームごとにセキュリティ担当者をつけて、横串で状況を見て全体最適のセキュリティ施策を講じていくようにしたいですね。

このほかにも、主要なプロダクトに関しては年に1回大規模な脆弱性診断を実施しています。また、コーポレート側の主導でリスクアセスメントも年に1回実施しており、これにはプロダクト側のメンバーも参加して、そこで出てきたプロダクトに関するセキュリティリスクは、私たちのチームで順次対応していく運用となっています。

 

田中氏：
これまでにいいツールだと思って導入しても、利用が広がらないケースを何回も経験してきました。そのため、ツールを導入する際には導入後の運用ルールをしっかりと定義し、説明会や勉強会を開催して現場の理解を得るようにしています。

yamoryの導入の際にも、どのような機能があってどのような効果を見込めるか、何を目指したいのか、また運用フローについても説明しました。なるべく現場に負担がかからない形の運用フローを事前にプロダクトセキュリティ部側で設計し、それらを勉強会という形で共有できたことも、受け入れられやすかった要因の一つと考えています。

そのため、yamoryに関してはすんなりと理解してもらえて、反発もありませんでした。これは、現場でも脆弱性対策の重要性を感じていたためだと思います。導入後もネガティブな意見はありません。

 

左：プロダクト本部 副本部長 兼 プロダクトセキュリティ部マネージャー 田中佑樹氏
右：プロダクトセキュリティ部 新沼孝之氏

 

新沼氏：
ライブラリレベルではyamoryで対応できていますが、プロダクションで使用しているミドルウェアでスキャンが難しいものに関して、バージョン管理、脆弱性の有無、OSレベルでの脆弱性検査は、まだJVNなどの情報をもとにアクションを決めている状態です。ここの分野でもyamoryのようなツールを使って脆弱性を管理できることが理想と考えています。yamoryのダッシュボード上で全て完結できるようになると嬉しいですね。

田中氏：
Chatworkはk8s（Kubernetes）を使ってアプリケーションサービスを運用していますので、コンテナ技術も広く浸透しています。一方で、コンテナ周りのセキュリティは世の中でもあまり出ていない領域だと感じています。yamoryには、ぜひコンテナスキャンなどのコンテナに関する機能を追加していただきたいと期待しています。またLinux以外では、ChatworkはAWS上のElastic Redisなどを使っていますので、その辺りも集約して管理できるようになるといいですね。

 

田中氏：
セキュリティと運用はセットだと考えています。yamoryを使って「どのようにセキュリティを向上させたいのか」ということと、「どういう組織にしたいのか」ということはセットです。企業はそこも意識しながら、セキュリティと付き合っていくのがいいと考えています。

僕たちも悩みながらチームを作って、yamoryを導入して、やっとしっかりした脆弱性対策ができるようになりました。そこで感じたのは、「やるぞ」という気概がないと難しいということです。脆弱性対策をやらないという選択肢はないと思いますので、一定の工数は割くという認識は必要だと思います。それぞれの企業に合ったやり方があるはずだと思うので、まずそれを考える人が必要です。会社、部署としてセキュリティ専任の人を立てることがスタートだと思います。

新沼氏：
多分、私が今回yamoryを「いいな」と感じたことが導入につながる大きなモチベーションになったと思います。これを使えば課題を解決できるのではないか、明るい未来がありそうだと直感的に感じました。そのモチベーションが運用を設計して社内に展開することにつながりました。魅力を感じたサービスに共感をする人を少しずつ増やして、巻き込んでいく。それをいかにうまくできるかが、浸透させるポイントだと思います。