接計畫的兩三事 #1


自上一次被要求重新報告計畫要 study 的 spec,然後在報告上提出例子之後,我又在這 spec 的基礎上被要求延伸完成另外一份 spec,然而,我並不清楚「延伸」一詞用的是否洽當,或許改成「憑空生出」來的更合理一些。

我 study 的這份 spec,是一個 5G Open Radio Access Network 架構上的資安文件,裡面詳盡描述了關於 threat、attack、vulnerability 等會對哪一些 components、interfaces 造成危害,進而影響到哪些 asset,而這份 spec 又提出了一些有跟沒有一樣的建議來預防這些事,例如架構應該符合規範要求、避免使用沒有經過安全性驗證的加密格式,這種空泛廢話。

接著我就在此之上,被要求做出「應對、對策」,如何解決上述問題,也就是說,如果攻擊真的發生了,我要怎麼處理那份 spec 裡面提到的攻擊情形,並且描述對 CIARA 的影響性,最後做 test case 去驗證 → 太好了!我解決了這個漏洞!問題來了!我現在要怎麼證明現在的網路架構是安全的?

ps. CIARA = Confidentiality (保密性)、Integrity (完整性)、Availability (可用性)、Replay (重送攻擊)、Authenticity (鑑別性)。

當然囉,我既不會知道攻擊發生之後怎麼解決,也不會知道解決完後怎麼驗證這個 threat 已經被去除,我唯一知道的就是,不管橫看豎看,明天的 meeting 都會爆炸,又是我就爛的一天。

不過爛也不是一天的事了,爛完又是新的一週,意外的是 meeting 並沒有炸到連灰都不剩的地步,完成這件事的期限又多拖了一週,於是,我就這樣在教授與廠商能接受有多爛的邊緣試探。

在我把那「憑空生出」的 spec 寫好一個雛形交出去以後,我的腦子已經變成了被退貨的形狀,之前才在說別人寫的都是空泛廢話,但我寫出來的東西竟然跟它沒兩樣,雖然我跟教授說了是否有時間討論,但我在那個當下卻把訊息通知關掉,準備去吃我的飯。

一轉眼,被砲轟的會議也結束了,我馬上就關掉那需要被大改的 (?) 的 spec,當我關掉它的瞬間,笑得像是個孩子一樣,選擇性遺忘的是,距離週五的 meeting,只剩下三天。

8/20 update

那份 spec 經歷了大改之後有模有樣,取而代之的是,我被要求要將這 spec 上的某部分給實例化出來,也就是如果把這東西以程式的方式處理的話,那程式要怎麼寫,我得實現自己唬爛的東西,我連它有沒有可行性都不知道,這種東西最看 deadline 了,沒錯,就是明天,總要想辦法在明天生出明天沒有辦法生出來的程式,這已經不是在挑戰教授的底線了,這看起來就像是在挑戰自己的極限。








你可能感興趣的文章

[Week2] - JavaScript :邏輯 & 位元運算子

[Week2] - JavaScript :邏輯 & 位元運算子

資料格式的選擇:XML & JSON

資料格式的選擇:XML & JSON

Semantic segmentation 簡介

Semantic segmentation 簡介






留言討論