ありがとう。また会おう。

まぁゆるりとやっていきますよと。

2017-03-25 脆弱性ええんやでルーキーズ

security-testing.doorkeeper.jp

脆弱性ええんやで、は3度めの参戦。
今回は時間も長かったこともあって、
OWASP ZAPの基本的な使い方の部分をしっかり学べたのでよかった。

いつものごとく、memo

最初に設定しておいたほうがいい項目

■基本設定
 セーフモード
 プロテクトモード★ これに切り替えること!
 標準モード(これがデフォルト)
 ATTACKモード

 ※標準モードだと管理外サイトに診断が走ってしまう可能性があるため


■オプション
 ローカル・プロキシ
  Address
  ポート :他サービスとかぶらないよう、5桁のがお勧め
 スパイダー(クローリング)
  Maximum depth to crawl:
   スパイダーをすすめる階層の深さ。サイトの作りによって決めましょう
  並列スキャンスレッド数
   大きくすれば早くなるがマシン負荷かかる
   通常は1で大丈夫なはず
   ※逆に遅延させることはできない
    やるならfiddler噛ませて遅延させる
  他の設定はとりあえずデフォルトで大丈夫
 動的スキャン
  並列スキャンするホスト数:1にしておくことお勧め
  並列スキャンスレッド数
   大きくすれば早くなるがマシン負荷かかる
   通常は1で大丈夫なはず
  スキャン中のミリ秒単位の遅延(最大1000ms)
   サイトに負荷かけすぎないよう、遅めが良い
 ネットワーク
  「外部プロキシサーバ利用」のチェックは外す
   この設定を使うのは、ZAPを通った後の通信先にプロキシ通す場合。
   会社のプロキシとか、Fiddlerかます時とか

■ポリシー
 スキャンポリシー

■アドオン
 インストール
 アップデート
  ヘルプ→アップデートのチェック
  マーケットプレイス
   PortScannerは入れないほうが良い 上級者向け
   ActiveScannerRuleとPassiveScannerRuleはお勧め

起動時に出る「ZAPセッションの保存方法」
ZAPセッション:ZAPを通過した通信を保存するデータベースのこと
 「指定した場所と名前で保存」を選択
 「次回から表示しない」を選択してしまった場合の変更方法は
 オプション→データベースにある

Firefox
 FoxyProxyを使う場合はFirefoxのプロキシ設定は「プロキシを使用しない」にしておく ポート番号はZAPの設定と同じにする

スパイダーを始めるには
左側のツリーを右クリック
 Include TO Context >規定のコンテキスト
  コンテキストとは、その診断で対象となるドメインのこと
 でてきたダイアログはそのままOK
 ツリーのフォルダアイコンが赤い丸がつけばOK。スパイダー/診断対象となる
もういちど右クリック>攻撃>スパイダー


■LT
設計段階からセキュリティや運用を考慮
最近出た脆弱性はほぼアップデートで解決可能
運用上アップデートできる体制にする
EOLにならないような製品選択(LTS)

構築しながらの脆弱性検査

~~~~~

あと、最近みんなこの話題に触れるw

blogs.itmedia.co.jp

僕も該当するんで気をつけます^^;

2017-03-24 Vuls祭り#2

vuls-jp.connpass.com

Vuls, 以前なんかの勉強会で知って、かなり便利そうだなという印象があって
今回このMeetupがあるってことで参加しました。

発表資料は上記サイトに上がっているのでそれをみてもらうとして。

それにしてもセキュリティ界隈の方々はいろいろな意味で猛者が多いというか
自分はまだまだ底辺だな…と痛感してしまう。
もっと勉強真剣に進めないとな…

Vulsはぜひ実務でも導入してみたい。

2017-03-18 Productivity Engineering − Forkwell Meetup #4

https://forkwell.connpass.com/event/51332/

いつものごとくですが、雑なmemo。

~~~~~~~~~~~~~~~

クックパッドにおけるモバイルアプリ開発の工夫 クックパッド @ichiko_revjune

リリース間隔 2週間から1ヶ月
関わるエンジニア 10名程度
リリース間隔の最初にキックオフを実施

朝会をSlack上に移動
 (会社がフルフレックスになったこともある)
 観察に得られる情報がなくなる(順調か、疲労はなど)

■Effective Retrospective アトラクタ @ryuzee

Retrospective = ふりかえり
有名なのはKPT
目的
 ・もっとうまくできるように
 ・強制的に仕事を停止する
   忙しいときほど止まれないが止まらないと事故が起こる
   強制的にとまって冷静に考える時間を作る

