情報収集 - 2020/09/14
資金移動業者 <-> 銀行間のセキュリティインシデントは別途まとめたので省略]
KPLアグリゲーションとzlib圧縮がサポートされてログ転送コスト(kinesis取り込みデータ量)が低下
Cloudwatch周りでグループ名やストリーム名、retension設定あたりがfluentbit.confに記載できるようになった
AWSのGremlinやChaos Monkey
SSM経由でKotlinコードを実行し、リソース枯渇、低速ネットワークのシミュレーションを実行する。
ECS on EC2/Fargateもサポート。Lambdaはサポートしていない。
FargateはMemory Hog ,CPU Hog, DIsk Hogのみ(Fargateはmanaged clusterなので)
ProlerやScoutSuiteを使って、Self Serviceなセキュリティ診断をできるようにするツール
カスタムモジュールを追加できる構成になっている(今はランサム系のモジュールのみ存在)
しかし、継続的モニタリングには Security Hubの Foundational Security Best Practices しろ、と書いてるので、そちらで十分な気もする
Amazonのチームはどのように継続的デリバリーを行っているか
testステージがあって、そこで機能テストとか統合テストをやってる。ロールバックもする。まあ、Runtimeに使うImage Scanはここにおきたいね。AquaのTraceeもここじゃないかな。
bake timeというのがあって、そこでslowly burningをするchaos engineeringっぽいことをやるみたい
コードレビューのチェックリストがあって、「現在の監視で対応できるか」とか「リソースへの影響はあるか」とか「ロールバック可能化」「依存モジュールはインストール済みか」など担っているのが面白い
いろいろあるけど、Preview機能にEDR遮断モードのリリースがでかい
MDATP for MacがBig SurからKernel Extensionがなくなり、System Extensionに移行するため、mdatpによるネットワークやファイルを裏側で許可している場合は要注意
最近SIEMについて思いを馳せているが、AWS上のmanaged ELKにするか、それともAzure Sentinelによせるか...
どちらもやってみるか?
DID AuthNを独自で作るんじゃなくて、まずOIDC SIOPにのることにしたよ、って話
図があるけど、ちょっとこれだけじゃわからんw
Bug Bounty Findingsの章からがおもしろい。筆者がみつけたOAuth2.0の脆弱性
認可サーバーのredirect_uri設定のチェックが弱い
一番おおいのはやっぱりstateをクライアント側で使わないこと。具体例があってまずさがわかりやすい
アカウント登録じにメールverificationがないRP。事前に被害者のメアドで登録することで、被害者がOAuth連携したときにアカウントをダッシュできるかも
Identity周りの侵害が増えている
GoogleのOSS向けFuzzingツール
OSSそのものにうめこむのではなく、GoogleのFuzzingサービス for OSS
登録するとcommit時に(Googleの?)ビルダーがFuzzing対象をGoogle側に登録することで、診断が実行される
診断され問題があった場合はOSSのオーナーに通知が転送される
issue自体はgoogleのtrackerに登録っぽい
Mitre Att&Ckみたくインディケーターより挙動(Behavior)に注目している
ECS(Elastic Common Schema)によるデータソースに依存しないロジック
名前の通り
DockerだとGame of ThrosesやDonkey DOckerがある
Mitre Att&CKのTacticsごとに対象のWindowsイベントログをサンプリングしたリポジトリ
C&Cとか、Credential AccessとかExetionなどなど。こいつをdetection ruleにすると良さそう
余談だが統計的にはどのTacticsもだいたい似たような量になっているので、ナニカに焦点をしぼるより、全Tacticsを特定の攻撃に絞って改善していくのが、Blue Teamのスケジュールとしては良さそう
Winlogbeatで集めてるっぽい。やっぱWindowsのログコレクターはwinlogbeatが標準になりそう
恥ずかしながら、まだ原文にあたれてない(し、時間もないので)今は、こちらに頼り...
TTPの収集や防御を能動的(Adaptive)にやるためのフレームワーク
Att&ckと紐付いてるため、攻撃手法に防御手法を紐付けられるのがやりやすい
ShieldにもTacticsがあるが、これは防御のためのTactics。攻撃経路を複雑化させたり、攻撃内容をどう認識するか、、、とか。攻撃者を騙す...という観点もあるのがおもしろい
システムやサービスに対して、設計の評価や検証とタスク計画を、セキュリティとエンジニアチーム間で推進させるプロセス
最低でも3つのゴールを満たすべき
アーキに対して、全員がどううごくかわかること
(Surface Areaの評価をしたうえで?)Compromiseさられるポインtのがどこか全体的に評価すること
緩和戦略と優先度を作る
GitHubでは、数ヶ月ごとあるいは年1で、開發チームやメジャーバージョンアプデの前に実施(複雑性によって頻度をかえる)
security <-> engineeringチームで顔を合わせて確認するまえに、engineeringチームでまずモデルしてもらうみたい
GitHub内のDevSecOpsのやりかた。OWASPのDSOMMフレームワークを利用
モルスタ : ハードウェア処理の委託先からの個人データの流出。集団訴訟をうけている。 サクソバンク証券: 委託先が不正アクセスを受けて個人情報漏洩。金融庁から業務改善命令 野村證券 従業員が、法人顧客275社に関する取引内容を、別証券に漏洩。2次流出は未確認 不正ログインと思われる件数は年間平均でおよそ0.3% -> 大型連休がある1月、4月、8月、9月、12月は、この数字が0.7%
夜間が多い
口座転売
地銀の遅い・予算のないインターネットバンキング化
ベンダー依存
顧客リスク格付けを営業店頭で実施
リスクに応じてKYCフォームの更新を依頼
上記をミドルオフィスからフロントの顧客部門に設置・対応
まあ、G-SIFSだからね
増すAMS/CFT対策コストに共同で対応する
全銀 -> 顧客情報収集を既存のCNSの枠組みを使う
地銀9行(like 千葉銀行)はTSUBASAアライアンスのAMLセンターで、マネロン対策の企画立案
あるいは海外為替を縮退する
取引監視: 例えば「顧客の職業や年収、事業規模と照らして過大な取引ではないか」「通常の取引形態と照らして不自然な取引となっていないか」「不稼働口座に動きがないか」
顧客接点: コールセンターで事情を踏まえつつ説明
その他
Spinnakerはしばらく触る予定はないのでスルー
OpaをConftest(CI)とk8s Admission ControllerのGateKeeper(ランタイム環境のクラスタ)で実装
前者はapply前のフィードバック取得、ベスプラにキャッチするための検証が主眼
一方、後者はapplyされる前に、確実にみたしてほしいPolicy
ただ、Audit機能を見る限り、デプロイ自体はされてよい。ただ、ワークロードへのapply前...ということ
共通基盤を作る上でのshould と should notがawsの事例をもとに整理されている 。よかった should:
適切な粒度の課題設定
共通基盤しゃサービス
困っていることを仮設をたてて聞く (くりかえし)
原因と解消方法も仮設をたてる -> ホワイトボードやドキュメントレベルで提案して、フィードバックをもらう
最初にプレスリリースを書く、事前想定FAQを作る
MVPの実装と効果測定の指標の用意 & 提供
should not:
欲しい物をきかない
原因と解消方法の提案時に、実装はしない