セキュリティを勉強しようと思い3ヶ月間で読んだ本の紹介と感想

直近3ヶ月ほどセキュリティを意識的に勉強してみようと思い、いくつか本を読んでみました。その読んだ本の紹介と簡単な感想を書きました。最後におまけで積読してる本も紹介しています。少しでも誰かの参考になれば幸いです。また「これもおすすめだよ!」ってものがあれば本に限らずぜひ教えてほしいです!

まずはじめに、私の前提知識やそもそもどうしてセキュリティを意識的に勉強しようと思ったのか?を書いておきます。

筆者の前提知識

この程度の知識があった上で本を読んでます!という前提を書いておきます。本の感想はこれらをふまえた上でのものです。

  • これまでモバイルアプリ開発がメインだったので、フロントエンド・サーバーサイドの脆弱性などは「徳丸本読んでなんとなくこんなのがあるの知ってる!」くらいのレベル
  • モバイルアプリ開発において意識すべきセキュリティはある程度理解して実践している(セキュアコーディングガイド読んで実践に活かしてます!くらいのレベル)
  • セキュリティエンジニアが利用するツールなどはほぼ知らない。Wiresharkは知ってます!BurpSuite初めて聞きました!くらのレベル
  • 暗号、ネットワークの知識は基本情報で基礎学びました!くらいのレベル

どういうモチベーションや目的で本を読んできたか

セキュリティを勉強すると言っても目的次第で読む本は変わるので、私のモチベーションや目的をざっくり書いておきます。

モチベーション

  • 将来的にエンジニアリングを経営目線で考える際のスキルとして、明らかにセキュリティに関するスキルが足りてないと実感し学ぶことにした
  • 私が働くスタートアップではセキュリティインシデントが事業存続を困難にする可能性があるため、インシデントを起きにくくするための対策、起きた場合のいい対応などを学ぶ必要性が高い
  • セキュリティに特化した技術力を身につけ、意識的に脆弱性を探すことができるようになりたい
  • 今のところセキュリティエンジニアになりたいわけではないが、セキュリティを学んで実践することが市場において今後評価されると予測し学ぶことにした

目的

  • 会社経営に活きるセキュリティ知識(技術力含め)を身に着け実践したい

どういう順番で本を読んだか

上記で書いたモチベーションや目的をふまえ、どういう順番で本を読んだかを書いておきます。

  • まずは経営 ✕ セキュリティの一般的な知識が身につきそうな本を読んでみた
  • 次はセキュリティの基礎知識を改めて学ぶために入門的な本を数冊読みつつ、気になるトピックの本も同時に読んでみた
  • 入門書がさらっと読めるようになったら、代表的な脆弱性(OWASP Top 10とか)を見つける手法や対策が学べそうな本を数冊読んでみた(今も読んでいる)

上記のことをふまえて読んできた順番に本を紹介します。

読んだ本の紹介と簡単な感想

経営とサイバーセキュリティ デジタルレジリエンシー

経営 ✕ セキュリティの基礎的な考え方を学ぶのにとても良い内容でした。「最優先で守るべきもの」を定義して対策するという話があり、当たり前といえばそうですがセキュリティは守りたいものや守るための対策がいっぱいになってしまう傾向があると思ってて、その中でも優先してやるべきことをはっきりさせるのが大事と書かれててよかったです。脅威・リスク分析みたいな手法の具体的なHowではなく、考え方を学ぶことを中心とした内容になってます。この本から読み始めて良かったです。

ゼロトラスト Googleが選んだ最強のセキュリティー

Zero Trustは名前の雰囲気からこういうことかな?くらいで全く知識がなかったので読んでみました。Zero Trustの考え方が必要になった背景を知れたのが一番の収穫です。境界防御だけじゃ対策として厳しい時代になってきた理由なども記載されていて学びが多かったです。最近だとVPN脆弱性を突いてゴニョゴニョする的な話を聞くので納得感がありました。

サイバー攻撃 ネット世界の裏側で起きていること

