鳩小屋

落書き帳

Cloud Native Security Conference 2022:最近のTrivy

Cloud Native Security Conference 2022 第2弾はTrivy開発者さんの発表についてです。

元祖の脆弱性診断機能はカバレッジや精度も自信ありとのこと。

設定ミス診断機能はいろんなIaCリソースを診断可能。DockerfileやKubernetesに限らずhelmやterraformまでスキャン可能。

ここまでは知っていたのですが、著名なソースコード管理ツールと統合されたり

クレデンシャル情報を検出したり

ライセンススキャンしたり

Kubernetesと統合したり

CSPMの機能も

SBOMやattestationといったソフトウェアサプライチェーン

なんとOperator化まで

なんというか、とんでもない進化を遂げていたようです。

個人的には、ソフトウェアサプライチェーン関連でin-totoやSLSAは知っていたのですが、chain-benchやCIS Software Supply Chain Security Guideまでは知りませんでした。 違いがほとんど分かっていないのですが、余裕があればCNCFのSoftware Supply Chain Best Practicesあたりと見比べてみたいです。

あと、SBOM機能については、拾える依存関係の範囲やツール間の互換性など、課題も残っているとのことでした。とても参考になりました。

Cloud Native Security Conference 2022:クラウドネイティブセキュリティガイドライン

いまさらですがCloud Native Security Conference 2022の動画版を視聴しました。
名前のとおりCloud Nativeセキュリティについてホットなテーマが取り扱われていました。
event.cloudnativedays.jp

ここではNRIの方々が発表されていた内容を紹介します。

NRI:「サイバー攻撃を想定したクラウドネイティブセキュリティガイドラインとCNAPP及びSecurity Observabilityの未来」

こちらの発表ではクラウド、コンテナ、CICD、ソフトウェアサプライチェーンなど、クラウドネイティブを構成するインフラレイヤからアプリレイヤのセキュリティについて汎用的なガイドやアプローチを手広く紹介されています。

クラウドサービス、OS、ミドルウェアなどのインフラリソースは実装レベルの個別ガイドラインが並んでいます。アプリ層のガイドラインでは、OS、ミドルウェア、開発言語などの実装は問わず、クレジット情報を保護する、プライバシー情報を保護する、といったアプリで扱う情報資産の保護に注目しています。


クラウドセキュリティ

クラウドとは言ってもどこかにデータセンタ、物理サーバ、物理ネットワーク機器などは存在しますし、そのうえで動くOS、ミドルウェア、アプリの構成はオンプレと大差ありません。ただし、ビジネスモデルとしてそれらを管理する組織が異なるため、正しく役割分担をしておく必要があります。そこで、クラウド利用者とクラウドベンダの管理責任を分離する責任共有モデルがまず重要になります。特に、最近はIaaS、PaaS、SaaSのような一般的なモデルに加えて、サーバレス、ローコード、kubernetesなどの責任共有モデルも理解することが求められます。

あまり重要でないと思われる方もいるかもしれませんが、提案段階の上流工程でこれらが合意されないまま開発または運用時にトラブルが発生すると、対応方針や責任の所在が見当たらず困ります。例えば、「サーバレスサービスを使うぞ、セキュリティは後付けで考えるぞ」といったケースでは、「あれ?OSにアクセスできないのにアンチウィルス製品なんかインストールできないぞ?いつも使ってた脆弱性診断ツールがOSレイヤにアクセスできないと使えないぞ?」といったことが起こりえます。また、インシデントが発生した際に責任の合意が取れていないと「クラウド利用者もクラウドベンダも俺は悪くない」と言い張るようなことが起こります。

大多数のベンダはクラウドベンダが提供するクラウドサービスを利用する「クラウド利用者」の立場になると思われます。このとき、利用者側の責任範囲は問題ないのですが悩ましいのは「クラウドベンダの責任範囲」です。下記のように「SIerが他ベンダクラウドサービスを契約して顧客にシステムを納品するSI案件」でインシデントが起こった際のことを考えてみましょう。
もし、クラウドベンダ側の責任範囲に問題があったとしても、顧客はフロントでやり取りをしているSIer(クラウド利用者)の責任にしようとします。このとき、SIer(クラウド利用者)は「責任範囲じゃないので知りません」とはいえません。

クラウドベンダ→SIer(クラウド利用者)→顧客

クラウド利用者であっても、クラウドベンダの責任範囲は完全に無視していいというわけではなく、クラウドベンダで対策が取られていることを契約(合意)する「監督責任」が生じます。
ただ、スライドの説明にあるとおり、一問一答形式でクラウドベンダに確認していると膨大な時間がかかってしまいます。そこで、クラウドベンダが第三者認証として公開している範囲については満たされているとして、クラウド利用者側では最低限責任を追及できる状態を確保しておく、ということだと思います。

よく「Windows OSをセキュアにしてください」とか言われますが、具体的にどこをどう設定すればよいのかまで提示されないケースもよくあります。
また、コンポーネントによっては100項目を超えるような対策の実装を、開発者の知識や経験のみに頼るのは現実的ではありません。

そこで次のスライドでは、クラウドサービス、OS、ミドルウェアなど、いろんなレイヤの対策をどうすればいいのかという問いに対して、CIS Benchmarksを紹介しています。
CIS Benchmarksでは、幅広いコンポーネントに対して実装レベルかつセキュアな設定方法を提供しています。
このようなレギュレーションを採用すれば、開発者のスキルに依存することなくエンタープライズレベルで通用する堅牢化を実施することが可能です。


コンテナセキュリティ

コンテナについては少しライトな内容ですが、フルマネージドKubernetesの責任共有モデルやコンテナイメージの脆弱性スキャンについて言及されています。

