先進的惡意程式撰寫技術，加殼（Packing）、多型（Polymorphism）、變形（Metamorphism）、
核心等級匿蹤技術（Kernel Level Rootkit）等，會讓同一種行為的惡意程式有不同的病毒 特徵。故國內外學者在近年來皆朝著動態分析方式來萃取惡意程式的行為特徵，而不再是 靜態的二進位執行檔案之特徵。
目前分析技術可分成靜態分析（static analysis）與動態分析（dynamic analysis）兩大 類，靜態分析將能夠針對檔案的內容做檢測，希望能夠找出不應該存在於該檔案的內容，
2 算服務已出現在人們的日常生活當中，如 Gmail、Dropbox 和 Facebook 等。雲端運算是一 個根據使用者要求提供服務的模型，使用者運算和儲存的資料都可以不用放在本地端。這 也最多人使用的方式就是入侵偵測系統(Intrusion Detection System)。近幾年來已有 一些公司開始提供雲端入侵偵測的服務給使用者使用。這些服務大都是將病毒碼
3
（Kernel Level Rootkit）等，會讓同一種行為的惡意程式有不同的病毒特徵。故國內外學 者在近年來皆朝著動態分析方式來萃取惡意程式的行為特徵，而不再是靜態的二進位執行 檔案之特徵。我們將整合修改先前開發的惡意檔案檢測模組來進行一系列分析。惡意檔案 檢測系統要提供一個全面性的分析。目前分析技術可分成兩大類：一）靜態分析（static analysis）、二）動態分析（dynamic analysis）。靜態分析將能夠針對檔案的內容做檢測，希 望能夠找出不應該存在於檔案內容，或是能夠判斷該檔案是否有可疑的加殼加密行為。此 部分主要以特徵比對（signature-based）來做判斷。此外，動態分析而是直接模擬運行時的 狀態，若該檔案為可執行檔時，我們將利用已知的動態堆疊資訊取得技術，來檢測該檔案 是否在執行時期，有取得堆疊資訊的能力。由於動態分析能夠彌補靜態分析不具有執行狀 況的資訊之缺點，所以本子系統將結合兩大分析技術，已達到較完整的檔案檢測分析。
本子系統架設在一個不對外公開的區域網路之內，屬於一種「內部雲 (private cloud)」
的雲端應用。不同於國內大部分雲端系統，業者或是系統管理員只能夠提供 Hadoop 運算 的帳號，其「公開雲 (public cloud)」的系統架構並不適用於惡意樣本分析平台，原因有下 列敘述。第一點，動態程式分析不能夠利用 MapReduce 來平行化其動態分析的流程，因為 程式被執行的控制流程是相互關係的，在不同的系統狀態，即使給予相同的指令也會有不 同的結果產生，所以不能把動態程式分析分散處理。第二點，提供虛擬環境來讓租用者分
4 Facebook 團隊開發的 Cassandra 作為基礎，其讀寫速度與資料庫的大小只有常數關係，並 不會因為資料庫太大而造成寫入速度變慢。而檔案輸入介面，可包含網路爬蟲以及使用者 層。最上層的是所謂的軟體服務雲 software as a service (SaaS)。第二種型態的雲是所謂的平 台服務雲 platform as a service (PaaS)。第三種型態的雲是所謂的基礎建設服務雲
infrastructure as a service (IaaS)。
雲端毫無疑問是目前一個炙手可熱的話題。當然許多人心中一定會有的一個疑惑是如 果台灣也要切入雲端，要如何著手？ 綜觀目前市場上的成功者，我們可以發覺他們一個 共同的特點就是背後皆有強大的 infrastructure 在支撐。Google、Amazon、Salesforce 等在 世界各地均佈有規模龐大的機房。也因此台灣若想在雲端上有所斬獲，或又純粹只是不想
5
受制於人（如直接使用 Amazon 或微軟所提供的雲），那我們勢必得發展出自己的
infrastructure。有鑑於台灣本身資源有限，顯然我們不可能指望有心從事雲端發展的企業皆 各自去建設自己的 infrastructure（如 Google 有自己龐大的 infrastructure 在支撐自己其 search engine、Gmail、YouTube 等 SaaS）。也因此，發展 IaaS Cloud 以提供國內企業一個 infrastructure 應是我們的首要目標。
台灣的硬體能力舉世聞名。對於建置 IaaS 雲所需要的硬體我們有絕對的能力可以掌 握，而這也可視為我們發展 IaaS 雲的優勢之一。再者以國家安全的角度而言，掌握自身 IT Infrastructure 亦是一個沒有討價還價空間餘地的議題。而這也是為何即便 Amazon EC2 已 很成熟，微軟也在推他們的 Azure Cloud Platform，我們卻仍必需要投入力量在 IaaS Cloud 上面的研究與發展。 台，包括 Emulab、ORBIT、APE （Ad Hoc Protocol Evaluation）、Roofnet、MiNT（Miniaturized Wireless Network Testbeds）、WHYNET（Wireless HYbrid NETwork）、Netbed、
TESTBED@TWISC 等等。這些網路測試平台有些更延伸支援網路安全測試或無線網路測
6
仿真度（fiedality）：
與一般模擬測試不同，除了網路狀況之外，網路測試平台應能仿真（emulate）真 實封包傳送接收情況，包括硬體瓶頸（CPU 使用率、緩衝區大小、網路卡速度 等）。
重複性（Repeatability）：
建置網路測試平台的其中一個重要挑戰即為重現之前的實驗，包括當時的硬體配 置、網路規模、拓樸、頻寬、狀況等等。
擴增性（Scalability）：
在真實網路系統中，網路規模將隨著使用量與使用者需求逐漸增大。為了能有效 地仿真實際的網路系統，好的測試平台也應該支援規模的縮放，以期正確地取得 測試效能或正確性。
擴充性（Extensibility）：
除了傳統的乙太網路之外，各種無線網路技術也逐漸興起，並普及於大眾。為了 能提供使用者全方位的測試環境，測試平台應能支援各種不同網路技術的擴增，
如 WiFi、WiMAX、無線感測網路等等。
參考上述各設計需求，本計劃所設計之雲端安全實驗觀測網路應具備下列特性：
解決實驗互相干擾問題。
解決系統安全問題，包括惡意程式碼外流或被駭客攻擊。
能仿真真實網路，包括其硬體、作業系統與網路配置。
能重複與重現各測試實驗。
雲端安全實驗觀測網路能支援未來的規模擴充，如增加實驗節點等。
支援更多新興網路技術（WiMAX、3.5G）之擴充。
7 題。Song, Wanger, Perrig [14] 提出了一個用來解決關鍵字搜尋加密資料的方法。使用者將 資料加密儲存在不可完全信任的遠端伺服器上，接者使用者可以透過關鍵字找回其對應的 為 Regenerating code[18][19]。在修復機制中，若新增的儲存伺服器完全還原了發生錯誤的 伺服器中儲存的資料，此類的修復方法稱為 exact repair，與之相對的方法則被稱為
functional repair。Rashmi 等學者提出 exact repair 的修復機制並且證明其效率衡量值落在 regenerating code 的曲線上[20]。Shah 等人則考慮網路狀況為不對稱的系統模型進行研究 [21]。其他學者紛紛考慮不同的系統模型演化出不同修復機制[22][23][24]。若系統只能修 誤(faulty error)的存在[27]。Rashmi 等人則提出可以結合兩個容錯編碼來提供更好的修復功 能[28]。Pawar 等人討論當修復機制在執行的時候，網路上的竊聽者是否會破壞資料隱私性 的問題[29]。Papailiopoulos 與 Dimakis 則證明了在最大化資料隱私性與最小化修復網路頻 寬問題中間的對等關係[30]。無論是修復單一錯誤或者多個錯誤，我們發現到的是在效率