サイバー攻撃とはなにか?脆弱性とはなにか?をわかりやすく説明しつつ、バッファオーバーフローなどの脆弱性がなぜ起きてしまうのか?の部分はコードを交えながら解説してくれるのがとても良かったです。他にもCVSS、脆弱性報奨金制度、CTFなどセキュリティに関わるエンジニアが知っておくと良さそうな情報がいっぱい書かれています。最前線でサイバーセキュリティに取り組んでる方が書いた本でとても参考になりました。私のようにセキュリティの知識と技術力両方学びたい方にとてもおすすめできる一冊です。

企業を強くするサイバー演習

会社としてセキュリティに気をつけていてもセキュリティインシデントが起きる時は起きるのだと過去の経験から実感しています。そのため実際にインシデントが起きたらどう対応すべきか?を演習するのが大事だと思い読んでみました。演習の事前準備から実施、ふりかえりなど一連の工程が丁寧に紹介されています。「この組織でセキュリティインシデント起きたら対応できるか心配...」と思ってる方はぜひ読んでみてほしい一冊です。

徳丸浩のWebセキュリティ教室

こちらは昔読んだのですが改めて読み返してみました。脆弱性の定義として"「悪用可能なバグ(欠陥)」だと考えると分かりやすい。通常、プログラムにバグがあると、「できるはずのことができない」。だが、脆弱性はこの逆で、「できないはずのことができる」ようになる。"と書かれてて、これは説明する時に使えそうでとてもいい文でした。Webアプリケーションで起きがちな脆弱性を知りたい方におすすめできる一冊です。同じく徳丸さんが書いた『体系的に学ぶ 安全なWebアプリケーションの作り方』を合わせて読むと理解が深まると思います。

イラスト図解式 この一冊で全部わかるセキュリティの基本

セキュリティの知識は文字で理解するのが難しいこともあるなーと私は感じたので、イラストも交えて学べる本書は良かったです。書いてある内容は既知のことが多かったですが、イラストを交えると理解力上がりますし、人に説明する際の参考にもなります。イラストも交えた入門書をお探しの方にはおすすめできる一冊です。

サイバーセキュリティ入門 私たちを取り巻く光と闇 共立スマートセレクション

セキュリティの基礎知識が少しずつ身についてきたかも?と思ったので、入門書をさらっと読めるか試すために読んでみた一冊です。学生に向けた教科書っぽい作りになってますが、中身はかなりしっかりしています。ある程度知識を得た上で読んだのでさらっと読めましたが、これを最初に読んだら私は挫折しそうかも...と思いました。そのくらい中身は詰まってて丁寧な解説が書かれている本です。

ホワイトハッカー入門

入門なので「これを読めば君も今日からホワイトハッカーだ!」とはならない気もしますが、ホワイトハッカーの方々がどういうことを考えて活動してるのかイメージがつかめるいい本でした。「実際の業務でやるとなると攻撃対象の情報収集とか事前準備が相当時間かかりそうだなー」とか、いい意味で現実を知れる内容になってると思いました。

OWASP ZAPとGitHub Actionsで自動化する脆弱性診断 技術の泉シリーズ

Kindle Unlimitedにあったのでさらっと読んでみました。OWASP ZAPの存在を知らなかったので、それを知れただけで読んで良かったです。詳しい使い方は本書で扱ってないので後は自分で調べる必要があります。

フロントエンド開発のためのセキュリティ入門 知らなかったでは済まされない脆弱性対策の必須知識

Webフロントを詳しく知らない私にはとてもいい内容でした。最近出版された本なので情報が新しいのも良い点です。セキュリティのために作られた仕組みの解説、脆弱なコードの紹介、脆弱性対策が順番に書かれていてとても理解しやすかったです。この本に書いてあることが色んなサービスでどの程度行われてるのかとか今後見てみるとより参考になりそうです。気になる人は著者さんが話してるYouTubeを見てみるのがおすすめです。

www.youtube.com

ウクライナのサイバー戦争

最近新書で出てるのを知って読んでみました。知識が増えたわけではないですがサイバー戦争の生々しさが伝わってくる内容でした。国のインフラが狙われやすいようですが、場合によっては自分が働く企業が狙われるケースがあるかもしれないと考えると他人事ではないと思わされますね。

今読んでる本

この先の本は今読んでいる最中の本です。途中まで読んでみての感想を書いておきます。

ハッキングAPI

