OWASP Top 10 Proactive Controls 2018 の概要と 2016 との比較

OWASP Top 10 Proactive Controls（OPC）とは、ソフトウェア開発者向けに作成された設計や実装時のセキュリティのベストプラクティスをまとめたものです。

本記事では、本記事作成時点での最新版の OWASP Top 10 Proactive Controls 2018 についての概要と 2016 との比較について解説していきます。

OWASP Top 10 Proactive Controls 2018 の概要

OWASP Top 10 Proactive Controls は、OWASP Top 10 などで有名な OWASP（Open Web Application Security Project）という Web アプリケーションセキュリティの情報共有、啓発を目的としたコミュニティが提供するドキュメントのひとつです。

OWASP Top 10 では、重要な Web アプリケーションのリスクに関して上位 10 項目の発見のポイント、防止方法、攻撃シナリオを解説し、組織でのセキュリティリスクを特定することに焦点を当てています。

OWASP Top 10 Proactive Controls は、重要な Web アプリケーションのリスクに対処するためのベストプラクティスを提供し、開発者のためのセキュアなソフトウェア開発の助けとなるように書かれています。

そのため、リスクという視点で列挙されている OWASP Top 10 とは異なり、セキュリティを高めるために考慮するべきポイント（セキュリティ要件の定義、セキュリティフレームワークとライブラリの利用など）が重要度順に列挙されています。

OWASP Top 10 Proactive Controls 2018 の各項目に関しての概要を解説します。

C1 : セキュリティ要件の定義

ライフサイクルの初期からセキュリティを考慮することでよりセキュアなソフトウェア開発を行うことができます。

そのためにも、まずセキュリティ要件を決めることが必要ですが、決めるためには業界標準、適用される法律、過去のセキュリティ問題の再発防止策などを含めることが理想的です。

OWASP ASVS という OWASP が策定した 286 項目の要求事項から成る Web アプリケーションに関する網羅的なセキュリティ要件のリストを参考にして要件を決めることができます。

ASVS に関しては以下の記事で詳しく解説しているので合わせてご覧ください。

• セキュアな Web アプリケーションを作るには？ Vol.01　OWASP ASVS 4.0.1 編
• セキュアな Web アプリケーションを作るには？Vol.02　ASVS 活用編

C2 : セキュリティフレームワークやライブラリの利用

アプリケーションをスクラッチで開発せずに適切なライブラリやフレームワークを利用することで、効率よくセキュアなアプリケーション開発を行うことができます。

ライブラリやフレームワークを利用する場合には以下の 4 つを考慮することが重要です。

1 メンテナンスがされ、広く利用実績のあるライブラリやフレームワークを選ぶ

2 利用しているライブラリ一覧を作成し、メンテナンスする

3 OWASP Dependency Check や Retire.JS のようなツールを利用して既知の脆弱性がないか確認し、最新の状態を維持する

4 ライブラリのカプセル化し、必要な動作のみを公開することでアタックサーフェスを減らす

余談になりますが yamory では、利用しているライブラリ一覧の表示、ライブラリに含まれている既知の脆弱性の検出を行うことができますので、2, 3 の部分をサポートすることができます。

C3 : セキュアなデータベースアクセス

セキュアなデータベースアクセスを実現するためには以下の 4 つの項目を考慮する必要があります。

1. セキュアなクエリ

信頼できないユーザーからの入力が SQL クエリに挿入されると SQL インジェクションを引き起こします。
OWASP Top 10 の 1 番目に Injection があるように最も危険なセキュリティリスクのひとつです。
SQL インジェクションを軽減するためには、 bobby-tables.com や OWASP Cheat Sheet on Query Parameterization を参考にパラメータ化クエリを利用することが最善の方法です。

2. セキュアな設定

初期設定が必ずセキュアな状態ではないため、CIS Benchmarks のような標準、ガイドを参考に設定する必要があります。
上記に加えて、データベースへのアクセスへの適切な認証（3. セキュアな認証）と、通信経路を暗号化されたもののみにする（4. セキュアな通信）を実施することが重要です。

C4 : データのエンコーディングとエスケープ

信頼できないユーザーからの入力をそのまま利用することで発生する問題は SQL インジェクションだけではありません。

クロスサイトスクリプティング（XSS）や OS コマンドインジェクションといった脆弱性も発生する恐れがあります。
エンコーディングとエスケープを実施することで防ぐことができます。

