「銃、病原菌、鉄」を参考にしたセキュリティ技術の学び方　ほぼ感想記事

IT

他分野の本とセキュリティをかけあわせていくシリーズ。

何気なく「銃、病原菌、鉄」を読んでいて、面白いなと思ったところがあったので、そこだけピックアップして記事を書くことにした。

結論

「最初は模倣から始まる」というが、それは信じて良い。

しかしそこから結果につなげるには、必死で頑張りまくるだけではなく、なにかに気づく「ゆとり」と、現実にアクセスし続ける「継続的な実践」が必要。

発明は突発的なものではない

面白いところは「発明は必要の母である」という章だ。

基本的にこの本は難しくて「へ～」ぐらいの感覚にしかならなかったし、全部読みきれなかったが、ここは結構参考になるなと思った。

内容としては、進化の途中で作られたいくつもの発明は、実は少しずつ発明されていったというものだ。

ライト兄弟が作ったとされる飛行機も、ロジック自体は前からあったらしい。

それが実現されていなかったけれど、そういうのを組み合わせて、結果ライト兄弟が形にできたとのこと。

様々なものがベースとなる発明があってこそだという内容だった。

誰か一人の天才が「急に車ができたぞ！！すげー便利！！」みたいになったわけではないとのことだ。

車自体も、車輪ができたときはいろんな地域に広まっていったが、使われなかった地域もあったとのこと。

全体として「便利だなー！」とはなかなかスムーズにいかないようで、このへんが面白いなと思った。

セキュリティに何が関連するか？

ここまでだったら、別に記事にしなくても個人の感想として持っておけばよかった。

しかしあるときにブルーピリオドを読んでいて、「最初は模倣から始まる」というセリフを見かけて、「これはつながるんじゃないか・・・！？」と思って記事にしたくなった。

ブルーピリオドは美術だが、セキュリティ分野でも「最初は模倣から始まる」は当てはまると思う。

用意された脆弱な環境を使い、脆弱性を再現する。

ブルーチームだったら、ベストプラクティスに従ってログやエンドポイントを整備したり、資料を整えたり、既知の攻撃を調べてそれに備えたりするだろう。

この「最初は模倣から始まる」は、人類自体が進歩していくにあたって使ってきた、根本的なフローだったのだ。

つまり、「学び方」というのはかなり限られてくるのがわかる。

「前例をベースとし、それは現状だとどう展開できるか？」くらいしかないと思う。

対策のバイパスを見つけるのだって、基本形を知っていなければできない。

新しいタイプの脆弱性を見つけるのだって、言語の仕様や言語がどう作られてどう動いているかの理解が必要だ。

「銃、病原菌、鉄」とセキュリティを組み合わせることで、新しい発見があるわけではないが、既存の勉強ロジックがより強固になったことがわかった。

安心して過去ベースの勉強を進めて良い

とりあえず「最初は模倣から始まる」は信頼していいことがわかった。

だが、ここから「発明」といえるレベルにするには、現実と照らし合わせていく必要があると読めた。

本の中では、「ガソリンができたときは、ガソリンは他のものの副産物で出来、使用用途はなかった。その後車の燃料に適していることがわかり、使われるようになった。」とあった。

いろいろと過去ベースで学び試していくうちに、過去ベースにそう形で良いものが出来た。

しかし、その試しが「発明」となるには、運とタイミング、それと現実と照らし合わせてのひらめきが必要だと読めた。

私が思ったこととしては、「自分なりの発明にしていくには、過去ベースで勉強しながらもゆとりは保ち、現実のいろんなものに興味を持ち試す必要がある。」だ。

「なにかいいもの作りたい！すごい脆弱性見つけたい！」と思った際に、過去のすごい成果物や脆弱性から学ぶのは正しいフローだ。

しかしそこから結果につなげるには、必死で頑張りまくるだけではなく、なにかに気づく「ゆとり」と、現実にアクセスし続ける「継続的な実践」が必要なのだ。

終わりに

「銃、病原菌、鉄」の盛大な感想記事になった。

この本は結構根本的なことが多く書かれていて、結構楽しめた。

全然染み付く気配なかったけど・・・。

また落ち着いたとき、なんか気になったときに読み直そうと思う。

