page icon

情報セキュリティ部


応募要項はこちら

セキュリティーエンジニア

セキュリティー推進担当


Pick Up コンテンツ

CSIRTとして挑戦しがいのある「セキュリティと利便性の両立」とは

CSIRTグループ 佐藤 健太
https://jp.corp-sansan.com/mimi/2022/07/interview-46.html
https://jp.corp-sansan.com/mimi/2022/07/interview-46.html
Sansan株式会社の情報セキュリティ部のCSIRTグループで働く佐藤健太にインタビューを行いました。ベンダーから転職の決め手になったのは、Sansan株式会社がSansanのカタチの中でPremiseとして掲げている「セキュリティと利便性の両立」への挑戦。日々、そこにどのように向き合い、取り組んでいるのかを聞きました。 続きを読む
 

「この領域ならば、あの人」と言われるような、明確な強みを持つエンジニアになりたい

CSIRTグループ 吉山 遼太
https://jp.corp-sansan.com/engineering/products-and-technologies/csirt/?interview=01
https://jp.corp-sansan.com/engineering/products-and-technologies/csirt/?interview=01
ソフトウェア開発においては、機能を増やして利便性を高める“攻め”の技術だけではなく、セキュリティを堅牢にしてサービスと会社の信頼性を高める“守り”の技術も重要です。Sansan株式会社において、セキュリティ対策を担う組織が「CSIRT」。このチームは顧客の個人情報の安全性担保を重視するだけではなく、生産性や業務効率を下げないセキュリティ対策を目指しています。CSIRTの吉山遼太に話を聞きました。 続きを読む
 

 
 

グループ概要

CSIRTのメンバーたちは、堅牢にするだけのセキュリティ対策には意味がないと考えています。

Sansan株式会社の企業理念である「Sansanのカタチ」には、Premiseとして「セキュリティと利便性を両立させる」という言葉が記されています。このフレーズが示すように、私たちは創業以来、個人情報などの大切なデータを守る方法を考え続けてきました。
そんなSansanのマインドを体現するチームがCSIRT。「Computer Security Incident Response Team」の略称であるこの組織は、社内のありとあらゆるセキュリティ課題への対応を担っています。
もっと見る
また、Sansanはセキュリティタスクフォースという、各プロダクトの開発部門や社内システムの管理部門のエンジニアが所属する仮想的な組織を設けています。CSIRTとセキュリティタスクフォースとCISO(Chief Information Security Officer:最高情報セキュリティ責任者)とが連携して情報を共有しながら、Sansanのセキュリティについて各種の取り組みを続けています。
CSIRTのメンバーたちは、堅牢にするだけのセキュリティ対策には意味がないと考えています。Sansanでは大勢の社員が働いているため、いくら堅牢でも、彼らの業務に制約が生じるようなセキュリティ対策では、企業全体の生産性は向上しません。各種の脅威からシステムやデータを守りつつも、社員たちは自由度高く業務に取り組める。私たちCSIRTは、そんな状態を目指しています。
CSIRTには「テクノロジーだけではすべての事象を検知・対応しきれない。だからこそ、人間の判断力や思考力、察知力が必要になる」という考え方があります。だからメンバー一人ひとりが、社内のステークホルダーと適切にコミュニケーションをとり、必要な情報を拾い上げる。そして、発生している事象から“本質的な課題”を見抜き、実行すべき施策を決定します。
CSIRTのメンバーに求められるスキルは多岐にわたります。セキュリティの理解だけではなく、コミュニケーションスキルやアプリケーション仕様を理解するスキル、プロジェクトの推進・調整能力、そして分析力や決断力。例えるなら、エンジニアリングの総合格闘技のような仕事なのです。
Sansanのお客さまや取引先の方々、そして全社員が安心してシステムを利用できるように。私たちは、そのための土台作りを日々続けています。
 
 

CSIRT技術スタック

