“セキュアなWebアプリ”に立ちはだかる課題 − ＠IT（情報元のブックマーク数）
開発で抑える、検査でバグを落とす、防御する、確認するという対策ですね。
Webアプリケーションの脆弱性対策は、おおむね以下のように分類できます。
“セキュアなWebアプリ”に立ちはだかる課題 (1/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
1. 開発時に脆弱性を作り込まないようにする
2. 開発後の脆弱性検査を行う
3. ネットワーク攻撃防御／検知システム（IDS／IPS／WAF）と関連サービスを利用する
4. ログ取得および関連サービスを利用する
今回は、この4点の現状をお話ししていきましょう。
やっぱりフレームワークに組み込まれるのが一番いいのかな？＞三輪節でも
セキュアプログラミングができる技術者、というスキルが明示的に個人のスキルとして示すことができないうえに、それで就職や転職に有利かというと、そこまで社会的な受け皿の機運は高まっていません。従って、技術者の中でも特に先進的な人たちだけのものになっているのも残念なことです。
“セキュアなWebアプリ”に立ちはだかる課題 (1/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
今後は、セキュアな開発の手法だけでなく、求められるセキュリティ基準の定義と評価する方法、評価主体、発注者によるセキュリティ管理コストの容認と受け入れ基準の明確化など、開発だけでなく、受発注、運用に至るまでの一連のプロセスの構築をしていかないとこの問題は根本的な解決の方向へは向かわないと考えています。
とはいえ、現在有志によってさまざまな活動が行われています。ソースコード検査による脆弱性発見のコスト削減の実証やセキュアプログラミング教育、ログの標準化への取り組みなどがやがて開発プロセスの中に自然に取り込まれていくことを願っています。
これを見て、ブラックリストor ホワイトリストと思った人はほかにもいるはずだ！！！！
ブラック・オア・ホワイト――開発後の脆弱性検査
“セキュアなWebアプリ”に立ちはだかる課題 (2/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
今のところはブラックか、グレーくらいだけど、ホワイトはツールが増えれば今後、流行るかもって感じか。
大ざっぱにいってしまうと、ブラックボックス検査はここ数年の市場の広がりの中で検査技術者も育成され、実績や経験も積まれてきたのである程度の品質とサービス価格が期待できますが、ホワイトボックス検査はこれからの市場であるので、検査ツールの熟成や技術者の育成やサービス品質の均一化、言語やセキュリティレベルのバリエーションなど、期待も大きいですが課題も多いといえるでしょう。
“セキュアなWebアプリ”に立ちはだかる課題 (2/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
IPSは止める！と言われますが、完全に誤検知無しで止めるなんて無理なので、ブラックのブラックを止めて
怪しいのはアラート、アラートがたくさん着たら止めるってのが一般的なIPSの運用スタイルかな。
これは人手と手間がかかるので、本当に大変。アウトソースしたくなるよねｗｗｗ
ここで問題となるのが、IDSやIPS、WAFそのものの性能です。本来であれば、設置すれば攻撃を止めてくれる、と期待されるものなのですが、現実はそうではないのです。ファイアウォールやウイルスゲートウェイ程度の精度を期待してはいけないのです。ここまでいうとベンダさんからおしかりや抗議を受けるかもしれませんが、少なくとも私がこれまで見てきた製品は「そのまま置けばピタリと止まる」を満足するものではありませんでした。
“セキュアなWebアプリ”に立ちはだかる課題 (2/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
また、IPSやWAFなどのインラインタイプのものは、攻撃も止めるがユーザーの正常なアクセスも止める、という障害にもつながるので、巨大なトラフィックのあるサイトでは敬遠されがちであるのも事実です。疑わしいアクセスの取り扱いは非常にセンシティブな技術です。
従って、まずは、甘めに設定しておいて実際のトラフィックを見ながら徐々に締めこんでいく、というチューニングが必要です。ユーザーのシステムは常にリニューアルされていきますから、それに追従してルールを緩めたり厳しくしたりチューニングの連続となります。これには経験を積んだベテランの技術者が対応しなければいけません。
某社の製品は、パケットを全部取ってくれましたよねぇ。そういえば神戸情報セキュリティ勉強会で取ったのをその場で見せてたな。
検索ができるのは必須ですな(何ｗ
原因究明や攻撃の有無を認識するには、攻撃である入力の生のパケットのログが最も有効なログとなります。これはサーバ自身でとるのもいいですが、現在ではネットワークに流れるパケットをレコーディングする装置の性能も上がってきたので、そのような装置を使うのも現実的なソリューションになってきています。サーバにおけるログ取得によるパフォーマンスの低下やリソースの消費にも効果があるでしょう。
“セキュアなWebアプリ”に立ちはだかる課題 (3/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
また、どれだけ被害があったかという観点では、前述のパケットログは当然ですが、ファイルへのアクセス記録やデータベースでの監査ログも重要な役割を果たします。SQLインジェクションなどの攻撃に対しては、この監査ログがなければ被害の特定ができません。またデータベースの監査ログがあればシステムとして不自然なSQL要求を検知することも可能になります
アプリケーションのログもきっちり組み込んでもらいたいですね、出力がばらばらでこまった記憶があります。
理想は一か所ですが・・・やっぱりきっちり記録してもらいたいものです。はい。
アプリケーションで抽出すべきログは開発時点で組み込まれていないと、後で組み込むのは難しいことから、「安全に作る」に加えて「安全に運用する」ということも考慮したシステムを開発してもらいたいと思いますし、発注者も「調達仕様書」のセキュリティ要件にログについての記述を必要に応じたレベルで書き込んでいただきたいと思います。
“セキュアなWebアプリ”に立ちはだかる課題 (3/3)：セキュリティ、そろそろ本音で語らないか（4） - ＠IT
