この記事はアドベントカレンダー実践セキュリティ監視基盤構築の13日目です。今回は、ログ収集によって取得したログをCloud Storageにどのように保存するかについて説明します。ログの保存にはいくつかのポイントがあります。ログの保存先のバケット名やオブジェクト名の設計、ログの保存形式、ログの保存期間などを考慮する必要があります。今回のアーキテクチャでは、Cloud Storageは「ログの収集」と「ログの変換・取込」をつなぐストレージとして利用することが主な目的です。すぐにログをデータウェアハウスであるBigQueryに投入するため、Cloud Storageは一時的なストレージと...

実践セキュリティ監視基盤構築(13): ログ保全の実装要点

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の12日目です。今回は、セキュリティ監視基盤で使用するログの取得方法について説明します。ログの取得方法は大きく分けて、Push型とPull型の2つがあります。Push型はログの発生元からログを送信してもらう方法で、Pull型はログを取得する側からログを取得する方法です。 Pull型のログ取得多くの外部サービスはAPIを提供しており、そのAPIを使ってログを取得できます。セキュリティ監視基盤側から能動的にログを取得する方法をPull型と呼びます。今回はPull型のログ取得を実装する際の留意点や実装方法について説明します。...

実践セキュリティ監視基盤構築(12): ログ収集の実装要点

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の11日目です。本日は、これまでの設計の議論に基づき、Google Cloud上でどのようにセキュリティ監視基盤を構築するかを説明します。 アーキテクチャの全体像アーキテクチャの設計では、ログ収集、ログ変換・取込、アラート検知、アラート対応の4つのプロセスが必要です。これらを統合してセキュリティ監視基盤を構築します。今回は外部サービスからログを取得する前提で構築していますが、組織内のアプリケーションのログも同時に取得したい場合は、適宜拡張可能です。基本的には、ログ収集とログ変換・取込の中間にあるデータレイクのCloud ...

実践セキュリティ監視基盤構築(11): セキュリティ監視基盤のアーキテクチャ（実装）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の10日目です。ここまでの説明で、自動的なアラートはルールに基づいて検知されることを説明しました。では、実際にどのようなルールを設計すればよいのでしょうか？ 既存のセキュリティ監視システムに触れたことがある人には馴染みがあるかもしれませんが、経験がない場合は想像しにくいかもしれません。今回は、アラート検知のためのルール設計について詳しく説明します。 アラート検知の考え方セキュリティ監視におけるアラートの検知の考え方は、大きく分けて3つのパターンがあります。基本的にルールとして定義されるのは以下のいずれかのパターンに属します...

実践セキュリティ監視基盤構築(10): アラート検知のためのルール設計

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の9日目です。先日に引き続き、セキュリティ監視基盤に取り込むデータの中から、「アラート」について詳しく説明します。今回は特に、セキュリティ監視基盤内で検知するものではなく、外部から取り込まれるアラートに焦点を当てます。 セキュリティ監視基盤における外部アラートの取り扱いこのアドベントカレンダーでの「アラート」とは、セキュリティ上の問題を引き起こす可能性がある事象を指します。セキュリティ監視基盤では、ログを分析したりルールを適用したりしてアラートを生成します。調査の結果、実際の影響があると判断された場合、それをセキュリティイ...

実践セキュリティ監視基盤構築(9): セキュリティ監視基盤で利用するデータ（アラート編）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の8日目です。今回はセキュリティ監視基盤に取り込むデータのうち、ログについて整理します。ログはセキュリティ監視基盤において重要なデータであり、セキュリティインシデントの検知や調査に利用されます。 ログとはログという単語はかなり広い概念として使われますが、ここでは主に以下のようなデータをログとして扱います。システム内で発生したイベントについて記録したデータシステムのある時点での状態を記録したデータ1は広義でイメージされるログに近いものであると考えられます。アプリややケーションログ、OSログ、ネットワーク機器のログ、...

実践セキュリティ監視基盤構築(8): セキュリティ監視基盤で利用するデータ（ログ編）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の7日目です。本日からセキュリティ監視基盤の設計についてお話しします。今回は、このアドベントカレンダーで取り扱う全体のアーキテクチャについて解説します。具体的なコンポーネントやサービスの選定・構成の前に、どの要素がどのような役割を担い、どのように組み合わさるのが望ましいかを整理します。 セキュリティ監視基盤のアーキテクチャ上の図はアーキテクチャの全体像を示しています。このアーキテクチャで注目すべきポイントは、ログとアラートのパイプラインです。ログを収集し、変換・取り込みを行い、分析可能な状態にしてからアラートを検知し対応...

実践セキュリティ監視基盤構築(7): セキュリティ監視基盤のアーキテクチャ

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の6日目です。今回は、セキュリティ監視の要件定義において重要な非機能要件について考えてみます。 非機能要件に対する考え方セキュリティ監視基盤もシステムの一部であり、設計を考える際には非機能要件が必要です。ただし、セキュリティ監視基盤の特徴として、外部システムと多数連携し、ログやアラートを取り込む特性があります。そのため、非機能要件を定めても、それが実際に適用できるかは連携先のシステムやログの出力能力に依存します。したがって、非機能要件はあくまで目安とし、選択肢がある場合に非機能要件を優先するという考え方が必要です。また、...

実践セキュリティ監視基盤構築(6): セキュリティ監視の要件定義（非機能）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の5日目です。今回は、セキュリティ監視基盤の設計・構築を行う前に、自組織にとってどのようなセキュリティ監視が必要かを明確にするための要件について考えます。セキュリティ監視の要件定義は、一般的な要件定義と同様に、機能要件と非機能要件に分けて考えることができます。今回は機能要件について整理します。 現状分析まず最初に行うべきは、自組織の状況を把握することです。データやシステム、脅威に関する情報を整理し、どこをどのように守りたいかによって、監視すべき対象や方法が変わってきます。このような分析は、セキュリティ監視の設計の道筋を立て...

実践セキュリティ監視基盤構築(5): セキュリティ監視の要件定義（機能）

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の4日目です。このアドベントカレンダーではセキュリティ監視基盤を内製することを前提としていますが、セキュリティ監視基盤を内製するべきかどうかは、組織や事業規模、技術スタック、人材のスキルセットなどによって異なります。この記事では、セキュリティ監視基盤を内製するべきかどうかについて考察します。 既製と内製の比較前回の記事で既製と内製のコスト比較について説明しましたが、今回は全体的な比較を以下の表で整理しました。やや大雑把な比較ですが、既製と内製の違いを理解するための参考にしてください。既製プロダクト・サービス内製...

実践セキュリティ監視基盤構築(4): セキュリティ監視は内製するべきか

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の3日目です。セキュリティ監視は情報セキュリティ対策の重要な要素ですが、導入のタイミングは組織や事業規模によって異なります。今回は、セキュリティ監視基盤をいつから始めるべきかについて考察します。 組織の脅威・リスク分析を行うセキュリティ監視は数ある情報セキュリティ対策の一つに過ぎません。どのような情報セキュリティ対策を講じるかは、組織の情報資産や守るべきデータを把握し、脅威やリスクを理解した上で、どのように対処するか（あるいは対処しないか）を考えることから始まります。本文書では脅威・リスク分析について詳しくは触れませんが...

実践セキュリティ監視基盤構築(3): セキュリティ監視基盤をいつから始めるか

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の2日目です。基盤の構築の話をする前に、まずそもそも「セキュリティ監視」とは何か、そして「セキュリティ監視基盤」とは何かについて整理をしたいと思います。 セキュリティ監視とは本稿では、セキュリティ監視を 「組織内で発生するセキュリティ上の問題を、継続的に検知・調査すること」 と定義します。 セキュリティ上の問題セキュリティ上の問題とは、脆弱性や攻撃活動の兆候、インシデントなどを指します。脆弱性は、システムやアプリケーションに存在するセキュリティ上の不備や欠陥であり、悪用されるとインシデントが発生する可能性があります...

実践セキュリティ監視基盤構築(2): セキュリティ監視およびセキュリティ監視基盤とは

この記事はアドベントカレンダー実践セキュリティ監視基盤構築の1日目です。 はじめに2000年頃にインターネットが普及し始めてから今日に至るまで、情報セキュリティに関する課題は大きくは変化していません。情報システムやネットワーク、アプリケーションの環境や構成要素、攻撃手法は変化しているものの、基本的な脅威や対策の方針は一貫しています。情報セキュリティ担当者は、継続的に発生する脅威に対して、適切な対策を講じる必要があります。情報セキュリティの対策は、さまざまな要素を組み合わせて構築されます。その中でも、セキュリティ監視は重要な要素の一つです。セキュリティ監視は、情報システムやネットワ...

実践セキュリティ監視基盤構築(1): はじめに

背景Ubieでは以下の記事にあるように、一昨年から新しく始めるプロジェクトにはGoとTypeScriptを積極的に採用しています。私は本来プロダクトセキュリティが主な専門領域なのですが、公私ともに普段からGoでツールやサービスの開発をしているため、社内のGo言語の普及をサポートしたりプロダクト開発に参加したりしています。https://zenn.dev/ubie_dev/articles/4437cde02a672bGo言語で開発したことがある方はご存知かと思いますが、Goは標準パッケージで提供されているエラーハンドリングは最低限の機能しか提供されていません。これは、CLIツー...

UbieにおけるGo言語のエラーハンドリング

年末年始に長い休みを取得できたので、2024年に会社で取り組もうとしている Detection Engineering の取り組みを自宅で素振りしてみました。短い期間だったのでツール自体やドキュメントの整備など至らぬ点はいろいろありますが、ひとまずこの記事ではその内容についてご紹介します。 モチベーション今年取り組もうとしているDetection Engineeringを小さく試してみたかったという他にも、以下のようなモチベーションがありました。 1. 多数のデバイスがつながる自宅ネットワーク内の監視をしたいその昔、自宅のネットワークに接続しているものといえばたかだかパソコン...

Detection Engineering at 自宅

