上記のイベントにシュッと参加してきたのでレポ。

tldr

現地で働いてるかたのナマの声などがきけて為になった。 leetcode頑張ろうと思いました。DroidKaigiが終わったら。

各セッション

「メルカリにおける技術者採用方法の変遷」とスマニューの「コーディング試験Codility運用の実態と実績」は遅刻したためレポなしです...すみません...

[リクルート] コードテストでtrack.runを使ってる話と採用フロー by @yosuke_furukawa

インターンのコードテストでtrack.runを利用している。
DB操作、HTTP API送信・受信、アルゴリズム問題、数学問題が題材
時間切れになってしても、回答の中でアピールすることが可能
中途面接の場合は、職務履歴書から質問を考えて、そのかたが何を学んだかにフォーカスする。自分の成長の場ともしている

[インディーゲーム開発者]:付け焼き刃でベイエリアの面接を突破するたった一つの方法 by @daigo

ホワイトボード面接が苦手
なぜなら通常の業務では鍛えられないスキルだから（Homebrewの作者も落ちる）
とはいえ、変な人を入れるよりマシ
電話面接よりもマシ
tips:
- 記述量の少ない言語を選ぶべし
- 大枠の方針を決めるべし
- Big-O Complexityの理解をしていれば標準関数を使っても問題ない
- ホワイトボードでの練習をする
- ホワイトボード面接中は常にコミュニケーションをするべし
- 基本はアルゴリズムだが、ゲーム計だと線形代数・３D数学、経路探索、当たり判定のための円や線分もでる
- LeetCodeを解いて、過去問になれる
- 搦手だとCEO/CTOに気に入られたり、業務委託からはじめたりする手段がある

コーディング面接を受ける際の Tips by @thagikura

ホワイトボード面接苦手税
オンライン面接はIDE利用不可だが、易しめ
オンサイトはホワイトボードで、コード以外にまれにアーキやデザインに関する題材もあった
時間は貴重
30min out of 45minくらいしかコードを書く暇がない
解決法を思いつくのはポイントの１つ
早く終われば終わるほど、自己アピールタイムも増える
やはり記述料がすくない言語のがいいが、省略してもよいという面接官もいる
メソッド分割も大事で、前提条件に特定のメソッドがあるということにしてもよい
データ構造やアルゴリズムが大事

QuipperのWebエンジニア採用におけるコードて

今は1問あたり2hrほどの問題を３つ家で解いてもらっている
言語はRuby/JS
もともとは１つのアプリまるまる作ってもらってたが、それだと時間がかかりすぎた
したがって方針を1) コードテストはなくさず 2)要素技術のみを解いてもらい 3)アルゴリズム問題はださない、ことにした
そうすることで2week -> 3dayのプロセスにした

speakerdeck.com

人生出始めて外資の会社を受けてみた by @ganezasan

日本のコーディング面接は、予備動作がなく、面接の場でいきなり題材がでてくる
また前提条件がざっくりしていることが多い

テックインタビュー裏表 by @mogutan88

一時期、学歴詐称が通るくらいゆるい基準だったことがある（というのが面白かった）

グローバルIT企業での働くまで・働いてみての学び by @daikikohara

JDは熟読するべし
実務経験３年はCS1年分の学位に相当
Cover LetterはLinkedInのプロファイルが充実していればいらない

2018-11-25

FIDO/WebAuthNにおけるAndroid SafetyNet AttestationとKey Attestationの違い

Android FIDO AuthZ

TL;DR
背景
SafetyNet Attestation API
- SafetyNet Attestaion APIのチェック項目
- チェックの経路
Key Attestation
おまけ
余談
余談の余談

TL;DR

AndroidのSafetyNet Attestation APIとKey Attestaionの違い
中身のレベル: ドキュメントを読んだレベル

背景

FIDO/WebAuthN in Androidの文脈で、SafetyNet Attestation API とKey Attestationの違いってなんだっけ？というところから始まっています。

SafetyNet Attestation API

SafetyNet Attestaion APIのチェック項目

アプリがインストールされた端末のHardware/Software情報を分析し、端末の改ざんがないかチェックするAPIです。 APIを叩くことでAndroid Compatibility Test Suite（CTS）というOEMベンダーやHWプラットフォーム間で互換性を担保するためのテストスイートの結果から判定されます。「WebAuthN 8.5 Android SafetyNet Attestation Statement Format」のVerification Procedureに ctsProfileMatch 属性のチェックを要求されていますが*1、これがテストスイートの判定結果です。値がtrueであれば、root化などの改ざんされた痕跡がないことが保証されます。

f:id:kengoscal:20181125022046p:plain

しかしながら、CTSにパスしたからといってAuthentictorにTEEを使っていることは保証されません。つまり、入札要件にHardware-backed Authenticatorを要求される場合、通らない事態が起こりえます。例えば、米国では政府機関の職員はハードウェアベースのAuthenticatorを使うことが強く推奨されております*3が、これに批准するのはSP800-63-BのAAL3もしくはFIDOのAuthenticator Level 3 *4 になります。

