ぶるーたるごぶりん

UI, UX, セキュリティとか😘

2020年の買ってよかったもの (主に仕事周りと音楽)

アフィとかなくて単純に「これよかったからお前も買えよ」みたいなやつ

仕事が完全なリモートワークになり、その際に買ってよかったものとかを適当に記載
(一部 2019年に買ったものだけど、リモートワークになって「あって良かったー」というやつも)

あと後半に蛇足で買って良かった音楽関係のもの(ギター関連・CDあたり)

買ってよかったもの [仕事・デスク周り・その他]

骨伝導イヤフォン

aftershokz.jp

最近皆こぞって買ってる(気がする)骨伝導イヤフォンです。   詳しくはどこかのレビューとか読んでもらえればいいと思います。かなり良かったです。
約1年程で壊れたのですが、保証が2年だったので新品と交換してくれました。

KindleiPhone の音声読み上げで流し、風呂に入りながら読書をするという使い方などをしてます。
人生は短いので、コンテンツ(風呂と本)を並列で消化できて最高です。

続きを読む

株式会社ビズリーチ(Visional Incubation)を退職します

タイトルの通り、学部卒から新卒で 4年半ほど勤めました株式会社ビズリーチ(正確にはビジョナルグループのビジョナルインキュベーション株式会社)を退職します。
ビズリーチへの入社 -> グループ経営化 -> visional incubationへの転籍 -> 退職 という流れです)

9/27 に最終出社で、11/15まで有給消化です。 45日近い休暇を満喫し、無事に「そろそろ働かせてくれ、助けてくれ」という心になりましたので、社会に戻りたいと思います。

長い休暇でしたので、積読していた本を消化しつつ、 ペネトレーションテストのトレーニング(HTB)で遊んだり、 億劫で手を出さなかったあたりの勉強や運動や、とにかく健全に過ごしておりました。


さて、読者が喜びそうな要素だけを先にまとめますと、以下となります。

前職

  • 総合評価で、自分にとってはかなり良い会社でした
  • 採用管理サービスの開発(Scala) -> セキュリティチーム(脆弱性診断・ログ監視設計とか) -> 脆弱性データベースの開発運用(Kotlin/Java) とかをやってました

次の職場

  • Fintechのレッドチームで働きます
  • リモートワークをしてる中で、オファーを貰ったことで改めてキャリア・やりたいこと・興味があること・どういう環境(リモートなど)を求めているか棚卸した結果、転職を決定
  • COVID-19 でもIT系は他の業界よりも影響を受けにくいため、この時期の転職もリスクとしては低い気がした
  • セキュリティエンジニアの需要供給(と、自身の若さ)を考えるとある程度選択の余裕はあると思っていたため
  • (社会人の平均年齢と比較して)自分は相対的に若いため、30歳までは辛くても経験値を稼ごうと言う考えのため

以下、便所の落書きくらいに思っていただければ。

会社について

前職についてですが

冒頭では総合評価で良い会社だったと書きましたが、 1年目に胸糞悪いことが不定期で起こり、めっちゃキレ散らかしていましたし、今でもそのことに関しては恨んでいます。

ただちゃんと補足しておくと、年々会社が(自分の視点では)真っ当になっていき、仕事も面白いものに大きくシフトしていきました。 なので、最終的には新卒として選んだ会社として、かなりベストに近いものだったように思えます。お世辞抜きで。 現在はバイアス抜きで普通にホワイトな会社なんじゃないでしょうか? 自分が体験した部署(ロール?)は少なくともホワイトだったと思います。 まあ3部署しか移ってないので自分が見たとこだけ良かったのかもしれませんが。

とはいえ、文化的にはかなり色が強い会社です。 なので合わない人には徹底的に合わない組織だと思いますし、 実際、自分は文化面でそりが合わいことが多々ありました。 一方で、それらの特色ある文化面の強さからか、内部の人は人柄が良い人が多かったと思っています。 実際4年半の仕事の中で関わった人のほとんどは人柄の良い人ばかりでしたし、 尊敬できる人ばかりでした。

(知り合いが使っていた表現ですが、) とにかく性格的にevilな人は殆ど居なかったように感じます。 例えば「極端な成果主義」であったり、「他者の仕事に対して敬意を払うことがおざなりになってる人」は、 社内ではそれほど観測しなかった気がします。 (もちろんこれをevilと捉えない人もいると思うので、まあそう言った方は軽く聞き流してください)

まとめると、 自分のように誰と働くのかを結構重視してるタイプにとっては、とても良い会社でした。

何をやっていたか

色々なタイミングも重なり、かなり幅広くやらせて貰えたと思います。

触れて問題ない程度に丸め込んだりオープンな情報ベースで書きますが、以下のことをやってました。

  • 1-2年目 (採用管理ツールのバックエンドの開発)

    • 非機能要件周りの開発・運用
    • バックエンド側・バッチサーバーなどの開発・運用 (Scala)
    • ほんのたまにフロント開発 (angular(.js))
  • 2-4年目(横断セキュリティの部署)

  • 4 - 4.5年目(脆弱性DBサービスの開発・運用)

最初の部署は、リリースしてから1年後くらいのサービスであったため、 組織規模も少数の上、幅広いタスクがありました。 そのあと異常な組織拡大を体験してこれまた多くの案件・課題と対峙して、非常に面白い環境だったと思います。
結果だけをみると仕事内容は非機能要件ばかりやってました。 そのため、新規開発に興味をあまり持たない人間になりましたが、自分には合っていたので全てヨシです。

また、タスクの中で脆弱性診断レポートを見る機会があり、その際に脳汁がドバドバ出たことで、見様見真似でサービスの問題探しを業務後に遊びでやってたりしていました。 結果、セキュリティ部署の設立のときにそのまま異動することとなりまして、運があったなーと振り返って思います。

セキュリティ部署では 多分人生の中で一番学びが多く、自分の将来をどっちに振るかを真剣に考えた時期となりました。 とはいえ、当時の自分の知識は(今もそうですが)素人に毛が生えた程度であったため、 インプットいっぱいしてどうにかしようと四苦八苦してました。

最後の部署は在籍自体は短かったですが、前部署の知識などを活かせる「OSS脆弱性DB」の開発運用と言うのをやってました。 横断セキュリティ部署にいたこともあり、多少の知識コンバートで済む場所もあれば、 (自組織以外の)開発ライフサイクルの知識であったり、各言語のパッケージ管理システムの知識など 特殊な知識が必要になる部分もありました。 そのため、ヒーヒー言いながら同僚の方に色々と教えを乞いながら仕事していました。 これらの知識は汎用的なものもあれば、今後一生使わないんだろうと思える部分もあって素直に楽しかったです。


