biglobeにおけるサイバーセキュリティ対策と脆弱性診断サー … ·...

Copyright (C) BIGLOBE Inc. 2014. All rights reserved. 1

BIGLOBEにおけるサイバーセキュリティ対策と

脆弱性診断サービス活用法のご紹介

2014/5/16

ビッグローブ(株)

BIGLOBE-CSIRT 兼法人事業部

橋田幸浩


サイバーセキュリティの脅威にも色々ありますが…

サービスシステム

アプリケーション

OS/ミドルウェア

インフラ（H/W）

汚染PC

外的脅威内的脅威

脆弱性事件／事故

（流出・消失・破壊・汚染）

ウィルス

ボッツ

善意のユーザ

悪意のユーザ悪意の関係者（内部犯行者）

善意の関係者

汚染PC

ウィルス

ボッツ

直接攻撃

間接攻撃

攻撃

攻撃ミスオペレーション

直接攻撃

事故

攻撃


自主事業でのノウハウに基づき適切に対処しています

サービスシステム汚染PC

外的脅威

脆弱性

ウィルス

ボッツ

善意のユーザ

悪意のユーザ

直接攻撃

間接攻撃

攻撃

攻撃

内的脅威

事件／事故（流出・消失・破壊・汚染）

悪意の関係者（内部犯行者）

善意の関係者

汚染PC

ウィルス

ボッツ

ミスオペレーション

直接攻撃

事故工事審査制度（手順書レビュー、共通チェックリスト等）自動化促進、 PDCAサイクルの確立

・検疫システムによるガード・ポリシ管理による端末制御

・私有品の社内設備への接続等は検疫システムでブロック・事故対策ルールや体制の整備

契約時の誓約書制度、ロギングと監査による抑止

アクセス規制

（L3フィルタ）

アクセス規制

（L3フィルタ）

お客様のご要望により、 IDS、Firewall、セキュリティ診断をオプションとして用意

デフォルト構成の最小化による堅牢性向上

情報watchと迅速なパッチ適用体制の整備

インフラ構成レベルでの堅牢性向上

・定量的検証による出荷前の潰し込み・定期検査の実施による堅牢性維持

プロセスや負荷を常時監視。異常を検知した場合は必要に応じて即時隔離・シャットダウン・データ保全等を実施（※お客様と調整の上、実施）

アプリケーション

ＯＳ／ミドルウェア

インフラ（Ｈ／Ｗ）

ポイント＝「要塞化」＋「境界防御」


外部からのサイバー攻撃の変遷

黎明期（～10年前）特定IPアドレスからの連続攻撃一目で悪意のある攻撃(通信)と分かる

中世（～５年前）特定危険国など、ある程度は定まった

範囲のIPアドレス帯からの攻撃一目で悪意のある攻撃(通信)と分かる

近代（～ここ数年) 国内ではあるが、特定プロバイダなど

限定的な範囲のIPアドレスからの攻撃正当な通信との区別がしづらい

現代（ここ１年） IP不特定で動的に変化しながら攻撃正当な通信との区別がほぼ不可能

特定の通信のみ遮断してしまえばOK

事業影響も

極小

通信遮断による事業影響は容認できる

レベルで収まる

通信遮断で対処すると

事業に致命的影響が及ぶ


攻撃トレンド201X

正規アクセスパスを悪用した攻撃へ超大規模DDoS

アンプ型攻撃ボットPC

NTP

オープンリゾルバ

数百Gbps トラフィック

・「要塞化」「境界防御」が通用しない攻撃にシフト・今後さらに防御困難な手法が開発されると想定

パスワードリスト攻撃

不正交換

不正接続

会員情報漏えい

スパム大量送信


セキュリティ意識の変革が必要

昔安全性/信頼性と利便性/収益性は、トレードオフ（背反）である

現代＋これから安全性/信頼性と利便性/収益性は、事業の継続と成長のための両輪である


開発者の皆様＆自分への問いかけ

そのサービス、ご家族やお友達に「自分が作った。安心して使ってくれ！」と言えますか?