Secure Element つまりHALをインターフェースにしたTEEのようなTamper-resistantなハードウェアをチェックする機構がSafetyNet Attestation APIにも実装されたものの*5、Android 9(Pie)からでしか使えません。

チェックの経路

CTSは公開されていますが、アプリ開発者はCTSをUSBでつないだ端末もしくはエミュレーターでしか走らせることができません。つまり、ユーザーが認証情報を登録したいアプリおよびインストールされたローカル端末内でAttestationが完結するわけではありません。ドキュメントにある次の図が示すとおり、①アプリがGoogle Play Servicesの中にある SafetyNet Attestation API を叩いて、②Google Play ServicesがGoogleのBackend APIに対して更にリクエストを投げる形になります。

f:id:kengoscal:20181124225451p:plain *6

こ子でのポイントはネットワーク通信がクライアントとGoogleのBackend APIおよびFIDOサーバーの間で計2回のネットワーク通信をすることになります。FIDOサーバーへの連携はまだしも、Google Backend APIへの互換性チェックは「10 things you might be doing wrong when using the SafetyNet Attestation API」にある通り多くの帯域や電力を消費すること*7 になるため、ユーザーにとって嬉しいことではありません。

Key Attestation

さて、Android 7(Nougat)ではKey Attestationが追加されました。「WebAuthN 8.5 Android SafetyNet Attestation Statement Format」*8にも書かれていますが、こちらとSafetyNet Attestation APIがある場合はこちらを使うほうがベター(SHOULD)です。これは次の点からだと自分は思います。

Authenticatorの真正性を確認できる
登録に必要な情報以外を集める必要がない
通信量を減らせる

Authenticatorの真正性を確認できる

Google Play Storeがプリインストールされた端末の初期バージョンがAndroid 7の場合、attest_key()を呼び出しTEEにあるAttestation Keyをつかうことで、 keyPairGenerator.generateKeyPair()で生成される認証(Assertion)用鍵に対して署名ができます。Attestation Keyは工場出荷前にTEEに埋め込まれたものなので登録リクエストの証明書チェーンを検証することで、FIDO認定のAuthenticatorが使われたか判断することができます。

登録に必要な情報以外を集める必要がない

FIDOはプライバシーも考慮した仕様です。そのため、個人を特定できないように、大量生産したAuthenticatorごとに共通したAttestation Keyを埋め込んでいます*9。せっかく、そのような設計にしているのに、SafetyNetではその過程で窃取可能な情報の範囲を端末全体に広げてしまっています。その先がGoogleとはいえ、FIDOのプライバシーポリシーとしては望ましくないでしょう。

通信量を減らせる

GoogleのBackend APIに通信するとき、必ずしも端末の完全性に必要な情報のみを送るわけではありません。互換性チェックのため、様々な情報を多くの帯域や電力を生贄に消費することになります。FIDOはIoT分野の認証も狙ってるようなので、地味に大切じゃないかなぁ。これをKey Attestationにすれば、通信量はCRL関係の通信のみに限定されます。

といったことから、Android アプリ開発者は次のようなフローで2つのAttestationを使い分ける形になると思います。試しに書いてみたので、実機での検証はまだです。

// Generate a Key Pair
KeyPairGenerator keyPairGenerator = null;
keyPairGenerator = KeyPairGenerator.getInstance(KeyProperties.KEY_ALGORITHM_EC, "AndroidKeyStore");
AlgorithmParameterSpec params = new KeyGenParameterSpec.Builder("Key1", KeyProperties.PURPOSE_SIGN)
    .setAlgorithmParameterSpec(new ECGenParameterSpec("secp256r1"))
    .setDigests(KeyProperties.DIGEST_SHA256)
    .setUserAuthenticationRequired(true)
    . setUserAuthenticationValidityDurationSeconds(5 * 60)
    .setAttestationChallenge("challenge".getBytes())
    .build();
keyPairGenerator.initialize(params);

KeyStore keyStore = KeyStore.getInstance("AndroidKeyStore");
keyStore.load(null);
SecretKey privKey = (SecretKey) keyStore.getKey("Key1", null);
SecretKeyFactory factory = SecretKeyFactory.getInstance(key.getAlgorithm(), "AndroidKeyStore");
KeyInfo keyInfo = (KeyInfo) factory.getKeySpec(privKey, KeyInfo.class);

if (keyInfo.isUserAuthenticationRequirementEnforcedBySecureHardware()) {
    // build Android Key Attestation Statement Format
} else {
    // Send a request to SafetyNet Attestation API
    // Build Android SafetyNet Attestation Statement Format
}

以上。

おまけ

AttestとCertifyの違いについて一時期ものすごく気になっていたのですが、最終的に次の様な使い分けになると自分の中で結論を出しています。

Attest: 何かしらが本物であることを断言すること。対象が美術品などであれば鑑定人が必要で、対象が証言などであれば証人（及び証人の署名）が必要。
Certify: 何かしらが基準に沿ったナニカであること。