フルマネージドKubernetesの責任共有モデルはややこしいので深く言及しませんが、CIS BenchmarksやAmazon EKS のベストプラクティス集などが参考になると思います。
Home - EKS Best Practices Guides


コンテナイメージの脆弱性診断ツールについては、未成熟な部分もあり注意が必要という内容です。
現在のコンテナイメージ脆弱性診断ツールは、「パッケージマネージャが管理する依存情報からパッケージ名やバージョンを抽出して脆弱性データベースと照合する」ような診断方式がとられています。そのため、「make installやwgetされた野良パッケージ」や「スキャン対象外のパッケージマネージャで管理されたパッケージ」は診断から漏れたりします。このような仕様を理解していないと思わぬ脆弱性が残ってしまいます。


運用監視

後半では、セキュリティバイデザイン(シフトレフト)やCICDなどを考慮して、セキュリティを効率的に組み込むツールを紹介されています。
SASTやDASTはアプリケーションの脆弱性、つまりセキュアコーディングができているかを自動チェックするツールになります。(SCAは違いますが)

そのほかにも、CSPM、CWPP、CIEMなどのクラウド環境保護製品が紹介され、それらがハッピーセットとなったCNAPP(Cloud-Native Application Protection Platform)が最強とされています。
たしかにこれさえ入れとけばOKといった製品が魅力的なのは間違いないですね。

この他にも関連技術や製品が紹介されていますので興味がある方は参照されてはいかがでしょうか。

物価上昇の状況整理

エネルギー費、食費など、去年の秋ごろから発生した家計直撃イベントの状況整理。

コロナ防疫

コロナウィルスの感染が拡大してから丸2年以上経ちましたが、世界的にはある程度折り合いをつけて経済活動を再開する潮流になっています。
ただ、感染者増加による工場停止や海運コンテナの稼働率低下など、サプライチェーンが混乱、つまり需給における「供給が弱い」状態で、経済活動を再開して「需要が高い」状態になると物価の上昇を招きます。特に、エネルギー費の高騰は生産から物流まで影響を与えるため、春頃から広い範囲でインフレが進んでいます。他には、中国のゼロコロナ政策による供給力低下も影響していると言われています。
ワクチンが変異種に効かなかったり、副反応があったりとインフルエンザレベルまで抑え込むにはまだ時間がかかるものの、サプライチェーンの混乱は一時的でインフレ自体はすぐに落ち着くはずでした。(ウクライナ侵攻がなければ)

ウクライナ侵攻

コロナ防疫の影響が残った世界情勢をさらに混乱させたのが2月に始まったウクライナ侵攻です。特に経済制裁によるロシア産天然ガスの輸入削減や物流混乱は世界の物価を上昇させました。
エネルギー関連ETF(上場投資信託)の価格推移を見ると、去年の秋ごろから上昇していた価格が未だに高止まりしていることがうかがえます。

エネルギー資源費はガソリン代から電気代、食品の輸送費から包装に至るまで幅広い分野に関わるため、家計圧迫の要因になります。

もう一つの問題は、黒海封鎖によるウクライナ産小麦の輸出停止でしたが、こちらは部分的に解決されつつあります。ウクライナ産小麦の輸出は世界の1割を占めるため、完全にストップすると供給先の国(特に途上国)で食糧危機がおこり、最終的には食糧暴動が発生します。スリランカの件もこの一例と言えるかもしれません。ただ、モスクワ撃沈やズミイヌイ島奪還、国際世論の批判により、ロシアから「農産物を載せた貨物船が航行中は、ロシア軍は黒海に面したウクライナの港・船舶を攻撃しない」という合意を取り付けています。機雷やロシアが約束を守るかどうかの問題は残っていますが、小麦供給の問題は快方に向かうとされています。

ウクライナ侵攻終結の見通しですが、短期決着の可能性は低そうです。ロシアは毎日10億ドル以上のエネルギー収入があり、経済面でまだまだ余裕があります。制裁によって精密兵器の供給には支障が出ていますが、ソ連時代に貯め込んだ大量の陸軍兵器を保有しているため、こちらの枯渇もあてにできません。人員面についてもロシア人ではなくロシア連邦を構成する貧しい諸国の民族を動員しているため、本格的な人員枯渇や反乱も望み薄です。一方、ウクライナ側は、NATO諸国から継続的な兵器供給を受け、それらを器用に使いこなして戦果をあげています。ウクライナ側が優勢となる戦域も増えてきましたが、NATO側の兵器供給もロシア側を圧倒しない程度に絞られているため、ある程度の膠着は避けられないと思われます。

金融混乱

米国編

コロナ防疫とウクライナ侵攻に付随して金融面でも大きな混乱が起きています。
コロナ期間(2020年~2021年末)は、経済活動の縮小で行き場を失った資金が証券に流れ、金融市場で劇的な上昇基調が続いていました。そのため、猿でもなんか買っとけば儲かるような状態でした。
ただ、米国のFRB(日本における日銀)が量的引締め(大量購入していた国債が売却され金利が上昇)を開始したことでその勢いは失速しました。さらに、FRBはコロナ防疫の余韻とウクライナ侵攻の複合要因で発生した歴史的なインフレを抑えるために政策金利の引き上げも開始しました。政策金利は銀行間の貸借りをはじめとして、企業融資への金利、住宅ローンなど、幅広い分野の金利に影響を与えます。金利が高いと借金の利子が膨らむため、購買意欲などが低下して需要が低下するとされています。これによりインフレを抑えようとするのがFRBの金融政策の狙いです。ただ、政策金利は需要には効果があるものの、サプライチェーンの混乱といった供給面への効果は限定的とされています。