前回の投稿が 2022年 → 2023年 だったので、だんだん一年の総評をまとめる生存報告ブログになってきています。ちょっと早いですが今年はすでに仕事納めもしており、2023年を締めていきたいと思います。2023年振り返り💼 仕事引き続き Ubie でエンジニアをやらせてもらっています。バックエンドプロダクト開発多し仕事内容としては2022年に引き続き、バックエンドのプロダクト開発が多かった年になりました。社内のリスク低減に関連した取り組みではあったのですが、直接的に情報セキュリティに関係があったかというとあんまりなかったです。とはいえ企業におけるリスクというのは情報セキュリティだけに限ったものではありませんし、多角的な経験ができたとも言えます。また、自分のチームで開発するだけでなく、ほかチームを巻き込む形でプロダクト開発するということもありました。今まで開発といえばほとんど個人技だった自分からすると、この2年間はかなり多くのことを得られたと思っています。実際には何事も「言うは易く行うは難し」でいろいろ苦労も多かったのですが、なかなか良い経験になりました。とはいえそろそろセキュリティに直接関連するところに戻りたいなと考えており、来年はそちらの方面を全力投球する予定になっています。組織の変化・進化Ubieで働き始めてから2年半弱経ったのですが、思い返してみると物凄い勢いで組織が変化してきたのを感じます。入社当時はまだ事業の探索フェーズだったと言ってよく、様々な可能性を模索したり、ときに筋肉運用で物事を解決したりというのも珍しくありませんでした。セキュリティ観点でも最低限の部分を抑えつつ、その他の部分は流動的に対応するというような状況も多くありました。しかしこの2年半の間で会社として様々な出来事や挑戦があり、その度に組織全体、そして社のメンバーも目覚ましくアップデートしてきていると感じています。特に事業の蓋然性が高くなってきたことにより、会社全体として開発生産性や信頼性をかなり重要視するようになり、それがメンバーにも浸透していったように思います。こういったスタートアップのフェーズの移り変わりというのを経験するのが初めてなので、一般的にこの変化の良し悪し判断が難しいですが、個人的にはわりと凄いことなのではないかなと考えてます。🌴 趣味OSS相変わらず休日はコード書きを趣味にして生きています。2023年のヒット作（当社比）はGoの公式構造化ロガーとして登場した log/slog 利用時に秘匿値をログに出力しないようにする masq かなと思います。github.comuser := struct {    ID    string    Email EmailAddr // ここでは独自の型を使う例（実態はstring型）}{    ID:    "u123",    Email: "mizutani@hey.com",}// slogのlogger作成時に、ReplaceAttrに指定logger := slog.New(slog.HandlerOptions{    ReplaceAttr: masq.New(masq.WithType[EmailAddr]()),}.NewJSONHandler(os.Stdout))// で出力するlogger.Info("hello", slog.Any("user", user))こんな感じでメールアドレスの型を指定すると、{  "time": "2022-12-25T09:00:00.123456789",  "level": "INFO",  "msg": "hello",  "user": {    "ID": "u123",    "Email": "[REDACTED]"  }}こんな感じにメールアドレスの値の部分をフィルタしてくれます。秘匿値がうっかり本番環境のログにでていたときに面倒臭さは何度も体験しているので、（自分で言うのもなんですが）もはや手放せないツールになっています。あとは軽量SOAR（Security Orchestration, Automation and Response）ツールである AlertChain の開発もかなり力を入れてやってきました。github.com平たく言うと、いろんな種類のセキュリティアラートをHTTP APIで受け取って、アラートの整形や各種サービスへの連携（情報収集や通知など）を Rego で記述したポリシーをもとに処理してくれるツールです。ポリシーをテキスト形式で記述できるのでGitなどで管理しやすいこと、そしてアラート処理のワークフローを回帰テストできるようになっているのが推しポイントで、個人的には気に入っています。こちらはすでに社内に展開し利用もしているのですが、まだいろいろ拡張をしたいのと、ユーザ層がかなりニッチだろうと予想しているため、あまり積極的に広報はしていません（何かの発表ではちょろっと話した気がするけど）。もし詳細を知りたいという奇特な方が世の中に1人でもいたら、解説記事の執筆などを前向きに検討したいと思いますので、ぜひご一報ください。ゲームいままでずっとFGOをわりとやっていたんですが、今は完全に原神にドはまりしてます。戦闘システムやキャラの性質を考えた編成の組み方が幅広く、戦略的にいろんな編成で遊べるのが楽しいですね。戦闘の難易度もほどほどの難しさではありつつも奥が深く、エンドコンテンツである深境螺旋をよく遊んでいます。最近実装されたキャラのナヴィア、無凸でなかなかぶっ壊れていて良いですね昨年に引き続き、サイクリングマシンで運動しながら素材収集するというのをほぼ毎日やっており、ゲームをするほど健康になっていてお得です。2024年どうするか仕事ちょっと前にアドベントカレンダーでも書いた Detection Engineering 、そしてそれにともなった Policy as Code の実践と浸透をやっていきたいというのが大きな目標です。長い目で見るとこのトピックは学生時代から追っていた自分にとって生涯のテーマみたいなところがあります。時代の流れとともにやるべきことや技術的な背景は大きく変わってきましたが、それでも根っこの部分である「セキュリティの分野でエンジニアリングをやっていく」というのは共通していると思います。今回は自力で頑張るだけでなく、社内のメンバーの知見なども借りながら基盤を構築していくことになりそうです。クラウド環境の機能を使い倒していくだけでなく、LLMのような技術の活用も視野にいれています。これについてはまだ構想の段階なのですが、うまく成果がでたらまた後日なんらかの形で公開したいと考えています。プライベートやや仕事と関連してはいるのですが、最近英語（特にListeningとSpeaking）を使う機会がわりと増えており、それにともなって英語学習のモチベーションがかなり上がっています。物凄い高いかと言われるとそこまでではないのですが、これまで自らの意志として英語勉強したいと思ったことなど正直一度たりともなかったので、それに比べると自分史上最高の学習モチベーションと言えます。具体的にはListeningの精度を上げること、そして仕事などでの会話で言いたいことがスルッと言えるようになる、というあたりを目指してやっていこうと思っています。ということで皆様良いお年をお過ごしください。来年も各位どうぞよろしくおねがいします。

2023年 → 2024年

この記事はUbie Engineering Advent Calendar 2023の2日目の投稿になります。UbieではこれからDetection Engineeringに対して取り組もうとしており、どのような課題があってどのように進めようとしているのか、についてご紹介したいと思います。 背景：セキュリティ監視の課題サイバー攻撃の対策の一つにサイバー攻撃の検知や検知後調査のためのログ収集をする「セキュリティ監視」があります。セキュリティ監視は未然にインシデントを防ぐのはやや困難ですが、早期検知によるインシデントが発生した場合の被害の極小化、そして調査によって影響範囲の特定ができま...

Starting Detection Engineering in Ubie

Go言語ではながらく公式のログ出力にlogパッケージが使われてきました。しかし昨今のクラウド環境などでのロギングでは構造化ログがほぼ必須であり、そのような流れを受けて公式の構造化ログパッケージ slog が提案されています。2023年8月にリリース見込みの Go 1.21 のリリースノートにはすでに掲載されており、1.21 で公式に取り込まれるのはほぼ確実かと考えられます。https://zenn.dev/mizutani/articles/golang-exp-slog 背景：絶対にログに秘匿値を出力したくないオンラインサービスで出力されるログは様々な目的で利用されます。例えば...

Go公式の構造化ロガー（予定）のslogで秘匿値をログから削除する

Go言語ではながらく公式のログ出力にlogパッケージが使われてきました。しかし昨今のクラウド環境などでのロギングでは構造化ログがほぼ必須であり、そのような流れを受けて公式の構造化ログパッケージ slog が提案されています。https://zenn.dev/mizutani/articles/golang-exp-slogこの記事執筆時点で slog は正式に公式に取り込まれたわけではないですが、 1.21 のマイルストーンにはリストされており、それなりの確度で導入されると思われます。これを受けて自分が開発しているプロダクトでも徐々に slog の導入を進めています。構造化ロギング...

Go公式の構造化ロガー（予定）のslogの出力を見やすくしてみる

TL; DRGoのGenericsを活用したテストユーティリティを試験的に作ってみました。https://github.com/m-mizutani/gtこんな感じにテストを記述できます。colors := ["red", "blue"]// NG: colors が配列なのに、文字型と比較しようとしてコンパイルエラーになる// gt.Array(t, colors).Equal("red")// NG: 配列同士だが、colorsは []string なのに対して []int を比較しようとしているのでコンパイルエラーになる// gt.Array(t, col...

Genericsを利用したGoのテストユーティリティ

ちょっと気が早いですが、そろそろ2022年も終わりということで今年の出来事を振り返りつつ、2023年への気持ちをしたためてみます。2022年💼 仕事引き続き Ubie でエンジニア業をやらせてもらってます。プロダクト（主にバックエンド）開発をするようになった実は最近はプロダクトセキュリティに関する仕事は必要最低限になっており、プロダクトのバックエンド開発が業務の8割以上を占めるようになりました。取り組んでいる内容についてはいずれ詳しくブログなどで紹介したいと思いますが、実際にユーザに触れてもらう部分を開発するというのは個人的に大きな転機でした。特にプロダクトに関するセキュリティをやる上では「プロダクト開発した経験」が活きる場面がいろいろとあり、良い経験をさせてもらっています。一方でプロダクトセキュリティの取り組みは全体的に今年は希薄になっていて、自分のキャリア的にこれでいいんだっけ？というのはちょっとあります。しかし普通に今の取り組みが楽しすぎるのでまあいいかという気持ちと、あとはセキュリティとプロダクト開発が両方ちょっとできる人という立ち位置も悪くないかなぁという考えでやっていってます。チームによる取り組みが多くなった上記のプロダクト開発にともない、「仕事で1つのプロダクトを複数人で継続的に開発する」というのをやっているのですが、これは実は自分にとって初の経験です。知識として複数人での開発におけるお作法などはある程度知っていたつもりですが、やはり実際にやってみると気づきが多いです。また、明らかに自分一人では難しいスループットが出せるようになり、チームの力というのを実感しています。やはり一人の筋肉でできることには限界がある。さらに社内のいろんなチームと密にコミュニケーションをとることも多くなりました。こういったムーブはもともとあんまり得意な方ではなかったんですが、今の職場は風通しの良さや透明性、カルチャーの浸透がされており、圧倒的に仕事しやすいと感じています。🌴 趣味OSS今年も休みの日は主にコードを書いて過ごしていたのでいろいろなソフトウェアを作ってきたが、代表作は以下の2つと言って良さそうです。どちらも自分自身で日常的に使っています。やはり自分が欲しい・使いたいと思ったものを実装するのが一番コスパが良いですね。zenn.devzenn.devゲーム今まではずっとFGOメインだったんですが、すべての所有キャラをレベルMaxまで育成しつつ、推しサーヴァントを完全体にできたのでややモチベーションが下がり気味でした。しかし待望のメインシナリオである第2部7章が先日開放されて、「FGO最高！FGO最高！」となってます（手のひらクルックル）（ほぼ）完全体メリュジーヌ Lv120、金フォウMax、獣刻印全カードMax。残念ながら宝具だけ4だが、適当な周回ならクラス相性を無視してメリュジーヌ一人ですべてを粉砕する一方で春頃に触ってみた原神にかなりハマってます。サービススタート当初は「ゼルダBotWの模造品」のように揶揄されており、自分もプレイしてみた最初の感触はその通りと感じましたが進めてみると全然違いました。平日は終業後にサイクリングマシンで運動しながらデイリークエストや素材集めをしており、ゲームするほどに健康になって便利。原神の方はまだまだキャラ育成とかの余地があるので当分は楽しくプレイできそうです。サイクリングマシンを漕ぎながらどうプレイするかいろいろ試した結果、ディスプレイをアームで伸ばしてPCをゲームパッドで操作するのが一番快適という結論にいたる2023年仕事については今携わっているプロダクト開発で取り組むべき課題が見えており、しばらくは開発業に専念しそうです。先日こちらの記事でもちょっと紹介してもらったんですが、社内でGoを推進していく機運があり、そのあたりの音頭取りについても積極的に取り組んでいきたいと考えています。先にも書いたとおり、もともとプロダクトやインフラのセキュリティを中心にやっていたのですが、キャリアの冗長性という観点でもプロダクト開発および運用をちゃんとできるようになるまで経験値が積めると良いなと考えてます。プライベートではもうちょっと運動量を増やしていくのが目標です。コロナ禍に入ってから逆に運動する時間ができコロナ禍以前とくらべて10kg弱痩せたんですが、このタイミングを逃さずさらに減量したり体作りをしていけるといいかなと考えています。具体的には筋トレをもうちょっと真面目に頑張ろうと思います。体は資本。ということで皆様良いお年を。来年も各位どうぞよろしくおねがいします。

2022年 → 2023年

!この記事は Ubie Engineers & Designers Advent Calendar 2022 の9日目の記事です。今や情報セキュリティはあらゆる分野で重要視されるようになっていますが、自分がしばらく働いているWebサービス関連の業界では「どの段階から情報セキュリティに取り組めばよいか？」という疑問がしばしば話題になります。昨今のWebサービスの多くは昔からのソフトウェアプロダクト開発における設計→開発→納品というフローで完結するものではなく、高速にプロトタイプを作成して価値検証を繰り返しながら、徐々にサービスとして成熟していくというモデルが多いと思います。そ...

Web サービススタートアップにおけるプロダクトセキュリティの始め方

大晦日ということで2021年のちょっとした振り返りと、2022年のゆるやかな展望のようなものをしたためておきます。仕事2021年今年の前半はクックパッドにてセキュリティ関連の仕事をやっていました。強く印象に残っている仕事がオフィスの移転とISMSの継続審査でした。継続審査はオフィスの移転などに伴って対応が後手後手になり、結構苦しみながら準備をすることになりましたが、なんとか完遂できました。関係者各位、ありがとうございました。そして7月末をもってクックパッドを退職し、ヘルステックのスタートアップであるUbieへ転職しました。ちゃんと働き始めたのは9月からなのでまだ4ヶ月程度なのですが、日々の密度が高すぎてもう1年位働いているような気がしています。ヤバい。mztn.hatenablog.com仕事内容は引き続きセキュリティ関連なのですが、Ubieは社内のリスク対応を専門にとりくむコーポレートセキュリティのメンバーがおり、自分はプロダクト関連のセキュリティに集中して様々な施策をしています。今取り組んでいるのは以下のようなトピックです。インシデント対応体制の構築プロダクトの脆弱性診断3rd partyパッケージの脆弱性管理OPAによるポリシーコード化の取り組みプロダクトセキュリティは自分以外にも（専任ではないいのですが）エンジニアがおり、スクラム形式でタスクを回しています。複数のメンバーで同じ領域に集中して取り組むのはなかなか楽しく、いろいろチャレンジングな取り組みもできています。2022年今年やってきた取り組みも一定形になってきたかなと思う一方で、成熟度はまだまだかなと思っています。特にポリシーのコード化は社内に広く展開し、活用していきたいと考えています。。プロダクトセキュリティ関連だけでなく、コーポレートセキュリティに関するポリシーもここに乗っけていきたいと目論んでおり、OPAというかRegoの布教を進めている日々です。また新しいトピックとして「攻めのセキュリティ」をやっていきたいと考えています。ここでいう「攻め」は「その取り組みによって安全性だけでなく利便性や事業速度の向上にもつながるもの」です。例えば異なるプロダクトで共通するようなセキュリティの機能を事業チームとは別に開発・運用できるようにしておくことで、事業チームがサービスの本質的な機能に集中することができるようになります*1。今まで外向けに使われるプロダクトでの開発経験は豊富ではないため身が引き締まる思いではありますが、チャレンジしていきたいなという機運です。個人活動OSSたまに自分が困ったりしたときには他所のリポジトリにPR投げたりしますが、基本的には自分の作りたいものを作りたいように作る、というスタンスでやってます。今年はGo言語を中心にしたユーティリティをいろいろやっていました。goerr: pkg.go.dev/errors のようにスタックトレースをつけつつ、文脈を表す変数を引き回せるエラー関数golambda: AWS LambdaでGoをいい感じにするやつ。PowertoolsのGo版のつもりzlog: 秘匿値をいろんな方法で隠せるGoのロガーzenv: 環境変数を読み込んだりMac Keychainに隠して管理したりするツール。これはGo関係ないあとデカ目のやつとしてはOctovyというTrivyをベースにした脆弱性管理のツールを作ったというか、作っています。これはもともと前職向けに作っていたやつなんですが、環境がAWS → GCPになったおかげでほぼフルスクラッチで書き換えることになりました*2。github.com登壇とかブログとか転職が挟まった＆ご時世的な状況もあり、ほとんど登壇はなかったです。唯一、自社でホストしたTech Talkイベント（発表資料）で脆弱性管理の話をさせてもらいました。ブログは自分の作ったものを説明したりするときにふらっと書く程度だったんですが、12月はOPA/Regoの一人アドベントカレンダーというのをやりました。我ながら頭がおかしいですね。adventar.org前々から準備していればよかったんですが、これやるか決めたのがそもそも11月中旬で、しかもその時点では「OPAってたしかk8sの設定チェックするツールだっけ？」みたいな状態でスタートしたので、25日分の記事を書くのはなかなかにハードモードでした。もう二度とやらんぞ。私生活転職という大きな節目はあったものの、基本的には前職・現職ともにほとんど在宅勤務のスタイルだったので、基本自宅に引きこもりという生活スタイルでした。たまたまこのご時世に突入する直前の2019年末にマンションを購入していたのですが、ちょっと広めの1LDKを選択していたのが僥倖でした。スペースの余裕は心の余裕。自宅環境の大きな変化はスタンディングデスクを購入したことで、最近おそらく8割以上の仕事時間は立ちながら作業しています。今も立ちながらこの記事を書いています。これで足腰が鍛えられているのかどうかよくわかりませんが、最初の頃は2、3時間くらいで疲れていたのが5、6時間立ちっぱなしでも大して疲れなくなったので一定効果がありそうです。まとめというわけで2021年も各位大変お世話になりました。2022年も引き続きどうぞよろしくおねがいします。*1:このあたりの話に興味がある方はぜひこちらをご参照ください https://mztn.hatenablog.com/entry/2021/11/04/092940*2:Lambda＋DynamoDBだったのをCloud Run+PostgreSQLにしたので、ほとんど異世界転生だった

2021年 → 2022年

TL; DRセキュリティエンジニア（プロダクトおよびコーポレート）絶賛募集中ですセキュリティだけを専門でやられていた方だけでなく、サービス開発が中心だったけどセキュリティも少しやっていたみたいな方も大歓迎ですヘルステックのスタートアップであるUbieで働き始めておよそ2ヶ月ほどたちました。入社する前からなんとなくは知っていましたが、メンバーの熱量の高さや能力の高さに圧倒され続けています。事業についても患者さん向けのユビ―AI受診相談や医師向けのユビーAI問診が中心ではあるものの、その枠に留まらない新しいチャレンジを多角的に取り組んでおり、とても刺激的な日々を過ごしています。自分はセキュリティエンジニアとして入社させてもらい、まだ大きな進捗はないもののUbieで提供するプロダクトやそのプラットフォームのセキュリティを向上させる取り組みをさせてもらっています。転職した理由として、事業ドメインや成長フェーズの異なる会社に移り、自分の技術や知識、そして考え方が通用するかというのを試したいというものがありました。入社前からいろいろと社内の話はいくらか聞いていましたが、実際に働いてみることで徐々に自分の中で取り組むべき具体的な課題がはっきりしてくるようになりました。同時に、1つ1つがとても重い話で一緒に取り組んでくれる仲間がもっと必要であるということも分かってきました。そこで、Ubieがこれから取り組みたい課題について言語化してみつつ、どういった方を探しているかについてまとめてみました。興味を持っていただいた方がいたら、ぜひお話させてもらえると嬉しいです。UbieにおけるセキュリティのチャレンジDevSecOpsバズワードのため定義がはっきりしないDevSecOpsですが、自分の中では以下のように定義しています。プロダクト開発の各段階で必要なセキュリティの要件を満たしていけるプロダクト開発で継続的に脆弱性が入り込んでいないかのチェックをするどのサービス事業会社もそうだとは思いますが、Ubieでは特にプロダクトの機能拡張や新しいプロダクトの開発がものすごいスピードで進んでいます。「今度こういう機能を実装する予定なんですよ」 → 「もうできました」みたいな爆速事案をしばしば目撃します。それゆえにプロダクトの変化が激しく、セキュリティ上問題になるような仕組みになっていないか、扱うデータが適切か、脆弱性などが入り込んでいないかなどを常に気にし続けなければなりません。セキュリティを専門に理解している人が張り付くという方法もあるかもしれませんが、スケールしないというのが難点です。これを解決するアプローチとして仕組み化と自動化を積極的にやっていきたいと考えています。この問題は単にCIにセキュリティチェックを組み込めばいいというわけではなく、どうすれば開発するメンバーの負荷にならないようにセキュリティを向上させられるかを模索していかなければなりません。そのためどちらかといえばプロダクト開発の経験があり、かつセキュリティに対して興味がある、というような方と一緒にチャレンジできると面白そうだなと考えています。全社共通・横断のプロダクト向けセキュリティ機能の実装前述したとおり、UbieではユビーAI受診相談およびユビーAI問診という2つのプロダクトを主軸としていますが、それらの拡張だけでなく新しいプロダクトの開発も積極的に取り組んでいます。これら全てのプロダクトは医療に関係するものであり、各々でセキュリティの機能（認証認可、プライバシー保護、監査、リスク分析など）が必要があります。プロダクトが少ないうちは個別に実装するほうが柔軟に動けるなどのメリットがありますが、プロダクトが多くなってくると実装水準のばらつきや全社的なコントロール、状況把握が難しくなるという課題があります。そこでプロダクトが成長・拡大しようとしているこのタイミングで、全社共通のセキュリティ関連機能を実装したいと考えています。これによって、各プロダクトが必要なセキュリティの水準を満たしつつ、サービス開発者が開発のスピードを上げられるという恩恵も得られるようになると期待されます。具体的な事例として、認証認可基盤の構築があります。開発するプロダクトが増えることで、認証認可の仕組みをどのように整えていくかという問題と向き合わなければいけません。現代の認証認可の仕組みは単純なID・パスワードの組み合わせを保持すればいいというだけでなく、多要素認証や様々なデバイスからの利用、そしてサービス間の連携を考える必要があります。Ubieが新しいプロダクトや機能を展開していくとなるとその間の認可をどのように制御すればいいかも考える必要があります。この機能もプロダクトごとに開発すると実装水準にばらつきが出てしまう他、将来的に会社横断で統合するとなると時間が立つほど移行の苦しみが大きくなってきます。今まさにプロダクトが広がっていこうとしている中でこのような仕組みをゼロから設計・実装できるというのは絶妙なチャンスだと考えていますが、自分はこういった仕組みを知識として知っているだけで、実際に大規模な基盤を実装・運用した経験がありません。そういった知識・経験・実装力をもった方にぜひ力を貸していただきたいと考えています。社内の統合的なセキュリティの向上Ubieは現在急速にメンバーを増やしつつあり、そのため社内システムや働く環境のセキュリティについても急速に整えていく必要があります。創業したばかりのベンチャーだとよくあることかもしれませんが、Ubieは事業を加速させるために社内のメンバーが自ら各種クラウドサービスを積極的に導入・活用するという文化が根づいています。現状、管理体制として2020年にはISMSを取得し、3省2ガイドラインの準拠を進めるなど、社内体制やシステム側の安全管理を急速に整えてきています。しかし今後世界市場に拡大するためにも、今ある文化を活かしつつ、安全かつスムーズに各種サービスが使えるようなサービス統制や環境整備をさらに進化させる必要があります。また、各社内システムなどで一定のセキュリティを保つような設定をしているものの、統合した守りの体制を構築していく必要があります。例えば各システムの状況をセキュリティ観点で監視・調査したり、アラートの調査や対応をしたり、セキュリティ関連のエンドポイント製品の導入や運用をしたり…というようなものがあります。これらをバラバラに使うのではなく、それぞれを連携させて機能できるようなグランドデザインをしながら実装・運用をしていく、という試みが必要です。このような体制を整えていくにあたり、人手を増やすことでスケールさせることも時には必要ですが、近代的なシステムやツールの力を使い、人だけに依存しないような構造を考えていく、というところにエンジニアリングとしてのチャレンジがあるのではないかと思います。そういった取り組みに興味がある人と是非一緒に取り組んでいきたいと考えています。どういった方に来てもらいたいか「セキュリティエンジニア」という募集をすると「ずっと情報セキュリティを専門にやってきた方のみを対象にしている」と思われがちですが決してそんなことはありません。特にセキュリティベンダー以外のユーザ向け企業などにおいて、セキュリティの分野というのは業務や開発といった営みに強く関係するものであり、時としてそちらについての知見が必要とされる場合もあります。もちろん一定のセキュリティに関する知識やエンジニアリングに関する技量は必要となりますが、セキュリティ以外のことについてもいろいろ取り組まれていたり、メインは開発だけど実態としてプロダクトのセキュリティ関連のケアをしてきた、というような人にもぜひ興味を持っていただけると嬉しいです。meetyのカジュアル面談募集のリンクも以下にありますので、興味を持っていただけた方はぜひお声がけください。お待ちしています！meety.netその他関連リンクrecruit.ubie.liferecruit.ubie.life

Ubieで一緒にセキュリティをエンジニアリングしていってくれる方を募集中です

先日ブログに書いたとおり7月末を最終出社として退職し、8月は有給消化期間にした。学生時代以来の長期夏休みを獲得したし、8月上旬にはfully vaccinatedになっていたのでうまくいけば8月下旬にふらっと旅行するぐらい大丈夫なんじゃないかな、とかちょっと期待していたらデルタ株によってご覧の有様である。そんなわけで折角の機会にも関わらず1ヶ月間は自宅の半径2kmから出ることなく過ごす羽目になってしまい、何もなさすぎて自分でも何をしていたのか忘れてしまいそうなのでブログをしたためておく。読書転職先の推薦図書をいくつか読んだ。Measure What MattersOKR (Objectives and Key Results) の仕組みや効果についてひたすら書かれている本。OKRというものに触れたのが初めてだったので最初はよくある目標設定とどう違うのかというのがピンときていなかった。今回、自分が読んでなるほどなと思った点は以下の3つだった。「やるべき重要な取り組み」の優先順位は組織でも個人でもすぐにブレる。なので方向性を揃えたり修正したりするためにOKRが使える。全社的にOKRというシンプルなプロトコルを使うことで目標管理のコミュニケーションがやりやすくなる。特に全社で定めたOKRが下位のOKRとつながることで、会社としての取り組みに整合性がうまれたりメンバー間の協力がしやすくなる。OKRは「組織にとって価値あることに集中」するための仕組みで、成果をトラックする＆必要に応じて柔軟に変更するという運用をやって初めて効果が発揮される。個人の成績と紐付けてはいけない。なぜなら「組織にとって価値あること」ではなく「OKRを達成すること」が重視されるようになり、間違っていたり環境変化によって効果的ではなくなってしまったOKRでもそれを達成させようとする力学が働くからHow Google WorksおなじみのGoogleが内部でどういう思想でどういう運用をしているかについて書かれた本。全体的に話がちょっと古い（2000年代ぐらいの話が中心）なのと、結果論なのではと思う話が多いきらいはあるものの、 "Googleっぽさ" をいくらか理解できたかなと思う。この本で書かれているような内容も現在においてはすでにいろいろな会社・組織に取り入れられるようになったなと感じており、読んだ率直な感想としてすごい斬新だとは思わなかった。ただ、もともとの根幹の話に触れておくのは大切だし、良い機会だったと思う。1兆ドルコーチシリコンバレーのbig tech企業を中心にコーチングの才を発揮していたビル・キャンベル氏の逸話集。氏の類まれな能力や人格による話なので全てをそのまま実践するのは難しく、体系だてた話でもないのでスッと理解するのも難しい。とはいえ自分に足りない人間力的なところで学ぶべきてきなところや、これからチャレンジしていくべきポイントという意味では学びがあったかなと思う。開発個人開発で手を付けたもの。AlertChainSecurity Orchestration, Automation and Response (SOAR) の小さい実装。前職にいたときはAWSのフルサーバレスアーキテクチャでDeepAlertというSOARを実装していたが、次の職場ではGCPなので可搬性ゼロで無事終了していた。ということでコンテナベースで動くものを作ろう思い立ったのだが、この機に最初から設計し直すかとなってフルスクラッチしているのがこのAlertChain。github.com基本的にはセキュリティアラートを受け取って、1) アラートに対して事前に定めたワークフローを自動的に実行する、2) 追加のワークフローを管理画面から実行できる、という2つだけの機能が主軸。事前に定めたワークフローでは、アラートにでてきたIPアドレスをOSINTしたり、条件に従ってリスク判定したり、どこかに通知したりというようなユースケースを想定している。一方、追加のワークフローというのはもうちょっとアグレッシブ＆人間の判断を挟んだほうが良さそうなもので、例えばinstanceをtermianteしたり、ユーザ権限をsuspendさせたり、みたいなのを想定している。下図は対象IPアドレスをBANさせるという追加ワークフローの例。前作との違いを少しふれると、以下の3点。前作は各ワークフローがばらばらになっていてテストがしにくかったのを悔い改め、AlertChainでは全ワークフローを一気通貫でテストできるようにした1プロセスだけで動くようにして運用やデバッグをやりやすくしたAlertChain自体がちゃんとアラートの情報を保持するようにし、管理画面から確認できるようにした正直、まだ荒削りというレベルにすら達していないが次の職場に導入していきたいと画策していて、運用していく中でブラッシュアップしていきたいと考えている。もうちょっと整ってきたタイミングで解説記事などを改めて書きたい。zenv開発などで手元のPCで環境変数を扱う時、envchainを活用しているが、秘匿値以外の環境変数もいい感じに扱えるツールがあると便利だなといろいろ思案した結果、結局envchain + dotenvのようなツールができたというのがこれ。なので既存ツールを組み合わせでどうとでもなる範疇の実装ではあり、人様に強く進めたいというほどのものではない。ただ、 .env ファイルに通常の環境変数だけでなく秘匿値の指定（秘匿値は実際にはkeychain内に保存してある）をしたり、読み込んだ環境変数を元にコマンドライン引数を書き換えたりができるようになっているので、個人的には便利。github.com利用イメージとしてはこんな感じ$ zenv secret write @aws-account AWS_SECRET_ACCESS_KEY Value: # コピペなどで入力$ zenv list @aws-account AWS_SECRET_ACCESS_KEY=**************************************** (hidden) # 読み込んだ環境変数を表示。秘匿値は伏せ字にする$ zenv @aws-account aws s3 ls(snip) # S3のリスト表示$ echo "AWS_REGION=ap-northeast-1" > .env$ zenv list @aws-accountAWS_SECRET_ACCESS_KEY=**************************************** (hidden)AWS_REGION=ap-northeast-1 # .envファイルからも読み込み生活ダイエット特に意気込んでやっていたわけではないんだけど成果はでていたので、したためておく。運動＋なんちゃって糖質制限的なやつを6月末からやっていて、だいたい3kgぐらい減量した。運動は実は去年からずっとエアロバイク30分程度というのを中心にほぼ毎日やっていたのだが、いまいち減量するにはいたならかった。そこでなんとなく食事量（特に糖質）を減らしてみたところ、徐々に体重が落ち始めたので惰性で続けてみて今に至る。食事はbase breadとnoshを活用しており、自分ではオートミールをベースにした炒飯とかカレーとかを調理したりしている。あと鶏むね肉やローストビーフをバッチで継続的に低温調理している。糖質はだいたい1日あたり平均して120gぐらいなはず。あとFitbitに食事管理機能があるのだが、定型の食事（それこそbase breadとかnosh）を摂る場合は計測しやすく便利。記入漏れとかもあるからあまり正確ではないが、概ね1日あたり500〜600kcalほどは消費カロリー量が上回っているらしい。豚肉キャベツ卵納豆とオートミールでチャーをハンしたやつ pic.twitter.com/GC6gE8LRdI— mizutani (@m_mizutani) 2021年8月8日  最近はまっているやつ・鶏胸肉を60度4時間くらいでアノーバする・薄切りにする&冷やしてる場合はレンチン・刻んだネギを盛る・ごま油ちょい＋塩ちょい＋白だしとお湯を1:1ぐらいを混ぜてぶっかける普通に美味くてスルッと食べれるし小腹が空いた時に便利 pic.twitter.com/hIMGtVzOZk— mizutani (@m_mizutani) 2021年9月4日  長らく米を食べていないので「たまにはがっつりカツ丼とか食べたい！」と思うことはままあるものの、今のところそこまで辛い気持ちにはなっていないので、無理なく継続してシュッとしていきたい。ゲームMONSTER HUNTER RISEエアロバイクのお供。毎日30分くらい野良で狩りに行っている。エアロバイクをやっていることを程よく忘れられるくらいの集中力が必要。他のゲームも試してみたが、あんまり没頭できないゲームだと「漕いでいて辛い」という気持ちが続いてしまうのだが、モンハンはいい感じに没頭できる。あと1サイクルが10〜15分くらいなので、2〜3回やっていると運動時間が終わるというのも良い。トータルのプレイ時間はそんなに長くないのでHR200ちょいぐらい。ただ最近さすがにちょっと飽きは感じ始めているので、代替になりそうなゲーム無いかなとは思い始めている。Factorio無人の星に不時着してしまったエンジニアが資源を集めて建物や工場を作り、武装や物流システムを発展させていくゲーム。一応、生産物の一つである「ロケット」を作るとクリアとはされているのだが、マップが無限に広がっておりクリア後も工場を発展させることができる。このゲーム、去年末くらいにめちゃくちゃハマって300時間くらいプレイし、自分なりの物流システムの最適解に至るまでやりこんだ。ところが、あまりに工場をでかくしすぎて処理負荷が大きくなりゲームがまともに動かなくなってしまったので、それ以降あまりプレイしなくなっていた。で、特に何かあったわけではないんだけど、ふともう一度ゼロから始めるかとなり、異世界転生よろしく2周目の知識を活かして、丁寧かつゆるゆるとしたプレイをしている。支配地域を広げすぎてわけわからなくなってしまった図。中心部が工場で、資源採掘ポイントと固定砲台が置かれている軍事拠点が鉄道網で各地に散らばっている月姫もう永遠に発売されないんじゃないかと思っていたけど、本当に発売されたよ！ ありがとうTYPE-MOON！！とりあえずの感想として結構演出も凝っているし（「魔法使いの夜」に近い）フルボイスなのでオートモードでプレイしていると実質アニメを見ているのに近く非常に快適。そのため自分の進行はとても遅くまだ序盤も序盤。ただ原作未プレイ勢ではあるものの、結末とか世界設定とかはだいたい知っているのでゆるゆる一月ぐらいかけて楽しんでいくつもり。