現段階でも結構なことを得られた。

著者、結構本出してるから読んでみるのもありかもなー。

脆弱性診断士にとっての確証バイアスの危険性

IT

行動経済学や心理学の本を読んでいて、いくつものバイアスが出てきた。

また、いつ見たかは忘れたけど、バグバウンティで発生するバイアスについて書かれた英語の記事もあった。

なので、ブログベースで私も書いてみようと思う。

内容としては、現場で見てきた確証バイアスの事例だ。

この分野に関して密接に研究したわけではないため、漏れ、不足、認識のミスなどあったらご容赦願いたい。

確証バイアスとはの概念も引用だが置いておく。

仮説や信念を検証する際にそれを支持する情報ばかりを集め、反証する情報を無視または集めようとしない傾向のこと

https://ja.wikipedia.org/wiki/%E7%A2%BA%E8%A8%BC%E3%83%90%E3%82%A4%E3%82%A2%E3%82%B9

過去の判断基準への異常な信頼

「なんか不思議な挙動する・・・」

「そういえば、似たような挙動で以前指摘してたな、これにしよう」

こういった、ちょっとルールに当てはまらないような挙動をした際、過去に似たような指摘をしているとそれにすぐ当てはめてしまう場合がある。

私もこう考えてしまうことはあるので、なんとも難しいものだ。

このケースの問題としては、「今回の挙動」にフォーカスしきれていないことだ。

「過去の指摘した挙動」と似ていることしかわからないため、「今回の挙動」がどういったものかを深掘りできていない。

この思考、おそらくだが過去に似た指摘がなければ深掘りしていたり、他の人に相談したりしていたはずなのだ。

（それをしないなら普通に見逃しだからな）

なので、「過去の指摘と同じだろう！」という確証バイアスの事例の１つだった。

エラーベースファジング結果への異常な信頼

「ん！？シングルクォート1つと2つで挙動が違う・・・！？SQLインジェクションだ！」

これは初学者による経験不足か、確証バイアスか悩むところではあった。

おそらくだが、二つ合わせた「経験不足＋限られた経験による確証バイアス」なのだろう。

脆弱性診断をしていると、大体の脆弱性は同じパターンで発生する。

普通にXSSが発生したりもするし、教科書通りのパターンでSQLインジェクションやパストラバーサルが発生したりもする。

その中でもSQLインジェクションは判断ミスが起きやすい。

バックエンドがどう処理をしているかわからないが、パーセントエンコードが2つ続くとエラーになるシステムを見たことがある。

他にも、奇数偶数でエラーが変わったり、WAFなのかリバースプロキシなのか環境の問題なのか適度にエラーが発生したりすることもある。

経験が浅いと「あー！！」といった感じで実は違う要因なのにSQLインジェクションを指摘しそうなことがある。

しかし、これはまだ良い。

この問題が発生しやすいのは、ある程度経験を積んだ人なのだ。

実のところ、「バックエンドの動きを予想し、エラーの内容を予測する」ということができる人は多くない。

そういった人は堅実に経験を積み重ねていくのだが、ある程度のラインに来ると「慣れ」になってしまう。

「慣れ」になったときにこのような謎エラーが起こるシステムに当たってしまうと、「はいはいSQLインジェクションね」といった感じで進めてしまう。

その後、軽くSQLインジェクションであることを確認して指摘してしまう。

これはピンポイントとなったが、結構あるあるだろう。

確証バイアスの説明でもある、「3つ並んだ数字の規則性を当てる」みたいなやつと同じやつな気がしる。

ここでの問題は、「軽くSQLインジェクションであることを確認して指摘」することだ。

念押ししたいなら、同時に「SQLインジェクションではないこと」も確認しなければならない。

適度にエラーになってしまうなら、シングルクォート１つだけを数１０リクエスト送ってみれば良い。

例で出したような「パーセントエンコードが2つ続くとエラーになるシステム」であれば、他のパーセンドエンコードの文字列を試してみれば良い。

この例が一番、確証バイアスの「反証する情報を無視または集めようとしない傾向」に適したものとなっただろう。

変化する判断基準への順応の遅れ

「この指摘項目は・・・こういう設定になってたらダメだったな」

