「スプラウト」を含む日記 RSS

はてなキーワード: スプラウトとは

2019-07-06

7payのセキュリティ審査って何をやってたんだろうか

ここ連日騒がれている7pay。

パスワードリセットリンク送付先のメールアドレスに対して設計上の問題脆弱性が発覚して大変な事態に発展しています

昨日の会見では社長ITリテラシ不足が露呈したり、サービス継続が表明されたりして、いわゆる「祭」の様相を呈しています

また、会見内で「セキュリティ審査実施した」と明言がされました。

https://www.asahi.com/articles/ASM745HHHM74ULFA01Y.html

セキュリティ審査実施していたにも関わらず、何故今回の問題が見逃されたのか。

非常に稚拙な推測ですが個人的に考えられる可能性をまとめてみようかなと思います

セキュリティ審査とは

その名の通り、サービスローンチ前に実施する、脆弱性問題がないか審査の事・・・だと解釈しました。

審査」というとISMS辺りを連想しちゃいますね。

一般的には脆弱性診断とかセキュリティ検査とも呼ばれています。私はこちらの呼び方の方がしっくりきます

以後脆弱性診断と記載していきます

実施した」とはいっても、どういった内容を実施たかはわかりません。

ただ、7payは「一般に公開する」「お金を扱うサービス」になるため、ガチガチ脆弱性診断を実施すべきでしょうし、実際に実施したのではないかと思います

通常、脆弱性診断というと、以下のような項目があげられると思います

抜け漏れあると思うけど、大体どこのセキュリティベンダーでも上記のような項目を診断しているんじゃないかなあと思います

詳しくは各ベンダの診断内容のページを見てみると更に詳しく載っています

LAC、CyberDefence、NRIセキュア、ブロードバンドセキュリティスプラウトなど。

ただ、今回の脆弱性診断が外部ベンダ実施されたのか、内部で実施されたのかはわかりません。

以下、推測をつらつら書いていきます

外部ベンダ発注したが、コスト削減のために対象を削りまくった

脆弱性診断はモノによりますが、診断内容をマシマシにするとエラい額が掛かります

Webサービス診断は見積もり方法が各社違ったり、ツールを使うか手動とするかによって金額も大きく変わってきます

また、数量計算ベンダによってまちまちです。ページ単位であったり、画面遷移単位であったり、SPAであればAPI単位であったり、複合での計算だったりします。

お願いすれば見積もり時にステージング環境で動いているWebサービスクロールして、各ページの評価を付けてくれるベンダもあります

規模と見積もり内容にもよりますが、100~200万といったところでしょうか。

スマホアプリ診断は一本幾らという場合が多いような気がしますね。相場としては50万~100万程度でしょうか。

プラットフォーム診断も内容によるとは思いますが、大体100万くらいかなあと思います

これ以外にWebSocketを使っていたり、別のサービス連携していたりするとその辺りの通信も含まれてくるのでまた金額は上がる可能性もあります

Webサービス200万、スマホアプリ(iOSAndroid)100万*2、プラットフォーム100万とすると、500万円掛かるわけですね。

脆弱性診断をするだけでこれだけのお金が吹っ飛んでしまうわけです。

そしてこれをそのまま発注するかと言われると、多分しないでしょう。

セキュリティお金が掛かる割にリターンが少なく、目に見える結果が必ず出てくるとも限りません。

経営層は中々首を縦には振らないでしょう。

会見でも明らかになったことですが、社長ITリテラシはあまり高そうにありません。

こうなると脆弱性診断の稟議を通すのは中々容易ではなかった可能性もありそうです。

また7月1日に間に合わせたようなところもあるっぽい(?)ので、開発側に資金を全振りしていた可能性もあり、診断に費用を掛けられなかったのかもしれません。

いずれにせよ、全く実施しないのはまずいし重要そうな部分だけピックアップして実施しましょうという話にはなるでしょう。

削れるものをあげていってみましょう。

例えば、iOSスマホアプリ実施しなくても良いかもしれません。iOS上で動くアプリは確かサンドボックス構造になっているはずで、ローカルに何かしらのデータを持っていても外部からアクセスは基本不可であるためです。確か。

そもそもスマホアプリ自体不要かもしれません。7payのサービスへのアクセスインターフェイスとしてのアプリしか提供していないのであれば、取り扱うデータほとんどないと考えられるためです。そのため、スマホアプリAndroidのみ、もしくは両方実施しなくても大きな問題は発生しないのではないかと思います

