情報収集 - 2020/11/17

今週のおすすめ/一言所管

PPAPの廃止をデジタル庁が謳ったが、場合に応じた考慮をしたほうがよさそう。

PPAPが効果を発揮するケース、しないケース

PPAPが効果を発揮しないケースのが大半だが、するケースもある（例: 手動での別途送信）

とはいえ、行政がイニシアチブをとって動いてくれるのであれば、その意気や良しなので、大義名分に使いつつ自組織の文脈に当てはめるのがよろしかろうと思う。

三菱電気とLiquid（取引所）のインシデントは次回のものにまとめます

MS365 office365に2つの新機能。priority accountのタグ付と、タグ付きユーザーのmail flow監視。

後者はquarantine機能への統合など今後は機能が拡張される。良さそう。

なお、そろそろ情報取得コマンドはpowershellだけじゃなくkqlも記載してほしい

Windowsの次世代security processor Pluton.

従来のTPMとは異なりcpuにビルドインされるためサイドチャネル攻撃などの物理攻撃への耐性が向上。

Firmwareアプデがwindowsアプデに組み込まれる。

deliver on a chip-to-cloud security vision、SHACK, project Cerberusが気になる

ナデラが直接retweetしてた

defenderでexchangeとteamのイベントをkqlでとれるようになった。やったね。

CloudAppEventsテーブルの爆誕。

2021にはシェアポ系が追加も。AppFileテーブルの置き換えで、基本mcas上で取れている情報以上はトレなさそう。

MS365 DefenderがLinux向けEDR機能をPreview

AthenaのFederated SQL Query

データソースを連携して、複雑なパイプライン構築 -> 抽出 -> 変換という流れを作らなくて良くなる

Athena Query Federation SDKで、データソース生えのコネクタを構築して、Athnenaからクエリを発行可能

東京regionはまだ

リクエスト数や同時接続数からの外れ値が発生したホストへの対応になるサーキットブレーカー機能を搭載

AWS Kinesis FIrehorse経由ではなくCloudwatchのようだ

AWS SSOかActive DirectoryをIdentity Sourceとして利用しているときに、WebAuthnが使えるようになった

S3 storage lens. Org全体のs3バケットのメトリクスを取得。コストやデータプロテクション状態を含む。良さそう

CloudflareのサーバーHWにおけるSecure Boot。AMD使ってるみたい。

他のブログと違いビルドプロセスとテストについても書いてあって面白かった。

書き方がうまくて、on-chip rom off-chip bootloaderの違いがすんなり腹落ちできたかも

DIFとOIDCのコラボにより、OIDCのSIOP章（７章）のリビジョンが終わるまで、did-siop↓は停止に

UKデジタル庁長官によるスピーチ。Digital Identity Trust Frameworkのα番を公開するみたい

デジタルIDデータの利用状態のトレース

Selective Disclosureについて主に語ってる。あんまSSIっぽい話はしてない。

Personal Data Protection Act (PDPA)

新しくなったっぽい部分:

データ漏えい時の通知義務

同意とみなす行為

データ処理に関して合理的な説明措置が取られ、説明された個人がオプトアウトするまでに合理的な期間があった場合と、リスクと影響の評価を実施したうえでの影響範囲について決定できたら可能

同意対象外の内容

ShareRing: Tendermint上で構築された独自のレッジャー「ShareLedger」 && SharRing IDアプリでパスポート・滞在先情報を管理する。

チェックインの効率化が可能。ほんまか？

プライバシーの保護の向上や詐欺（なりすまし）対策が向上

他にも旅行系でSSIが増えているようだ

ランサム、初期時の当たるも八卦状態から、より標的型のexecution段階に段階をシフトしてきてる気はする

パスワード付きZIPファイルを使った攻撃の例もあるよって話

オストリッチZIP: メール添付ファイルを暗号化ZIP化しパスワードをメール別送するZIP。要はPPAP

利点と欠点から、利用環境の整理、漏洩事象モデルを構築し、漏洩確率を評価

オストリッチZIPは条件付きで高い

誤送信に別送前に気づいてパスワードを送らない確率が高いことが条件

また、暗号化ZIPをパスワードを知らずに解析できる確率が低いことが条件

総じて、オンラインストレージ利用と漏洩確率は変わらない

オンラインストレージは送信後の情報コントロール権を送信者が持ち続けられることが

パスワードを別経路で送れば、漏洩対策は高い

一番冷静な資料かも

決済サービスであるGoogle Payに「プレックス」呼ばれる銀行口座が統合される

決済ビジネスの行く末

既存銀行プレイヤーのサバイバル方法 -> It勢との連携（中途半端であるとの指摘も）

香港で広まる仮想銀行

大手も仮想銀行を意識して、スマホ口座開設・非店舗型口座解説をするなど

行政/会社/団体

FeliCa-SEチップの利用

令和4年度内にAndroid端末搭載を目指す。2年間での法整備。実証実験やシステム構築が行われる予定

スマホのライフサイクルへの対応も合わせて検討される

key recoveryの話

廃止後どうするかは未定っぽい

プライバシーマーク制度では上記の方法による個人情報を含むファイルの送信は、メールの誤送信等による個人情報の漏洩を防げないこと等から、従来から推奨しておりません

いつか導入したくなるかもなのでメモ

ローカル認証の強化に3,400円/台はらうか...というのは迷いどころ

Device Authorization Grantっぽい

goccy/go-yaml　が神らしい

port7777

イベント/勉強会/発表資料

後で読む

以下がコア

Protection from Unauthorized Access

Immutability

Availability of services, tooling and content

Auditing and Accountability

どこを見て追うだけではなく、文書の読み方や、調査指針もかいてあって非常に参考になる

永久保存版

DBインターフェースを作らなかった理由は以下

Mockに信頼性がないわりに手間

LocalStackという外部モックでまかなえる（デメとしては外部サービスにテストが依存する.など）

gocloud.devでもいいかも

handler, dbは非struct。関数だけ提供。良さそう（デメとしてはテストごとにDBを切り替えることは難しい。例: 接続Failする異常系）

UseCase層を排除

全体的によさそう

余談だけどTerraformファイルもだんだんフラットになってきた

件数はめちゃくちゃ多いものの、情報種別が限定的なのがなんだろうという感じ

ユーザー認証的なマイクロサービスがあって、そこだけSQLIとかでぶっこ抜かれたとか？

個人に来たメールから以下がわかっている（画像後述）

10/16~10/17に漏洩、11/9に漏洩認知

上述の通り漏洩経緯は不明、認知経緯も不明

最大677万件が氏名、メアド、暗号化パスワード等が漏洩

クレカ情報、口座情報、決済情報、参加履歴、電話番号、住所は対象外

現在も調査中

身代金を支払う組織: 全体の30%

何人ぐらいの組織なんだろ

次回まとめます

その他

ken5scalにPeatixから送られてきた謝罪文

https://gyazo.com/0d8db870d05947c054f139ef8591aff2