ここで、米国のインフレ状況を表す指数で重要となるのが「CPI(消費者物価指数)」になります。 グラフを見ると2021年頃から急激な上昇を見せていて、7月の発表でようやく前年月を下回りピークアウトとなることが期待されています。ただ、日本の物価上昇が2%に対して米国が約9%であることを考えると、米国のインフレがいかに進んでいるかが分かります(日本はデフレからスタグフレーションに移行)。


米国 消費者物価指数 (前年比)

米国では給料もうなぎ上りではあるものの、物価上昇率の方が高いため、生活は貧しくなっていると言えます。FRBはこのようなインフレ指標を確認しながら政策金利の上げ幅を決定しているため、金利上昇や株価の動向を把握するうえで重要な指標となっています。

日本編

ここまで米国のインフレや金利政策を見てきましたが、これは日本国民の家計を苦しめる円安の原因にもなっています。
国債金利政策金利は厳密には別物ですが、正の相関関係があります。つまり、政策金利が上昇すると国債金利も上昇するような傾向があります。
米国では前述のとおり国債金利が上昇していますが、一方の日銀(日本銀行)では、これらの金利を押さえつける低金利政策(指値オペ)を継続しています。
グラフをみるとわかるとおり、最近は日本国債米国債金利差が拡大しています。

資金は金利が高い(儲かる)方に流れるため、円を売りドルを買うという流れが強くなっています。
これによって円安が進み、食品やエネルギー資源の輸入価格に拍車をかけています。これらは、貿易赤字にもつながる(円よりもドルを買っている状態)ため、更に円安がすすむという悪循環の側面もあります。
円安の良し悪しは判断の分かれるところですが、国民の家計に限っては物価上昇として重くのしかかります。

では、日銀はなぜ低金利政策を続けるのかという疑問にたどり着きます。これは景気低迷の中で金利を上昇させるとさらなる景気の悪化を招く可能性があるためです。そもそも日本経済はお世辞にも金利上昇に耐えられるような状態ではなく、国債金利上昇による国庫の圧迫や住宅ローンの変動金利の上昇など、負の側面が想定されます。そのため、状況を好転させることはできないものの、金利を上昇させるよりマシという考えのようです。
政府としても打てる手があるわけでなく、緊張感をもって注視する以外は何もしてくれないようです。おまけに給料の上がらない国民は座して耐えるのみです。

個人的な対応

コロナやウクライナの問題は一時的なものですが、スタグフレーション(所得が上がらず物価のみ上昇)は今後も続くと考えています。
社会保障費が上がっていくようなことも考えると、やはり頼みの綱は資産運用ぐらいかもしれません。
最近は相場が怪しい動きをしているので控え気味ですが、運用益自体は出せているのでまったりやるしかないですね。

検体番号079 ~モルモットへの道~

ヒャッハー 治験のお時間だー

背景

リモートワーク中心のためコロナワクチンは様子見をしていましたが、出社する気運も少しずつあらわれ、コロナワクチンの接種も視野に入ってきました。
ただ、評判の副反応から打ちたくないという気持ちが強く悩んでいました。

そこでたどり着いたのがワクチン治験。

今ならなんとワクチンを打つだけでお金がもらえる!

と言えば聞こえはいいですが実際は人体実験です。モルモットです。
気になると思うので先に金額を出すと、来院ごとに15000円*10回みたいな感じです。その対価として自身の体を実験体として差し出すわけです。

「治験」は「薬の候補」を健康な成人や患者に使用して、効果や安全性、治療法(適正な投与量や投与方法)などを確認する目的で行われる「臨床試験」を指します。
つまり、薬局で処方される薬と異なり、安全性が未確認で厚労省の承認も得られていない薬を投与することになります。
本来、治験参加はリスキーな行為ですがコロナワクチンに限っては状況が異なりました。
いずれのワクチンも副反応上等と言わんばかりに発熱や倦怠感が報告され、現在も安全性が疑われる代物です。
なので、承認ワクチンも治験ワクチンも安全性大差ないのでは?→どうせ打つなら金をくれ。という結論に私はいたりました。

治験内容

応募した治験は、明治グループや塩野義製薬傘下のkmバイオロジクスが開発を進めるKD414ワクチンの第III相臨床試験でした。
治験は第I相から第III相まであり、第I相は人に初投与、第III相は後詰として多人数で試験という感じです。
実施の順序から言えば第III相が比較的安全ですが、厚労省のお墨付きが一切ない点は同じです。


https://ciru.dept.showa.gunma-u.ac.jp/general/cr-steps/

第I相治験の前は動物実験非臨床試験になります。
マウスから猿までいろんな動物を使って毒性検査や致死量などを調べるようですが非臨床試験との大きな違いは最後は全部殺処分になることです。
創薬おじさんだったパッパによると「ネズミちゃん達は袋に詰めてドライアイスいれたら体温で気化して窒息するからラクチン」と仰せでした。
ぐう畜。

さて、このKD414ワクチンですが、インフルエンザワクチンと同方式の不活化ワクチンになります。
前評判で副作用の発生確率が圧倒的に低く、プロトタイプワクチンとしても承認も目指しているため、新しい変異株への継続対応も期待でき、個人的には有望視しています。
結局、最新鋭ワクチンが打てる、お金がもらえる、ほんの少し社会貢献と意気込んで応募しました。

具体的な試験内容は、被験者を2グループに分け、kmバイオロジクスとアストラゼネカのワクチンを投与して効果を比較する対照検証試験でした。
来院前はプラセボ群との比較試験かと思っていたのですがまさかのワクチンガチャです。
しかも、どちらのワクチンを打ったかは数か月後まで分からないというおまけつきです。

