dimeizaのブログ

興味のある技術(IoT/VR/Smart Speaker)とか、資格試験の話とか、日常で出会ったTechな話について書いています。

Developers Summit 2017 Summer【C-6】CIにおけるセキュリティテストの組み込み方について 聴講メモ

Developers Summit セミナー聴講メモ

講演資料

　資料公開予定なし。

概要

　激化するWebアプリへの攻撃を紹介しつつ、高速化する開発とセキュリティ対策の両立を図るための手段として、"DevSecOps"の考え方に基づいて、CIの中にセキュリティテストを導入する手法について紹介する。

スピーカー

　ユービーセキュアの最首さん。製品事業を統括している。

詳細

増加するDDoS攻撃

  • 昨年秋、史上最大のDDoS(Distributed Denial of Service)攻撃が発生した。

  • 商用DDoS攻撃をスクープしたBrian Krebsのサイトに対して、665[Gbps]の攻撃。

  • フランスISP(OVH)が複数経路からDDoS攻撃を受けた。攻撃の一つは799[Gbps]、総計1.1[Tbps]の攻撃。
  • 昨年10月にDyn社が運営していたDNSがダウン。
    • 多数の有名サービス(Twitter等)がアクセス不能になった。
    • DNS水攻め攻撃。
      • ランダムなFQDNを生成して、キャッシュサーバに問い合わせを行い、DNSのキャッシュを消費させる。
      • 正当なFQDNについてもキャッシュが効かなくなり、上位サーバも負荷で落ちる。

Mirai

  • これらの攻撃はマルウェア『Mirai』を用いたボットネットによるもの。

    • 今はGitHubにソースがアップロードされ、OSS化している。
      • ソース公開後、亜種による拡散攻撃が複数回観測。
        • 日本では5358ポートに対する攻撃が増加した旨の警告。
        • 2017/2にはWindows版も確認されている。
    • DDoS機能とBOT拡散の機能を持つ。
    • 攻撃者がC&Cサーバに指示すると、C&Cからボットネットへ攻撃指示が拡散する。
    • 拡散機能では、ランダムなIPアドレスにTelnetし、既知のパスワードでログインを試みる。
      • 攻撃結果をレポートサーバで集計し、集計結果を元にボットを配置していく。

  • 教訓

    • IoT機器は初期設定情報を変更してから使用する。
    • 昨今の攻撃では、攻撃者の修正や、攻撃のスピードが早いという特徴がある。

Miraiのデモ

  • ここで、登壇者のPC内仮想環境上でMiraiの攻撃デモが行われた。
    • C&Cサーバからの指示を受けて、ボットPCが攻撃対象にHTTP Floodを仕掛ける。
      • 攻撃対象はC&Cサーバ自身を指定し、10秒間攻撃を行った。
    • C&Cサーバのターミナルにログイン後、コマンドラインから攻撃を指示。
      • 何故かログインプロンプトはロシア語。ログイン後のメッセージは英語。
      • 攻撃コマンドは普通のLinuxコマンドのようにオプションで攻撃手法や攻撃対象アドレスを指定できる。

開発スピートとセキュリティ対策の両立

  • アプリケーション開発のライフサイクルとセキュリティ診断のスピード感が合わない。

    • 外部診断は費用、時間がかかるので、ライフサイクルに組み込みにくい。
    • 数回分のリリースをまとめて外部診断しているケースもある。

  • “DevOps"にセキュリティを組み入れて"DevSecOps"に。

    • DevOpsのスピード感を活かしたままセキュリティプロセスを取り込む。各工程にセキュリティ対策を入れていこう、という考え方。
    • 数年前からガードナーがコンセプトを出しており、RSA Conference 2016などで言及されている。
    • 実装、テスト、リリース時にセキュリティ診断を行う。
      • 単に診断を組み込むだけでは速度が落ちるので、実装、テスト、リリースについて自動化を行う。

  • “ツールで診断を自動化する"、"脆弱性検出を前倒す"が目指す姿。

    • 開発者自身が診断実施者になる。
      • これまでは外部の実施者がブラックボックステストとして実施していた。
      • 開発者が診断することでホワイトボックス、グレーボックステストになる。

  • 開発者が診断実施者になるメリット。

    • 開発者が希望するタイミングで診断が行えるようになる。
    • 実施範囲を自分で決められる。
    • 検出結果の判定が容易。
    • セキュリティ対策知識が開発側に蓄積されていく。

