AppSecにありがちな間違い – Part 1: テスト手法を１つしか使わない

この記事は2019年7月3日に公開された以下の記事を翻訳したものとなります。

 https://www.appsealing.com/2019/07/appsec-mistakes-part-1-using-only-one-testing-method/

開発者の共通認識として、どんなセキュリティアプリ（テク用語でAppSec）戦略も決定的な切り札にはなりません。ただし、多くの場合このような戦略を実行し経験を重ねることで、将来的に堅牢なセキュリティのアプリを作成するのに役立ちます。AppSec手法を実装する際に企業や開発者がしてしまいがちな6つの間違いについて掘り下げてみましょう。この間違いから学ぶベストプラクティスを継承し、
とどまるところを知らないサイバー危機に対して、堅牢なセキュリティロードマップの展開に活かします。これらの手法は、急速に進化を遂げる脅威のランドスケープよりも一歩先にいられるようにするため、いずれは実装するべきです。

繰り返しやってしまいがちな間違いの１つは、不適切なアプリテストと関係しています。よくあるのは、開発者・テスト担当者が各テストのタイプの必要性と妥当性を吟味せずに、限られたテスト手法のみを実行するというものです。各テストのタイプの必要性と妥当性は、アプリケーションの現状と、全体的なAppSecの要件によって判定します。ソフトウェアのセキュア開発ライフサイクル（sSDLC）を考慮に入れると、効果的で完全なAppSecテスト手法を獲得するには静的分析と動的分析の両方が必要です。

相互に補完し合う静的分析と動的分析

静的アプリケーションセキュリティテスト（SAST）は必須のホワイトボックステストです。開発者はここからアプリの構造とソースコードを理解します。静的アプリケーションセキュリティテストは、コードベースの検証を行い、ランタイムでない環境での欠陥とマルウェアの発見に役立ちます。Webサイトの脆弱性とデプロイ段階でのデータ漏洩に関する報告が増えていますから、配置構成におけるクロスサイトスクリプティングなどのセキュリティ脆弱性テストは不可欠です。一方で、ブラックボックステストとも呼ばれる動的アプリケーションセキュリティテスト(DAST)は、ランタイム環境で実行し、全体的なアプリのパフォーマンスを監視するのに一役買います。動的アプリケーションセキュリティテストを実装できるのが本番環境のみであるため、アプリのソースコードの分析はできません。

上記で述べたように、静的分析と動的分析はお互いに補完しあい、片方の弱点がもう片方の強みとなっています。静的分析では、カプセル化、配置構成、クロスサイトスクリプティングなどから発生する問題点を特定できません。実際、アジャイル開発モデルの出現とquick sprintsが日常的になったことで、アプリ内の効果に変更が加わり、包括的で徹底したテストが必要になりました。静的分析はそのホワイトボックスアプローチにより、ソフトウェア開発の初期段階でセキュリティの脅威を見つけるのにコスト効率が良く、システムの将来的なバグを発見するのに効果的です。

- 「OWASP Mobile TOP 10のリスクからアプリを保護しよう」について詳しく読む。

一方で、動的分析は、静的分析では手の届かない欠陥の発見について補完します。この欠陥は、アプリが実用段階になるまで気づかれません。アプリ構築が完了してデプロイの準備が整ったときに、動的分析を使用して実行コードをテストします。継続的インテグレーション、継続的デプロイメント（CDCP）のプロジェクトにおいては理想的ではありません。理由としては、アプリのコードが頻繁に更新されると、ランタイムでの評価が困難になるからです。それでも、初めの段階から実用に至るまで、アプリのライフサイクル全体を通してセキュリティを評価することはとても重要です。

セキュリティ戦略にシナジーを与える

静的分析では、コードベースとバイナリを調べることで、アプリにセキュリティ脆弱性がないか内側から外側にチェックします。動的分析では、アプリの実行モード中に外側から内側に調べます。この２つの組み合わせにより完全なテスト方法となります。片方しか行わないと、攻撃ベクトルを検証せずアプリをセキュリティの脅威に脆弱なまま置いておくことになります。

セキュリティ戦略をたてるには開発者またはテスト担当者による計画的なテスト戦略を実装してサーバーサイドとクライアントサイド双方の脆弱性を査定することが必要です。そうすることで、開発チームはセキュリティのフレームワークをCICDやアジャイル、DevOpsといった最新の開発モデルに合わせることができるようになります。自動セキュリティテストツールの使用に加えて、手動の介入も脆弱性の利用、検証、適切なパッチのためには必要です。

「脆弱性スキャン vs ペネトレーションテスト」について詳しく読む

ハッカーがフィッシングなどの単純な手口を使ってユーザーをだましていたのは、遠い昔になってしまいました。今では、アプリに悪意のあるコードを挿入するハッカーの手口は増え、それにより開発者はアプリ対して完全に信頼のおけるテスト方法を作成しなければならなくなりました。それゆえ、アプリを利用してすべてのセキュリティ脅威を一度に検出する万能な解決策などはないといえます。静的分析または動的分析のどちらかだけでは100％の脅威検出はできません。開発チームまたはテスト担当者は、両技術の間にシナジーをもたらし、これらの分析技術を実装して、将来にも有効なセキュリティソリューションを発達させていくべきですが、継続的なバージョンアップグレードのサイクルの中で、タイトなスケジュールに合わせようと追いつめられると見落としがちになってしまいます。

オープンソースライブラリの脅威とその回避方法について記載している「AppSecにありがちな間違いPart-2」の記事も併せてご確認ください。

セキュリティについてのご相談はinfo@appsealing.jpにお問い合わせください。