様々なツールを使ってWeb API脆弱性を見つける方法がいっぱい書かれています。セキュリティ関連のツールはほぼ知らないので「こんなことができるツールがあるのか、すごい!!」と思わされっぱなしです。例えば「ポートスキャンってよく聞くけど、どうやってやるのかなー?」と思ってたのですが、まさにそれを簡単に行うツールが書かれていたりして読んでて楽しです。この本で紹介されていることは実践でも使える気がします。

CISOハンドブック――業務執行のための情報セキュリティ実践ガイド

CISO(Chief Information Security Officer)ってたまに聞くけど、具体的な役割ってなんだろ?を知らないので読んでます。とにかくやることがいっぱいあり大変そうですが、それだけ大事な職務ってことですね。

AWSではじめるクラウドセキュリティ クラウドで学ぶセキュリティ設計/実装

第1部が特にAWSに限った話じゃない部分で責任共有モデルなどの話も書いてあるので読んでます。気になる人は著者さんが話してるYouTubeを見てみるのがおすすめです。

www.youtube.com

マルウエアの教科書

どんなマルウエアが存在するのかあまり知らないので知るために読んでます。400ページ以上あるので内容がぎっしり詰まってそう!

おわりに

最近では本に限らずセキュリティを学べるコンテンツがいっぱいあります。私は本と合わせてセキュリティ関係のYouTubeを見たり、Podcastを聴いたりして学びが捗ってます。これらのコンテンツを世に出してきた方々、本当にありがとうございます!この記事も少しでも誰かの参考になれば幸いです。また「これもおすすめだよ!」ってものがあれば本に限らずぜひ教えてほしいです!




(おまけ)積読してる本

おまけとして買って今後読もうと積読してる本をただただ並べてます。セキュリティに関する本って探すといっぱいありますね。買いたい本はもっといっぱいあるので、また別の機会に紹介できればと思ってます。

DeNAのサイバーセキュリティ Mobageを守った男の戦いの記録

はじめて学ぶバイナリ解析 不正なコードからコンピュータを守るサイバーセキュリティ技術

セキュアで信頼性のあるシステム構築

実践 CSIRTプレイブック

セキュリティエンジニアのための機械学習

リアルワールドバグハンティング

CISOのための情報セキュリティ戦略ーー危機から逆算して攻略せよ

ランサムウエアから会社を守る ~身代金支払いの是非から事前の防御計画まで

サイバーセキュリティ戦記

マスタリングTCP/IP 情報セキュリティ編 (第2版)

コンテナセキュリティ コンテナ化されたアプリケーションを保護する要素技術

Webブラウザセキュリティ Webアプリケーションの安全性を支える仕組みを整理する

よくわかるパーソナルデータの教科書

SlackのメッセージをNotoinに保存する自動化をZapierで組むことでフリープランのまま過去のメッセージ履歴を参照できるようにする

私は個人的なメモや考えたことを書いておく場所としてSlackを使っています。個人用途のため無料ワークスペースで使っているのですが、2022年9月からフリープランだと過去90日間のメッセージ履歴しか見れなくなる変更が行われました。

slack.com

過去に書き込んだ内容を参照したい時があるため、Slackに書き込んだ内容をNotionのDBに保存することで、Slackはフリープランのまま過去のメッセージが参照できる仕組みを作ることにしました。

Slackに書き込んだら自動でNotionのBDに保存したいので、Zapierを使って自動化のワークフローを組みました。

Zapierもお金をかけずにワークフローを組みたいと思ったので、2ステップのワークフローを組んで実現しました(3ステップ以上は有料プランになる)。

今回は、この自動化を実現したZapierのワークフローを紹介します。

事前準備(NotoinのDBを作成する)

Slackに書き込んだ内容を保存するNotoinのDBを作成します。

私は下の画像のように「内容」、「URL」、「書き込んだ時のタイムスタンプ」のカラムを持つBDを作って運用してます。

Zapierのワークフローの概要

ここからZapierのワークフローの説明をしてきます。まずはワークフロー全体はこんな感じです。

とてもシンプルなワークフローです。

Slackのパブリックチャンネルで新しい投稿がされたことをワークフローのトリガーにします。あとはSlackに投稿された内容などをNotionのDBに書き込みます。