ふりかえりにおける大前提=心理的安全性
 立場の上下関係、人事評価の恐怖があると本当の問題にたどり着かない
 まずはその場を安全にすること
 「あなたvsわたし」を「問題vsわたしたち」にする

アジャイルレトロスペクティブス」
 1)場を設定する
  会議の冒頭に全員に口を開いてもらうと主体的参加度が上がる傾向
  進め方を説明
 2)データを収集する
  意見だけを元にすると解決策が危うくなる
 3)アイデアを出す
 4)何をすべきかを決定する
  誰がいつまでにやるのかをはっきりする
  「拳から5本指」
 5)終了する
  記録を残す

失敗例と対策
 KPTばかりではなく、やり方を変える(タイムライン)
  KPTは断片になりがちなので、ときには全体をみる
 場所を変える

いい話を若干大げさに褒め称える
早めの時間にやる


■自己言及的なチームをつくる GMOペパボ @june29

自分たちに自覚的である、会話している
自分たちの問題を解決できるのは自分たちの行動だけ
自力で前進できると意識することも重要
いちばん難しいのは無関心
「加点方式」でチームを捉える 信頼貯金をためる
 「減点方式」チームはトラブルを隠す

自分たちの日々を自分たちでデザインする

言葉を尽くす、行動で示す
 チームにとっての良さを言葉にする
 褒める
 率先して行動する

個の価値観の押しつけはチームの価値観を壊す