診断自動化に用いるツールの特徴

  • SAST(Static Application Security Testing)とDAST(Dynamic Application Security Testing)。
    • SASTはソースに対する静的解析。
    • DASTは動作するアプリに対して動的に解析。

SAST

  • パターンマッチングやライブラリチェックなどを行う。

  • 以下のようなデータフロー解析がよく採用される。

    1. 外部入力を受け取る変数(ソース)を探す。　
    2. エスケープ処理を探す箇所(フィルタ)を探す。
    3. 変数が制御に影響する処理(シンク)を探す。
    4. ソースからシンクに行く間にフィルタが働いているかを確認する。

  • 脆弱性の検出率はツール依存。

    • NSAの調査結果によると、脆弱性を仕込んだソースに対して複数のSASTツールで解析したところ、27％の脆弱性はどのSASTでも検出されなかった。
    • ツールの特性を考慮して導入していく必要がある。
  • 実施準備が容易。
  • SCA(Software Composition Analysys)という系統のツールもある。
  • OSS含め種々のツールが有る。

DAST

  • 擬似攻撃リクエストを送り、レスポンスで脆弱性を判断する。
  • 攻撃パターンを切り替えつつリクエストを行う。
  • 環境構築とツール設定が必要。
  • SASTと比して診断時間が長い(数時間から数十時間)。
  • SASTと比して過検知が少ない。
  • OWASP ZAPが優秀なツールとして有名。
    • OWASP(Open Web Application Security Project)。Webセキュリティを中心テーマとした非営利組織。

誤検知

  • セキュリティテストには誤検知の問題があるので注意。
    • False Positive(偽陽性)
      • 正常な現象を異常として検知してしまう。
    • False Negative(偽陰性)
      • 異常な現象を正常として見逃してしまう。

DevSecOpsの実施

  • 4つの自動化された作業からなる。

    1. 開発者の手元で簡易なSASTを行う。
    2. (プルリク等により)マージするタイミングでSCA(ライブラリチェック)。
    3. SASTサーバでSAST診断。
    4. デプロイする段階でテスト環境に対してDASTを実行。

  • 簡易SAST->SCA->SAST->DAST->マニュアル診断、という手順で脆弱性をふるい落とす。

    • 認証不備や機能レベルのアクセス制御をマニュアルでチェックする。

      • あまり修正するところではないはずなので、毎回実施する必要はなく、初回リリースやメジャーリリースで行えば良い。

    • 複数のSASTを導入すると良い。

    • 早く開発者にフィードバックすることが重要。
    • 可能であれば簡易SASTはIDEに組み込む。
    • データフローのような解析系は時間がかかるので、プルリク時に専用環境で実施するのがおすすめ。
    • 過検知が発生した場合、次の解析時から除外して検査できるツールを使うとよい。

  • DASTも専用の環境で実施する。

    • 診断用テストデータを準備し、シナリオとセットで管理する。
    • 変更や削除処理用のテストデータは事前投入する。
    • 同じリクエスト処理を何度も行うので、エラー検知機能や通知機能はOFFにしておく。
    • 高い性能の環境で実施するとよい。

  • DASTの診断時間が短いアプリの特徴。

    • 画面の遷移階層が浅い。
    • リクエストパラメータが少ない。
    • 一言で言うと簡素なアプリ。
      • 簡素なアプリは攻撃箇所(Attack surface)が少なく、安全性を確保しやすい。

ツール導入時の考え方

  • どういうツールを使うか？
    • 複数のツールを導入して、なるべく早い工程で脆弱性を見つける。
  • マニュアル診断はどこで？
  • ツールはどのように使い分ければ？
    • SASTは複数ツールの導入を推奨。
    • DASTはツール設定でユーザ操作の再現性、網羅性を上げるとよい。

余談

  • ユービーセキュア製のVEXというツールはBlack Hat USA 2017で出展しているらしい。