つぶやき

技術系や雑感等は再編集して本文の記事にする事を前提としているので、こっちにLinkを張らないでください。

古い記事のインデックスはこちら

セキュリティに関して思うこと

年金機構問題でつい色々書いてきたが、まぁ、自分のセキュリティ知識なんて知れている。知らないことがたくさんあるから、うまくまとまらないし、話もあっちこっちに散らばってしまうわけだ。でもまぁ、思っていることがある間に、少しずつ駄文を生産することにする。素人考えなので、専門家から異論があるかもしれないが、私の思う事をグダグタ書いてみる。

例によって、飽くまで個人の雑感なので、気に入らない人は華麗にスルーしてください。

さて、お題のセキュリティ。

本来、セキュリティという言葉は、ラテン語の「Se-(〜から離れる)」＋「cura(心配事)」から成り立っている。つまり、個人や組織などが持っている心配事から離れていくことがセキュリティの基本的なイメージと言える。

では心配事とはなんだろう？色々な考え方があると思うが、例としては「人の生き死に」や「財産や収入の毀損」など、何らかの不利益が思い浮かぶのではないだろうか？

よく考えると、この心配事は大きく分けて三つの面を持っている。それが

守るべき対象(生死や財産、収入、愛情など)
(守るべき対象に対する)不利益が起こる可能性
不利益が起こった時の影響（死ぬ、大怪我をする、財産がなくなる、振られるなど）
- この不利益が起こった時の影響を算定するために、保護対象の価値などを十分に考える必要がある。

であると私は考えている。

セキュリティを考える上で、非常に重要な言葉としてリスクというのがあるが、このリスクを私は

リスク＝不利益が起こる可能性×不利益が起こった時の影響

と考えている。もちろん、相当に単純化しているが、これで概ねの用は足りる。

さて、このリスクが「足し算(加算)」ではなく「掛け算(乗算)」である事が重要なのだ。

極端な例で考えてみよう。

もし「不利益が起こった時、その影響がない」のであれば、「不利益が起こる可能性が100%」であっても問題ない。
- なぜなら影響を被らないから。
逆に「不利益が起こる可能性が0%」ならば、「不利益が起こった時の影響が甚大」であっても問題ない。
- なぜなら、不利益が起こらないから。

もちろん、この例は極端であり、単純すぎる。なぜなら、不利益が起こる可能性が0なら、そもそもそんな事を考える必要がないし、影響がないなら、それはそもそも不利益ではない。しかし、「可能性は(非常に小さいかもしれないが)０じゃない」場合や、「影響はないわけではないが非常に小さい」場合がある。その判断ができるのは、当然、「それをリストアップしている」からであって、考えた結果として棄却できるだけであろう。

セキュリティを確保するという事は、保護する対象それぞれと、想定されるリスク、そしてリスクに対する対策を行うという事を意味するのだから、最低限この単純な考えを持っているべきであろう

ここで、自分の事を考えてみる。自分は、このようなセキュリティの確保の事をちゃんと考えているだろうか？

正直に言えば、残念ながら(少なくとも私は)ここまでいつも考えているわけではない。なぜ考えないのだろうか？

少なくとも私の場合、「守る・護る」べきものをそこまで明確に定義しているわけではない。そして、失う事を考える事自体が恐ろしいから、リスクを詳細に分析しない。

「そんな事が起こる可能性は低い」と思い込みたい
不利益が大きければ大きいほど、可能性を低く考えたい

から、リスクから目を背けてしまう。

現実の問題として、正しく準備していれば、影響を小さく、もしくは可能性を小さくする事ができるのかもしれないが、「コスト(お金や時間)がかかる」というすぐ目の前にある「小さな不利益」を大きく取り上げて、本来のリスクという「大きな不利益」に蓋をしてしまうわけだ。

この流れ、見かけた事がありませんか？自分の家族、自分の所属する組織などで。

つい風呂敷を広げてしまったが、このしばしば見かける流れの延長線上に、いわゆるITセキュリティ関係の事件が発生していると思っている。

