该系列文章将通过逆向的方式分析Tesla远程api，并自己编写代码实现远程控制Tesla汽车。
0x00 简介Tesla自身的app具备控车的一些功能，如解锁、温度控制、充电、行车轨迹、召唤功能等。那么可能有朋友要问了，分析app自己实现的意义是什么呢？为什么不用官方提供的app呢？而且Github也有大量开源项目。
最开始我也有同样的疑问，但是，当我去尝试了解后，发现分析api，自己可以拓展多种玩法：
挖掘潜在的隐藏功能。在漏洞挖掘过程中，总会有一些未在界面显示，被开发者隐藏起来的一些功能。这些功能一旦被我们发现，对漏洞挖掘或者实现额外的功能都有帮助。
实现批量控车功能。官方的APP同时只能控制一台汽车，无法控制多台。我们熟悉API后，我们则可以实现批量控制汽车，实现速度与激情中的控车场景，这想想都觉得很酷；
熟悉Tesla业务流程，可以深入去挖掘漏洞；
尽管目前网络上有很多Tesla的API代码或库，但是其他的车还没有。我们以Tesla为典型例子，可以将其思路和方法拓展到其他同类的汽车厂商中；
个性化定制，通过API可以按照自己习惯定制流程，控制更加灵活。还可以拓展功能，如雨天自动关闭天窗，根据情况自动制热/冷却等。甚至可以做成一个商业产品；
通过api调用，配合代理跳板实现隐藏自身，同时不会暴漏自己的imei、设备等，减少APP信息收集导致的隐私泄漏。
记录下所有关于车的数据，进行数据分析。
這一篇是跟 Allen 在 iThome 2020 資安大會一起分享的主題。在國內，大家比較少討論資安策略這個議題。主要原因除了這個題目太過艱澀、無聊外，從商業的角度也不容易成為獲利的服務。而我們會想分享這個主題的原因與我們主要的服務「紅隊演練」有關。
執行紅隊演練三年多來，雖然協助企業找出威脅營運的重要入侵路徑，甚至發現防禦機制的不足之處，許多積極的客戶更想知道除了當次紅隊演練發現的問題外，是不是有更周延的方式來盤點防禦現況的不足。因此，我們開始尋找一個結構化且完整的方式來探究這個議題，開始思考國際標準、框架與紅隊演練之間的關係。希望除了從攻擊者的思維跟技巧找到企業的問題外，也能從防守方的角度思考企業長期而全面的防禦規劃。
複雜的問題，更要從策略面思考資安是非常複雜而且分工細膩的工作，不確定問題的核心就無法釐清權責、安排資源，遑論降低再發的機率。因此要解決這個複雜問題需要有資安策略來支撐，而不是頭痛醫頭、腳痛醫腳。首先，我們把資安的防護分為三種階段：
根據我們的觀察，幾乎多數的企業都是落在「恢復原狀型」，但企業多半認知其為「防微杜漸型」。造成這個認知上的落差，主因來自於對自身安全狀況的不了解，導致對於風險的掌握程度產生誤判。因此，透過一個宏觀的策略思考，有助於盤點各種控制措施不足之處，才有機會將防禦縱深的機制拴緊螺絲，打造期望的防禦體系。
分層負責，各司其職我們建議將縱深防禦以一個更全面的方式來檢視，分為 Executive Layer、Process Layer、Procedure Layer 以及 Technology Layer 四層，一個好的防禦策略，除了要做到 R & R (Role & Responsibility) 外，更重要的是在上而下制定策略之後，經由下而上的方式確保策略的有效性，因此不同階層的資安從業人員都有其需要關注的重點。
在說明完不同階層關注的重點後，這裡特別說明幾個重要 (或使用率較高) 的標準及框架。除了要知道哪些框架跟標準與資安有關外，同時也需要了解適用的情境、目的及彼此間的差異
實務上來說，企業的防禦策略有兩種不良的狀態
那麼要如何改善這兩種不佳的防禦狀態？我們可以單獨使用 CDM 來評估技術層的守備範圍是否足夠，也可以使用它來作為程序、流程及技術層的跨階層的盤點；
CDM (Cyber Defense Matrix) 是 OWASP 的一個專案，由一個 5x5 的矩陣所構成。橫軸是 NIST CSF 的五大類別，而縱軸則是資產盤點常見的分類；組織可以利用這個矩陣來盤點企業 Technology View 建構的防禦設備，更精準的確認需要保護的資產是否在 NIST CSF 的每個類別都有對應的措施。
以 ISO 27001 作為例子，將其本文的要求及附錄 A 的控制措施，對應到 CDM 上，進而盤點 ISO 27001 在組織的程序面所能涵蓋的範圍。要注意的是，不同組織在盤點時，會產生不同的對應結果，這正是透過 CDM 來檢視的意義所在；例如在盤點「A.7.2.2 資訊安全認知、教育及訓練」時，企業要思考對於人員的教育訓練是否涵蓋到 NIST CSF 的五大類別，還是只包含人員意識的訓練；另外以「A.6.2.2 遠距工作」的防護機制，除了針對網路層及應用程式保護外，管理程序是否也包含遠距工作的資料及設備要求？
接著，往下一層 (Procedure Layer)，也將企業現有的控制措施，對應到 CDM 中。這邊以 CIS CSC 為例，淺藍色的部份屬於基本型的控制群組、灰色部分為基礎型控制群組，組織型的控制群組因為比較偏向程序面，因此比較難單獨歸屬在特定的 CDM 區塊中。
透過真實的威脅，補足資安策略的不足在透過 CDM 盤點完 Procedure Layer 及 Process Layer 後，企業接著可以透過資安事故、威脅情資、紅隊演練或模擬入侵攻擊工具 (BAS) 等貼近真實威脅的服務或工具，來思考資安策略的不足之處。這邊我們以一個紅隊演練的部分成果作為案例，來貫穿本篇文章的應用。
在這個案例中，我們約略可以發現幾個問題：
上述的 4 個項目，是直覺在盤點時可能想到的疏漏項目。但要怎麼確認還有其他根因 (root cause) 是企業沒思考到的呢？這時候就可以利用已知的標準及框架，搭配先前盤點好的控制項目，來更為周延的思考目前還可以強化的控制措施；如果企業的資源有限，甚至可以參考 CIS CSC 對於優先權的建議順序，先確認組織實作群組 (Implementation Group) ，再依基本型、基礎型及組織型，訂定短、中、長期計畫及投放資源，有目標的改善防禦能耐。
最後，可以將上圖找出 Procedure Layer 的控制項目，對應到 Process Layer 的盤點結果，檢視流程上對應的作法。以 「14.1、依據敏感性網路進行區隔」為例，去評估 ISO 27001 中「A.6.2.2 遠距工作」的要求上，在設備、應用程式、網路、資料及使用者，是否都有做好網路區隔；或是「6.3 開啟更詳盡的日誌」，評估在 ISO 27001 中「A.16.1.5」對於資訊安全事故的回應上，在偵測、回應跟復原上，是否都有對應的程序可以支持，監控到發出的告警。
透過本篇的方法論可以從技術、程序、流程到風險，讓不同階層的資安從業人員有一致性的溝通方式。我們希望資安策略對於企業是一個真正可被實作、建立出短、中、長期目標的務實作為，而非只是一個組織治理中的一個高深名詞。