Google Spreadsheet as Cron(はてな

「思考停止するな」


■最速で価値を提供する ネクスト @masamichi

狩野モデル
 魅力的品質
 性能品質
 当たり前品質

ISO/IEC25010
品質の仕様化
 言語化されない品質は作られない
「品質は誰かにとっての価値である」(Weinberg)

トレードオフではなくANDの発想(ビジョナリー・カンパニー)



ペアプログラミングの使いどころ タワーズ・クエスト @t_wada

ペアプログラミングのやりかた(大事なこと)
 喋る
  (考えを声に出す、時にはホワイトボードなどに書く)
 喜ぶ、
 交代する(例:テストを書く人と実装の人をわける)
 でかいディスプレイお勧め
 
いつ、誰とやるか
 チームに新しいメンバーが入ってきたとき
 不具合修正
 新機能作成
 日or週に一回決まった時間に

なぜやるか?
 稼働率よりスループット
 ペアプロは常にレビューを回すプロセス
 書き終えた後の指摘より書いている最中の指摘のほうが受け入れやすい
 スキル伝授にペアプロ最速
  コードを書く瞬間の思考にアドバイスを貰えるから

FAQ
 コストが倍になるのでは?
  エラーを超初期に直せる。将来の時間が省かれた形でやってくる
  現実として、コストは1倍と2倍のあいだ
 開発環境がバラバラ
  「お前のこのみとチームの成功とで大事なのはどっちだ?」(Kent Beck
 揮発性が高い
  (2人の間だけで、チームの共有にならない)
  →モブプログラミングというやり方
 上級者にメリットあるの?
  「教えることが一番の学び」教えることで知識が整理される(きのこ80)
 プレッシャーが強いから苦手
  心理的安全性が一番大事
  個人を尊重する
   全員ができるものではない


ソロプロはOSS活動に費やす

「食わず嫌いはもったいない」(塹壕からのScrumとXP)

質疑応答
 経営層への説得方法は?
 →「許可を求めるな、謝罪せよ」
  リファクタリング
  また、短時間だけ導入するのもあり
  不具合修正はペアプロで、とかも説得しやすい
   (不具合修正はチーム成長のチャンス)

2017-03-08 社内Meetupを主催した。

先週水曜日、社内Meetupを主催した。

今までうちの会社ではほとんど勉強会的なことはやっていなくて
前職では毎週勉強会みたいな会社にいた身としては
全く無いのもどうなのかなぁ・・・とずっともやもやとした思いを抱いていた。

そんな折、2月に社長も含めて社内のエンジニア集めて飲む機会があったのが
その飲み会自体、そもそも社長が
「エンジニアはコミュニケーション取れてるのか?飲んでるのか?」
という話がきっかけだったと聞いている。
で、その飲み会の中で、数名で勉強会的なことやりたいね、ということになり
今回の運びとなった。

第1回は、ちょうど Japan AWS Users Groupの祭典、JAWS DAYSが直前だったので
AWS総復習と題して、自分が喋ることにした。
スライドはこちら。

www.slideshare.net

内容は総復習っってことで、かなり上っ面部分だけになっているのと
かなり喋りでカバーしてるので、雑な作りになっているのはご容赦を。

で、実際にやってみて、こういう場は定期的にやったほうがいいな、と改めて実感した。
特にうちの会社は、今エンジニアが複数部署にわかれていて
建物も別のところにいたりするので(たいして離れた場所ではないが)
部署が違うと向こうが何してるのかわからない、みたいなことで、知識の分断が発生していて
その交流を促す意味でも、こういう場は必要だなと。
また、だからこそ「勉強会」ではなく「Meetup」というタイトルに意味を込めてて
誰かが先生になって教える、ではなく、全員が対等にコミュニケーションする場を提供したい、という思いでであった。

参加者には好評だったので、今後も2回、3回・・・と続けていきたいと思っている。
まだ、社内Meetupという位置づけだが、ゆくゆくは社外の人を呼べるような場に育てていきたい。

2017-03-11 JAWS DAYS 2017

http://jawsdays2017.jaws-ug.jp/

AWS User Group Japan の年に一度の大イベント。
昨年に続き今年も参加しました。
やはりこの熱気はすごい。
スライド見るだけではなく、現地で感じることが大事だと思う。

■赤ドクロ Presents 『AWSで開発するならこれやっときゃいいよ的な話』

EFSの話でてたけど、東京リージョンまだきてないんだよね・・・AWSさん、お願いします。

The Twelve Factor App の話。
https://12factor.net/ja/
本来はクラウドとは関係ないが、クラウドではより重要になってくるプラクティス。

DevOps はCultureが大事で、続いてPractice, Tool。

AWS SECURITY DEATH \m/ ~セキュ鮫様からのお告げ~ by Security-JAWS

Security Groupはステートフルなので戻り通信の設定は不要
Network ACLはステートレスなのでin/out両方設定が必要

Shield(DDos対策)
 CloudFrontでオプションを有効化すれば使える
 CloudFront, ELB/ALB、Route53に有効
 コスト:Basicは無料 Advancedは 300$/月
  ※DDosに該当する通信の転送量はかからない

AWS WAF
 CloudFront, ELB, ALBに仕込める
 デメリット
  正規表現でルール書けない、細かいカスタマイズが難しい
  POST通信の中身がみれない(遮断はできる)

設計段階でのセキュリティ考慮が大事

AWS Config 構成管理
 ELBはALBのみ対応。Classic ELBは非対応
 監査・コンプライアンス、トラブルシュート用途に
 コストはお安め
 AWS Config Rules
  構成管理設設定をチェックするツール
  AWSが用意するマネージドルールとLambdaで定義するカスタムルールがある
EC2 Systems Manager
 →OSの中の情報をマネージメントコンソールで確認

■コミュニティで拓く、パラレルキャリアへの道

5社で働くってすごい。。。
関係者への「期待値コントロール」大事

■知らない間に使われていませんか? ~AWSの利用監査対策~

CloudWatch Logs
CloudTrail→CloudWatch Logs連携
AWS CIS・・・不正操作の代表的なものを挙げている
オオカミ少年」にならないよう、バランスが必要

カスタム通知
CloudTrail→CloudWatch Logs→Lambda→SNS
Lambdaでメール本文を日本語化してSNSでメール送信してる

ログの集約、検索、レポート
「sumologic」を利用(AWSのパートナーになっている)
 無料枠あり
 CloudTrail、S3、ELB、Inspector等と連携
 Deep Securityのログも見れる

Bastion監査も似たような仕組みで実施
(誰がSSH接続したか、失敗形跡など)

■武闘派CIO3人が、ホンネで語るITの現実

去年も長谷川さんのトークセッション聞いたけどほんと面白い。

AmazonGoすごい。
「学び方を学ぶ」
「忍者の草飛び」
 …最初は低い草を飛ぶ、草が成長してだんだん高くなるやつ
  なんか忍者ハットリくんだか、藤子不二雄系の漫画で見た記憶ある
「客を捕まえてから新規事業提案」が鉄則
CIOはゴールキーパー的役割
同じ過ちを3回した場合と自分ごとにしない人には叱る

AWSデータベースアップデート 2017

Redis
 オリジナルではなく、Amazonが改修いれたものを使っている
 海外ではRedisに永続データを入れるケースが増えている

Aurora
 r3.xlarge以上になると、MySQLとのパフォーマンス差が顕著に
 PostgreSQL Aurora
  Performance Insight
   クエリパフォーマンスをマネージメントコンソールで見れる
   他のエンジンにも展開予定あり
 オンラインDDLが爆速(NULL許可でカラム追加の場合)
 今後のアップデート
  Online Point in Time Restore
  Database cloning
   コピーしてもボリュームコスト2倍にならない。差分分のみ増える
 Aurora Auditing
  MySQLのAuditプラグインよりパフォーマンス劣化が小さい
 Index構築も速い
 空間Indexも速い

DMS
 fan in(複数DBを1つに)、fan out(1つのDBを複数DBに)も可能
 オンプレ→AWSだけでなく、AWS→オンプレもできる
 評価レポート・・・移行のしやすさを評価したもの

Athena
 S3のファイルをSQLで直接検索
 LTSV,CSV,JSON等対応。gz圧縮対応
 裏はPrestoで動いている
 Amazon QuickSight
  S3、RDSにつないでグラフ生成。13種類

今後のリリース予定
 Amazon Glue・・・マネージドなETL

2017-03-02 GitLab Meetup Tokyo

gitlab-jp.connpass.com

こちらも参加してきました。
GitLabってぶっちゃけどのくらい使われてるのかな・・・と思ってたんですが
イベント参加者100名超えているところをみると
実はかなり使われてるっぽく、ちょっと勇気づけられた。
LT発表してたけど、結構有名な大手メーカーで使ってるってのがまた意外だった。
もっと日本語情報が充実してくると嬉しい。

以下、参加時のmemo

~~~~~

■@tnir 「GitレポジトリからCI/CD・コンテナ化を含めた開発統合プラットフォームとしてのGitLabと今後の展開」

セルフホスティングの他の製品
 GitBucket
 Gogs

GitHost.io てのもある

インストールはomubus-gitlabが一番楽

次回開催決定 4/11(火)@リクルート


■@catatsuy 「GitLabの実践的な運用」

複数台構成はきほんできない
RedisやDBは別にできる
強めのサーバおすすめ(メモリ食う)
Redisはふっとんでも問題あるデータではない。キャッシュやセッションデータのみ
mysqlはおすすめではない・・・そもそもRailsmysqlがつらい

バックアップはDBでかくなりがちなので、バックアップ別にしたほうがよい

バージョンアップ時は最低DBだけバックアップをとっておこう

■@hiroponz 「GitLabコミュニティへのコントリビュート(仮)」

近い将来多言語化するかも?

■GitLab LT
@jeffi7 「わりと大きい会社でGitLabをホスティングしてみた話」

わりとというか、かなり大手ですよね。すごい。
専門部署があるところは強いよなぁと思ったり。
(片手間でメンテするのはきつい…)

2017-02-28 第46回 脆弱性診断ええんやで

security-testing.doorkeeper.jp

前回に引き続き参加。
今回はOWASP TOP10の2番目、「認証とセッション管理の不備」

今回は本題よりも余談でちょいちょい出ていた、ほんまかいな!?的なネタが面白かった。
(いや、本題もためになったんですけどね)

その他、以下はセミナー中に取ったメモ。
あまり体系的にまとめてないけど。

~~~~~

検索キーワード
 Let’s know owasp
 工程別活用可能な資料
 OWASPの歩き方

■認証とセッション管理の不備

ASVS要件
https://jpcertcc.github.io/OWASPdocuments/ASVS/OWASPApplicationSecurityVerificationStandard3.0.pdf

無線LANが普及した結果、一般ユーザは無線LAN接続に抵抗なくなった
→キャリアや有名企業になりすましたアクセスポイントをしかけて通信を盗める
→ネットワークの盗聴、セッションIDの奪取はリスクが高まっている
 ※有線LAN前提ではネットワーク盗聴はその敷地内に侵入する必要があるので
  リスクは高くなかった

・セッションの寿命はできるだけ短く。ブラウザ閉じたら終了が望ましい

・オレオレセッションID生成はダメ、絶対。

md5ハッシュは元文字列が辞書由来の単語であれば、Googleなどで検索できてしまう

セキュリティ業界の常識として、暗号化/復号方式は公開されなければいけない
(オレオレ暗号化は遠くない先に破られる)
※狙われなければ破られないけど…

・ログイン成功したらでセッションIDを再生成する
 →攻撃者はログイン前のセッションIDを把握できる(している)ので

■LT
サイバー攻撃の被害にあった場合
・被害が明確なら、拡大防止のためサーバ隔離(クラウドなら停止)
・「情報セキュリティ事故対応ガイドブック」(IPA
・相談可能な組織
 ・ラック(緊急対応サービス「サイバー119」)
 ・三井物産セキュアディレクション
 ・アクティブディフェンス研究所
 ・オレンジセキュアサービス(トラブルレスキュー)

AWS WAFは現時点では正規表現対応してない(id=[0-9A-Za-z]+ とか)