クリプキクローネ日記帳

ある種の音楽と数学とランニングはミニマルなところが似ていると思う。

スポンサーサイト

上記の広告は1ヶ月以上更新のないブログに表示されています。
新しい記事を書く事で広告が消せます。
  1. --/--/--(--) --:--:--|
  2. スポンサー広告

ビューティフルセキュリティ [Andy Oram, John Viega(編), 伊藤真浩(訳)]

ビューティフルなセキュリティなんて挑戦的なタイトルですよね。



1章
学習性無力感や確証バイアスのせいでセキュリティが向上しません。という話。
心理学おもしろい。

2章
Wi-Fiの無料アクセスポイントの詐欺の典型的な例。
紛らわしい名前がついてると避けるのはなかなか難しい。

3章
セキュリティは医療に似ているというアナロジー。
健康なときはなかなか投資しようと思わないけど、
不健康になって初めてありがたさが分かる。
そしてどれくらい健康かという絶対的な指標はなく、
主観的な問診等のデータを総合的に判断するしかない。

そんな中、少しでも客観的に評価できるようにセキュリティの計測が必要。
IDとアクセスの管理と分析のできている割合、など。

ベアリングス銀行の話は知らなかったのでショックだった。
セキュリティあんま関係ない気もするけど。

4章
インターネット闇経済の構造と仕組み。
ここまで組織化されているのか…。
役割分担もはっきりしていてすごい。

5章
クレジットカード決済したときにクレジットカードの情報が多くの組織間でやりとりされ共有されてしまう、という話。
改善案の仕組みが複雑でよく分からず。

6章
オンライン広告の話。
無駄にクリックしまくって広告の価値を水増しする攻撃など。
それによって広告主は余計なお金を払わないといけないが、
広告の価値を大きく見積もりたい部門があるせいで状況が改善されない。

7章
Pretty Good Privacy(PGP)について。
権威のある認証局ではなく、個人ベースでお互いに信用の輪を広げる考え方。
PGPに限った話ではないだろうけど、暗号は戦争で使われてたせいで輸出入の話が厄介。

8章
ハニークライアント。
サーバーはセキュリティがしっかりしていることが多いので、
サーバーの脆弱性を検査するよりもクライアントの脆弱性を検査したほうがよい。
クライアントの脆弱性を検査する方法として、自分からいろんなサイトに飛んで
自分のレジストリが変なふうに変わっていないかどうかチェックするクライアントソフトのこと。

実際には正常なレジストリ書き換えも多いので判別が難しい。
でもウイルスソフトでは検出できないマルウェアを多数検出成功。
ウイルスソフトはベンダーがウイルスを見つけてもそこからバイナリのシグネチャを作るのに労力がかかるため。

9章
最近の製品やサービスは多品種小量になりつつある。(ロングテール理論)
セキュリティに求められてることもケースバイケースでそれぞれ異なってきており、
細かいカスタマイズ性が必要。
A社のウイルスソフトでB社のシグネチャを使う、というように組み合わせで運用できるようになるべき。

10章
NASAでセキュリティリスクを重要度と可能性のマトリクスで表現。
セキュリティはあとから追加するものではなく、設計段階から組み込むべし。

11章
セキュリティ強化のために新しい開発プロセスを定義した話。
セキュリティ組織によるレビューなど。
CLASP(包括的アプリケーションセキュリティプロセス)を参考にした。
精鋭メンバーを集めて研修を行い、全社に展開。
セキュリティ危険性スコアが高いプロジェクトはそれを下げなければならない。

アウトソーシングに対するセキュリティ担保はさらに困難。
開発プロセスの確認やツールによるセキュリティ危険性解析など。

12章
セキュリティ弁護士の話。
そんな専門分野あるのか…。
企業のセキュリティ対策チームに外部の弁護士を加えるべき。
なんとアメリカン!

カリフォルニア州データ保護法が画期的。
また、セキュリティ対策をどこまでやるかを判断するために
ROI(投下資本利益率)の算出が必要だが、
セキュリティの場合はリスクの発生確率と発生時の損害の積に比べて
対策への投資額が安ければやるべき、という計算ができる。
発生確率って難しいよな…。

13章
美しいログ。
という自己矛盾。
データが大きすぎたり偽陽性のデータが多すぎたりして目的のものを見つけるのは難しい。
フォーマットが統一されていないのも問題。
別々のサーバーのログを組み合わせると全貌が見えてくることがある。

ログも今後発展すれば、ただ記録を残すだけではなくて
そこに記載された異常情報から適切な処理を自動で行えるようになる、という考え方。
それってログ関係なくただのエラー処理シーケンスじゃないんだろうか…。

14章
セキュリティ事象をどうやって検出するか。
1000台のSMTPサーバーに接続するのは不審か?メールサーバーであれば不審でない。
同じデータでも環境や状況によって不審かどうかが異なる。
接続先IPアドレスが規則的に変化しているときも怪しい。
従来のログからアクセスの平均や標準偏差を出しておいて、
そこから大きく外れた挙動を不審とみなすべき。

15章
これが一番ビューティフルセキュリティだった。
データ半透過性をうまく導入しよう、という話。
とは言っても特別なことではなくて、たとえばなんらかの購入情報の氏名だけハッシュ値にしておけば、
盗まれても困らないし、売れ行きのデータ解析には何の悪影響もない。
サーバー側のパスワードの管理とかは既にこれですよね。
ただハッシュ値にしてしまうと元に戻せないので、
個人を特定してオススメ品の表示、というようなことができない。
最近の個別ユーザー狙い撃ちの流れからすると致命的。
また、データが少しでも壊れたら常識的な推測では復旧ができないのも生データとの違い。
あと意外なメリットとしてハッシュ値ならキーを均等に分布させられるので
似ている名前が集中してインデックス検索に時間がかかる、というような問題が回避できる。

セキュリティと聞くとファイアーウォールだとかアクセス権だとか暗号化だとか、
アクセスのたびにオーバーヘッドが発生するイメージだけど、
単にデータを一見無意味なものに変換する、というのは確かに一番スマート。
ハッシュさんあらためてすごい。

16章
ウイルスソフトのブラックリスト方式がいかにしんどいか、という話。
ここでもAIに期待、系。

付録
生体認証まとめ。
未来のコンビニは人がお店に入って好きなもの取ってそのまま持って帰るだけで、
入り口の生体認証が識別してくれて勝手に口座から引き落とされる。
すごい(笑)。そしてこわい。
こういうのって「こわい」という世論が強すぎてなかなか進まないだろうけど、
効果にも目を向けてある程度リスクを許容して実用化するべきと思う。



  1. 2017/12/09(土) 01:57:15|
  2. | トラックバック:0
  3. | コメント:0
<<かんたんUML入門 [改訂2版] [竹政昭利、他(著)] | ホーム | C++テンプレートテクニック 第2版 [επιστημη ,‎ 高橋晶(著)]>>

コメント

コメントの投稿


管理者にだけ表示を許可する

トラックバック

トラックバックURLはこちら
http://myumbrella.blog42.fc2.com/tb.php/389-7b454bbf
この記事にトラックバックする(FC2ブログユーザー)
上記広告は1ヶ月以上更新のないブログに表示されています。新しい記事を書くことで広告を消せます。