忙しい人のためのセキュリティ・インテリジェンス - 2021/02/08
今週のおすすめ/一言所管
GoogleがOSV(Open Source Vulnerability) を公開。OSSの利用者が、どのOSSに影響をうけるのか自動的に把握・判断できるように支援する脆弱性データベース。日本だとVuls等があるが、情報量が多いと言うより、自動で脆弱性の修正状況のトラッキングとかポリシーとかがあると嬉しい Termporary Access Passという機能ができたみた。
読んで字の如しだが、一時的に今まで管理者が払い出せていたパスワードとどう違うのだろうか :eyes:
Compliance
他
AWS CloudHSMが東京サポート
Amazon Timestreamは時系列データベース
目的はアプリ監視、エッジワークロード(デバイス?)とかも?。
安いらしい。東京はまだない
Google
日本は米国とイギリスについでフィッシング・マルウェアキャンペーンの対象になってた
日本の場合は、その送信元の78%が日本。ほー
短い期間のキャンペーンで、共通したテンプレを大量の相手にばらまく
「k-匿名性」で、攻撃対象になりがちなユーザー傾向を分析
他サービス漏洩で電子メールやその他の個人情報が漏洩すると、フィッシングやマルウェアの標的にされる確率が五倍
地理的要因あり
高年齢層がたーげっとになりがち
モバイルユーザーより、マルチデバイスユーザーのが多い
マルチデバイスがより裕福とみなされ、ターゲットにされてるのかも
google groupのタイプをAPIでかえることで、security groupにできる
ラベルをつけられたり、外部グループを追加できなくすることができる
ラベルは消せない、って書いてあるけどほんまか?
google groupのメンバーシップに有効期限を設定できるように。
異動における引き継ぎとかに役立ちそう
電子的識別と電子署名のための技術的・法的枠組みをeIDASは提供する
金融サービスでは以下の商用利用が考えられる
Full Trust SP: 自前ホスト
Trust SP light: リモートシグネチャ as a service
署名SP: APIをつかってサービスを使う感じ。
金融サービスは署名SPとしてRA(registration Authrotiy)になる。そしてTSPのAPIを叩く。顧客とのpoint of contactになるため、法的責務もここに集約される
NISTによるAuthenticationのオントロジーと分類体系
Contrlled Unclassified Information (CUI)のNon-Federatel agencyの取り扱いについてまとめあSP800-171の補完版
大きく3つの状況を想定
1. 情報がagencyのシステムに常在している場合
2. agencyが政府に変わって情報を収集・管理していない場合
3. CUI保護の要件がない場合(171がカバーしない.?)
住基ネットへの訴訟(合憲判断)や個人情報漏洩の不安をもとにした離脱から、マイナンバー制度設計は対応策を徹底
個人に関する情報を各期間で分散管理
マイナンバー利用可能な事務を限定
カード情報を限定(カードリーダーを使ったり、証明用と署名用でパスワードを分けたり)
が、やりすぎて、非常に使いにくい
マイナンバーカードについても、電子証明で本人認証させたいのかなど。スマホでもできるようになるので
愛知県に提出された大村秀章知事の解職請求(リコール)の署名の83%に無効の疑いがあると県選挙管理委員会が発表
wow
デジタルIDには、信頼性を提供するという「トラストアンカー」としての役割だけでなく、それを活用するための「トラストサービス」としての役割が求められる。そこで民間デジタルIDとして、「各種法令に準拠したオンライン本人確認」「複数要素による安全な当人認証」および「法令に準拠した電子署名」を提供することによって、サービス事業者が容易に実装し、電子証明書というトラストサービスというトラストサービスを使えることを可能にする
eシールの定義
電子文書等の発行元の組織を示す
また、発行元を示した後に、文書等が改ざんされていないことを確認する仕組み
3つのレベルがあって、レベル2が技術レベルを担保できるもの。レベル3はトラスとアンカーとなりえるもの。レベル1はそれ以外。
ユースケース図
https://gyazo.com/6cfff561a6d550852529ceb78dea4b19
セキュリティが意味するところは、CIAを確保する情報セキュリティから、サイバー空間のサイバーセキュリティへ
2社間での相互信頼が、複雑するサプライチェーン構造によって成り立たなくなっている
「データの信頼性」が重要
Metiではそれを守るために「サイバーフィジカルセキュリティ対策フレームワーク(CPSP)」を策定
3層構造
サイバー空間におけるつながり: データの信頼性
フィジカル空間とサイバー空間のつながり: フィジカル <->サイバー間のデータ転写に関する信頼性
企業間のつながり: マネジメント(ISMSとか)を基盤に書く主体の信頼性
6つの構成要素
組織、人、モノ、データ、プロシージャ、システム
トークン設計と管理に関する技術的概要のドキュメント
トークン、ウォレット、トランザクション、UI、プロトコルに関するフレームワークチックなドキュメント
MicrosoftのOfficeにたいするフィッシングサイトがFirebaseでホスティングされてるって話
Googleサービスを使うことでドメインの正当性が高められる。AWSでも起きそう
SaaS上のデータ侵害を検知するまでに平均で約200日
どうするか?
monitoringするだけでなく、セキュリティスコア(security rating)による継続的なリスクとイベントの監視が必要
以下のActive/Passsiveスキャニング
Injection Attacks, Broken Authentication, Sensitive Data Exposure, Security Misconfig, XSS, Insecure Deserialization, Using components with known vulnerabilities, etc.
自動化されたリスクアセスメント
MLのアルゴリズムやモデルに対する脆弱性報告はあるものの、それを運用するメンツと管理方法について騙ったことはないよね、ちょっと思考実験しようか的論文
CERT(運用サイド)が著者
MLシステム運用者と脆弱性管理者の間のコミュニケーション領域(trading zone)を確立させることが目的
そのために、共通言語?(“boundary objects, value of item)にCVE-ID使おうぜ、というやつ
MLシステムそのものにCVE-IDをアサインされる状況を考える
発見、レポート受理、分析、協力、公開、対応というオペレーションに関するCVE-IDをもとにコミュニケーションしようというやつ
参考文献の「Enhanced Cyber Threat Model for Financial Services Sector (FSS) Institutions.」が気になる
Threat Hunting, Threat Intelligence, Honeypotのノウハウ p120越え
7割 Threat Hunting, 2割 Threat Intelligence, 1割 Honeypotみたいな配分
Proactiveなdefenseテクだが、その本質とは defenses that increase costs to cyberattackers by reducing costs to cyber-defenders. らしい
手法としては、High Impact ActivityをFrequentにチェックするところから開始
Threat Huntingのプロセス、成熟度、フレームワーク、種別、ユースケースが豊富に紹介されていて、勉強になる
↑の補助資料。ベンダーの資料なので、conclusionは「うちの製品つかおうぜ!」
成熟度フレームワークはこちらのほうがわかりやすい
脆弱なやられアプリ DamシリーズのGraphQL版
別に誰かがDamn Vulnerableの商標をとってるわけじゃないけど
OAuth2.0の脆弱性シリーズ
テスラが$1.5billion分のビットコインを購入
それに伴いBitcoinが500万超え
CBDCは価値の貯蔵・移転をする決済手段である一方、物理的な外観をもつ通貨
通貨も社会のニーズや期待を反映し、設計変更や多様性が求められる
民間発行通貨 is ...?
行政/会社/団体
いい話だった
アメリカにもデジタル庁っぽいのがある -> United States Digital Service (USDS)
その組織にエンジニアをリクルートした時の歴史とやり方:
シリコンバレーの会社を一社一社行脚して、healthcare.govの話をし、USDSの話をし、現在アメリカの様々な省庁が抱える様々な問題の話をし、そこで活動することの意義、人を救える、人の命を救える、そんな数々のプロジェクトを紹介し、「USDSに来て手伝ってくれ」というリクルーティング活動を丁寧に絶賛行っていました。
小さな成功の積み重ねと、トラブルを体験してそれを一つ一つ解決して成功に導いていくことで、デジタル庁という組織が強くなっていくと思うので。デジタル庁で働いてようと働いてなかろうと、国民みんなが暖かく見守り、できることを支援していくべきだと思います。失敗を恐れて、役に立たないけど安全パイなプロジェクトだけやってても、デジタル庁を作った意味はない
1. Understand what people need
2) Address the whole experience, from start to finish
3) Make it simple and intuitive
4) Build the service using agile and iterative practices
5) Structure budgets and contracts to support delivery
6) Assign one leader and hold that person accountable
7) Bring in experienced teams
8) Choose a modern technology stack
9) Deploy in a flexible hosting environment
10) Automate testing and deployments
11) Manage security and privacy through reusable processes
12) Use data to drive decisions
13) Default to open
cloudfrontのcache_policyおよびrealtime_log追加
realtime log, kinesis firehoseにダイレクトでおくれるようんあんねーかな
configのconformance_pack追加
securityhub_organiztion_admin_account追加
Gitlabがaqua -> trivyに乗り換えようとしてるっぽい
IstioのAuthorization PolicyでないAuthorization Policyをやる場合
OPAものっている
開発者はPredicioのSDKを購入してアプリに組み込むことで、ユーザーのいち情報などを取得できたが、
同時にPredicioがその情報を移民管理局や税関・国境警備局などに売っていた
Googleは、そのSDKを月曜までに除外しないアプリをPlay Storeから外すと宣言
LinkedInのSRE カリキュラム。GitHub上でOSS化されている
内容
Linuxの基本、Git、Linuxネットワーク
PythonとWebv
データ: RDBMS, NoSQL, BigData
システムデザイン
セキュリティ
Writing Secure COdeにUnit Testingあるのがいいな
広報から経理、労務、総務を始めた同僚の話。最近は、社内システム周りの仕事も頼らせてもらってる
労働集約的な業務からの開放へ
Bazelにfuzzingの開発とテストをする機能が埋め込まれた
rules_fuzzing extension libraryを使う
開発者はfuzzドライバコードとビルドターゲットを書く
OSS-Fuzzとの連携もビルドインでサポート
Envoy proxyで実績あるよ
イベント/勉強会/発表資料
コレ全部Go Securityっていうのはちと雑な気がするが、go buildのオプションが勉強になった
やっぱConftestだよな〜
GitHubのデプロイプロセス構築までの道
まずは、デプロイ後の正常動作までの時間、ロールバックの頻度、手動作業時間に関するデータの収集
以下のメトリクスで計測
CIビルド時間、デプロイパイプラインの各ステップ時間と総時間、デプロイパイプラインの最終状態、ロールバック数、ステップのりトライ数
デプロイ・マージしたPR数/week
mergeされたpr数
SLOも設定
Webアプリと揃える
APIとしてJSON形式で返す
認可リクエストをセッションに紐付けつつリダイレクト
セッションを検証しつつコールバック処理を行うエンドポイントが必要
3兆円規模の売買機会が失われたとされる
ICSに対する不正侵入。やばい。こういうガチにやばい奴はまだ聞いたこと無いかも
全PCは、32bit版Windows 7
全PCが同じパスワード
第三者が容易に外部からインターネット経由でファイヤーウォールをすり抜けて侵入できる状態にあった
その他