忙しい人のためのセキュリティ・インテリジェンス No.31 - 2021/04/26
今週のおすすめ/一言所管
Compliance
Intune/Windows10
Secured-Core PCってなんのこっちゃっと思ってたけど、Secure BootやRemote Attestationを任意のタイミングで実行可能なDRTMを実現するためのHWをサービスとして提供するって話
が、各社ベンダーのサポート窓口がそういうのに答えられない、答えてくれないケースが多いのでニーズはありそう
以下が気になった
Locate device remote action for Windows 10 devices:
Widnwos10デバイスの位置情報がわかるようになった
位置情報サービスをオンにしないといけない
View end of support details for your feature update profiles
EoS情報が見れるようになった。イイネ...
Endpoint Manager > Reports > Endpoint Analytics > Proactive Remediations しらなかた
DetectionスクリプトとRemediationスクリプトつっこめるのか。これは...
他
ECS Fargateで、200GiBの一時ストレージが使えるように。
MLをするコンテナや、でかいDocker Imageを使えるように
AWS Nitro EnclaveがWindows on EC2でも使えるように
DRのための4つのストラテジ
Backup & Restore, Pilot Light, Warm Standby, Multi-site active/active
https://gyazo.com/70fbe9a6aabb0fc582629419e4cac662
本プログではBackupとRestoreまで
BackupはAWS Backup
RTOは、DisasterのDetectionからRestoration
Detection -> Escalation & Declartion -> Restoration/Failoverの順番
Eventbridgeとかやっていきましょうという話
従来のCyberKill Chainの各ステージおよび対策(course of action)を、クラウドネイティブ向け環境にあわせてメトリクス化
具体的には、Intrusion前と後でReconnaisance項目を設けたり、Course of ActionにResponse/Contain(隔離)/Restore(復旧)を追加したり
っていうか、こいつの真価はAppendixだな...
以下が気になった
Email threads with recipients outside your organization will be labeled “External”
組織外からメールがきたときに"External"ラベルがつくようになった
サービスaccountを使った認証のべスプラ in Google Cloud
そもそもユーザーの代わりにサービスが動く場合はサービス垢を使わない。OAuthを使う
gcloud, gsutil, terraformを使うときも同様
基本的にはサービス垢をComputing Resourceにアタッチするのが正しい
アタッチした後のaccess tokenの取得はクライアントライブラリを使うかメタデータサーバーを使う
もしGoogle Cloud外のリソースからGoogle Cloud APIを叩きたい場合は、workload identity federation を使う
ID Tokenがアレば使える
サービス垢keyは他にやり方がない場合に使う。ラストリゾート
https://storage.googleapis.com/gweb-cloudblog-publish/images/authentication_approach.max-2800x2800.jpg
クラウドは責任共有(shared responsibility)から運命共同(shared fate)だ!という宣言
shared fate -> 運命共同の訳はken5がしたもの
「Risk Protection Program」を他社とパートナーシップを組んで開始
他社 -> ミュンヘン再保険会社, アリアンツ
そもそもアリアンツとミュンヘン再保険会社が双子の関係にある保険会社らしい
具体的には「Risk Manger」という診断ツールをつかってセキュリティ態勢の診断をしたり
その診断レポートをパートナー企業に送って、サイバー保険「Cloud Protection +」につなげる
そんなサービス
コレ自体は3月のだった。まあいいや
TerraformでGoogle Cloudをセキュアにするためのモジュールが公式に提供されている
AWSもCloudFormationじゃなくて、Terraformで提供してほしいンゴ...
bootstrapにcicdとstate bucket, サービスaccount作成が入ってんの、とても高感度高い
続くorgでログ、ネットワーク、dns、ビリング、通知、vaultが入ってるの尊いな
そんなモジュールのver2がリリースされたよって話
Trusted Cloudの要件というのがぶちあがってる
透明性とSovereignty(多分、データ主権)を提供するセキュアプラットフォーム
データ主権はデータの制御権を持つ的な意味
ゼロトラストアーキテクチャ
責任共有から運命共同へ
ガイダンスやモジュールを提供してセキュアなDeployをできるようにする
セキュリティとコンプライアンスへの準拠管理を用意にするツールを提供する
カバーしきれないリスクを移転する保険プログラムを提供する
https://gyazo.com/538f5e1c7f7c47ea31a302797250aa10
https://gyazo.com/f88478f1688c0483b79a0cbee54890f2
Society5.0で紙の世界から電子の世界に変容するにあたり、既存のトラストサービスから利便性をあげつつ信頼性を損なわないようにするための情報整理
書面、対面認知、押印 -> 電子文書、電子認証、電子署名
トラストサービスの機能:
正当性(真正性 + 完全性 + 否認防止)確認: 電子署名(個人)、eシール(組織)、モノの正当性(IoT)、データ(eデリバリ)、Webサイト認証、タイムスタンプ(時間)
EUと日本を比較。
基本的に↑と同じだが、P31-p32のトラストの源泉について触れてることを覚えておきたい
法令 > 保証レベル > 標準 > 信頼点の公開という順番で信頼が紡がれていく感じ
2022年に施行される改正法でも(中略)委託先の安全管理措置を監督できていれば同意が不要な制度は同じ
同時に、個人情報保護委員会も、データの海外移転そのものに違法性はないとした
しかしながら、中国という国は、国家の情報活動に民間が協力する義務がある
つまり、そもそもの前提や土台が違う
そういう国に、個人データや機密性の高いデータ、重要な業務に関わるIT調達において、リスクを踏まえて調達先の国と企業を選べるようにしたい、、、という話
イデオロギー的な話でもありつつ、まあ、サプライチェーン内に中国が入ると企業活動できないかもよ、という警鐘でもある
経済安全保障を巡っては、米中をはじめとする各国が国家安全保障上の自国の優位性を確保するため、重要な技術やデータなどを得る動きを活発化
経済安全保障にも配慮して、プライバシーとセキュリティー保護のあり方、それらを実現するガバナンスのあり方についても提言を求められている
Operational TrustからTechnical Trustへのシフト
operational trust: compliance, rule, certification, training
removing people from security equation
data in rest, data in transitからdata in useの対応が必要
Rustのtips
不要なcloneを避ける
環境変数をoptionalとして扱う
_ を使って大きい数値を読みやすくする
unwrap より ? を使う
バイトデータを扱うときはvec だけでなく Bytes も検討する
enumのサイズは、構成子のデータ型によってきまる
LayerXの秘匿化(Confidentiality)&透明性(Exec Integrity)モジュール「Anonify」におけるRust開発について
Anonify: 機密性の高いデータを秘匿化したまま複雑な計算を実行可能。TEEをバックエンドにしてる
システム運営者も呼応激写も中身をみることは原則できない
Anonifyに対してAPIを叩くと処理結果飲みかえる
メモリ暗号化でConfidentiality, Remote AttestationでExectuion Integrity
上記の特性のため、システムコールなどの特権命令やlibc、stdが使えないつらい
一方、全てのAnonify処理がTEEでないこともある。暗号化はTEE外で、復号はSGX内で。
何も考えずに実行すると、std環境とsgx_tsd環境の差異のせいでコンパイルエラーが発生する
それを解決するために features というものを使っているという話
認知したきっかけは、操作ログが消えてたこと(攻撃社に消された?)
FileZenのゼロデイをついて、リモートからファイルを操作できた
不正アクセスが確認できたタイミングは2020/03
ディレクトリトラバーサルを元にしたOSコマンドインジェクションが対象の脆弱性
OSINT興味でてきた
CIツールのCodeCovに不正なスクリプトをいれて、外部アドレスに実行内容をアップロードしてた話
アップロード先のIoC、不正スクリプトの改変元のIoC、関連しそうなIoCが公開された
IoC -> IPアドレス
Initial Accessに必要な通信テク、Persistenceテクが書いてあって参考になる
マルウェアの侵害が始まってから気づくまでの中央値が10年間で416日間から24日間
ただし原因はランサムのような、気づかせないとならないケースが多くなったから、と見ている
行政/会社/団体
SP800-171では、管理すべき非機密情報(CUI)を扱う米連邦の契約事業者がすべきセキュリティ対策
例えばF35戦闘機の製造情報の10%は機密情報、他はCUIになる
172はその準拠状態をAssessするための評価手順
172Aは171のうちレベル4およびレベル5の評価手順
EUのデジタル統治(autonomy)/主権を支えるための研究の特定について
デジタルautonomy/soverigntyの定義
Digital Autonomy: 外部からの不当に影響されることなく、価値と要求に従ってプロダクトやサービスを提供できる能力のこと
Digital Sovereignty:
個人による個人のデータ統治、データドリブンをする産業のデジタル統治、政治的なデジタル統治に分類
重要な研究ジャンルは
データセキュリティ、Trustworthy HWおよびSWプラットフォーム、Threat Mgt・Response、暗号、ユーザー中心のセキュリティ・ツール、デジタル通信セキュリティ
以下、長し読み
データセキュリティ研究:
AIとAIの脆弱性、機械学習プラットフォームの可用性確保、説明可能なAI、AIが動作する環境のセキュアなどうさ、AIに対する信頼
Trustworthy SW研究
OS、ミドルウェア、マルウェア・ボットネット検知、仮想化セキュリティ、SW開発セキュリティ、リスクアセスメント、安全なセンサ、クラウドプロバイダに依存しないクラウドサービス
などなど。気になったものは見ればよさそう。
JST CRDS(JST研究開発戦略センター)が開催したワークショップの報告書
ワークショップはアーキテクチャ、OS、セキュリティ、データ保護、プログラミング言語からの研究会によるもの
セキュリティ系は「プライバシー保護データ解析技術」が面白かっった。形式手法のジャンルと日本のアドバンテージも興味深かった
プライバシー保護データ解析技術は、準同型暗号を使った秘密計算による解析の話。
KPMGなどがハッカソンしてるみたい。銀行も不正取引検知のためのニューラルネットワークに応用する研究をしている模様
ユースケースではにているConfidential Computingと対立する技術になるのかしらん
記念すべき最初のリポジトリはWIndows Event のログおよび収集のガイダンス
イベント/勉強会/発表資料
Netflixに10年いる情報セキュリティのVP
2011に600人規模のときに、1人のセキュリティエンジニアとして入った
そこからチームを拡大し、まずはクラウドインフラとアプリアーキ系のセキュリティ機能を追加
2016年には、検知エンジニア、スタジオセキュリティ?、アプリセキュリティを追加。ついでにCorporate Engineeringも統合
AWS CTFのライトアップ。面白かった
AWS環境でハニポを使った話
アクセストークンの公開パターンとPassRoleのはまりどころなどがおもしろかった
セキュリティ系のとかキャリアを積みたい人は、これを参照して一定の方向性を考えてもいいかも
エラーやプロジェクト参画1日目にソースコードを読む場合を想定したソースコードを読む技術
よかった
目的を設定して、動的解析をして、静的解析をする
動的解析 -> 処理の流れを追ったり、自然言語に直したり、挙動をみたり
静的解析 -> ドキュメントを読んだり、構造・設計を見たり
品質を犠牲にしてスピードを、、、というケースはままあるが、中期は逆効果、長期では致命
じゃあ、効果がでる短期は?というと、筆者の経験則的には1週間...という感じ
個人的には1スプリントくらい
凝集度(モジュール)は高くと結合度(モジュール感の関係)は低く
凝集度は、機能的、逐次的、通信的、手順的、時間的、論理的、偶発的なレベルに分けられる
前者の方が凝集度が高く、後者は低い(悪い)。
偶発的凝集はとりあえず動く状態で、絶対避ける。
理想は機能的凝集だが、逐次・通信・手順・時間的凝集は可能な限り小さく保つことが重要
結合度は、メッセージ結合、データ結合、スタンプ結合、制御結合、外部結合、共通結合、内部結合にわけられる
前者の方が結合度が低く(良く)、後者は高い(悪い)
**制御結合は論理的凝集** なのであまり良くない
理想はメッセージ結合とデータ結合だが、スタンプ結合でもおk(注意が必要なケースあり)
それ以外は可能な限り避ける。内部結合は必ず避ける
外側(UI/RB/リポジトリ)と内側(ビジロジ・エンティティ) の関係
外 -> 内は常に呼び出し可能
内 -> 外はストリームでイベント渡したり、インターフェースによるInjectionだったり
参考文献も充実
面白かったけどstraceやgdp、アセンブリの話じゃない、これw
その他