2024年、プロダクトセキュリティのトレンドはどうなるのか。様々な業界で活躍する開発エンジニア・セキュリティエンジニアの方々13人に見解を伺いました。
今回は、「2023年のプロダクトセキュリティを振り返る」というテーマでお届けします!
▼前編(2023年のプロダクトセキュリティに関する取り組みの振り返り) flatt.tech
今回コメントをいただいた方々
- CADDi CTO 小橋昭文さん
- サイボウズ Cy-PSIRT
- Finatextホールディングス 取締役CTO/CISO 田島悟史さん
- Google 小勝純さん
- グラファー 森田浩平さん
- IssueHunt 取締役 CTO Junyoung Choiさん
- カンム 金澤康道さん
- メルカリ IDP team kokukumaさん
- メルカリ Product Security team, Manager Yannarak Wannasaiさん
- Security-JAWS 吉江瞬さん
- Ubie 水谷正慶さん
- Flatt Security 執行役員・プロフェッショナルサービス事業CTO 志賀遼太
- Flatt Security 取締役CTO 米内貴志
※所属組織名アルファベット順、順不同
※本記事記載のコメントは個人としての見解であり、各所属企業・組織の総意としての見解ではありません。
質問項目
今回は、以下の項目についてコメントをいただいています。
- プロダクトセキュリティ分野で、2024年に取り組みたいこと・注力したいこと
- プロダクト開発・運用組織が2024年に意識すべきセキュリティトレンド
- 今回コメントをいただいた方々
- 質問項目
- CADDi 小橋昭文さん
- サイボウズ Cy-PSIRT
- Finatextホールディングス 田島悟史さん
- Google 小勝純さん
- グラファー 森田浩平さん
- IssueHunt Junyoung Choiさん
- カンム 金澤康道さん
- メルカリ kokukumaさん
- メルカリ Yannarak Wannasaiさん
- Security-JAWS 吉江瞬さん
- Ubie 水谷正慶さん
- Flatt Security 志賀遼太
- Flatt Security 米内貴志
- まとめ(Flatt Security 米内貴志)
CADDi 小橋昭文さん
- コーポレートサイト:https://caddi.com/
- 技術ブログ:https://caddi.tech/
2024年に取り組みたいこと・注力したいこと
嬉しい悲鳴ですがプロダクトが成長して規模が拡大するにつれて、ステークホルダーも増えソフトウェアも複雑化してます。数人集まれば全てが把握できて意思決定できたものが、徐々に領域やモジュール別の有識者を巻き込む場面が増えてきてます。 2024年には、セキュリティにまつわる意思決定の階層化及び権限移譲を、より進めていこうと思います。設計レビューやエスカレーション方法なども更新して、より適切な解像度の有識者が適宜連携して推進できる構造を作ろうと思っています。
もちろん、関係者が増えて意思決定が階層化すると、当然ながら仕組み化や自動化は必須になりますし、コミュニケーションの練度も上げていく必要があります。決して簡単ではないですが、これから一年はプロダクトを次のステージに持っていくためにも、拡大する事業を支えるプロダクト組織として複雑さに向き合い、さらに成長したく思っております。
2024年に意識すべきセキュリティトレンド
事業密着型の「実態」と「実現性」を重視したセキュリティとの向き合い方が求められると思います。直近ではCVSS 4.0が出て、よりベースライン点数だけではなく環境要素を加味した、状況に応じて変動する点数の付け方が進められています。この背景には世間統一の発信ではなく、各社のアーキテクチャや使い方、リスク要素などを加味して決定をすることが求められています。
また、少し前に更新されたCISAのSecurity by Design and Defaultに関する文書では、説明の詳細化と実例の追記がされています。各原則へ対処するにも、CVSS同様に状況を正しく捉えて判断していくことが重要とも解釈しています。
医療では生活習慣や遺伝により病のリスクが異なり、適度な予防施策を打つ場面は少なくないと思いますが、セキュリティも同じく各社特有の事情を理解した上で、適切な意思決定をすることが重要であることが最近強く発信されている気がします。
自社SaaSを開発・運用する組織といえば、継続的な価値提供がプロダクトの命でもあり、それを一番理解しているのは自社の社員であるはずです。だからこそ組織全体でセキュリティ解像度を上げていくことが、意識すべき重要なトレンドかと思います。
サイボウズ Cy-PSIRT
- ブログ:https://blog.cybozu.io/
- X(旧Twitter):@CybozuSecurity
- コーポレートサイト:https://cybozu.co.jp/
2024年に取り組みたいこと・注力したいこと
2023年で挙げた取り組みを継続することはもちろん、Bug Bountyも注力したいポイントです。2024年は、Bug Bountyの開始から10周年を迎えます。これまで多くの方々に報告いただき、製品の堅牢化に寄与いただきました。おかげさまで近年はシンプルな脆弱性は減少傾向にあり、より複雑な脆弱性が報告されるようになるなど変化が見られています。海外の参加者も増加傾向にある中で、今後のBug Bounty自体の方針も含めて改めて検討し、10周年のイベント等も検討していく予定です。
また、これまで製品セキュリティという枠組みの中で取り組んできたことを継続し強化しつつも、より視野広く開発プロセスや仕様に踏み込んでの活動などにも尽力していきたいと考えています。
2024年に意識すべきセキュリティトレンド
- サプライチェーン攻撃の増加
- AIにおけるセキュリティ
- CVSSv4
前回の記事でもお伝えした通り、サプライチェーン攻撃は近年増加傾向にあると考えております。そのため、今後も引き続き注意が必要な内容だと思います。
また、AIの利活用が進む中で、AI上での情報の取り扱いや攻撃など、AIに関する様々なセキュリティリスクが今後も発生していくことが予想されるので、それらに対しても注視が必要だと考えています。
更に、2023年7月にMITREからアナウンスされたCVSSv4にも注目しています。現時点ではCVSSv2やv3を用いた評価が行われていますが、今後v4への移行が進むことが予想されるため、公開された脆弱性の脅威を正確に理解する足掛かりとして、CVSSv4がどのような仕組みで評価されるのかを把握しておく必要があると思います。
Finatextホールディングス 田島悟史さん
- 個人ブログ:https://blog.s-tajima.work/
- X(旧Twitter):@s_tajima
- コーポレートサイト:https://hd.finatext.com/
- 技術ブログ:https://techblog.finatext.com/
2024年に取り組みたいこと・注力したいこと
2024年に取り組みたいこととしては、クラウドサービスのガードレールの拡充です。当社は、長らくAWSを中心にシステムを構築してきており、AWSについては内製のガードレールの仕組みを整備してきました。
一方で、昨今のOpen AI / Azure OpenAI Service の登場等をきっかけに、他社クラウドを利用する機会も徐々に増えています。そういった他社クラウドにおいても、安全で効率的にシステムを構築できるように、ガードレールを整備していく必要がありますが、今回はそれを完全に内製するのではなく、CSPM製品の導入によって実現することを考えています。宣伝というわけではないのですが、例えばGCPについては、Flatt SecurityのShisho Cloudの活用を視野に入れて調整を進めています。
2024年に意識すべきセキュリティトレンド
2023年11月に、CVSS v4.0が正式公開されました。一つ前のv3.0は2015年6月に公開されました。その後、v3.1へのマイナーアップデートもありましたが、メジャーバージョンとしては、v4.0が8年ぶりの更新となります。
ソフトウェア産業において、脆弱性情報の評価と対応方針を確定することは、一筋縄ではいかない難しい作業ですが、このCVSSのアップデートもきっかけに、各社運用の見直しの動きが出るのではないかと思います。弊社も今年、関連するテーマとして 「KEVを活用した依存ソフトウェアの脆弱性管理の省力化」というブログ記事を公開しました。 KEV (Known Exploited Vulnerabilities) Catalog を利用して、脆弱性管理を効率的にやっていますというお話なので、興味あるかたはぜひ読んでいただけると幸いです。
Google 小勝純さん
- X(旧Twitter):@shhnjk
- コーポレートサイト:https://about.google/intl/ALL_jp/
2024年に取り組みたいこと・注力したいこと
GoogleではWeb開発のフレームワークにStrict CSP、Trusted Types、RIPなど様々なセキュリティ機構をデフォルトで組み込む事で沢山のWebアプリケーションを安全に保っています。しかしBardなどのLLMを使ったアプリケーションが出てきたことで、Indirect Prompt Injectionなどの新しい攻撃手法が既に報告されています。
2024年はLLMを使ったアプリケーションのリスクを洗い出し、Webアプリ側で横断的に使える緩和策の提案と実装に注力して取り組みたいと思っています。
2024年に意識すべきセキュリティトレンド
色んなSaaSプロダクトがLLMを使った機能の実装や計画をしているかと思います。
その際には、LLMに対する様々な攻撃を理解してどの攻撃が自社のサービスにとって致命的かを知っておくと良いと思います。
例えば、社外に漏れてはいけない情報がLLMのトレーニングやシステムプロンプト内で使っているかを知っておけば、トレーニングデータを抜く新しい手法などが公開された時に対応の優先度が分かるでしょうし、システムプロンプトを漏洩させる攻撃などはそもそもシステムプロンプトに関するユーザの入力を弾いたり、システムプロンプトの一部が出力される前に検知して出力を中断したりなどの対策が出来るかもしれません。
LLMアプリケーションのOWASP Top 10なども出ているので、目を通しておくと良いかもしれません。
グラファー 森田浩平さん
- 個人ブログ:https://blog.ssrf.in/
- X(旧Twitter):@mrtc0
- コーポレートサイト:https://graffer.jp/
2024年に取り組みたいこと・注力したいこと
当社では SRE とセキュリティエンジニアが連携して、「セキュアで信頼性のあるプロダクト開発及び開発生産性の向上」をテーマとして掲げています。そのためのアクションの一つに、Policy as Code などを用いた自動かつ継続的な監査の強化があります。この取り組みにより、システムが非準拠の状態になるのを未然に防ぐだけでなく、非機能要求の背景や理由を文書化することで、SRE & セキュリティエンジニア以外でも運用体制を理解し維持できるようにすることを目指しています。
さらに、イネーブルメントチームとしての役割を果たし、プロダクト全体の領域における課題の発見と解決やプラクティスの適用に取り組んでいます。具体的には、「データライフサイクルの継続的なドキュメンテーション」や「プロダクトにおける権限マトリックスの自動生成」などに挑戦しています。
2024年に意識すべきセキュリティトレンド
ワードでいうと SBOM / VEX などは昨年に引き続きトレンドとなるでしょうし、Technology RadarではAttack Path Analysisなども登場しているので、注視しようと思っています。
一方で、やはり無視できないのは AIだと思います。プロダクトの開発・運用をしているかに関係なく、業務を支援するために AI を利用すること、またプロダクトの機能として AIソリューションを活用・提供することは、もはや当たり前になっています。今後も業務の中で AIを利用する場面は増えるでしょうから、投入するデータの扱いに注意するなど、組織として安全に AIを利用するための仕組みを整備し続けることが必要です。データの機密レベルを明確にする活動などは、より重要性を増すでしょう。また、AIを用いたプロダクトの提供者としては、利用者に対して透明性のある運用や堅牢なシステムの提供が、より強く求められると思います。AIの利用を制限するのではなく、積極的に活用していけるように、継続的にキャッチアップしていく必要があるトピックであるため、意識すべきトレンドだと思います。
IssueHunt Junyoung Choiさん
- コーポレートサイト:https://issuehunt.jp/
- X(旧Twitter):@IssueHunt_jp
2024年に取り組みたいこと・注力したいこと
セキュリティ水準を本質的に評価する仕組みを作りたいと考えています。
現状はモグラ叩きのように脆弱性を検知し、改修することに焦点が当てられており、アプリケーションにおけるセキュリティ水準の評価は脆弱性の検知数・改修数に依存しています。
そのため、事後対策ではなく、未然に防ぐ仕組み作りに注力したいと考えています。
出てきたモグラを叩くだけではなく、モグラが出てこられないように穴を塞ぐことが重要です。
欧米では普及しつつある「シフトレフト」という考え方についても脆弱性を未然に防ぐアプローチから生まれたものです。
しかし、シフトレフトの成熟度に関する評価基準(線)が国内においては存在しておらず、現在は「どの程度脆弱性スキャナを導入しているのか」「どのようにコードレビューしているのか」といった、点で語られていると感じています。そのため、2024年はこの仕組み作りに取り組みたいと考えています。
2024年に意識すべきセキュリティトレンド
業種業態問わず、最低限の対応として以下の脆弱性診断ツールを導入する必要があると考えています。
- SAST(ソースコードに対するスキャン)
- DAST(運用中のアプリケーションに対するスキャン)
- SBOM(アプリケーションを構成しているコンポーネントに対するスキャン)
- CSPM(クラウド設定に対するスキャン)
日本では「シフトレフト」という概念がまだ浸透していない状況です。そのため、開発段階からセキュリティを意識する習慣が一般的でない企業が多く存在しています。
現状の組織において、セキュリティチームが不在である場合でも、ソフトウェア開発者がセキュリティツールによって検知した脆弱性の対応をすることで、セキュリティの知見を持った開発者を内製化することに繋がります。この一歩から開発チームのセキュリティに対する理解が深まり、よりセキュアなアプリケーションの開発が可能になると考えています。
脆弱性診断ツールは種類が多く、中々導入ハードルが高いと考えられている企業の方は、弊社にて設計から運用まで一気通貫でサポートすることも可能です。
カンム 金澤康道さん
- ブログ:https://liva.hatenablog.com/
- X(旧Twitter):@s_liva
- コーポレートサイト:https://kanmu.co.jp/
2024年に取り組みたいこと・注力したいこと
SaaSプロダクトの開発・運用に関するところでは、2つ注力したいと考えています。
1つはPCI DSSの対応を組織的に進めていくための体制作りです。PCI DSS v4へのメジャーバージョンアップがあり開発体制も大きくなっていく中で、特定の人に偏った体制では維持が難しくなっていることを課題に感じているためです。
もう1つは、攻撃が起きた際の被害の最小化です。不審な動きを早期に検知できる仕組みづくりや、既存の実装における被害が拡大しそうな部分の修正、そういったものを作り込まないようセキュリティレビューや診断などを行えるようにしたいと考えています。
2024年に意識すべきセキュリティトレンド
2024年もサプライチェーンの侵害による問題は引き続き意識していきたいです。2023年1月に発生したCircleCIのインシデントや、パッケージマネージャーを通じて悪意あるソフトウェアが配布されたりなど、サプライチェーンへの攻撃が目立ちました。2024年度も引き続きサプライチェーンの侵害は続きそうです。
意識すべきかは分からないですが、個人的にはパスキーにも注目しています。 SMS認証コストの削減や、UXの改善、より安全な認証機能の提供といった面に期待しています。
メルカリ kokukumaさん
- 個人Twitter:@kokukuma
- コーポレートサイト:https://about.mercari.com/
2024年に取り組みたいこと・注力したいこと
サービスで要求すべき認証強度と身元確認強度の明確化、またその利用方法の整理に取り組みたいと考えています。7pay不正アクセス事件や、ドコモ口座 不正引き出し事件、フィッシング被害等、これまでのセキュリティインシデントを踏まえ、サービスを利用する際には十分な認証強度と身元確認強度を要求し、重要な機能の利用時にはSMS OTPによる再認証を行うなど、phishingへの対策を行っています。
一方で、同じアカウントとクライアントにおいて、異なるセキュリティレベルを要求するサービスが提供されている場合、最も高いセキュリティレベルに引っ張られ、いくつかのサービスで過剰な要求が生じていることがあります。
パスキーの導入に際して、セキュリティとユーザビリティのバランスを取る方向に意識がシフトしてきている背景から、各サービスで必要な認証強度と身元確認強度を明確にし、共通の制限方法を導入することで、必要なセキュリティを確保しつつ、ユーザビリティを損なわない状態を目指したいと考えています。
2024年に意識すべきセキュリティトレンド
Generative AIの進化により、フィッシング攻撃の手法もより洗練され、巧妙になっています。この技術を悪用する攻撃者は、AIを使ってリアルな偽メールやウェブサイトを作成し、ユーザを騙して個人情報を盗み出すことが可能になってきています。実際にどのような攻撃方法が出てくるのか、注視していきたいと思います。
対策の方面からは、ユーザの警戒心と知識によってフィッシング攻撃に対抗することは、もはや現実的な対処方法ではありません。ユーザが特に気にしなくてもクレデンシャルが奪われない仕組みが必要です。パスキーの利用拡大がもっとも現実的な対策だと考えられますが、一方でパスキーはそれ自体が新しいものなので、さまざまな課題があり、それに対してFIDO Allianceやw3cにおける議論も活発に行われています。そのため、各Platformで提供されるパスキーの実装やFIDO Allianceが示す方向性について注視していく必要があると思います。
メルカリ Yannarak Wannasaiさん
2024年に取り組みたいこと・注力したいこと
Trustworthy, Safe, and Secure Large Language Models (LLMs)
With the growing use of generative AI tools like GitHub Copilot and ChatGPT in software development, Large Language Models (LLMs) have become crucial components of many applications. Therefore, security engineers must comprehensively understand the security dimensions of LLMs. This understanding is vital for protecting these models from compromises and preventing them from becoming conduits for cyberattacks. Given that LLMs handle and produce substantial amounts of potentially sensitive data, it's imperative to ensure their compliance with data privacy regulations and prevent inadvertent leakage of confidential information. Additionally, the susceptibility of LLMs to adversarial attacks that could manipulate their outputs necessitates strategies to fortify these models against such threats. As AI technology faces increased regulatory oversight, particularly in sectors like finance and healthcare, ensuring LLMs' compliance with laws and standards is essential. The trustworthiness and security of LLMs are key to building public trust and facilitating their ethical and widespread adoption.
In summary, a security engineer’s role extends beyond technical mastery to encompass ensuring the ethical, legal, and safe use of AI, thereby maintaining public trust and addressing a range of AI-specific security challenges.
信頼でき、安全でセキュアな大規模言語モデル (LLM)
ソフトウェア開発においてGitHub CopilotやChatGPTなどの生成AIツールの使用が増える中、大規模言語モデル(LLM)は多くのアプリケーションに不可欠な要素となっています。したがって、セキュリティエンジニアにはLLMのセキュリティ面を総合的に理解することが重要です。これは、これらのモデルを妥協から守り、サイバー攻撃の経路にならないようにするために不可欠です。LLMは、機密情報を含む可能性のある大量のデータを処理および生成するため、データプライバシー法規に準拠し、機密情報の誤った漏洩を防ぐために、この分野の知識が不可欠です。さらに、出力を操作する敵対的攻撃に対して脆弱である可能性があるため、これらの脅威に対してモデルをより強固にするための戦略を開発することが重要です。AI技術は、特に金融や医療などのセクターにおいて、ますます規制の対象となっているため、関連する法律や業界基準にLLMが準拠していることを保証することが不可欠です。LLMの信頼性とセキュリティを確保することは、公衆のAI技術への信頼を築き、その倫理的かつ広範な採用を促進するために重要です。
要するに、セキュリティエンジニアの役割は、技術的な習熟度を超えて、AIの倫理的、法的、安全な利用を保証し、公衆の信頼を維持し、AI特有のセキュリティの課題に対処することにも及びます。
2024年に意識すべきセキュリティトレンド
Software Supply Chain Security and Software Provenance
As cyber threats become more advanced, the diversity of sources in software supply chains, like open-source software (OSS) and third-party software, introduces significant risks. Organizations must secure their software supply chain to protect against vulnerabilities. Increasingly stringent regulatory requirements are emphasizing the need for transparency and security in software development, including the mandate for companies to provide a Software Bill of Materials (SBOM) that details all software components used. Organizations need to systematically identify, assess, and mitigate risks throughout the supply chain, including during development, build, and deployment.
Software Provenance, which involves tracing the origin and history of software components, is vital for regulatory compliance and reducing risks of tampered or malicious code. Comprehensive software security and provenance management require organizations to maintain and update various documents like SBOMs and test reports throughout a product's lifecycle. This commitment not only meets regulatory demands but also builds client trust in software security. Overall, prioritizing supply chain security and software provenance is crucial for organizations to protect against emerging threats and comply with evolving regulations.
ソフトウェアサプライチェーンセキュリティとソフトウェアプロビナンス
サイバー脅威が進化し、高度化するにつれて、オープンソースソフトウェア(OSS)や第三者のソフトウェアなど、ソフトウェアサプライチェーンの多様な出所が組織に大きなリスクをもたらしています。組織はソフトウェアサプライチェーンを保護し、攻撃者が利用可能な脆弱性から守るためにセキュリティを確保する必要があります。ますます厳格になる規制要件は、ソフトウェア開発における透明性とセキュリティの必要性を強調しており、企業に対して使用しているソフトウェアの全コンポーネントを詳細に記載したSBOM(Software Bill of Materials)の提供を義務付けています。組織は、開発、構築、展開フェーズを含むサプライチェーン全体でリスクを特定、評価、軽減するために、体系的なアプローチを採用する必要があります。セキュリティインシデントの際には、包括的なSBOMが脆弱性の迅速な特定と解決を促進します。
ソフトウェアの出所、作成、修正を追跡する「ソフトウェアの来歴」は、規制コンプライアンスと改ざんまたは悪意のあるコードのリスクを減少させるため、特に重要です。これは、潜在的に敵対的な国々からの製品を扱う際に特に重要です。包括的なソフトウェアセキュリティとソフトウェアの来歴管理のためには、組織は製品やサービスのライフサイクル全体にわたって、SBOM、ポリシー、テストレポート、証明書などの様々な文書を維持し、更新する準備をしなければなりません。サプライチェーンのセキュリティと透明性への責任は、規制要求を満たすだけでなく、ソフトウェアのセキュリティに関心を持つ顧客との信頼を築くことにも繋がります。要するに、ソフトウェア開発の風景が変化するにつれて、新たな脅威から保護し、厳格化する規制に適応するために、サプライチェーンのセキュリティとソフトウェアの来歴を優先することが組織にとって不可欠です。
Security-JAWS 吉江瞬さん
- X(旧Twitter):@security_jaws
- Webサイト:https://s-jaws.doorkeeper.jp/
2024年に取り組みたいこと・注力したいこと
クラウドを利用する上で考えるべきセキュリティは上げるとキリがありませんが、「Shift Left, Shield Right」をより説いて、セキュリティ対策に取り組めるような体制を築きたいと考えています。つまり、サービスの設計や要件定義からSecurity by Designを考える「Shift Left」、クラウドのプラットフォームはもちろんクラウド上のワークロードを保護することを考える「Shield Right」についてより注力したいと考えています。私個人はクラウドベンダーやクラウドセキュリティベンダーのCNAPP(Cloud Native Application Protection Platform)サービスに興味があり、2024年も引き続き調査していきます。CNAPPは開発から運用まで、クラウドネイティブアプリケーションのライフサイクル全体をカバーする統合セキュリティアプローチとなります。
2024年に意識すべきセキュリティトレンド
SSPM(SaaS Security Posture Management)が日本の中にどれくらい根付くかは見ていきたいと考えています。海外ベンダーでは、Adaptive Shieldといった製品もありますが、国内でよく利用されるSaaSのセキュリティまで管理されるものではないので、このあたりに対応したものが登場してくるかどうかは確認したいです。あわせて、先の問いにも回答したとおり、CNAPPについては意識していただきたいところです。
Ubie 水谷正慶さん
- ブログ:https://mztn.hatenablog.com/
- X(旧Twitter):@m_mizutani
- コーポレートサイト:https://ubie.life/
2024年に取り組みたいこと・注力したいこと
今年はPolicy as CodeおよびDetection Engineeringの全社的な実装に取り組むことを計画しています。これまで、社内サービスやリソースが適切な状態にあるかを定義し、それを定期的にチェックする仕組み、また社内の問題を自動的に検出し対応する仕組みを導入してきましたが、これらのシステムを導入した当初は、開発中のSaaSプロダクトや事業そのものが探求の段階にありました。そのため、システムアーキテクチャや検出すべき対象、サービスの理想的な状態などが頻繁に変化し、監視や検出の運用が安定せず、限定的なものになっていました。
最近、ブログにも記載しましたが、事業やプロダクト、組織運用の方針がはっきりしてきたため、Policy as CodeやDetection Engineeringの仕組みを改めて全社に実装し、導入することを目指しています。
2024年に意識すべきセキュリティトレンド
1つ目は、サードパーティのサービスが侵害された場合の影響に引き続き注意を払うべきです。開発だけではなく、社内全般で利用されているサードパーティのサービスによって多大な影響が生じる可能性があります。影響を最小限に抑えるためには、どのデータを預けるべきかを慎重に考慮する必要があります。また、サードパーティのサービスが他のサービスと連携する際の仕組みに注目することも重要です。連携時に静的なトークンに強い権限を与えると、そのサービスが侵害された場合には影響範囲が広がります。しかし、OIDCによる認証や不必要に強い権限を持たないトークンの使用などの配慮があると、影響範囲を最小化できます。このような点をサービスを選定する際に意識することが必要だと考えています。
2つ目は、生成AIへの注目です。負の面では、攻撃者がマルウェアの亜種を生成したり、難読化したり、フィッシング攻撃を巧妙化したりするために生成AIを利用する可能性があります。基本的な脅威の性質は変わりませんが、攻撃がより低コストで実行できるようになることで、攻撃の熟練度が全体的に向上することが懸念されます。一方で、セキュリティ業務に生成AIを活用することで、分析や作業の負担を軽減したり、コストがかかっていたシステムを安価に実装できる可能性があります。これらの側面からも、生成AIに注目し続けることが重要だと考えています。
Flatt Security 志賀遼太
- X(旧Twitter):@Ga_ryo_
2024年に取り組みたいこと・注力したいこと
例によってプロダクト開発・運用をする組織をサポートする組織の目線での回答とさせていただきます。 2024年のFlatt Securityのプロフェッショナルサービス事業において重要と考えているのは、大きく分けて以下の2点です。
1. 脆弱性診断サービスにおけるプロフェッショナル性の追求
2. 価値提供範囲の拡大
1点目は脆弱性診断サービスにおけるプロフェッショナル性の追求についてです。
プロフェッショナルファームにおいては、サービスの提供価値は組織に属する人に密接に関わってきます。特に2023年に打ち出したリスクフォーカス型プランやソースコード診断は、「プロフェッショナルとは何か」といったところにフォーカスしたものとなっていますので、その傾向は更に顕著になっていると言えます。
そのような中では、プロフェッショナルとして学習し続け、提供価値をより良くし続けられるかといったサイクルをいかに上手く回せるか重要性も同様に高まっているため、今年は特にここにも注力したいです。
また、日々サービス改善案を模索しておりますので、既存の脆弱性診断の枠組みに囚われず、これからもサービス改善をしっかり実現していかねばならないと感じています。
2点目は価値提供範囲の拡大についてです。
プロフェッショナルサービス事業では、お客様にも恵まれ、非常に多くのご依頼をいただけるようになりました。
これまでは脆弱性診断という比較的「何故やるのか」「何をやるのか」などが分かりやすい事業を主軸に行っていましたが、セキュリティというのは、往々にして「何故/何を/何から」といった最初のステップで困ってしまうことが多くあります。
こういった点について、脆弱性を発見・報告する部隊としてではなく、プロダクトセキュリティ全体のプロフェッショナルとしてご信頼をいただき、お客様の開発組織に伴走する組織となれるよう、サービス自体の拡充などを行っていきたいと考えています。
特に、Accountability(説明責任)を意識したセキュリティ戦略の策定と、それに伴ってコードベースでの診断スキルを利用した早め早めの実装の検証など、プロフェッショナルとして提供すべきことは山ほどあるなという認識です。
2024年に意識すべきセキュリティトレンド
2023年のところにも記載させていただきましたが、基本的にはやはり生成AIの利活用については今後サービスも更に展開される可能性が高く、キャッチアップしておくべきと感じます。個人的には、管理/監視/検査ルール自体の生成ツールとして生成AIが盛り上がるみたいなものが、自分の仕事を奪ってくれる領域としても気になっている状況ではあります。
それこそ弊社小島が先日出したブログに出てきているものでも、セキュリティチェックシートの自動化SaaSのようなものは既に出てきています。
また、それこそ先ほどの回答にもあるような、「何故/何を/何から」といった部分の回答をある程度の精度で出してくれるとなれば、プロダクトセキュリティの一歩目が非常に楽になるのではないかと言った想像をしています。
逆に我々としては、そういった生成AIにおけるExplainability(説明可能性)やモデル自体の安全性(敵対的攻撃への対策など)の部分を特に意識しつつ、そこで提供できない価値にフォーカスできればと思っています。
Flatt Security 米内貴志
- ブログ:https://diary.shift-js.info/
- X(旧Twitter):@lmt_swallow
2024年に取り組みたいこと・注力したいこと
弊社志賀が「Accountability(説明責任)」について言及していますが、弊社の二事業のシナジーを最大化することで、この点に関して大きな寄与を生むことが 2024 の注力点です。
要は「なぜ、どう、何に取り組んでいて、これから何をするべきか」がクリアな状態で歩めるプロダクト組織を増やすことが、私や我々の向かっていく方向になります。
Accountable な施策を実施するためには、愚直に自組織を取り巻く脅威を把握し、資産を把握し、脅威に対して抱えるリスクを把握し、やることに優先順位をつけ、歩み続ける必要があります。
一方、この愚直なプロセスを一度回すだけでも、多くの組織が息切れしているのが現状です。ここには主に 2 つの背景が見え隠れしています:
- 各ソリューションの説明可能性が低いこと(何に対して何ができる製品であるか、不明瞭である)
- 各組織内のブレインの不足(製品を使いこなす以前に、資産や脅威の整理など、大本・上流の取り組みをする能力・体力が不足している)
Flatt Security は、この二点を共に解決してプロダクトセキュリティのブレインになるべく、プロダクト事業とプロフェッショナルサービス事業を有しています。
これまで 2 事業それぞれで培ってきた知見や信頼を土台として、より多くのプロダクト組織を "strategize" していく面白い戦略が描けてきたので、この道を突っ走ってみます。
2024 はいい年になりそうです!
2024年に意識すべきセキュリティトレンド
数あるセキュリティロールの中でも、いわゆるセキュリティアーキテクトの重要性が、相対的に増していく一年になるのではと予想しています。
弊社小島の記事 でも言及がある通り、Unbundled 気味だったセキュリティツールの Rebundle は加速しています。
また生成 AI 領域の発展が、細かな末端レベルでの情報処理のあり方を変えており、細かな問題のトリアージ・修正の自動化も進んできました。
このようなトレンドは、ようは「意思決定のためのリスク情報収集や、末端の問題解決は加速しているのだ」と解釈できます。
今のフロンティアは「意思決定」です。具体的には、「人・データ・ビジネスを理解し、セキュリティの理想形を模索し、意思決定する」というロールの補助/代替ができる技術は未だ発展途上となっています。
そう考えると、意思決定能力・リーダーシップの重要度が、今相対的に増していると考えるのが自然でしょう。
とくに "文系的" な情報セキュリティ領域(社会規律に立脚して、情報のあり方を考える領域)と、"理系的"な情報セキュリティ領域(データや技術に立脚して、情報の流れを実装する領域)を横断して思考できる能力は、より重用されていくのではと思います。
まとめ(Flatt Security 米内貴志)
前編に引き続き、後編でも様々な立場・領域で活躍する方からのコメントを賜りました。日本の技術コミュニティのために、皆様の貴重な知見を還元いただいたことに、この場を借りてお礼申し上げます。
頂戴したコメントを改めて読んでみると、2024 年は、やはり引き続き AI 技術への注目が高い一年となりそうですね。自社プロダクトへの組み込みに際する論点もあれば、モデルを悪事に用いられるリスク/Safety への論点、その手の便利なツールを自組織として活用する際の情報流の増加に係る論点など、様々な論点を生み出していることが見て取れます。
一方、生成 AI 以外の論点においては、それぞれ異なる関心領域が持たれていることが伺えます。これは異なる組織が異なるセキュリティの maturity を持つこと、異なる事業ドメインには異なる脅威が存在することを考えると自然ですが、昨年頂戴した回答(前編/後編 )との差分を見るとコミュニティの前進の様子が感じられて面白いものです。
本企画は2022年-2023年の年末年始が初回で、2023年-2024年の年末年始で実施した今回が 2 回目となります。この企画を通して日本のコミュニティへのよい還元ができそうだ、と改めて感じた 2 回目でございましたので、来年もご期待いただければと思います。二度あることは三度ある、なんて言いますしね。
これを読んでくださっている皆様のトレンド予想もお伺いしたいです。X(旧 Twitter)やはてなブックマーク等でのコメント、お待ちしております!
(編集/寺山ひかり)
▼前編(2023年のプロダクトセキュリティに関する取り組みの振り返り) flatt.tech