2021年8月の夏休み

https://github.com/m-mizutani/m-mizutani/commit/067a421f3e3e8405cba870bb461446c545128a2e2021年7月30日を最終出社日として現職のCookpadを退職し、9月からUbieという医療系のスタートアップに入社します。Cookpadでのこれまで2017年11月に入社したので、在籍期間は4年弱でした。この間、組織変更に伴う部署異動はありましたが、ずっと情報セキュリティに関わる業務をやってきました。システムのセキュリティ対策主な業務は「インフラや社内システム、開発サービスに対するセキュリティの機能をエンジニアリングによって向上させること」でした。製品やサービスをそのまま導入することもありますが、自分たちの必要に応じて既存ツールを拡張したり、全く新しいシステムを自作することもありました。例えば以下が代表的なやつです。低コストでセキュリティログの横断検索ができる仕組みセキュリティアラートに自動対応する仕組みコンテナ脆弱性を検査して結果を管理する仕組みセキュリティに関する社内の問題を見つけ出してエンジニアリングによってそれを解決していく、という仕事内容は自分の志向とマッチしており仕事はとても楽しかったです。さらに仕事で取り組んだ結果を発表する機会も各所から多くいただき、これについてもありがたかったです。USに飛んで英語で撮影するぞという話を突然もらって、七転八倒しながら達成したのも良い思い出です。ただ調子に乗っていろいろやりすぎてしまった感があり、退職に伴って大量のシステムを引き継ぐことになってしまった点については少し申し訳ないなと感じている次第です。社内リスク対応いわゆる社内の情報セキュリティ委員会というやつもやっており、社内で新たに起きる情報セキュリティのリスクをコントロールするということもやっていました。自分もこの業務に携わるまであまり意識したことがなかったんですが、会社の活動というのは目まぐるしく変化し、それに伴って様々なリスクが発生します。そういったリスクに対応するため、どんな情報システムを使ったらいいのか、どのように使ったらいいのか、どんなデータを扱っていいのか、という相談をうけたり判断をしたりということもやっていました。これは単純に社内ルールに準拠するだけでなく、法律や規制などについても配慮し、とりあつかう情報の重要度などから実際のリスクを考え、現実的な落とし所を考える必要があり、最初のうちはかなりハードな業務でした。自分もそもそも法律などについては素人だったり、（セキュリティの人にありがちですが）過度に安全側に倒して現実的でない方法になってしまうなど四苦八苦していました。しかし同僚の助けも借りつつ最終的にはある程度の部分をこなせるようになった気がしており、自分としてはなかなか良い経験値になったのではと思います。その他会社生活全般組織のカルチャーや雰囲気も自分にとってはかなりマッチしていたと思います。前職が大手SI企業だったこともあり、そのギャップの衝撃から入社直後にわりとはしゃいでいる記事を書いたりしていました。さすがに今はもうこの記事のテンションはありませんが、ここで良かったと感じたことは特に変わっていません。今回の転職直前にオフィスが恵比寿からみなとみらいへ移転するという一大イベントがありましたが、これについても今回の転職とはあまり関係ありません。個人的にみなとみらいはいろいろ思い出深い土地で気持ちがあったし、WeWorkの無限にビールが飲めるサービスとか楽しみにしていたのですが、情勢によって結局ほとんど恩恵に預かれませんでした。悲しい。めちゃくちゃいい天気@みなとみらい pic.twitter.com/UmRlo4tWT1— mizutani (@m_mizutani) 2021年7月27日  転職のきっかけということで現職に対して特に厳しいことがあったというわけではないのですが、自分の能力の幅を広げるという観点でこの度転職をすることにしました。セキュリティエンジニアのキャリアパスというのもいろいろあると思うのですが、自分は「システムのセキュリティ対策」というのがやはり最も興味の強い範囲で、これを継続していった場合にどのようにキャリアを重ねていけばいいのかという点についてはこれまでずっと模索してきました。社内リスク対応の方はパスとして例えばCISOになるというような話があったりすると思いますが、どちらかというと現場でエンジニアリングしていたいので、役職を上げるのとはまた違うかなと考えています。というようなことを長らくもやもやと考えていたのですが、あるきっかけで「違う事業ドメインにチャレンジしてみることで幅を広げるのがいいのでは」と思いつきました。同じWeb系であっても他社のセキュリティ担当の方と話させてもらうと、やはり会社の事業ごとにリスクであったり守るべき資産の捉え方というのが大きく違うな、というのは以前から感じていました。そのため現職でうまくいっている事例を話しても「うちとは（環境や背景が）違いますね」という反応になることがあり、自分のやっていることが他の会社や事業ドメインでどのくらい通用するのか？というのが未知なままでした。そこは確かにやってみないとわからないので「だったら環境を変えてチャレンジすることでより多くの場所で通用することを増やしていこう」と考えるようになりました。Ubieでのこれからというわけで冒頭で書いたとおり、Ubieという医療系のスタートアップに転職することにしました。現状では医療機関向け、および患者さん向けのサポートをして患者さんを適切な医療へつないでいく、といったサービスを提供しています。（私もまだ事業の細かいところを知っているわけではないので、詳しくはこちらの資料を見ていただくか、あるいは興味のある方はぜひお声がけください）ubie.appUbieに決めた理由実は今回の転職では他の会社の選考は受けておらずUbie一本だった*1ため、他社との比較はしていません。普通に考えて転職するときは複数社を受けてオファーを並べて検討するものと思うのですが、1社目で転職しようと考えた決定的な理由は以下の2つでした。事業ドメインが今までと大きく違うセキュリティをエンジニアリングしていくことへの理解1については転職のきっかけの話の通り、事業ドメインがなるべく違うところが望ましいというのがありました。特にセキュリティに対しての厳しさでいうと自分の中では医療と金融が最も難しい分野であり、その片方である医療の分野というのは自分の思惑にとてもマッチしていました。また、事業についても「今あるアナログなビジネスをちゃんとデジタル化していく」という分野は個人的にとても面白く、熱い領域であると考えています。（流行り言葉を使うといわゆる "DX" になるんだと思います）Ubieの事業が医療機関に関わってくることで自分たちのサービスだけでなく、医療機関でのセキュリティというのも同時に携わっていく必要があり、それについてもチャレンジングで興味深いと考えています。自分の中でさらに決定打になったのは2の「セキュリティをエンジニアリングしてくことへの理解」が大きかったです。これはCookpadへ入社する際の転職活動で感じたことでもあるのですが、いわゆるセキュリティの問題に対して製品やサービスの導入するだけでなく、ちゃんと自分たちでエンジニアリングをして問題を解決しようというマインドを持った組織というのは日本だとまだかなり少ない印象です*2。Ubieのメンバーとカジュアル面談をした際に彼らもその課題感をもっており、しかしまだそこにアプローチするメンバーがいないという話を聞いたときに、ここで働いてみたいなとう気持ちが強くなったことを覚えています。この他にもマネジメント的な上下関係がない組織構造（ホラクラシー）や評価のない制度、会社の雰囲気など惹かれた部分はいろいろあります。ただまだ直接働いたわけではなく「良さそう」という印象でしかないので、詳しくはいずれ別の機会にという感じです。やっていきたいことというわけでUbieへの転職後も引き続きセキュリティエンジニアをやっていく予定です。今回は医療という領域になるため、リスクに対する考え方や対応がよりシビアになっていくのではないかと考えています。利用してもらう人のために十分な安全性を担保していかなければならないのですが、じゃあどこまでやったら「十分か」ということを常に見極めていく必要があります。そうしたことを突き詰めていく課程で、最適なセキュリティとはなんなのか？、そもそも最適というものがあるのか？ ということを考えていきたいと思っています。また自分の密かな目標として、サービス運用をソフトウェアエンジニアリングの方法でアプローチするSRE（Site Reliability Engineering）にあやかり、Security Reliability Engineering*3の方法論を探求していきたい、というものがあります。Site Reliability EngineeringはもともとGoogle社内で運用にまつわる作業や問題をソフトウェア開発の考え方・発想・手法で解決する方法論を体系化して世に出したのが発端という認識です*4。この着想はセキュリティに関する運用にも適用でき、ソフトウェアエンジニアリングの応用で解決できる問題というのは多くあるのではないかと自分は考えています。ただSREとは領域や前提がいろいろ違うためそのまま持ってくることはできず、セキュリティ分野ならどうかということを改めて検討しなければなりません。自分が新しい領域でチャレンジすることでSecurityのReliability Engineeringの方法論を体系化していく足がかりになればと考えており、引き続きやっていきたいと思います。ということで各位、引き続きどうぞよろしくお願いいたします。*1:厳密に言うとUbieに最初に声をかけてもらったので、Ubieの選考がだめだったら他を考えようとしていました*2:逆に海外のbig tech companyはこのマインドがかなり強い印象で、例えばAWSの事例紹介などでユーザ企業がAWSのサービスを組み合わせてセキュリティの問題を解決しているという話は多くあります*3:略語がSREともろかぶりなので、この名付けはどうかと思うんですが*4:なんですが門外漢なので違ったらこっそり教えて下さい

転職します（Cookpad → Ubie）

3月8日の11:00〜の回でシン・エヴァンゲリオンを観劇してきました。基本的ただの雑感のなぐり書きですが、旧劇の「閉塞の拡大」をBGMに聴きながら今のお気持ちをしたためておきます。思春期から拗らせた者の末路なので、その前提でご笑覧ください。ネタバレしかないので、ご注意ください全体通して「まとまった…な…？」みたいな感じ。アニメーションとしてはめちゃくちゃ動くしすごかったけど、エンターテイメントとしては序や破の方が好きだし、旧劇劇場版のようにバチバチに尖ったところもなかったなという感じ。とはいえこれまでの物語を締めようとしているというのがしっかり見えて「あーこれで終わりなんだな」というのを実感させられた。四半世紀に渡る因縁に対してスパッと決着ついたのかと言われるとちょっとわからないけど、とりあえずこの作品を世に出してくれてありがとうという気持ちです。その他雑感序盤〜ヴンダー出撃小出しにされるコンテンツ見るの嫌い派なので先行映像は一切観なかった、ので冒頭の戦闘シーンは登場する敵含めてちょっと意表をつかれて良かった村の生活で人間性を獲得していく綾波に対し、どんどん人間性を失っていくシンジがちょっと哀れシンジ、旧劇ではわりと「そんなことでうじうじしているんじゃない」みたいな感じがあったけど今回の件はまあそりゃ落ち込むよね…、という納得がめちゃくちゃあったとはいえ旧劇劇場版みたいに最後までこのテンションだったらどうするんや…と思っていたけど、ちゃんと復活してくれてよかったアスカにけちょんけちょんに言われてたけど、自分で世界滅ぼしかけて目前で友人殺されてという状況からちゃんと立ち直るの、むしろ強靭メンタルすぎでは？アスカとケンスケがいい仲になっていたのは最初「まじで！？」ってなったけど、個人的にはなんかわりとすんなり受け止められた。一方、一緒に見に行った友人は許せていなそうであった。古のオタクは難しいのだプラグスーツの電源がなくなる描写、そのまま爆発でもするんじゃないかとヒヤヒヤした異空間での戦闘〜シンジ覚醒誘導弾、「完全に無人在来線爆弾じゃねーか」と思わずツッコミ「ヤマト作戦」とかその他あれこれで、ああ庵野監督は本当に宇宙戦艦ヤマト好きなんだなぁと実感ミサトさんとシンジのコミュニケーションが落ち着いたものでなんか良かったマイナス宇宙〜終劇親子プロレス（初号機vs13号機）は、仮想世界での戦いという演出はすごいわかるんだけど、なんかギャグっぽく感じてしまいうーむという印象「特撮っぽい描写」を演出するために色んな要素をチープにしていたと思うんだけど、あそここそ全力全開最高作画をやってほしかった異空間とかスケールのデカさからなんかグレンラガンを想起した旧劇のお家芸、精神世界描写もでてきたり、旧劇のラストに通じるアスカのシーンも会ったりして「あー、ほんとうに過去の因縁を終わらせようとしてくれたんだな」というのを感じたしかしこれ新劇だけ観てた人にはわりと「？」になったりするんじゃないかな本当は旧劇もこうありたかったということなんじゃないかなー？旧劇だとゲンドウについてあまり語られなかったけど、今回の深堀りで普通にまるでダメなオヤジだったことがわかりちょっとニッコリしたわれながらちょろいけど髪下ろしたミサトさんいいよね、、となりました最後のシンジの相手がマリだったのは、嫌ではないんだけど個人的には納得いかずそもそも君たち本作でやっとちゃんとした面識持ったというぐらいの仲じゃん…。個人的にはあのポジションはレイだった。アスカはケンスケとよろしくやっているのでヨシこれはなんか過去作に気づいてない伏線とかあるのかもしれないので考察班を待ちます最後が実写だったのは、監督からの「現実に帰ってこい」的なメッセージを感じましたね旧劇時代に比べ、監督が結婚して拗れが解消したという説はわりと信憑性があると思う

シン・エヴァンゲリオン感想（ネタバレあり）