「あれ！？最近の基準だと変わって・・・た？」

脆弱性診断は指摘する基準が1〜2年単位で変わることが多い。

大体が微々たるもので、重大なリスクになるものではないが、我々はペンテスターではないので、リスクが小さいからといって適当にして良いわけではない。

最近で結構困ったのがCookieのSamesite属性だ。

chromeがデフォルトでlaxにしたり、firefoxがデフォルトでlaxにしたりしなかったり、IEは全く関係なかったり、そんなこと言ってたらIEがサポート終了したりした。

脆弱性診断に関わる人全てがさまざまな基準について精通しているわけではないし、いつだって情報を追って理解しているわけではない。

そういった中で、このsamesite属性は結構厄介だった。

そもそも、「Cookieに新しい属性が増えますよ」ってことで基準を修正した後、浸透させるのも大変だ。

「Cookieの属性とはこういうもの」みたいなのが長く続いた人ほどアップデートするのが大変そうだった。

この例は個人が悪いわけではなく、いい意味でも悪い意味でも使える「慣れ」が悪い方向に出たかなと言った感じだった。

「RANGE」でも出てきたが、狭い分野に特化するとこういった変化に弱くなってしまうのだろう・・・。

対策

想定する結果と相反するエビデンスを揃えさせる

これはルール的なものだが、「発生した」エビデンスと「発生しなかった」エビデンスを残すようにさせる。

すると、エビデンス取得の過程で相反する事例を確認できるし、なんらかの要因があって作業者が気づかなかった場合も第三者の目がどこかで入ることによって確証バイアスの発生を少なくできる。

第三者の目を増やす

これはリソース的に難しいかもしれないが、見る目を増やせば確証バイアスが起こる確率も減らせる。

稼働率みたいなもんだ。

しかし、組織全体が同じ確証バイアスを共有していたり、そもそも疲弊していたりすると使えなかったりもする。

大事なのは余裕ということか。

機械的に判断する項目を増やす

そもそも人間の目が入らないようにするのも効果的だと思われる。

判断のリソースを曖昧な挙動に割り振ってしまおうというものだ。

SQLインジェクションであれば、パターンをかなり用意し、スキャナも並行して使用することでだいぶ検知の信頼性が上がる。

時間はかかってしまうが、確証バイアスの影響は減らせるだろう。

終わりに

初めて分野を組み合わせた記事を書いてみた。

楽しかったので、これからもやってもいいかもしれない。

書いていった事例は仕事で見つけて「ああ・・・」となったものばかりだ。

この事例は発生する確率が高いわけじゃない（高かったら構造的な問題だ）が、発生してしまったらお客様に申し訳ない。

可能な限りそういったことを減らしたいという気持ちもあったのでこれを書いてみた。

人がやる限り、確証バイアスをはじめとしたバイアスから逃れることはできないんだろうけども・・・。

CakePHP CVE-2023-22727(SQLインジェクション) 動かす

IT

※脆弱性診断を行う上でのスキルアップとして検証を行っております。この記事で知り得たことを悪用することは禁止とします。

概要

アドバイザリから引用した。

https://github.com/advisories/GHSA-6g8q-qfpv-57wp

サニタイズされていないユーザー要求データが渡された場合、メソッドCake\Database\Query::limit()とメソッドは SQL インジェクションに対して脆弱です。Cake\Database\Query::offset()

Impact https://github.com/advisories/GHSA-6g8q-qfpv-57wp

この問題は、4.2.12、4.3.11、4.4.10 で修正されています。

patch https://github.com/advisories/GHSA-6g8q-qfpv-57wp

環境作成メモ

ガンガンchatGPTに聞いた。

環境

  • M1 Mac
  • Docker

ミス1 platform: linux/arm64 が入ってなくて動かないコンテナがあった。

⇨M1 Macの場合はarm指定を入れる。

ミス2 volumesを仮想？にしていて、検証するうちにゴミが溜まってエラーになった。

⇨dockerマスターになるまではローカルのディレクトリを指定する。

出てきた課題1 古いバージョンのCakePHPはどうやってインストールする？

⇨composer.jsonでバージョンいじってcomposer updateする。

動作確認

4.4.9

