Sansan Builders Box

Sansanのものづくりを支える技術やデザイン、プロダクトマネジメントの情報を発信

新卒セキュリティエンジニアがインシデントに対応し、現場の開発エンジニアから意見をもらった話

 

Sansan株式会社で新卒セキュリティエンジニアになりました大井です、現在CSIRTに配属されています。

今回は、オープンソースライブラリに悪意のあるコードが混入されるインシデントに、新卒セキュリティエンジニアがいかにして対応を行い何を学んだのかを記したいと思います。

 

インシデント対応を行って得た学び

私がこのインシデントに対応し得た学びとしては以下の2つが挙げられます。

  1. 開発部門に対しインシデント連絡を行う場合は、可能な限り詳しい情報を渡す必要がある
    ・具体的には危険性、発生条件、バージョンなどを伝達すること

  2. 対策は多段的に行う
    ・初動対応と根源対応を適切に使い分けること

 

 

対応の流れ

対応の流れを図にすると以下のようになります。

f:id:CuWj6sqo:20181219152352p:plain

 <不審なファイルを検知>

インシデントの判明は、ウイルス対策ソフトによる検知からでした。

<調査>

アラートを確認したところ、あるエンジニアのPC上のファイルが原因であることが判明しました。
そこでヒアリングを実施するとともに、コードのレビュー及び公開情報の調査(OSINT)を実施しました。私が調査した結果は以下のようになりました。

 
・今回検知したライブラリは開発対象のシステムを構成するファイルの中から見つかった
・このライブラリは古くから利用されていた
・ライブラリのパス名を調べたところ悪意のあるコードが仕込まれたとの情報が見つかった
・ウイルス対策ソフトが検知したコードを私が調査したところ難読化されていた

 
上記の調査結果から私がライブラリの使用禁止と社内調査を考え、CSIRTの先輩社員にも確認をお願いし、アドバイスを頂きました。

アドバイスの内容は「当該ライブラリの使用の有無を調べ、依存しているのであれば別ライブラリへの移行をお願いする」というものでした。自分は対応をその様に変更しました。
 

<プロダクト調査>

CSIRT内での方針を決めた後、各部のセキュリティ担当者に連絡しライブラリの使用状況の調査を行ったところ、ライブラリの利用があることがわかりました。


<削除依頼>

そこで別ライブラリへの移行とライブラリの削除をお願いしたところ、開発部のエンジニアから「最終的な削除は構わないが、利用状況によってはすぐに対応できないため、悪意のあるコードの埋め込まれたバージョンを確認し、バーションを戻して一時的な対策をして、早急に安全を確保するべき」との指摘をもらいました。 

指摘を受けて、不正なライブラリのバージョンに着目し社内のプロダクトにおけるライブラリ使用状況を確認したところ、Sansanプロダクトにおいては不正なコードが埋め込まれたバージョンのライブラリは使用していないことが分かりました。

したがって、プロダクトには不正なコードは混入されていないため、悪用された実績もなく、問題がなかったことも確認できました。

 
<削除計画 or 実施・代替手段連絡>

不正なコードが埋め込まれたバージョンは使用していませんでしたが、当該ライブラリ全体を社内ツールから使用終了とし、別ライブラリへの移行を実施しました。近日中に削除が完了する予定です。

  

終わりに

初めてのプロダクトに関わるインシデント対応となり、自分にとって様々な学びになりました。具体的にはプロダクト開発部との連絡など、「誰が担当でどの様に調査し対応するのか」などを学ぶことが出来ました。

また、バージョン番号や危険性などの情報伝達の重要性や、初動対応と根源対応の取り方なども今回のインシデント対応で学びました。今回の事例を踏まえて、自分から多段的提案や不足のない情報の提供をしていきます。

© Sansan, Inc.