セキュリティ初心者のボクには見逃せない勉強会が!
「開発エンジニアのためのセキュリティ★ナイトフィーバー!! #tecomp 【Vol.08】」ってのに参加してきましたよ。事前登録は必要で名刺とアンケートへの回答が必要だけれど、無料のイベントです。懇親会も無料だそうな(*1)。
パネリストとして登壇するのはセキュリティ方面でよく見かける辻 伸弘さん、根岸 征史さん、セキュインコさん、新井 悠さんの4名の方々。
全般的に初心者でも大丈夫という触れ込み通り、一般論というか入り口部分というか比較的わかりやすい部分をテーマに話していただいたのかなーって感じ(*2)で、セキュリティ初心者のボクとしてもとても有意義な時間が過ごせました。欲を言えば、もうちょっと長いこと聞いていたかったなって感じですかね。
どんな話があったの?
ってことで、参加中にツイートされたものを読み返しながらいくつかピックアップしてみましょうか。ついでに自分の感想を書いてみたりして。
なお、各ツイートは議事録でもなければ各パネリストの方の発言を正確に書き写したものではありません。要約したり自分の理解に基づいて言葉を変更している部分があるので、各パネリストの方の真意とことなるものになってしまってるかもしれません。その辺りは他のツイートを参照したり、直接参加した人に聞いたり、パネリストの方に迷惑にならない範囲で質問するなどして、各自正確な情報の入手に勤めてください。
ボクも、各ツイートをした人も、このイベントを企画した人も、パネリストの皆さんもそこら辺は一切保障しないです。
前半戦の内容まとめ
前半は情報の収集方法や情報発信の時に気を付けること。後半はマルウェア、侵入された後の話など技術ネタ。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
今回は約1時間ちょっとのトークタイムを半分に分けて、異なるテーマでのお話となってましたね。前半も後半もなかなか興味深い内容で、これ参加できて良かったと心の底から思えるものでした。……まじ、これ、金とって言いレベルだよ。ほんと。
情報収集の方法。セキュインコさんは押し入れでドラえもん状態。TwitterとRSSリーダで情報収集してる。RSSリーダ登録は1500件!?毎日見てる!? #tecomp #人間なのはオフレコで
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
セキュインコさんがどうやって情報収集しているか……って話ですね。「押し入れの中でドラえもん状態」ってフレーズが脳内で何度もリフレイン。意外というかなんというか、TwitterやRSSリーダで情報収集してるんですね。ただ、プロジェクターで映し出された写真を見る限り、「え?これ読めるの?」ってくらいミッシリ表示されていました。いや、もう、まじ、圧巻。
あと、中の人なんていないそうです。
マウスが3ヶ月に1回壊れるスクロール量にならないと一人前になれない。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
マウスオペレーションもパネェらしく、3ヶ月に1回マウスが壊れるとか。……あれ?マウスってそんな簡単に壊れるものだっけ?
CVE番号(?)とか「ゼロデイ」などの重要キーワードをチェック。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
まあ、当然ながら情報の洪水状態になるわけで。特定のキーワードが含まれるネタがあったら「ピヨピヨ」音をならすようにするなど、いろいろ工夫をしているようです。このキーワードのチョイスってのもノウハウなんだろうなぁと思ったり。
(オフレコ) #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
そんな情報量、いつ目を通してるの?……って話のヒトコマ。オフレコだそうなので、ボクは書きません。
辻さんはPocket等に保存するときに重み付けしてる。通勤/下校時にスマートフォンでやってる。気になったらPocketに。後で読み返す。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
通勤中に気になるネタをPocketやEvernoteにつっこんでるのが辻さんのスタイルだとか。どちらのサービスも有料版契約してるらしいっす。
根岸さんは気になったら片っ端からEvernoteへ。流れでおいたいものをとりあえず保存しておいて、後で読み返す。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
根岸さんも同じようなスタイルだとか。細かい使い方は微妙に異なるっぽいですが、みんな自分がやりやすいようにいろいろ工夫してるんだなぁというのが印象。
タグが増えていくのでどうやって管理するか。いっそ管理しないというソリューション。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
こういうスタイルでやってくと、タグが増えまくるとか。表記揺れってやつですね。どう管理してるの?……って話で、「管理しない」って話が出たときは、素直に「へぇ〜」って感じでしたね。まあ、ある程度の表記揺れは工夫次第で吸収できる部分もあるでしょうからね。
情報を見るポイント。情報のソース。何を重要と判断するか。新井さんはReddit(?)を使ってる→Twitter等で流行っているかをチェック。トップダウンなフロー。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
新井さんはRadditとかいう英語の掲示板サイトみたいなので情報を得ているとか。英語だけれどがんばって読んでみる価値はあるってことで。真似しようとする前に英語力を鍛えなければ……。
セキュインコさんはソースを重視。複数組織のニュースを見て同じ情報が公開されているか。一時情報はどこかをチェック。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
あるネタについて、それが信頼できるか判断する為の手段のひとつって感じの話だっけカナ?複数のメディアで流れている情報を見比べて、同じようなこと言ってるようなら大丈夫そうじゃね?……って感じかな。まあ、1次ソースに当たるのは鉄板として。
あるソースだけ見ても影響が分からないものがある。辻さん:「危ない」といっても「攻撃が観測された」のと「攻撃コードがPublicになっているか」で判断。日本語環境で動くか、ベンダーと報告者で影響範囲の主張が違う場合は、全部やってみる。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
ソースに当たっても曖昧な情報しかでていないことがあるよね……って話か。インシデントの話でも「攻撃が観測されたよ」(≒攻撃高度はPrivateだよ)なのと「攻撃コードがPublicになってるよ」とでは重要度が違うよねってことだったかな。あと、ベンダーのリリースとセキュリティ問題の報告者で影響範囲が異なる場合があるよねってことで、その時は一通り試してみて影響範囲を確認するよ、と。ここら辺はプロの仕事だなって感じですね。
新井さん:自社のソフトウェアが指摘された場合。検証コードを出して貰う。TrendMicro社では必須。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
セキュリティ上の問題を指摘されたらどうするの?って話の流れで。検証コードを出して貰うようにお願いしましょうよ、と。たぶん、問題を報告したってことは少なくともそれを再現する情報を持ってるだろうから、自分たちの状況把握の為にも報告してきた人にお願いした方がいろいろスムーズだよね……ってことかなぁ。
セキュインコさん:悪用できるか、情報がどれだけ広がってるか、悪用されると何ができるか、攻撃方法が公開されているか、簡単に攻撃できるか、マスメディアでどうあつかわれるかなどで影響度/緊急度を判断。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
数あるセキュリティに関するネタの中で、重要度とか緊急度を判断する指針のお話。だいたいこの辺りを個別に見てみて、どれくらいインパクトがあるのかを確認するとよさげですよ……と。
IEサポート切れた直後に脆弱性が発覚。報道等を見ると本件に関して若干の混乱が生じた。MS社によりすぐに情報が公開されたので、それをソースに情報の正確性を判断。では一般エンジニアはどこまで見ていくべきか。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
IEみたいな一般消費者(=非エンジニア界隈)にもわかりやすいネタの時は、テレビなどのメディアでも取り上げられるよね。でもそうすると結構な混乱が見られる場合があるよね、と。セキュリティの専門家はともかくとして、一般のエンジニアはどうしていけば良いのかと。
辻さん:全員がそうする必要はないけど、例えば「○○さんが言ってたし」というので判断するのも有りか。間違った情報を流した後に訂正情報を目にしたらそれもちゃんと拡散するのが大切。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
とりあえず、信頼できる「専門家」を事前に見つけておいて、その人達がどう言っているかってので判断するのもいいんじゃない?……って話。これは結構わかりやすくて良いよね。ボクも複数のセキュリティの専門家の人をTwitterでフォローしているから、今後悩んだときはこの基準でいろいろ考えてみようかな。
根岸さん:専門家でも間違えることがあるが、信頼できる専門家を複数クロスチェック。
辻さん:情報発信者に凸する。結構返ってくる。たまに脅迫されることもあるけど。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
ひとつ前のと似たような話。その情報を発信している人に聞いてみるのもありじゃね?……ってお話。意外と答えてくれるらしい。迷惑にならないように……ってのは絶対条件だろうけど、覚えておくといいかも。
辻さん:ホントに困った人は聞いてくることがある。聞いてみたら意外と答えてくれるかも(みんなそれやったら大変なことになるけど) #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
逆にパネリストの人たちも質問を受けることがあるとか。基本的には自分でがんばるとして、もうどうしようもなくなってダメになるようなら……。まあ、お金出せるならちゃんとその筋の人にお願いした方がいい気もするし、毎回聞いてたらアレだけど。
辻さん:IEのとき、IE使うなを超えてInternet自体を止めたところも。Strutsの時も止めた会社いたよね。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
インタネット接続自体を止めたところもあるよ……って話で。「仕事捗っていい感じでした!」って感想があったとか。
セキュインコさん:お詫び文これくしょんしてる。お詫び文の書き方(≒止め方)もいろいろ。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
何かあったときに各企業がリリースするお詫び文。それをコレクションしていらっしゃるとか。サイトを止めるときにはどこかに書いてあるよね、お詫び文。
根岸さん:Struts、開発側から出てる情報も不足したりして受け手側が混乱することも。受け手側でのアクションがないと止めるにしても判断しようがない。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
Struts1の脆弱性の件。開発側からも曖昧な情報しかでてなかったりで混乱が見られたとか。受け手側でサイトを止めるにしても、止めるのか止めないのか判断する材料が必要だよね、と。
辻さん:パスワード大好き。パスワードオジサン。リスト型攻撃にかんして追いかけていると、その事実公表にも温度差がある。お詫び文にも「○○は書いておかないとダメだね」というテンプレが必要。情報公開したことを評価する空気。叩くだけじゃなく、リカバリへの評価重宝に思える。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
事実公表の方法等を見ても、温度差があるよねというお話。「お詫び文」のテンプレ化もありじゃね?、と。あとセキュリティ上の問題が発生した事実そのものはさておき、情報公開したことへの評価や後始末をうまくやった事へを評価するのも大切だよね。
アメリカのアメリカの国家運輸安全委員会(NTSB)や日本の航空・鉄道事故調査委員会を思い出したよ。アレも「なぜトラブルが起き、どうすれば回避できたか」ってノウハウを蓄積するのが目的で、事故を発生させた責任追及は目的外だよね。
【Q】具体的にどのサイト見てるのか。
【A】セキュメモ(セキュインコさん)、redditのnet sec(新井さん)、セキュインコさん発の情報(根岸さん)
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
プロはどのサイトを見ているのかという話。まあ、いろいろ見てるから「コレ!」とは言えないけど……という前置きがあって、強いて挙げるとすれば……って感じだからあくまでご参考まで。
後半戦の内容まとめ
実例から読み解く技術的トレンド。
辻さん:「マルウェアに感染したら地獄行き」な意気込みの人が多いが、感染手前で防ぐのには限界がある。ある程度のあきらめが肝心ではないか。それより、感染した後にどうすべきかを考えるのも重要ではないか。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
マルウェアに感染しないのが一番。だけど、感染したら「はい、それまでよ〜」にならないようにしないとね。ある程度割り切って、感染しちゃったらどうするって所を考えるのが建設的ですな。
新井さん:バンキングマルウェア話。かつてはキーロガーが主流だったが、金融機関側で対策が取られてきたのでオンラインバンキングには効かなくなってきた。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
金のあるところに犯罪あり。オンラインバンキング辺りは狙われやすいよね、と。以前はキーロガー仕込んでID/PWを盗むってのが多かったけど、今は対策が取られてきたからキーロガーによる被害は下火だとか。
新井さん:WEBインジェクション。 感染した利用者のコンピュータでオンラインバンキングへアクセス→偽画面へ誘導。だますことを目的としたものが流行ってきた(Z-BOT系)。最近は流れが変わってきていている。個人から法人にターゲットがシフト。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
代わりに「騙す」方法が使われてますよ、と。たとえば、乱数表を全部入力させようとしたりするのは比較的有名だよね。あと、法人が狙われることも多くなってきたとか。法人の場合、取り扱う金額もBigになるだろうから、金銭的被害額も大きくなりそうだ。
根岸さん:最近の事例。韓国のゲーム開発会社に侵入。ゲームコードへの署名用証明書が盗まれ悪用された事例があった。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
実例のお話。コード署名用の証明書が盗まれて悪用された事例ってのがあちこちであるらしい。正規の署名をもつ悪意あるソフトウェアって最悪だよね。
新井さん:台湾の制御系ソフト向けの証明書が盗まれた事例もあった。対岸の家事ではない。盗まれた証明書が悪用されるというのは珍しいことではなく、狙われるリスクがある。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
こちらも実例の話。セキュリティを高めても、証明書の管理がナーナーなことってあるかもしれないから、気を付けないとね。
辻さん:表面上は「不正送金」であるが、それに至るまでに自分が「無関係」であるとは言い切れない。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
「被害」って意味だと、金銭的な話に注目しやすい。けど、それが達成されるまでに、一見無関係と思われる何かが関係していることも。前述のコード署名用証明書の話もそうだよね。何が影響するか分からないから、気を抜かないようにしないと。
辻さん:記号が使えないというケースがネック。意識高くいってもシステムによっては意識高く居続けられない。ユーザの意識向上にシステム開発する側が受け入れられるようにしていった方がいいのではないか。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
パスワードの話。ユーザ側への注意喚起が広まって、パスワードに英数字混在させたり、大文字小文字や記号などを含んだ長いパスワードを利用しようとする人がいるかもしれない。けど、それをシステム側で受け付けてくれないことってあるよね。数字○桁のみとか。
根岸さん:制約があるので一般化は難しいかもしれないが、ユーザドリブンで働きかけていくのも良いのではないか。USではユーザサイドが各サイト等の仕様を洗い出してレポートを出していたりする。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
ユーザ側から声を挙げて、そういったシステムの改善を促すってのもありかもしれないよ、と。アメリカでは消費者団体がサイトのそういった仕様をチェックして公表したりする動きがあるらしいとか。
【Q】セキュリティ攻撃のターゲットになりやすい言語は?
【A】CとかよりもPHPなどがWebアプリ狙われてる様な気がする(新井さん)、事故事例等ではサーバを狙うならWeb系、クライアントならJavaやFlash等が多い(辻さん)
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
Webアプリやそれを構成する技術は狙われやすいのかもね。ボクもWebアプリに携わる機会があるから気を引き締めないと。
Wordpressが狙われる場合は、本体よりプラグインが狙われる。ベンダーサイドがワンパッケージでセットアップした為、ユーザ側が把握していない場合も。アップデートされていない、どこの馬の骨か分からないものが入ってるケースも。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
これはしっかり認識しておきたい話題。本体よりプラグインやテーマファイルが狙いやすいってのは、根拠はないけどなんとなくボクも感じていた話だし。あと「Wordpressで作ったサイトです」って感じで製品を構成している場合もあるけど、「アップデートをどうするか」とか「このプラグインは入れても安全なのか(ちゃんとメンテされてるのか)」とかはちゃんと考えないとね。
自分がそういったサービスを使う側でも、「このサイトには何が使われているのか」ってのは気を配った方がいいね。
最新化もいいけどその前に「何が入っているのか」を把握する等は重要。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
最新化するってのはある意味思考停止なのかもなぁ。「最新の状態」≠セキュアな状態。
設計段階でアップデート等を考慮していなかったり、問題発生時の手順が考慮されていないことも。開発の段階から考慮しておくべき。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
ただ作れば良いってもんじゃない。作った後は運用が始まるんだ。だからそこまでしっかり考えよう。何か起こってから考えてもどうしようもないことがある。
【Q】セキュリティとラーメンは関係ありますか?
【A】(´・ω・`)?
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
どちらも「のびてはいけない」ってことらしいとMention貰った。ホントかどうかは知らない。あと、元ネタがあるっぽいけど、それが何かはしらない。
【Q】セキュリティインシデント発生時、初動で開発エンジニアがどうするべきか
【A】インシデントの種類による。(初動からはズレるが)窓口をしっかり定め、どこの窓口に連絡がきても言いように(根岸さん)
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
インシデントの種類によって初動でやるべき事はちがう。これセキュリティに限らずそうだよね。あと、窓口がなかったりすると、どこにレポートが飛んでくるかが分からない。窓口があっても窓口外にレポートが飛んでくるかも。そういったことを事前に考慮して、体制を整えておくのが吉かな。
根岸さん:正規のソフトウィーアップデートでマルウェア感染の事例。気づきにくい。普段何気なくやってることが狙われたとき、PGPをチェックするなどしてないと気づかない。そういうことが起こりえることを頭に置いておく必要があるのではないか。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
正規のソフトウェアアップデートをしたらマルウェアに感染しちゃった!(><)って事例があるよね、と。アップデート前にPGPでチェックするとか、アップデートプログラムにそういった確認手段が入ってない場合は、そういうリスクがあるよってことはしっかり認識しておく必要がある気がした。また、そういった手段を講じていても、インシデントに繋がるリスクは常にある。前述の通り、「限界がある」のだ。
セキュインコさん:今城になってるトピック。コミュニケーションツールを使ったなりすまし事例が多発。似たような手口/手段が今後も出てくる可能性。金銭的被害あるが、正規の手順ですべて行われているので救済も困難。今後気を付けないと。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
今気になってる話。某コミュニケーションツールを使って金銭をだまし取る手口が広がってるよね。サービス内で完結するもの(ポイントとかね)だったら最悪サービス提供者が身銭切れば補償できるけど、外部のプリペイド系が絡んだりするとやっかい。今後各種コミュニケーションツールで同じような事例が発生する可能性は否定できないよね。今大丈夫でも明日大丈夫かは分からないし。
新井さん:ネイティブアプリ開発で気をつけること、ASLR を使うと DLL のロードアドレスがランダマイズされるので攻撃がやりづらくなる。なのでこれをオンにしておくのが良いと思う。攻撃側は逆にこれがオンになっていないものを探す。 #tecomp
— tss_logger (@tss_logger) 2014, 7月 30
詳しくないのと聞き逃してしまったので他の方のツイートを拝借。
「ネイティブアプリで気を付けるべき点はなんですか?」という質問への回答。ボクはネイティブアプリ作らない人だけど、覚えとくと安心かもね。いつ関わることになるか分からないし。この辺りって、IDEとかフレームワークとかが吸収してくれたりしてないのかな?
質疑応答、最後に一言
この辺りは力尽きて自分でツイートできなかったので他の方のツイートを拝借させていただきます。なかなか参考になることが書いてあると思うYO!
辻さん:セキュリティを勉強するだけじゃダメ。それ以外の範囲を勉強することも重要。独りでも多くの人に伝えていくこと。技術以外で解決していくこと重要。
#tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
セキュリティ業界に転職したい人から。みなさんはどういうきっかけで?
新井さん:新卒で就職、氷河期だった。大学ではプログラミングを専攻。学生時のアルバイトで警備員を経験、物理セキュリティ。警備員の同僚の、昼はプログラマーの人にインターネット業界を勧められた。 #tecomp
— tss_logger (@tss_logger) 2014, 7月 30
新井さん続き:でもインターネットの会社にメールで問い合わせても、返事が来ない。そのとき日経新聞で見かけた三輪さんに興味を持ってラックに問い合わせたら、人事から即返事が来たのでそこから話が進んだ。入った時点でセキュリティには経験が無く、入社後にキャリアを積んできた。 #tecomp
— tss_logger (@tss_logger) 2014, 7月 30
根岸さん:いまがインフラエンジニアなら、その経験はそのまま活かせると思う。 #tecomp
— tss_logger (@tss_logger) 2014, 7月 30
辻さん:自分は最初からセキュリティがやりたくて上京してきた。しかし構築などの仕事もやっていて、それも効いている。侵入テストがしたかったのだが、当初それほどの件数が無かったこともあり。構築する立場を考慮して診断結果を伝えられるのはメリットだった。 #tecomp
— tss_logger (@tss_logger) 2014, 7月 30
1. フレームワークの仕様を検討してください 2. フレームワークに依存しすぎないようにしてください。サポートしているレイヤーを意識して。 3.脆弱性対策をしたコードに漏れがあることもある。スーパークラスを作って継承など 4. 保全は重要。原因追求のため。 #tecomp
— riotaro okada (@okdt) 2014, 7月 30
#tecomp
質問:セキュリティエンジニアは普段コードを書いているのか?
根岸さん:製品になるようなコードは書かないが、小さなコードは書く。自分たち用のツール。
新井さん:同じ。Python を使うことが多い。
根岸さん:セキュリティ用のツールは Python が多い。
— tss_logger (@tss_logger) 2014, 7月 30
ボク的まとめ
今日の勉強会を一言でまとめるなら……
Python、覚えるか。 #tecomp
— はゃかゎゆぅた@(17年+百数ヶ月)歳 (@yuta_hayakawa) 2014, 7月 30
って感じ。
このエントリには含めなかったけどTwitterで「#tecomp」を検索しておくと、いろいろ有益な情報が得られると思うよ!ツイート数が膨大だけど、後でチェックしてみると良いと思う。ボクも後で読み返してみようと思ってるよ!
#tecomp件のツイート
!function(d,s,id){var js,fjs=d.getElementsByTagName(s)[0],p=/^http:/.test(d.location)?'http':'https';if(!d.getElementById(id)){js=d.createElement(s);js.id=id;js.src=p+"://platform.twitter.com/widgets.js";fjs.parentNode.insertBefore(js,fjs);}}(document,"script","twitter-wjs");
*1:ボクは参加してこなかったけど
*2:所々深そうな話はあったし、「開発エンジニア」向けではない話もあったけどね