表題のとおりですが altenv というツールを作りました。 Alter environment の略です。github.comモチベーション業務上、大小様々なツールやらシステムやら（これとかこれとか）を開発をすることが多いのですが、あつかうプロジェクトが多くなると開発やデプロイなどに使う設定値の管理がだんだん煩雑化していくという課題を感じていました。特に一部のツールは外部公開もしているので、実装と設定をちゃんと分離しようとすると（特にローカルでの開発に関する設定の場合）数ヶ月たった後に作業をしようとすると「どの設定値を使うんだっけ、、」というのがちょいちょいありました。単純にちゃんと管理しておけという話ではあるものの、そういった設定値を統一的に扱えるものがあると便利だなと思って作ったのがこのツールです。端的に言うと、オプションや設定ファイルに記載された内容に応じて環境変数を読み込み、その環境変数とともに指定されたコマンドを実行するというだけのツールです。イメージとしては以下の通り。$ cat test.envDBNAME=hoge$ altenv -e test.env npm run server# running npm server with environment variable DBNAME=hogeユースケース細かい利用方法はレポジトリの方に書いたつもりなので、ざっくりとユースケースごとの使い方を書いておきたいと思います。コマンドラインのオプションでいろいろ指定することもできますが、デフォルトで $HOME/.altenv という設定ファイルを読み込むので、そちらの設定を交えて紹介したいと思います。プロジェクトのディレクトリごとに環境変数をわけるwordir.xxx というテーブルがあり、これを使って作業ディレクトリごとの環境変数を定義できます。（ xxx はただのラベル）[workdir.proj1]dirpath = "/Users/mizutani/.ghq/github.com/xxx/project1"define = ["DB_NAME=mydb1"][workdir.proj2]dirpath = "/Users/mizutani/.ghq/github.com/yyy/project2"define = ["DB_NAME=mydb2"]CWDが dirpath 以下にあるとそのテーブル内に記載された設定が有効化されます。具体的には以下のようになります。（ -r dryrun で読み込まれた環境変数一覧が表示されます）$ cd /Users/mizutani/.ghq/github.com/xxx/project1$ altenv -r dryrunDB_NAME=mydb1$ cd ../../yyy/project2$ altenv -r dryrunDB_NAME=mydb2外部のレポジトリやファイル共有サービスから参照するdefine で環境変数を定義するやり方だと全ての環境変数を $HOME/.altenv に書く必要があり、チーム内で共有するのが難しくなってしまいます。なので、外部ファイルを参照することで、gitレポジトリやファイル共有サービス（Google File StreamやDropboxなど）を使って環境変数を共有できます。（ただし、gitレポジトリは自分で最新ファイルをpullしてくることを想定しています）[workdir.proj1]dirpath = "/Users/mizutani/.ghq/github.com/xxx/project1"envfile = ["/Users/mizutani/Google Drive File Stream/Shared drives/MyTeam/config/project1.env"][workdir.proj2]dirpath = "/Users/mizutani/.ghq/github.com/yyy/project2"envfile = ["/Users/mizutani/.ghq/github.com/yyy/configs/project2.env"]このように設定することにより、project1 のディレクトリにいる際にはGoogleドライブのShared Drive内にあるファイルが、project2のディレクトリにいるときはconfig管理用レポジトリ内のファイルが参照されるようになります。Staging / Production などの切り替えをする例えば同じディレクトリでもステージング環境とプロダクション環境の両方にアクセスする場合、利用する環境変数の切り替えが必要になります。 profile.xxx というテーブルを用意することにより、利用したい設定を都度選択できるようになります。profileにおける xxx はそのままプロファイル名になります。[profile.proj1-stg]envfile = ["/path/to/proj1/stg.env"][profile.proj1-prd]envfile = ["/path/to/proj1/prd.env"]このように設定しておくと、 -p オプションによって読み込まれる環境変数を切り替えることができます。$ altenv -p proj1-stg ./deploy.sh# ステージング用の環境変数が読み込まれた上で deploy.sh が実行される秘匿値を環境変数に使う（macOSのみ）macOSが提供しているKeychainに環境変数を保存しておくことで、ファイルなどに平文保存するより安全にAPIキーなどの認証情報を管理できます。基本的には envchain の機能をベースに実装しています。-r update-keychain -w <namespace> というオプションをつけることで、読み込んだ環境変数をKeychainに書き出します。<namespace> は任意の名前空間を指定できます。例えばすでに平文でファイル保存していた場合は以下のようにしてKeychainへの書き出しができます。$ altenv -e credential.env -r update-keychain -w mycredあるいはすでに環境変数に読み込まれている場合は以下のようにしてKeychainへ書き出すこともできます。例としてAWSで利用する環境変数 を保存してみます。$ env | grep -e "^AWS_ " | altenv -i env -r update-keychain -w aws-cliまた、コピー＆ペーストにより1つずつ書き出すこともできます。$ altenv --prompt AWS_SECRET_ACCESS_KEY -r update-keychain -w aws-cliEnter AWS_SECRET_ACCESS_KEY Value:# 秘匿値を想定しているため入力した値は表示されない呼び出すときは -k <namespace> オプションで保存した環境変数を呼び出せます。$ altenv -k aws-cli -r dryrunAWS_SECRET_ACCESS_KEY=xxxxxxxAWS_ACCESS_KEY_ID=xxxx$ altenv -k aws-cli aws s3 ls2019-11-21 19:02:20 mybucket-12019-11-21 19:02:22 mybucket-2...

CLIの環境変数をいい感じに管理するツールを作った