事業優先という理由で安全性に手を抜いたサービスでご家族やお友達が被害を受けたとき、「企業は利益を出すのが仕事だから、少しくらい仕方が無い。最低限の賠償はしてもらえるのだから、運が悪かったとあきらめなさい」と言えますか?


それでは、会議室と現場では何が起こっているか?


実態はこんな風になっていませんか?（その１）

情シス・セキュリティ対策責任者ガイドラインやチェックリストを作ったので全件確認せよ

プロジェクトリーダ・分厚くて読む気になれない・読んでも意味がよく分からない・何をどこまでチェックすれば良いか分からない

開発担当者・予算や納期から考えると現実的に不可能・どう答えれば良いか分からない

経営者 ○○社がサイバー攻撃でやられたらしいが、うちは大丈夫なのか?

収益性が第一多少のリスクは

容認されるべきだ


実態はこんな風になっていませんか?（その２）

情シス・セキュリティ対策責任者・とにかくガイドラインやチェックリストを守るべし・個人情報を扱ってるサイトを優先的に調べさせよう

プロジェクトリーダ・現実味が無いから、抜粋してチェックさせよう・個人情報を扱ってるサイトさえ守れば良い

開発担当者・イエスと回答すれば良いんでしょ → 次ページ参照・個人情報を扱ってなければチェック不要だ

経営者まずは個人情報の防護をしっかりとやってくれ

まじめな開発者さん達は、大量のチェック項目を必死に確認する。だけどお金は（ほぼ）頂けず…


「脆弱性対策」の実態

一般論的なチェックリストは形骸化・属人化する典型的な例（本当にあった「開発担当者の怖い勘違い」）パスワードは「分かりにくい物」を設定しているか？不要なポートは閉じてあるか？不要なデバッグモードは閉じてあるか？ <script>alert(“警告”)</script> と入れても正しくサニタイズされるか？

等々

「都合の良い解釈」と「不十分な検証」に陥りやすい


「セキュア開発の目的」とは？

ありがちな目的の見誤りチェックリストやガイドラインを満たすこと？コーディング規約を満たすこと？脆弱性を潰すこと？ …etc

正しい目的お客様の安心・安全を守ること＝お客様に余計なリスクを負わせないこと＝「攻撃の余地がない事」や、「やるべき事の抜け漏れが無い事」を分かりやすく証明し、その状態を維持すること

NO! 目的にあらず


対策：要件定義の例：基準をシンプル＆明確化

「様々な団体に検証・評価されているツール」を品質基準として利用「都合の良い解釈」や「過剰な要求」を防止

BIGLOBEで使っている要件定義の一例 AppScanなど一般的に定評のある検査ツールを用い、出荷検査時点における既知の脆弱性が残っていないことを証明すること

目的＝お客様の安全を担保することであり、ﾁｪｯｸﾘｽﾄやｶﾞｲﾄﾞﾗｲﾝを満たすことではない


参考：ツールのベンチマーク情報例

出典 http://sectooladdict.blogspot.jp/2011/08/commercial-web-application-scanner.html Gartner Magic Quadrant for Application Security Testing 2013


・SEや情シスがサポートサイトを日々巡回・調査する手間（負担）をゼロ化

PDCAサイクルにおける各種サービスの最適な使い方は？

出荷前検査

ワンショット型セキュリティ診断

脆弱性が見つかったら

即修繕

開発製作

問題が見つからなければ安全性をアピール

軽微な修繕

大きな修繕

出荷後監視クラウド型脆弱性診断＋改ざん検知

教育学習

ガイドラインチェックリスト

ツールによる検査で、都合の良い解釈や不十分な検証に陥ることを防止

問題が発生したら CSIRTで対応

IPAや省庁などのガイドに対し、網羅性・信頼性の高いツール（サービス）を選定

IPAや省庁などのガイドに対し、網羅性・信頼性の高いツール（サービス）を選定

フィードバック


ツール毎の特性を活かして診断＆監視

例えるなら、象が踏んでも壊れない筆箱を… ワンショット型診断 → 本物の象が全力で踏む（ほぼ）破壊検査（脆弱性が無ければ壊れない）リリース前の環境に対してスキャンする踏ませるにも準備が要る