「やっていたこと」の総評になりますが、 たまに耳にする謳い文句「この会社でしかできないこと」という言葉は、 確かにビジョナルグループと言う会社・グループに存在したと思います。

厳密に言うと、世界で10社とか、20社くらいは同じ仕事を提供できる組織が存在すると思います。 ただ、国内のみで絞ればここくらいしかないという仕事は確かに存在していました。

例えば「脆弱性DBの開発・運用」はまさしくこの会社でしかできないことのはずです。 他にも、(合弁事業会社になりましたが)求人検索エンジンの開発(ex. クローラー)とかも、かなり特色のあるシステムだと思います。

と、こんなことを書いた上で自分で反論となる要素を出してしまいますが....
実はOSS脆弱性DBサービスは他にも国内で存在しています。
ただ、正直自分が 1セキュリティエンジニアとして使う場合、貧弱だったり遅かったり、運用負荷が高すぎたり、厳しいものが多くある印象を持ちました。 そう言った意味で、品質面・運用面などの部分である程度に進んだ「OSS脆弱性DB」の運用と言うのは国内ではここしかできない仕事だと勝手に思っていました。
(※この発言は個人の見解であって、所属組織を代表するものではありませんし、そもそも退職済みで、こんなけおだてても自分に1銭も入ってきません)

他にも M&A とか、物流系や色々と横に広く伸び始めているので、HR系だけじゃなくなり、グループとして面白い領域に進んでいるのではないでしょうか。

生憎と自分はビジネスよりもセキュリティ組織をどうするのかと言った観点にしか興味がないと改めてわかったので、そこまで興味は強くなかったですが

雑にまとめますと、 あらゆる会社と同様に、この会社にはこの会社独自の要素があり、そこがマッチする人にとっては面白い仕事ができると思います。

と言う感じです。そう言った要素を総合した結果、自分にとっては良い環境でした。

なんで転職するか

これだけベタ褒めしてるのに「なんで転職するんだ?」と思われたかもしれません。 実際オファーを貰うまであまり考えていませんでした。

しかし、オファーをもらって改めてキャリアなどを考え直した際に転職しようと決めました。

  • オファーを貰ったことで、改めて自分がどういう部分に楽しみを感じ、どういう点が伸ばせるか(どう給与を上げていくのか)を考え直した
  • セキュリティエンジニアとしてのキャリアパスをどう選ぶのかを考え直した
    • 極論的な言い方をすると Red, Blue(攻撃側・防御側)どちらに進むのか
    • どの領域が好きで、どの領域は苦手か(ex. 脆弱性診断, SOC, フォレンジック, IR, など)
    • 何をすると給与を上げやすいか
      • 今後のDevSecOps的部分の需要に対してどこに投資するとリターンがデカそうか?と言う打算
      • そのスキルを伸ばした場合に「そのスキル」を取ってくれそうな会社はどこがあるか(規模・業態など)
  • コロナによってリモートワークが基本となった(時間が多くできた)のでよりチャレンジしたい
  • 周りで子供ができたり結婚して時間があまり取れてない人を多く見た(時間がなくなる所を見た)ので、頑張れるときに頑張る

これらを元に、オファー内容を以下のような感じで捉えてました。

  • オファー内容の業種がFintech だった
    • (あたり前ですが)セキュリティへの投資額・要件の難易度が高いと判断
    • 前のチームの上司が、金融あたりは1回チャレンジするといいかもねと、アドバイスをくれていた
    • 何でもそうですが、下から上に上がる際は努力が必要ですが、上から下に落ちるのは容易なので、いっぺん上がろうという決意
  • 自社開発だった
    • 元々は自社サービスの開発をやっていたこともあり、次のような内容に対して強い意志を持っていた
      • どのようにセキュリティを開発に組み込むのか (いかにアジャイル開発などに組み込むか)
      • ビジネス・UX を損なわないセキュリティデザインをどう作るか
      • いかに最適に問題を検出し、それを組織的・機能的にガードできる状態にするか

(セキュリティをやってる人なら書かずともわかると思いますが、) この辺りは、ショットで診断をして直すということよりも、そこから分かる傾向であったりから問題が発生しない体制・仕組み・アーキテクチャを目指していくということに関心が強いという物です。
(もちろんそれ抜きで、面白い脆弱性を見るのは大好きと言った技術的好奇心も持っていますが)


話をめっちゃ逸れますが、 この辺りのセキュリティ文化であったりの話は、Google SRE本3弾がめちゃくちゃいいことを沢山書いてるので皆さんもぜひ読んでください
https://landing.google.com/sre/books/

無料です


と、これらの要素が社内セキュリティの面白さだと思っており、 オファー内容で網羅されていたこともあって魅力的に見えました。

なので、これらの要素に惹かれるような状態である内は、(狭く深くが求められやすい)セキュリティベンダーには行かないだろうなーと思ってます。 もちろん札束で顔面叩かれまくったら考えちゃうかもですが、その時の自身の状態によると思うので、その時にならないとわからないです。

おわりに

現状のスキルとしては、WebAppSecに極振りなので、ここからのステ振りをどうしてくかを考えて育成計画をちゃんとやっていきたいなーと思ってます。 また、その観点で次の職場は英語が求められる環境らしいので、英語弱者の自分としては背水の陣を敷けて嬉しい限りです。1-2年は辛いことがいっぱいでしょうが頑張ります。

こんな感じで退職することとなりましたが、 とにかく関わった方々には感謝しかないです。

特に、仕事を通して仕事の仕方というか、そう言った普遍的な部分から技術的な部分まで、様々なことを吸収させてもらえたのは最高に良い経験でした。

仕事を異常に丁寧に行うM氏、 ベースとなるセキュリティの考え方を仕事を通して教えてくださったO氏 には頭が上がりません。

他にもルノワールアセンブリの勉強会を開いてくれたY氏、 毎週Scalaのコップ本輪読会や、HTTPサーバを作ろうの会を開いてくださったI氏・T氏、 結果的に非機能要件ばかり振ってくださったK氏・S氏、 有志で行った○○すべらない話に参加された多くの方々には感謝しても仕切れないです。

ありがとうございました。


最後にWishlistは貼りませんが、 今年一番良かったインドのプログレッシブメタルバンドの新譜貼っておきます https://pineappleexpressmusic.bandcamp.com/album/passages

退職振り返りポエム

退職ポエムです。 退職エントリは退職日が来たら投稿します。

各年度でうまくいったこと、うまくいかなかったこと、 これをやれば良かったかなーと思っていることを書きます。

なんで辞めるのかとかは別の投稿にて。