なのでITにおける認証情報の登録の文脈で、例えば製造元の秘密鍵によって証明書チェーンが構築されるFIDOでは登録プロセスの一部でAttestされていると言えるのではないでしょうか。そもそもがここらへんは欧米発祥の概念であるので、しゅっと一言の日本語にするのは難しいと思いました。

...っていうことを国際法律事務所にいる弁護士の友人に聞いたところ「ん〜、同じじゃない？」と言われたので、拘ることを辞めました。

余談

最近、アウトプット疲れを起こしていたのですが、その一因として気負いすぎていたことがあると思いました。砕いてい言うと、発表・講演とブログ上でのアウトプットに対して同じ情報量と質を自分に対して求めていて、それが重荷になっていたようです。よって、改めてアウトプットの目的の1つである「自分の思考の整理をすること」に立ち止まり、つまりブログでは自分が理解できるレベルで満足する方向に決めました。あと、発表や講演をする目的である「他の人に知見を共有する」には、それなりに聴講者のことを考える労力に加え、情報のまとめ・削減・制御が必要なので、その一部を構成する内容を順次公開していったほうが最終的な編集工数が減ると見込みました。

余談の余談

自分は文章化や可視化がめちゃくちゃ苦手（＝それなりにするのに時間がかかる）ので、まずはバシバシ数を出して慣れようと思いました。

*1:https://www.w3.org/TR/webauthn/#android-safetynet-attestation

*2:https://developer.android.com/training/safetynet/attestation

*3:https://www.slideshare.net/FIDOAlliance/nist-80063-guidance-fido-authentication

*4:https://fidoalliance.org/certification/authenticator-level-3/

*5:https://source.android.com/compatibility/tests

*6:https://developer.android.com/training/safetynet/attestation

*7:https://android-developers.googleblog.com/2017/11/10-things-you-might-be-doing-wrong-when.html

*8:https://www.w3.org/TR/webauthn/#android-safetynet-attestation

*9:https://fidoalliance.org/wp-content/uploads/2014/12/FIDO_Alliance_Whitepaper_Privacy_Principles.pdf

2018-10-08

技術書典５で新刊を出します（セキュア旅団 - 「あ10」

セキュリティ技術書典技術書典5

きたる技術書典５で「No Security No Life」という新刊を出します。ブースは「あ10」です

f:id:kengoscal:20181008010229p:plain — 新刊

f:id:kengoscal:20181008010426p:plain

各章を紹介します。

PowerShellによるWindows APIプログラミング by @gr4vit0n

Exploit-DBでARM分野の掲載数が世界一の @gr4vit0nさんが書くPen tester向けのPowerShell編です。「ペネトレーションテスターのためのPowerShellの基礎」の続編で、攻撃に必要な基礎部分をWindows APIに特化して解説します。

転生したらWordPressでインシデント対応の担当者だった件 by @ym405nm

WordPressまわりの脆弱性の権威である @ym405nm のなろう系ラノベデビュー作です。ある日キッティング担当のたかし君が目を覚ますとWordPress担当者になっていた！そこから急にインシデントにモテモテに..

Cracking ASR - 音声認識システム by @bbr_bbq

BlackHat Arsenalもはや常連といっていいセキュリティ周りの機械学習マン @bbr_bbq が音声認識システムに対する悪意ある偽音声データの生成手法とその対策を論文を紹介しながら語ります！

FAPI the Security: the 2nd by @ken5scal

FAPI Read and Write Profileの仕様について語ります。OIDC Hybrid Flow, ID token, MTLS, JWT/JWSについてお話します。Open Bankingなどに興味がある人は是非読んでくれよな！

以上、「お、なるほど！こういうセキュリティもあるんだな！」とWowをお届けする4章をまとめた「No Security No Life」/1000円を #技術書典5 でオール電子書籍で配布します。既刊もあるので、是非そちらとあわせてご検討ください

2018-08-02

Financial APIs Workshop 2018 と Japan/UK Open Banking and APIs Summit 2018参加レポ #fapisum

Authlete社の創業者　川崎さんにお招きいただき次の2つのイベントに参加してきました。（川崎さん、ありがとうございます！）

⁃ 7/24(火): Financial APIs Workshop 2018
⁃ 7/25(水): Japan/UK Open Banking and APIs Summit 2018

両日とも満席であり金融機関向けAPIやFAPIへの関心が高まっていることを実感できる2日間でした。内容は7/24は技術者を対象にした、7/25はよりエグゼクティブを対象としたThe Open Banking Implementation Entity（OBIE）やFAPIを中心としたセッションになっていました。本ブログはその2日間をまとめたものになります。

OBIE概要

金融機関に預けられた取引履歴や本人情報などの金融データはユーザーのものになりますが、従来は金融機関がそれらをある意味、勝手に利活用していました。それを本来の所有者であるユーザー自身が制御できるようにすべし。ローコストで機会を増やすべし。そういった考えからオープン銀行APIの標準やセキュリティやセキュリティアーキテクチャを策定している in イギリスがOBIEです。 OBIEは所属団体が 継続的に仕様に満たされた実装されていることを保証 することで、一時的に準拠可能な企業を量産するのではなく、エコシステムを築くことを１つの目標としています。