一日目は適正試験として抗体検査や抗原検査のために唾液採取や採血があり、コロナ感染以外にもHIVや妊娠検査が行われました。
印象的だったのは採血担当者の方が注射失敗などあり得ないと言わんばかりの熟練者オーラでした。(近衛師団のような安心感)
注射の痛みもほとんどなく機材も進化しているなーと思いました。(小並感)
待ち時間もwifi付きでスマホポチポチし放題なのでずっとソシャゲで遊んでました。

私は一日目試験を無事パスしたので二日目のワクチン接種に参加しました。(今まで感染してなかったということはやはり引籠りが最強の感染対策)
投与直後は何事もなくkmバイオを引いたかと思ったのですが、帰宅後に微熱が出始め、夜にはご覧のとおり。

心拍数が45度ぐらいの風呂に入っているかのような状態になり、しんどい状態が続きました。
次の朝も38度越えだったため速攻魔法「傷病休暇」を発動し、布団に転がっていました。
データをとるためできる限り市販薬を飲まないようにという指示もあったものの、3日も付き合えないので一類医薬品のロキソニンで解熱しました。
症状を見るにどうやらアストラゼネカを引いてしまった説が濃厚ですが想定範囲内です。
タダでも打ちたくないという気持ちは今も変わりませんが、ちゃんと対価をもらっているので頑張ります。

以上、治験参加記録でした。
気になっているお薬がある方もぜひ参加されてみては?(ゲス顔)

2021年度:読書

去年度買った本の感想です。

インフラ技術は、物理サーバで動かすベアメタル、計算リソースをエミュレートする仮想化、物理リソースをアウトソースするクラウド化、OSのリソースを効率よくサイロ化するコンテナ化といった具合で進化してきました。
特にクラウドやコンテナの利点をアプリレイヤまで最適化するクラウドネイティブ分野では、従来型の開発モデル、アーキテクチャ、コア技術が一気にパラダイムシフトしてきています。
セキュリティ側もこれらに追随していく必要があり、例を挙げるだけでも頭が痛くなりそうなボリュームですがこればかりは地道に理解していくしかありません。
・DevOpsに合わせたセキュリティガバナンス、プロセスの実装
アジャイル開発おけるセキュリティ実装プロセス
クラウド・コンテナセキュリティ
・マイクロサービスやゼロトラストモデル
・CICDやソフトウェアサプライチェーン

個人的には、国防総省のDevSecOpsリファレンスやCNCFのソフトウェアサプライチェーンに興味があり、ここら辺を理解するのが当面の目標です。
そういった背景もあり、なんとなくクラウドネイティブチックな書籍が並んでいる状況です。

software.af.mil
github.com

読んだ本

実践入門 Kubernetesカスタムコントローラーへの道

k8sカスタムリソースやカスタムコントローラの貴重な日本語資料。オペレータまわりの基礎知識をさっと学ぶにはいい本でした。
k8s拡張機能の中枢を担っている機能なので大雑把に理解しているだけでも視野が広がるようになりました。
ただ、カスタムコントローラ自体が難しいので読んだ次の日には頭から抜けていたような感じです。

入門 監視

そもそも運用者さんて何やってるんだっけ?という状態だったので読みました。
監視の基本的な考え方・心構えがしっかりと書かれていて参考になりました。
DevOpsやマイクロサービスまわりへの言及もありSREにもつながりそうな知識が得られました。

OpenShift徹底入門

OpenShiftはエンタープライズ向けに魔改造されたk8sですが、公式ドキュメントがわかりづらく苦しんでいたのでtwitterで見かけて即購入しました。
開発者、運用者、セキュリティ担当者の視点から幅広く機能が紹介されていて、OperatorHubや最近買収したstackroxの機能など、初めて知った機能もたくさんありました。
まだまだ乏しい日本語書籍の中でも素晴らしい出来です。OpenShiftわかんねーという方は買って損はないと思います。

Effective DevOps

なんとなく言葉は知っていても何がDevOpsで何がDevOpsじゃないのかまったく分かっていなかったので読みました。
4本柱としてコラボレーション、アフィニティ、ツール、スケーリングの説明と実践的な話が書かれているところが中心です。
特に組織の文化づくりのところが頭から欠けていたので勉強になりました。「うーん、これはDevOps!w」みたいなことが言えるようにはなりそうです。
ただ、日本(特にSIer依存のユーザ企業)ではまだまだウォータフォールが根強く、普及するのがもう少し先になりそうな気がしました。
個人的には、ウォータフォールは局所的な自動化はできても本質的に成長が頭打ちな面があるため、国外のように内製化と併せて浸透していくといいなーと思いました。

解体 kubeadm

k8sの構築ツールはいろいろありますが、そもそもどうやって構築されてるんだっけ、どうやって動いてるんだっけ。そんな疑問を劇的に解決してくれる書籍です。
k8s脳死で構築したり触っていたりすると、これ何の証明書だっけ?これ何の鍵だっけ?この設定ファイルとあの設定ファイルの違い何だっけ?みたいなことがよく起こります。
この書籍ではkubeadmによる構築処理が丁寧に解説されているため、上記のようなファイルがいつ生成されてどこで使われるのか把握できるようになります。

アジャイルサムライ

業務的に滝の呼吸に触れることが多いのでアジャイル開発は1ミリも分からない、そんな状態から読み始めました。
内容がフランクで読みやすく、アジャイル開発の考え方やワークフローが飽きずに頭に入ってくるような内容でした。
アジャイル開発のなんたるかがエアプレベルですが理解できたので、DevOpsとの違いやなんちゃってアジャイルとの区別もついてきた気がします。
セキュリティ実装のプロセスを考えると、滝の呼吸の手法どおりにはいかず、なかなか頭の痛いところがあるなと感じました。