参考情報として、XSS Filter Evasion Cheat Sheet という XSS をテストするためのドキュメントが提供されています。
こちらを確認することで XSS がどのような入力によって引き起こされるのか学ぶことができます。

Cross Site Scripting Prevention Cheat Sheet では防止策についてまとめられています。

C5 : すべての入力値を検証する

すべての入力値を検証することで適切にフォーマット化された値だけがアプリケーションに入力されるようになります。
それによってアタックサーフェスが減少し、攻撃を困難にすることができます。

入力値検証をクライアントサイド、サーバサイドで行うことがありますが、クライアントサイドでの検証はバイパスされる恐れがありますので常にサーバサイドでの検証も行う必要があります。

また、検証に正規表現を利用する場合には ReDoS と呼ばれる DoS を引き起こす可能性がありますので注意が必要です。

注意点として、入力検証を XSS や SQL インジェクションのメインの防止策とはしないでください。

C6 : デジタルアイデンティティの実装

デジタルアイデンティティの管理は考慮すべき点が幅広く、OWASP Proactive Controls ではごく一部のみしか紹介できません。
より詳細に確認したい場合は NIST SP800-63-3B が参考となります。

NIST SP800-63-3B の内容の一部の紹介として、AAL（Authentication Assurance Level）という 3 つのレベルで分けられレベルごとに要件が定義されたものがあります。
たとえば、AAL レベル 1（個人を特定できる情報（PII）を含まないような リスクの低いアプリケーション）ではのパスワード要件（長いパスワードやパスフレーズの推奨など）やセキュアなパスワードストレージの実装などが示されています。

デジタルアイデンティティの管理は非常に難しい課題ですので外部のドキュメントをよく参考にすること、経験が豊富なエンジニアが担当することが推奨されています。

C7 : アクセス制御の実施

アクセス制御が正しく実装されていない場合には意図しない情報が公開されてしまう、変更されてしまうなど大きなリスクに繋がります。

アクセス制御を実装する場合にも「C1 : セキュリティ要件の定義」と同様に早い段階から検討して設計することが重要です。
アクセス制御の実装を検討する時には、以下の 5 つの要件を考慮する必要があります。

1 アクセス制御を早い段階で徹底的に設計する

2 すべてのリクエストがアクセス制御を通るようにする

3 アクセス制御のデフォルトは「拒否」

4 最小権限の原則

5 アクセス制御ルールをにハードコーディングしない

C8 : すべてのデータの保護

攻撃者はさまざまな方法を使ってデータを盗み取ろうとします。

たとえば、通信経路が暗号化されていなければ傍受される可能性がありますし、保存されたデータが暗号化されていなければ SQL インジェクションを使って平文のまま盗まれる恐れもあります。
すべてのデータの保護するために以下のポイントを確認することが重要です。

データの分類
データの重要度決め、保護するためのルールを決める

通信経路のデータの暗号化
TLS といった暗号プロトコルを適切な設定で利用する

保存時のデータの暗号化
不要な機微情報の保存は避け、信頼された暗号ライブラリを利用する

鍵のライフサイクル
用途ごとに鍵を分ける、キーローテーションを可能にするなど鍵管理を行う

アプリケーションシークレットの管理
アプリケーションで利用する鍵などは設定ファイルで管理せず AWS KMS 等を利用して実行時アクセスにする

C9 : セキュリティロギングとモニタリングの実装

デバック目的のログと同様にセキュリティ目的のためのログを取ることで、IDS への入力情報、フォレンジック分析、法規制への準拠などのメリットがあります。

セキュリティロギングを実装するときは以下のポイントに注意が必要です。

・何をログに取るのか検討し、機微情報が含まれないようにする

・侵入検知のために、変更が想定されないはずのデータが変更されて送信されているなど、想定外のユーザーの行動を特定できるようにする

・セキュアなロギング設計をするために、ログに書き込む前に検証する、ログファイルの権限を検討するなど完全性を維持する対策を取る

C10 : すべてのエラーと例外の処理

エラーや例外を正しく処理することでコードの信頼性や安全性を高めることができます。
エラー処理が攻撃を検知するためにも役立つことがあるため、侵入検知にも役立てることができます。

しかし、エラー処理の誤りは情報漏洩や DoS に繋がる恐れもあります。
エラー処理を実装する場合には、以下のアドバイスが参考になります。

・ユーザーに表示されるエラーメッセージは、重要な情報が漏洩しないようにし、ユーザーが適切な対応ができるだけの情報に抑える

・例外処理では、サポートや QA が問題を理解するのに十分な情報をログに記録する