・・・この辺り私の勘違いというか、「最優先でやるべきだろjk」といった考えがあれば指摘ください。

プラットフォームも、ベンダによります実施しなくとも良いとも思います

ベンダ説明でも、主にポートスキャンをして、空いているポートに対してtelnetで色々したりするといった説明がなされたと思います

Webサービスなら443と、空いていても80くらいしか外部には公開していないので、これは実施しないという選択をしても不思議ではないと思います

サーバコンフィグも、DocumentRootがおかしいとか致命的な設定ミスをしていない限りは見てもらう必要はないでしょう。

そもそも構築手順等はノウハウもあるでしょうし、わざわざ見てもらう必要性はほとんどないわけです。

ワイドショーでは「不正海外IPからで、国外からアクセス許可していた」事が取り上げられていましたが、例えプラットフォーム診断をしていても、この辺りは指摘されなかった可能性があります

実施していればもしかしたら備考レベルでの注意や、口頭で「国内のみに留めておいた方がいいかも」といったことは伝えられたかもしれませんが、「利便性」という観点から実行されることはなかったんじゃないかなと思います

Webサービスですが、ログインログアウト処理は必須でしょう。また、新規登録情報変更、退会処理も重要です。

パスワードリセットどうでしょうか。正直これも重要です。なので、ベンダに依頼するにあたってはここも診断対象としていたはずです。

ところで今回の件では協力会社について様々な憶測が飛んでいますが、NRI説が結構人気みたいです。

ただ、NRIにはNRIセキュアというセキュリティに特化した子会社存在しています

もし脆弱性診断をするとなった場合、そこを使わないという手はあまり考えられません。そもそも発注時にそれを見越して診断費も開発の見積もりに含まれているのではないかと思います

ただし、セブン側が「脆弱性診断はこちら側で発注します」と言っていれば話は別です。

NRIセキュアは診断費用が高いらしいので、コストダウンするために別ベンダに診断部分のみ発注する可能性はあります

別のベンダ発注したことで、抜け落ちた可能性はゼロではないかもしれません。

また、NRIセキュアが実施する場合においても、「ここは抑えておいた方が良い」という機能毎やページ毎にランク付けした資料セブン側に提出することと思われますが、どこを実施してどこを削るかの最終的な判断セブンに委ねられます

考えられる事としてはパスワードリセットの処理を診断対象外としたことですが・・・そうする理由もわからないので、うーん・・・

ただ、こうして対象を削りまくることで100万程度、もしくはそれ以下まで診断費用を抑えることができます

特定ベンダと、ツールを用いた定期診断を実施してもらう契約をしていた

この可能性もあるのかなと思います

使ったことはありませんが、SecurityBlanket 365というサービス自動での定期診断が可能なようです。

ライセンスやどういった動き方をするのかはいまいちわかりませんが、ベンダ逐次依頼する脆弱性診断よりかは安く済むはずです。

ただ、自動診断となると設計上の不備やそれに伴う問題は検出できないはずです。

ツールの手が届く範囲での、XSSPoC、ヘッダの有無など、ごく一般的脆弱性診断になると考えられます

でも手軽そうで安価っぽいなので、これで済ませていても不思議ではないです。

セブン内部でツールを用いた診断を実施していた

脆弱性診断ツールOSSのものもあればベンダ販売していたり、SaaS提供しているものもあります

OSSならOWASP ZAPやw3afがWebサービスの診断が可能です。また、phpcs-security-auditなど、ソースコードを解析し脆弱な箇所がないかを診断するものもあります

ちなみにWebサービスに対する診断を「DAST」、ソースコードに対する診断を「SAST」と言ったりします。

有償のものとなると、DASTは先程のSecurityBlanket、AppScan、Nessus、Vex、VAddyが挙げられると思います

SASTになると、RIPS TECH、Contrast Securityなどでしょうか。

上記のようなツールを用いて、セブン内で脆弱性診断を実施することでセキュリティの知見を高めたり、内部で完結させるための動きを取っていたかもしれません。

こういった動きは結構色んな組織で見受けられます。外部の手を借りずに診断ができれば、関係者間の調整も楽ですし、それと比べると費用も安く済みますからね。

ただし、社内のエンジニアに任せる事になるため、片手間になってしま可能性があります

また、ツール使用方法についてのノウハウは溜まるかもしれませんが、それとセキュリティの知見が溜まるかどうかは別の問題としてあると思います

・・・とは言ってもセブンにはCSIRT部隊ちゃんとあるんですよね。