だいたいタイトルの通りなのですが、色々なサイトで公開されているブラックリストを取得して、トラフィックログなどとの照合に使うことを目的とした badman というライブラリを作成しました。Blacklisted Address and Dmain name Manager です。github.com少し前だとネットワークのセキュリティ監視をするといったら、だいたいsnortのようなネットワーク型IDSを使うことが多かったと思います。しかし近年だと殆どの通信がHTTPS化されているということもあり、現状だとネットワーク型IDSはあまり有効な手法と言えなくなってしましました。代わりにできることの一つとしては、ネットワークのフロー情報（IPアドレス、ポート番号、プロトコルややりとりされたデータサイズなど）やDNSの問合せ＋応答のログを蓄積しておいて、マルウェアのCommand & Controlサーバや詐欺サイトとの通信が発生していなかったのかを検証することです。この方法だとWebなどの通信が暗号化されていたとしても、不審な通信があったかを発見できます。ただ、継続的に発生する通信ログの検証をするたびにブラックリスト提供サイトからリストをダウンロードしてくると、提供サイトや自分のネットワークにも負荷をかけてしまいます。そこで一度ダウンロードしたものを中長期的に使い回せるようにと考えて、このライブラリを作成しました。なお、ライブラリになっているのはログの入力方法やログの内容が環境によって大きく異ると考えられたからです。具体的なアーキテクチャ例は後で説明します。どう使うものかGo言語に親しい方だとだいたい以下のコードを見てもらえるとイメージがつくのではと思います。package mainimport (    "bufio"    "log"    "os"    "github.com/m-mizutani/badman"    "github.com/m-mizutani/badman/source")func main() {    man := badman.New()    if err := man.Download(source.DefaultSet); err != nil {        log.Fatal("Fail to download:", err)    }    // ipaddrs_in_traffic_logs.txt contains IP address line by line    fd, err := os.Open("ipaddrs_in_traffic_logs.txt")    if err != nil {        log.Fatal("Fail to open a file:", err)    }    defer fd.Close()    scanner := bufio.NewScanner(fd)    for scanner.Scan() {        entities, err := man.Lookup(scanner.Text())        if err != nil {            log.Fatal("Fail to lookup:", err)        }        if len(entities) > 0 {            log.Printf("Matched %s in %s list (reason: %s)\n",                entities[0].Name, entities[0].Src, entities[0].Reason)        }    }}このコードでやっていることは以下のとおりです。ブラックリストを提供しているサイトから複数のリストをダウンロードして自分用のレポジトリを作るIPアドレスのリストが含まれている ipaddrs_in_traffic_logs.txt を開いて1行（1 IPアドレス）ずつとりだすとりだしたIPアドレスがレポジトリに含まれていたか検証するこのサンプルだと1.のブラックリストをダウンロードしてくるところは毎回実行されてしまいますが、本来はダウンロードしたものをローカルに一度保存し、それを使い回すということを想定しています。保存する方法は A) シリアライズされたデータをファイルに書き込んで、次回以降はそのファイルを読み込む、 B) 永続性のあるデータストア（現在パッケージに取り込んでいるのはAWSのDynamoDBのみ）をバックエンドに使う、の2通りがあります。詳しい使い方についてはレポジトリの README を御覧ください。アーキテクチャ例AWSで使うことを前提に、2つのアーキテクチャ例を紹介します。それぞれ badman をライブラリとして使って独自にプログラムを作り、動作させることを想定しています。サーバレスで使う場合このケースでは、2つのLambda関数を利用しています。 1番目（左側）の関数はブラックリストを定期的に取得し、シリアライズされたブラックリストデータをS3に保存します。 2番目（右側）のLambda関数は、トラフィックログファイルがS3にアップロードされた際のObjectCreatedイベントによって呼び出されます。 そしてLambda関数はシリアライズされたブラックリストデータとログファイルの両方をダウンロードし、トラフィックログのIPアドレスがブラックリスト内に存在するかどうかを確認します。 存在する場合、ラムダはSlackなどの通信ツールを介して管理者に通知します。このアーキテクチャの利点はスケーラビリティと価格の柔軟性です。Lambdaは（上限はあるものの）トラフィックログの到着件数の増減に応じてスケールアウト・スケールインするのでログ量に応じてリソースが足りなくなったり、逆に過剰にリソースを割り当てたり、というのを心配する必要がありません。さらに、ログ量が少なければ料金も自動的に少なくなるので、あまりコストをかけたくない小さい規模のネットワークの監視をするなどのケースでおすすめです。一方で、不利な点は遅延です。ログの流量によりますが、S3にアップロードする前にログをある程度まとめることになるのでそのバッファリングをしている時間は遅延が発生します。経験則だと概ね数分〜十数分になります。もしリアルタイム性が必要なら以下のサーバ型モデルを採用したほうが良いかもしれません。サーバ上で使う場合このアーキテクチャでは常時稼働しているプログラムをホスト上（この例ではAWS EC2）で動かします。主な利点は、リアルタイム性のためのストリーム処理です。 先述したとおり、サーバレスモデルではある程度ログをまとめてからS3にアップロードする必要があるため、ログの発生から処理完了までに数分の遅延が発生します。常時稼働させるサーバプログラムを使ってデータを絶えず流し込むことで、遅延を最小化します。このプログラムはfluentdのforward用のサービス*1 を動かしている事を想定しており、fluentd経由でトラフィックログを受信します。 その後、badmanを使用して、ブラックリストに含まれているIPアドレスのトラフィックログを確認します。 ブラックリストは定期的に更新されることを想定しています。プログラムを実行しているホスト（この場合はEC2）がクラッシュしても回復できるように、DynamoDBをデータ保存用のレポジトリとして使用します。このアーキテクチャの欠点はリソースの割当が難しいことです。おそらくログの流量がボトルネックになるので、その最大値に合わせてホストのリソースを設定する必要があります。さらにトラブルやいつもと違うイベントでログの流量が大幅に増える可能性がある場合は、それについても気をつける必要があります。これを解決するためには自動的なスケーリングなどの仕組みと組み合わせて使う必要があります。利用してもらうにあたっての注意ブラックリストを提供しているサイトはそれぞれ異なるポリシーを持っています。そのため、環境や組織によっては利用条件を満たさない可能性があるため注意してください。使えるブラックリスト提供サイトを限定するために、利用者が自分で使うサイトを選択することもできるようになっています。また、自分で badman が提供しているInterfaceを満たす構造体を実装すれば、独自のサイトや非公開のデータストアからデータを取り込むことも可能です。簡単にですが各サイトのポリシーについてもREADMEにまとめてありますので、そちらもご参照下さい。ちなみに昔、似たような mdstore というツールを実は作っていたんですが、今回はGoでえいやと作り直しました。理由としてはLambdaで動かしたかったので、1) Lambda+マネージドサービスだけでよりステートレスに動かす仕組みを作りたかった、 2) 概ねnodejsより速く動くGoにすることで、実行時間を短くして安く済ませたかった、などです。*1:プロトコルは https://github.com/fluent/fluentd/wiki/Forward-Protocol-Specification-v1 になります

IPアドレスやドメイン名のブラックリストを取得・管理するGo言語のライブラリを作った

AWSにおけるお手軽セキュリティ監視運用のはじめかた 2019（Cookpad Tech Bookより）

最近、セキュリティアラートの自動対応に対する機運が高まっているので、どういった種類のものがあるかについて整理のため自分なりにまとめてみました。なおここでの「アラート」は「セキュリティシステムや人間がある程度の確度をもってセキュリティ侵害が発生した、あるいは発生し続けていると判断したもの」を指しています。disclaimer基本的に筆者の知識・経験に基づいて書いてます。もっとこういうのあるよ、というのがあれば教えて下さいアラートの検知などの話はしません各対応の細かい実装方法についても話しません（環境・製品・サービスなどに大きく依存するため）アラートの対象となるホスト（被害を受ける側）については、特に断りがない限りサーバ環境とクライアントPC環境の両方を想定して書いていますお題は以下の通りです。Notification (通知)Investigation (調査)Preservation (保全)Block (遮断)Remediation (修復)Quarantine (隔離)これらから1つだけ選ぶ、というよりは状況などに応じて複数を併用することを想定しています。Notification (通知)概要: アラートが検知されたことを関係者に通知する。EメールやSlackなどチャットに流すこともあるし、PagerDutyのように通知先や対応状況の共有などをサポートするツールを利用することもできる利点対象ホストに対して（基本的に）全く干渉しないため誤検知だとしてもホスト・サービスなどに対して影響しない課題（当然だが）人間が対応を開始するまではホストはアラートで示された状況から何も変化しないので、もし本当に危険に晒されている状況で人間が対応を開始できなければ危険度は高くなっていく検討事項基本的には人間が対応をすることが前提であるため、誰がいつどのように対応するか？ということまで含めてちゃんと設計する。例えば「通常業務時間内で対応する」というのであれば原則として深夜や土日に検知されたアラートについては通知がきても翌営業日ないし週明けにしか対応できない、というようなことを組織内で握っておく必要があるホストに影響がないからといってどんなアラートでも通知しようとすると流量が増えていき人間が疲弊する。また、意図的に増やそうとしなくてもセキュリティシステムなどの更新により新しいアラートが検知されて流量が増える可能性もある。そのためアラート数を少なくするような仕組みとセットで考えるとよいInvestigation (調査)概要: アラートに出現した識別情報（IPアドレス、ドメイン名、ユーザ名、ファイルのハッシュ値などなど）に対して関連情報を収集する。例えば不審な通信のアラートが検知された場合、外部の脅威情報DB（VirusTotalやabuse.chなど）を参照することで、その通信先がC&C（Command & Control）サーバとして利用されていたのかどうかを知ることができる。他にもあるユーザが不審な行動をしたというアラートが検知された場合、組織内で利用しているサービスやシステムのログを参照することで、当該ユーザがアラートの前後に何を、どこから実施していたのかがわかる。これによって、アラートのリスク評価などの時間を短縮できる。なお、調査のみを単独で実施するというよりは通知などと組み合わせることでより効果を発揮する利点調査をする過程において判断が必要となる手順はあまりないため、誰がやっても同じ結果になる。そのため自動化の恩恵（時間の短縮、ミスの防止）を十全に受けることができる。課題特になし検討事項外部の情報を参照する場合はAPIなどを使って検索をすることになるが、そのような脅威情報を提供してくれるサービスは無料版だとかなり厳しくAPIの利用制限が定められている場合が多い。したがって、アラートが大量に発生している状況ですべてのアラートについて調査しようとするとあっという間に利用制限に引っかかる。特に自動化していると気づかずにDoSのようになってしまって、あげくBANされる可能性もあるため流量の制限などは事前によく検討しておく必要がある。なお有料版にすることで制限緩和してくれるサービスもあるが、だいたいはそこそこいいお値段である上述のポイントにも絡むが、1つのアラートに対してどこまで深堀りするかも考える必要がある。例えば、あるIPアドレスが過去にマルウェアを配布していたという情報を得た際、どのような種類のマルウェアなのかを知ることでよりリスク評価が容易になる。ただ、そのような紐付けされた情報をたぐり始めると際限がなくなってしまい、APIの制限にひっかかったりシステムの負荷が上がってしまうという問題がある。そのため、無闇に関連する情報を探すのではなく、アラートに含まれる識別情報の意味と文脈を考えて、ちゃんと調査する対象を選んだりどこまで調べるかを考えなければならないPreservation (保全)概要: アラートの対象となっているシステムから調査に必要そうな情報を探して別の場所に保全する。集める情報としてはシステムログ、ミドルウェアやシステムの設定情報、動いているプロセスやネットワークの状況といったものが挙げられる。フォレンジックアーティファクト収集ツールを自動で実行しデータを別の場所へ転送するイメージ利点通知、調査に次いでホストに影響を及びさない（ただし情報取得時に負荷のかかる手段を使うと、可用性の面で影響があるかもしれない）収集したい情報が大量であったとしてもアラートが検知された近辺でのみ収集することで、データ転送やストレージなどのコストを下げられる課題通知などと同様にホストに干渉しないため進行中の脅威があった場合に阻止してくれるものではない侵害を受けたホストの場合、保全の対応をする前にrootkitなどを仕込まれている可能性があるため、ファイル情報やプロセス情報などが改ざんされたものになっている恐れがある検討事項セキュリティ侵害を受けた対象ホストから保全した情報の削除・変更ができるとまずいので、権限の設定やアーキテクチャをちゃんと考える必要がある課題の部分でも述べたとおりアラート発生後だと正しい情報を取得できない可能性がある。自動化によって対応開始の時間を短縮でき人間が手動で対応するよりは良いが、アラートもセキュリティ侵害発生直後に発見されているとは限らず、後手に回っているのは間違いない。そのため多少データ転送やストレージのコストがかかったとしても、常時必要な情報を収集する仕組みを検討する価値はある厳密な証拠保全の観点から言うと、自動保全の工程で微細な証拠を消してしまう（例えば証拠が残っているディスクの一部の領域を上書きしてしまうなど）可能性もあるので、そういった工程のなかで影響がないように留意するBlock (遮断)概要: 現在進行系で攻撃を受けている際に、攻撃元になっている相手を遮断して攻撃による影響を排除すること。つまりBAN。主に外部にサービスを提供するサーバ環境で必要な場合が多い。狙ってやってくるDoS攻撃だけでなく、悪意のあるなしに関わらずシステムに想定外の負荷をかけるような通信や、不正な行動（リスト型攻撃など）を弾くといった場面でも有効な場合がある利点可用性の点でいうと、サービス側の性能向上や負荷がかかる部分の修正といった作業無しですぐ効果がでる課題サービスの場合、すべての通信を遮断するとただのサービスダウンになってしまうので攻撃者の識別子（IPアドレスやユーザ名）を指定した上で遮断することになる。しかし、どちらも攻撃者からすると比較的簡単に用意できるため、ボットネットなどを使って数の暴力で押されると弱いという問題がある概要にも書いたとおり、あくまで可用性への影響低減や不正な行動の抑制に対して効果があるものであり、任意コード実行などの攻撃が成功したあとに遮断しても無意味である（遮断しても別の場所から打ち込まれて死亡するだけなので）検討事項BANした対象をどの程度の期間BANし続けるかも考えておく必要がある。IPアドレスのような識別子はNATによって複数人が同時に使っていたり、アドレスのつけ変わりによって別の人が利用したりすることはよくある。永久にBANし続けると無関係の人まで巻き込んでしまうため、攻撃による影響低減とのバランスをとって検討しなければならないサービス内でBANする場合は比較的柔軟に遮断ルールを持てる（はずだ）が、マネージドサービスやセキュリティ製品をつかってネットワークのレイヤでBANする場合は保持できるルール数に上限があったりするので注意が必要であるあくまで筆者の経験則や聞いた話だが、いきなりボットネットで大規模攻勢に晒されるということはあまり多くはない気がするため、短期的には遮断しつつ、その間に別の対応を進めるというような併用が効果的かもしれないRemediation (修復)概要: 攻撃、あるいは悪意のないミスなどによって変更されてしまったファイルや設定などを含むシステムをあるべき状態に戻すこと。サーバ上のコンテンツ復旧や、マルウェアに汚染されたホストからマルウェアを取り除いて正常な状態に戻すといったようなことも含める。また、ホストだけではなくクラウドを含むマネージドサービスについても、管理者が禁止している設定内容になっていた場合に自動的に修復させる、といった用法もある。概念としてまとめてしまったが、具体的な方法については修復対象によって大きく異る。利点攻撃によるコンテンツや設定などの改変に対しては、（場当たり的にではあるが）可用性を高めることができる。機密性や完全性が損なわれている状態だとしても、とにかく可用性を維持したいというようなものに有効（主に悪意のない）意図しない設定変更などに対しては、認可の粒度の粗さを補うことができる。つまり「Aという項目に対して変更する権限をあたえる」までしか認可の設定ができないシステムにおいて「Aという項目はXかYという内容になっていなければならない」というルールを強制したい場合に、「Aという項目がZになっていた場合に自動的にXに戻す」というような対応をすることで、擬似的にルールを実現できる。課題攻撃による改変に対しては、根本原因を取り除くわけではない。改変が発生しているということはホスト上の様々な箇所が改変されている可能性があり、それらを全て適切に修復するのはかなり困難である。例えばサーバの場合だとコンテンツや設定だけでなく、同時にバックドアが仕込まれている可能性が高い。またPC環境でマルウェアに感染していた場合、昨今のマルウェアは感染とほぼ同時に複数の悪意あるコードをホスト上のあちこちに仕込み、1つや2つ駆除されたとしても別のマルウェアが再度汚染を再開させてもとの状態に戻ってしまう。したがって攻撃に対しては場当たり的であると言わざるを得ない。主に悪意のない、意図しない変更に対する修復についても便利ではあるものの、一度は意図しない状態になってしまう（完全に変更を防げるわけではない）という点に留意する必要がある。そのため、根本的には認可の粒度をより細かくできるようにする、というアプローチの方が重要である。クラウドのような環境であれば問題が起こったホストをまるごと潰して、全く同じものを再度作り直すという自動化をすることで、ホスト上にどのような改変がされていたとしても完全にその影響は除去できる。ただし、同じものが再度作られるということは当然攻撃を成功させた脆弱性もそのまま再現されるので、やはり根本解決には至らない検討事項課題で述べたとおりあくまで場当たり的な対応であり、修復単体で対策しても可用性を少し高める程度である。並行して根本的な（おそらくは人間による）対応を実施するということを念頭に置いて自動化を設計する必要がある。フォレンジックの観点で考えるといろいろな痕跡を破壊する可能性があるため、それを踏まえた上で実施するかどうかを検討する必要もある。Quarantine (隔離)概要: 攻撃を受けたとされるホストをネットワークから切り離し、攻撃による内外への影響を閉じ込める。攻撃を受けただけという状況よりは、攻撃が成功してすでに侵入されている、といった状況で被害の拡大を防ぐのに有効な一手になる。利点ほとんどの攻撃がネットワーク越しに発生する＆社内向けシステムもほとんどがネットワークによってアクセスされることを考えると、攻撃元からの指示を止めつつ内部システムや外部サイトへの影響を完封できる。攻撃の進行を食い止めるための強力な方法である課題ネットワークから切り離されるため、可用性に対しての影響が大きい。サーバの場合はサービスの提供が全くできなくなるし、PC環境の場合は操作している人の作業が強制的に中断される可能性がある。サーバの場合はサービスが冗長化してあって対象のホストを急に隔離しても大丈夫＆すぐに代替のサーバが用意できる、というようなアーキテクチャになっている必要がある。PC環境の場合は事前にそのような対応をすることについての合意形成が必要になる課題と言うほどではないかもしれないが、ほとんどの場合があくまでホスト単位での隔離なので、すでに攻撃が横展開されていた場合は影響を完封できないことには留意したい検討事項課題で述べたとおり、他の対策に比べて非常に影響が大きく安易に実施できない。そのため自動的に実施する場合は、対象ホストの重要度（機密性の高い情報がある、強い権限を持っている、など）を考慮したり、攻撃が進行中であることを示す複数の証拠をもとに発動させるなど、慎重に条件を検討する必要があるネットワーク通信を遮断するため、C&Cサーバとの通信も遮断される。これは影響を極小化するという意味ではいいが、フォレンジックの観点からは追跡が難しくなるとも言える。これについてはどちらが良いかという諸説がありつつ、ビジネス的な判断要素も多分に絡まってくる。そういった高度な判断が必要と考えると、やはりあまり自動化に向かないかもしれない

セキュリティアラートの自動対応の種類についてまとめた

あまりにニッチすぎるから全く需要ないかなと思ったんですが、世の中に3人くらいは同じ悩みを抱えた人がいるかなー？と思ったので一応ブログをしたためておきます。github.comこれはなにタイトルでちょっと雑に書きましたが、もう少し正確言いうとAmazon S3上に保存したログのフォーマットやスキーマの一部をコード上で定義し、管理するためのフレームワーク in Go言語です。以下のように定義を書いた後、S3のバケット名、キーを指定するとパース済みの構造体を返してくれます。ここでは1行ずつのJSON形式で保存されたログが your-bucket バケットの http_log/ 以下に入っており、さらに ts というフィールドに時刻情報が入っていることを定義しています。   pipeline := rlogs.Pipeline{        Ldr: &rlogs.S3LineLoader{},        Psr: &parser.JSON{            Tag:             "ts",            TimestampField:  rlogs.String("ts"),            TimestampFormat: rlogs.String("2006-01-02T15:04:05"),        },    }    reader := rlogs.NewReader([]*rlogs.LogEntry{        {            Pipe: pipeline,            Src: &rlogs.AwsS3LogSource{                Region: "ap-northeast-1",                Bucket: "your-bucket",                Key:    "http_log/",            },        },    })実際の読み取りはこんな感じ。   ch := reader.Read(&rlogs.AwsS3LogSource{        Region: "ap-northeast-1",        Bucket: "your-bucket",        Key:    "http_log/log.json",    })    for q := range ch {        if q.Error != nil {            log.Fatal(q.Error)        }        values := q.Log.Values.(map[string]interface{})        fmt.Printf("[log] tag=%s time=%s src=%v\n", q.Log.Tag, q.Log.Timestamp, values["src"])    }rlogsの中には自分自身の需要によりJSON、VPC FlowLogs、CloudTrailのそれぞれのログに対応するパーサーを用意していますが、自分で実装することもできます。なんで必要なのかS3はオブジェクトストレージという性質上、当然ながら保存するときのログの中身・構造は一切問われません。そのためフォーマットやスキーマという概念を（ほぼ）無視してログの保存ができますが、一方でログを利用する際には別途中身をパースする必要があります。保存しているログが2、3種類だけしかない、あるいは保存する際にちゃんと共通のスキーマに落とし込んでいる、というような場合はこれ以上お話することはないのですが、だいたいの場合現実はそうはいかないかなと思っています。特にS3にログを保存するときのメリットは「高可用でログの一次保存ができる」という点が大きいです。そのため、ログを保存する前にあれこれやってエラーなどがおきて可用性が下がってしまうというのは、アーキテクチャの旨味が少なくなってしまうかなと思います。ということからログを利用する際にはどのバケット、どのプレフィクスにどんなログが入っているかを知っている必要があります。ログを利用するツール・システムが1つだけならそこに定義などを書いておけばいいのですが、実際には様々なことにログを利用したくなるため、自分は共通化したいと考えました。そこで共通利用できるようにして、ついでにログの取得＋パースの機能もつけようと思ったのがこのフレームワークです。どう使うのか組織内などで1つレポジトリを作り、そこにフォーマットやスキーマの定義を書いて、それをGoのパッケージとして呼び出す、というような使い方を想定しています。例えば your-git-server.example.com のようなサーバがあって your-git-server.example.com/someone/logparser のようなレポジトリを用意した場合、以下のような感じで定義を書いておきます。package logparserfunc NewReader() *rlogs.Reader {        logEntries := []*rlogs.LogEntry{                // ログの取り込み方＋パースの仕方＋場所の定義を                {                        Pipe: rlogs.Pipeline{                                Ldr: &rlogs.S3LineLoader{},                                Psr: &parser.JSON{                                        Tag:             "your.log",                                        TimestampField:  rlogs.String("time"),                                        TimestampFormat: rlogs.String("2006-01-02T15:04:05Z"),                                },                        },                        Src: &rlogs.AwsS3LogSource{                                Region: "ap-northeast-1",                                Bucket: "your-backet",                                Key:    "logs/",                        },                },               // いろいろ書く        }        return rlogs.NewReader(logEntries)}そのあと、実際にログを利用するコード内で以下のように呼び出します。package mainimport (        "your-git-server.example.com/someone/logparser")func main() {    reader := logparser.NewReader()    ch := reader.Read(&rlogs.AwsS3LogSource{        Region: "some-region",        Bucket: "your-bucket",        Key:    "http/log.json",    })    for q := range ch {        if q.Error != nil {            log.Fatal(q.Error)        }        values := q.Log.Values.(map[string]interface{})        fmt.Printf("[log] tag=%s time=%s src=%v\n", q.Log.Tag, q.Log.Timestamp, values["src"])    }}どう使っているか以前、会社のブログにも書いたですが、今の仕事ではおよそ20種類ぐらいのログをこのフレームワークを利用して取り込み、いろいろなことに利用しています。このあたりの話はまたいずれ改めて会社のブログなどに書くかもしれません。

Amazon S3上のログのスキーマを管理していい感じに使うGo言語用ツールを作った

クラウドネイティブなハニーポットをAWS上に作ってみた話

テキスト出力されたログファイルから元のログフォーマットを分析するツールを作った

背景先日、会社でアニメの雑談していたときに「そういえば今時のネット配信はテレビ放映中のアニメのカバレッジってどれくらいなんだろう？」と気になりました。だいぶ配信が整備されてきたようなそうでもないような…。個人的には四半期に一度せっせと録画の準備をしたり、HDDの残り容量を気にしていろいろケアしたり、録画に失敗したりというので消耗するのはそろそろやめたかったのでなるべくならネット配信で見てしまいたい派です。ということで、現実的にどれくらいの視聴ができるのかというのを知るべく、2018年春アニメのネット配信状況をまとめて見ました。結果2018年春アニメ ネット配信一覧 - Google スプレッドシート※ 雑に作った＆後から情報が更新されることもあるようなので、間違いなどあればtwitterなどで指摘してもらえればと思います結論から言うと「完全にネット配信だけで生きていくことはできないが、頑張ればわりといける」です。まとめはある程度配信数を揃えていそうなサイトで、かつ月額定額制で（少なくともその期にやってるアニメは）定額のうちに入っているものを対象にしたつもりです。（ニコニコ、DMMなどは1週間で無料期間が終わってPay per viewになるので除外しました）バンダイチャンネルdアニメストアAamzonビデオ・プライムビデオGYAO!AbemaTV楽天TVHuluビデオマーケットNetflix以下、まとめていた時の気づき。配信数はバンダイチャンネルとdアニメストアの二大勢力。しかしそれでも30本ちょいで今季から新しく始まった72作品の半分に届いていない日中や夕方にやるような本来子供向けのアニメはあまり配信されていない傾向にある。そのためみたいコンテンツが深夜アニメ枠ならかなりがカバーされているAmazonビデオやNetflixは二大勢力には数で劣るものの、独占配信のコンテンツがいくつかある

2018年春アニメはネット配信だけで視聴できるのか

11月にSI企業からCookpadにセキュリティエンジニアとして転職して1ヶ月たったのですが、いろいろ感銘をうけたのでその気持を忘れぬうちに文章に残しておきたいと思います。disclaimer個人の主観であり、客観的にSI企業が悪いとかWeb系が良いとか言っているわけではありません。かなり前職disな話っぽくなってしまっていますが、そこは企業としての性質の違いだとご理解いただければ幸いです。当該企業からはお金を頂いています。予めあしからずご了承ください。しがらみが少ないCookpadはWeb系の中でもかなり規模が大きい方だとは思うのですが、それでも前職のグローバル含めた規模のおそらく1/1000ぐらいであり、自分にとってはとても風通しの良い体質に思えます。新しく何かを始めようとするときも、関係する人と立ち話で「こんな感じにしようと思うんだけどどうですかね」みたいなところをざっと決めて作りながら物事を進めていく…というやり方だと感じています。Rough Consensus and Running Codeという世界ですね。もちろんこの1ヶ月の間に細かい手戻りも何度かあったりしたのですが、ちゃんと合意を取りながらすすめると言ったやりかたを超えるスピード感で仕事をするのが重要と感じています。（もちろんこれは対象の規模などにもよりますが）また、サービスなどに直結するような内容でも素早く動いていくことを重視しているように感じています。前職では何かしようとするとだいたい2〜3つ以上の力学というか外圧のようなものがあり、それをまずどうにかしないといけませんでした。グループ内部ではわりと好きにやらせてもらっていたのですが、その外に出ようとした瞬間に壁を突破したり調整したりが必要でそこで疲弊してしまうことが少なくありませんでした。現職では担当者同士ですぐ話をして次のステップへ進めるというサイクルが短く回っているため、むしろ振り落とされないよう頑張ってついていかねばと思う場面も少なくありません。強いエンジニアが多いとりあえず、右を見ても左を見ても豪傑ばかりという印象です。前職でも研究所に学術的研究に秀でた方は多くいらっしゃいましたが、正直なところエンジニアリングが得意という人は全体でもかなり少なかったです。本当はエンジニアリングも得意だけど、そういうのが仕事の内容的に見えてこないというだけだったかもしれませんが、全体としてエンジニアリングにあまり積極的でない空気感を感じていました。当然ながら現職ではエンジニアリングは非常に重要な位置づけとなっており、これを蔑ろにすると（多分）人権を失います。象徴的なイベントとして、入社後にちょうど社内ISUCONが開催され私も参加させてもらったのですが、出張や休暇などでいない人を除いて全技術職が参加必須というのに驚きました。技術職と言っても様々な分野の方（インフラ、サーバサイド、フロントエンド、モバイルアプリ、研究職）がいらっしゃるわけですが、皆さんほぼ基本的な技術は一通りできるのは当たり前で、その上で自分の得意分野を活かして競技に参加していました。クックパッドの社内ISUCON始まりました pic.twitter.com/gI6ewazyzM— Issei Naruta (@mirakui) 2017年11月22日また、CTOが「今日一日業務が止まるのはとても手痛いが、それでもやる価値がある」と言っていたのがとても印象的で、ちゃんとエンジニアの育成に力を入れているんだなと思いました。セキュリティの分野についても入り組んだ攻撃や防御の話に通じている人はあまりいませんが、実践のサービス開発と運用の部分については長年の蓄積を持つ人が多く、学ばせてもらうところが多くあります。そういった環境に身を置けるというのはエンジニアとしてありがたいことだと思います。当事者意識があり、サービス・環境の改善にとても前向き自分たちが作っている・使っている環境を常に良くしていこうという文化を強く感じます。前職の場合、基本的には本社なり別部署が決めたものを（それがどんなに使いづらいものでも）言われるがままに使うというのが基本でした。規模の大きさを考えると仕組みや使うものを決める人と使う人を分けたほうが仕事が明確になって良いのでしょうが、使いづらさやだめなところがいつまでも改善されないというフラストレーションがありました。現職場では自分達が使うものを自分たちで選び、時には作るといったことをするため、常に「どうすると良くなるか？」といった方向を見ているなと感じています。これは今あるものを良くするためにも重要なことだし、その良くなったものをベースにまた次の新しいことを始めるのにも活きてきます。また、そうするべきかという議論や検討はもちろん必要ですが、ソフトウェアであれば自分で作ってしまっても良いわけで、ものづくりが好きな自分としてはそれも魅力の一つになっています。自由にオープンソースにコミットできる正直、これが一番強烈だったかもしれせん。入社する前から外部に対してアウトプットしていくことは評価にも含まれており望ましいという話は聞いていたのですが、実際にとても自由な状況でした。OSSに関するポリシーを見てみると "従業員は自分の良識に基づいて、業務時間中に開発したソフトウェアをOSSで公開できる" という説明を見つけ、あまりの神々しさに見た瞬間目が潰れるかと思いました。目がーっ！前職では知財やそれに準じる成果物が非常に厳しく管理されており、私的時間に書いたコードですらOSSとして公開あるいはcontributeするのに内部レビューと承認が必要でした。おかげでOSS的活動が好きな自分としては少なからずストレスではあったのですが、それが完全に開放され翼を授かった気持ちです。というかむしろ、前職との違いに頭がクラクラしています。おかげで、これまでgithub上でPRを送るというOSS活動に縁がなかったのですが、先日始めてPRを送りmergeされてました。実に大したことじゃないんですが、ささやかながら嬉しい気持ちになっています。今後は自分で書いているOSSだけでなく、他のOSSにも積極的に貢献していきたいと考えてます。その他あまり本質ではないのですが、その他感動したことなどをいくつか。いわゆる今時の仕組みを使った開発・運用社内で動いているシステムやフレームワークを見て「おお、これが噂に聞いたgitでconfigのバージョン管理をして自動デプロイされるというあれか…！」と感動していました。github eterpriseまでは前職でも使っていたのですが、普通にコードのバージョン管理をするだけで（それでも社内ではかなり珍しい感じでしたが）そういった今時っぽい使い方はしていませんでした。まあがっつり運用というほどではなかったので、そこまでする必要がなかったと言えばそうなんですがね…。開発マシンなどマシン自体は前職もそこまで悪くなかったですが、現職ではさらにもう一回り上のスペックになっています（MacBookPro メモリ16GB）。基本、全員が4Kディスプレイを使っています。キーボードやマウスについても、自分は最近 Realforce とLogicool G900 がベストな組み合わせなので「ちょいと値は張るけど新しく職場用に自分で買うかー」と思っていました。が、この話をしたら「いや、普通に発注してくださいよw」と言われするっと申請したらしゅっと支給されてとても感動しました。無限のコーヒーやスナックがあるまったく本質ではないし、前職にいたときもコーヒー買うお金をケチったことなどないのですが、やはり無料で供給されると思うと気分が全く違いますね。ここしばらくカフェインをコードに変換する仕事をしていました。おわりにまだ転職してからたかだか1ヶ月なのでこれから見えてくる大変なことや苦労も色々あるとは思うのですが、今のところ職務内容も含めて、転職してよかったと思える生活をしています。この記事は別にリクルート目的というわけではないので特にリンクなどは貼りませんが、現職ではセキュリティエンジニアだけでなくいろんな職種を募集しているので、興味のある方は気軽に声をかけてもらえればと思います。追記コメントとか見てたら「給与や労働時間の話がないのは闇」って書かれていて、みんなよく訓練されてるなぁと感心してしまいました。気になる方も多いと思うので一応追記しておきます。給与は前職で「独身一人暮らしが雑に出費しても貯金できる程度」もらってると書きましたが、そこからちょい上乗せするくらいもらっています。転職時にあんまり給与交渉しなかったので場合によってはもっとあがっていたかもしれません。勤務時間は基本1日8時間となっていてフレックスタイム制です。残業時間は先月で確か20時間ちょいぐらいだったと記憶していますが、これは働きはじめでいろいろ慣れていなかったこともあり、効率的にやればもっと短縮できそうではあります。

Web系企業に転職して最高だったという話をしたい

先日転職したわけですが、転職活動序盤に「そもそも情報セキュリティ関連の求人ってどういうのがあるんだろう？」と思ってばーっといろいろな職種を見渡していました。その結果、概ねこういうカテゴリの募集があるのか、という知見を得たのでまとめてみます。これから情報セキュリティ関連の職種への就職・転職を考えている人の参考になれば幸いです。なお、筆者の個人的嗜好によってバイアスがかかっている可能性は多分にあり、まったくもって網羅性を保証するものではありません。脆弱性診断自社で開発するプロダクトやサービスを検査し、脆弱性を発見する仕事。また開発物のチェックだけでなく、セキュアな開発のガイドラインを作成するというような仕事が付け加えられている場合もある。プロダクトやサービスに直接関連する開発の知識・経験が求められる。SOCオペレータサーバやネットワークを監視してセキュリティインシデントを発見・対応する仕事。非常に規模が大きい自社サービスを抱えているところでは自社内だけを対応するケース（プライベートSOC）もあるが、おおむね契約したお客さんの環境を監視するManaged Security Serivceの要員を募集している場合が多い。監視機器の環境構築・導入・保守も担当する。インシデントを発見した場合に報告するだけなのか、インシデント対応をサポートするのかなどは会社によって異なる。社内全体のリスク管理個別のプロダクトやサービスの脆弱性を検査するだけでなく、社内全体のリスク評価の実施して改善案をだしたり、インシデント発生時の演習のとりまとめをやったりする。CSIRT (Computer Security Incident Response Team) に近い業務を求められるものもある模様。かなり上級職で給与レンジも高いが、幅広く深い知識と経験が要求される感じがした。ITシステム部門（セキュリティ担当）大手日系企業などに多い。社内のIT利用を統括するIT部門においてセキュリティ関連の業務を担う。社内でIT機器を使う際のセキュリティ関連ガイドラインを作成したり、ISMSなどのレギュレーション対応、セキュリティベンダへの発注、監査対応など諸々を対応する模様。自分で手を動かしてテクニカルなことをやる場面は少なそう。インフラエンジニアIT部門とやや似ているが、どちらかというと自社サービスのアプリケーション、ミドルウェア以外の部分（OS、ネットワーク、サーバ管理など）を担当し、その中でセキュリティ業務も担当すると言った感じ。どちらかというとセキュリティはおまけ要素っぽさがある。セキュリティプロダクトベンダのテクニカルセールスやサポート外資系ベンダに多い。日本でプロダクトを売る時に導入や運用において起こる技術的な課題を解決する。またはプロダクトを導入後の問題に対して対応するようなポジション。外資系だとおそらく上司が海外にいるとか普通にあるっぽいので求人で英語力必須とある。コンサルタントお客さんのセキュリティ上の課題を洗い出し、ソリューションまでの道筋を示したりする。観測した範囲だとセキュリティ専門にやるというよりはITコンサルの中の一部の業務という感じっぽい。ここまでくるとあんまりエンジニアという枠ではないかも。その他リサーチャー：脅威分析などを専門にやるポジション。募集要項を見る限り学会などでの発表を目指すような研究者ではない（トーマツ等）セキュリティプロダクトベンダの開発エンジニア：国内で募集している例はかなり少ない（トレンドマイクロぐらい？）インシデントレスポンスチーム：まれに見かけた。自社内のインシデント対応を担当

情報セキュリティ関連の求人

2017年10月31日をもって，6年7ヶ月お世話になった日本IBMを退職します．何やってたの？最初に入社したときは研究部門（東京基礎研究所）につとめていてIBMクラウド上のログ管理のシステムやSIEM関連の開発をやっていました．2015年4月から1年半ほどIBM Tokyo SOC (Security Operation Center) で働かせていただいたのですが，いろいろな力学によって2016年9月ごろにはまた研究部門に戻っていました．研究所では，自分はどちらかというと開発よりのプロジェクトをやることが多く，実験したり論文書いたりというようなアカデミックな活動はあまりできていません．ただ，やはりまわりは一流の研究者というか超人のような人たちが多く，色々刺激されたり勉強させてもらいました．特に学生時代の研究は我流で突き進んでいたところが少なからずあったので，改めて研究のやりかたについて学べたのはありがたかったです．もともと学生時代にIDS（侵入検知システム）まわりをやっていたこともあり，SOCではその経験を活かしつつ，実際の現場ではどのようになっているかということを肌感覚として大いに学ばせてもらいました．最初の頃は純粋にアナリスト業務をやっていましたが、途中から業務効率化や分析の方が面白くなってしまい、後半はそういったツールの開発に取り組んでいました。Tokyo SOCレポート*1もほそぼそと執筆を続けさせてもらい楽しかったです．現職どうだった？素直に書いてみたいと思います．研究所は完全裁量労働で働く時間は相当な自由が効きましたが，一方で海外勢と一緒にやるプロジェクトだったりすると夜中の電話会議もそれなりの頻度でありました．個人的には給与に不満はありませんでした．独身一人暮らしが雑に出費しても貯金できる程度にもらっていました．（少なくとも自分の周りは）仕事に対しては真摯で筋の通った方が多く，直接の人間関係で困ったことなどはほぼありませんでした．非常に古く大きい企業（創業から106年，全世界で社員数40万人弱*2 ）であるため，そういった組織特有のしがらみというか壁を感じる場面は少なくなかったです．何で辞めるの？新しい経験を積みたくなった，というのが最も大きな理由です．開発に従事するのもSOCで監視をするのもそれぞれ楽しさはありますが，情報セキュリティという視点でみるとそれぞれ局所的になってしまっているなと感じていました．一口に情報セキュリティといっても，現実にやならければいけないことは多岐にわたりそれぞれが密に連携している...と思っています．今後，何か一つの技術や活動に注力するとしても，一度全体を見渡して情報セキュリティの設計・実装・運用に携わってみたいと思うようになりました．そのためには現在の会社だとどうしても「BtoBのベンダ」という立ち位置になって局所的な話になりがちになってしまうため，もっと自分が全体に責任をもって取り組めるユーザ企業でセキュリティに取り組んでみたいと思って退職を決めました．どこに行くの？11月1日よりCookpad社にてセキュリティエンジニアとしてお世話になる予定です．セキュリティ界隈でまたしばらく活動させて頂くことになるかと思いますし，アカデミック方面にもできれば関わり続けたいと思っております．本職の開発の方々には及ぶべくもありませんが，開発自体は割りと好きな方なのでセキュリティ関連で面白いものを作っていくということもやりたいですね．ということで，今後共何卒よろしくお願いいたします．*1:https://www-935.ibm.com/services/jp/ja/it-services/soc-report/*2:Wikipediaより https://ja.wikipedia.org/wiki/IBM

退職します

TL;DRとりあえず次回も使ってもいいかな，という印象使ってみたもの・環境など出張で1週間ほどUSに行くことになり，せっかくSIM free版のiPhoneを持っているのでなるべく安く済ませてみようということで日本で買えるprepaid SIMにチャレンジしてみましたwww.amazon.co.jp機種: iPhone SE (SIM free版)使った場所: NewYorkCity および White Plains周辺使ってた期間: 1週間良かった点地下鉄やトンネル内などではさすがに電波がとどかなかったが，それ以外の屋外ではほぼ問題なく使えた通信速度はとても速いとは思わないまでも，過剰なストレスを感じるほどではない．普通ホテルのWiFiと組み合わせて使ったところ，通信量は7日間でおよそ300MB強だったので容量も問題なしただし平日はほとんど仕事でつかっておらず，日中もフルで使ったのは土日だけなので1週間観光であちこち行くとかだと若干心もとないかも追加容量プラン（"top up"）もあるので必要に応じて追加金できる良くなかった点このSIMに限った話ではないのかもしれないが，屋内が比較的弱い．例えばJFK空港内とかはかろうじて通信できるが不安定「SIMを指してから5分以内にSMSでUSの郵便番号（ZIP code）を送るとその地域の電話番号が割り振られる」という説明だったのに，指した瞬間にSMSが飛んできて勝手に番号が割り当てられた．まあ通話使わないのでそんなに困らなかったけど・・tipsAPNの設定を変更する必要がある普段IIJ mioを使っているのだがちゃんとプロファイルを削除しないと競合して上手く動かないAPNの設定をしたあと一度iPhoneを再起動したらデータ通信できるようになった

ZIP SIM使ってみた@ニューヨーク

悪意のあるドメイン名のブラックリストを取得・管理する mdstore というツールを作って公開しました。github.com世の中にはフィッシング詐欺やマルウェアによる攻撃に使われるドメイン名のブラックリストを公開しているサービスがいくつかあります（参考）。近年はDGA(Domain Generation Algorithm)を利用したマルウェアもあるためブラックリスト化だけでは追いつかない場合もありますが、それでも既知の攻撃に利用されるドメイン名の名前解決を発見もしくは防止できれば、水際で攻撃による被害を食い止められる可能性があります。ただ、このようなブラックリストは提供しているサイトによってカバーしている領域などが違うため、ブラックリストごとに違うドメインが扱われています。多くのドメインを網羅しようとすると複数のサイトからデータを取得する必要がありますが、フォーマットが異なるなどの理由から一手間必要です。このツールは複数のブラックリストをローカルにダウンロードし、DBに投げ入れて管理・利用することで、この一手間を簡略化しようというものです。2017年1月7日現在、以下の3サイトからデータを取得します。DNS-BH – Malware Domain Blocklist: BH DNS Files, Terms of UseMVPS: Blocking Unwanted Connections with a Hosts FilehpHosts: Download, End User Licence Agreement注意：ブラックリストを提供している各サイトの利用規約では基本的にinternalな利用は認めているようですが、特に商用利用などをする場合には詳細をご自身でよく確認してください。使い方セットアップ本ツールはnodeで動作し、redisにデータを格納します。動作を確認しているバージョンは以下のとおりです。node: v7.2.1, v6.0, v6.1redis: v3.2.6インストールは環境に合わせてよしなにやってください。その後、npmを使ってmdstoreをインストールします。$ npm install -g mdstoreパスを通すのが面倒でなければカレントディレクトリへのインストール（上記コマンドから-g を抜く）でも問題ありません。さらにツール利用前にredis-serverが動作していることを確認してください。install mdstore by npm npm install -g mdstorestart redis server, e.g. redis-server &またデフォルトのredis server接続先 (localhost, port 6379, db 0) 以外を使いたい場合はオプションで指定できます。-s or --host: redis server host-p or --port: redis server port-d or --db: redis server dbブラックリストの更新update コマンドを使うことで各サイトのブラックリストをダウンロードし、DBへの格納までを実施します。すでに対象のドメイン名が存在する場合は、取得したという履歴が追記されます。現在サポートしているサイトは3サイトだけですが、hpHostsが特に件数が多いため完了までに2〜3分かかります。$ mdstore updateupdate: OKドメインを探すget コマンドを使うことであるドメイン名が存在するかどうかを調べることができます。下記では例として 151.ru というドメイン名が存在しているかどうかをクエリしています。% mdstore get 151.ru2017-01-06T14:44:05.347Z { source: 'hphosts', ts: 1483713845.347 }左のカラムが対象となるブラックリストをダウンロードした時刻になります。右側のtsのフィールドがタイムスタンプでこれをDateに変換したものです。ドメイン名がブラックリストに追加された時刻ではない点に注意してもらえればと思います。sourceはブラックリストの取得元を表しており、hphosts、dnsbh、mvpsのように表示されます。その他、データの取得元で掲載されている項目に応じて追加のメタ情報が表示されます。/etc/hosts の生成ローカルのredisに保存してあるデータをもとに、悪意のあるドメイン名を 127.0.0.1 に強制的に変換する /etc/hosts を生成します。これを /etc/hosts と置き換えることで悪意のあるサーバと通信する可能性を低減させることができます。$ mdstore hosts > hosts.txt$ head hosts.txt127.0.0.1       localhost::1     localhost127.0.0.1       www.wwsupport.net127.0.0.1       www.memdesign.co.uk127.0.0.1       www.titanweb.net127.0.0.1       www.livingston.rs127.0.0.1       iphonesupport.co.uk127.0.0.1       up1702.info127.0.0.1       dcstest.wtlive.com127.0.0.1       ad.doubleclick.net.34325.9225.302br.net$ sudo cp hosts.txt /etc/hosts         # Linuxの場合$ sudo cp hosts.txt /private/etc/hosts # macOSの場合データへのアクセスCLIでアクセスする以外には、ローカルのredisに格納したデータはmdstoreのライブラリを使って参照することができます。以下のようなnodeのコードでアクセスできます。DNSの問い合わせログを持っている場合、自分でコードを書くことで不審なサイトへのアクセスがなかったかを確認できます。var mdstore = new (require('mdstore')).Redis();mdstore.update((err) => {  // synced        mdstore.get('is.the.domain.malicious.com', (err, res) => {          if (res.length > 0) {                  console.log('yes, the domain name is malicious');          } else {                  console.log('no, this is benign');                }        });});また、当然ですがredis serverに直接クエリすることも可能です。ただし、履歴データはMessagePackでエンコードされているので直接人間が読むのはちょっと難しいです。一応、以下のような1 linerで表示させることはできます。$ redis-cli --raw lindex 151.ru 0 | node -e "process.stdin.pipe(require('msgpack-lite').createDecodeStream()).on('data', console.log);"

悪意のあるドメイン名のブラックリストをまとめて取得・管理するツール mdstore を公開しました

1月ごろ事前予約開始したのを偶然知り、9万円以上という値段に一瞬たじろぎながらも完全にノリと勢いだけで注文したOculus Riftがついに先週自宅に届いたのですが、この一週間毎日遊んだ感想をまとめておきたいと思います。ひとことで言うと、自分がこの十年の間に触ったガジェットの中では最高に興奮しました。やばい。Oculus Riftやばい。ご存じない方のために念のため説明しておくと、Oculus RiftはHMD（ヘッドマウントディスプレイ）の一種です。これまでのHMDは頭を動かすと自分の頭についているHMD本体も一緒に動くため、映像も一緒に動いてしまうので単純に「頭に普通のディスプレイをくっつけているだけ」に等しい状態でした。しかしOculus Riftは内部・外部にセンサーがあり「頭を動かすと見えている映像も追随して動く」という機能を実現しています。このような製品は総称してVR（バーチャルリアリティ）HMDなどと呼ばれており、HTC ViveやPlayStation VRもその仲間です。どういうことが起きるのかの雰囲気は以下の動画からどうぞ。www.youtube.comまず総評自分の語彙のなさが歯がゆいのですが、とにかくまず言えることは没入感が半端なくすごいです。センサーで頭の動きを追跡して映像を追随させる、と言われると「どうせ微妙に位置がずれたり反応がぶれたりするんでしょう？」と思うかもしれません。というか、自分自身がそう思っていたのですが、使ってみると完璧と言って差し支えないほどの精度で映像が動くという点に驚愕しました。格ゲーをやりこんでいるような人だとフレームレートの違いが認識できるらしいので、そのレベルになるとひょっとしたら違和感を感じるのかもしれませんが、私のような一般人にしてみると映像の動きはリアルと全く変わらないと感じました。一人称視点の映像だと完全にその世界に入りこんで「どこだここ！？」みたいになります。もう一つすごいと思ったのはコンテンツの可能性の幅の広さです（コンテンツそのものの量はまだそれほど多くない）。今までVRはゲームに使うものだよね的な議論が多かったような気がしていますが、思った以上にいろいろな分野で応用できるのではないかと感じました。ゲームも一人称視点のものに限られるかと考えていたのですが、三人称視点のゲームとかシムシティのようなシミュレーションゲーム、あるいはリアルタイム戦略ゲーム（RTS）にも応用できる可能性があります。詳しくは後述。とにかくこればかりはいくら言葉で語っても伝わらないかもしれないので、ひとりでも多くの人に体験してもらえればと思う次第です。やってみたコンテンツここからは実際に自分がさわってみたゲームと感想をつらつらと載せていきます。EVE: Valkyriewww.youtube.com一人称視点のシューティングゲームです。有名どころで言うとエースコンバットみたいな感じですね。ゲームとしては昔からあるようなものなのですが、Oculus Riftによる没入感で「俺、パイロットになってる！！」感が味わえます。最初に発進で射出される場面などは思わず「うわあああああ」って声がもれてしまうような迫力ですし、右や左、さらには後ろをみても宇宙空間が広がっており、完全に気分はマクロスとか宇宙戦艦ヤマトの戦闘機です。これでロボットだったらガンダムだったんだが、、、と思うところではありますが、間違いなく近々ロボット版をどこかが開発・発売すると確信できるほどロボットものとVRは相性がいいと思わせてくれるゲームでもあります。グラフィックスも綺麗なので、迫力があって楽しいです。ゲームとしては3次元空間を飛び回って敵を撃墜したりしていくのですが、プレイとしての大きな違いは視野の大きさと視点移動の概念が大きく変わった点でしょう。Oculus Riftは視野角が100〜110度あるらしいので、格段に目でとらえることができる範囲が広がっています。さらには視点も現実と同じ感覚で動かせるので、レーダーだけに頼らず360度敵を目で追いながら戦うということができます。レーダー機能ももちろなるのですが、近距離で高速旋回する相手のユニットを目で追いながら戦えるだけで全然違う体験でした。単純にゲーム性としてはだいぶ難しくてまだ撃墜されるばかりなのですが、毎日こつこつやっています。全体的にみるとこれまでプレイした中で一番完成度が高いゲームだと感じています。Lucky's Talewww.youtube.com3D空間でキャラクターを動かしてステージをクリアしていく、いわゆるNINTENDO 64やゲームキューブのマリオに近いゲームです。三人称視点なんだから別にこんなHMDつけてやらなくても、と思うかもしれませんが、自分の目の前にそのフィールドそのものがあるというのは想像以上の新鮮さを与えてくれました。いってみれば、自分の机の上に箱庭があって、そこでキャラクターを動かしているような感じでプレイができます。ゲーム性でみても単純にキャラクターを動かしてステージをクリアしていくだけなんですが、これがVR視点になったとたん思った以上に楽しい。マリオなどの視点移動もかなりよく出来ていたとは思いますが、これをプレイすると今まで3Dの三人称視点のゲームでどれだけ視点移動・調整にストレスを感じていたのか気付かされます。あと、これはゲームやコンテンツによって違うので一概には言えないようですが、このゲームではいわゆる「覗き込み」ができます。つまり体を乗り出すことによって建物の裏側にあるアイテムが見えたり、体を動かして少し先にあるステージの状況が見えたりします。なので自分が動きながら「何かを探す」というアクションができ、ゲームの幅が広がるなと感じました。このあたりは本来は広い空間を動きまわることを想定したHTC Viveの方が強いのかもしれませんが、Oculus Riftでも十分に仮想空間を感じ取れました。また、このような「箱庭のようなものを三人称視点で見ながらゲーム」というコンテンツがVRで成り立つとすると、かなりいろいろなジャンルに応用ができるのではと思います。例えばシムシティのようなシミュレーションであっても、自分が作った街を上空から覗き込みながらプレイするというやりかただと違った楽しみ方が生まれると思います。さらにVR HMDと組み合わせて使うVR用グローブも開発中のようなので、シムシティでも模型を置いたり取り除いたりするような感覚で街を作る、というようなインターフェースも実現できると考えられます。他にもリアルタイム戦略シミュレーション（RTS、エイジ・オブ・エンパイア シリーズ、StarCraftシリーズなど）も、これまではマウスを使ってユニットや建造物の操作をしていましたが、例えばイメージとしては動くミニチュアを手で操作しながら戦わせる、というようなインターフェースも考えられると思います。さらにはオンラインのカードゲーム（HearthStoneなど）であっても、本当に対戦相手と対峙しているかのような空間でプレイでき、FaceRigのような技術と組み合わせれば「対面にいるのはゲームキャラクターなんだけどちゃんと対戦相手の表情が伝わってくる」というようなゲーム空間が作り出せます。（それでプレイヤーが楽しくなるかキレやすくなるかは難しいところですが 苦笑）www.youtube.comなにはともあれ、そういった観点から新鮮な驚きを与えてくれるゲームでした。Windlandswww.youtube.comこちらは一人称視点で飛んだり跳ねたりしてステージを進んでいくタイプのアクションゲームです。ワイヤーのようなものを木に引っ掛けながら飛び回るのが特徴です。古い人間なんでゼルダの伝説のフックショットみたいなもの、というのをまず連想したのですが、スパイダーマンの蜘蛛の糸や進撃の巨人にでてくる立体機動装置をつかって飛び回る…といったほうがイメージとして近いかもしれません。このゲームはHTC Viveだと両手でそれぞれ持つ専用インターフェースを使ってプレイするようなのですが、Oculus RiftでもXbox用のコントローラで普通にプレイできます。一人称視点のアクションゲームであり、（ちょいグラフックは雑な感じがするものの）世界を冒険するみたいな感じのプレイ内容になっており、まさにVRの本懐！といったようなゲームなのですが、実際のところ個人的にはこれが一番激しく酔って辛かったです。VRに限らずこの手のアクションゲームではよくあることですが、プレーヤーに人間離れした跳躍力があるため激しく飛んで激しく落ちていきます。ゲーム性の点からは別に不自然でもなんでもないのですが、リアルな映像として脳に入ってくると「視覚は動いていると言っているのに、体は動いてない（加速度を感じない）よ？」ということになり、お脳が混乱します。万人が同じ感想を持つかわかりませんが、夢のなかで落下しているという状況に近い気持ち悪さがあります。また、EVE: Valkyrieのような広い空間を高速に移動するのではなく、床や壁などがかなり近くにあり、「視覚が移動している」ということを強烈に認識しやすいことも原因だと思います。ひっとしたらジェットコースターとかが好きな人だとわりと大丈夫なのかもしれません（自分はジェットコースター駄目派です）。あと、飛ぶだけではなく落下を繰り返すということもあって緊張しているのか、このゲームだけめちゃくちゃ手汗をかきました。ということで、体験としてはなかなかおもしろいのですが圧倒的に消耗が激しく、自分は1日あたり20分くらいのプレイが限界でした。でも刺激的です。動画再生・デスクトップ表示アプリこのあたりを試してみました。BigScreen (Beta)CINEVEOVideo (Oculus)Whirligigwww.youtube.comWindowsのデスクトップそのものやただの動画をVR上の空間に投影するだけのアプリケーションなのですが、これもまたいろいろと可能性を感じます。これまで、VRではないHMDを使った動画再生は映画館のような迫力があると言われつつも、頭を動かすと画像も動いてしまう違和感があり微妙と言われてきた気がします。これらのアプリケーションはデスクトップや動画を仮想空間にうかぶ空中ディスプレイのように表示したり、仮想空間上の壁面に投影したりします。例えばCINEVEOは映画館での上映を模したVR空間に動画をスクリーン投影しますが、Oculus Riftの没入感に加えてわざわざ映像の光が壁に反射するのを再現していたり、当然ながら頭を動かせば他のお客さんが見える、といった演出から本当に映画館にいるような錯覚を覚えます。http://www.mindprobelabs.com/cineveo_themes.htmlよりCINEVEOはmp4などの動画ファイルを用意する必要がありますが、BigScreenはデスクトップの映像をそのまま表示するので、直接VRに対応していないWeb系のストリーミングサービス（ニコ動、バンダイチャンネル、AbemaTVなど）でも映画館のような環境で再生可能です。また、Whirligigは魚眼レンズ x 2で撮影したような動画を擬似的な3DとしてOculus RIftで見ることができます（この場合、映像の範囲は前方180度に限られていました）空中ディスプレイにデスクトップが移るので、攻殻機動隊の電脳世界のようにこれで作業できたらカッコいいのに…！と思ったのですが、解像度があまりよくないという問題（後述します）があるため、例えば空中ディスプレイ上でコードを書くというのは現状かなり厳しいのではという状況です。ただ、先述したVRグローブ等と組み合わせることで新しいユーザインターフェースが期待できるため、あるいは現在マウスでやっているようなアプリケーションの作業をVRに置き換えるという時代は来るかもしれません。その他その他に以下のようなゲームを試してみました。InCell VRInMind VRwww.youtube.comそれぞれVRのサンプルのような位置づけのコンテンツです。ゲーム性は大してないのですが「VRで仮想空間を高速移動する」という体験ができます。MIND Pathwww.youtube.comあまりのホラー感に開始3分で音を上げました（お化け屋敷ダメです）これは別にホラーというわけではないのですが、あまりに没入感すごいので、暗い屋敷みたいな空間でいきなりゾンビとかが脅かしにでてきたら心臓が止まる自信があります。今後も自分はホラー系をプレイしないですが、逆に好きな人には最高だと思います。www.youtube.comMocuMocuDanceMMDのモデルを表示するソフト。まじかで見る等身大ミクさんかわいいです。Leap motionと組み合わせてボーンの操作ができるようで、はやくも手の動きをセンスするインターフェースとの組み合わせの良さを見せてくれています。Oculus Riftの課題さて、散々持ち上げた後でなんですが…ぶっちゃけ結構いろいろな課題があると思います。お値段非常に高価だと思います。まず本体が送料込みで94,600円、さらに接続先のPCの最低推奨スペックとしてCPU i5-4590＋Graphci Card: NVIDIA GTX970以上を要求してくるので、コアPCゲーマでもないかぎりは少なく見積もっても10万強のPCに買い換える必要があります。よって現状では合計20万円以上の初期投資が必要であり、なかなかハードルが高いというのは否めません。画質がいまいち没入感すごい！という話をさせてもらったのですが、よくよく画面をじーっと見つめると結構粗が目立つ解像度として見えます。screen-door effect（網戸効果）というらしいのですが、そもそもディスプレイ部分に眼球が近すぎるため本来の解像度より粗く見えてしまうようです。そういう意味ではふと画像の粗さに気づいて「あ、仮想空間なんだな」と時々思い出すレベルになっています。逆に高い解像度で見えるようになったら現実より現実っぽい仮想空間ができあがるのではと思うので、今後の技術の向上に期待です。メガネ当方完全にメガネ野郎なので結構深刻な問題です。構造的には顔に密着するようになっているため、持っているメガネを無理やり装着しようとするとすべからくフレームがへしゃげそうになり、そのまま使うのを断念しました。結局どうしたかというと、ひとまずは昔のメガネを分解してレンズの前におき、無理くり対応しています。いろいろな対応策が考えられてはいるようですが、個人的には生まれて初めてコンタクトレンズの購入を検討しているところです。こんな感じ。意外と置いただけでもまあまあなんとかなる。酔う正直なところ、これが最大の問題だと思います。Windlandsの解説でも書いた通り、そもそも移動がともなうコンテンツだと「視覚情報では加速度がかかっているはずの状態なのに体は加速度を感じていない」というミスマッチが必ずおきるので、体に負担？がかかっているような気がしてきます。ここ数年乗り物酔いや普通のディスプレイでFPSとかのゲームをやって一切酔ったことがない自分でも、ものによっては1時間ぐらいでちょっとキツくなってきます。これはもう人類が進化して三半規管とかがそういう視覚情報と体感加速度のギャップとかに対応するとかしないといけないのかもしれませんが、どうにか解消してくれないかなぁと思う点ではあります。まとめ買いか買いじゃないか、と聞かれたらまだ普及期には至っていない、というのが正直な感想です。お値段＋諸問題と得られる効果を考えるとちょっと面白そう、というノリで買えるおもちゃではないと思います。しかし、個人的には十分なインパクトがありVRの可能性を大いに実感できる製品だったことは間違いありません。例えるなら、1980年代に給料一月分ぐらいするようなコンピュータを一部のマニア層だけが買って、可能性を感じながらもほそぼそといじっていた黎明期に近いと思います。このOculus Riftが現行の値段・性能でそのまま普及するとは自分も思いませんが、5年後、あるいは10年後にVRというものがなんらかの形で社会の一部で使われているだろう、ということは確信できます。ということで、Oculus RiftにかぎらずHTC ViveでもPlayStation VRでもいいのですが、ぜひこれらの製品に触れられる機会があれば一度体験することをお勧めします！

Oculus Riftはいいぞ。最高だ

www.recomtank.comちょうど職場でも新しいメンバーの教育問題がいろいろ議論されているところで、この記事を見て思ったこともいくらかあったのでつらつら書きなぐってみます。上の人がみんな「俺は見て覚えた」というのは生存者バイアス（の可能性が高い）どことは言いませんが、マニュアル化された教育法がない世界では確かに「自分は先輩を見て覚えた。だからお前もそうしろ」という言説をよく見かけます。できる上の人達はみんな口をそろえて言うため、それに従えば自分もできる人になれるのか、と思ったり思い込んだりしてします。しかしそれは「上を目指していた人たちが全員そのように上へあがっていた」のではなく「そのような教育方法でも生き残った人たち」なのであり、ただの生存者バイアスに過ぎません。そのやり方についていけなかった人たちがその組織・業界を去っていった結果、残った人たちなのであって、その後ろには屍の山が築かれています。個人的な経験の中でもそういった人たちをいろいろな場面で見てきました。育てたい人物像をイメージ出来ているか『最初から教えてばかりだと、考える能力が身につかない』という論もあり、この言葉が完全に間違いではないと思います。ただ、まずこれは程度問題であり、育てたい人物像と設定するハードルの高さのバランスを考える必要があると思います。例えば本当の超少数精鋭を育てたいのであれば、ほぼ突き放してついてこれた人だけがその組織・業界に残る、ということもあり得ると思います。ただし先程も書いた通り、その後ろには山のような屍が築かれ、その道を志した100人に1人とか、もっとひどければ10000人に1人しか残らない、みたいな話もありえると思います。HxHのハンター試験みたいなものです。貪欲に自分で学習し、人のスキルなどを盗んでいく超逸材だけが残っていくことでしょう。ただし、このモデルは本当に人数を増やす必要が無い場合か、それだけ厳しい道でも志願する人が後を絶たない、といったような状況でなければ成立しないでしょう。一方で超逸材がいなくてもいいが（いてもいいけど）仕事として100点満点中80点をちゃんととれる人が増えてほしい、という場合だと、全て「自分で勝手に学べ」モデルは非常に相性が悪いと思われます。一般的な企業や組織はほとんどがこちらに該当すると思われます。特に事業などの規模を拡大させたい場合は100人雇って1人しかものになりませんでした、では話になりません。こういった場合は先のブログで書かれていた通り、マニュアル化された作業手順や教育方法があってしかるべきだと考えます。そもそも「マニュアル化できない」とはどういうことなのかちょっと自分のいる業界に偏ってしまいますが、基本的にマニュアル化できない仕事というのは、人によって過程や結果が異なることを許容する 仕事だと考えられます。以下、その例をあげてみます。何かを自ら創造するような仕事（システム・ソフトウェア設計、新しい企画の立案）前提条件の想定が難しく条件の組み合わせも複雑であり、条件の網羅が困難なもの（トラブルシューティング、インシデントレスポンス）試行錯誤しながら進めないといけないもの（新しい機器の検証、探索的データ分析）確かに上記のような仕事について全てマニュアル化するのはかなり難しいとは思います。しかし、全てをマニュアル化するのは難しいとしても、部分的にはいろいろマニュアル化（ないしは定型的な教育によって身につけた手順によってできるもの）できそうではないでしょうか？ 例えばソフトウェアの設計などはどのような道筋でやるべきかという教本はいろいろありますし、トラブルシューティングでもまずはこれをチェックしろ、みたいな初動のマニュアルは作成できそうです。最終的に人間が考え、発想し、創造する必要のある仕事は確実にあると思います。しかしそのためには、どこからが機械的に作業して（あるいはもう機械に作業させてもいいわけで）どこからが人間の判断の力を発揮しなければいけないか、という線引をすることが重要なのではと思います。あと、基礎力の必要性などについてもちょっと書きたかったですが、夜更かしが過ぎてきたのでこの辺で。

『見て覚えろ』の後ろには屍の山がある

前回からの続き。ちょうど経団連的新卒採用プロセスがはじまったということで、博士課程をしている後輩によく話していることをまとめました。この話は私が経験した情報科学系のごく狭い範囲の知見を元に書いていますが、現在博士課程の人やこれから博士課程に進もうと考えている人の参考になれば幸いです。また、主に企業への就職を中心に話をします。前回は就職先の選び方について書きましたが、では実際に就職しよう！として動き出した時にどういうアプローチで内定をもらうか、という部分についてです。1) 新卒採用プロセスに乗る、2) 中途枠・オープンポジションを狙う、3) つてを頼る という三本立てでお送りします。1) 新卒向け採用プロセスに乗るいわゆる説明会に参加して、エントリーシートをだし、何度か面接を経て採用、という学部生や修士生と同じパターンです。博士の場合は例外扱いになるケースも有りますが、こういった新卒採用プロセスを持っている会社の場合はだいたいそこに組み込まれることが多いと思います。細かい対策については学部や修士のものとほぼ変わらないのでSPI対策本などを読んでおく感じでしょう。時期的な制約が強いこのアプローチで気をつけなければいけないのは、プロセスに乗れる時期が1年のうちに限られているという点です。2017年卒の場合は2016年6月から採用試験がはじまるので、2017年3月に卒業することを前提に2016年6月から就職活動をはじめなければなりません。学部や修士過程では単位を落とすなどのミスをしないかぎりは決まった時期に卒業できるので「お前は何を言っているんだ」という感じかもしれませんが、ほぼ学内で卒業までが完結する学部や修士と違い、博士課程の卒業審査は学外の要素がからんでくるため、卒業時期が不安定になりやすいというリスクがあります。博士課程の在籍経験がある人はよくご存知かと思いますが、博士過程を卒業するためには研究をして博士論文を書くだけではなく、論文誌への掲載や国際学会での発表という要件が明示的・暗黙的かを問わず存在します。論文誌や国際学会での採択は学内でコントロールできるものではなく、外部の査読者に掲載や発表を了承してもらわなければなりません。これは容易なことではなく、1度の投稿には構想・実験・論文執筆に数ヶ月を要しますし、下手をすると何度投稿しても掲載・発表拒否となることもあります。こういったものが卒業条件（あるいは卒業を決めるためのプロセスの条件）に加わることで希望通りの時期に卒業できないというケースが起こりえます。そのためこの新卒向けプロセスに乗る場合、（例えば2017年卒予定だとすれば）2016年6月には論文誌や国際発表が完了・あるいは見通しが立っている状態にして、6月からは就職活動に時間を割き、その後に研究まとめ、博士論文執筆や発表をこなすということを手際よく進め、2017年3月にちゃんと卒業する、というところまでをやりとげなければなりません。採用プロセスの課程が分かりやすいこのアプローチは時期の制約が厳しい代わりに、採用プロセスが比較的分かりやすいと言えます。中途枠や例外的な扱いになると他に参考事例が無いので、自分が今どういう状況に立っているのか（採用が進んでいるのか停滞しているのか）ということが不明瞭になりがちです。これが（ある程度大きい企業に限るかもですが）新卒採用のプロセスになると同じプロセスをやっている別の学生が一定数以上いることになります。就職希望の他の学生の方と状況をシェアできることもあるかもしれませんし、過去の事例からおおよその状況を把握できます。あくまで自分の立ち位置がわかるという程度のものですが、戦略的に複数の企業の採用面接を受けている時にはメリットになると考えられます。2) 中途枠・オープンポジションを狙う外資やベンチャーだと、そもそもあまり体系だてて新卒採用を実施しておらず、誰でも応募できるオープンポジションという形で募集をしているケースが多く見られます。また日本企業でも中途採用という形で新卒以外の採用希望者を雇用しているため、そこから採用プロセスに乗せてもらうというアプローチがあります。業務内容が明確で採用プロセスも比較的柔軟中途枠・オープンポジションはそれぞれ求められる技能や採用後の業務内容について、ほとんど事前に明示的に説明されています。前回でも少し書きましたが、新卒採用プロセスによる就職は採用後の業務内容が明示されないケースが少なからずあります。また、例えば面接中に口頭で説明されれる場合もありますが、所詮は口約束なので会社の都合によっていつの間にかに変わっている場合もあります。もちろん会社都合による業務の内容は中途枠・オープンポジションでも発生する可能性はありますが、最初から業務内容が曖昧な採用プロセスと明確なプロセスでは対応が違ってくると思われます。また、面接・雇用タイミングの融通がききやすいというアドバンテージもあります。先述の通り、新卒採用のプロセスでは面接などの時期が限られており、内定、ないしは内々定から実際の雇用までにかなり期間があります。経団連の施策によってかなり後ろだおしされたものの、それでも約半年ほどの差があります。それに対して中途やオープンポジションの場合は採用決定後、かなり早い時期で雇用が始まると聞いています。そのため、例えば博士号の審査に関するどたばたも終わり、卒業までのいくらかの期間の間に就職活動をして就職する、というような流れもありえます。タイミングよく求職している業務経験者じゃあ新卒プロセスは忘れて、中途枠・オープンポジションを狙うのがいいのか？という話になりますが、もちろんデメリットもあります。まず、中途枠やオープンポジションでは「業務経験者」を条件にしている場合が多く、そのケースでは博士課程卒はこれに該当するのか？という問題があります。博士課程での専門にマッチしていれば下手な業務経験者よりも技術的な面については優っているケースは多々あると思います。また、博士課程の学生でも研究プロジェクトをまわす経験があるのだからそういった面でも業務と比べて遜色ない、と主張する方もいらっしゃします。ただ、自分も博士課程を卒業して企業に就職して5年ほどたった今考えても、やはり経験の質は若干違うと感じています。特に中途枠という設定の窓口に多いと思いますが、そういったことを採用担当の方が懸念される場合は「新卒採用の窓口があるのでそちらからどうぞ」と突っ返されるリスクがあります。また、受けたいときに受けられる可能性が高い事と、受けたいときに希望する職種を募集しているかというのは全く別問題になります。企業側としていつでも採用希望を受け入れるということは（適切な人材がいれば）早く採用して働き始めてほしいということの裏返しでもあります。追加で募集するということもありますが、多くの場合は人が見つかればその募集は打ち切ることになるので、この辺りの動きはかなり流動的です。また企業側の方針転換などで誰も採用しないままの打ち切りということもありえます。自分の希望する企業の希望する職種が都合の良い時期に募集しているかは完全に運である、というところにリスクがあります。3) つてを頼る前述の中途枠を狙う、に若干近いところがありますが、知り合いの会社の中の人経由で採用面接をうけさせてもらうケースです。博士課程の学生となると企業とのプロジェクトや学会参加などでその人なりの人脈を築いている場合が多いと思います。そういった人たちに紹介してもらい、面接を受けさせてもらいます。多くの場合、紹介してもらう人に人事権がなかったりするので、紹介＝即採用みたいにはならない（というかそのケースはヤバイ）のですが、いくつか中途採用やオープンポジションに比べて有利な点があります。面接にたどり着きやすい、というアドバンテージ外資系に多いパターンだと思いますが、レジュメだけ登録させて「空きができたら会社から連絡を出すね」というのを見かけます。こういうのは大手ほど大量のレジュメが登録されることになるので、特別な業績などあれば別でしょうが、待てども待てども連絡がこないのはざらです。その点、紹介の場合は比較的面接プロセスまではたどり着きやすく、同じような内容が書かれた大量のレジュメの中から選ばれるのを待つよりは、面接官に直接自分をアピールできるチャンスが得やすいと言えます。これは採用する側からも、どこのだれだかわからない応募者より、同じ会社で働く社員の紹介のほうが安心感があります。そのため、大企業でも応募者が面接をパスして入社したら紹介した人に褒賞がでる紹介制度がある、という話をよく聞きます。一朝一夕ではどうにもならないつてを頼る時の難しさは、当然ですが自分の人脈を学生時代どれくらい築けたかによって頼れる範囲が変わってくることです。これは少なくとも大学の研究室などに所属してからどのように活動してきたか、すなわち対外発表や外部講演、勉強会での交流などをどれくらい積極的にこなしてきたかということに依存します。そのためそれなりに長い期間がかかっていることが重要であり、エントリーシートのように今日明日で何十社にアプローチできるというものではありません。自分の状況・ペースにあわせた就活を長々と書きましたが、結局のところ博士課程にいる時点でいわゆる「みんなで足並み揃えて」何かをするという道からは外れていると思います。それぞれ学生さんごとに状況・ペースが違うので、いろいろなやり方のメリット・デメリットを勘案して自分にあった方法を選ぶと良いと思います。