CategoryTechnology Stack
Programming Language / Library etc.Python, Ruby, JavaScript
Endpoint ProtectionCrowdStrike, Proofpoint
Authentication ProtocolsCAT, TestRail
Vulnerability AssessmentBurpSuite, OWASPZAP, Vaddy, FutureVuls
OSINT etcTwitter, Shodan, Censys, ThreatCrowd, SecurityTrails, Pentest-Tools, RiskIQ
Basic AnalysisNmap, Wireshark, ANY.RUN, HybridAnalysis, VirusTotal
Log AnalysisOpenSearch, Elasticsearch, Beats, Fluentd, rsyslog
InfrastructureAWS, GCP, Azure
MonitoringGrafana, Zabbix, CloudWatch
CIAWS CodePipeline
Code ManagementGitHub

「CSIRT」エンジニアに関する記事

Amazon Elasticsearch Service を用いた SIEM の構築事例 - Sansan Builders Blog
Sansan-CSIRTの松田です。Sansan に join してから早1年半が経過しました。 先日 AWS Security Roadshow Japan 2020 に「Sansanの成長を支えるセキュリティログの活用と Amazon Elasticsearch Service」をテーマに発表させて頂きました。 こんなに大きなイベントでの登壇は人生初です。しかもAWSです。それはもう緊張しました。開催報告は こちら に記載されていますので、興味のある方はウォッチしてみてください。 また、今回 CSIRT が開発に参画した SIEM on Amazon ES に関するリリースは以下に掲載されています。 時間の関係上、基本的なトピックしかお話できませんでしたので、本ブログではもう少し詳細に書きます。 発表内容でも触れましたが、一般的にSIEM(Security Information and Event Management)の機能としては以下の3つです。 SIEM に最も重点を置くことは、複数のログを管理し長期的に相関分析できる状態とすることです。 なぜなら Sansan は個人情報を扱う会社です。何も起きないように日々高いレベルで対策を実施し、運用しています。 しかしながら、組織を標的とした攻撃というものは用意周到に準備されるものであり、最終的には"いつもと違う"という違和感に気付くことで発見を早めることができます。 その点、違和感という物は簡単にロジックへ落とし込めない物が多く、まだまだ攻撃者が有利な状況が続いていることも理解しています。 だからと言って何もしないと言う訳にはいきません。 違和感に気付く、即ち「インシデントを発見して管理すること」を最終的な目的とするならば、その前提に必要となるログを管理しいつでも検索できる状態を目指すことになります。 ログを管理して、検索できる状態にするという行為は一見簡単そうに見えますが正直辛いです。地味な割には、手間がかかり、いざという時に無いと困るものです。 この当たり前のことをしっかりと実現するために今回 Amazon Elasticsearch Service (以下、Amazon ES)を選択したことは非常に良い決断だったと思っています。 以前は Splunk という製品を利用していましたが、維持運用にかかるコストが増加しつつありました。
全社統合ログ基盤を構築して得た知見 - Sansan Builders Blog
こんにちは。CSIRT の吉山です。 私は2020年の4月にセキュリティエンジニアとして新卒入社し、現在は主にログ基盤(SIEM)の構築・運用やインシデント対応などの業務に取り組んでいます。 今回はそのログ基盤構築や運用、その他検証で得た知見などについて紹介します。 まず初めにログ基盤の技術的な概要についてここで簡単に触れておきます。 ちなみに基盤構築の背景などについては、以前に同じく CSIRTの松田が記事にしているのでこちらもぜひ一読いただければと思います! buildersbox.corp-sansan.com 基盤は AWS 上で構築しており、Amazon OpenSearch Service (以下、OpenSearch。旧 AWS Elasticsearch Service) をメインに構築しています。 基盤全体を見ると構成としては以下のような状態です。 ログの流れとしては S3 へのログの収集 S3 へのオブジェクト配置(PUT イベント)で ETL 用 Lambda (es-loader) をキック es-loader から OpenSearch へログをポスト という具合になっています。 ログ基盤へ取り込みたいログはすべて S3 へ保存しています。S3 から OpenSearch までは es-loader が一括して行っているため、S3 に保存さえすれば勝手にログがインデックスされます。 構成でも触れたとおり、ログ基盤へ取り込むログはすべて1度 S3 を経由します。 S3 を選んだ理由としては主に以下の3点があります。 コスト

当社エンジニアに関する記事

 

Sansan株式会社について

 

Sansan Tech Podcast

当社のエンジニアがお届けするPodcastです。Sansanエンジニアの技術のこと、カルチャーのこと、日々のSansanライフについて自由に語っています。