脆弱性が存在する4.4.9であることを確認した。

chatGPTに頼んでデータやら容易してもらった。

INSERT INTO posts (title, body, created, modified) VALUES
('First Post', 'This is the first post.', NOW(), NOW()),
('Second Post', 'This is the second post.', NOW(), NOW()),
('Third Post', 'This is the third post.', NOW(), NOW());
public function limited()
{
    if ($this->request->is('post')) {
        $limit = $this->request->getData('limit');
        $posts = $this->Posts->find()
            ->limit($limit)
            ->order(['created' => 'DESC']);
    } else {
        $posts = [];
    }

    $this->set(compact('posts'));
}

修正時のテストとして使われている「--」（コメント）で試してみる。

https://github.com/cakephp/cakephp/commit/3f463e7084b5a15e67205ced3a622577cca7a239#diff-000573bb2b704f30344f3f525c5360bcbe979ca256c513f453458010e55da897

正常系

コメントあり(エラー起こらない想定)

コメント構文エラー

SQLインジェクションが成立していることが確認できた。

4.4.10(修正後)

修正後のコード。文字列チェックが入っている。

https://github.com/cakephp/cakephp/commit/3f463e7084b5a15e67205ced3a622577cca7a239#diff-000573bb2b704f30344f3f525c5360bcbe979ca256c513f453458010e55da897

4.4.10に上げた。

先ほどと同じコメントを投げてみた。

修正コード通りのメッセージが表示されていた。

まとめ

仕様上では文字列以外を想定している関数もあるので、「'"」をエスケープするというだけではSQLインジェクションは防げない。

このCVEが2023というのが、これが浸透していない証拠だと感じる。

(djangoでも似たようなのあったよね)

気になったセキュリティニュースたち 〜1/20

IT

新年になってエンジョイしたり体力失ったりと色々あったけどなんとか再開する。

(書籍レビュー)大企業のWebサイトの脆弱性発見事例が学べる「リアルワールドバグハンティング」

https://toranoana-lab.hatenablog.com/entry/2023/01/10/125809

ニュースではないけど、気になったので。

この本結構事例が紹介されてておもろい！

HackeroneのHacktivity眺めてるいる感じ。解説あるのでとっつきやすい。


KADOKAWAグループでスクール運営を行うバンタンのサーバに不正アクセス、CMSの脆弱性を悪用し侵入

https://scan.netsecurity.ne.jp/article/2023/01/19/48789.html

CMS経由・・・

少し前にCMSバグハントしてたけど再開するかな・・・

Microsoft Windows における任意のディレクトリの作成が可能な場合に特権を昇格する手法（Scan Tech Report）

https://scan.netsecurity.ne.jp/article/2023/01/18/48785.html

へー！脆弱性チェーンみたいだ！

The easiest way I used to bypass an admin panel

https://medium.com/@siratsami71/the-easiest-way-i-used-to-bypass-an-admin-panel-93d4297ed4a6

UAを削除するだけでアクセス制御がバイパスできるのはなんか逆に新しいな。

「HTTP Request Smuggling」かなと期待してたけど違うのはなんか残念・・・しかし予想を超えた成果！

気になったセキュリティニュースたち 2022月12月19日〜12月23日

IT

色々あって記事にできてなかった・・・

NIST Retires SHA-1 Cryptographic Algorithm

https://www.nist.gov/news-events/news/2022/12/nist-retires-sha-1-cryptographic-algorithm

SHA-1も終わった・・・！！！

政府機関と警察庁が年末年始のセキュリティに関する注意喚起、要点をポスター化 - INTERNET Watch

https://internet.watch.impress.co.jp/docs/news/1465305.html

https://www.npa.go.jp/cybersecurity/pdf/20221220press_2.pdf

大事なやつやなー。

耐性とか、「誰にも連絡つかん！！！」とかになるもんな・・・

Safeurl HTTP library brings SSRF protection to Go applications | The Daily Swig

https://portswigger.net/daily-swig/safeurl-http-library-brings-ssrf-protection-to-go-applications

なんか便利なのできてるなーって思った。

結局、こういうのを使うの忘れたってなりがちなんだろうけども。

組み込み RE の概要: UBoot を介した UART の検出とファームウェアの抽出