OBIEの標準は大まかに４つのカテゴリに分けられます。

Identity: 信頼されたOBIE参加団体と顧客（APIクライアント？）に関するリストとAPI。アプリ登録や登録された銀行やFintechの情報（含むJSON形式のデータ）のみならずSwaggerファイルも置かれているようです。
Reference Data: 銀行の商品や説明（eg ATMの場所）といったオープンにすべきデータに関するAPI
Users Data: 口座や支払い情報に関するRead/Write API
Security: 認可や認可の委譲にかんする同意を含めたセキュリティ標準

OBIEは2016年に発足したばかりですが、2018~2018は様々な仕様の追加・変更があるようです。 AIS（Account Information Services）やPIS（Payment Initiation Services）のPSD2（※）口座や通貨への対応、CIBA（Client Initiated Backchannel Authentication Profile）によるユーザー同意とクライアントが認可トークンを取得するデバイスをDecoupledする仕様、失効通知…などがもりもりです[1: p9]。

※ 銀行によるオープンAPIを事実上義務付けた決済サービス指令のv2

こちらを整備していきつつ、開発者やベンダーへのサポートを充実させていくようです[1: p.15]。

OBIEの技術スタック

全ての仕様はオンラインに公開されています[3]が、ベースはOAuth2.0[4]のフレームワークです。

OAuth2.0++

OAuth2.0についての基本的な解説もありました[9]が、基本的には@TakahikoKawasakiさんのQiita[4]を読めばおｋです。しっかり理解したいのであればRFCを読むといいでしょう。ちなみに、私は両方読んでいるので完全に理解しています（していない）。他にもある主体について「この主体はこの情報があるから真正だぞ」と主張するための情報を表現するJWT[7]についての解説もありましたが、これはRFC7519とともにAuth0が発行している”JWT Handbook”を読んで見るのもいいかもしれません。私は両方（略）。

OAuth2.0（RC674）はフレームワークです。すなわち場面やケースにあわせて、オプションを付与したり拡張することができます。逆に言うと、フレームワークのみでは十分出ないケースがあります。

金融APIも例外ではなく、金融機関として満たさなければいけないセキュリティの要件または ”プロファイル”になります。Nat Sakimuraさんの講演[10]によると、RFC6749単独ではプロファイルは満たせません。なぜならOAuth2.0における認可フローの各ステージにおいて、認証（メッセージ、送信者、受信者、利用者）などが考慮されてないからです。具体的に言うと、認可リクエストやレスポンスの保護といった部分が十分ではありません。

またOauth2.0では許容されていたBearer Tokenも盗難されたら誰であろうと利用可能になってしまうなどの問題もあります。そこで、従来のOAuth2.0に加えPKCE + Hybrid Flow + JWS AuthZ Request(JAR) + MTLSを拡張機能としてとりこむことで、金融機関向けのセキュリティ要件（プロファイル）を満たしています。なお、上記の話はNat Sakimuraさんの講演ではFAPIのread/write security profileの文脈ででてきましたが、OBIE自体はそれをベースにしている[13]ので大きくずれてはないと思います。私の知る限りではOBIEでは、トークンが発行要求者とひもづいているSender Constrained TokenのうちToken Bindingについて触れてないぐらいだと思います。

このような仕様を認可サーバーをAPIで提供するAuthleteさんはver2.0で実装したようです。他にもAuthleteさんはFAPI受けスコープ属性の管理機能を作成したり、新規クライアント認証の方式を追加したり、MTLS証明書および検証ができるような機能が追加されたようです[18]。

その他OBIEの仕様・サービス

上記だけでなく次に紹介するような仕様やサービスがありました。恥ずかしながら、私は知りませんでした。

さて、OAuth2.0はRedirectを前提としたフレームワークになっていますが、EU各国では様々なバリエーションが登場しています。例えば、POSで支払いをするクライアントがユーザーの管理下にないことを想定し、同意や認証はユーザーの認証器で、トークンの取得はOauthクライアントに分離（decoupled）するようなアプローチもあります。また、こちらはあまりよくわかっていないですが、”認証した結果を「パスワード」として送信する[14, p.18]” というようなEmbeddedな方法もあるようです。

個人的に一番newだったのはintent registration endpointです。探してもあまり情報がでてこなかったので多分に推測がありますが、AuthZリクエストを送る前に、認可目的をサーバーに伝えるような仕様です。例えば、「Aさんに$100を送信する」行為をしたい場合、その目的をクライアント経由で送りintent_idを取得します。認可リクエスト時にはintent_idを記載したリクエストをします。こうすると例えば「同意を得るために必要な個人情報の取得」といったユースケースにも利用できるのかと思われます。

