自動化するときに考えるべきこと3つ

自分の経験を元にメモ書き。

1. 自動化の目的は「属人性排除」「ヒューマンエラーの除去」「高速化」のいずれか、もしくは全てである

属人性排除

「この作業は○○さんしかできないから」みたいなものをなくすのが属人性排除。 これは自動化することによって作業の一部、あるいは全てをほかの人でもできるようにすることで達成される。 職場における人の入れ替わりで秘伝の技が途絶えてしまったり、引き継ぎの労力を少なくすることによって 組織としての靭性を高めることができる。 また自動化する過程で、ある人物しか理解していなかったロジックや、そもそも作業をしている本人ですら説明できないような手順や理論を解き明かし、再現性のある形へ落とし込めるという副次的な成果がある。これが手順書という形だと解釈の違いによる間違いなどが発生する可能性があるが、コードによって自動化されていることで誤解を生む可能性を極小化する。（ただし0になるわけではない）

ヒューマンエラーの除去

プログラムによって自動化された作業でも当然例外やバグによって思わぬ挙動をすることがあるが、人間も言うに及ばずしょっちゅう間違いをおこす。 しばしば「集中力が足りない」「もっと注意する」「気合」などの精神論で解決できると信じている人がいるが、個人的な経験則でいうと、どれだけ注意深く作業したとしてもだいたい最低0.01〜0.1%程度の確率でミスをする。プログラムのバグの発生も同程度、あるいはもっと高い確率かもしれないが、最大の違いは（バグ修正すれば）プログラムは同じ間違いを二度起こさないことである。人間の場合、同じ人物が同じミスをしてしまうこともあるし、作業者が入れ替わると同じミスを起こすかもしれない。

高速化

単純作業やロジックが決まっているものについては、それを得意とする機械にやらせるべきである。

2. 自動化の目的は「コスト削減」であってはならない

よく「自動化によってコストが削減されます」という言い方がされているが、だいたいの場合こういうプロジェクトは失敗する傾向が強い。 これは、この文脈ででてくる「コスト」とはすなわち「人件費」のことであり、「コスト削減」といは「人員整理・リストラ」につながるからである。 多くの場合、自動化するためには今その仕事をしている人物から作業のロジックやノウハウを教えてもらわなければならないが、 プロジェクトの最終目的がリストラだとすると、教えてもらう人たちがまさのその対象になるわけである。 これでは協力してノウハウを教えてもらうどころか、その人達が抵抗勢力になってしまうため、プロジェクトが進まなくなってしまう。

結局のところ自動化とは人間の作業を機械にやらせることになるので、コスト削減が最終目的ではないとしても少なからず上記のような問題を引き起こしやすい。ただし、以下のようなケースでは比較的スムーズにすむ。

1. 他にやるべき作業があるにも関わらず、現在は自動化対象の作業に業務時間が圧迫されている場合
2. 全てを完全に自動化できず、最終的に人間の判断などが必要な作業の場合

(1) は例えば、目先の作業に振り回されてしまって先行投資的な作業に取り掛かれていないような状況である。(2) は例えば現実世界や人物間の文脈をもとに最終的な判断しなければいけない作業だったり、一定確率でしか正解が導かれるが外した時の影響が大きいので人間が責任を負う必要があるようなケースである。こういう類のものは結果が導かれるまでの過程を正しく理解している人物が必要になるので、単純に機械を人に置き換えられるものではない。

3. 自動化は「熟練の作業者」ではなく「未熟な作業者」に対して効果が高い

なぜか自動化の話がでると「専門家（熟練の作業者）」「それ以外」という登場人物しかでてこなかったりすることが多いのだが、現実にはその中間たる「未熟な作業者」がいる。最初の目的に挙げた「属人性排除」「ヒューマンエラーの除去」「高速化」は、もちろん熟練の作業者に対しても有効だが、それ以上に「未熟な作業者」に対してはより大きい効果を生みやすい。これは作業を完全自動化するわけではなく、未熟な作業者がとりかかる一部だけでもその効果がでやすいという観点もある。（熟練の作業者の一部の作業を置き換えると、逆に効率が下がってしまうことがしばしばある）ただし、先述した判断が必要な作業などもあるため、自動化された作業について無知でよいというわけではない、ということについては注意が必要である。

コンピューターセキュリティシンポジウム2015に参加してきました

情報処理学会 コンピューターセキュリティシンポジウム(CSS)2015＠長崎に参加してきました。ちゃんぽん美味しかったです。

より実践的になっている学会

実学的な発表が多くなってきている印象でした。CSSにはマルウェア対策研究人材育成ワークショップという発表枠が含まれているのですが、ここで発表されているネットワーク侵入検知や防御、マルウェア分析などは他のコンピュータ科学の研究とくらべてもとくに実践的な内容になっていると思います。マルウェア対策技術というのは、攻撃者側のマルウェアや攻撃手法の変化が非常に早く、自分も昔指導教員に「マルウェア関連の研究で5年前というのは石器時代」と言われたことがあります。そのため研究でも数年後に芽がでるようなものではなく「今」「役立つ技術」というものが求められていると思います。