https://voidstarsec.com/blog/uart-uboot-and-usb

細かいハードウェア解析記事やなーおもろい

本学への不正アクセスによる個人情報の流出の可能性に関するお知らせとお詫び

https://yamagata-u.ac.jp/jp/information/info/202212161/…

当該サーバ内の他のサイトの保存領域にもアクセス可能であり

ペンテストしててこういう環境だったら「あっ」ってなるやつ

Release Radar · November 2022 Edition

https://github.blog/2022-12-16-release-radar-nov-2022/

これいろんなライブラリの存在知るのにいいな！！

Webアプリケーションフレームワーク「SvelteKit 1.0」正式リリース。SSR/SSG/SPAなど対応 － Publickey

https://www.publickey1.jp/blog/22/websveltekit_10ssrssgspa.html

JavaScriptのサーバサイドかー 脆弱性あるかな？

Tauri+Next.jsでモバイルアプリ開発｜laiso

https://zenn.dev/laiso/articles/825ee7e652ad1b…

セキュリティ関係ないけど、初めて知った技術的なやつ。

クロスプラットフォームのモバイルアプリは結構あるから、知っとくと便利だな〜って感じだった。

デコンパイルの時の出方とか知らんとビビってしまうからね・・・

優秀であり続けることのワナ セキュリティエンジニアは気にしてもいいかも？

IT

優秀であることは、デメリットも多分に含む。

「私が新米セキュリティエンジニアとか、セキュリティ仕事したい人に伝えられることはなんだろう？」と考えたところ、仕事とそれ以外で学んだことの組み合わせかなと思った。

なぜこのテーマを選んだかというと、セキュリティエンジニアのバーンアウトが特集されていたからだ。

https://japan.isc2.org/blog2022/how-to-prevent-burnout-among-cybersecurity-professionals-before-during-and-after-a-breach.html

個人力アップがメインテーマになるセキュリティ業界でも、こういったバーンアウト記事は出てくるものだ。

というか、バグバウンティのWriteupを追っていても週に１本くらいはバーンアウト対策の記事が出てくる。

それほど、セキュリティ業界とバーンアウトは密接なのだ。

今の時代の若い人たちはTwitterを見ている限りイキイキとしているように見える。

私もイキイキとしていたが、やはりバーンアウトは襲ってきて、今ではなんとか対処しながら仕事している。

少しでもメンタルを病んでしまう人が少なくなればなと思う。

そして、参考はやっぱり「YOUR TIME」。

「やるかやらないか」で精神を病む

「人生はやるかやらないかだ」でメンタルが病む

YOUR TIME ユア・タイム: 4063の科学データで導き出した、あなたの人生を変える最後の時間術 鈴木 祐 書籍版 第4章 203ページ

私自身、耳が痛い言葉だ・・・。

2,3年前の書いた記事を読んでみると、「まずはやってみよう！考えるよりも！」みたいなことをよく書いていた気がする。

成果という面では一部は正しかったのかもしれないが、メンタル管理という点ではダメらしい・・・。

原因はシンプルで、「プレッシャーがかかるから」だそうだ。

優秀な人、優秀であろうとする人ほど、「やるかやらないかだ」が当たり前の世界でスピード感を求められるのはプレッシャーを感じるのではないだろうか？

少なくとも、私はプレッシャーを感じた。

空き時間を許せないほど、徹底的に効率よく行動しようと思っていた。

その行動は、この業界に入ってからの期間に対し多大な成果をもたらした。

しかし、その行動は長期間続けられる物ではなかった。

「やるかやらないか」を「やらない」にするときが来ているのかもしれない。

生産性を上げれば上げるほど忙しくなる

生産性を上げれば上げるほど忙しくなる

YOUR TIME ユア・タイム: 4063の科学データで導き出した、あなたの人生を変える最後の時間術 鈴木 祐 書籍版 第4章 206ページ

これは言うまでも無いかもしれない。

職場の優秀な人、ずっと忙しそうじゃ無いだろうか？

本の中でも、「仕事は優秀な人にお願いしたいよね」と言う当たり前のロジックが働いて、結果優秀な人は忙しくなると言うのがあった。