それぞれのタスクについて説明していきます

1. Slackのパブリックチャンネルで新しい投稿がされたことをトリガーにする

このタスク(トリガー)の設定はとても簡単です!

Eventで「New Public Message Posted Anywhere」を選択し、あとはBotの投稿もトリガーにするかどうかを選択するだけです。

2. Slackに投稿された内容などをNotionのDBに書き込む

Eventで「Create Database Item」を選択し、Actionでは事前準備で作成したDBを選択し、それぞれのカラムに必要な情報を埋めていきます。

ワークフローの作成はこれで終わりです😊

ワークフローをONにしてSlackで適当に書き込みをすると、その内容がNotoinのDBにも書き込まれるはずです!

おわりに

なんとかお金をかけずにSlackの過去90日間以降のメッセージ履歴を参照する仕組みを作れました。ぜひ使ってみてください!

ちょっとした補足ですが、Zapierもワークフロー自体は無料プラン内に収まっていますが、Slackに書き込む回数が多すぎると無料プランで使えるタスク数を超えてしまう可能性があります。そうなるとNotoinへの書き込みを一部諦める or 有料プランにするしかないです。そこは多少注意が必要です。

10Xに入社して2年が経過しました & 第二子の育休に入ります

軽い近況報告です。

10Xに入社したのが2021年5月 GW空けで入社して2年が経過しました。直近1年くらいはEM(エンジニアリングマネージャー)として働いてました。

10x.co.jp

入社エントリーはこちら。

hack-it-iron.hatenablog.com

んで、2023年5月 GW空けから第二子の育児休暇に入ってます。育休期間は第一子の時と同じく半年くらい取る予定で、仕事復帰は2023年11月予定です。

10Xは福利厚生として出産・育児サポートが充実していて、出産サポート休暇はフル活用しました。産後のサポート金は出産後の一時的な世帯キャッシュフローとしてめっちゃありがたいやつです🙏🏻

10x.co.jp

現場からは以上です。

1on1におけるゆとりの設計と実践(エンジニアリングマネージャー 1年生の記録)

前提情報

  • 10Xというスタートアップで働くEngineering Manager(エンジニアリングマネージャー) です
  • 2022/04にEMになりました(それまでマネージャー経験はなし)
  • ソフトウェアエンジニア 4〜5名のマネージャーです
  • 1on1は週1 or 隔週 決まった曜日・時間帯に実施してます(実施頻度はメンバーにより異なる)

ゆとりを大事にしたい

その昔『ゆとりの法則』を読んだことでゆとりを持つ大事さを常に意識してきた。マネージャーになった時も「ゆとりを持ったマネジメントがしたい」と思った。

1on1におけるゆとりの設計

マネージャーになるとメンバーとの1on1は大事なイベントになる。1on1にゆとりを持たせるため、以下のような方針をメンバーに伝えた。

  • 1on1は基本30分で時間を取る
  • ただし 私(マネージャー)の予定は1on1後の30分は予定を空けておくように努力します
  • なぜなら 話が盛り上がったり、話したいことが話せないと困るので、私の予定上は最大30分は伸ばしてもいいよ!というスタンスのためです
  • 1on1の実施頻度、実施の曜日・時間帯は各メンバーの希望に合わせます

これに加えて私が1on1に遅れないために1on1開始前に予定を入れない努力もしました(1on1開始 10分前にブロック予定を入れ別の予定が入らないようにするのがおすすめ)。

ゆとりの効果

時間的ゆとりを持った1on1にすることで、以下のようなメリットがありました。

  • 焦らず話せる(焦って結論を出さなくて済む)
  • メンバーが話したいことを最優先にはしつつ、マネージャーから伝えたいことを話す時間も確保でき、伝えるべきことの先送りを防げる(時間なくなったからまた次の1on1にしよう…が減る)
  • 話す中で新たな話題を見つけたり思い出したりした場合でもその場の1on1で話せる(「まだ時間あるから私としては全然大丈夫だよ!」と言ってあげられる)

メンバーから見ても時間を気にして話される体験は気持ちよくないと思うので、焦らず話せるのが一番良い効果です。

実際どうだったか