今回もそうですが、このマルウェア対策研究人材育成ワークショップ(MWS)というのは大学や企業の研究所だけでなく、セキュリティをサービスとして売っているような会社やそれこそアンチウィルスベンダの方も参加されており、こうやってデータ収集してみた、みたいな内容も多く発表されています。これはこのワークショップが始まってから徐々に広まってきた流れであり、それ以前のCSSにはなかった流れだったと記憶しています。ワークショップの委員の方もこういった実践に沿った研究活動を広めてほしいという願いがあったようで、それが形になってきているということを強く感じました。

研究は良くも悪くも機械学習的な話が多かった

自分が参加したセッションの偏りがあったからという気もしますが、とりあえずデータを機械学習に食わせて何か結果をだす、というような発表が多かったのが印象に残っています。データをいろいろな視点から扱ってみるという点では貢献があるかなと思う反面、機械学習系の研究の悪いところとしてでやすい「なぜこの手法を選んだのか」ということを論じきれていなかったり、「この結果は他の環境や実環境でも有用なのか」というようなことに対しての突っ込みが甘いものも少なくなかったように思います。

研究所から離れた自分が参加してみて

私自身が今年の4月から研究所を離れて現場（SOC）に入っているのですが、やはり現場的視点を持ってからこういう研究発表を聞くと面白いと思いました。特にMWSというのは事前に配布されるマルウェア関連のデータがあるのですが、この共通のデータをいろいろな視点で料理している研究を見ると、実際の現場でも「ああ、こういう見方や分析をして見ると何か見えてくるかもしれない」というような着想を得ることができました。

すでに多くのセキュリティ対策ベンダだけでなく大手Webサービスの方などもちらほら参加されるなど、多様な方々が集まるよい場だったと思います。研究というキーワードがあるとちょっと疎遠になってしまいますが、普段セキュリティに関わっている方ならいろいろと有益だと思いますので、参加を検討してみるとよいと思いますよ。

AWS EC2へのSSHに対する攻撃をハニーポットで分析してみた (2015年4月〜6月)

数ヶ月間、私のお小遣いを貪り続けてきたAWS EC2上のハニーポットですが、さすがに財布へのダメージが蓄積してきたのでいったん停止させました。停止させたもののそれなりにデータを蓄積していたので、さてどうしようかなと思っていたのですが、 先日、長崎で開催された情報処理学会のコンピュータセキュリティシンポジウム2015で聞いた講演の一つに SSHの新しい攻撃方法について触れられていてちょっと気になったので、収集したデータのうちSSHに関しての通信のみちょっと分析してみました。

ハニーポットの構成やデータの収集方法については過去のエントリを参照していただきたいのですが、 今回はAWS Asia Pacific (Tokyo)上でEC2のインスタンス4つを4月頭から6月末まで動かしてデータを取得しました。財布へのダメージも4倍！ しかしおかげで複数のIPアドレスで観測した時に生じる差分について知ることができました。

アクセス件数の推移

2015年4月から6月までEC2の4インスタンスで観測したSSHサーバへのアクセス件数

まずはベタに各インスタンスに対するアクセス件数を時間軸で見たものです。A, B, C, Dがそれぞれのインスタンスになりますが、 4つともアクセス件数の傾向にそれほど大きなブレ方はしていないことがわかります。これらのインスタンスが使っているIPアドレスは どこにも広告していないので基本的には全て無差別に打ち込まれている攻撃であると言えます。そのため特定の組織などに対する 攻撃とは異なるかもしれませんが、このようなアクセスは使用しているIPアドレスに関わらず、安定（？）して日々起きていることがわかります。

アクセス先ポート番号の件数

2015年4月から6月までEC2の4インスタンスで観測したSSHサーバに対するアクセス先ポート番号の件数

つづいてアクセス先ポート番号の分布です。4インスタンスの合計値から上位20件をグラフにしてみました。 当然ながらデフォルトポートである22番へのアクセスがダントツですが、それ以外にも様々なポート番号に対して アクセスが来ていることがわかります。ちなみに観測されたポート番号は合計56種類となっており、 5050、18080 などといったSSHとは全く関係なさそうなポート番号もターゲットとなっていました。

