Ssmjp201410 wakatono

5,335 views

Published on

Discussion about issue of systems operation and security in ssmjp 201410.
Of course, this is the trigger of discussion.

Published in: Business

Ssmjp201410 wakatono

  1. 1. 緊急 teach in! CVE-2014-8485
  2. 2. CVE-2014-8485 •_bfd_elf_setup_sections()の脆弱性 •不審なファイルにBinutilsのstringsを実行する と,おかしいことが起きるかも •lcamtuf@coredump.cx の blog で紹介されて た(@2014/10/24)
  3. 3. 進撃の運用現場と セキュリティの乖離 wakatono
  4. 4. 開発に必要なもの •人 •モノ •カネ •知識 •経験
  5. 5. 運用管理に必要なもの •人 •モノ •カネ •知識 •経験
  6. 6. 知識と経験 •開発と運用のどちらでも必要
  7. 7. あ •開発や運用で必要なものもう1つ •それは?
  8. 8. モラル
  9. 9. インモラル(何かエロい)な運用 •多分成立しない
  10. 10. そのための教育? •良識人/善男善女には有効 •最初からやる気満々の人には通用しない •彼らは隙あらば殺る気満々
  11. 11. そういう人を出さないために? •最初から運用を考えた設計 –使用期限をきちんと考える 資産化とも関連 –使用期限内はきちんと使える設計 運用もその前提で(!) •運用でケチらない 不届き者を入れない •運用だけでカバーしようとしない だいたいボロが出る
  12. 12. なんて綺麗にいけるの? •多分「いけない」 ことのほうが 圧倒的に多い…
  13. 13. 最初から運用を考えるという こと 開発企画時から「開発」「運用」 の2つをきちんと考える あとできれば「たたみ方」な.
  14. 14. 開発時に考えるべきこと •その開発対象はどのくらい使うのか 例えば5年は使うとか かかる費用は「開発」+「利用期間中の運用費 用」 •更改はするのか 5年使った後は,また別のモンに引き継ぐのか •上記前提を考えなおすタイミングはどこに設ける のか お金の総枠が変わるリスク
  15. 15. セキュリティを考えるポイント •これから開発・運用に入るものは今から でも –あたりまえといえばあたりまえすぎますが •すでに運用に入ってるものは, 運用の確認と見直しから入る必要がある –たいていの場合,他の業務との関係もあるの で面倒だが,適当に考えると後でひどい目に
  16. 16. 運用上のセキュリティ •外との接点が一番のポイント •でも,運用結果や情報って,外との接点が必要 なモンでもある –これがないと,普通はお金をもらえない •ここでジレンマ –個別に解決するしかない(安直に「ソリューション 入れて解決」とか言ってる奴は(ry –このジレンマを突く不届き者が必ずいる(と思え)
  17. 17. 不届き者って? いろんなパターン
  18. 18. 典型的なのは… •「何かにのめりこんで借金」は鉄板 –あぶり出すのもかなり難しいが… •ペイが少ない人に対して責任をどこまで 集中させるか? –運用まわすことを最優先に考えると,多分NG •重要な情報を扱う局面で再委託をさせな いというのは本質ではない –本質は「どこまで追いかけられるか」 –追いかけられないのであれば,再委託どころ か委託もNG
  19. 19. 重要なのは •「やったらバレル/捕まる」をきちんと得心 してもらう –教育の一環ではあるけど,「通り一遍のCBT」で はまず効果なし •隙を見せない意志表示 –そういってるけど「こうすりゃバレないでしょ」 と思ってる人の出鼻をくじく •例:取ってる証跡などをきちんと明示 •実際に隙を見せない –ルールを決めて,そのルールから外れたら検出さ れるということをきちんと見せる
  20. 20. 悪魔の一言「運用でカバー」 言うは易し,行うは難しの典型
  21. 21. 運用あるある •「技術的に実現困難」「では運用でカバー」 思いつき/開発側の腕の無さを運用に押し付 けるな •運用費用を削減しろ 最初から一定期限の運用費用を想定しとけ… •開発チームがそのまま運用に 人柱… •暫定仕様が気づいたら正式に 思いつき/開発側の腕の無さを運用に(ry
  22. 22. セキュリティ運用の難しさ •そもそもシステムが司る業務を知らない(!) •セキュリティ屋はセキュリティ屋の範疇でモノ を語ることが多い 専門企業はその傾向強いか? •セキュリティ強化→運用オーバヘッドとなる ケースが多い それでも運用費用下げるの?
  23. 23. なので… •セキュリティ屋さんは業務屋さんの中に 入り込んでほしい –やってる企業さんもいらっしゃいます •運用屋さんは損益分岐点をきちんと示し て欲しい –「セキュリティ云々のために工数増大する」 というのは,根拠とともに述べてほしい(そ の意見は期待されてます)
  24. 24. とはいいつつも,日本の運用 •マジでピカ一です,ハイ 言った以上のことも考えてやってくれちゃう これであのお値段は(ry •セキュリティについても(オーバヘッドでけ えよはおいといて)かなり強固 •海外の事例があまりにも(ry •もっとも,お値段も非常に高い とはいえ,上記の事情もあるのでしょうがな いところも
  25. 25. セキュリティ屋と運用屋 •多分,相性は良い •運用屋は「安定運用のために必要なことをき ちんと遂行する」ことに価値を見出す –セキュリティが安定運用に寄与することを説明し, 実行する動機付けを行う必要がある •セキュリティ屋がここを説明できないと,運 用屋は納得しない –そりゃ当然だわな…
  26. 26. アウトソース •セキュリティとコア業務に関しては,本気でやめたほ うがいいです 業務とセキュリティを分離して考えるのが実は一番い けない(分離できるところもあるとはいえ) •とはいえ,世の中の流れはBPOとかBPOとかBPOとか セキュリティってビジネスプロセスだっけか? •セキュリティとコア業務の境界がなくなってくるけど … これはこれで正しい –分離しなきゃいけないって誰が決めた? –アウトソースしづらくなる/できなくなるけど •コア業務のアウトソースなどという常軌を逸した行動はしない よね?
  27. 27. 経営手法の現状を見ると •正直,今の経営手法自体が相当イッてる感 –欧米型の経営が日本企業でも主流だけど,強い日 本企業の経営手法はそもそも欧米型の経営とは相 容れない部分もある –日本企業を瓦解させるために,欧米型の経営手法 を(誰かが)流行らせたとしか思えない •成果主義/数値化/見える化が流行 –現場を見て業務や成果を評価できない人でも数は 比較できるよね? –適正に評価できない人には良いツール •適正に業務評価できる人には邪魔者でしかない
  28. 28. 数値化の罠 •何も起こってない(きちんと運用できて いること)を数値化するのってかなり難 しい •セキュリティの場合も同様
  29. 29. 数値化しづらい業務の運命 •費用なりの効果を求める→数値に根拠を求め る だいたい費用削られるか,本質でない数値化 のために貴重な工数を取られるか どっちにしてもバッドエンド •工数削られると何が起こるか? 人が削られる→一人何役もやることになる さらに安い会社を探して運用を任せる 委託をやめて自分らでやる
  30. 30. 工数を削られるってことは •費用が削られるってこと →運用者が儲かるどころか人を削って やっと現状維持 •儲からないと何が起こる? 従事者の給料は増えない →従事者に何か(経済的にアレなこと が)あると,従事者は補填のために何か を考える
  31. 31. そういう人を出さないために? •最初から運用を考えた設計 –使用期限をきちんと考える 資産化とも関連 –使用期限内はきちんと使える設計 運用もその前提で(!) •運用でケチらない 不届き者を入れない •運用だけでカバーしようとしない だいたいボロが出る 運用費用を聖域と考えるのではなくて, 「計画された費用で計画された期間計 画された業務をきちんと完遂するため の必要経費」と考える必要
  32. 32. セキュリティも同様 •何か起こると「なんとかしろ」 •何もないと「なんでこんなにかかる の?」
  33. 33. セキュリティも同様 •何か起こると「なんとかしろ」 •何もないと「なんでこんなにかかる の?」 何か起こってほしいと 思ってるようにしか見 えない
  34. 34. 日本型経営とセキュリティの 親和性 実は意外にあうと思ってたり
  35. 35. 嫌疑がかかった時の証跡 •「自社の人が悪いことをやってないこと を示す」のは難しいが,就業時間内の行 動を示すための証跡はある程度提示可能 •ホンネはどうあれ経営層からどう証跡取 得について提示されるのがベターか? –社会の要請で –内部といえども信用できないから –「当社の社員は信頼できる」ことを客観的に 示すため
  36. 36. 運用といえばCSIRT? CSIRTという名の銀の弾丸はない
  37. 37. 最近よく聞くこと •インシデント発生→CSIRT設立 •セキュリティリスクに対応するためCSIRT 設置準備 •CSIRTがあればインシデント対応は万全 –いや,そんなことないから
  38. 38. CSIRTという考え方 •昔からあったけど,認知度が上がったのは ごく最近 •すでにインシデント対応をやってるところが あるならば,札をつけるかつけないかだけの 話 •経営幹部から降りてくるのはもう少し抽象的 なオーダーでいいはず(CSIRT設立はあくま で手段)
  39. 39. 運用といえばSIEM? SIEMという名の(ry
  40. 40. SIEMというソリューション •なんか見えない攻撃を見えるようにして くれるらしいぞ •「相関分析が~」「ログ分析~」 •でも…SIEMは銀の弾丸ではない
  41. 41. SIEMで必要なネタ •日々の運用管理で出てくる証跡類 –要は適切に取得されたログ •適切に取得されないログはゴミよりタチ悪い •怪しいものを怪しいと言い切れる知見 –誤検知を誤検知と言い切れるだけの知見 •運用がきちんと回ってないと,SIEM邪魔 者
  42. 42. SIEM運用がまわったとして •レスポンス必要なネタが増えるだけ •でもそれは悪いことなの? •何を良くするとSIEM入れてよかったにな る?
  43. 43. セキュリティはリスクの新参者 (1/2) •これまで思い知らされた事実の山からの発見 •セキュリティリスクはあくまでリスク要因の 1つでしかない –せめて,運用上のリスクと運用者にとらえていた だくにはどうするのがよいのか? •しかし新参者であるが故に,対処方法や方針 等がまだ確立されていない風 –100%予防は困難. –予防に加えて早期検知と適切な対処が鍵
  44. 44. セキュリティはリスクの新参者 (2/2) •新参者であるが故に,どうしても他の リスクと比較して後回しにされがち –最近はそんなこともないか? •リスク要因としてのセキュリティを, 堂々と語れる大御所がまだまだまだまだ 少ない –いないとは言わない –時間に解決してもらうしかないか?
  45. 45. ということで… まだまだ続くよ 問題提起

×