https://www.nca.gr.jp/member/7icsirt.html

『7&i CSIRT は、7&i グループCSIRT として設置され、グループ企業に対してサービス提供しています。』と記載があります

また、『7&i CSIRT は、7&i HLDGS. の組織内に専任要員を以て設置され、インシデント発生時の対応だけでなく、インシデント発生の未然防止にも注力しています

グループ企業情報システム部門と連携し、7&i グループ内で発生するインシデントに対する未然防止のための調査分析リスク情報の共有、ならびにインシデント対応活動を行なっています。』

という記載もあるため、今回の7payも、7&i CSIRTが動いてセキュリティ関連のチェックをしていたのではないかと思います。「情報システム部門」とはありますが。

組織図上にはありませんが、デジタル推進戦略本部の下か、リスクマネジメント委員会情報管理委員会のどこかに所属しているんじゃないかと思われます

日本CSIRT協議会にも名を連ねているわけですし、CSIRTメンバー専任要因ともありますし、セキュリティ関連の技術知識は十二分にあると思うんですよね。

なので、内部でツールを使って実施していたからといって、こんな重大な不備を見逃すというのはちょっと考え辛いなあ・・・と思います

会見内で言われた二段階認証検討事項に上がらなかったのかなあ・・・と。

まあ、今でも機能しているのであれば、の話ではありますが。

で、これを書いている最中に気付いたのですが以下のようなリリースが出ていたんですね。

https://www.7pay.co.jp/news/news_20190705_01.pdf

これを見ると内部のCSIRT機能していなかったか力不足判断されたかどちらかになるのかな・・・と。

実際はどうだかわかりませんけど・・・

診断を実施したがどこかで抜け落ちた

これも有り得る話かなあ・・・と。

関係者が多いと情報共有にも一苦労です。

開発やベンダCSIRT部隊情報共有したとしても、POが忘れていたとか、伝えたつもりが曖昧表現で伝わっていなかったとか・・・

ベンダ実施して指摘事項として伝えていたけど、いつの間にやら抜け落ちていてそのままサービスイン・・・というのもシナリオとしては考えられますね。

問題認識していたが上申しなかった/できなかった

7payは社内的にも一大プロジェクトだったはずで、スケジュールも決まっている場合、余計なことを物申すと手戻りや対応時間を取られることになります

そういった事を許さな空気が出来上がっていると、まあ中々上には上がってきづらいです。

これも十分にありえる話ですかね。ないといいんですけど。

セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった

どうしても『審査』という言葉に引っかかっています。『検査』ならまだわかるんですが。

そこで思ったのですが、情報セキュリティ基本方針個人情報保護方針を元にしたチェックリストのようなものセブン内にあって、それを埋めた・・・みたいなことを「セキュリティ審査」と言っていたりするのかなと思ってしまったんですね。

でもこれはセブンペイの社長個人情報保護管理責任者ということで、ISMSPMS等で慣れ親しんだ単語である審査』を使っただけかもしれません。

そもそもそれで終わらせるなんて事ないでしょう。セブン程の企業・・・

そもそもやってない

大穴ですね。いやこれはないと思いますよ。あったら大問題じゃないですか・・・

というわけで、なんとなく「こうだったりして・・・」みたいな事をつらつら書いてみました。

そういえばomni7で以下のお知らせが上がっていましたね。

https://www.omni7.jp/general/static/info190705

『定期的にパスワードを変更いただきますようお願い申し上げます。』とのことです。CSIRTはもしかしたらもう機能していないのかもしれないですね。

もしくはわかりやす対策提示しろと言われたのかもしれません。それなら仕方ないんですけど。

パスワード定期変更を推奨する因習はいつ消えるんでしょうか。

以上。

以下追記 2019-09-08

一部typoとか指摘事項を修正しました(役不足力不足 etc)。

ついでに時間経ってるけど追記します。もう誰も見ないでしょうけど。

所詮「人のつくりしもの」だよ

監査なんて取り揃えた書類通りになっているかどうかなので、監査受けているかセキュリティ的に大丈夫ってことじゃないよ

そんなに監査が万能なら監査できるくらいの人が作り出せば完璧になるはずだろ

ちゃんと読んでいただけましたか?全文通して私の主張が「監査をしっかりやれば防げた」という意味と捉えられているのでしょうか。そんなに分かりづらい文章を書いた覚えもないのですが・・・