体系的に学ぶ 安全なWebアプリケーションの作り方 第2版

私はWebというよりアプリケーション周りの知識が壊滅的なので、基礎から勉強し直しました。
HTTPヘッダ、CORSなど前提知識も説明があり、実装レベルの話も書いてあるのでポンコツな私でもさくさく読み進められました。
改版されたらまた買うぐらいの良書です。

Web API

Web APIの話も当たり前になってきているのでさすがに理解していないのはまずいと思い読みました。
WebAPIのことが体系的に書かれていて勉強になりました。
開発者には遠く及びませんが、インフラ周りに関わる身としてはいい塩梅のボリューム感でした。

Kubeletから読み解くKubernetesのコンテナ管理の裏側

techbookfest.org

Kubeletって何してるんだっけ。それを日本語で解説している貴重な書籍です。
ユーザには抽象化されているのでk8sを使う分にはほとんど必要ありませんが、k8sの内部挙動を追う際に重宝しそうです。

Kube API Server ~Kubernetes API Serverの内部実装を見てみよう~

techbookfest.org

API Serverって何してるんだっけ。それを日本語で解説している貴重な書籍です。
こちらもk8sを使う分にはあまり必要ありませんが、k8sの内部挙動を理解する際に重宝します。

ゼロトラストネットワーク ―境界防御の限界を超えるためのセキュアなシステム設計

ゼロトラストまわりもまだまだバズワード感がありますが、体系的に理解するために読みました。
外部からの侵入ではなく、侵入された後の水平展開や内部犯による脅威を抑制することが大まかな目的ですが、TPMなどから提供された信頼を認証、認可で適用して信頼の連鎖を積み上げたり、開発工程における署名、識別主体のサイロ化などが紹介されていました。マイクロサービスアーキテクチャのセキュリティもゼロトラストとなることが多いのでIstioの機能を理解・納得するのに参考になりました。
ただ、正直ここまでやるか?というぐらい暗号ハッシュや証明書が出てくるので目が回ります。具体的にはmTLSが当然のように登場してきて、まじめに署名書購入していたら破産してしまうぐらいの勢いです。
費用対効果を考えると疑問符が付くこともあるので、ほんとに必要なのかよく考えてから導入すべきかと思います。

Dockerコンテナ開発・環境構築の基本

DockerやKuberntesについてはあまり得るものがありませんでしたがgithub actionsとargo CDを利用したCICD環境構築の手順が説明されていて勉強になりました。CICDホンノチョットデキルぐらいは言えるようになったかもしれません。
テスト自動化とかは全くやったことがないので、実践レベルではもう少し修業が必要そうです。
個人的にはソフトウェアサプライチェーンまわりで話題に上がるのでCICDのセキュリティも興味があります。

イラストでわかるDockerとKubernetes

買った時点でruncやcontainerdのコードリーディングに着手していたので、個人的には読むのが遅すぎました。
低レベルコンテナランタイムの存在やオーケストレータへの言及がありますが、内容が抽象的であまり得るものがなかったというのが正直なところです。
読み直すビジョンが浮かばなかったので、メ〇カリで出荷しました。出荷先で役に立っていることを祈ります。

セキュリティのためのログ分析入門

Hardening競技に参加することになり、精神安定剤として購入しました。勉強にはなりましたが競技で役に立ったかは微妙です。

Kubernetes完全ガイド

Kubernetesの日本語版聖書です。2版は1.18版が対象となり少し古くなってきていますが、まだまだ現役かと思います。
Kubernetesわからんという人はとりあえずこれ買っとけば間違いないです。

Docker/Kubernetes開発・運用のためのセキュリティ実践ガイド

Docker/Kubernetesのセキュリティがバランスよく解説されています。日本語書籍としてはトップクラスの出来かと思います。

Container Security: Fundamental Technology Concepts That Protect Containerized Applications

洋書ですが、unshareを使ったnamespaceの分離など、コンテナ技術の本質的な実装に踏み込んだ内容をセキュリティ視点で解説した書籍です。翻訳版が出たらまた買いそうです。
docker runを実行しているだけでは絶対に身につかないようなエンジニアリング的な視点が詰まった書籍なのでエンドユーザの視点よりも踏み込んだ理解をしたい方にはおすすめです。
一方、なんとなくコンテナが使えればいい、なんとなくコンテナセキュリティを理解したいという方には少しヘビーな内容かもしれません。

新版 CISSP CBK公式ガイドブック

CISSPの参考書。エイゴヨメナイノデタスカリマシタ。
独学だとどうしても知識が偏ったり穴が開いたりするので、体系的な勉強という意味では役にたったと思います。あと、米国資格ということもあってNIST文書の用語がすらすらと理解できるようになった気もします。
資格やレギュレーションこそがすべてみたいな思想は大嫌いですが、無いよりはマシなので、また気が向いたら他の資格にもチャレンジするかもしれません。
個人的には既存の知識や技術をうまく扱う技能(テクニック)、道しるべがなかったとしても自力で解決する工学力(エンジニアリング)、両方のバランスが大事だと考えています。

Learn Kubernetes Security: Securely orchestrate, scale, and manage your microservices in Kubernetes deployments

めぼしい日本語書籍を読み終わったので洋書に遠征しました。知っていることも多かったので、知らなそうなところを重点的に読みました。
カバー範囲もしっかりしていたので英語が読めるのであれば悪くない内容だと思います。
日本語書籍でもコアな部分は拾えるので日本人が無理して読むほどの価値はないかもしれません。

読めてない本

実践 Terraform

IaC周りでよく聞くTerraform、いかほどものか勉強するために購入しましたがペンディング状態です。気が向いたら読みます。

