仕様上、かつ既定でセキュアなソフトウェアを供給するようメーカーに求める CISAのガイダンス 31
ストーリー by nagazou
えっ 部門より
えっ 部門より
headless 曰く、
米Cybersecurity & Infrastructure Security Agency (CISA)が連邦捜査局や国家安全保障局(NSA)のほか、オーストラリア・カナダ・英国・ドイツ・オランダ・ニュージーランドのサイバーセキュリティ当局と共同で、ガイダンス「Shifting the Balance of Cybersecurity Risk: Principles and Approaches for Security-by-Design and -Default」を公開している (ニュースリリース、 VentureBeat の記事)。
ガイダンスでは顧客の手元に届いてから確認された脆弱性を修正する現在のソフトウェアは仕様上脆弱 (Vulnerable By Design) だと指摘。ソフトウェアメーカーは出荷するソフトウェアを仕様上セキュア (Secure By Design) かつ既定値でセキュア (Secure By Default)になるよう、緊急の対策が必要だという。
ソフトウェアのセキュリティは製品の開発や構成、出荷に先立つ設計プロセスに組み込む必要があり、セキュリティ対策で顧客に負担をかけることなくメーカーが責任を持つ必要があるとのこと。また、脆弱性情報の透明性確保に努めることや、セキュリティを優先する組織構造の構築なども挙げられている。
言うは易し行うはきよし (スコア:1)
日本語での解説見つけた。セキュア・バイ・デザインおよびセキュア・バイ・デフォルト [sompocybersecurity.com]
まあ、言うは易し行うは難しの典型だよね、と思いつつ、
メモリ安全性の高い言語の利用（C#、Rust、Ruby、Java、Go、Swift等）
ってあったりして、OSレスだったりハードを直接たたく必要があるときにはRustしか選択肢がなく、その場合でもunsafeだらけになるからメモリ安全とはならないよなあ、と思ったり。組み込み屋にはハードルの高いガイダンスですね。
Re:言うは易し行うはきよし (スコア:2, 参考になる)
その解説は間違っています
エンジニアを自称したいなら、この手の文章（ガイダンスとか仕様書）を正確に読み取るスキルを持つべきです。
原文は Memory safe programming languages (SSDF PW.6.1): Prioritize the use of memory safe languages wherever possible
直訳すると「可能な限りメモリセーフな言語を優先的に使用しましょう」です。
原文は、メモリ安全性の高い言語（C#、Rust、Ruby、Java、Go、Swift）から言語を選べとは言ってません。
使える場合は使いましょう、と言ってるだけです。別にC言語しか使えない状況なら、C言語を使ってもガイダンス違反にはなりません。
この手の文章を読むときは日本語は不向きです。英語の原文を読んで、mustなのかshouldなのか、wherever possibleのような句は無いか、等に注意しながら読み進めるべきです。
Re: (スコア:0)
コーディング規約のMISRA Cを思い出した。
あれも規約の意図を理解せずに守るのは無理みたいなことを言う人が居た。
MISRA Cの逸脱手続きを言語仕様で実装したのがRustのunsafeみたいな感じ。
Re: (スコア:0)
たとえばおまえらがその昔…幼き頃…捨てられて凍えている子犬を助けたことがあるとしよう…でもC言語は死ね
Re: (スコア:0)
Appleにバグのない製品をつくれぐらい難しいよなあ
どこまで要求するのだろうか。OSSまで厳格に要求されたら誰もソフトウェア開発なんてしなくなるだろう。
Re: (スコア:0)
C/C++の肩身の狭いこと。Cにもunsafe実装はよ
Re: (スコア:0)
unsafeな事するためにC/C++を選ぶんだからいらない
Re: (スコア:0)
わかってないな、safeを基本とするモードを設けるから、unsafeが要る、つまり、safeが要るっていうことだぜ
分かりません (スコア:0)
仕様上脆弱なのを仕様上セキュアにする方法がわかりません
仕様って情報処理する現実そのものを写したものでもあるし
Re: (スコア:0)
HTTPでいったらHTTPSがオプションなってるけどデフォルトでHTTPSだけ有効にして
HTTPは無効にするとかそういうこと。
Re: (スコア:0)
chromeがそれやってhttpのサイトを開こうとするとリダイレクトループにはまって開けなくなったりしてたねえ
Re: (スコア:0)
ガイダンスの内容理解してなさそう
このガイダンスの話に限定するならやらかしてんのはサイト側
わざわざHTTPSで受け付けるようにしておきながらHTTPにリダイレクトなんて仕様上脆弱でしかない
Re: (スコア:0)
> 仕様上脆弱なのを仕様上セキュアにする方法がわかりません
だから、その方法を文章化して、ガイダンスとしてpdfで無料公開しましたよ、ってニュースだよ。pdf 読めよ。
> 仕様って情報処理する現実そのものを写したものでもあるし
こういう、基礎を学んでない、教育を受けてない知ったかぶりが蔓延してるから、いつまで経っても Vulnerable By Design のままなんだろうね。
文句があるなら、まずはガイダンスを読んでね。勉強もせずに「わかりません」とか無責任すぎるよ。
Re: (スコア:0)
二度と開発企画分野で働かないでください
よろしくお願いします
Re: (スコア:0)
実装屋やってれば
PS3とか結構セキュアだったとおもう (スコア:0)
ハイパーバイザ経由のハッキング方法が見つかる前はこれといった穴が無く、重大な脆弱性もなかったのにね
バグがあってもそれを利用できない(せいぜいクラッシュするくらい)っていう高いセキュリティがあった
勝手アプリ・無署名アプリ禁止できるなら、あれくらいのセキュリティはできるはず
いまのiPhoneもなんだかんだいって高セキュリティになってる
Re: (スコア:0)
これってそんな話か？
Re: (スコア:0)
そんな話も含むと思うよ
Re: (スコア:0)
いくら仕様がセキュアでも、実装が非セキュアだと台無しだけどね。
https://ja.wikipedia.org/wiki/%E6%A5%95%E5%86%86%E6%9B%B2%E7%B7%9ADSA#... [wikipedia.org]
全部，オプトインの確認からはじめる，にすべきか (スコア:0)
ユーザーの認知/許可しない通信は原則すべて禁止すべきで，
そうなっていることを保証しなきゃならない時代になるのか
ユーザーはそんな判断できねーだろうからうちら信用してくださいよ，か。
どこか第三者が審査入れるくらいになるのか。
Re: (スコア:0)
審査する第三者（という名の特定国家/宗教/思想団体の工作員）を審査する仕組みも必要
基本が大事 (スコア:0)
まずはハードウェア、ファームウェア、OSをセキュアにしてくれないかな。
セキュリティを口実にすれば何だって許される風潮 (スコア:0)
も危険だと思うけどね。
「セキュリティのため管理サーバーと通信できなくなれば機能停止します」
「セキュリティのため出荷から3年経過したら使用不能になります」
「セキュリティのため利用者の顔情報の登録が必要です」
まずは何が目的で誰を守るためのセキュリティなのか明確にしろと思う。
Re: (スコア:0)
「会社が儲かって存続するため」という名のセキュリティでしょ。
Re: (スコア:0)
最後のはともかくまともな施策じゃん。
これの必要性が理解できてないレベルなら勉強不足だよ。
Re: (スコア:0)
最後以外の上２つはいいと思うんだけど何が「危険」なの？
Re: (スコア:0)
優先度も考えてないセキュリティって結局危険だよ。
たとえば「管理サーバーと通信できないので防犯装置の機能停止しました」とか実装したらもはや脆弱性。
コスト (スコア:0)
そのセキュリティにお金をしっかり出してくれるならいいんじゃなかろうか。
大企業とか資本も規模もあるところならいいだろうけど、中小だと厳しそう。
まぁガイダンスだし、これに従わないと違法、とかではないから気にもかけない企業も減らないかな。
官公庁と取引したいなら必須なんだろうけど。
とあるフッター曰く (スコア:0)
「科学者は100%安全だと保証できないものは動かしてはならない」、科学者「えっ」、プログラマ「えっ」