博士の愛した就活（採用プロセス編） 

タイトルは思いつきです。博士課程にいる後輩によく話していることをまとめました。この話は私が経験した情報科学系のごく狭い範囲の知見を元に書いていますが、現在博士課程の人やこれから博士課程に進もうと考えている人の参考になれば幸いです。また、企業への就職を中心に話をします。博士課程を修了した後に企業への就職を考えている場合、企業を選択するにあたって以下のことをチェックするとよいのでは、という点をまとめてみました。就職後の業務は明確か？就職したとして自分の専門を活かした仕事ができるかというのは、その会社の採用形態によって異なります。外資系などの場合は新卒採用の場合でもある程度は業務内容を明確にしたうえで募集しているところが多いと思います。さらにオープンポジションのような形式で募集している場合は、より具体的に業務内容が明示されていることが多く、自分の専門が活かせるかどうかということについて判断しやすいでしょう。逆に日本企業の場合は「とりあえずとるだけとって後から事業部や部署に振り分ける」という形式をとっているところが比較的多い印象です。こういう場合、自分が専門でやっていた分野を得意とする企業であっても研究職などにはつけず、営業など研究開発とは遠い部門へ配属されるということも普通にありえます。特に日本企業では定期的に部門を移っていくことでキャリアアップするといった、官僚のシステムに近い会社もあるようです。いろいろなことを広く経験したい、という方にとってはそういうシステムはいいのかもしれませんが、博士に進んだ人で自分の専門をずっとやっていたい、という方にとってはミスマッチになる可能性があります。そういう観点から就職後、どのようなキャリアパスが用意されているかということも確認しておくのがよいでしょう。会社として博士号を評価してくれるか？血の滲むような思いをしてとった博士号を評価してくれるかどうかというのは、博士課程の学生にとって重要な関心事だと思います。残念ながら、企業によっては博士号をプラスに捉えてもらえないどころか、マイナスの評価になる場合すらあります。博士号を持っている人は専門指向の強い人と捉えられがちなので、ポジションとのミスマッチがあるとそれがマイナスイメージに働くことがあります。また、単純に学部生に比べて歳を重ねているという現実もあり、新卒採用主義の企業からすると敬遠されやすい傾向があります。企業によっては正規ルートでは博士の学生は就職できないということすら聞いたことがあるため、もし博士課程後に特定の企業へ就職しようと考えている学生さんがいらっしゃる場合、事前に確認しておくべきです。しかし一方で博士号をプラスに評価してくれる企業もあります。主観的な意見ですが、やはり外資系やベンチャー企業などに多いと思います。博士号取得の過程ではある分野への専門性だけではなく、他分野にも応用が効く問題発見・設定や解決能力などが養われるので、そういった点を見てもらえるようであれば採用に対しても有利に働く面があると思います。給与面での優遇はあるか？また採用過程だけでなく、給与面に反映があるかも重要な点です。学部卒と修士卒で給与がわかれているというケースは多く見かけますが、博士卒に対して給与面での優遇がある企業もまれに見かけます。博士卒の給与が書かれていない企業は、そもそも博士の応募が少ないので例外的な扱いになっており給与面については応相談な場合と、そもそも修士と同じ扱いである場合があるかと思います。博士課程は在籍中に毎年学費を払わなければなりませんし、就職すればそれだけ給与を稼げたであろう3年以上の在籍期間を消費しています。就職に際して給与が全てとは思いませんが、給与は会社に対する貢献へのフィードバックの一つの形ではあるため、給与が修士卒と同じということは、博士号についてはあまり評価してくれていないと考えるのが自然かもしれません。また、働いた経験がないと実感しにくいと思いますが、給与というのは同じ会社で働き続けるにしても後から転職するにしても、最初の年収というのが後々に響いてきます。昇給は元の給与に対してN%加算みたいな形式になるかと思いますし、転職するにしても元の給与に+N百万みたいな形で増えれば上々、普通はほぼ同額、みたいになると噂に聞きます（これは業界によって大きく違うかもしれませんが）。あまり給与だけみて就職先を決めても不幸になることが多々ありそうですが、その一方で給与を甘く見ない、ということも非常に重要です。全く違う分野を考える場合上記3点は自分の専門をある程度意識した就職の話になりますが、全く違う分野を考える場合は年齢がやはり重要なポイントになってきます。学部卒と比べると通常で約5年、在籍期間が長ければそれ以上の差がついています。年齢が上になった人が全て新しいことを学ぶのに不向きだということはありませんが、経験則的には年齢が若い方が学習にも意欲的で飲み込みも早いという側面はあります。そういったことから採用に不利になったり、新卒採用に対してそもそも年齢制限が加えられるというケースもあります。博士課程はこじらせると6年、あるいはそれ以上かかるケースがあり、その場合は学部・修士で浪人・留年がなかったとしても卒業時点で30歳を超えてしまいます。これは違う分野に行く場合だと大きなハンデキャップになってしまう可能性が高く、個人的には途中で見切りをつけるという選択肢も検討するべきではと思います。