ステーティング Go言語

ほとんど勉強せずにGoコード読んだ感想としては、とにかく可読性が高いという印象を持ちました。
最低限のプログラミング言語知識があればノリと雰囲気で読めることも多く、C+のようなオナニー言語と比較すると好印象です。
ただ、理解していないとどうにもならない時もあるため、ちゃんと勉強が必要と考えています。

SRE サイトリライアビリティエンジニアリング

インフラ技術者や運用者のスキルを併せ持ったような技術体系と理解していますが、書籍の分厚さに圧倒され未着手状態です。
前提知識も多く、急がば回れの精神で外堀知識が揃い次第挑戦したいと思います。

分散システムデザインパターン ―コンテナを使ったスケーラブルなサービスの設計

マイクロサービス周りの基礎知識を身に着けるため買いましたが、まだ読めていません。
マイクロサービス自体は銀の弾丸ではないので、極端に需要のある分野とは思っていませんが、クラウドネイティブ分野の範疇としてもう少し基礎を固めておきたいという思いがあります。

CISSP受験

先日、CISSPを受験しました。
結局2週間前までほとんど対策せず短期決戦となりましたが合格できました。(教訓:人は追い込まれてこそ輝く)

www.isc2.org

試験概要

出題形式:250問(日本語・英語併記)、四択
受験費用:749米ドル

受験費用は約8万円。一発合格を狙う最大のモチベーションといっても過言ではありません。
試験時間は6時間で一問あたり平均約90秒で回答するイメージです。朝8時からなので体調管理も大事かもしれません。
自由休憩(飲食・トイレ)することができ、私は2回トイレに行きました。
入退室に必要なアクセスキー以外(身分証やロッカーの鍵)はロッカーに封印するため、資料の参照はできません。

試験当日

開示は禁止されているため、具体的な試験内容は控えますが、ぱっと見は情報処理技術者試験でみるような4択と同じ形式です。
ただし、正解の選択にそれなりの知識と思考が要求されるため、一筋縄ではいきません。

例えば、通常の4択では明らかな正解1つと明らかな誤り3つが並ぶことが多いですが、CISSPの試験ではその常識があまり通用しません。
正解か誤りのどちらかといえば正解といえるような選択肢が2つ3つ4つ並ぶものが大半で、最も正しい(優先されるべき)選択肢を選ぶことになります。
そのため、選択肢の技術対策や運用対策は何を解決できるのか、どこまで信頼できるのか、どこまで問題文の状況に適しているのかをその場で見極める力が重要になります。
つまり、設問に出てくる用語は知っていて当然、選択肢を吟味することが求められます。
加えて、単純にビジネス、ガバナンス、マネジメント、プロシージャ等、カバー範囲が広いため、回答はより難しくなります。

所感としては、即答できたのは6割程度。3割は選択肢を絞って考え込む。1割は選択肢の内容(問題文や単語や意図)が一部理解できずに鉛筆コロコロでお祈りといった感じでした。
迷った際は、問題文を一言一句を確認して本質的に何を聞かれているのかを再認識。英語文面も参照して認識に違いがないかを再確認。そのうえで考え込むといった方針をとりました。
特に、日本語は「検証されて検証された」がverifyとvalidateであったり、「管理と管理」がmanagementとadministrationなど、判断に影響のあるガバガバ翻訳の場合もあるので、英語とのハイブリット方式で回答するのがよいと思いました。試験当日も上記のようなケースがあり、10問ぐらい新次郎の顔が頭から離れませんでした。(ファッキュー)

試験が終了すると、その場でこんなレポートがもらえます。

知識のインプット

前述のとおり当日の試験では、いつ(特定時点または特定期間)、どこで(組織、部門、物理的な施設)、だれが(役割、権限、責任)、何を、どのように実行すべきか。その中で最も優先されるべき選択を理由付けして判断できる必要があります。問題文の意味が分からなければ正しい選択肢の中から最も正しい選択肢を吟味することすら叶わないため、ある程度の知識習得は必須になります。まずは、CISSPセミナーのテキストや公式問題集を読み込み、なんとなく重要そうな単語や考え方をインプットしていきました。注意点として、技術要素や物理設備の性質自体は、CISSPや国内外を問わずに普遍的に通用知識になりますが、それらの捉え方や考え方自体はCISSP固有であるケースもあります。ですので、実務経験者からすると、他の資格やガイドラインと言ってることが違う、自身の業務では全く違う考え方を採用している、自身が所属している組織にはアンマッチというようなケースもあります。それらはあくまで「CISSPとしての考え方」つまり、米国でスタンダードなナレッジの一つと割り切って捉えるべきかと思います。とはいえ、IT業界でコーポレートから技術まで幅広いレイヤで頂点に君臨する米国基準であることには変わりませんので、あくまでベストプラクティスの一つ、されど米国の標準資格といった心持で臨むと気持ちよく勉強できる気がします。

CISSPでは頻繁に問題が更新されるらしく、過去問や公式問題集の内容がそのまま出題されることはありません。一方、出題形式が変わって同じ単語が登場する可能性はあるため、単語自体や単語の意味を抑えておく意義はあります。少し意識した点としては、略語のみならず正式名称まで確認をして、選択肢や問題文に略語が登場した際に意味を把握できるようにしました。多岐にわたる分野から様々な略語が登場する点や正式名称で概ねの概念を把握できる点から、略語の意味が分からず失点するケースを防げるかと思います。

回答訓練

CISSPで問われる本質は単純な知識ではなく知識を含めた「CISSPの」考え方です。そのため、それらを根本的に身につけておかなければ失点を重ねることになります。

せっかくなのでCISSPチックな4択を用意してみました。
こちらをベースに回答のイメージを紹介したいと思います。