やってたこと

  • 1-2年目 : 採用管理サービスの開発 (Scala)
  • 2-4年目 : 横断セキュリティチーム(脆弱性診断・ログ監視基盤の開発運用)
  • 4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java)

うまくやれたこと、やれなかったこと

1 - 2年目

1-2年目 : 採用管理サービスの開発 (Scala)

正直今の自分から見て何もかもがうまくいってなかったし、努力も人並み以下、スペシャリティや軸というものもないという状態だったのが反省点。 ただ結果的に次年度から持ち直したので、まあ良かったでしょう。 環境がすこぶる良かったのでそれに救われました。

良くなかった点

  • 軸が無かった
  • 深めの技術的なことは(学習コスト的にストレスと感じるので)億劫になってた
  • 結果、フレームワークとかの使い方を学んで何かをやった気になる という典型的なダメパターン

(自主的な部分で)やって良かったこと

  • 外部ベンダーの脆弱性診断レポートを読んだ事
    • 脳汁ドバドバ出て頭がおかしくなった
    • 自部署・他部署に対して(許可をもらって)脆弱性探しを見様見真似でやってた事
  • 技術書典に合同誌で出さしてもらった事
    • 身内開発者コミュニティみたいなのに所属した事で、色々と学びであったり、やる気などをを得られた事

次節にて書くんですが、 ガッツリとした新規開発っぽいことを結果的にあまりやらなかった2年間で、結果として新機能開発に対してあまり興味が出ない人間になった気がします。 もしかしたら元々そうだったのかも・・・?

とはいえ、それが結果的に今につながっていると思ってるので経験と今の方向性的に大変良かった気がします。 今と違う道に歩んでたのであればミスマッチになってたかもしれないので運ですかね。

(受動的な部分で)良かったこと

  • バグ修正チームの所属と対応 [短期]
  • (結果として)非機能要件の開発ばかりやってたこと(パフォーマンス・バグ・セキュリティ・開発環境整備など)[長期]
  • HTTPサーバをRFCを見ながら開発しようの会への参加(先輩の完全なボランティア)
    • 一時ソースに当たれという強い圧力
    • (仕事がScalaで、まだそれほどわかってもいなかったのに流行っているという理由で Goをやって)「一つの言語をマスターできないやつは他の言語やってもマスターできない(意訳)」というど正論を(優しく)アドバイスしてもらった事
  • めちゃくちゃ丁寧に仕事する方と同じチームで開発した事
    • 完全に自分の中での仕事の姿勢が整ったのでこの会社で働いた中で一番良い経験だった
  • 実費で海外カンファレンスに出たりするような先輩などが居たのでやる気が上がった
  • セキュリティチーム発足時に声をかけてもらって異動したこと

脆弱性レポートが面白すぎたことで完全に道を踏み外しましたが、 それまでは特別「何か1つに軸を」という点が疎かでした。

ただ、レポートを読んで面白いと思って気がついたら異動していましたし、 非機能要件周りへの欲求みたいなのが合わさっていい感じになったので、チープですがパズルが合わさったみたいな感じですかね。 とはいえ殆ど環境のおかげなので同僚の方々には感謝。

あと自分は馬鹿なりに行動力はあるタイプだと自負していて、そこ前面に出して色々活動してたのは褒めていい気がしてきました。

やれば良かったこと

「やれば良かったこと」というより、「今の方向性(セキュリティ)じゃなかったらこれをやったら良さそう」という内容になってしまいますが、 例えば以下をやったら良いのかなーと思いました。

  • ISUCON の過去問を一通りひとりでやる
    • サーバーサイド・ミドルウェア・ブラウザ・フロント周りの領域に大なり小なり足を突っ込めるため、初年度のエンジニアとしては登場人物のマッピングができて良さそう
    • 各要素のパフォーマンス周りにある程度の自信ができるのに2,3年くらいかかりそうだけどそこを越えれば一端のエンジニアにはなれそう?
      • 毎日1-2時間競プロやるの2年くらい続ければ良さそう
      • とはいえ今のセキュリティと同じで好きじゃ無いと大変きつい茨の道
      • 逆にいえば軸足とやる気があればたいていなんとかなる気もする
      • 問題は、競プロガチ勢とかのスキルがフルで求められるような土壌が多くの会社でない問題

仮に今別の道があったのであれば一つ軸を作るためにもISUCONとかの過去問全部やって、競プロとかに入り浸るような動きすれば、 まあ多少なりとも軸はできたのかなーと思います。

  • 仕事で使ってるOSSのコントリビュート
    • 正確にはコントリビュートが良いというよりは、利用言語におけるBetterな書き方とかを学ぶために
    • ただよっぽど気合がないと、(かつその特定要素に自信がないと)枝葉の修正しかしなさそう
  • 合わせて大きめの開発を個人か仕事でやる
    • ようは枝葉と根元部分の開発をやれというだけの割と当たり前の話になりそう

こっちはすごい当たり前の話になりますが、大きめの開発・小さめの開発を両方やっておくのはやっぱり重要だなと。 あとは(多少)Angular(.js)での開発があり、変にそっちに気が散ってた時期もありましたが、バッサリフロントは切るくらいの気持ちで 特定分野以外やらないという決意をして動いた方が良かったなと思います。

書けば書くほどこの年ダメだったなあ

(書き終わってから思い出しましたが)これをちゃんと丁寧にやれば良いだけだった。 https://github.com/kamranahmedse/developer-roadmap

2 - 4年目

2-4年目 : 横断セキュリティチーム(脆弱性診断・ログ監視基盤の開発運用)

ここら辺はこちらの記事に書いてある通りなのでまあ良いでしょう。 https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805

(自分の中では、プライベートの時間を確保した割りに)それなりに成長実感もあってかなりうまくいきました。

勉強癖というか、努力の仕方であったり、キャリアパスや自分が何に対してモチベがあり、 どういう点が弱いかなどが言語化できたのが良かったと思います。

あと強いオーナーシップを持って仕事に取り組んでいたのは素直に良かったです。 自社開発系のセキュリティは、強いオーナーシップ + フットワークが軽い( + 会社がそれに理解を持っている)と、かなり楽しくやれると思ってます。 なので「(誰もやらないなら)俺がやる(比喩表現です!)」くらいの強い気持ちが大切だと改めて思います。