「今そこにある危機」、それに対して「自衛する手段」、それは、この単純な考えなのではないか？そして、継続的に実施すること(できてないけど)などと思う次第であります。そして、自分の課題は、「どうやって(時々でいいから)継続的に見直すか」なのだろうと思います。

もう少し掘り下げたいと思うが、時間もないので、今日のところはこの辺で駄文を終りにします。

tweet:2015:0605_01 · 2018/07/02 19:01 · 2018/05/14 13:56

セキュリティに関して思うこと(その2)

もうしばらくセキュリティの一般的な部分に対する思うことを書いておく。

しつこいが、例によって個人の雑感なので、どう思っていただいても結構だが、気に入らない方は華麗にスルーしてほしい。

先日の記事で、リスクを

リスク＝不利益が起こる可能性×不利益が起こった時の影響

と書いた。

今回は、不利益が起こった時の影響の部分を少し書いてみる。

仮にあなたが市場価格１億円のダイヤモンドを持っているとしよう。 話を簡単にするために、このダイヤモンドは純粋に資産として持っているものであり、価値のみが評価基準だとする。このダイヤモンドを守るというのはどういうことだろうか？まず、心配事を書き出してみよう。

盗まれる
壊れる(割れる、燃えるなど)
価値が減少する

と言ったあたりが心配事の中心になるだろう。（他にも、例えば借金の担保だったり、見物料などを取っていたりするかもしれないがきりがないのでこの程度で）これらの心配事が不利益を考える上での第一歩である。

次に不利益となる事態が発生したら何が起こるのかを「盗まれる」という不利益を例に考えてみる。

ダイヤが盗まれる→１億円の資産が０になる→取り戻すために何らかの行為を行わなければならない→コストが発生→被害が拡大する
ダイヤが盗まれる→それだけの資産を持っているくせに防御が甘いと認識される→常に狙われる立場になる
ダイヤが盗まれる→盗まれた事実を知られてしまう→やっかみ等の対象にされる→人間関係が悪化する
ダイヤが盗まれる→盗まれるような体制を敷いていたお前が悪いと非難される→気分が悪い

(他にも様々あって、ここではいちいち書ききれない)

セキュリティを考える上では、「保護すべき対象」と「対象の価値」と「対象に付随する価値」をしっかり見つめる必要がある。特に、「対象に付随する価値」は、「対象の価値」と違い、時代や状況などによってしばしば大きく変化してしまうものである。そして、この「対象に付随する価値」を見極めなければ、不利益が起こった場合の影響を算定する事ができない。

ISMSやP-Markを取得する際に、必ず保護しなければならない情報のリストを作成し、機密度等を見直し、（ある程度の）価値算定を行うのは、まさにリスクを（できる限り）明確にするために必要だからである。

ベネッセの件でJIPDECがプライバシーマーク認定を剥奪した。この件で、実はJPIDECに質問を出し、回答をもらった。ここにそのまま貼るわけにもいかないので、サマリーを記載しておく。

プライバシーマーク制度委員会で審議した。
審議内容は非開示である。
取り消し措置の根拠は第15条7項による。
実覚事項および判断基準は
- 乳児を含む機微情報であり、影響が長期間継続する可能性が高い
- 社会への影響および「制度への影響が大きい」こと
- 流出した個人情報数が過去最大規模であること
ただし、各自項において閾値を「制度としては設定していない」