組織の情報セキュリティにおいて最も重要視されるべき概念を選択してください。
1.情報資産を適切に保護してビジネスの継続性を支援する
2.有効かつ効率的なナレッジや技術を導入し情報システムの堅牢性維持に努める
3.技術、運用、物理の観点から網羅的に対策を実施することで情報システムが保有するリスクの低減に努める
4.ガバナンス、マネジメント、プロシージャの取組みにおいて組織が保有する情報資産の価値を向上させる

情報セキュリティでは価値のあるものを保護することが重要になりますが、組織で守るべきものには「ビジネス」という「組織の最大ミッション」に影響する資産が該当します。
これには、物理資産やプログラム資産、その他ビジネスで取り扱う顧客情報まで様々なものが該当します。

ここで注意すべきなのは、資産は技術関連に限定されないことです。技術資産のみが保護されていたとしてもビジネスリスク(漏洩による法的責任、レピュテーションリスク、ビジネス優位性の喪失)を内包する資産への保護が疎かであれば組織の事業継続に大きな影響を及ぼします。最終的に技術対策が必要になるケースは多いですが、それ自体が最優先の目的ではないことは認識しておく必要があります。
2はビジネス視点の文言が抜けている点から正しくはあるものの、1には劣ると考えています。

また、情報セキュリティの取り組みはあくまでビジネスの支援です。情報資産の価値を向上させることが主目的ではなく、資産のビジネス価値が損なわれないようにする、損なわれたとしてもビジネスに影響が出ないようにすることが重要です。この点においては、資産に対する分類(classification、categorize)・分析を行ったうえで脅威・リスクを洗い出し、回避、転嫁、低減、受容から適切なリスク対応戦略をとることも求められます。3では、リスクの低減に努めるとありますが、これが必ずしも正しいとは限らず、対策コストの方がリスク顕在化による損害よりも高くつく場合、あえて対策をしない「受容」戦略をとることも検討すべきといえます。4についても「情報資産の価値を向上」とあるため、1の方が適切と言えます。

このように、ビジネス視点からトップダウンに資産を保護していくことが組織における情報セキュリティの根本的な考え方になります。
まずは、抽象的な方針が定義されたポリシが定められ、それに沿ってベースライン(最低限の基準)やスタンダード(標準)に落とし込み、より具体的なプロシージャを実装していくような流れは、CISSPの各ドメインでも登場してきます。情報セキュリティの観点から組織がどういう状態であるか(何もできていないのか、ある程度対策できているのか、どこに問題があるのか)を判断して適切な解決策を選択できるようになることを目標としておくと、自分が何を勉強しているのかを見失わずに済む気がします。

なお、CISSPで導入すべき技術やナレッジは必ずしも業界最先端のものである必要はなく、信頼性が担保されたものも推奨されます。ベストプラクティス(NIST)などの情報を取り込むところもこれらが反映されていると思います。

あとは細かいテクニックですが、合格ラインは70%となっているため、極端に失点を恐れる必要はない気がします。50%-60%程度に自信をもって回答できていれば、2択に絞れた問題も半分以上は回収できるはずです。また、CISOあたりに求められる知識が中心のため、各要素に精通している必要はありません(たまに出題されますが捨て問と判断して差し支えないないです)。単語をみて大まかな特徴、メリット、デメリットが理解できていれば大半の問題は回答可能です。ただ、同じ用語であっても日本でよく扱われる意味とCISSPでの捉え方に齟齬があるケースもあるので、事前に知っている単語でも定義や扱いを確認しておくとよいかもしれません。

所感

CISSP自体は、幅広く浅くといった感じで各領域で求められるのは概要レベルの知識です。ですので、これ単体でセキュリティプロフェッショナルとするのは正直疑問です。
例えば、TCPであればSYN、ACKを聞かれる程度でパケットレイアウト等まで言及されるようなことはおそらく稀です。関連ガイドラインについてもどのガイドがどの分野のガイドなのか、どのような内容が定義がされているのか程度が主で、一言一句覚えるようなことは必要ありません。また、CISSPホルダであっても、2要素認証を実装してください、WAFをチューニングしてください、脆弱性診断を実施して修正対応まで実施してください、インシデントレスポンスでログ解析してくださいといった具体的な作業では手が止まる気がします。総括すると、セキュリティ責任者などの上級職や関連する従業員は取得すべき資格ですが、必ずしも万人にフィットするものではなさそうです。ここら辺は他にも関連資格があるようなのでもしかするとサポートされているのかもしれません。

最後に、試験とは関係ありませんが、勉強してなんとなく感じたのは、やはり人の扱いが米国と日本で異なっている点です。米国では個人に過度な期待をしない、言い換えると人はミスをしたり、少なからず感情的に行動して、非合理的な行動をするものと判断しています。そのため、米国の基準や規則ではそれを織り込み済みでルールや対策を整備し、上級職がそれらの管理・説明責任を負うという形態が構築されている気がします。例えば、従業員が技術的な最小権限が付与されているにもかかわらず誤って機密を公開してしまう、解雇を理由に論理爆弾をしかける、個人的な利益のために営業秘密を他社に持ち出す、運用者が操作を間違えてシステムデータを削除してしまうなど、様々な人的リスクがありますが、CISSPではそれらも考慮のうえでトップダウンに教育、トレーニング、NDA(秘密保持契約)、デュアルチェックなどでリスク管理を行っています。たとえ、リスクが顕在化したとしても組織としての責任は十分に果たしているため、残りの責任は従業員に擦り付ければ組織が守られます(事業継続できます)。一方、日本では個人の働きに過度に期待するケースがよく見受けられます。これは、米国では上級職が担うべき管理責任や説明責任までを末端の従業員に押し付け、結果的にリスクが顕在化した際の対策が取られておらず被害が拡大する、レベルの低いインシデントが世間に露呈する、挙句問題をうやむやにしたまま言い逃れる、といったことに繋がっているように思います。つまり何が言いたいのかというと、会社・組織がうまくいかないのは若手社員のせいではなく、だいたい経営層や管理職のせいです。CISSPではリスク管理の観点から組織を俯瞰するスキルも多少身につくので、問題が起こったときに自分が悪いのか否かを判断して自分を守れるようになることも重要だと思いました。

