ロード・トゥ・ザ・ホワイトハッカー

ホワイトハッカーはじめました

セキュア開発

脆弱性の無い開発のために

先日、情報処理安全確保支援士のオンライン講座の単元で、「セキュア開発」というものがあった。

DXと言われる昨今、ソフトウェアの製造が増えれば、それだけ脆弱性も増える可能性がある。セキュリティのこと考えなければ、DXなんてとっくに完了して、世の中がもっと便利になっているかも。

脆弱性を見つけるために、ペネトレーションテストなどをするのでしょうが、運用時で見つかったセキュリティ対策コストは、設計時の対策コストの100倍、だそうです。

 

f:id:chikuwamaruX:20211113084149p:plain

参照:https://www.ipa.go.jp/files/000055823.pdf 

 

当然、開発の最初の段階からセキュリティを意識するはずで、
「セキュリティ・バイ・デザイン
「DevSecOps」
「シフトレフト」
など、考え方がいろいろとあって、少し混乱。

 

開発プロセスから運用まで

「DevSecOps」は「DevOps」という考え方にSecurityを含めた全体プロセス。

参照:https://www.trendmicro.com/ja_jp/business/campaigns/aws/resources/devsecops_whitepaper.html

 

具体的に、どんな開発をすれば脆弱性をもったソフトウェアを作り出さないのか?

 

こちらの資料が分かりやすかった。

www.acrosec.jp

「セキュリティ・バイ・デザイン
「継続的なハードニング」
「シフトレフト」

という3つの概念を、縦軸と横軸とで説明されていて、「継続的なハードニング」を支えるのが「DevSecOps」。

なるほど、なんとなく腹落ち。

 

開発者には、EC-Councilからこんな講座も。

www.gsx.co.jp

 

ただ、いきなり、全体プロセスが最適に回り出すはずもない。

開発者の関心である「セーフティ」と、「セキュリティ」のすり合わせから、始めるのが現実的かと思いました。

f:id:chikuwamaruX:20211113092150p:plain

参照:https://www.ipa.go.jp/files/000055823.pdf 

 

 

こんな記事もあるので、役割の分担をしながら、運用に組み込んでセキュリティを高めることを考える必要があるんでしょうね。

japan.zdnet.com

サイバーセキュリティの仕事に疲弊した人々の一部がダークサイドに落ち、自らの能力を悪用するという可能性も否定できない。