Developers Summit 2017 Summer【C-6】CIにおけるセキュリティテストの組み込み方について 聴講メモ
講演資料
資料公開予定なし。
概要
激化するWebアプリへの攻撃を紹介しつつ、高速化する開発とセキュリティ対策の両立を図るための手段として、"DevSecOps"の考え方に基づいて、CIの中にセキュリティテストを導入する手法について紹介する。
スピーカー
ユービーセキュアの最首さん。製品事業を統括している。
詳細
増加するDDoS攻撃
昨年秋、史上最大のDDoS(Distributed Denial of Service)攻撃が発生した。
商用DDoS攻撃をスクープしたBrian Krebsのサイトに対して、665[Gbps]の攻撃。
- フランスISP(OVH)が複数経路からDDoS攻撃を受けた。攻撃の一つは799[Gbps]、総計1.1[Tbps]の攻撃。
- 攻撃元は15万台のボットネット。
- 昨年10月にDyn社が運営していたDNSがダウン。
Mirai
教訓
- IoT機器は初期設定情報を変更してから使用する。
- 昨今の攻撃では、攻撃者の修正や、攻撃のスピードが早いという特徴がある。
Miraiのデモ
- ここで、登壇者のPC内仮想環境上でMiraiの攻撃デモが行われた。
開発スピートとセキュリティ対策の両立
アプリケーション開発のライフサイクルとセキュリティ診断のスピード感が合わない。
- 外部診断は費用、時間がかかるので、ライフサイクルに組み込みにくい。
- 数回分のリリースをまとめて外部診断しているケースもある。
“DevOps"にセキュリティを組み入れて"DevSecOps"に。
- DevOpsのスピード感を活かしたままセキュリティプロセスを取り込む。各工程にセキュリティ対策を入れていこう、という考え方。
- 数年前からガードナーがコンセプトを出しており、RSA Conference 2016などで言及されている。
- 実装、テスト、リリース時にセキュリティ診断を行う。
- 単に診断を組み込むだけでは速度が落ちるので、実装、テスト、リリースについて自動化を行う。
“ツールで診断を自動化する"、"脆弱性検出を前倒す"が目指す姿。
- 開発者自身が診断実施者になる。
- これまでは外部の実施者がブラックボックステストとして実施していた。
- 開発者が診断することでホワイトボックス、グレーボックステストになる。
- 開発者自身が診断実施者になる。
開発者が診断実施者になるメリット。
- 開発者が希望するタイミングで診断が行えるようになる。
- 実施範囲を自分で決められる。
- 検出結果の判定が容易。
- セキュリティ対策知識が開発側に蓄積されていく。
診断自動化に用いるツールの特徴
- SAST(Static Application Security Testing)とDAST(Dynamic Application Security Testing)。
- SASTはソースに対する静的解析。
- DASTは動作するアプリに対して動的に解析。
SAST
- パターンマッチングやライブラリチェックなどを行う。
以下のようなデータフロー解析がよく採用される。
- 外部入力を受け取る変数(ソース)を探す。
- エスケープ処理を探す箇所(フィルタ)を探す。
- 変数が制御に影響する処理(シンク)を探す。
- ソースからシンクに行く間にフィルタが働いているかを確認する。
脆弱性の検出率はツール依存。
- 実施準備が容易。
- 比較的診断時間が短い(数分から数時間)。
- ちなみにMiraiをSAFESQL(SQLインジェクション静的解析)で検査したら数秒で終了した。
- SQLインジェクションの脆弱性はなかった。Miraiはよくできている。
- ちなみにMiraiをSAFESQL(SQLインジェクション静的解析)で検査したら数秒で終了した。
- 過検知が多い傾向がある。
- 比較的診断時間が短い(数分から数時間)。
- SCA(Software Composition Analysys)という系統のツールもある。
- OSS含め種々のツールが有る。
DAST
- 擬似攻撃リクエストを送り、レスポンスで脆弱性を判断する。
- 攻撃パターンを切り替えつつリクエストを行う。
- 環境構築とツール設定が必要。
- SASTと比して診断時間が長い(数時間から数十時間)。
- SASTと比して過検知が少ない。
- OWASP ZAPが優秀なツールとして有名。
- OWASP(Open Web Application Security Project)。Webセキュリティを中心テーマとした非営利組織。
誤検知
- セキュリティテストには誤検知の問題があるので注意。
DevSecOpsの実施
4つの自動化された作業からなる。
- 開発者の手元で簡易なSASTを行う。
- (プルリク等により)マージするタイミングでSCA(ライブラリチェック)。
- SASTサーバでSAST診断。
- デプロイする段階でテスト環境に対してDASTを実行。
簡易SAST->SCA->SAST->DAST->マニュアル診断、という手順で脆弱性をふるい落とす。
認証不備や機能レベルのアクセス制御をマニュアルでチェックする。
- あまり修正するところではないはずなので、毎回実施する必要はなく、初回リリースやメジャーリリースで行えば良い。
複数のSASTを導入すると良い。
- 早く開発者にフィードバックすることが重要。
- 可能であれば簡易SASTはIDEに組み込む。
- データフローのような解析系は時間がかかるので、プルリク時に専用環境で実施するのがおすすめ。
- 過検知が発生した場合、次の解析時から除外して検査できるツールを使うとよい。
DASTも専用の環境で実施する。
- 診断用テストデータを準備し、シナリオとセットで管理する。
- 変更や削除処理用のテストデータは事前投入する。
- 同じリクエスト処理を何度も行うので、エラー検知機能や通知機能はOFFにしておく。
- 高い性能の環境で実施するとよい。
DASTの診断時間が短いアプリの特徴。
ツール導入時の考え方
- どういうツールを使うか?
- 複数のツールを導入して、なるべく早い工程で脆弱性を見つける。
- マニュアル診断はどこで?
- ツールはどのように使い分ければ?
- SASTは複数ツールの導入を推奨。
- DASTはツール設定でユーザ操作の再現性、網羅性を上げるとよい。
余談
- ユービーセキュア製のVEXというツールはBlack Hat USA 2017で出展しているらしい。