Open Banking Conformance Suite[15]も素晴らしかったです。これは先述した”所属団体が継続的に仕様に満たされた実装されていることを保証”した状態を保証します。これは、FAPIやOBIEのAPIプロファイルに対するテストだったり、IdPやFIntechなどのRPにも適用できるテストです。これにより、コストや準拠状況を一瞬で可視化できるようになります。これがあれば、各金融機関がFintech業者のセキュリティ担当に押し付けるフォーマットがそれぞれ完全にことなり評価ポイントもまちまちの全く本質的でないセキュリティチェックシート in エクセルを駆逐できるようになると思います。

そして、Open Banking Directory[16]。これ、個人的にOpen Banking Conformance Suiteと同じくらいワクワクしたがNew内容なので、詳細はもっと調べてからにしたいです。サマリーとしては、Regulators（金融庁のような監督組織？）、銀行、Fintech企業などのサードパーティが、それぞれが他のDirectoryメンバーとやりとりするためのクレデンシャル（例: 登録したアプリのクレデンシャル）や証明書およびその他属性データを登録する場所、それがOpen Banking Directoryです、多分。

まとめ

以上のように、今回の2つのイベントをひっくるんだ#fapisummitに参加してまいりました。英国では着々と金融APIの発展が進んでいるようです。日本でも同様に整備しよりスケーラブルでセキュアな金融基盤がうまれることを願っています。

私自身もFAPI Part.1（Read Only API Security Profile）について「俺らの愛したセキュリティ」で著しました。もしよければ次のリンクからご購入してみてください。 https://booth.pm/ja/items/864595

また、技術書典5にも無事当確しました。その際にはFAPI Part 2（Read and Write API Security Profile）について書くやもしれません。その際は、是非当ブースまでご訪問ください。

Reference

2018-07-30

July Tech FestaでAWS GuardDutyの話してきた

本日（2018/07/29）、July Tech Festa 2018で「GuardDutyを使ったサイバー攻撃の検出と分析」の話をしてきた。とりあえず、今年はじめにかんがえていたインフラ関係でアウトプットを出す約束を守れてよかったとおもう、ふいー。なお、buildersconは落ちた模様...

GuardDutyを使ったサイバー攻撃の検出と分析.pdf - Speaker Deck

今北産業

だいたい以下について話た。

AWSでなぜGuardDutyを使うのか
実際のところのGuardDuty
今後、どのように発展させていきたいのか

AWSでなぜGuardDutyを使うのか

AWS（というよりIaaS）の世界観だから発現したリソースには、それに応じる脅威がある
よって、従来の検知メカニズムに追加対応をする必要がある
要は優先度とリソースの話であり、それを考えると（まだEC2とIAMにしか対応してないといえど）検知の要件からダッシュボード、そして他リソース（LambdaとかLambdaとかLambdaとか）との連携を容易にできるAWS GuardDutyはなかなか良いソリューションになりうる

実際のところのGuardDuty

まあセオリーはセオリーなので、じゃあ実際使ってどうなのか？という話をした。

じっさいやすい！（ニンジャスレイヤー風） -> 従来の外部SOCサービスを完全に置き換えた

   * Q&Aのときに検知漏れはないか？ときかれたときに、「そもそも要件がなかったから問題ない」とかいう頓珍漢な回答をしてしまった。
   * ちゃんとGuardDutyテスト攻撃スイート↓があり、そこでテストをすることで検知漏れがないことを確認した、という回答にすればよかった。なお、ちゃんとCloud Formationが動かなかったのでissueをたてたものの一ヶ月弱放置されている模様。

github.com

     * まあ、どっちにしろ社内Pentestのとき外部SOCサービスはかすりもしなかったので問題ない。

SOCの天敵である誤検知もほぼない -> あったらフィルター作って自動Archiveすればいい。

インシデントレスポンスをコード化可能 -> はいはいLambda。とりあえずやったのは以下。基本的にはAPI叩いてるだけです。必要なのは適切なフローを確立させておくこと。あとはただの実装（とデプロイと運用とIAMの設定とその他hogehoge）

  1.  JIRAにインシデントチケット作成
  2. 重要度に応じたSlack通知
  3. Pager Duty連携 <- 正直最近はJIRAと役割がかぶって2重管理になってるなぁと思っている。どちらかによせたい。
  4. 自動的にスナップショットとって、フォレンジック用インスタンスを隔離VPCにたてるところまで書いた。尚、社内ではまだ調整中の模様。

今後のGuardDuty

要はとりあえずGuardDutyオンにしておきなよ、影響はないし、という話だが、まだ成長段階。大きく分けて当社の実装とAWSへの要望になる。

当社の実装

インテリジェンスデータを食わせたい
JIRAとPagerDutyの役割をはっきりさせたい
全体的にもっと綺麗にしたい <- 今、Goでかいたのをzipにしてuploadする作業を手動でやってるので...
Lambdaの構成を考えたい <- モノリシックなLambdaにするか、Pipeでつなげるようにするか。あとエラー処理
実際に攻撃スクリプトを作成
https://github.com/awslabs/amazon-guardduty-tester でissueに対する反応がなければ、おれがterraformとgoスクリプトで作りはじめる。

AWSへの要望