今思う(時間もやる気もしっかりあれば)やったら良さそうなこととしては

  • 診断・ペンテスト周りを伸ばすのであれば特定分野のCTFを継続的に続けるのが(若干遠回り感強いですが)近道なのかなあ。ひとまずは毎日HTBやってます。半年くらい続けるつもり
  • ログ監視・インシデントレスポンスとかを伸ばすのであれば MITRE ATT&CK あたりの読み込みとそれっぽい環境を作って自分で封じ込みみたいなことやるのが良さそうな気がします。が実際どうなんでしょう?
    • 少なくともブルーは、レッドよりも攻撃寄りの知識があった方が良いとどなたかもいってましたし、最終到達地点を遠くに設定するのであれば、遠いようで近道な気がしてます。
    • 同僚の人が SANS - SEC504 を強く推してたので受けたい気持ちはありましたがSANS高すぎて個人でやりたい層には厳しすぎ

セキュリティのキャリアパスも、(勉強するための)ロードマップも殆どない気がしていて、 開発者向けの各要素のロードマップが、 セキュリティエンジニア向けに提供されてたら幸せになれそうな気がしました。 (誰か〜〜!!誰か氏〜〜〜!!)

あ、あと仕事の中でNISTシリーズ、FIPS, PCIDSS に(広く浅く)目を通す機会があり、結構良かったですね。 やはりホワイトペーパーは正義。

4 - 4.5年目

4-4年半 : 脆弱性DBの開発・運用 (Kotlin/Java)

最後の年ですね。

期間が短いのであまり書くこともないですが、失敗したことは結構ありました。

  • 自分の役割と評価者が求めていることのギャップを理解せずに突っ走った

    • これは「評価を上げる」という観点に絞った場合、確実に埋めておかないとガッツリ失敗する部分なのでかなり失敗した気がします。
      評価者はセキュリティエンジニアではなかったので、実施したタスクの効果などの理解の難しさはあったはずですが、それに甘えて「タスクの有用性を伝える」という機会を能動的に作りに行かなかったのは反省点(どう伝えれば良かったのかも不明)
    • そもそも「俺はこれをやったぞ」をアピールだけしても評価されるわけがないので、組織として今何に注力しており、自身のスキルで何を与えられるのかを理解をするのが重要なんでしょうね。サラリーマンですね。まあコロナとか色々なものが重なってとにかく失敗したので仕方ないと言ってしまうとそれまでなのかも。
  • Kotlin/Java わからんまま進んでた

    • Scalaしかやってなかったので、Kotlin/Java 周りにあまり理解がなかったのですが、それをそのままにして突っ込んでいったのはあまり褒められたもんじゃなかったですね。
    • 一応ロールはセキュリティエンジニアでしたが、セキュリティサービスなのもあって開発もある程度求められるような立ち位置にありました。そういう立場としっかりと認識していたにもかかわらずこうだったので、手を抜いていたのは事実。
  • インフラ弱い

    • わかりきってたことなんですが、ズーーーーーっと億劫でやっていませんでした。

と、書き終えてから気がつきましたが、あまり良かった点が思いつかない・・・。

あるとすると 台湾のIT大臣 オードリー・タン氏のGithubの草 より、自分は草が生えてなかったのに恥ずかしさを感じ、毎日草を生やす活動を始めたことでしょうか。 今は草を生やすのはやめて毎日CTF(正確には Hack The Box)をやるチャレンジしてます。

同僚の人で毎日(確か4年間も!!)草を生やしてる方がいたのですが、やってわかりましたがかなりきついです。本当に尊敬できるなーと感じます。 そこまでの情熱と根気は自分にはないので、できる範囲で頑張っていきたい所存です。

総合的に見て自分のよかったこと・反省点

以上、振り返ってみましたが結構「うまくやれてたこと」「やれてなかったこと」って多いですね。 4年半という長さを考えれば妥当なのかもしれないですが。

自分で言うのもあれですが、直近2年半は、総合的に見ればうまくいった方だと思います。 自分を制御してそれなりに頑張れた気がします。

あと改めて思いますがTwitterに生息しているような72時間耐久CTFみたいなことやってそうな方々は化物だなーと思います(褒めてます。いつもやる気をもらってるので感謝)。

うまくいったキッカケは、やはり先輩に言われた「一つの言語マスターできないやつは他の言語もマスターできない(意訳)」と言うど正論パンチだと思います。 結局のところ、仕事で行える範囲というのには限りがありますし、色々な物に手をつけるすぎると器用貧乏になりがちです。

別に器用貧乏が悪いわけじゃないですし、言い方を変えればカバー範囲が広いと言えます。 ただ、自分の場合は求められる仕事の範囲に対し、「カバー範囲が広い」ではなく、「広すぎて」「浅すぎる」でした。

なのでそこを矯正できたのは大成功でしょう。


あまり関係ないメンタル的な面では、以下のような事柄が自分のやる気を出させてたように思えます。

  • ゴールの日程が決まっている事柄を起点に、インプット・アウトプットをしたこと(CISSP受験/カンファレンス発表/技術書典の参加など)
  • Twitter に気絶するまでCTFをやってたり、9割セキュリティの話しかしない強者(またはそう見える人)を見て「このままだと死ぬ」と暗示をかけてたこと
  • エンジニアの同僚と専用のチャンネルを作って、間接的にその人たちが頑張ってるのを見て「このままだと死ぬ」と暗示をかけてたこと
  • 台湾のIT大臣よりコミット数が少なかったため「このままだと死ぬ」と暗示をかけてたこと
  • Pink Floyd の Time の歌詞 に大切なことが全て書かれているのでそれを不定期に読んで「このままだと死ぬ」と暗示をかけてたこと (TwitterBotでTimeの歌詞を呟く奴がいて、それで遊んでいるうちに癖になってた)

半分ジョークですが、半分はマジで、 この辺りの危機感というか、背水の陣を敷くのは自分のスペック上、正しい運用でした。

なんせ(就職前までの20数年間の経験上)、比較的に才能がないのは自覚してましたし、 逆に自分の良いところは馬鹿なりに努力はする点だと理解してたので、そこをうまく伸ばしていけばそれなりには力が付くだろうと。

(考えて)努力さえすれば良いと言う完璧な根拠も出揃っていて、

  • 人類全体を見れば思ったよりも努力をしてる人が少ないのは自明
    • 流行ったゲームの壺おじのクリア率を見るよりも明らか(5%くらいしかクリアしてないはず)
  • Pink Floyd - Timeにとにかく大切なことが全て書いてある
  • ダルビッシュ氏も考えて努力しろ(意訳)と言っている
  • なろう系で努力して最強になっている描写が多数観測されているため、なろうは真実を語っている

と、完璧な根拠が出揃っています。 なのでそれを信じて突っ走って正解でした。

でも何度も書いてしまうんですが、何よりも同僚の方に多く刺激をもらえたのが体験の割合として良かったです。

