FIDO/WebAuthNにおけるAndroid SafetyNet AttestationとKey Attestationの違い
TL;DR
背景
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化などの改ざんされた痕跡がないことが保証されます。
しかしながら、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に対して更にリクエストを投げる形になります。
こ子でのポイントはネットワーク通信がクライアントと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
技術書典5で新刊を出します(セキュア旅団 - 「あ10」
きたる技術書典5で「No Security No Life」 という新刊を出します。ブースは「あ10」です
各章を紹介します。
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 でオール電子書籍で配布します。既刊もあるので、是非そちらとあわせてご検討ください
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は所属団体が 継続的に仕様に満たされた実装されていることを保証 することで、一時的に準拠可能な企業を量産するのではなく、エコシステムを築くことを1つの目標としています。
OBIEの標準は大まかに4つのカテゴリに分けられます。
- 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]を読めばおkです。しっかり理解したいのであれば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
[1] Ralph Bragg, Open Banking for Developers. https://www.slideshare.net/fintechlabs-io/open-banking-for-developers [2] Tasuya Kudo, Trends in Banking APIs, https://www.slideshare.net/fintechlabs-io/banking-apis-authorization-practice [3] Https://openbanking.atlassian.net/wiki/ [4] Takahiko Kawasaki, https://qiita.com/TakahikoKawasaki [5] The OAuth 20 Authorization Framework(RFC6749), https://tools.ietf.org/html/rfc6749 [6] OpenID Connect Core 1.0 incorporating errata set 1, http://openid.net/specs/openid-connect-core-1_0.html [7] JSON Web Token(JWT), https://tools.ietf.org/html/rfc7519 [8] JWT Handbook, https://auth0.com/resources/ebooks/jwt-handbook [9] Takahiko Kawasaki, OAuth OIDC Basics, https://www.slideshare.net/fintechlabs-io/oauth-oidc-basics [10] Nat Sakimura, FAPI and Beyond, https://www.slideshare.net/fintechlabs-io/fapi-and-beyond [11] OAuth2.0, https://oauth.net/2/ [12] Financial-grade API (FAPI) WG, http://openid.net/wg/fapi/ [13] Open Banking Security Profile - Implementer's Draft v1.1.2 , https://openbanking.atlassian.net/wiki/spaces/DZ/pages/83919096/Open+Banking+Security+Profile+-+Implementer+s+Draft+v1.1.2#OpenBankingSecurityProfile-Implementer'sDraftv1.1.2-OAuth2.0,OIDCandFAPI [14] Tatsuya Kudo, Trends in Banking APIs, https://www.slideshare.net/fintechlabs-io/banking-apis-authorization-practice [15] Joseph Heenan, FAPI/Open Banking Comformance, https://www.slideshare.net/fintechlabs-io/fapi-open-banking-conformance [16] Open Banking UK Identity Product, https://www.slideshare.net/fintechlabs-io/the-open-banking-identity-product [17] AUTHLETE 社、「金融グレード API」導入促進へソリューション提供開始 , https://prtimes.jp/main/html/rd/p/000000007.000024448.html [18] Justin Richer, Authlete FAPI Implementation Part 1 https://www.slideshare.net/fintechlabs-io/authlete-fapi-implementation-part-1
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をたてたものの一ヶ月弱放置されている模様。
* まあ、どっちにしろ社内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なことをやっていくつもり。
RSAカンファレンス 2018のお薦めスライド
RSAカンファレンス2018のスライドが公開されていたので、ざっと一通りみました。 おもに私が面白い・役に立ったなと思うもののまとめをします。
オペレーション
Incident Response In the Cloud
クラウド上でSANS GCIHをするには、というテーマの発表です。Preparation, Detection, Containment, Recoveryのフェーズでの対応をクラウド向けに再構築しているもので、とても勉強になりました。
- Preparation
- Detection
- Containment
- Tag付けして調査
- 隔離VPCにいれtり、隔離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などが良さそう。
From SIEM to SOC: Crossing the Cybersecurity Chasm
昔はエンドポイントはAVなどで防御だけやっておけばよかったけど、最近は防御も検知も一次対応もやらないとね、と主張したスライドはよかったです。まあ、これは従来のネットワーク上の検知を否定するものではなく、より詳細な対策をするにはエンドポイントもみていこう、という話なのでとてもまっとうな話だと思います。Carbon BlackというEDRベンダーのプレゼンなのですが、「AntiVirustは死んだ」のような脳死に営業文句がなかったのは相当ぷらすでした。
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がよい読み物でした。
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はちょっと関係なかったかな...?
OAuth2.0 Threat Landscape
RFC6819の内容ですね。下記の攻撃(脅威)および対策についてまとめたものです。
- CSRF攻撃
- Token/Code漏えい
- Token使い回し
Can blockchain enable identity management?
Portableな個人の属性を個人が選択して使い、その属性情報と信頼スコアをBlockchainに残すSelf Sovereign Identityなしくみです。最近だとMicrosoftが活発に取り組んでいる気がします。
Identity In Ten Hundred words
Identity周りにおける用語解説集です。これだけでプレゼンがなりたったかよくわかりませんが、辞書的に使うのにはよいです。
その他
Transfer Learning: Repurposing ML Alogorithms from different domains to cloud defenese.
Microsoftにおけるクアウドを防御するための機械学習に関する発表です。正直難しかったのでまとめられてませんが、悪意あるPowershellを検知する手法など興味深いかったです。
技術書典4に出店した as セキュア旅団
技術書典4にサークル名「セキュア旅団」として、新著「俺らの愛したセキュリティ」を販売しました。
お立ち寄りくださった皆様、ご購入いただいた皆様、誠にありがとうございました。万が一入手できなかった方のためにbooth(など)でダウンロード購入できるようにする予定ですので、お待ち下さい。
本投稿では、備忘録として次の2点についてまとめます。
- 執筆内容
- サークルとして取り組んだこと
執筆内容
「セキュア旅団」は自分の好きなセキュリティ技術をアウトプットしていくことを目的としています。世の中にインパクトを与えるか、インフルエンサーになるか、そういった結果は大事ではなく、ただアウトプットを至上とします。そんな「俺得」技術書を今回も書かせて頂きました。
前回の「ニッチセキュリティー明星へ登る」の著者3人チームに情シス得意マンが加わったことで、質的にもページ数的にも肉厚な技術同人誌を世に出せました。本誌は次の4章からなっています。
- PowerShellによるWin32 APIプログラミングの基礎
- 実践Metasploit API
- Beyond Corp by Google
- 相互連携する金融時代 - FAPI the Security
最初の2章はペネトレーションテスターに必須となる技術です。1章目は最近のExploitで多様されているPowerShellプログラミングの基礎です。ペネトレーションテスター向けに書かれていますが、情シスによる管理のコード化という観点からも非常に有用そうです。なお、この著者は1人で53p仕上げています。意味がわからない。怖い。
2章目はペネトレーションテスターなら一度は触ったことがあるであろうMetasploitのRPC APIの叩き方を取り上げています。Pythonクライアントを使って、効率的なペンテストをやりたいかたにはうってつけではないでしょうか。私はGolangで叩いて見ようと思いました。
そして、情シス待望の書が3章目です。みなさまの社内セキュリティはどのような環境でしょうか?USではネットワーク境界でセキュリティを担保しないゼロトラストネットワークスというアーキテクチャが主流になりつつあります。特にGoogleはそれに関する論文を「Beyond Corp」という名前で出すほど進んでおり、VPNに頼らない社内アクセスを実現しています。本章はその論文を日本語にまとめたものです。
最後の4章「相互連携する金融時代 - FAPI the Security」を私が執筆しました。まだ登場したばかりでその将来性は未知数ですが、いままで1サービス内に閉じていた金融系の経済圏をよりオープンにするにあたって策定されたFinancial API(FAPI)のRead Onlyなセキュリティ仕様を、OAuth 2.0やOIDCのrfcとともに読み解いたちょっと頑張ってしまった作品です。
この用に様々な、かつ尖ったセキュリティ技術の知識を結集させたものが、新刊「俺らの愛したセキュリティ」です。内容がわかったところで、次はどのように本著を作成から販売までしたかご説明します。
サークルとしての活動
メンバーに声をかけたのは大体1月です。しかし、私自身の転職やDroidKaigiでの講演により、本格的な方針を決定したのは2月中旬ぐらいでした。そこから各々が原稿をRe:Viewで書き、4/21にマージ・販促体制を構築し当日に臨みました。方針は次の通りです。
- 電子書籍オンリー
- ダウンロードカードによる配布
- 1000円
- 表紙担当を起用
電子書籍オンリーにしたのは、主に2つの理由があります。まだノウハウがないのに、期待値とことなる分量によって在庫リスクが発生することを恐れたを抱えたくなかったことが理由の1つです。もっと大きな理由は、ハードを準備することで圧迫されるスケジュールが大分厳しかった事です。正直、創業2年目のスタートアップに転職したてで、サークルのマネージメントに割く余力はなかったので、これはただしい判断だったと思います(そもそもマネージメント苦手です)。
ダウンロードカードを準備したのは、前回の反省からです。前回も電子書籍オンリーでしたが、QRコードを購入者に読み取ってもらう販促形式でした。これは意外と時間がかかります。それぞれのカメラの精度が異なりますし、混雑を極めている中でパラレルにさばくことは困難でした。何より①スマホを取り出す②アプリを立ち上げる③照準をあわせる④読み込む、とアクション数が多くなります。他にも、読み込んだあとなんらかの拍子にダウンロードをできなかった場合、支払った料金がむだになってしまうリスクがありました。
そういった反省から、1000円札と 交換する
形で入手できるダウンロードカードにし、これらの課題を解決しました。ただ、予想よりずっと来場者が多かったため、途中でダウンロードカードがなくなり、急いで擦りに行くという見通しの甘さを露呈してしまいました。次回のイベントに活かそうとおもいます。
また、前回は500円でしたが、今回は1000円にしました。これは価格そのものより、やはりオペレーションの観点からの改善です。基本的に1000円で支払う人が多い(という印象をもっている)技術書典で硬貨を使うと、お釣りが財布を物理的に圧迫します。
また、お釣りをわたすことはそれだけ価値交換のプロセスが多くなることだと思います。従って、人口密度の高いところではUX的に良くないと判断しました。技術書典はお祭りなので、出店から出店にすぐ移動できたほうが良い体験ではないでしょうか? そういった体験を考えた結果、一枚の交換券だけで欲しいものが手に入る方式にしてみました。こういった価格設定と先述した配布方法により、まあまあの体験を提供出来たかな、と思っています。
尚、公式から「後払い」アプリがリリースされていましたが、アプリ支払いと現金払いからみると、売上的には 2:8でした。後払いアプリもモダンではありますが、①スマホ取り出しからの④読み込み⑤それをサークルにみせて⑥サークルはそれを渡す、という手続きを踏まねばなりません。その点、現金は①千円を取り出す②渡す③サークルは本を渡す、とスピーディーです。したがって、しばらく現金前提で販売するのが良いな、と思いました(もちろん、後払いは引き続き利用)。
表紙担当としては、今回、正式にデザイナーさんに依頼をしました。まあ、現職の同僚なんですけど。サークルのコンセプトを伝えつつ、表紙のキャラをシャチにしたい、という良く分からない要望を、完全な形に落とし込んでくれました。ありがとうございます!お陰でサークル近くにおこしいただいた皆様が歩を止めて、興味を持ってくれるようになっていたと思います。
しかし、どちゃくそ格好よくないですか?シャチの可愛さとかっこよさが見事に共存していますね。青の濃淡をつかいわけることで、シャチが推進の浅いところへダイナミックに3D移動することを表現しているようです。他にも細かいセキュリティ関連のアイコンがキュートすぎます。凄い。すごすぎる。
最後に
もっと「このブースに寄ってよかったな〜」と思えるような体験を作ろうと思っています。具体的にはダウンロードカードをリッチにしたり、物理本を出すことです。先述の通りデザイナーさんに入ってもらうなど、一見して手にとりたくなるような体験を作って行くと同時に、セキュリティといえば「シャチ本」と誰もが思いつく世界にしていきたいと思います。
以上、今後とも宜しくお願いします。
P.S
- 販売数は336部。前回は90部くらいでした。
- シャチは私の趣味です。
- Boothでのダウンロード販売に向けて動いています。
DroidKaigi2018で発表した内容の補足とスタッフとしての役割
DroidKaigi2018でスピーカーとして「認証と認可と君と」というタイトルで話してきました。
また、併せて微力ながらもスタッフとしてお手伝いさせていただきました。
スピーカーとして
さて、技術的なところは今後ステップバイステップでコードともに説明していくと思うので、本稿ではエモいパート(序盤と終盤)のところのフォローをしようと思います。
序盤のエモい部分
序盤は何故、@ken5scalがこのテーマを攻めようと思ったかをFintechと業界絡めて話しています。 金融APIに求められるセキュリティ~APIDays Paris講演より|2017年2月号|金融ITフォーカス|刊行物|NRI Financial Solutions
上記の記事にある通り、Fintechという金融ビジネス上のイノベーションで、注力されようとしている分野は3つあると言われています。それが1) AI 2) Blockchain 3) オープンAPIです。その中でも特にオープンAPIに注目しています。企業単体ではできない・持てない価値を交換する窓口および経路として、シルクロードのような存在になると思っているからです。
そんなAPIを安全に守るため様々な対策が必要なのですが、そこで重要なのが認証と認可です。アクセス制御として第一の入り口となる認証・認可こそオープンAPI時代の要だと思い、今回のDroidKaigiのテーマとして取り上げさせて頂きました。
終盤のエモい部分
いくらOAuth2.0やFIDOを実装したところで、リスクから解放されることはありません。それぞれの仕様を安全たらしめているものがいつ危殆するかわからないからです。従って、目を光らせて最新の情報を追わなければなりませんが、既存の仕様を理解しつつ、常に最新を追うのは、これはなかなか骨です。そこで仲間が必要になるわけですが、なかなかセキュリティと開発が交わるチャンスは少ないです。願わくば、本セッションを通じて、すこしでも認証・認可について面白いと感じて頂いて、価値をユーザーに安全に提供するための仲間になっていただければ幸いです。
スタッフとして
相変わらず最高のチームでした。そんなチームですが、一端の中小企業の規模になりつつあり、参加者様も過去最多になりました。そのような状態で、どのように円滑・安全に運営していくかが、今後のワイの仕事になりそうです。 宜しくお願いします。