仕事を学んで、余計なところは効率化して、「さぁ時間ができた！！」とはなぜかならない・・・

そんな経験がないだろうか？

私はある。

どこの会社でだって、どこの現場だって、みんなと協力して成果を上げたりなんとかして効率化したりした。

その度に「やったー！！楽になった！！」とみんなで喜んだもんだ。

その結果、「のんびり暮らせました、めでたしめでたし」になったことなんてない。

桃太郎が鬼を倒したら、別の地域の鬼退治をひたすら頼まれるようになってようなもんだ。

能力を上げたり、効率化したりすることで「できる」ようになることはあっても、「時間が生まれる」ことは無い。

生産性を諦め、評価が下がるのを許容する勇気！

技術以外から目を背けないこと

バーンアウト記事からストレス軽減策をいくつか引用してみる。

  1. 自分の行動、誰と話し、何を話したか、すべてを記録しましょう。
  2. 侵害/インシデント対応プロトコルに従い、変更すべき点があればメモしましょう。
  3. あなたは一人ではないことを理解しましょう。
  4. 家に帰ったら、孤立しないで、家族と話し、自分の気持ちや受けた影響を伝えましょう。
  5. 積極的に活動し、休息を取り、食事をしましょう。
侵害の前、最中、後における、サイバーセキュリティ専門家の燃え尽き症候群を防ぐ方法
https://japan.isc2.org/blog2022/how-to-prevent-burnout-among-cybersecurity-professionals-before-during-and-after-a-breach.html

もはや、「常に高いパフォーマンスを維持すること」なんて書かれていないし、「世界有数のハッキング技術を有するべく努力すること」なんてのも書かれていない。

何項かに別れて「とにかく休んでリラックスすること」と記載されている。

これは本当に大事で、特に「あなたは一人ではない」はやばいぐらい大事。

家族、友達、同僚などなど気軽に話しかけたり相談することが大事。

「孤立」という意味で、一人でいることはそうそうないはずだ。

終わりに

「優秀であり続けることのワナ」だった。

とりあえず日記とか本の感想の延長で書いていたが、書きたいことが多かったのでメイン記事にした。

セキュリティ関連の記事は毎日結構な方が読んでくれているので、セキュリティ関連でちゃんと書いておくかという気持ちにもなった。

これからゆっくり技術記事も書いていくが、根底としては「頑張らない」をモットーとしてやっていく。

自分への戒めとして、この記事を書いたのかもしれない。

2022年までのキャリアを振り返ってみる

IT

私のキャリアとかインタビューでまぁまぁ聞かれるのでメモした。

一応結論としては、何か技術力が大切なわけではないと思ったというところ。

小学生時代

天才ハッカーのエピソードであるような「父親のパソコンをつかってプログラムをしていたんだ！」ってなはない。

普通に漫画を読んだりゲームをしたりそとでどろけーしたりしていた。

このころにポケモンやロックマンエグゼを履修した。面白かったなぁ…

中学生時代

剣道部に入ったため、部活に悩殺された。

ブラック部活だったので、ガンガンに練習を詰め込まれて将来とか勉強とかじゃなかった。

みんなお利口さんで偏差値を高めるのに勤しんでいた学校だった。

だから、規則を破ったり勉強に慣れなかったり集団で行動するのが苦手な人に対してかなりバッシングする文化があった…

日本の極みみたいな中学校だった。

私も例外なく勉強して偏差値を高めていた。

でも60くらいになれば満足してそれ以上は興味出なかった。

歴史や国語はまったく興味が出ず、感覚に任せていた。

趣味はもっぱらモンハンをしていた。

普通に2ndGにハマりまくっていた。

将来の夢としてゲームプログラマーを目指していたので、情報系の高校に行くことになった。

このころはそれほどゲームが好きだったのだ。

プログラマーにしたのは、周りがゲームクリエイターを目指す人が多く、同じの目指すのつまらんと思ったと言うだけだった。

高校生時代

情報系の学科に入った。

基盤に抵抗とかトランジスタとかハンダ付けしたり、C言語やったりした。

情報のベースとして二進数計算とかめちゃやった。

この時は意識が高かったので、在学中にITパスポートと基本情報技術者をとった。