めっちゃ丁寧に仕事をするタイプの人であったり、 異常なスピードでコードを生成する人だったり、 わざわざ休日に時間まで作ってくれてアセンブリルノワールで教えてくれる先輩だったり、 毎週Scalaのコップ本の輪読会を(すでに読破済みであるにもかかわらず)開催してくれる先輩であったり。 あげればキリがありませんが、自分の足りない部分や、こうあると良いと思える部分を持ってる人たちに囲まれたのはお金では買えられない経験だったように思えます(エモ)

最後に

もう書くことないのでこれで終わりです。

貰えるものは貰いたいのでお金払いたい方はほしい物リストから何か買ってください。

Amazon の Wish Listはこちらです。 https://www.amazon.co.jp/hz/wishlist/ls/2UICHQMVQMTJP/ref=nav_wishlist_lists_1?_encoding=UTF8&type=wishlist

Bandcampの Wish List はこちらです。 https://bandcamp.com/kumagoro_alice/wishlist

それと一切関係ないですが、今年一番オススメのヘヴィメタルの新譜は、 インドのプログレッシブメタルバンド Pineapple Express - Passage です。 皆さん今すぐ書いましょう。

退職エントリは 11月中旬にに公開します。

GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話

GitHubが狙う「ライブラリのバージョン管理問題」の解決と依存関係地獄の話

GithubOSS Security Foundation に入りましたね。 大変興味深くて 関連するドキュメント なりについて会社のチームで雑談していたところ、 GitHubの「DependaBot」が何を狙い、どういう「大きな課題」を解決するのか? という話において、点と点が結びついた感じがあるので言語化してみます。

「この大きな課題」を説明する前に Dependency Hell について国内で言及してる記事がそれほどないので その辺りをまずは書いていきます。

ここのあたりが国内の開発者の中でも認識が広まっていくと、より一歩先のステージにいくのかなと思うので、 比較的ラフな感じで書いていきます。 ​ ちなみに、このブログ記事は所属組織とかに関係なく個人で執筆しています。 なので1デベロッパーとして、Dependabotが何を成し遂げるのか(ようとしているのか)を個人的感想でまとめてみます。 (僕の所属する組織は近しい領域なのでバイアスが掛かり気味かもです。ご注意ください。) ​ ちなみにこんなこと言いながら僕自身は DependaBot つかってないです。 (機会がないだけ) ​

Dependabotでできること

​ ここがメインの記事ではないので、サクッと書いてしまいます。 Dependabot は、マニフェストファイルはトップページに書いてあるとおり

Dependabotは依存関係を安全かつ最新に保つためにプルリクエストを作成します。

というツールです。

Dependabot は対象のGitプロジェクトの中から、 マニフェストファイル( pom.xml, Gemfile などの、依存するライブラリなどの管理ファイル)をベースに、「古いライブラリ」「脆弱性を持ってるライブラリ」などを検知し、自動でプルリクを作ってくれるやつです。 ​ 「え、めっちゃいいじゃん、即導入!」と行けばいいんですが、こいつを適切にハンドリングするのは なんだかんだ難しかったりします。 ​

続きを読む

DevOpsと(セキュリティ系)静的コード解析 (+DAST)が相性が悪いのはなぜか

※ 2020/5/22 一部加筆

SASTとIterativeな開発の相性の悪さ

若干煽り気味なタイトルですが、チーム内で話していてなぜセキュリティ静的コード解析(Static Application Security Testing: SAST)と言ったセキュリティアプローチがDevOpsで回りにくいのかが言語化できた。

そもそも静的コード解析というアプローチによるセキュリティ担保は基本的に「教科書的なウォーターフォール型」において有効で、 理由としては「人月・工数」のみで考えられた「誰でもその作業ができ、セキュリティの知識がなくても良い」みたいな作業者の能力を考慮しないアプローチが基本だからである。 そう言ったアプローチだと「SASTのアラート全部直してくれな!そしたらセキュアだから!」という形に落とし込むことにより、 問題をある程度封じ込めれると。 ただ、これをDevOps、というよりイテレーティブな開発(Scrum, Agile 系統)に落とし込むと、日々の開発のたびに発生するLintといったアラート地獄と向き合うこととなり、 その結果エンジニアがサボったり(ちょっと悪意のある言い方)して回らなくなる。 そもそも最初の導入で大量のエラーが出てげんなりしてやらないと思う。

続きを読む

WebアプリケーションにおけるDevSecOpsの理想と現実 Part 1 〜Bot型攻撃から見たパッチ管理について〜

はじめに