・エラー処理は慎重にテスト、検証をする

2016 と 2018 の比較

OWASP Top 10 Proactive Controls は 2016 年にも発行されており、2018 と異なる部分もあります。
2016 と 2018 でどのような変化があったのか解説したいと思います。

今回の変更で大きく変わった部分としては 2016 では 9 位だったセキュリティフレームワークやライブラリの活用が 2 位へとランクをあげている点です。

OWASP Top 10 Proactive Controls は、重要度順に並べられているため「セキュリティフレームワークやライブラリの活用」が近年より重要になっていると思われます。

また、内容の違いを見るとライブラリ一覧を作成し、メンテナンスを行うこと、ライブラリのカプセル化し、必要な動作のみを公開することでアタックサーフェスを減らすこと、という点が新たに追加されています。

フレームワークやライブラリを使うことでセキュアにより効率良く開発できると同時に、その中に含まれる脆弱性のリスクも含まれてしまいます。
そのリスクと上手に付き合っていくためにもこれらのプラクティスも同時に実施していくことが必要です。

「セキュリティ要件の定義」に関しては前回の「早期に、繰り返しセキュリティを検証する」とタイトルが大きく変わり、内容としても繰り返しのテストの重要性よりも要件定義を強調した書き方へと変化しています。

要件定義時にミスユースケースという攻撃者側からの視点を取り入れてセキュリティの要件を拡張させる方法も追加されています。

それ以外の各項目に関してもアップデートされ、「セキュアなデータベースアクセス」では 2016 ではクエリーのパラメータ化などによる SQL インジェクション対策のみでしたが、 2018 では設定や認証、通信面でのセキュア化についても記述されるように追加されました。

こちらも近年の開発環境の変化に合わせて変更がされているように感じられます。

OWASP Top 10 との関連

OWASP Top 10 Proactive ControlsはOWASP Top 10 との関連についても書かれています。
OWASP Top 10 Proactive Controls 2018 と OWASP Top 10 2017 の対応表はこのようになります。

さいごに

今回は、OWASP Top 10 Proactive Controls 2018 についての概要と 2016 との比較、OWASP Top 10 との関連について解説しました。

OWASP Top 10 Proactive Controls を利用したセキュアな開発が少しでも広がればと思います。

また、2016 との比較を通してセキュリティのベストプラクティスに関しても時と共に変化していくことが感じられます。

毎年公開されている IPA 「情報セキュリティ 10 大脅威 2021」 が 2021 年 1 月 27 日に公開されましたが、10 位に「脆弱性対策情報の公開に伴う悪用増加」がランクインし、昨年 14 位からランクを 4 つ上げました。

OWASP Top 10 Proactive Controls 2018 の 2 位の「セキュリティフレームワークやライブラリの活用」でもありましたように、利用しているライブラリに脆弱性が発見され、脆弱性情報が公開されることで悪用されるリスクが増加します。

情報セキュリティ 10 大脅威 2021 からもわかるように近年よりこの脅威が注目されています。

Proactive Controls にも記載されていたベストプラクティスに従って利用しているライブラリ一覧の作成、メンテナンスをし、OWASP Dependency Check や Retire.JS のような既知の脆弱性を確認できるツールの活用、常に最新の状態へアップデートし脆弱性対策をしていきましょう。

さいごになりますが、yamory では、パッケージ管理システムで管理されているフレームワークやライブラリの脆弱性を自動で検出、対応優先順位付けし、脆弱性の一元管理を行うことができます。また、自分たちが利用しているソフトウェア一覧の確認もできます。
yamory は、OWASP Top 10 Proactive Controls 2018 の 2 位「セキュリティフレームワークやライブラリの活用」、IPA 「情報セキュリティ 10 大脅威 2021」10 位の「脆弱性対策情報の公開に伴う悪用増加」に対応するサービスと言えると思います。

無料トライアルも可能ですのでご興味がある方はぜひ試してみてください。

また、yamory ではセキュリティに関するイベントを随時開催中です。

今月は、2 月 18 日（木）16:00 〜 17:00 に「Struts の脆弱性への攻撃デモでみるリスクと効率の良い脆弱性管理の方法」を開催します。

ご興味のある方はぜひご参加ください。

参考文献

• OWASP_Top_10_Proactive_Controls_V3
• OWASPTop10ProactiveControls2016-Japanese
• OWASP-Top10-Proactive-Controls-2018-JP
• OWASP-OPC-IEEEE-OTop10-OTMobTop10-ssdf