ゲーム作成を仕事にしたかったのだが、授業で作りたいゲームを作って満足してしまったのでやめた。

特にこれといってやりたい感じのことがあるわけではなかった。

家の事情的に進学は難しいし、奨学金もらってまで何か知りたいことはないので就職することにした。

プログラミングは面白かったので、プログラミングできる会社に就職することにした。

新卒〜4年くらい(1社目)

プログラミングする会社に入社したけど、あまり関係ない仕事についた。

最初は技術なんて言ってられなく、ビジネスメールや上司との話し方、電話対応など基本的な対応習得に迫られた。

1年くらいでビジネス周りは落ち着いた。

その感、なんだかんだプログラムは好きだったのでJavaの資格は取った。

というか、仕事がプログラミングじゃなかったので流石にプログラミングしたかった。

資格を取ったり、現場で成果を出した(つもりでいた)が、プログラミングは出来なかったので転職した。

プログラミングはできなかったが、Windowsの細かい設定や情報セキュリティ周りには触れていた。

当時はそんな興味なかった。

一般企業のパッチ管理、社員教育、監視、インシデント一次対応は大変だった。

この辺の経験があってか、こういう防御面はあまりやりたくないと今は思っている。

やりたいとしたら、もう少し歳を取ってからかな。

社員とか経営層に舐められるんだよね、若いと。

とまぁ、結構普通に新卒を過ごしてきたのだが、あえて役に立ったことをあげるとすれば「適応力」か。

とにもかくにも新しいことをやったり、現場特有のルールがあったりしたので、馴染むことが何より大事だった。

脆弱性診断をやっている今でも、「適応力」は便利に使えている。

ただ、自分に芯がないと周りに合わせて残業したしまったり、まわりのネガティヴな空気に巻き込まれたりする。

私は絶賛芯が無かったので、良くも悪くも適応していろいろ酷い目にあったりした…

社会人4年目〜6年目(2社目)

プログラミングを仕事にした。

しかし、上司が厳しくてプログラミングを断念した。

変数名とか無駄なロジックとかで、お客さんの前で数時間単位の説教してくるのよね、、、

辛すぎて顔が歪むので、後半はマスクが手放せなかった。

「これで根を上げてたら上達できないよ？」と言われていた。

当時はそれが嫌だったのでなんとしてでもやっていたが、今思えばそんな辛い思いしてまで習得したくはない。

後、一般的な開発フローが意外とつまらなかった。

自分の作りたいものを作りたいだけで、誰かが作りたいものを作ってあげたいわけじゃないんだなぁと思った。

キャリアが途切れたので、必死にやりたいことを考えた。

この時の気持ちは揺れに揺れていた。

マルウェア解析に興味を持っていたりもしたので、プログラミング経験を積むのもアリだと思っていた。

しかし、プログラミングをするにはあまりにもつまらない…

学生時代を参考にしてゲームを作ろうともした。

面接を2社受けたけど、どっちにも「向いてなさそうだからやめときな！まだまだチャンスはあるって！落ち着いて！」と丁寧なアドバイスをもらった。

専門学校にいっめ学び直そうかと思ったけどそこまでの熱意は出なかったので諦めた。

だいぶ悩んだ末に「マルウェア解析」が残り、こっちの業界に行こうとした。

ただ、「マルウェア解析」は必要なキャリアが足りなかった。

なんかマルウェアとか攻撃分析ならそれもいいなぁと思って求人漁ったり情報を調べたりする日々が続いた。

有志の勉強会に参加したり、SECCONのカンファレンスに行ったりといった感じだ。

なんだかんだといろいろご縁があって、脆弱性診断の仕事につけるようになった。

ここでの学びといえば、挫折したことととりあえず行動したことだろうか？

今を見直すのは大切だったし、わからないことだらけでもとりあえず動き回るのも大切だった。

社会人6年目〜(いま)

いま！粛々と脆弱性診断やらペネトレーションテストやらをやっている。

1年ごとに新たな分野にチャレンジさせてもらっていて、2022年はペネトレーションテストをやっていた。

来年は何をしようかな。

終わりに

これまでのキャリアまとめだった。

誰かに向いて書いたと言うよりかは、また誰かに聞かれた時ように話す私用のメモ。