おわり

log4shell 年末防衛戦

log4shell(CVE-2021-44228)が先週金曜日頃から話題になり一週間経ちました。
CVSSが最大スコア10ということで、いろいろなところで被害調査や対策実施に追われていたのではないでしょうか。

logging.apache.org

概要

この脆弱性Javaのロギングに関するライブラリであるlog4j-coreというパッケージが対象となっています。
特にJavaアプリケーションが DNSLDAPを利用するためのJava Naming and Directory Interface(JNDI)に関するJNDI lookup という機能がよろしくないようです。

JNDI lookupは${}で囲まれたログ文字列を変数化し、DNSLDAP 等などの外部ドメインが含まれていればリクエストを飛ばしてしまいます。
そのため、まずは悪性LDAPサーバにアクセスさせ、悪性クラスファイルを配置したwebサーバに誘導することで任意のコード実行が可能になります。
また、任意のコード実行まで行われなかったとしても、攻撃フローの途中で行われるDNSクエリから環境変数が流出するケースやDos攻撃も想定されます。
普通の環境変数であれば許容範囲ですがAWSのアクセスキーなどが漏洩すると笑えないことになります。

milestone-of-se.nesuke.com

脆弱性有無の判定

この脆弱性(CVE-2021-44228)はlog4j-coreというパッケージに含まれていますが、紛らわしいものとしてlog4j-apilog4j-to-slf4jといったライブラリもあります。
log4j-apiはバックエンドとしてlog4j-coreを利用していれば問題ですが、そうでなければこのファイル自体にはJNDI lookupが含まれていないため問題なさそうです。
log4j-to-slf4jについてもslf4j APIとの互換ライブラリであるため、問題はありません。
そのため、該当バージョンのlog4j-coreが存在しているかが重要になります。

www.slf4j.org

log4j-core(2.0-beta9から2.14.1まで)を検出する方法には以下のような方法があるようです。
MavenのようなjavaパッケージマネージャやrpmのようなOSパッケージマネージャの機能で依存パッケージを出力する方法
・findコマンドやwhereコマンドでファイルを全探索する方法
・実行中のjavaプロセスが参照するクラス一覧が格納されたクラスパスから検索

パッケージマネージャですべて検出できるのか、WAR ファイルは大丈夫かなど、いくつか懸念はあるものの、ある程度有効っぽいです。
ちなみに私有VMでファイル検索を試してみましたがノーコード開発ツールのMendixとリバースエンジニアリングツールのGhidraが引っ掛かりました。
f:id:FallenPigeon:20211218161920p:plain

脆弱性診断ツールでもこの機能が使われているケースがあり、セキュリティツールを使おうとしたら死んだみたいなこともありそうです。

PoCコードもたくさん出回っているので簡単な検証を実施するのもよいかもしれません。
各製品の対応状況をまとめたリストもあるようです。

log4shell/software at main · NCSC-NL/log4shell · GitHub

被害調査

パッチ適用前に攻撃が行われていないか確認するためには、ログから特徴的な挙動を探す形になります。
攻撃時には通常の運用では発生しないアウトバウンド通信が行われるはずです。特にLDAPDNSに関して不審なものが見つかれば、リクエストとレスポンスを確認すべきでしょう。
これらの挙動が確認された場合は、対象のJavaアプリを中心に本格的な調査が必要になります。Javaアプリが行った挙動ログを確認し、不審なものを抽出していきましょう。

恒久対策

恒久対策はJavalog4jの更新になります。が、いくつか注意点もありそうです。
当初はJavaがこのバージョンなら他の対策は不要、log4jは2.15であれば問題なしといった情報が出回っていましたが、2.15でのDos攻撃、情報漏洩(第2号:CVE-2021-45046)や該当Javaバージョンのパラメータ回避策が登場してきています。
2.16についても無限再帰によるDos攻撃(第3号:CVE-2021-45105)が発見され、修正された2.17が登場しています。
どちらも最新バージョンにするほかなさそうです。

www.bleepingcomputer.com
www.bleepingcomputer.com

緩和策

そんなにポンポン更新出来たら苦労はせんのじゃボケという方もいらっしゃるかと思います。

Javaやアプリに変更を加えずにできる有効な緩和策は、インバウンド通信による接続元の制限が挙げられます。
脆弱性Javaライブラリに悪性ペイロードを着弾させることで顕在化するため、ネットワークレイヤの遮断で大半の攻撃は防止できます。また、アウトバウンド通信についても必要最低限、特にLDAPDNSなどをブロックすることで二重防御が可能です。

もう一つの方法は、WAFルールによるブロックになります。ただし、WAFのブロックは基本文字列比較で行われます。
この脆弱性は多数の文字列エスケープ手法が発見されているため、過信は禁物です。

github.com

最後にサーバ側の対策になります。
trustURLcodebaseやformsgnolookupsのパラメータ設定が有効とされていましたが、回避策が登場しているようです。
いまのところjndilookup.classを削除する方法がまともそうです。

回避策がさらに登場する可能性があるため、恒久策が取れない場合は複数の緩和策の実施を検討しましょう。