忙しい人のためのセキュリティ・インテリジェンス No.29 - 2021/04/12
今週のおすすめ/一言所管
Confidential Computing
Intel SGXはtee内外のcontext switchとメモリ枯渇時のページングで処理が遅くなる。
ので、SGX-extendedなlibcパラメタをいじる必要があり、その最適値を焼き鈍し法でチューニングするSGX Tuningの論文
マルチスレッドなミドルウェアで大きな改善を確認
コンパイルしたWASMを使うことでTEE上の開発効率あげよう
同時に、WASMでアプリからの直接的なシステムコール減らして速度あげよう
WASM in TEEとOS間はWASIで繋げよう、という論文
TEEを従来のSQLサーバーとつなぐ時の課題のうち、1) TEE内アプリのアテステーション 2) 秘匿性を保ったままDBにどうクエリを発行するか but インデックス処理編、という論文
キーは暗号化されており、それぞれのページでenclave内で比較処理し参照するページを探索するみたい。ここがよくわかってない。
Don't Trust, But Verifを実現する形
トラスト関連お技術の歴史とIntel SGX
この場合のトラスト = 想定したプログラムだけが動く(完全性、真正性、環境を準備する技術)
技術要素的には 1) Attestation = 真正性 2) Isolation = 環境を準備する技術 3) Integrity = 完全性が重要
PC内のTPMの遷移が面白い
また、OS,ハイパーバイザ、プラットフォームセキュリティエンジンとHWを運用・管理するクラウド事業者を信頼してアプリを実行していたところが、TEEの登場で、Platform Security EngineとHWを運用するクラウド事業者、そしてEnclaveを提供するチップベンダーを信頼する形に
OSおよびハイパーバイザは信頼しない
Confidential Computing: CPUのみがアプリ・データを制御可能なクラウド環境 -> CPUのみを信頼して利用可能なクラウド環境
基本リングプロテクションの効果
社会・サービスは仕組みを理解してるから回るわけではなく、特定のなにかに対して信頼があるから動いている
ただし、信頼対象が少ない方が確実性の高い事業運営ができる
もともと産業初のConfidential Computingがアカデミック側の論文でも取り上げられ始めている(例 IEEE S&P)
Confidential ComputingはHWベースだが、AWSは参加してない。そのAWSのNitro Enclavesはハイパーバイザベース
https://gyazo.com/bc6f497d16f67c8f6dd871f9e556acc8
信頼できるコンピューティング: Security、Privacy、Reliability、Business Practices
従来のセキュリティ境界: Ten Immutable Laws of Security
が、ファームウェアの脆弱性・カーネルプロテクションの利用率・フィッシングの成功率から境界の再定義が必要に
新境界
全コードは整合性を持って実行される
ユーザーのアイデンティティは侵害・なりすまし・盗難されない
簡易的な物理アクセスを持つ攻撃社は、デバイス上のデータやコードを変更できない
悪意のあるコードがデバイス上にとどまらない
セキュリティ前提の違反が観測可能
全アプリとシステムコンポーネントは最小権限を持つ
で、MicrosoftはSecure Boot、Virtualization-based Secccccurity(ハイパーバイザベースの仮想化による保護技術)、Secure Launchを実装
これにより「Seven Properties of Highly Secure Devices」が定義される
同時に、クラウドプラットフォームも変化している
求めてた奴。BeyondCorpでInventory Serviceを構築する「Vulnerability Scanners」
ScannerをWindowsマシンにインストールして、それをDefenderに登録するイメージ
https://gyazo.com/7f2176309eeae78c6b901657b892f01d
地味に知らないことあった
Office周りのactivity logとか結構有用そう
あと、Livestream完全に誤解してた。Alertと完全に混同してた。
Compliance
他
IAM Access Analyzerのポリシーチェック項目を拡張。
リンター的だけでなく、ベスプラモ提示
Variational Autoencodersという機械学習モデルをベースに、GuardDutyがAPIの呼び出しを確率分布的に学習できるように
結果、50%のアラートの削減(ノイズ?)と300%の監視カバレッジにすることに成功
加えて、どのTacticsかも判定できるようになった
Usual Behaviorも見れるようになって、より人間が直感的に異常を認識しやすくなった
Detectiveでは、以下の情報を提供することでGuardDutyを補完する(ここはいぜんから変わらず)
role chainingとrole chain先で実行したapi
該当送信元IPアドレスでのアクションを時系列化
上記APIが呼び出した他のroleやAPIおよび成功・失敗
AWS Configで定義するカスタムルールでEC2のNon CompliantなRuleを定義して、SSMを使って自動Responseする
GuardDutyで検知したSuspiciousな通信をAWS Network Firewallで自動ブロックするやりかた
Step Functionを使う
Network FirwallのRuleは同サービスのRule Groupにまとめられ、さらにFirewall Policyにまとめられる
本ブログでは不審な通信をブロックするRuleをGroupに追加する。Rule Groupは特定期間後にRuleは削除される
sts:SetSourceIdentity の話。これを使うとChain先のRoleで行ったイベントもCloudTrailに記録される
超便利。今まではこれがなくてフィルタが大変だった
aws sts assume-role で--source-identity指定しないとなので、周辺ツールへのcontributeチャンス
どうでもいいけど、AWSの新機能リリースではどーしてもClassMethodさんには勝てないので、「別に二番〜3番煎じでいーや」って開き直る心がけが大事
IAM Access AnalyzerがCloudTrailをベースにPolicyを作成してくれる機能をリリース。さんきゅう
Google
comprimiseの定義だったり、Let's encryptによるssl対応サイトの増加率が10%になった話とかあ、クライアント証明の話、失効確認による認証負荷の増大とか面白かった
情報漏えい事例は減少傾向
誤操作・誤認ルートは減少
中途退職者によるものは増加
従業員300名規模以下の企業では、情報漏洩認識時に何もしなかった割合が多い
余裕がない、何をすべきかわからない、対応のための費用確保に失敗
電子契約サービスで締結した場合(事業者署名型になる場合)、電子署名法上の電子署名といえるか?電子署名は自然人でなければならないのでは?という疑問に答えるブログ
電子署名法(電子署名及び認証業務に関する法律)による定義
一 当該情報が当該措置を行った者の作成に係るものであることを示すためのものであること。」
二 当該情報について改変が行われていないかどうかを確認することができるものであること。」
電子署名された電子ファイルが本人の意思により作成されたものかどうかをケアするのは第三条
電磁的記録であって情報を表すために作成されたもの(公務員が職務上作成したものを除く。)は、当該電磁的記録に記録された情報について本人による電子署名(これを行うために必要な符号及び物件を適正に管理することにより、本人だけが行うことができることとなるものに限る。)が行われているときは、真正に成立したものと推定する。
利用者の指示に基づきサービス提供事業者自身の署名鍵により暗号化等を行う電子契約サービスに関するQ&A(電子署名法2条1項に関するQ&A)」にて、サービス提供事業者による介在がなく、且つ、利用者の意思のいに基づいて機械的に暗号化されているなら、電子契約サービスを利用していても、サービス・プロバイダではなく利用者が電子署名をおこなった、と評価している
Certificate Transpaarencyの新しい機能「SCT Auditing」がChromeに搭載
CTの目的は公開された証明書をCT logsに記録することだけど、それが確実におこっていることを保証したい
CAが証明書を発行したい意向を示すと、CT logsからSigned Certificate Timestamp (SCT)が発行される。それを証明書に入れる。そのためCT logs(オペレータ)がTrust Anchorになるが、共謀などを考慮して、ChromeのCT Policyでは、少なくとも1つのSCTはGoogleが(運営するCT Logsが)発行するものでなければならにことになっている
その場合、GoogleがSPoFになるので、CT logsから自動的にチェックできるSCT Auditという仕組みが考案されている...という話
なお、CT logに負荷が集中してしまう問題をどうさばくかは書いてない
CodeCovの内部システムが改ざんされて、本システム内で利用されている情報を窃取できる
例えばCIとかでCodeCov使ってると、tokenを任意のサーバーに転送するなどができる
PHPのソースコードに、正しい権限を持っているユーザーの名前で悪意あるコミットがされた
一回リアートしあら、またリストアされた
アカウントが窃取されたわけではなく、サーバーそのものがやられたことが原因
コミットされたコードはバックドアを仕込むようなやつ
リポジトリサーバーを自前からGitHubに移した模様
FAPI 1.0がファイナルに
行政/会社/団体
CISAのSparrowによる分析結果の可視化ツール「Aviary」
Sparrow自体はMS365周辺の侵害アカウントを検知するためのツール
GCPでdrive連携するならサービスアカウントのメアドをdriveに追加すればいいのか。便利だな
NetflixのSecurityチーム、youtubeチャネルを持っていた模様
CODEOWNERSとか知らなかった...あと、EnvironmentでDeployment Branchを限定して、Environment内のSecretを利用できるブランチを限定できたとは...
Environtmentを使ってVaultのSecretIDを指定
APIでGitHub Secretsローテもできたんだなー
イベント/勉強会/発表資料
LayerXがエンジニアブログを開始
※ 本まとめは@ken5scal個人的なもので費用は発生していませんが、LayerXの従業員なので利害関係があります。
GraphQL系エントリ
テスト系
文化系
開発手法系
CX系
インフラ系
機械学習系
その他