低レイヤー技術＋セキュリティ❤️ソフトウェアの研究開発という職業

はてな匿名ダイアリー

2023-09-21

■低レイヤー 技術＋セキュリティ❤️ソフトウェアの研究開発という職業

セキュリティソフトウェアの研究開発、という仕事を自分の経験をもとに紹介します。主な想定読者は、情報セキュリティ関連を仕事にしたいと考えている学生や若手、特に、いわゆる「低レイヤー技術」に惹かれている人です。

背景

低レイヤ技術を間接的に仕事で生かしてきた経験の共有。元Linuxカーネル開発技術者の場合 - 覚書を読んで思い出したのですが、セキュリティキャンプなどで、セキュリティに興味のある学生とやり取りをしていて、ソフトウェアエンジニアリングの分野でセキュリティ関連のキャリアが議論されることが少ないと感じました。自分はセキュリティソフトウェアの研究開発に１０年以上携わっていることもあり、この職業は低レイヤー技術をセキュリティに活かせる面白い選択肢だと思っているので、紹介してみることにしました。

どういう職業？

セキュリティソフトウェアの研究開発では、アンチウイルスやEDRなど、文字通りセキュリティ機能を提供するソフトウェアを研究、開発します。

「研究、開発」と書いたように、この職業には研究と開発の両面があります。

研究は、実現可能性や価値が定かでないアイディアを調査、試験実装する、という仕事がその一部です。例えば、ファイルをディスクに書き込まないマルウェアを検知したいが、どのような技術的選択肢と課題があるかを評価する。実現可能な場合は、開発チームと協働して実装、出荷にこぎつける。あるいは、製品として実装された機能がバイパスされないか調査したり、バイパスされてしまった場合にはその原因を究明したりして、製品を改善するために開発チームと協働する、という場合もあります。

開発は、研究との対比という意味においては、できると判っているアイディアを保守性の高い状態で実現する作業だといえます。保守性の重視は研究との大きな違いで、例えば、研究では、コメントもテストものない書き殴りのコードで十分であっても、開発の工程では、5年後でも改修が必要になるため許容できなかったりします。製品という大きなコードの中での開発であるため、別のチームや利害関係者との連携も、研究の場合よりずっと重要です。例えば、リードのポジションであれば、研究工程で実現可能と分かったアイディアが、既存の機能に統合する形で実装されるべきか否かアーキテクトと議論したり、テスト計画を品質保証のチームと練ったり、プロジェクトのスケジュールを調整したりします。

研究は、既定の手法がなく、闇の中を手探りで進める面があり、最終的に製品レベルにこぎつけずに終わる場合も多いです。判りやすい成果が出ない場合があるので、好き嫌いが別れやすいです。自分は、職業としては研究３，開発７くらいのバランスが好きで、趣味では逆に研究８，開発２くらいになってます。趣味では成果が出ようが出まいが過程が楽しければ満足、という個人的な考え方がこの違いとして出ているようです。

低レイヤー 技術の価値

この職業のおいて、低レイヤー技術に明るいことは、ほかの多くのエンジニアができないことができるという付加価値、だと自分は考えています。例えば、特定分野の詳細を知っていることでその分野の研究、開発が効率よくできたり、新しいアイディアが生まれたりします。具体例をいくつか挙げると、OSの仮想メモリー管理に親しみがあれば、プロセスのメモリーを走査してメモリー上のみに存在するマルウェアを検出する機能をより効果的に設計、実装できる。プロセッサーの機能の詳細を知っていれば、CETという新しいプロセッサーにしかないセキュリティ機能を、他のプロセッサー機能を使って疑似的に実現するというアイディアを思いつく。などです。脆弱性の知識や探す技術も、とても価値があります。脆弱性を知らない人と、知っている人では、どちらが脆弱性の少ない設計や実装をできるでしょう。自社の製品の脆弱性を、開発中に発見するのと、テスト・出荷後に発見、改修を加えるのではどちらのコストが少なくて済むでしょう。コンパイラーの知識は検出ロジックを書くための独自言語の開発に、エミュレーターの実装経験はマルウェア解析エンジンの開発に役立ちます。

ただ、低レイヤー技術は付加価値であることに注意してほしいです。

まず前提として、ほかの平均的なエンジニアができることに加えて低レイヤー技術があるべきです。セキュリティソフトウェア開発者の多くは、実はセキュリティや低レイヤーのエキスパートではありません。優秀な開発者であることに加えてこれらを必要条件にしてしまうと、人が雇えなくなってしまうためです。そのため、一般的なエンジニアリングの能力に加えて低レイヤー技術やセキュリティという強みがあると、大多数の開発者ができない（したがらない）ことを任せられる人、と差別化してもらえる可能性が高いです。一方、エンジニアリングに対する素養や意欲なしでは、セキュリティソフトウェアの研究開発職は難しいです。その場合、研究者のほうがあっています。（ちなみに自分は、脆弱性解析とマルウェア解析を専門とする研究職にも各２年ほど就いていました。）

やりたい仕事を得るためにできること

ここからは一般論になりますが、OSに詳しくても、プロセッサーに詳しくても、バグハントが得意でも、それを会社が求める結果を出すために使えなくては意味がありません。会社は、あなたがやりたい仕事をくれません。会社は、会社が必要としている仕事をもってくるだけです。

ではどうやって「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を最大化するか。

まずは、上司にどういう仕事をしたいかを明示的に、繰り返し話しておきます。さらに、能動的に、自分からプロジェクトのアイディアを提案して意欲を示すことも心がけます。あなたの仕事を最終的に選ぶのは上司である以上、上司からの理解は必須です。良い上司（そして良い上司であることを可能する、良い上司の上司）は、必ず、あなたの能力に対する信頼度に応じて、あなたの意向を考慮してくれます。言い換えると、まずはやりたい仕事を主張する前に、与えられた仕事をこなして信頼を得る必要があります。個人的な経験では、これは１年あれば十分で、１年たっても状況に変化がない場合、あなたの仕事ぶりが上司の信頼を得るのに不十分か、あなたがやりたい仕事をうまく伝えられていないか、上司やその上司あるいは会社に問題があるか、あるいはこれらの組み合わせの可能性が高いです。

上記がうまくいかない場合、チームや会社を変えることを検討しましょう。チーム異動はリスクの少ない選択肢です。これも、実現するか否かは、上司からの信頼の程度に大きく依存します。会社を変えるのはリスクが大きいですが、上司やその上司を変えるよりも現実的です。新しい会社でもうまくいかなかったら、また新しい会社を探せばOKです。最終的にあった会社に行きつくか、自分の能力やコミュニケーションに問題があることに気づくと思います。

最後に、「会社が必要とする仕事」と「あなたがやりたい仕事」の重複を追求しないことも視野にいれておきましょう。仕事はあくまでお金のためであって、やりたい仕事のほうが楽しいが必要要件ではない。……という視点を持っておくと、些細なミスマッチで不満をためて、そこそこ良い環境から性急に転職してしまう、という状況を防ぎやすいです。隣の芝生は青い、ということを忘れないように。