今回利用したハニーポットは特にSSHサーバを偽装するわけではなく、 アクセスしてきた接続元のホストに対してSYN-ACKを返すだけで、あとは勝手に相手が送ってくれたデータをせっせと回収します。 ではなぜ22番ポート以外もSSHだとわかったのか？というとSSHの接続確立時に相手が勝手にバナーとして SSH-2.0-PUTTY のような文字列を送ってきてくれるので、そこからSSHをターゲットにしているということがわかります。 なかにはSSH-2.0-paramiko_1.15.2やSSH-2.0-libssh2_1.4.2のように、あからさまにツール使ってますぜと宣伝してくれている やつもいたりします。 しかし先に述べたとおりこちらからは何も情報を渡していないため、相手は攻撃先がSSHサーバであるかどうかを確認などせずに22番以外の ポートに接続をしにきているということがわかります。「ポート番号を変えているからパスワード認証でも大丈夫だよね」とか 「ポートスキャンを止めているからどこがSSHのポート番号かわからないよね」と考えている管理者の方はぜひ設定の見直しをお勧めいたします。

アクセス先IPアドレスと攻撃元IPアドレスの関係

2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレスの件数（アクセス先IPアドレス毎）

それではようやく複数のインスタンスを使ってデータ収集した強みをみたいと思います。 気になることの一つとして「攻撃者はIPアドレスのレンジを舐めるように攻撃しているのでは？」ということだと思います。 実際にSSHにかぎらずport sweep（アドレスレンジに対して特定のポートが空いていないか順番に確認するタイプのスキャン）などでは そういった挙動も見られます。

上の表は各インスタンス（A, B, C, D）で観測されたかどうかと、それぞれで観測されたIPアドレスのユニークな数になります。 観測されたIPアドレスは全部で6,669件ですが、そのうちの約80%にあたる5344件の攻撃元IPアドレスがどれか一つのインスタンスでのみ 観測されているということになります。それぞれのインスタンスはある程度同じレンジにおさまっていたため、 このことから 攻撃者は近接するアドレスに対して何度も出現する可能性が高いとは言えない ということがわかります。 先ほどのポート番号に比べると直接的な対策ができるような類のものではありませんが、例えば自組織で管理されている サーバでSSHの不審なアクセス（Brute forceなど）が発生したさいに他のサーバも利用するブラックリストに追加する、 というような対策はそれほど効果的ではないかもしれません。（もちろん、残り20%は複数インスタンスで観測されているので 無意味ということはありませんが、それでも全インスタンスで観測されたアドレスは約6.5%ほどになっています）

攻撃元IPアドレス毎の接続試行回数

2015年4月から6月までEC2の4インスタンスで観測した攻撃元IPアドレス毎の接続試行回数の分布（n<10)

最後にご紹介するのが1つの攻撃元IPアドレスからやってくるSSHアクセスは何回まで試行されるか？ということをグラフにしたものです。 先述したとおり、このデータ収集はあくまでTCPセッションが確立したとみせかけてデータを送信させるだけという仕様になっているため、 本当にBrute force attackのようなパスワード試行された回数をカウントしているわけではありません。 しかし、通信状態の問題などでうまく接続できないなどのケースが考えられるため、相手がどれくらいしつこかったのかということを 知る指標にできるかと思います。

このグラフでは1つのインスタンスでのみ観測された5344件のIPアドレスに対してそれぞれのアドレスは何度接続試行したのかを ヒストグラムで表したものとなります。一番左のバーが1回だけの試行だった攻撃元IPアドレスのかたまりになるのですが、 これを見るとほとんどの攻撃元IPアドレスが試行1回目でダメそうだったらその時点で諦めているということがわかります。 このグラフは試行10回までの分布しか表示していませんが、10回以上試行してきたIPアドレスは16件だけでした。 全体的に非常に諦めがよい、ということを読み取ることができます。

しかし、ここで最初にふれた情報処理学会のコンピュータセキュリティシンポジウム2015の話に戻ってくるのですが、 富士通研究所の齊藤さんが発表された「SSHログインセンサによるSTBF(Brute Force attacks with Single Trials)の観測」において 一つのIPアドレスからパスワード試行が1回だけ実施されて、次は別のIPアドレスから試行されて、というのを繰り返すBrute force攻撃が確認されたという 事例が報告されていました。これは、一つのホストからパスワード試行を繰り返すと防御側に目立って接続拒否されたり、 共有されているブラックリストに掲載されてしまい他の環境に対しても攻撃ができなるなることを攻撃者が警戒した結果、 ボットネットのように悪性ホストを大量に所有（またはレンタル）している攻撃者が目立たないように1回だけパスワード試行をして去る、という 一撃離脱型の攻撃が連続して発生しているということだと考えられます。 この攻撃に対してはIPアドレスを基準としたパスワード試行回数制限による対策がほぼ無効化されてしまうということが言えます。

実際にこの攻撃がどのくらい世の中に蔓延しているかについては発表者の方も今後調査を継続していくとおっしゃられていましたが、 ここで紹介した分析からもそのような種類の攻撃が発生している可能性を示唆する結果となりました。 AWSでのインスタンスに限りませんが、SSHでリモートアクセスをしているホストについては 今一度設定の見直しなどをしたほうがよいかもしれません。