個人的には、このような決定を下した段階で、「プライバシーマーク制度は死んだ」と言わざるを得ない(認定を取得しても意味がないことが明確になった）と考えているが、飽くまでも個人の考えなので、異論・反論はあるだろうとは思う。

これを見て、「対象に付随する価値」というのは算定が難しいものであり、評価者次第で物凄い差が出るものであると思う。

セキュリティを考える上で、おそらく一番難しいのは、この「不利益が起こった時の影響の算定」なのだろうと思っている。なぜなら、影響を算定するための「価値」の算定根拠はどうしても主観が入らざるを得ないものであり、したがって、主観が異なってしまえば算定価値が変化してしまうからである。

結論のない、グダグダの駄文だが、思うことということでお許しいただきたい。

tweet:2015:0610_01 · 2018/07/02 19:01 · 2018/05/14 13:54

Vulsrepo on nginx with FreeBSD

NGINXは標準ではCGIを動作させることができない。そこで、fcgiwrapを利用して動かしてみる。

http://qiita.com/hmikisato/items/c793ced0ba2695a89de6を参考にした。

pkg install nginx fcgiwrap
pkg install p5-CGI p5-JSON

で、fcgiwrapの設定。rc.confに以下を記載

nginx_enable="YES"

fcgiwrap_enable="YES"
fcgiwrap_user="monitor"
fcgiwrap_socket_owner="monitor"
fcgiwrap_socket="unix:/var/run/fcgiwrap/fcgiwrap.socket"

nginx.confを以下のように編集

load_module /usr/local/libexec/nginx/ngx_mail_module.so;
load_module /usr/local/libexec/nginx/ngx_stream_module.so;

worker_processes  1;
user monitor;
events {
    worker_connections  1024;
}

http {
    include       mime.types;
    default_type  application/octet-stream;
    sendfile        on;
    keepalive_timeout  65;
    server {
        listen       80;
        server_name  localhost;

        location / {
            root   /home/monitor/htdocs/vulsrepo;
            index  index.html;
        }

	location ~ \.cgi {
		include		fastcgi_params;
		fastcgi_pass	unix:/var/run/fcgiwrap/fcgiwrap.socket;
		fastcgi_param	SCRIPT_FILENAME $document_root$fastcgi_script_name;
		root		/home/monitor/htdocs/vulsrepo;
	}

        error_page   500 502 503 504  /50x.html;
        location = /50x.html {
            root   /usr/local/www/nginx-dist;
        }
    }
}

そして、nginxとfcgiwrapを起動

# service fcgiwrap start
# service nginx start

次にvulsrepoを導入。 Document rootを/home/monitor/htdocs/vulsrepoにしてあるので、以下を実行。

mkdir -p ~monitor/htdocs/vulsrepo
chown -R monitor:staff ~monitor/htdocs

次に、vulsrepoをgithubから取得

monitor$ cd /home/monitor/htdocs
monitor$ git clone https://github.com/usiusi360/vulsrepo.git

vulsの出力を取り込む必要があるので、

monitor$ vuls scan 
monitor$ vuls report -to-localfile -format-json --cvedb-path=/home/monitor/vuls/cve.sqlite3

を実行した上で、

monitor$ cd /home/monitor/htdocs/vulsrepo
monitor$ ln -s /home/monitor/vuls/results .

これで、Browserからアクセスすれば、Vulsrepoの出力が見れるはず。

重要

vulsrepoのcgi script(vulsrepo/dist/cgi/getfilelist.cgi)は、sh-bang!形式で、先頭行に#!/usr/bin/perlと記載されている。FreeBSDの場合、perlをpkgで投入すると、#!/usr/local/bin/perlに修正する必要があるので、注意すること

あとは、毎日の更新問題だけ。以下のようなscriptをcronでdailyに動かせばOK

#! /bin/sh

##### Main Routine
. ~/.goenv.sh
DATE=`date "+%Y"`

${HOME}/go/bin/go-cve-dictionary fetchnvd -years ${DATE}
${HOME}/go/bin/go-cve-dictionary fetchjvn -years ${DATE}

# Run vuls
cd $HOME/vuls

${HOME}/go/bin/vuls scan
${HOME}/go/bin/vuls report -to-localfile -format-json --cvedb-path=${HOME}/vuls/cve.sqlite3

tweet:2017:0206_01 · 2018/07/02 19:01 · 2018/05/14 13:51

FreeBSDのWeb ServerにLet's Encryptの証明書を突っ込む

かねてからの懸案だったLet's Encrypt証明書対応のメモ。

2017/02/01現在、まだFreeBSDでの動作確認をしていないので、この記事を鵜呑みにしても動かない可能性が高い。

→ 続き...

tweet:2017:0131_01 · 2018/07/02 19:01 · 2018/05/14 13:51

pfSenseとXenServer

XenServerでpfSenseを使っていると、非常に限定された状況で、通信性能が激烈に劣化することがある。

この劣化は、以下の条件で発生することがわかっている。（ただし、これに限定されるかどうかは未確定）

同一のXenServer上に配置されているVM間での通信である
XenServer側及びVM側双方でTSO(TCP Checksum Offloading)が生きている

この条件に合致する場合に、TCP Checksumがおかしくなって性能が激烈に低下するように見える。こういう場合には、以下の設定をVM側で行えば良い

/boot/loader.conf.localを作成し、以下を記載

net.inet.tcp.tso=0
kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い

/etc/sysctl.confに以下を記載

net.inet.tcp.tso=0
kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い

加えて、rc.confなどで設定するifconfigの引数に -tso を加えると良い。自分の場合は、 -rxcsum -txcsum -tso -lro を加えている

これをpfSenseで行うには以下を実行する。

System → Advanced → System Tunables を選択
1. net.inet.tcp.tso エントリーがあれば、それを編集、なければ、「＋」をクリックして作成し、値を 0 にする
2. kern.ipc.nmbclusters エントリーがあれば、それを編集、なければ、「＋」をクリックして作成し、値を 1000000 にする
Diagnostics → Edit File を選択
1. ファイル名に /boot/loader.conf.local を指定し Load をクリック
  - 以下を記載する
```
net.inet.tcp.tso=0
kern.ipc.nmbclusters=1000000	# この行は、NICがIntel系(em等)の場合に入れておくと良い
```

これで、再起動すればOK。

なお、XenServer側からの設定に関しては、

    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-gso="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-ufo="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-tso="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-sg="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-tx="off"
    xe vif-param-set uuid=VMに割り当てられているVIFのUUID other-config:ethtool-rx="off"

とすれば良いのだが、自分の場合は面倒なので、全VMのTSO類をoffにするために以下のようなscript実行している

#! /bin/sh
# See http://cloudnull.io/2012/07/xenserver-network-tuning/
#
# for All VM's VIF NIC offloading to off.
#
for VMUUID in `xe vm-list | awk '/uuid/ {print $5}'`; do
  INSTANCEID=`xe vm-list uuid=$VMUUID | awk '/name-label/' | grep -v "Control domain" | sed 's/     name-label ( RW): //'`
  for VIFUUID in `xe vif-list vm-uuid=$VMUUID | awk '/uuid/ {print $5}' | sed '/^$/d'`; do
    echo $INSTANCEID
    xe vif-param-list uuid=$VIFUUID | grep "other-config"

    xe vif-param-set uuid=$VIFUUID other-config:ethtool-gso="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-ufo="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-tso="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-sg="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-tx="off"
    xe vif-param-set uuid=$VIFUUID other-config:ethtool-rx="off"

    xe vif-param-list uuid=$VIFUUID | grep "other-config"
  done
done

この時、XenServerのdom0側も設定したいのであれば、併せて以下のscriptを実行するのも良い。

#! /bin/sh
# See http://cloudnull.io/2012/07/xenserver-network-tuning/
#
# for All XenServer PIF NIC offloading to off
#
for PIFUUID in `xe pif-list | awk '/uuid/ {print $5}' | sed '/^$/d'`
  do
    xe pif-param-list uuid=$PIFUUID | grep "other-config"

    xe pif-param-set uuid=$PIFUUID other-config:ethtool-gso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-ufo="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tso="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-sg="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-tx="off";
    xe pif-param-set uuid=$PIFUUID other-config:ethtool-rx="off";

    xe pif-param-list uuid=$PIFUUID | grep "other-config"
done

tweet:2016:0406_01 · 2018/07/02 19:01 · 2018/05/14 13:50

<< 新しい記事 | 古い記事 >>

ほほほのほ

目次