議事録

第6回議事録

概要

• 2018/3/15 8:00-9:30
• 参加者：楠，萩生，肥後，佐藤，島岡，杉井，中島，山崎，須賀，加納，小宮山，岩下，小川，丸山、原島、樋田、鈴木, 上原，松尾，林

agenda

1. Agenda Bashing, Note Taker
2. Status update
3. 過去議事録の確認・承認
4. Security WG Item
   1. Objectiveについて
   2. requirementsについて
5. TF Future plans
6. AOB / Housekeeping
7. Tasks and To-Dos

議事サマリ

agenda1. Agenda Bashing, Note Taker

agenda2. 過去議事録の確認・承認

• 第3,4,5回議事録：承認

agenda3. ステータスupdate

• TFについて：なし
• WGについて：個別mtgなし
• リエゾン進捗：なし
• 関連団体で１点。
  • 金融庁で研究会が始まるのが4月半ば。
  • http://www.fsa.go.jp/news/30/singi/20180308.htm
  • 4月中に開催。月2回くらい
  • 業界団体はオブザーバーとして参加。
  • 岩下、楠も参加
• 業界団体(新団体)
  • 報道通り新団体の設立の合意に至った。既存の2団体が残り、JBA/JCBAで新団体。登記や規約の整理など組織作りをやっている。奥山さん、加納さん。理事数人、監事、事務局長などを決める。発表から1ヶ月以内。

agenda4. WG item

• 提案

  • Objectiveをまとめたものについて共有
  • requirementの文書について共有

• 議論を経てのコンセンサス

  • スコープ
    • 広げすぎない。適宜別文書など。当初のものを書き上げることを優先。
  • 責任分界
    • 6章のリスク評価が表裏一体。ここからのアプローチで。
  • FISCとの連携
    • 仮想通貨交換事業者が、FISC会員になり連携を探る道がある
    • 適宜落とし所を探っていく。
  • セキュリティとセーフティ
    • 参照している他の基準などは、セーフティが主。
    • 外的なサイバーセキュリティの脅威への対処が必須なのが、今回の特質であるが、チャレンジングだが一歩ずつ積み上げていく。
  • チェックリスト
    • 第2フェーズ以降で取り組む。
    • 形骸化しがち、一方で、事業者に伝わらない。バランスを探る必要がある。
  • ISOのテクニカルレポートでの言及
    • 問題ない。

• 議論サマリ

  • スコープ
    • 5章のモデルでは、現状、取引所の中の話を書いている
      • 顧客の本人確認や認証、アプリケーションの脆弱性、API他を入れるのか。
      • 1案は、5章では外の話は別スコープとして別の文書に分ける。別案、網羅性の観点で触れておいた方が良かろうとことであれば、顧客の関係性については、簡単にでも触れておく。参考文献のポイントのみを触れる程度にする。
    • 深堀りせずに分ける方が良い
    • 取引所システムとして触れた方が良い部分はある程度ある。
  • 責任分界
    • 業者が負うべき責任はなんなのか、責任分界点はどこか、の2点が、Objective、スコープと強く関連する。
    • 責任分界は顧客保護のためなのだが、取引所も法廷で紛争解決する時にどうなのか、そこに倣う形になる。
    • 銀行における歴史。これまで銀行が対策を怠ってきたから、全て保障しなさい、そういう流れになってしまった。
    • 銀行みたいに全部銀行が悪いとしてしまうと、業界が伸びない。預金の場合は、法律になってしまっているので、事業者に不利になっている。教育までしっかりやれば、事業者に行き過ぎない規制になる。
    • 法的責任範囲についていうと、微妙な論点が出てきたことは明らかであるが、この文書においての責任分界の話には、補填については入ってこない。
    • 議論するときには仮想通貨の特異性を忘れないでほしい。
    • 文書のスコープの外縁を定義するためには、日本におけるリーガルリクアイアメントを意識しないといけないことはあるかもしれないが、実際、このドキュメントで規定したいことは、万国共通のテクニカルリクアイアメントに絞るのが良い。
    • 誰に対して責任を負っているのか、大目標と、6章のリスク評価が表裏一体。
  • FISCとの連携
    • FISCに仮想通貨の事業者が入ってくるのはありえると思う。今は会員の対象外だから、手を出せない、やりようがない。FISCも悩んでいる
  • セキュリティとセーフティ
    • FISCはターゲットとする取引が、お互いが完全に了解している前提のもの。レガシーなクローズドなネットワーク。外部からの脅威よりも安全。
    • ソースコードのコントロールが必要
    • セーフティは想定内でいかに安全にするか。セキュリティは想定外も含めて。
    • 今あるFISCやPCIDSSが仮想通貨におけるリスクを全て網羅していないということは明らかになった。自分たちで考えていかないといけない部分は多い。ISO27002も含めて、セーフティがメイン。どうやってPDCAを回していくか、であって、外的なサイバーセキュリティの脅威への対処は本当にこの10年くらい。そこはチャレンジングだが、一つずつやっていく必要がある。
  • チェックリスト
    • 当初は、考え方のみ。次のステップで、チェックリスト的なもの。積み上げていかないといけない。
    • チェックリストとかガイドライン、としてしまうと、それをやっていれば良いと思われてしまいがち。あるコントロールをいれたから、あるobjectiveを満たす、という構造のものはない。
    • 最初は自己宣言にしかならない。ことが起こる、とか、あそこが怪しいという指摘や通報があった時に、認定自主規制団体なり金融庁なり踏み込んで、「これやってるって書いてあるけど、実際どうやってんの」と言うことが、実際のFISCの運用としては行われている。
    • 今の銀行におけるFISCの運用の実態は、ややもすると形式論になってしまっている。ちゃんとやりましょう、一体として底上げしていこうという機運が大事。
    • 抽象的に書いたり、粒度が荒いと、何も伝わらないし、何の変化も起きない。チェックリストが形骸化するのはわかるが。
    • そのチェックリストを全体に対して作っていこうとすると、結構な仕事量。
    • 銀行があんまり参考にならない。FISCが安対基準を直すと同時に、機械化通達も直し、機械化通達で認めたところを安対基準の中に書き込んでいく、と言うプロセスを何十年にも渡って続けてきたので、業務と安対基準とがリンクしているものができた。仮想通貨は、すでに取引所が存在しているところから始まる。そこに対して整合的な安対基準を作るという機能は、今のFISCにはない、と言うのは事実。
  • ISOのテクニカルレポートでの言及
    • 佐藤さんのやつが現状いい。その中身をいくつかテクニカルレポートのドラフトに入れようかと思うが、よろしいか。著作権の話。
    • 問題ない

• 時間切れのため、終了