博士の愛した就活（就職先の選び方編）

練習などを兼ねてちょいと書いてみました。自分のMacBookProで作業をしていた時に取得した通信データから、通信相手をドメイン名で判定し、送受信量をもとにツリーマップにしてみました。通信からのデータ取得は自作ツールを使い、出力結果をPythonでごにょっといじった後にd3jsで描画しました。通信データは約5時間ほど。HTML版はここに公開しています。細かい通信量とか見えます。送信データ量のツリーマップ送信データ量と受信データ量は一度に表現するのが難しいので、今回は分けてみました。まずは送信データ量から。解説を入れるとこんな感じです。送信データ量そのものは多くないのですが、作業していたソースコードがDropbox配下にあったので頻繁にDropboxにデータを送信していたため、Dropboxがとても大きく出ています。といっても、送信データ量はDropboxの島を全部あわせて70MB程度ですね。どうということはありません。さらに、作業時にずっとみていたニコ動の通信が目立って見えるのがわかります。これも送信データ量としては少なく、トータルで20MB強というところでしょうか。これはこちらから生中継をするようなデータを流していたわけではないため、ほぼTCPのack（受信確認）のパケットだけでこれぐらいの容量になっていることが伺えます。受信データ量のツリーマップ一方、受信側はこんな感じです。解説付きだとこんな感じになります。さっきより顕著にニコ動の通信がデータ量を占めているのがわかります。マイリスト登録していた動画をBGM代わりに受信しつづけていたので、その配信される動画のデータががつんと乗ってきている状態ですね。全体で約2.5GBほどあり、携帯キャリアの回線（テザリング）などを使っていたらあっというまに帯域制限にひっかかったでしょう。（この時はカフェに設置されてるWiFiを使っていました）次に大きなポーションになっているのが左下のBlizzard社からの通信です。これはBlizzard社が制作、発売しているHeathstoneのパッチが落ちてきたためだと考えられます。Hearthstoneはゲームとしてとてもシンプルなのですが、演出などが豊富なためアプリ・パッチのサイズがとても大きいというのが若干ネックになっている気がします。でもゲーム内容はとても面白いのでおすすめですよ（脈絡のない宣伝）他に注目すべき点としては右下にあるtwimgからのトラフィックでしょうか。そこまでtwitterの画像をずっと見続けた記憶はないので、Twitterクライアント（Tweetbot）がサムネイル（および画像本体？）を取得する通信だけで約100MBほどを受信しているのがわかります。ちなみにツイートの受信であるuserstream.twitter.comからの受信は右上にある青の細長い部分で、受信は20MB程度です。写真投稿などが多い昨今だと通信データ量だけでみればかなりtwimgに負荷がかかっているようです。ということで、通信を無制限に使える環境であれば特に気にすることのないものですが、データ量制限のある環境ではどの通信がどれくらいの割合をしめているかということがわかると通信データ量の節約がはかどるのではと思います。（一部当然のことですが）今回の知見としては以下のとおりです。動画垂れ流して見ているのは非常にインパクトがでかいアプリケーションのパッチも種類によってはそれなりに重いツイート取得はそうでもないが、画像閲覧はそれなりに重いようなのでクライアントの設定しだいではデータ量を節約できるかも？こちらからは以上です。