一番上でも記載していますが、私は今回の7payの「セキュリティ審査」は、「脆弱性問題がないか審査の事」、つまり脆弱性診断」を指していると仮定して本エントリを書いています

そういう意味で、ここで私が指している「審査」と貴方が指している「監査」は似て非なるものです。字面は少し似ていますがね。

監査貴方記載する通り「ある事象対象に関し、遵守すべき法令社内規程などの規準に照らして、業務成果物がそれらに則っているかどうかの証拠収集し、その証拠に基づいて、監査対象有効性を利害関係者に合理的保証すること」です。

貴方の言う「監査」に近いことは「セキュリティ審査自体が、情報セキュリティ基本方針個人情報保護方針に沿った内容かどうかを確かめただけだった」の見出し部分で触れていますが、それで終わらせているわ このエントリーをはてなブックマークに追加ツイートシェア

2018-12-12

anond:20181212131846

ブロッコリー🥦いいですね!

ロッコスプラウトがお手軽で美味しいので、よく使います👍☺️

2018-06-28

topisyuアカウントスプラウト社員共同運営、とか言ってる人達

topisyuが元々小町やらを荒らしていた釣りだってのを知らないんだろうか。

それがただの「設定」で事実じゃないとしても、企業運営アカウント

企業サイト荒らしてた、と言う「設定」にするのはまずいだろうよ。

2016-12-08

anond:20161207220141

煮炊きすると水分が抜けてかなり食べやすくなる(=原料換算のグラム数を稼げる。煮たら容積が減るから余計原料が必要になるというのは不合理な考え方)

ソーセージハム汁物に入れる(キャベツと玉ねぎ人参コンソメスープシチュー

煮物おでん大根じゃがいもロールキャベツポトフキャベツ、玉ねぎ人参

・粉ものといっしょに食べる(お好み焼きキャベツもやし餃子ニラキャベツほうとうかぼちゃネギ

・肉といっしょにする(鍋物ネギ青菜きのこ焼肉茄子、玉ねぎキャベツもやしきのこ、芋)

・芋料理かぼちゃ料理野菜を食べたと言い張る

 

でも煮炊きした野菜ばっかり食べてると、たまにあーっレタス食べたい!生野菜足りない!となる。人間は贅沢だというわけではなく、たぶん焼く煮るでなにかが壊れたり捨ててしまうから自分は煮た野菜抜きが続くと腸にくるし、生野菜抜きが続くとこんどは胃がダメ(VCだけじゃなくキ○ベジン的な酵素とかありそう)

果物みかんりんご、なし)

レタス洋食タコスタコライスサンドイッチ

・その他肉料理の付け合せの生トマトや刻みキャベツスプラウト空芯菜の芽など)

2007-12-10

http://anond.hatelabo.jp/20071210021555

なくなるとおもうよ。

というか採算がとれない確実に。

先見の明がある農家の人はハウスを一昨年、またはその一年前の冬ぐらいら手控えてる。

今年の冬もハウスをやらなければいけない農家や、ハウスをしてしまった農家はまじめに地獄だと思う。

それどころか、今年は漁業のような事業でさえ採算がとれなくなる可能性がある。

物価転嫁するところと、LEDライトでの集魚灯みたいな設備投資をするところと分かれているみたい。

ハウスも古タイヤを買い付けてそれを燃して…なんていう設備投資をしたひとがニュースになってたけど、

付け焼刃だとおもうな。

原油はすくなくともあと半年は現況維持をするとおもうので、この冬で経済的に相当厳しい一次産業の人がでてくるとおもう。

ビニール一枚で温室を保ちつづけることがいったいどれだけエネルギーが非効率的かとも思うので、

これからは地産地消だとかいいながら運輸費を削った流通形態になるとおもうよ。

儲かるところはあまり影響がないキノコ栽培とかそこらへんで、

他はずいぶん変わるとおもうな。

葉っぱものはスプラウトとかみたいに植物のタケが小さいものだけになってしまうかも。

2007-06-22

今日の晩ご飯

冷やし中華(錦糸たまごきゅうりトマト

・新たまねぎと生揚げと九条ねぎ味噌汁

・ざる豆腐withおろし生姜

スプラウトと海藻のかりかりじゃこサラダ

こんな感じでした。

会社の人に生菓子を頂いたけど、もうおなかいっぱい。

http://anond.hatelabo.jp/20070621192133

セロリといかくんのマリネって美味しそうだね。

http://anond.hatelabo.jp/200706212

 
アーカイブ ヘルプ
ログイン ユーザー登録
ようこそ ゲスト さん