2014年7月30日水曜日

開発エンジニアのためのセキュリティ★ナイトフィーバー!! #tecomp 【Vol.08】に参加してきましたよ!

セキュリティ初心者のボクには見逃せない勉強会が!


「開発エンジニアのためのセキュリティ★ナイトフィーバー!! #tecomp 【Vol.08】」ってのに参加してきましたよ。事前登録は必要で名刺とアンケートへの回答が必要だけれど、無料のイベントです。懇親会も無料だそうな(*1)。


パネリストとして登壇するのはセキュリティ方面でよく見かける辻 伸弘さん根岸 征史さんセキュインコさん新井 悠さんの4名の方々。

全般的に初心者でも大丈夫という触れ込み通り、一般論というか入り口部分というか比較的わかりやすい部分をテーマに話していただいたのかなーって感じ(*2)で、セキュリティ初心者のボクとしてもとても有意義な時間が過ごせました。欲を言えば、もうちょっと長いこと聞いていたかったなって感じですかね。

どんな話があったの?


ってことで、参加中にツイートされたものを読み返しながらいくつかピックアップしてみましょうか。ついでに自分の感想を書いてみたりして。

なお、各ツイートは議事録でもなければ各パネリストの方の発言を正確に書き写したものではありません。要約したり自分の理解に基づいて言葉を変更している部分があるので、各パネリストの方の真意とことなるものになってしまってるかもしれません。その辺りは他のツイートを参照したり、直接参加した人に聞いたり、パネリストの方に迷惑にならない範囲で質問するなどして、各自正確な情報の入手に勤めてください。

ボクも、各ツイートをした人も、このイベントを企画した人も、パネリストの皆さんもそこら辺は一切保障しないです。

前半戦の内容まとめ




今回は約1時間ちょっとのトークタイムを半分に分けて、異なるテーマでのお話となってましたね。前半も後半もなかなか興味深い内容で、これ参加できて良かったと心の底から思えるものでした。……まじ、これ、金とって言いレベルだよ。ほんと。



セキュインコさんがどうやって情報収集しているか……って話ですね。「押し入れの中でドラえもん状態」ってフレーズが脳内で何度もリフレイン。意外というかなんというか、TwitterやRSSリーダで情報収集してるんですね。ただ、プロジェクターで映し出された写真を見る限り、「え?これ読めるの?」ってくらいミッシリ表示されていました。いや、もう、まじ、圧巻。

あと、中の人なんていないそうです。



マウスオペレーションもパネェらしく、3ヶ月に1回マウスが壊れるとか。……あれ?マウスってそんな簡単に壊れるものだっけ?



まあ、当然ながら情報の洪水状態になるわけで。特定のキーワードが含まれるネタがあったら「ピヨピヨ」音をならすようにするなど、いろいろ工夫をしているようです。このキーワードのチョイスってのもノウハウなんだろうなぁと思ったり。



そんな情報量、いつ目を通してるの?……って話のヒトコマ。オフレコだそうなので、ボクは書きません。



通勤中に気になるネタをPocketEvernoteにつっこんでるのが辻さんのスタイルだとか。どちらのサービスも有料版契約してるらしいっす。



根岸さんも同じようなスタイルだとか。細かい使い方は微妙に異なるっぽいですが、みんな自分がやりやすいようにいろいろ工夫してるんだなぁというのが印象。



こういうスタイルでやってくと、タグが増えまくるとか。表記揺れってやつですね。どう管理してるの?……って話で、「管理しない」って話が出たときは、素直に「へぇ〜」って感じでしたね。まあ、ある程度の表記揺れは工夫次第で吸収できる部分もあるでしょうからね。



新井さんはRadditとかいう英語の掲示板サイトみたいなので情報を得ているとか。英語だけれどがんばって読んでみる価値はあるってことで。真似しようとする前に英語力を鍛えなければ……。



あるネタについて、それが信頼できるか判断する為の手段のひとつって感じの話だっけカナ?複数のメディアで流れている情報を見比べて、同じようなこと言ってるようなら大丈夫そうじゃね?……って感じかな。まあ、1次ソースに当たるのは鉄板として。