インターネット通信データ量をd3jsのツリーマップで可視化してみた

自分の経験を元にメモ書き。1. 自動化の目的は「属人性排除」「ヒューマンエラーの除去」「高速化」のいずれか、もしくは全てである属人性排除「この作業は○○さんしかできないから」みたいなものをなくすのが属人性排除。これは自動化することによって作業の一部、あるいは全てをほかの人でもできるようにすることで達成される。職場における人の入れ替わりで秘伝の技が途絶えてしまったり、引き継ぎの労力を少なくすることによって組織としての靭性を高めることができる。また自動化する過程で、ある人物しか理解していなかったロジックや、そもそも作業をしている本人ですら説明できないような手順や理論を解き明かし、再現性のある形へ落とし込めるという副次的な成果がある。これが手順書という形だと解釈の違いによる間違いなどが発生する可能性があるが、コードによって自動化されていることで誤解を生む可能性を極小化する。（ただし0になるわけではない）ヒューマンエラーの除去プログラムによって自動化された作業でも当然例外やバグによって思わぬ挙動をすることがあるが、人間も言うに及ばずしょっちゅう間違いをおこす。しばしば「集中力が足りない」「もっと注意する」「気合」などの精神論で解決できると信じている人がいるが、個人的な経験則でいうと、どれだけ注意深く作業したとしてもだいたい最低0.01〜0.1%程度の確率でミスをする。プログラムのバグの発生も同程度、あるいはもっと高い確率かもしれないが、最大の違いは（バグ修正すれば）プログラムは同じ間違いを二度起こさないことである。人間の場合、同じ人物が同じミスをしてしまうこともあるし、作業者が入れ替わると同じミスを起こすかもしれない。高速化単純作業やロジックが決まっているものについては、それを得意とする機械にやらせるべきである。2. 自動化の目的は「コスト削減」であってはならないよく「自動化によってコストが削減されます」という言い方がされているが、だいたいの場合こういうプロジェクトは失敗する傾向が強い。これは、この文脈ででてくる「コスト」とはすなわち「人件費」のことであり、「コスト削減」といは「人員整理・リストラ」につながるからである。多くの場合、自動化するためには今その仕事をしている人物から作業のロジックやノウハウを教えてもらわなければならないが、プロジェクトの最終目的がリストラだとすると、教えてもらう人たちがまさのその対象になるわけである。これでは協力してノウハウを教えてもらうどころか、その人達が抵抗勢力になってしまうため、プロジェクトが進まなくなってしまう。結局のところ自動化とは人間の作業を機械にやらせることになるので、コスト削減が最終目的ではないとしても少なからず上記のような問題を引き起こしやすい。ただし、以下のようなケースでは比較的スムーズにすむ。他にやるべき作業があるにも関わらず、現在は自動化対象の作業に業務時間が圧迫されている場合全てを完全に自動化できず、最終的に人間の判断などが必要な作業の場合(1) は例えば、目先の作業に振り回されてしまって先行投資的な作業に取り掛かれていないような状況である。(2) は例えば現実世界や人物間の文脈をもとに最終的な判断しなければいけない作業だったり、一定確率でしか正解が導かれるが外した時の影響が大きいので人間が責任を負う必要があるようなケースである。こういう類のものは結果が導かれるまでの過程を正しく理解している人物が必要になるので、単純に機械を人に置き換えられるものではない。3. 自動化は「熟練の作業者」ではなく「未熟な作業者」に対して効果が高いなぜか自動化の話がでると「専門家（熟練の作業者）」「それ以外」という登場人物しかでてこなかったりすることが多いのだが、現実にはその中間たる「未熟な作業者」がいる。最初の目的に挙げた「属人性排除」「ヒューマンエラーの除去」「高速化」は、もちろん熟練の作業者に対しても有効だが、それ以上に「未熟な作業者」に対してはより大きい効果を生みやすい。これは作業を完全自動化するわけではなく、未熟な作業者がとりかかる一部だけでもその効果がでやすいという観点もある。（熟練の作業者の一部の作業を置き換えると、逆に効率が下がってしまうことがしばしばある）ただし、先述した判断が必要な作業などもあるため、自動化された作業について無知でよいというわけではない、ということについては注意が必要である。

自動化するときに考えるべきこと3つ

情報処理学会 コンピューターセキュリティシンポジウム(CSS)2015＠長崎に参加してきました。ちゃんぽん美味しかったです。より実践的になっている学会実学的な発表が多くなってきている印象でした。CSSにはマルウェア対策研究人材育成ワークショップという発表枠が含まれているのですが、ここで発表されているネットワーク侵入検知や防御、マルウェア分析などは他のコンピュータ科学の研究とくらべてもとくに実践的な内容になっていると思います。マルウェア対策技術というのは、攻撃者側のマルウェアや攻撃手法の変化が非常に早く、自分も昔指導教員に「マルウェア関連の研究で5年前というのは石器時代」と言われたことがあります。そのため研究でも数年後に芽がでるようなものではなく「今」「役立つ技術」というものが求められていると思います。今回もそうですが、このマルウェア対策研究人材育成ワークショップ(MWS)というのは大学や企業の研究所だけでなく、セキュリティをサービスとして売っているような会社やそれこそアンチウィルスベンダの方も参加されており、こうやってデータ収集してみた、みたいな内容も多く発表されています。これはこのワークショップが始まってから徐々に広まってきた流れであり、それ以前のCSSにはなかった流れだったと記憶しています。ワークショップの委員の方もこういった実践に沿った研究活動を広めてほしいという願いがあったようで、それが形になってきているということを強く感じました。研究は良くも悪くも機械学習的な話が多かった自分が参加したセッションの偏りがあったからという気もしますが、とりあえずデータを機械学習に食わせて何か結果をだす、というような発表が多かったのが印象に残っています。データをいろいろな視点から扱ってみるという点では貢献があるかなと思う反面、機械学習系の研究の悪いところとしてでやすい「なぜこの手法を選んだのか」ということを論じきれていなかったり、「この結果は他の環境や実環境でも有用なのか」というようなことに対しての突っ込みが甘いものも少なくなかったように思います。研究所から離れた自分が参加してみて私自身が今年の4月から研究所を離れて現場（SOC）に入っているのですが、やはり現場的視点を持ってからこういう研究発表を聞くと面白いと思いました。特にMWSというのは事前に配布されるマルウェア関連のデータがあるのですが、この共通のデータをいろいろな視点で料理している研究を見ると、実際の現場でも「ああ、こういう見方や分析をして見ると何か見えてくるかもしれない」というような着想を得ることができました。すでに多くのセキュリティ対策ベンダだけでなく大手Webサービスの方などもちらほら参加されるなど、多様な方々が集まるよい場だったと思います。研究というキーワードがあるとちょっと疎遠になってしまいますが、普段セキュリティに関わっている方ならいろいろと有益だと思いますので、参加を検討してみるとよいと思いますよ。

コンピューターセキュリティシンポジウム2015に参加してきました

数ヶ月間、私のお小遣いを貪り続けてきたAWS EC2上のハニーポットですが、さすがに財布へのダメージが蓄積してきたのでいったん停止させました。停止させたもののそれなりにデータを蓄積していたので、さてどうしようかなと思っていたのですが、先日、長崎で開催された情報処理学会のコンピュータセキュリティシンポジウム2015で聞いた講演の一つにSSHの新しい攻撃方法について触れられていてちょっと気になったので、収集したデータのうちSSHに関しての通信のみちょっと分析してみました。ハニーポットの構成やデータの収集方法については過去のエントリを参照していただきたいのですが、今回はAWS Asia Pacific (Tokyo)上でEC2のインスタンス4つを4月頭から6月末まで動かしてデータを取得しました。財布へのダメージも4倍！しかしおかげで複数のIPアドレスで観測した時に生じる差分について知ることができました。アクセス件数の推移2015年4月から6月までEC2の4インスタンスで観測したSSHサーバへのアクセス件数まずはベタに各インスタンスに対するアクセス件数を時間軸で見たものです。A, B, C, Dがそれぞれのインスタンスになりますが、4つともアクセス件数の傾向にそれほど大きなブレ方はしていないことがわかります。これらのインスタンスが使っているIPアドレスはどこにも広告していないので基本的には全て無差別に打ち込まれている攻撃であると言えます。そのため特定の組織などに対する攻撃とは異なるかもしれませんが、このようなアクセスは使用しているIPアドレスに関わらず、安定（？）して日々起きていることがわかります。アクセス先ポート番号の件数2015年4月から6月までEC2の4インスタンスで観測したSSHサーバに対するアクセス先ポート番号の件数つづいてアクセス先ポート番号の分布です。4インスタンスの合計値から上位20件をグラフにしてみました。当然ながらデフォルトポートである22番へのアクセスがダントツですが、それ以外にも様々なポート番号に対してアクセスが来ていることがわかります。ちなみに観測されたポート番号は合計56種類となっており、5050、18080 などといったSSHとは全く関係なさそうなポート番号もターゲットとなっていました。今回利用したハニーポットは特にSSHサーバを偽装するわけではなく、アクセスしてきた接続元のホストに対してSYN-ACKを返すだけで、あとは勝手に相手が送ってくれたデータをせっせと回収します。ではなぜ22番ポート以外もSSHだとわかったのか？というとSSHの接続確立時に相手が勝手にバナーとしてSSH-2.0-PUTTY のような文字列を送ってきてくれるので、そこからSSHをターゲットにしているということがわかります。なかにはSSH-2.0-paramiko_1.15.2やSSH-2.0-libssh2_1.4.2のように、あからさまにツール使ってますぜと宣伝してくれているやつもいたりします。しかし先に述べたとおりこちらからは何も情報を渡していないため、相手は攻撃先がSSHサーバであるかどうかを確認などせずに22番以外のポートに接続をしにきているということがわかります。「ポート番号を変えているからパスワード認証でも大丈夫だよね」とか「ポートスキャンを止めているからどこがSSHのポート番号かわからないよね」と考えている管理者の方はぜひ設定の見直しをお勧めいたします。アクセス先IPアドレスと攻撃元IPアドレスの関係2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレスの件数（アクセス先IPアドレス毎）それではようやく複数のインスタンスを使ってデータ収集した強みをみたいと思います。気になることの一つとして「攻撃者はIPアドレスのレンジを舐めるように攻撃しているのでは？」ということだと思います。実際にSSHにかぎらずport sweep（アドレスレンジに対して特定のポートが空いていないか順番に確認するタイプのスキャン）などではそういった挙動も見られます。上の表は各インスタンス（A, B, C, D）で観測されたかどうかと、それぞれで観測されたIPアドレスのユニークな数になります。観測されたIPアドレスは全部で6,669件ですが、そのうちの約80%にあたる5344件の攻撃元IPアドレスがどれか一つのインスタンスでのみ観測されているということになります。それぞれのインスタンスはある程度同じレンジにおさまっていたため、このことから 攻撃者は近接するアドレスに対して何度も出現する可能性が高いとは言えない ということがわかります。先ほどのポート番号に比べると直接的な対策ができるような類のものではありませんが、例えば自組織で管理されているサーバでSSHの不審なアクセス（Brute forceなど）が発生したさいに他のサーバも利用するブラックリストに追加する、というような対策はそれほど効果的ではないかもしれません。（もちろん、残り20%は複数インスタンスで観測されているので無意味ということはありませんが、それでも全インスタンスで観測されたアドレスは約6.5%ほどになっています）攻撃元IPアドレス毎の接続試行回数2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレス毎の接続試行回数の分布（n<10)最後にご紹介するのが1つの攻撃元IPアドレスからやってくるSSHアクセスは何回まで試行されるか？ということをグラフにしたものです。先述したとおり、このデータ収集はあくまでTCPセッションが確立したとみせかけてデータを送信させるだけという仕様になっているため、本当にBrute force attackのようなパスワード試行された回数をカウントしているわけではありません。しかし、通信状態の問題などでうまく接続できないなどのケースが考えられるため、相手がどれくらいしつこかったのかということを知る指標にできるかと思います。このグラフでは1つのインスタンスでのみ観測された5344件のIPアドレスに対してそれぞれのアドレスは何度接続試行したのかをヒストグラムで表したものとなります。一番左のバーが1回だけの試行だった攻撃元IPアドレスのかたまりになるのですが、これを見るとほとんどの攻撃元IPアドレスが試行1回目でダメそうだったらその時点で諦めているということがわかります。このグラフは試行10回までの分布しか表示していませんが、10回以上試行してきたIPアドレスは16件だけでした。全体的に非常に諦めがよい、ということを読み取ることができます。しかし、ここで最初にふれた情報処理学会のコンピュータセキュリティシンポジウム2015の話に戻ってくるのですが、富士通研究所の齊藤さんが発表された「SSHログインセンサによるSTBF(Brute Force attacks with Single Trials)の観測」において一つのIPアドレスからパスワード試行が1回だけ実施されて、次は別のIPアドレスから試行されて、というのを繰り返すBrute force攻撃が確認されたという事例が報告されていました。これは、一つのホストからパスワード試行を繰り返すと防御側に目立って接続拒否されたり、共有されているブラックリストに掲載されてしまい他の環境に対しても攻撃ができなるなることを攻撃者が警戒した結果、ボットネットのように悪性ホストを大量に所有（またはレンタル）している攻撃者が目立たないように1回だけパスワード試行をして去る、という一撃離脱型の攻撃が連続して発生しているということだと考えられます。この攻撃に対してはIPアドレスを基準としたパスワード試行回数制限による対策がほぼ無効化されてしまうということが言えます。実際にこの攻撃がどのくらい世の中に蔓延しているかについては発表者の方も今後調査を継続していくとおっしゃられていましたが、ここで紹介した分析からもそのような種類の攻撃が発生している可能性を示唆する結果となりました。AWSでのインスタンスに限りませんが、SSHでリモートアクセスをしているホストについては今一度設定の見直しなどをしたほうがよいかもしれません。