https://github.com/awslabs/amazon-guardduty-tester <- 頼む！反応してくれ！
S3やRDSも頼む（Macieか？）
IPブラックリストやホワイトリストやめない？ゼロトラストでいかないか
端末情報連携したいなーJamfとかJamfとかADとか。これも基本ゼロトラスト対応のため
CloudTrailの移動とかRegionまたぎが地味にめんどいで、マスターアカウントにそれらの情報も集約したい
たのむ！各FInding TypeとActionごとのJSON スキーマ例をちゃんと出して...Lambdaのエラーでしか気づけない...
特定の送信元IP/宛先ポートへのDeny通信急増は検知したい。今はGuardDutyの仕様として、6時間毎に結果をまとめられて送るのでわからん。

といったような話をしてきました。

反省

ポジ

自己紹介ページを削ってよかった。あれで30秒、本当に話したいことを増やせた
コードの記載はしたけど、あえて読み飛ばした。後ろの人は絶対みえないよね
検知内容の詳細の解説も削ってよかった
時間ぴったしに終わる能力が向上してきた。

ネガ

もうちょっとしゃべる練習すればよかった。いったりきたりする説明が多かった気がする
今後のGuardDutyでは文字に頼りすぎた。もうちょっとビジュアルを挟むべきだった
普通に当社の求人出し忘れた

今後はGuardDutyでやりたいことを増やしつつ、もうちょっとCloud NativeやOAuth/OIDC/FIDOなことをやっていくつもり。

2018-05-03

RSAカンファレンス 2018のお薦めスライド

RSAカンファレンス2018のスライドが公開されていたので、ざっと一通りみました。おもに私が面白い・役に立ったなと思うもののまとめをします。

オペレーション

Incident Response In the Cloud

クラウド上でSANS GCIHをするには、というテーマの発表です。Preparation, Detection, Containment, Recoveryのフェーズでの対応をクラウド向けに再構築しているもので、とても勉強になりました。

