開発からリリース、運用に至る中で、何もしなくてもセキュリティが完璧だというソフトウエアは存在しない。ソフトウエアは常に脆弱性が存在するリスクを抱えており、何も対応しないままだといずれサイバー攻撃を受けてしまう。場合によっては、取り返しのつかない事態を引き起こす可能性もある。

では、そもそも脆弱性とはどのようなリスクなのか。具体的にどのような対策を行えば良いのだろうか。

9月12日～15日に開催された「TECH+ EXPO for セキュリティ 2023」にEGセキュアソリューションズ 取締役 CTOで独立行政法人情報処理推進機構（IPA）非常勤研究員 技術士（情報工学部門）の徳丸浩氏が登壇。脆弱性対応の基本となる知識と、必要なスキルについて話した。

脆弱性とは何か

冒頭、徳丸氏は「Webサイトへの侵入経路には2種類しかない」と説明した。その2つとは「認証の突破」と「脆弱性の悪用」である。前者は主にパスワードを推測されたり、漏えいしたりすることでWebサイトへの侵入を許してしまうケースだ。一方、後者はソフトウエア自体の脆弱性を悪用された結果、Webサイトに侵入されてしまうケースだ。

  • Webサイトへ侵入されてしまう経路は2種類

では、「脆弱性」とは何か。

徳丸氏によると、脆弱性とは「悪用可能なバグ」、あるいは「設定不備」のことを指す。前者の例としては「バッファオーバーフロー」や「SQLインジェクション」、「クロスサイトスクリプティング」などがあり、後者の例としてはパスワードをデフォルトで放置している場合や、任意のメールを中継する「オープンリレー」などが挙げられる。

脆弱性はさらに基盤ソフトウエアの脆弱性と、アプリケーションの脆弱性の2つに分類される。

基盤ソフトウエアの脆弱性は、ApacheやPHP、JRE(Java)などが対象となる。こうした基盤ソフトウエアの脆弱性は世界中で調査され、日々新たな脆弱性が報告されている。言わば“既知の脆弱性”であり、「CVE(Common Vulnerabilities and Exposures)」という番号で識別される。例えば、Apache Log4jの脆弱性であるLog4Shellについては、CVE-2021-44228と表記する。

一方、アプリケーションの脆弱性とは、Webサイトごとに個別に作り込んだカスタムアプリケーションが対象となる。多くのユーザーを抱える基盤ソフトウエアとは違い、開発・運用する企業自身が脆弱性を探す必要がある。すなわち“未知の脆弱性”だ。未知なのでCVE番号では表記されない。

ただし、既知であるか未知であるかに関係なく、脆弱性の種類については「CWE(Common Weakness Enumeration)」で表記することが可能だ。例えば、SQLインジェクションであればCWE-89となる。

脆弱性対応のステップと具体的な方法

こうした脆弱性を突かれて攻撃を受けた場合、情報漏えいやデータ改ざん、DoS攻撃やなりすましなどの被害が発生することが考えられる。いずれもサービスや企業に大きな損害を与える可能性があり、早急に対策しなければならない。

では、どのように対策を打つべきなのだろうか。

アジャイル開発では一般的に、企画、要件定義、基本設計、詳細設計、プログラミング、テスト、リリース判定、リリースといった流れでプロジェクトが進行する。本来であれば、これら全てのフェーズで脆弱性対応が必要になるが、いきなり全てのポイントを押さえるのは難しいだろう。

  • アジャイル開発におけるセキュアなシステム開発ポイント

そこで徳丸氏は、いくつかのポイントに絞って脆弱性対応を進めることを推奨する。

まず、企画段階だ。ここでは利用するプラットフォームやコンポーネントを選定するが、その際に確認したいのが「サポートライフサイクルポリシー」である。

「仮に既知の脆弱性が見つかっても、バージョンアップやパッチがなければ対応できません。そこで、ソフトウエアによってはあらかじめサポートについてのポリシーを文書化したものが用意されています。これがサポートライフサイクルポリシーです」(徳丸氏)

有名なのがMicrosoftのサポートライフサイクルポリシーだ。同社では製品発売から最低5年間はメインストリームサポートを行い、その後も最低5年間は延長サポートを行うことを公表している。このようにサポートライフサイクルポリシーが公開されていれば、各製品で保証されているサポート期間を事前に把握できるので、脆弱性対応の見通しがつきやすいのだ。

次にプラットフォーム脆弱性の責任範囲についても確認しておきたい。