ソースに当たっても曖昧な情報しかでていないことがあるよね……って話か。インシデントの話でも「攻撃が観測されたよ」(≒攻撃高度はPrivateだよ)なのと「攻撃コードがPublicになってるよ」とでは重要度が違うよねってことだったかな。あと、ベンダーのリリースとセキュリティ問題の報告者で影響範囲が異なる場合があるよねってことで、その時は一通り試してみて影響範囲を確認するよ、と。ここら辺はプロの仕事だなって感じですね。



セキュリティ上の問題を指摘されたらどうするの?って話の流れで。検証コードを出して貰うようにお願いしましょうよ、と。たぶん、問題を報告したってことは少なくともそれを再現する情報を持ってるだろうから、自分たちの状況把握の為にも報告してきた人にお願いした方がいろいろスムーズだよね……ってことかなぁ。



数あるセキュリティに関するネタの中で、重要度とか緊急度を判断する指針のお話。だいたいこの辺りを個別に見てみて、どれくらいインパクトがあるのかを確認するとよさげですよ……と。



IEみたいな一般消費者(=非エンジニア界隈)にもわかりやすいネタの時は、テレビなどのメディアでも取り上げられるよね。でもそうすると結構な混乱が見られる場合があるよね、と。セキュリティの専門家はともかくとして、一般のエンジニアはどうしていけば良いのかと。



とりあえず、信頼できる「専門家」を事前に見つけておいて、その人達がどう言っているかってので判断するのもいいんじゃない?……って話。これは結構わかりやすくて良いよね。ボクも複数のセキュリティの専門家の人をTwitterでフォローしているから、今後悩んだときはこの基準でいろいろ考えてみようかな。



ひとつ前のと似たような話。その情報を発信している人に聞いてみるのもありじゃね?……ってお話。意外と答えてくれるらしい。迷惑にならないように……ってのは絶対条件だろうけど、覚えておくといいかも。



逆にパネリストの人たちも質問を受けることがあるとか。基本的には自分でがんばるとして、もうどうしようもなくなってダメになるようなら……。まあ、お金出せるならちゃんとその筋の人にお願いした方がいい気もするし、毎回聞いてたらアレだけど。



インタネット接続自体を止めたところもあるよ……って話で。「仕事捗っていい感じでした!」って感想があったとか。



何かあったときに各企業がリリースするお詫び文。それをコレクションしていらっしゃるとか。サイトを止めるときにはどこかに書いてあるよね、お詫び文。



Struts1の脆弱性の件。開発側からも曖昧な情報しかでてなかったりで混乱が見られたとか。受け手側でサイトを止めるにしても、止めるのか止めないのか判断する材料が必要だよね、と。



事実公表の方法等を見ても、温度差があるよねというお話。「お詫び文」のテンプレ化もありじゃね?、と。あとセキュリティ上の問題が発生した事実そのものはさておき、情報公開したことへの評価や後始末をうまくやった事へを評価するのも大切だよね。

アメリカのアメリカの国家運輸安全委員会(NTSB)や日本の航空・鉄道事故調査委員会を思い出したよ。アレも「なぜトラブルが起き、どうすれば回避できたか」ってノウハウを蓄積するのが目的で、事故を発生させた責任追及は目的外だよね。



プロはどのサイトを見ているのかという話。まあ、いろいろ見てるから「コレ!」とは言えないけど……という前置きがあって、強いて挙げるとすれば……って感じだからあくまでご参考まで。

後半戦の内容まとめ




マルウェアに感染しないのが一番。だけど、感染したら「はい、それまでよ〜」にならないようにしないとね。ある程度割り切って、感染しちゃったらどうするって所を考えるのが建設的ですな。



金のあるところに犯罪あり。オンラインバンキング辺りは狙われやすいよね、と。以前はキーロガー仕込んでID/PWを盗むってのが多かったけど、今は対策が取られてきたからキーロガーによる被害は下火だとか。



代わりに「騙す」方法が使われてますよ、と。たとえば、乱数表を全部入力させようとしたりするのは比較的有名だよね。あと、法人が狙われることも多くなってきたとか。法人の場合、取り扱う金額もBigになるだろうから、金銭的被害額も大きくなりそうだ。



実例のお話。コード署名用の証明書が盗まれて悪用された事例ってのがあちこちであるらしい。正規の署名をもつ悪意あるソフトウェアって最悪だよね。