クラウド型診断 → 象みたいな人が踏む非破壊検査（作りが甘ければそれでも壊れる）リリース後の環境に対してスキャンする毎日でも踏める

クラウド型診断＝ワンショット型診断÷3 AppScan/WebInspect + Retina/Nessus


良くある質問

後工程で脆弱性を見つけてもリカバリが大変。ガイドやチェックリストをきちんと守らせるよう、上流工程でのチェックを強化するほうが有効なのでは? 最初はそう思っていましたが、実際はそうではありませんでした

技術力の高い会社セキュリティに疎い会社

・ポイントは押さえてあるから大丈夫！修正も簡単！・抜け漏れが出るより過剰検知される方が良い

手に負えないどうしたら良いか

分からない


セキュア開発＝高コスト開発？

ありがちな誤解セキュア開発＝採算性を横に置いた、ルール至上主義型の高コスト開発？

セキュア開発＝もっとも低コストな開発手法セキュアシステム＝ in/out を適切に制している

NO! もしそうなっていたら

ガイドやルールが良くない

ポイントを押さえて作ったシステムは、バグも少なく、パッチ影響も少なく、トラブル発生時の対処も簡潔で、

トラブル発生率も極少な構造になる

すなわちコスト

ミニマム


脆弱性診断ツールを活用した要件定義の効果

1. セキュリティ要件定義が10分で終わるテストの手法と信頼性の説明がほぼ無用

2. テスト工程を1/3に圧縮できる正常性テスト→異常系テスト→脆弱性テストを脆弱性テストの1step で済ませられる想定見積：0.5人月→実質で3人日に圧縮

3. 出荷審査の形骸化を防げる「ガイドやリストさえ満たしていれば良い」という思考停止を防げる

4. 開発パートナーのスキル計測・向上が図れる生産性の善し悪しが浮き彫りになる


筆者のセキュア開発体験

ログ管理システムの開発市販製品では機能要件･コスト要件が合わず、独自開発する道を選択 AP開発費：３年で約5千万

適用サーバ台数：システム側：本番系･評価系合わせて24台（拡張容易）クライアント側：300台超（諸元は最大3,000台の設計）蓄積データ量：12T（諸元は214Tの設計/理論上は無限）

アプリ保守費：四半期あたり0.9～1.0人月をキープ（個別のセットアップ費用は除く)

生産性＆セキュリティバグ修繕コスト：手戻り費用は、ほぼ無し ※一カ所だけ“要件間違い”でのみ手戻り

中級エンジニアが１営業日あたり１時間を保守に費やす計算

パッケージメーカーの人に現物を見てもらったところ、

安すぎると言われた


おまけ：昔の人は核心を突いてます

二宮尊徳の言葉道徳なき経済は罪悪であり、経済なき道徳は寝言である道徳＝お客様の安心･安全＝セキュリティ経済＝事業(サービス)＝収益

セキュア開発思想の根本安全性に手抜きしたサービスは罪悪であり、収益性を無視したガイド至上主義は寝言


まとめ：開発と監査の実態を、こんな風にしませんか？

情シス・IPA・省庁・ガイドラインやチェックリストを遵守してるか、全項目に答えて！・上流工程でもチェックし、チェックしているかどうかも報告して！

経営者 ○○社がサイバー攻撃でやられたらしいが、うちは大丈夫なのか?

開発担当者 / プロジェクトリーダ「攻撃の余地なし」と出てますが、何か?


ガイドラインやチェックリストを満たすことでは無い

常の問いかけそのサービス、「自分が作った。安心して使って」とご家族やお友達に自信をもって言えますか?

まとめ：セキュア開発の目的とは?

＜真の目的＞１．お客様の安心・安全を守ること＝お客様に余計なリスクを負わせないこと＝「攻撃の余地がない事」や「やるべき事の抜け漏れが無い事」を、証明・維持すること２．安全性と収益性を両立させること


ご静聴ありがとうございました

安心・安全

未来、つながる

biglobeにおける サイバーセキュリティ対策と 脆弱性診断サー … ·...

Documents

biglobeにおけるサイバーセキュリティ対策と脆弱性診断サー … ·...