「クラウドやレンタルサーバなどを使う際、どこまでベンダーが面倒を見てくれるのかという責任境界について確認しておくことが重要です」(徳丸氏)

IaaS（Infrastructure as a Service）やオンプレミス型であれば、OS、プラグイン、カスタマイズ部分、パスワードなど全ての点において利用者が責任を持つ必要がある。一方、PaaS(Platform as a Service)やレンタルサーバであればOSについてはベンダーが責任を持って管理してくれるが、それ以外は利用者の責任範囲となる。SaaS（Software as a Service）であればOSやWordPress、プラグインなどソフトウエア部分はベンダー側の責任となり、利用者が責任を持つのはパスワード程度で済む。

このように責任範囲をはっきりさせることで、脆弱性に対する自社の負担を考えてプラットフォームを選定することが可能になるのだ。

脆弱性診断はトリアージが鍵に

次に開発からリリースまでの段階で実施すべき脆弱性対策として徳丸氏は脆弱性診断を挙げた。これはWebアプリケーションやプラットフォームの脆弱性を確認する手法であり、具体的には攻撃者の立場で擬似攻撃を行う「DAST」や、専用ツールなどを使ってソースコードを読み込む「SAST」、アプリケーションが依存するライブラリやフレームワークを分析して脆弱性を把握する「SCA」といった手法が一般的だ。

「『脆弱性診断は定期的に行うべきか?』との質問をよくいただきます。アプリケーション診断については、ソフトウエアの作成や改修の度に行うことが望ましいでしょう。一方、プラットフォームやコンポーネント診断はもっと高頻度に行うことが望ましいと言えます」(徳丸氏)

リリース後、運用に移ってからも脆弱性対策は必要だ。特に知っておくべきなのが「トリアージ」である。

これは脆弱性の影響範囲を把握した上で、対応の要否や優先度を検討することを意味する。現実的に全ての脆弱性に対応することは難しいため、脆弱性に対して対応するかどうかや、対応する場合の優先度を決めておく必要があるのだ。

「仮にApacheの脆弱性を確認したところ、mod_proxyに脆弱性が見つかったとします。しかし、このモジュールは使っていなかった。それならば影響はないので脆弱性への対応はしなくても良いと判断できます。また、脆弱性に対して攻撃経路があるかどうかも重要です。脆弱性があっても内部サーバなので実際には攻撃できない場合などは優先度を下げることもあります。ただし、内部サーバであっても攻撃を受けるケースもあるので注意が必要です」(徳丸氏)

セキュリティエンジニアの仕事とは

こうした技術やセキュリティ言語、ソフトウエアを扱うのは、他の誰でもなくセキュリティエンジニアだ。終盤に徳丸氏はセキュリティエンジニアの仕事内容について紹介した。

セキュリティエンジニアといってもその業務は多岐に渡る。前述した脆弱性診断やトリアージ、社内外のPoC担当、リーガルアドバイザー、ノーティフィケーション担当、インシデント対応、社内教育など、多くの業務が存在する。

こうしたセキュリティエンジニアを目指す人々からでよく挙がる質問が、「専門学校に行くのが良いのか、大学でコンピュータサイエンスを学ぶのが良いのか」というものだ。

この問いに対して、徳丸氏は立命館大学の上原哲太郎教授の回答を引用しながら、次のように述べる。

「今から目指すならちゃんとコンピュータサイエンスを勉強することをお勧めします。より高みを目指すなら、情報科学やコンピュータサイエンスの基礎が必要になるからです。すでにセキュリティエンジニアとして働いているならば、基本情報や情報処理安全確保支援士などの試験を受験するのも有効です。また、最終的にはプログラミング能力も重要になります」(徳丸氏)

さらに、セキュリティエンジニアは他者とも積極的にかかわりながら仕事を進めることになるため、コミュニケーション能力も重要だと言う。また、生成AIなどが登場していることから、プロンプトを書くための日本語能力もこれからは必要になるそうだ。

  • セキュリティエンジニアを目指すには専門知識以外の習得も必要となる

*　*　*

脆弱性を放置すると、事業や会社そのものにとって致命的なインシデントにつながる恐れもある。その意味でも脆弱性対応は重要だ。また脆弱性対応はサイトの企画段階から計画的に進める必要があり、総合的なITの実力が試される場でもある。徳丸氏の講演をきっかけに、セキュリティへのリテラシーや関心を高めていただきたい。