攻撃者は、楽に、多くを狙います。広く使われる作りほど、公表された1つの穴が同じ作りの全サイトに効きます。スクラッチ開発と、WordPressなどのオープンソースを、攻撃する側から見て比べます。
攻撃する側は、1つの手口でいくつのサイトに届くかで狙う先を決めます。
ソースが公開され、穴も頻繁に見つかる。公表された穴に対して、更新していないサイトを自動のクローラーが数時間で一覧にします。同じ手口が何十万サイトに効くので、攻撃する側にとって最も割のいい対象です。
サイトごとに作りが違うので、手口を1つずつ作り直す必要があります。手間に対して得られる数が少なく、狙う旨味がない。構造が独自であること自体が、攻撃の対象から外れる理由になります。
WordPress周辺で見つかる脆弱性の件数と、その内訳です。
本体は守られていても、サイトは本体だけでは動きません。機能を足すためのプラグインに穴が集まり、公表された時点で修正がないものも多い。これが、広く使われるオープンソースの構図です。
本体の穴は、公表されればすぐ直ります。問題は、カスタマイズして使うことで修正パッチが「当てられないもの」に変わる、運営側の運用です。
パッチを当てるとカスタマイズ部分が動かなくなる可能性が高い。そもそも、修正パッチが出ていること自体に気がつかないケースも多い。費用をかけないとベンダーは当ててくれず、そもそも受けないこともある。結果、新しい修正が当たっていない状態で何も起きないことを祈る運用になります。攻撃する側から見て、最も狙いやすい形です。
どちらにもメリットとデメリットがあります。守りの観点で並べます。
| スクラッチ開発 | オープンソース（WordPress など） | |
|---|---|---|
| 作りの独自性 | ○サイトごとに独自。手口の使い回しが効かない | ×公開された同じ作り。1つの穴が何十万サイトに効く |
| 脆弱性の公表 | ○公開情報に載らない。クローラーの一覧に入らない | ×半年で6,700件が公表され、未更新のサイトは数時間で一覧にされる |
| 修正パッチ | △作った会社が自分の部品を直す。会社の力量に左右される | ○本体とプラグインの修正は公開される |
| カスタマイズとの相性 | ○最初から独自なので、修正と衝突しない | ×パッチを当てるとカスタマイズ部分が壊れる可能性。当てずに置く運用になりやすい |
| 機能追加の速さ | ×開発が要る。日数と費用がかかる | ○プラグインを入れれば速い |
| 初期費用 | ×高い | ○安い |
| 作れる会社 | ×設計段階からセキュリティを組める会社に限られる | ○多い。乗り換えもしやすい |
| 守りの前提 | 作った会社の知識と、納品前・定期の脆弱性診断 | 更新を続ける体制（担当者・保守契約・費用） |
| 向いている場合 | 個人情報を扱う。長く運用する。独自の機能がある | 更新する体制を持てる。情報発信が中心で、個人情報を持たない |
サーバーの層とは別に、サイトの作りそのものに対応が要ります。公開から時間が経ったサイトほど、効果があります。
公開から時間が経ったサイトほど、当時の基準で作られた部分が残っています。今あるサイトの診断と対応は、今からでも効果があります。
機能を足すたびに、新しい穴が開く可能性があります。公開前の診断だけでなく、改修のあとと、決まった間隔での定期診断が要ります。エムズでは納品前の診断を標準、公開後の定期診断と侵入監視をオプションにしています。