こちらも実例の話。セキュリティを高めても、証明書の管理がナーナーなことってあるかもしれないから、気を付けないとね。



「被害」って意味だと、金銭的な話に注目しやすい。けど、それが達成されるまでに、一見無関係と思われる何かが関係していることも。前述のコード署名用証明書の話もそうだよね。何が影響するか分からないから、気を抜かないようにしないと。



パスワードの話。ユーザ側への注意喚起が広まって、パスワードに英数字混在させたり、大文字小文字や記号などを含んだ長いパスワードを利用しようとする人がいるかもしれない。けど、それをシステム側で受け付けてくれないことってあるよね。数字○桁のみとか。



ユーザ側から声を挙げて、そういったシステムの改善を促すってのもありかもしれないよ、と。アメリカでは消費者団体がサイトのそういった仕様をチェックして公表したりする動きがあるらしいとか。



Webアプリやそれを構成する技術は狙われやすいのかもね。ボクもWebアプリに携わる機会があるから気を引き締めないと。



これはしっかり認識しておきたい話題。本体よりプラグインやテーマファイルが狙いやすいってのは、根拠はないけどなんとなくボクも感じていた話だし。あと「Wordpressで作ったサイトです」って感じで製品を構成している場合もあるけど、「アップデートをどうするか」とか「このプラグインは入れても安全なのか(ちゃんとメンテされてるのか)」とかはちゃんと考えないとね。

自分がそういったサービスを使う側でも、「このサイトには何が使われているのか」ってのは気を配った方がいいね。



最新化するってのはある意味思考停止なのかもなぁ。「最新の状態」≠セキュアな状態。



ただ作れば良いってもんじゃない。作った後は運用が始まるんだ。だからそこまでしっかり考えよう。何か起こってから考えてもどうしようもないことがある。



どちらも「のびてはいけない」ってことらしいとMention貰った。ホントかどうかは知らない。あと、元ネタがあるっぽいけど、それが何かはしらない。



インシデントの種類によって初動でやるべき事はちがう。これセキュリティに限らずそうだよね。あと、窓口がなかったりすると、どこにレポートが飛んでくるかが分からない。窓口があっても窓口外にレポートが飛んでくるかも。そういったことを事前に考慮して、体制を整えておくのが吉かな。



正規のソフトウェアアップデートをしたらマルウェアに感染しちゃった!(><)って事例があるよね、と。アップデート前にPGPでチェックするとか、アップデートプログラムにそういった確認手段が入ってない場合は、そういうリスクがあるよってことはしっかり認識しておく必要がある気がした。また、そういった手段を講じていても、インシデントに繋がるリスクは常にある。前述の通り、「限界がある」のだ。



今気になってる話。某コミュニケーションツールを使って金銭をだまし取る手口が広がってるよね。サービス内で完結するもの(ポイントとかね)だったら最悪サービス提供者が身銭切れば補償できるけど、外部のプリペイド系が絡んだりするとやっかい。今後各種コミュニケーションツールで同じような事例が発生する可能性は否定できないよね。今大丈夫でも明日大丈夫かは分からないし。



詳しくないのと聞き逃してしまったので他の方のツイートを拝借。

「ネイティブアプリで気を付けるべき点はなんですか?」という質問への回答。ボクはネイティブアプリ作らない人だけど、覚えとくと安心かもね。いつ関わることになるか分からないし。この辺りって、IDEとかフレームワークとかが吸収してくれたりしてないのかな?

質疑応答、最後に一言


この辺りは力尽きて自分でツイートできなかったので他の方のツイートを拝借させていただきます。なかなか参考になることが書いてあると思うYO!















ボク的まとめ


今日の勉強会を一言でまとめるなら……



って感じ。

このエントリには含めなかったけどTwitterで「#tecomp」を検索しておくと、いろいろ有益な情報が得られると思うよ!ツイート数が膨大だけど、後でチェックしてみると良いと思う。ボクも後で読み返してみようと思ってるよ!





*1:ボクは参加してこなかったけど
*2:所々深そうな話はあったし、「開発エンジニア」向けではない話もあったけどね

0 件のコメント:

コメントを投稿