Preparation
- レスポンスチーム用のIAM
- ログ・エビデンス用のS3バケットの準備
- 全アカウントでのロギングやCloudWatch
- SGでレスポンスチームしか使えないインバウンドな通信。アウトバウンドは必要なときのみ開ける。
Detection
- SIEM, CASB
- CloudTral(API呼び出し元、時間、呼び出し元IPアドレス、レクエストパラメタとレスポンス）
- Security Monkey
- 見たいログ（ユーザーの疑わしい行動、switch role時の行動、新しいリソース、不審な行動の時間帯、失敗したアクセス、Get/Describe/Listは可能であれば飛ばす）
Containment
- Tag付けして調査
- 隔離VPCにいれｔり、隔離SGを適用
- EC2のEBSをスナップショットする（フォレンジックEC2にアタッチする）
- メモリはMargarita Shotgunなどで取得
- SANSのInvestigative Forensic Toolkit(SIFT)の構築. EBSスナップショットをアタッチ。
- ThreatResponse Suiteを使うのも良い（AWS_IR, Incident pony, Margarita Shotgun）
- Digital Forensic Analysis of Amazon Linux EC2 Instances
Erradication
- Terraform destroy && Terraform apply

他にも、github.com/tradichel/AWSSecurityAutomationFrameworkなどが良さそう。

https://www.rsaconference.com/writable/presentations/file_upload/air-w14-incident-response-in-the-cloud.pdf

From SIEM to SOC: Crossing the Cybersecurity Chasm

昔はエンドポイントはAVなどで防御だけやっておけばよかったけど、最近は防御も検知も一次対応もやらないとね、と主張したスライドはよかったです。まあ、これは従来のネットワーク上の検知を否定するものではなく、より詳細な対策をするにはエンドポイントもみていこう、という話なのでとてもまっとうな話だと思います。Carbon BlackというEDRベンダーのプレゼンなのですが、「AntiVirustは死んだ」のような脳死に営業文句がなかったのは相当ぷらすでした。

https://www.rsaconference.com/writable/presentations/file_upload/spo3-r04-endpoint_security_and_the_cloud-how_to_apply_predictive_analytics_and_big_data.pdf

Identity

Risk-based approach to deployment of omnichannel biometrics in Sberbank

Biometricksの話です。Biometricsによる認証メソッドはすでに、ハイプ・サイクルにおける実用段階まで到達していて

ただ、欧州では可用性が低いことと偽造可能なことからBiometricsは信用されておらず、Something You Haveのカード等のSomething You Haveを採用しています。まあね〜。

そういったBiometricsにおける課題から、Riskベースの認証について、そのワークフロー、リスクスコアの計算モデル、ユースケースの取組が紹介されています。

余談ですがJuniper, TOP10 Disruptive technologies in fintechがよい読み物でした。

https://www.rsaconference.com/writable/presentations/file_upload/idy-w02_risk-based_approach_to_deployment_of_omnichannel_biometrics_in_sberbank.pdf

Adventures in OpenBaking: Understanding OAuth and OpenID Connect Client Ecosystems

Open Bank in イギリスにおける現状と課題の概要を掴むのによいです。半分ほどのスライドがOAuth 2.0 Dynamic　Client Registration（RFC 7591 ）に費やされていました。Dynamic Client Registrationは、認可サーバーに対してクライアントが直接メタデータを登録することで、クライアントクレデンシャルを受け取る仕様です。 https://www.rsaconference.com/writable/presentations/file_upload/idy-r04_adventures_in_open_banking-_understanding_oauth-openid_client_ecosystems.pdf

Google And Microsoft Debut: Replacing Passwords w/ FIDO2 Authentication

FIDO2の紹介ですね。まあ、そこまで新しいことはなかったかな...が、おぬぬめです。

https://www.rsaconference.com/writable/presentations/file_upload/idy-f02_mcdowellfinal.pdf

Detection of Authentication Events involving stolen enterprise credentials

不正な認証イベントを検知するための、機械学習モデル及びインフラの考え方についての実用的なお話になるかと思います。特長としては、認証イベントの発生時間、同時間帯の端末上のイベント、通信イベント（ポート毎のパケット・バイト・接続数、DNSイベント）、同時間帯の認証側サーバーのイベントになります。これをランダムフォレスト、ロジスティック回帰、Naiive Bayes, マルチレイヤーパーセプトロン、SMOを使って学習させた模様。

特にイベントデータのストリームから、同データを抽出し、アップデートをかけていくかは参考になりました。

でも、stolen enteprise credentialsはちょっと関係なかったかな...?

https://www.rsaconference.com/writable/presentations/file_upload/idy-f03_detection-of-authentication-events-involving-stolen-enterprise-credentials.pdf

OAuth2.0 Threat Landscape

RFC6819の内容ですね。下記の攻撃（脅威）および対策についてまとめたものです。

CSRF攻撃
Token/Code漏えい
Token使い回し

https://www.rsaconference.com/writable/presentations/file_upload/idy-w04-oauth-2.0-threat-landscapes.pdf

Can blockchain enable identity management?

Portableな個人の属性を個人が選択して使い、その属性情報と信頼スコアをBlockchainに残すSelf Sovereign Identityなしくみです。最近だとMicrosoftが活発に取り組んでいる気がします。

https://www.rsaconference.com/writable/presentations/file_upload/idy-r12_can-blockchain-enable-identity-management.pdf

Identity In Ten Hundred words

Identity周りにおける用語解説集です。これだけでプレゼンがなりたったかよくわかりませんが、辞書的に使うのにはよいです。

https://www.rsaconference.com/writable/presentations/file_upload/tv-t08-identity-in-ten-hundred-words.pdf

その他

Transfer Learning: Repurposing ML Alogorithms from different domains to cloud defenese.

Microsoftにおけるクアウドを防御するための機械学習に関する発表です。正直難しかったのでまとめられてませんが、悪意あるPowershellを検知する手法など興味深いかったです。

https://www.rsaconference.com/writable/presentations/file_upload/csv-w02-transfer-learning-repurposing-ml-algorithms-from-different-domains-to-cloud-defense.pdf

2018-04-28

技術書典４に出店した as セキュア旅団

技術書典４にサークル名「セキュア旅団」として、新著「俺らの愛したセキュリティ」を販売しました。

f:id:kengoscal:20180428022928p:plain

お立ち寄りくださった皆様、ご購入いただいた皆様、誠にありがとうございました。万が一入手できなかった方のためにbooth（など）でダウンロード購入できるようにする予定ですので、お待ち下さい。

本投稿では、備忘録として次の２点についてまとめます。

執筆内容
サークルとして取り組んだこと

執筆内容

「セキュア旅団」は自分の好きなセキュリティ技術をアウトプットしていくことを目的としています。世の中にインパクトを与えるか、インフルエンサーになるか、そういった結果は大事ではなく、ただアウトプットを至上とします。そんな「俺得」技術書を今回も書かせて頂きました。

前回の「ニッチセキュリティー明星へ登る」の著者３人チームに情シス得意マンが加わったことで、質的にもページ数的にも肉厚な技術同人誌を世に出せました。本誌は次の４章からなっています。

PowerShellによるWin32 APIプログラミングの基礎
実践Metasploit API
Beyond Corp by Google
相互連携する金融時代 - FAPI the Security

最初の２章はペネトレーションテスターに必須となる技術です。１章目は最近のExploitで多様されているPowerShellプログラミングの基礎です。ペネトレーションテスター向けに書かれていますが、情シスによる管理のコード化という観点からも非常に有用そうです。なお、この著者は１人で５３ｐ仕上げています。意味がわからない。怖い。

２章目はペネトレーションテスターなら一度は触ったことがあるであろうMetasploitのRPC APIの叩き方を取り上げています。Pythonクライアントを使って、効率的なペンテストをやりたいかたにはうってつけではないでしょうか。私はGolangで叩いて見ようと思いました。

そして、情シス待望の書が３章目です。みなさまの社内セキュリティはどのような環境でしょうか？USではネットワーク境界でセキュリティを担保しないゼロトラストネットワークスというアーキテクチャが主流になりつつあります。特にGoogleはそれに関する論文を「Beyond Corp」という名前で出すほど進んでおり、VPNに頼らない社内アクセスを実現しています。本章はその論文を日本語にまとめたものです。

最後の４章「相互連携する金融時代 - FAPI the Security」を私が執筆しました。まだ登場したばかりでその将来性は未知数ですが、いままで１サービス内に閉じていた金融系の経済圏をよりオープンにするにあたって策定されたFinancial API（FAPI）のRead Onlyなセキュリティ仕様を、OAuth 2.0やOIDCのrfcとともに読み解いたちょっと頑張ってしまった作品です。

この用に様々な、かつ尖ったセキュリティ技術の知識を結集させたものが、新刊「俺らの愛したセキュリティ」です。内容がわかったところで、次はどのように本著を作成から販売までしたかご説明します。

サークルとしての活動

メンバーに声をかけたのは大体１月です。しかし、私自身の転職やDroidKaigiでの講演により、本格的な方針を決定したのは2月中旬ぐらいでした。そこから各々が原稿をRe:Viewで書き、4/21にマージ・販促体制を構築し当日に臨みました。方針は次の通りです。

電子書籍オンリー
ダウンロードカードによる配布
1000円
表紙担当を起用

電子書籍オンリーにしたのは、主に2つの理由があります。まだノウハウがないのに、期待値とことなる分量によって在庫リスクが発生することを恐れたを抱えたくなかったことが理由の1つです。もっと大きな理由は、ハードを準備することで圧迫されるスケジュールが大分厳しかった事です。正直、創業2年目のスタートアップに転職したてで、サークルのマネージメントに割く余力はなかったので、これはただしい判断だったと思います（そもそもマネージメント苦手です）。

ダウンロードカードを準備したのは、前回の反省からです。前回も電子書籍オンリーでしたが、QRコードを購入者に読み取ってもらう販促形式でした。これは意外と時間がかかります。それぞれのカメラの精度が異なりますし、混雑を極めている中でパラレルにさばくことは困難でした。何より①スマホを取り出す②アプリを立ち上げる③照準をあわせる④読み込む、とアクション数が多くなります。他にも、読み込んだあとなんらかの拍子にダウンロードをできなかった場合、支払った料金がむだになってしまうリスクがありました。

そういった反省から、1000円札と 交換する 形で入手できるダウンロードカードにし、これらの課題を解決しました。ただ、予想よりずっと来場者が多かったため、途中でダウンロードカードがなくなり、急いで擦りに行くという見通しの甘さを露呈してしまいました。次回のイベントに活かそうとおもいます。

また、前回は500円でしたが、今回は1000円にしました。これは価格そのものより、やはりオペレーションの観点からの改善です。基本的に1000円で支払う人が多い（という印象をもっている）技術書典で硬貨を使うと、お釣りが財布を物理的に圧迫します。

また、お釣りをわたすことはそれだけ価値交換のプロセスが多くなることだと思います。従って、人口密度の高いところではUX的に良くないと判断しました。技術書典はお祭りなので、出店から出店にすぐ移動できたほうが良い体験ではないでしょうか？　そういった体験を考えた結果、一枚の交換券だけで欲しいものが手に入る方式にしてみました。こういった価格設定と先述した配布方法により、まあまあの体験を提供出来たかな、と思っています。

尚、公式から「後払い」アプリがリリースされていましたが、アプリ支払いと現金払いからみると、売上的には 2:8でした。後払いアプリもモダンではありますが、①スマホ取り出しからの④読み込み⑤それをサークルにみせて⑥サークルはそれを渡す、という手続きを踏まねばなりません。その点、現金は①千円を取り出す②渡す③サークルは本を渡す、とスピーディーです。したがって、しばらく現金前提で販売するのが良いな、と思いました（もちろん、後払いは引き続き利用）。

表紙担当としては、今回、正式にデザイナーさんに依頼をしました。まあ、現職の同僚なんですけど。サークルのコンセプトを伝えつつ、表紙のキャラをシャチにしたい、という良く分からない要望を、完全な形に落とし込んでくれました。ありがとうございます！お陰でサークル近くにおこしいただいた皆様が歩を止めて、興味を持ってくれるようになっていたと思います。

f:id:kengoscal:20180428022928p:plain

しかし、どちゃくそ格好よくないですか？シャチの可愛さとかっこよさが見事に共存していますね。青の濃淡をつかいわけることで、シャチが推進の浅いところへダイナミックに３D移動することを表現しているようです。他にも細かいセキュリティ関連のアイコンがキュートすぎます。凄い。すごすぎる。

最後に

もっと「このブースに寄ってよかったな〜」と思えるような体験を作ろうと思っています。具体的にはダウンロードカードをリッチにしたり、物理本を出すことです。先述の通りデザイナーさんに入ってもらうなど、一見して手にとりたくなるような体験を作って行くと同時に、セキュリティといえば「シャチ本」と誰もが思いつく世界にしていきたいと思います。

以上、今後とも宜しくお願いします。

P.S

販売数は336部。前回は90部くらいでした。
シャチは私の趣味です。
Boothでのダウンロード販売に向けて動いています。