本記事では、前回の記事(https://brutalgoblin.hatenablog.jp/entry/2020/02/15/153805)にてあまり触れられなかったWebアプリケーションにおけるDevSecOpsの所感や考え方、動向を個人的思想でまとめた記事になります。

本記事は個人の感想が多分に含まれているため、どこかしらで(何かしらに)寄った意見や 知識不足から来る誤った解釈などが含まれているかもしれません。 もし本記事で誤った箇所や違ったポリシー、事業のフェーズによって違う考え方を持たれている方がいらっしゃいましたら、是非コメントやリプライなどで意見をください。 というか、私自身が迷っている部分も多くあるため、そういった知見を頂けるのであればこの記事を書いた甲斐があるというものなので、是非是非フィードバックを・・・!

本記事は章組をした段階であまりにもデカくになってしまいましたので、記事を分割して公開します。 記事の構成としては大まかに 「何から守るか(攻撃)」「どのように守るか(手段)」「手段には何があるか」「理想と現実」 という流れに沿って話を進めていこうと思いますが、書き終わった内容を順番に投稿していくのでこの流れから大きく脱線するかもしれません。

ちなみに本記事の根底にある考え方は、以下の資料あたりをかなり参考にしています。(パッと思いついたのが以下の資料なので他にも色々ある気がします。)

https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu
https://speakerdeck.com/rtechkouhou/e-yi-toshan-yi-gajiao-chai-suru-nei-bu-bu-zheng-toiuming-falsesasupensu
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043

続きを読む

セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか

セキュリティエンジニアになり、そこから2年間分の勉強内容と参考になった資料とか

自分の振り返りも兼ねて2年分の勉強内容とかをざっくりまとめようと思います。

新卒からバックエンド開発を2年程行い、その後セキュリティエンジニアとして横断セキュリティ部門に異動しました。 そこから更に2年が経ち、来月からセキュリティサービスの開発とかをすることになったので、 もし同じような人が居た際になんとなし参考になればいいかなという意図で書いてます。

ちなみにセキュリティ部門に異動するまでのセキュリティの知識レベルは「徳丸本を2回通しで読んでる」程度です。 セキュリティ部門に移ってからは脆弱性診断・ログ監視・開発ガイドライン周り・脆弱性管理とかをやってました。

本記事では自分自身がユーザ系の企業に属しているので、ベンダーとかそちら寄りの内容ではないです。 あとできる限り社内の事情を記載しません。何が問題になるかわからないですしあんまり重要じゃないので。

内容的には次の単語辺りがスコープです。 脆弱性診断, セキュアコーディング, ログ監視, インシデント対応

入って3ヶ月間くらい

入ってしばらくは診断の研修を受けたりしてました。 この頃はBurp Suiteの使い方とか学んでた気がします。 もともと開発をやってたのと基本的な脆弱性とかの問題は理解していたのでツールの使い方とか注意事項などを覚えるのを中心にしてた気がします。

この頃はとある診断員さんのスライドとかを軽く見ながらやられサイトとかを触ってました。
https://www.slideshare.net/zaki4649

今ならやられサイトは OWASP Juice shop とかを使った方がいい気がしますが、 診断対象がレガシーな傾向にあるなら OWASP Webgoat とかを利用した方が良い気がします。
https://www.slideshare.net/zaki4649/ss-116423487
https://owasp.org/www-project-webgoat/

自分が全くの未経験だった場合なら 徳丸本(体系的に学ぶ 安全なWebアプリケーションの作り方 第2版 脆弱性が生まれる原理と対策の実践) あたりを一周して Webセキュリティ担当者のための脆弱性診断スタートガイド 第2版 上野宣が教える新しい情報漏えいを防ぐ技術 を読むのが今なら最適解な気がします。

また、この頃からログ監視(社内ネットワーク監視)とかも仕事として入ったりしてました。 何もわからなかった気がするので、診断だけでも早くまともになろうとしてた気がします。

3ヶ月 - 6ヶ月

診断を早く一人前にならなければと思い、徳丸さんのブログとバグハンターのmasato.kinugawaさんのブログのバックナンバーを古いのから順に全部読んでました。

https://masatokinugawa.l0.cm/
https://blog.tokumaru.org/
http://www.tokumaru.org/d/

あとXSSチートシートとかを見たりしてどういうペイロードが何に影響するのかとか調べてた気がします。 今なら PayloadsAllTheThings という攻撃コードだけをまとめたリポジトリをまず見ろと自分に教えます。
https://github.com/swisskyrepo/PayloadsAllTheThings

脆弱性診断士スキルマッププロジェクトのWebアプリケーション脆弱性診断ガイドライン あたりもずっと眺めてた気がします。
https://github.com/ueno1000/WebAppPentestGuidelines/blob/master/WebAppPentestGuidelines.pdf

この頃からバグバウンティとCVEを取ることに憧れを抱き始めました。 当時の自分にアドバイスをするなら、「さっさとCVE童貞は捨てて憧れとかプライド・卑屈さを無くし、真面目に勉強した方が良い」と言います。
(CVEは取ろうと思えば簡単なものなら1日で取れると思うのでそんなにありがたがるものではないという意図です。もちろん強い(?)CVEもありますが)

CVEを取ろうとされている方はリクルートさんのRedTeamの発表で非常に参考になると思います。
RECRUIT RED TEAMのセキュリティトレーニング:OSSへの貢献とCVE IDの取得
https://recruit-tech.co.jp/blog/2018/09/25/redteam_training/
こちらに書いてあるように、ひたすらgit pull & 30分ほどコードを読んでを繰り返しまくるやつをやるといい気がします。

それと6ヶ月頃から運よくCISSPの研修を受けさせてもらったのでCISSPを取る気持ちで勉強してました。 (実務の経験年数が足りないので受かっても準会員となってしまいますが。ちなみに点数が1割くらい足らなくて落ちました。) 多分この書籍?をもらい、土日に4時間ずつ勉強するのを1年程続けてました。
新版 CISSP CBK公式ガイドブック
https://www.amazon.co.jp/%E6%96%B0%E7%89%88-CISSP-CBK%E5%85%AC%E5%BC%8F%E3%82%AC%E3%82%A4%E3%83%89%E3%83%96%E3%83%83%E3%82%AF-%E3%82%A2%E3%83%80%E3%83%A0%E3%83%BB%E3%82%B4%E3%83%BC%E3%83%89%E3%83%B3/dp/475710376X/ref=sr_1_1?__mk_ja_JP=%E3%82%AB%E3%82%BF%E3%82%AB%E3%83%8A&keywords=CISSP+%E6%97%A5%E6%9C%AC%E8%AA%9E&qid=1581733898&sr=8-1

このわからないなりにCISSP勉強したことが、この2年間の中で最もよかった勉強内容でした。 基本的なユーザ企業に置けるセキュリティの考慮事項・ビジネスとセキュリティの関係・ 実際の運用を考慮した体系的セキュリティのエッセンスがCISSPに詰まってると思います。 これひとつ学ぶだけで、「ユーザ企業における」セキュリティ運用立て付けで、それなりな判断をできるようにると思います。 なので、個人的にはユーザ企業に勤めているセキュリティエンジニアほどCISSPをお勧めします。 まあCISSP落ちたんですが。
体系的な知識だけであればセキュリティスペシャリストとかでもいいんだろうと思います。 ただCISSPの方が「ユーザ企業に求められる」ビジネスとセキュリティについて 現実的な知識が入ってくるきがするのでお金があるならそちらをお勧めします。 ちょっとオーバースペック感はありますが・・・。

それとこの時期は気が向いた時とかにOWASPで面白そうなプロジェクトがないかとか見てた気がしますが、 そんなに熱心には見てなかったですが。 OWASP Top 10よりも面白い内容がいっぱいあるので適当に眺めてみると良いかもしれません。
https://owasp.org/projects/

7ヶ月 - 12ヶ月

この頃は海外カンファレンスの資料を読み漁ってました。 2016以降に開かれたBlackhat, hitcon, ロシアのセキュリティカンファレンス(名前を忘れた)の発表スライドのなかで Webに関係あるものをひたすら落としてきて読んでました。

例えばBlackhatの場合、発表一覧の中で関連項目の絞り込みができるので、 Web AppSec, Security Development Lifecycle あたりで絞り込みを行い、 そこから気になる発表を見つたら、 発表名 + slide とかでググってスライドを見てました。 https://www.blackhat.com/us-19/briefings/schedule/

それと6-12ヶ月目までは徳丸さんのブログなども含めて仕事後1時間くらい(例のカンファレンスの資料含めて)ブログとかを読み、 そのあと帰る生活をしてました。 多分この辺りで徳丸さんとmasato.kinugawaさんのブログのバックナンバーは全部見終わった気がします。 めっちゃよかったです。

それと引き続きCISSPを取る気で勉強してました。 ただ気持ちは「俺はセキュリティを何も知らなすぎるので一般教養として勉強する」くらいの心持ちだったので 割と穏やかマイペースな感じで勉強してました。

実務ではこの辺りからログ監視・インシデントレスポンスっぽいことが少しだけ理解し始め、そちらに対する興味も増してきました。 とはいえまだまだピヨピヨ状態だったので今だったらここら辺から適当に選んで読んだり手を動かしたらよかったのかなと思います。
Awesome-Cybersecurity-Blueteam
https://github.com/meitar/awesome-cybersecurity-blueteam

合わせてawesomeシリーズにはめっちゃお世話になってる気がするので適当に摘んで見に行ったのも良かったです。
Awesome-Red-Teaming
https://github.com/yeyintminthuhtut/Awesome-Red-Teaming

Awesomeシリーズは結構色々あるのでその分野の知識があまりない段階で最初の方に見にいくといいと思いました。 多分そうすることで全体感というか、ロードマップみたいなものが見えてくる気がします。 https://github.com/sindresorhus/awesome#readme

それと実務関連でユーザ企業における脆弱性管理に関して、この資料が本当に素晴らしいと思って5,6回くらい読み直して参考にしてました。
脆弱性管理のベストプラクティスとスレットモニタリング
https://speakerdeck.com/rtechkouhou/cui-ruo-xing-guan-li-falsebesutopurakuteisutosuretutomonitaringu 上記の資料にも影響され、このあたりからCVEに全部目を通すようになりました。 某L社のエンジニアの方が「タイトルには最低限全部目を通してる」と書いてたので 「なるほど、普通は読むのね」と誤解(?)して読み始めました。

確かこの辺りで技術書典5でセキュリティテストの話書いてました。 https://techbookfest.org/event/tbf05/circle/25700002

1年 - 1年半

この頃はそろそろCVEを取ってこのコンプレックスにも似た感情をどうにかしようと思ってました。 なのでカッチョいいCVEを取るためにWebフレームワークの脆弱性を見つけようと思いはじめ、 まずは事例を知ることからということで 1つのフレームワーク脆弱性パッチコードをずっと読んで内容を理解するというのを続けてました。

脆弱性を見つけられなくても技術書典と何かのカンファレンスで発表できればと思ってたので無駄にはならないだろうと。 結果これを書いて出しました&発表しました。
https://techbookfest.org/event/tbf06/circle/36030002 (コードで理解するWebフレームワークの脆弱性 Playframework編 の方)
https://speakerdeck.com/kumagoro_alice/kototeli-jie-suruplayframeworkfalsecui-ruo-xing
知らないうちにカンファレンスの方は動画が上がってたので気になる方は検索すれば出てくると思います。

上記の発表をしたことでパッチコードを読むのが趣味になり、 今でも気になるCVEが発行された場合はパッチコード探して読むことを続けてます。

このタイミングでCISSP落ちました。

あとセキュアコーディングガイドライン関連の仕事があったので政府刊行物をちょろちょろ読んだりしてました。 PCIDSS, NIST 800シリーズあたりはセキュアコーディングから外れる部分も結構ありますが大変参考になりました。
(言うほど量を読んでないですが・・・)
https://ja.pcisecuritystandards.org/minisite/env2/
https://www.ipa.go.jp/security/publications/nist/

NISTは結構有志のかたが日本語化してたりするので助かりました。

1年半 - 2年

この頃からログ監視の仕事の比重が重くなったので四苦八苦してました。
インプットとしてはあまりうまく行ってなかった気がします。 この頃はインシデントレスポンスみたいな部分に自分の課題を感じてたので 今ならこの辺りを真っ先に読むのがよかったのかなと思います。
atomic-red-team
https://github.com/redcanaryco/atomic-red-team
Macにおける攻撃とかの話ってあんまり効かないので、こう言う例となるものって(実際あるかは置いておいて) 参考程度には良い気がします。

CSIRT:構築から運用まで
https://www.amazon.co.jp/CSIRT-%E6%A7%8B%E7%AF%89%E3%81%8B%E3%82%89%E9%81%8B%E7%94%A8%E3%81%BE%E3%81%A7-%E6%97%A5%E6%9C%AC%E3%82%B7%E3%83%BC%E3%82%B5%E3%83%BC%E3%83%88%E5%8D%94%E8%AD%B0%E4%BC%9A/dp/4757103697/ref=pd_sbs_14_img_0/358-0194960-2457850?_encoding=UTF8&pd_rd_i=4757103697&pd_rd_r=201243b6-8ef8-4cda-80b2-8e27f6da32c3&pd_rd_w=Rq3dO&pd_rd_wg=Z4EIP&pf_rd_p=ca22fd73-0f1e-4b39-9917-c84a20b3f3a8&pf_rd_r=J65PXP3C9WBKPR66GP5D&psc=1&refRID=J65PXP3C9WBKPR66GP5D
値段が高くて薄い&文字が大きめでしたがこれも良い書籍でした。 さらっと流すなら2日もあれば読める量です。 ただ中に書いてあるんですが、ユーザ企業向けのCSIRTではないです。

まだ読んでないですがお勧めされてるので読みたい。すごい分厚いからやる気でないですが・・・。
インシデントレスポンス 第3版
https://www.amazon.co.jp/%E3%82%A4%E3%83%B3%E3%82%B7%E3%83%87%E3%83%B3%E3%83%88%E3%83%AC%E3%82%B9%E3%83%9D%E3%83%B3%E3%82%B9-%E7%AC%AC3%E7%89%88-Jason-T-Luttgens/dp/4822279871

どこに載せるか迷ったけどよかった本や記事とか

パケットキャプチャの教科書
https://www.amazon.co.jp/gp/product/4797390719/ref=ppx_yo_dt_b_asin_title_o04_s00?ie=UTF8&psc=1
すごくわかりやすくて良かったです。 ちなみにミスってKindle版と書籍の2冊買っちゃいました。

ブラウザハック
https://www.amazon.co.jp/gp/product/B01DIV9AHQ/ref=ppx_yo_dt_b_d_asin_title_o03?ie=UTF8&psc=1
とても良いんですが、一般的なユーザ企業で求められるセキュリティからは大きく外れてはいる

サイバーセキュリティ レッドチーム実践ガイド
https://www.amazon.co.jp/%E3%82%B5%E3%82%A4%E3%83%90%E3%83%BC%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3-%E3%83%AC%E3%83%83%E3%83%89%E3%83%81%E3%83%BC%E3%83%A0%E5%AE%9F%E8%B7%B5%E3%82%AC%E3%82%A4%E3%83%89-Peter-Kim/dp/4839967571/ref=pd_bxgy_img_3/358-0194960-2457850?_encoding=UTF8&pd_rd_i=4839967571&pd_rd_r=04acdeac-2ebc-4868-84a4-dec0c6b33738&pd_rd_w=1KRzh&pd_rd_wg=gW6NF&pf_rd_p=587b16be-0f5e-4017-ba4e-8771a0be2909&pf_rd_r=379STDP2QQQK79R8VJR4&psc=1&refRID=379STDP2QQQK79R8VJR4
めっちゃ良い

Find Security Bugs というOSSのセキュリティ静的コード解析ツールの脆弱性検出パターンドキュメント
https://find-sec-bugs.github.io/bugs_ja.htm
Java/Scalaベースなんですが、コードベースの診断をしたいとかであれば大変参考になるはず。

PortSwigger Blog
https://portswigger.net/blog
良い記事がめっちゃあるのでバックナンバーから気になるのを見るだけでも良い

Hackerone - Hacktivity
https://hackerone.com/hacktivity?sort_type=latest_disclosable_activity_at&filter=type%3Aall&page=1&range=forever
バグバウンティプラットフォームのHackeroneの公開されたレポートが読める

体系的に学ぶモダン Web セキュリティ
https://speakerdeck.com/lmt_swallow/learn-modern-web-security-systematically
モダンWebに関する登場人物がまとまっていて本当に体系的ですごく参考になる資料でした

ユーザー企業における情報システムとセキュリティ
https://speakerdeck.com/ken5scal/yuzaqi-ye-niokeruqing-bao-sisutemutosekiyuritei-number-seccamp2019
とてもとても参考になるメチャクチャ良い資料でした

PoC読むのと実際まで評価するやつ
CVEを読んでるときにTwitterとかで CVE番号 + PoC とかで調べると結構引っかかるんですが、 それの評価と実際に刺さるかをDocker環境作ったりして試すのも割と良かった気がします。単純に面白いですし。
※当たり前ですが、中にはマルウェアとかあるので気をつけてくださいね。

終わりと雑記

長くなりましたが、こんな感じで勉強をしてた気がします。(全文で1万字)
他にも素晴らしすぎる本や資料があったはずなんですが、パッと思い出せないので一旦このくらいにしておきます。

2年経った今はDevSecOpsについて考える機会が増え、 アジャイルスクラムと言ったスタイルにいかにセキュリティを合わせていくか ということに破茶滅茶興味を持っているので、しばらくここに投資していこうとしてます。

DevSecOps自体はバズワードで、ベンダーが強く押し出してる部分があるので、 ベンダーに踊らされないようにしつつ、現実的なレベルで色々な会社がうまくセキュリティを担保できる世界がくるといいんだろうなーというのが 自分の感覚です。

Web界隈も大変わちゃわちゃしており、Webアプリセキュリティという観点で見ると 「ブラウザのセキュリティレベル」「フレームワークとかのデフォルトのセキュリティレベル」が共に上がっていっている現状があり、 実際に遭遇する攻撃・刺さる攻撃の質も変わってきてるように思えました。 そのため、開発者がリスクとする攻撃シナリオも変わっていき、防御も変わっていき・・・、 結果としてこれまでのDLC(Development Life Cycle)から少しずつDevSecOps的なDLCに移っていくだろうという推測です。 現時点ですでにこれまでのDLCでは守りきれないようになっているので、この考えは割と外れていないと思ってます。

なので、今後のDevSecOpsを考慮したDLCでは、 「開発者に対して安全な環境を提供し、ベストプラクティスに乗っ取った環境を提供し続ける」 「侵入を検知するために監視を行い、オートメーション化」 「脅威分析・素早い脆弱性管理(バグバウンティとかのトリアージ)」 とか、あとはゼロトラスト辺りがキーワードになってく気がしてます。

この辺りはNetflixのこの記事が結構含みを持った書き方をしており、参考になるかもです。
https://medium.com/@NetflixTechBlog/scaling-appsec-at-netflix-6a13d7ab6043
特に静的コード解析とかうまくいかなかったぜみたいなことを匂わせてたりした書き方で面白いです。


こういった資料がいっぱいあるおかげでこの2年なんとかなったので筆者の方々本当に感謝してます。

最後に勉強とは違って感銘を受けた言葉/記事を3つほど記載して終わります。

(翻訳)セキュリティで飯食いたい人向けの行動指針
https://ken5scal.hatenablog.com/entry/2017/07/19/%28%E7%BF%BB%E8%A8%B3%29%E3%82%BB%E3%82%AD%E3%83%A5%E3%83%AA%E3%83%86%E3%82%A3%E3%81%A7%E9%A3%AF%E9%A3%9F%E3%81%84%E3%81%9F%E3%81%84%E4%BA%BA%E5%90%91%E3%81%91%E3%81%AE%E5%BF%83%E3%81%AE%E6%8C%81

警告: 映画のような華々しさはない
完全もしくは標準的なカリキュラムなどない
手を動かせ。実践しろ。
コードを書け
コードを壊せ
知識を共有しろ
コミュニケーションを怠るな
辛いことも失敗もある
楽観者でいよう
助けを求めよう
Good luck and happy hacking!

徳丸氏のツイート
https://twitter.com/ockeghem/status/1224669744021659648

艦これAPIを叩く
https://np-complete.gitbook.io/c86-kancolle-api/
(この文章がなければセキュリティをやり始めなかった気がします。)

ありとあらゆる攻撃を考慮しないといけません。 ユーザの環境も様々です。 APIを提供する側はそれらを制限することなんてできません。 クライアントに正しいも間違っているもありません。 不正な攻撃であろうと全てのリクエストは平等に扱われてしまうことを忘れてはいけません。 とにかく想像力が必要です。 人間は全員犯罪者で、ありとあらゆる手段を使って攻撃をしてきます。 どんな攻撃ができそうか想像し続けましょう。 単純にシステム上のやりとりだけではありません。 ソーシャルハックもかなり有効な攻撃手段です。 (ハッカーに奪われた、5万ドルのTwitterアカウント「@N」:オーナーに返還 見事なソーシャルハック事例) 他のサービスの情報と組み合わせた攻撃も有効です。 本当に穴はないですか? XSSのように機械的に検出できるようなものではありません。 複雑なシステムの一つ一つは小さな穴でも、組み合わせたら大きな穴になることもあります。 本当に穴はないですか?

宣伝

技術書典8で「Firefox脆弱性レポートまとめ本」というのを出します。
https://techbookfest.org/event/tbf08/circle/5736916351713280