メンバーによって差はありましたが、予定通り30分で終わるのと、時間オーバーして話すのが半々という感じでした。時間オーバーする場合は追加で15分(計 45分)話すことが多かったですが、時間オーバーの幅もメンバーの状況次第で変化するため、1時間とか2時間話すこともありました。

これにより話すべき時に話したいことを話し尽くすことがそれなりにできていたと思ってます。

ただ気をつけるべき点もあります。長時間にわたって話すことで互いに疲れてしまい、その後の仕事に身が入らないとか、結論が出ないままグダグダ話してしまったりとか。そのため時間内で話すべきことを話しきる努力は必要です。どうしても収まらない場合に「私はこの後も時間空いてるから大丈夫だけど、XXさんは大丈夫?」と言えるゆとりの準備が大事です。

おわりに

どういうマネジメントがしたいか?を考え「ゆとりを持ったマネジメントがしたい」と決心したことで、無理のないゆとりを持ったマネジメントが今のところできている気がします。

まだマネージャー1年生なので全てがうまくできてるわけじゃないですが、この時のゆとりを忘れずにこれからもやっていけるようにこの記事を残します。

Androidアプリ開発を学び直してる話

前提情報

  • 2012年から9年ほどAndroidアプリの開発をしていた
  • 2021年4月までJava&Kotlinを使ったAndroidアプリ開発をしていた
  • ここ最近はFlutterでアプリの開発をしている
  • つまり2年間ほどKotlinを使ったAndroidアプリ開発をしていない

2年間でAndroidアプリ開発は何が変わったか

  • Jetpack Composeが本格的に使われるようになった
  • Jetpack Navigationやmulti-moduleの採用事例が増えた

変化を追う上でDroidKaigiアプリはとても参考になる。

github.com

github.com

なぜ学び直すのか

Flutterでアプリ作れるスキルがあるなら、アプリ次第ではFlutterで作った方がiOSAndroid両方で動くものが作れるので便利です。仕事でアプリを作る場合はFlutterが第一候補です。

ではなぜKotlinを使ったAndroidアプリ開発を学び直すのか?って話ですが、多くの企業ではFlutter登場前からアプリを作って運用してきた資産が山程あります。それらをメンテナンスし続ける需要はあります。例えば副業をやりたいなーって思った時もFlutterよりKotlinを使ったアプリ開発の方がまだ多いと思います。

市場としてまだ需要がある技術なら、学び直す価値は全然あるなーと思ったわけです。転職サイトで来るオファーでも「Androidアプリ開発お願いしたいぞ!」ってやつは多く来ます。

どう学び直してるか

仕事では全くやる機会がないため、個人でAndroidアプリ作成しながら学び直してる。とにかく早くアプリを作りたいという意味ではFlutterの方が断然楽なのだが、学び直し=学習が目的なのでKotlinを使ったAndroidアプリ開発にしている。

とはいえ作りたいものがない状態では学習も進まないので、Rebuildに特化したPodcastアプリを作ることにした。

rebuild.fm

最近のデファクトスタンダードなものを使って開発している。Jetpack ComposeもMaterial 3を使って実装している。

Jetpack ComposeやNavigation 何もわからん状態からのスタートなので、Composeを使ったテンプレートプロジェクトから始めた。そこから作りたいUIを実現するために必要なものをとにかくググりながら実装するみたいな感じ。ググるとMaterial 2の情報多く、Material 3とインタフェースが違い部分が多くてコピペしてもエラー出るしわからん!!ってことが頻発して厳しかった...(今もまだある)

どんなpackageやファイル構成でどこにどれを書くのがベストプラクティスなのかもわからないので、そこは気にせずとにかく実装してまずは動くものを作ることに集中している。ある程度慣れてきたらOSSなども参考にしつつ適切にファイル分割したりしている。

いきなり難しいことをせず、ひどいコードでもいいから書きながら学ぶスタイルでやってます。

9年もAndroidアプリ開発やってきてひどいコードとかウソでしょ?と思う方向けに作っているものをパブリックに公開しました。設計や読みやすいコードを学習したいわけじゃないのでまあいいかなーって気持ちでやってます。

github.com

おわりに

学び直すって楽しいよね🌸

現場からは以上です。