接計畫的兩三事 #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 了，沒錯，就是明天，總要想辦法在明天生出明天沒有辦法生出來的程式，這已經不是在挑戰教授的底線了，這看起來就像是在挑戰自己的極限。