Last Updated on 10月 7th, 2019, By
 In AppSealing Blog, AppSealing News

AppSec Mistakes Part-1

世界の開発者は、アプリセキュリティ(AppSec)の先制的な適用が、必ずしも成功するわけではないということを知っています。しかし、このような過程で得た経験は、その後開発者がセキュリティ面で安全なアプリケーションを作成できるようサポートします。ここでは、企業や開発者がアプリセキュリティ方法を具現化するにおいて、一般的に犯しやすい6つの誤りについて詳しく紹介したいと思います。このような誤りから学べる模範例は、企業や開発者が増加を続けるサイバー脅威に強力な対策を講じるロードマップを発展させるのに役立つでしょう。この措置は、急激に進化するリスクに対抗し、予め対応するために必要なプロセスです。

繰り返される誤りの一つは、アプリケーションテストにおいて不適切な方法を用いることに関連しています。一般的に、開発者とテストは、各テストタイプの必要性と適用可能性を考慮しないまま、アプリケーションの限られたテストケースのみを実行します。安全なセキュア・ソフトウェア開発ライフサイクル (sSDLC)の適用において、静的解析と動的解析は効果的かつ包括的なアプリセキュリティテスト方法論を確立するにあたって必要不可欠です。

静的解析と動的解析の相補的関係

静的アプリケーションセキュリティテスト(SAST; Static Application Security Testing)は、基本的にホワイトボックステストであり、これを通して開発者は、アプリケーションのアーキテクチャとソースコードの詳細内容をチェックします。そのため、SASTは、実行環境でないコードベースを監視し、セキュリティホールと悪性コードを探し出す過程だと言えます。配布段階でウェブサイトの脆弱性とデータ侵害の過程が発見される事例が増加するにつれ、配布前のセキュリティ脆弱性に対するチェックは必要なプロセスとして認識されるようになりました。それに対し、ブラックボックステストとして知られる動的解析(DAST; Dynamic Application Security Testing)は、実行環境で行われ、アプリケーションの全般的な性能のモニタリングをサポートします。DASTは、アプリケーション配布後にのみ実行できるため、アプリケーションのソースコードを検査することはできません。

SAST,DAST,IAST testingImage Credit- Gartner Application Security terms SAST, DAST, and IAST

上述した静的解析と動的解析は互いに補い合い、一つの方法の弱点は他の方法の強みになります。静的解析ではカプセル化、配布構成、クロスサイトスクリプティングなどで発生する問題を把握することはできません。短いサイクルのスクリプトとアジャイルの開発方法論の出現は、アプリケーションの変更事項を毎日徹底的かつ包括的なテストにより確認する過程が必要だということを、益々強調しています。ホワイトボックス式の静的解析は、ソフトウェア開発の初期段階でセキュリティリスクを把握し、システムの潜在的バグの発掘費用の効率化を高めます。

それに対し、動的解析は、アプリの製品化完了段階に到達するまでセキュリティホールを除去できない静的解析の短所を補います。アプリケーションがビルドされ、配布準備が完了すると、その後に動的解析を使用してセキュリティテストを実行します。継続的なインテグレーションととデリバリー(CI/CD; Continuous Integration/Continuous Deployment)を使用するプロジェクトは、アプリケーションコードが頻繁に変更されビルドされるため、実行時点でセキュリティ評価を行うのは困難です。そのため、このような場合は、はじめから最終段階までのアプリケーションのライフサイクル全般にかけてセキュリティを評価することが必要不可欠です。

シナジー効果を生み出すセキュリティ戦略

静的解析がアプリケーションのコードベースとバイナリ基盤でアプリのセキュリティホールを検査する反面、動的解析はアプリケーション実行後に外部でアプリケーションのセキュリティホールを検査します。静的解析は、アプリケーションの内部から外部へ、動的解析はアプリケーションの外部から内部へセキュリティを点検すると言えます。結果的に、この二つの解析は完璧なテスト方法論を形成します。どちらかを実行しないと、攻撃可能な方法がテストされなくなり、アプリケーションのセキュリティは脆弱になります。

セキュリティ戦略を確立するためには、開発者やテスターがサーバーとクライアントの脆弱性をすべて評価するためのテスト戦略を具現化しなければなりません。この過程は、開発チームがCI/CD、アジャイル、DevOpsなどの最新開発方法論とセキュリティフレームワークを組み合わせられるようサポートします。自動化されたセキュリティテストツールの使用以外にも、脆弱性の攻撃、検証、パッチ有無を確認するためのマニュアル化された作業も必要です。

ハッカーがフィッシングなどの単純な技術を用いてユーザを騙すのは、もはや過去のことです。これからは、アプリケーションへの悪性コードの挿入などによる攻撃が増加するため、開発者は完璧なアプリケーションテスト戦略の確立を強く求められています。一度にアプリケーションすべてのセキュリティリスクを検知する、万病に効く薬のような方法はありません。開発・テストチームは、二つのテスト技術が互いにシナジー効果を生み出し、未来の競争力を育むよう、発展させなければなりません。

アプリセキュリティにおける誤り-2部の記事をご確認ください。この記事では、オープンソースライブラリの脅威とその克服方法について紹介しています。

AppSealing
AppSealing
AppSealingはコードを作成せずにモバイルアプリを保護できるとともに、リーズナブルな価格(使った分だけ支払う)の、クラウドベースのセキュリティソリューションです。AppSealingは手軽に使用でき、ハッカーの不法なアプリ偽造・変造行為を遮断するランタイムアプリケーション自己保護(RASP)セキュリティを提供し、アプリケーションの実行時に様々なハッキング攻撃からあなたのアプリを守ってくれます。

Leave a Comment

Reverse EngineeringApp Security with simple coding practices