搜尋此網誌

2010年7月29日 星期四

[教戰守則] 雲端運算安全考量

your_concerns_have_been_duly_noted_now_please_mug-p1681881732787072162otmb_400 不管安全議題是不是雲端運算日後能否蓬勃發展的主要障礙,安全議題目前確實是組織在決定是否採用雲端運算技術時最擔憂的考量。對此 Global Knowledge 發表了一份白皮書 – 10 Security Concerns for Cloud Computing,內文當中提到了在採用雲端服務前必須確認的 10 個問題。這 10 個問題分別是

  1. 資料在哪裡?(Where’s the data?)
    不同的國家或地區對於資料保護的法規與規範相當分歧,而且有些法規會限制資料所能存放或流經的地區。
  2. 誰擁有存取的權限?(Who has access?)
    內部攻擊往往導因於鬆散或錯誤的權限管理,了解授權的管理流程與控管機制可作為你判斷的依據。
  3. 有任何法規上的規範嗎?(What are your regulatory requirements?)
    法規擁有絕對的強制性,因此必須了解業務所在地與產業的法規規範,並確認採用雲端服務後可以符合相關的規範。
  4. 你是否擁有稽核的權力?(Do you have the right to audit?)
  5. 供應商對於員工的教育訓練計畫。(What type of training does the provider offer their employees?)
    人永遠是資訊安全中最脆弱的一個環節,良好的員工教育訓練除了可以減少人為的疏失,更可以增進服務的能量。
  6. 供應商採用何種資訊分類系統。(What type of data classification system does the provider use?)
    了解供應商如何對客戶的資料進行分類,又如何保護這些分類過後的資料。保護不侷限於存放中的資料,更包含保護使用與傳輸中的資料。此外,不同客戶間的資料如何隔離也是必須注意的地方。
  7. 服務水準協議的內容。(What are the service level agreement (SLA) terms?)
    所有的服務事項必須以合約為主,所以服務水準協議的內容必須明確的記載服務的範圍與各項量測數據。
  8. 供應商長期提供服務的可行性。(What is the long-term viability of the provider?)
    為避免日後轉換系統的困擾,應該盡可能找尋能夠長期合作的供應商。因為雲端服務尚屬新興市場,在缺乏足夠的歷史資料以供參考的情況下,慎選供應商顯得更形重要與困難。
  9. 發生安全事件時的處理方式。(What happens if there is a security breach?)
    雖然供應商不斷強調自身系統的安全性,但是雲端服務的系統對駭客而言依舊是一個極具吸引力的目標,更何況沒有任何的系統擁有絕對的安全,所以了解一旦發生資訊安全的問題時供應商將提供哪些協助是相當重要的課題。
  10. 災難復原與業務持續計畫。(What is the disaster recovery/business continuity plan (DR/BCP)?)
    除了了解災難與業務持續計畫的內容外,最重要的是確認其 RTO/RPO 符合你自身業務的需求。

因為雲端運算尚屬新興的業務模式,因此在導入時不管其規模大小都應該審慎評估。除此之外,所有的服務內容應該盡可能以明確的文字記載於合約之內,以保障你身為消費者的權利。

 

相關連結:

2010年7月27日 星期二

[教戰守則] 避免記憶力驚人的瀏覽器帶來機密資料的外洩

all-browser-logos

常常進行網路瀏覽的使用者一定有一個感受,那就是有很多的機會都需要填寫一些繁瑣的表格,而其中有很多基本資料 (例如姓名、電話) 甚至是不斷重複出現的。為了減少使用者的困擾,有不少相關的外掛工具可以幫助使用者自動填寫一些標準的欄位。而除了透過外掛工具外,大多數瀏覽器還內建了另外一個較為陽春的功能,就是會把之前填寫過的網頁資料記錄下來,而下次當你需要重複填寫同一個網頁時,這些資料就可以自動出現。這個功能首先由 Microsoft 所推出,稱之為 auto complete。

自動記憶曾經利用這台電腦的瀏覽器 (此例為 Chrome) 登入過 facebook 的帳號。auto complete 001

以畫面上的例子而言,瀏覽器會把使用者曾經輸入到 Facebook 電郵地址欄位的資料記憶下來,並根據使用者已經輸入的資料顯示合適的建議。這個情況出現在自己的電腦上,我相信沒有太多人會因此而感到不安。但是如果這個情況出現在一台公用的電腦上,那麼就會產生一些值得討論的議題。首先雖然以資訊安全的角度來說使用者的帳號也是需要保密的資料之一,但是對於大多數的使用者而言帳號並不是什麼極具機密的資料,儘管帳號就是自己的電郵地址亦然。也就是說以 Facebook 這個例子而言,對使用者來說往往並不會造成困擾,而且也不致於造成實際的損失。但是如果今天自動顯示的資料不是一個電郵地址,而是身分證字號、甚至是信用卡卡號呢?

好心的中華電信網頁,自動把信用卡卡號填寫出來。credit card autocomplete - cht

這個實際例子所帶來的潛在危機,我想不需要我在此多做說明。要避免這類問題的產生,系統開發商負有絕對的責任。因為 auto complete 在不同的瀏覽器之間有不同的行為,所以要有效地避免此一問題就必須採用多管齊下的方式。建議作法如下:

  1. 關閉 auto complete 的功能。此一功能可以透過在 text 或 password 輸入元件內加上 autocomplete=”off” 的參數加以關閉。此外也可以透過在 form 加上 autocomplete=off 的參數關閉單一 form 內所有 text 與 password 輸入元件的 auto complete 功能。
  2. 關閉網頁的 cache。這裡指的是利用 HTTP 標頭的方式告知瀏覽器不要將此一網頁存放至快取內。
  3. 採用加密的 (SSL)方式。

我以一個簡單的 PHP 程式為例,這個程式採用上述的建議以避免瀏覽器將使用輸入姓名 (username)、電話 (telephone) 與密碼 (password) 三個欄位內的資料加以記憶以供日後自動輸入。

<?php
    if ($_SERVER['HTTPS']!="on") {
       $url = "https://".
              $_SERVER['SERVER_NAME'].
              $_SERVER['REQUEST_URI'];
       header ("Location: $url");
       exit;
    }
    header("Expires: Tue, 03 Jul 2001 06:00:00 GMT");
    header("Last-Modified: ".gmdate("D, d M Y H:i:s")." GMT");
    header("Cache-Control: no-store, no-cache, must-revalidate, private");
    header("Cache-Control: post-check=0, pre-check=0", false);
    header("Pragma: no-cache");
?>
<html>
<head>
<title>Auto Complete Defend Demo</title>
</head>
<body>
<form action="foo.php" action="POST" autocomplete="off">
Name: <input type="text" name="username"><br/>
Tel: <input type="text" name="telephone"><br/>
Password: <input type="password" name="password"><br/>
<input type="submit">
</form>
</body>
</html>

雖然說解決此一問題是系統開發商的責任,但是身為一個使用者卻不應該把自身資料的安全全然交由廠商來保護。使用者可以採用下列步驟來保護自己:

  • 盡量避免利用公用電腦 (或他人的電腦) 存取重要的網路服務。
  • 利用主流瀏覽器所提供的私密瀏覽功能來存取重要的網路服務。這個保護措施不但在使用公用電腦 (或他人的電腦) 時相當實用,就連使用自己的電腦時也可以採用。畢竟要永遠限制其他人無法存取到你的電腦可說是一件不可能的任務。
  • 在使用一些自動幫助填寫表格的外掛工具時請小心評估哪些資料可以記憶,那些又不該記憶。

雖然這類問題因為無法在遠端發動攻擊與有效地自動化,所以並不容易產生大規模的資料外洩事件。但是對於使用者而言,保護自身資料的私密性絕對是責無旁貸的責任。因為就算只有一筆資料外洩,只要那是你的資料,對你而言就是再嚴重不過的事情了。

2010年7月26日 星期一

[新聞時事] WPA2 被發現存在安全漏洞

wifi_logo

在無線區域網路 (Wi-Fi) 當中,安全性的問題一直是一個令人坐立難安的課題。從 WEP 可以在數分鐘之內被破解,再到有人將破解 WPA 變成雲端服務,WPA2 是目前在理論與實務上能夠有效保護 Wi-Fi 的唯一協定。然而就像所有的系統都無法永遠保證其安全性一樣,已經有資訊安全研究員宣稱找到 WPA2 的漏洞,可以用來進行中間人攻擊 (Man-in-the-Middle Attack)。此次被發現的漏洞被稱之為 ‘Hole 196’,而 ‘Hole 196’ 並不是導因於實作上的錯誤,也不是加密演算法出問題,而是在於規範本身的定義。也因為問題出在規範本身,所以目前 (甚至在可見的未來) 並沒有任何方式可以用來避免這個問題的產生。唯一的好消息是要利用這個漏洞發動中間人攻擊之前,攻擊者必須先通過無線網路的驗證,也就是說通過授權的內部使用者最有可能利用這個漏洞進行攻擊。發現 ‘Hole 196’ 的研究員預計將於 Black Hat Arsenal 與 DEF CON 18 發表演說,並介紹更多相關的細節。

 

相關連結:

2010年7月25日 星期日

[從電影看資安] 市話可不是只有便宜 - 明天過後

明天過後 是一部以地球氣候變遷為主軸的災難電影。這類災難電影免不了都要來段冒著生命危險拯救親人的感人劇情,而這次選定的是父親冒著大風雪前往搭救兒子的戲碼。男主角的兒子山姆因為參加校際機智問答比賽而前往紐約,沒想到剛好遇上災難性氣候轉變,洪水加上暴風雪讓整個北方區域成為重災區,而山姆與一大群人則被困在紐約的圖書館當中。在所有無線通訊都無法使用的情況下,山姆想到利用傳統的有線電話與男主角取得聯繫,不但順利報了平安,更讓男主角知道要去哪裡解救親愛的兒子…

身為男主角,即使職業是教授同樣可以擁有矯健的身手。vlcsnap-2010-06-29-16h42m12s164

男主角在最後一刻終於趕到並載送兒子山姆前往機場。vlcsnap-2010-06-29-16h44m30s3

山姆的小組所向披靡,得到最高分。 vlcsnap-2010-06-29-19h46m15s14

好日子沒有多久,海嘯來了。每次世界末日都會毀損一次的自由女神再次在劫難逃,被強力海嘯所襲擊。vlcsnap-2010-06-29-16h47m14s56

海嘯襲擊到整個陸地。vlcsnap-2010-06-29-16h47m53s5

山姆心儀的同學在慌忙之中發現海嘯來襲,急忙回頭逃進圖書館。vlcsnap-2010-06-29-16h48m38s191

山姆的對手一起落難,想要用手機聯絡弟弟卻無法連線。vlcsnap-2010-06-29-16h50m20s193

還好圖書館還有舊式有線電話,山姆順利與父親取得聯繫。vlcsnap-2010-06-29-16h50m41s146

行動電話的方便與普及,讓透過行動電話與人進行聯繫成為許多人的首選。除了朋友之間大量使用行動電話外,行動電話在商務上的應用也越趨廣泛。好在大多數商務名片都還印有傳統有線電話的聯絡方式,所以在商務應用上有線電話依舊佔有一席之地。但是除了一般正常工作時間的聯繫外,在商務上還有許多非工作時間的緊急聯繫需要進行。系統當機時找尋 On-call 的值班人員、災難發生時聯繫緊急應變小組的成員、或是臨時發生需要主管權限才能決定的緊急事件,都屬於這類情況。

為了因應這些突發的狀況,每個公司都會有所謂的緊急聯絡清單 (就算沒有緊急聯絡清單也至少會有通訊錄)。在資訊安全方面常見的會有兩個清單,一個是資安事件發生時的應變小組人員聯絡清單,另外一個則是災難發生時的應變小組聯絡人員。不管是哪種狀況,當發生問題時大家的第一個反應就是撥打行動電話,但是萬一透過行動電話無法取得聯繫…完了,因為清單上只載明行動電話的號碼。或許我們可以假設在正常的情況下,無線通訊出錯的機會相當低,所以只保留行動電話的聯絡方式還情有可原。但是當談到發生災難時,無線通訊是否還能保持暢通可就有值得探討的空間,也因此災難應變小組人員的聯絡方式不應該只有行動電話號碼,更應該包含傳統有線電話的號碼。至於這樣做會不會導致公私不分,那倒也是太多慮了,因為災難應變小組人員的名單必須受到嚴格的管制,並不像一般通訊錄是公開的,所以不會發生半夜有人打電話來問安的惡作劇。或許這只是一件小事,但是當災難發生時,任何小細節都有可能成為成敗的關係。「有備無患」準沒錯,老祖宗已經告訴過我們了。

2010年7月23日 星期五

[新聞時事] Dell 伺服器主機板內含惡意程式

server-poweredge-r410-overview2 日前一位使用者在 Dell 網站投書,提及他接到 Dell 客服電話表示要替他更換伺服器的主機板,而理由竟然是因為主機板內含惡意程式。遇到這種匪夷所思的事情,大概沒有多少人會相信,也難怪這位使用者會選擇先上網求證。而根據 Dell 的回答,表示確實有一批伺服器的主機板內含惡意程式,而且也已經啟動後續的處理機制。買過電腦的人都知道,買 (非光華牌的) 電腦都會附上許多可能永遠也不到的附屬軟體,這些軟體稱之為 Bundle。以個人電腦而言,這類軟體通常是一些燒錄或影音播放的工具。而對於伺服器,則是以管理工具為主。軟體公司還知道,如果能夠跟這些電腦設備的大廠合作,一旦 Bundle 成功就代表著源源不絕的現金滾滾而來。軟體公司知道,惡意份子當然也知道,Bundle 是一條可以好好利用的散佈管道。其實買電子產品附送惡意程式也不是第一次發生,但是以伺服器這種屬性與價位的產品而言,發生這種疏失實在是很令人難以接受。Dell 彈性化的快速生產方式,或許需要更有效的方式來管理可能產生的安全風險了。

 

相關連結:

2010年7月21日 星期三

[資安標準] OWASP Application Security Verification Standard (ASVS)

Dude_Writing_Check_List

近幾年應用程式所產生的安全漏洞數量已經明顯高於網路與作業系統層級的總和,其中尤其以 Web 相關的應用程式為最大宗。包含網站本身所存在的安全問題,再加上各式各樣瀏覽器與外掛程式 (如惡名昭彰的 Flash),都讓相關問題日益嚴重。雖然目前有很多方法與工具可以幫助服務供應商與使用者解決相關問題,但是因為缺乏共通性的標準而讓整個事情變得很難有效地管理與追蹤。舉例來說,身為一個使用者,你怎麼知道 Gmail 與 Hotmail 哪一個比較安全?好吧,或許 Google 與 Hotmail 本來就各自擁有為數眾多的愛用者,所以這個問題可能不是那麼難回答 (答案對不對是另外一回事)。但是如果今天換成是兩個名不見經傳的小網站,要回答哪一個網站比較安全可就不是那麼容易的事情了。

OWASP 是一個專注於 Web 應用程式安全的非營利性組織,在 2008 年開始推動應用程式安全認證的計畫, 並於 2009 年推出正式的版本,稱之為 OWASP Application Security Verification Standard 2009 (後簡稱 ASVS)。OWASP 是一個中立的組織,所以 ASVS 也不侷限應用在特定的架構或平台之上。不過儘管標準的名稱是 Application Security Verification,但是整個計畫依舊是以 Web 應用程式的安全議題為主。在軟體開發的領域中,Verification 這個動作指的乃是檢查最後的產出 (例如可執行的程式碼) 是否符合當初規範。至於規範本身合不合於實際的應用,乃至於製作過程當中是否有什麼需要改進的作法,則都不屬於 Verification 的範疇。規範本身合用與否,可以透過 User Acceptance Testing 等方式加以確認。而製作過程的合適與否,目前則以 CMMI 這類標準為主。不過 CMMI 是以確保軟體的品質為主要目標,因此 OWASP 提出了另外一個稱之為 Software Assurance Maturity Model (SAMM) 的標準與之對應,SAMM 正是專注於軟體的可靠度 (Assurance)。簡而言之,ASVS 與 CMMI/SAMM 等著重在整體作業流程的標準不同,反倒是比較像 Common Criterion (CC)。

OWASP 希望透過 ASVS 可以提供 Web 應用程式所有相關人員一個共通性的語言,清楚的標示出必須完成哪些安全性的需求。這裡所謂的相關人員,除了我們平常慣稱為甲乙方的直接人員外,也包含了最終的使用者。只是對於最終使用者而言並不需要了解標準的詳細內容,只需知道最後的檢驗結果就足夠了。除此提供共通的語言與標準外,ASVS 還將所有需要檢驗的項目分成 4 個大的層級 (其中兩個層級又各自分成 A、B 兩個子層級),層級越高表示檢驗項目的數量與深度也隨之增加。透過層級的劃分讓相關人員可以評估不同系統之間何者較值得信任,較高的層級往往也就表示更值得信任。ASVS 層級的定義如下:

  • Level 1 Automated Verification
    • Level 1A Dynamic Scan
    • Level 1B Source Code Scan
  • Level 2 Manual Verification
    • Level 2A Penetration Test
    • Level 2B Code Review
  • Level 3 Design Verification
  • Level 4 Internal Verification

由層級的劃分我們可以看到 ASVS 包含利用程式進行自動化的檢驗與人工檢驗這兩種不同的形式,而檢驗的主題除了程式碼之外,也包含(部分的)設計文件。

標準規範對於資訊安全到底是正面抑或負面的影響,至今雖然仍存有很大的爭議,但是不可否認的是唯有透過標準才能夠 (公平地) 量化我們想要了解的項目,而這也是我們想要管理、改進這些項目前最基本也是最重要的一個先決條件。也因此儘管目前採用 ASVS 的組織與專案還是不多,但是網站應用程式安全的檢驗標準依舊是大家值得關注與採行的事項。

2010年7月17日 星期六

[從電影看資安] 誰才是大將軍 - 大兵小將

大兵小將 的時代背景設定在戰國時代,主角有兩位,分別是梁國的小兵與衛國的大將軍 (太子)。必須一提的是,雖然在電影中把電影情節的前後事件做了很明確的介紹,但是故事中劇情並不是真實的歷史事件,所以在引用上可得小心了。回到故事本身,小兵與大將兩人相遇在一場慘烈的戰役上,是唯二的生還者。衛國大將軍因為與梁國大將軍做了一場生死決鬥,因此體力不支而被貪生怕死的小兵所虜獲。戰場上擒獲敵將自是大功一件,可以獲得五畝良田與終生免除兵役,也因此小兵說什麼也要拼死把敵國將軍抓回去領賞。就在返回粱國的路途中,兩人巧遇一個能歌善舞的落單女子。這個女子因為對戰爭所帶來的毀滅感到深惡痛絕,因此對軍人充滿敵意。而小兵無意間把大將軍的裝備穿戴在身上,再加上他帶著一個俘虜,讓女子誤以為他才是一個殺人無數的大將軍,所以就在酒中下毒想要給他一個教訓。沒想到陰錯陽差之下,被誤認的大將軍與真正的大將軍都喝下了有毒的酒,昏迷不醒…

貪生怕死的粱國小兵,連身上的弓箭都是假的。vlcsnap-2010-06-30-11h21m20s152

衛國大將軍費盡千辛萬苦終於打敗粱國將軍。  vlcsnap-2010-06-30-11h22m21s1

螳螂補禪,黃雀在後。小兵雖然怕死腦袋可靈光了。vlcsnap-2010-06-30-11h23m45s67

小兵不只穿戴大將軍的裝備,還模仿大將軍說話的語氣。vlcsnap-2010-06-30-11h34m32s130

鬼嚇人嚇不死,人嚇人嚇死人。vlcsnap-2010-06-30-11h26m04s169

神祕女子誤將小兵當成大將軍了。vlcsnap-2010-06-30-11h25m08s135

神祕女子再次確認。vlcsnap-2010-06-30-11h27m02s4

乎你死。vlcsnap-2010-06-30-11h27m26s211

該喝的喝了。   vlcsnap-2010-06-30-11h50m02s235

不該喝的也喝了。vlcsnap-2010-06-30-11h51m06s108

倒了一個。 vlcsnap-2010-06-30-11h29m56s221

另一個也倒了。vlcsnap-2010-06-30-11h29m18s56

電影中的小兵雖然是無心之舉,但是他確實做了一個在資訊安全中很重要的動作,那就是假冒 (Spoofing)。一般聽到假冒,大家很直覺地就想到不好的一面。各式各樣的 Spoofing 攻擊,包含 ARP Spoofing、IP Spoofing、DHCP Spoofing、DNS Spoofing、URL Spoofing…甚至是 Certification 都可以 Spoofing,也就是說幾乎所有你可以想像到的項目都有遭受 Spoofing 攻擊的可能性。Spoofing 除了對攻擊方很重要外,其實對於防守的一方也是同樣重要。當然,身為防守的一方,不會使用 Spoofing 這樣負面的名詞,所以才會讓人容易誤會假冒單純是攻擊方所使用的技巧。

Spoofing 用在防守方面最基本的應用就是用來對付所謂的 Banner Grabbing。通常駭客在發動攻擊前會先進行資訊收集的工作,其中一個方法就是利用 Banner Grabbing 來了解目標的基本資料。Banner 指的是當我們試著連上服務時,服務會先回應一個預設訊息,原意是讓我們確認有沒有連錯服務。因此我們可以透過 Banner Grabbing 的方式知道目標的電子郵件服務乃是透過 Sendmail 8.14.3 所提供,而這樣的資訊可以幫助駭客擬定相當有效的攻擊方法。Banner Grabbing 的好處除了可以遠端執行外,更重要的是它利用的是目標系統的預設行為,因此幾乎不會造成任何的起疑。對付 Banner Grabbing 的方法其實很簡單,就是把目標系統的預設 Banner 改掉,像是明明執行的是 Sendmail,但是卻送出 Exchange 的 Banner。有些建議作法是把 Banner 整個刪掉,讓駭客無法取得任何有用的資訊。但是我個人認為假冒為其他服務有其好處,可以誤導攻擊者採用錯誤的攻擊手法。如果搭配其他的安全機制 (如 IDS/IDP),更大大增加了在有效攻擊行為發生前就發現駭客的機會。

修改服務的 Banner 固然有其效用,但是畢竟這些有價值的服務還是會遭受到攻擊。就算攻擊不成功還是會或多或少受到一些影響,更何況攻擊確實有其成功的機會。所以我們可以把這樣的概念延伸到利用一些假冒的服務來取代真正的服務,藉此吸引並誤導駭客的注意力。這樣的作法稱之為 Honeypot (或是 Decoy Server),而 Honeynet 指的則是由一群 Honeypot 所組成的系統。不管是修改 Banner、Honeypot,或是 Honeynet,基本上都是假冒的應用。兵不厭詐這句話跟道德沒有關係 (但是可能跟法律有關係),攻擊方可以利用,防守的一方也別輕忽了。不過最重要的是,假一定要假的像,這已經不只是一門技術,更是一門藝術,也唯有如此才能像 Michael Jordan 在球場上的假動作一樣地有效與迷人。

2010年7月11日 星期日

[從電影看資安] 交給猴子管理的度量 - 食破天驚

電影 食破天驚 描述一位從小就喜歡搞一些創意發明的小男孩,因為太過專注於發明而被同伴視為怪胎。小男孩所居住的小鎮資源不豐,唯一的特產就是沙丁魚。就在小男孩長大後,小鎮居民的生計因為沙丁魚不再受到市場的歡迎而受到很大的影響。就在一次陰錯陽差的錯誤下,男主角意外發明了一個可以讓食物從天而降的機器,並瞬間成了小鎮的英雄。然而就在大家恣意要求男主角利用機器產生大量食物的同時,食物開始產生變化,不但外觀變得更巨大,甚至產生了自己的思想…

男主角向女主角解釋食物製造機的原理。vlcsnap-2010-06-28-19h33m13s89

女主角對於這個神奇的機器有些質疑。 vlcsnap-2010-06-28-19h36m43s147

男主角設計了一個用來指示食物是否安全的度量。vlcsnap-2010-06-28-19h37m05s116

男主角早就預測到有食物過度突變的危險性。vlcsnap-2010-06-28-19h37m11s188

好像有點危險了,但是很多人都還想看機器表演食物秀。 vlcsnap-2010-06-28-19h45m15s147

敲一敲,不危險了?vlcsnap-2010-06-28-19h45m23s243

這次來個天然冰淇淋的街景。vlcsnap-2010-06-28-19h51m16s173

男主角前往接受鎮長的表揚,把實驗室交給副手管理。vlcsnap-2010-06-28-19h49m54s133

副手竟然是一隻…猴子!食物的突變已經進入危險的階段,猴子當然無能為力。vlcsnap-2010-06-28-19h49m14s236

食物突變後產生由義大利麵與各種食物所形成的龍捲風。  vlcsnap-2010-06-28-19h48m30s52

電影中的危險顯示表可以視為度量 (Metrics) 的一種,度量在資訊安全管理上是很重要的一個元素。度量其實可以利用在很多方面,小至防火牆規則的有效性,大到整個安全計畫的成效,都可以透過度量來加以評估,也就是說度量可以用來評估技術性與非技術性的事項。只要是我們想要評估成效的項目,理論上都可以透過度量來達成目標。更有甚至,度量本身也可以透過其他的度量來評估。不管是哪一種度量,往往都跟監視 (Monitoring) 這個概念息息相關,透過度量可以明確定義出監視的目標並讓自動化監視變成可行,甚至我們可以說一個沒有進行監測的度量 (或交給猴子監測的度量) 並沒有任何實質上的意義。

度量雖然很實用,但是如果設計出不合適的度量,卻有可能反受其害。因為不合適的度量並沒有辦法反應出真正的問題,甚至可能誤導了問題的真相。而最為危險的情況則是不合適的度量隱蓋了正在發生的問題,而給使用者一種假的安全感 (false sense of safety)。一個好的度量通常必須同時具備下列五大特色,那就是所謂的 SMART

  1. Specific (明確的),如何取得度量的數值必須是明確定義的。
  2. Measurable (可量測的),通常也就是可量化的指標。
  3. Attainable (可實現的), 度量的數值必須是確實可以取得的。
  4. Relevant (貼題的),也就是度量必須能夠正確地反應出我們想要評估的事項。
  5. Timely (即時的),如此一來我們才可以在第一時間做出必要的反應。

一旦有了一個合適的度量,接下來就是定義出所謂的上下臨界值 (Upper/Lower Threshold)。如此一來才可以知道是否已經達到原先預估的效果,或者是是否需要啟動修正/應變計畫。除了採用上下臨界值外,也有可能設計成幾個不同的區段 (就像影片中的危險顯示表),用來表示程度的差異。在執行的過程中,誠實面對是最為重要的關鍵,絕對不可自欺欺人 (就像男主角把指數敲回去)。即使發現度量的選擇可能有錯,也應該重新定義一個更合適的度量,絕對不可把度量拋諸腦後,屆時從天而降的可就不只是食物了。

 

相關連結:

2010年7月10日 星期六

[技術分享] Cross-site Request Forgery (Part 2)

csrf_wizard_sleeves_tshirt-p2357758638809497577c6n_152 在上一篇的文章中,我們了解到何謂 CSRF 以及其運作原理,在這篇的文章中我想要談談網站開發者與使用者該如何做才能避免 CSRF 的威脅。

要避免 CSRF 的攻擊,目前公認最有效的方式就是所謂的 Synchronizer Token Pattern。簡單來說,Synchronizer Token Pattern 指的是每次使用者發出請求時 (不管是透過 POST 還是 GET) 都必須傳回一個網站系統所指定的亂數,而這個亂數可以設計成適用於整個 Session 階段,也可以設計為只能使用一次。以安全性而言,後者的作法確實可以達到相當好的效果,但是卻也會為使用者帶來極大的不便性,所以在大部分的情況下前者反而是比較常用的作法。其實後者的作法除了應用在增加安全性之外,也常被用來作為避免使用者重複發出請求的保護措施。使用者重複發出請求尤其容易出現在反應較慢的系統中,使用者因為失去耐心或不知所措之下往往只好重複之前的動作 (請求)。

等等,在使用 GET 的情形下,Synchronizer Token 不就等於直接擺在 URL 參數中讓人取用,那怎麼還有安全性可言?別忘了在 CSRF 攻擊中,通常駭客是無法取得受害者與目標網站之間溝通的訊息,所以這樣的作法依舊大幅增加駭客產生合法請求的困難度。再加上 Synchronizer Token 的有效期僅存在單一 Session、甚至是單一請求中,因此就算駭客取得 Synchronizer Token 後也往往無濟於事了。此外,透過 SSL 進行連線可以讓 Synchronizer Token 被”看到”的機會大大降低。

Synchronizer Token 的一個特例就是直接把 Session Token 當作 Synchronizer Token 使用,這種方法又稱之為 Double Submit Cookies。使用 Double Submit Cookies 的好處是比較方便,網站系統不需要另外維護一份 Synchronizer Token 的對應關係表,但是這樣做卻會讓 Session Token 處於一個較危險的狀況,增加了 Session Hijacking 攻擊的成功機會。

除了 Synchronizer Token 外,還有一些其他的手法也會被用於應付 CSRF,像是只接受 POST 的方式、檢查 Referer 標頭、將單一請求就可以完成的流程拆成多個請求、URL 重導、秘密的 Cookie (Secret cookie) 等方式。然而這些方法頂多增加 CSRF 攻擊的困難度,甚至有些方法對於應付 CSRF 並沒有任何的助益,在使用上必須多加小心。話雖如此,上述手法中有一個手法被很多網站系統所應用,那就是將單一請求就可以完成的流程拆成多個請求。然而這個手法在實際應用上必須稍加變形,也就是在後面的請求中加上一個駭客 (或瀏覽器) 無法知悉的秘密。沒錯,我講的就是現在很多網站系統會在使用者進行重要請求時 (例如修改密碼) 要求使用者再次輸入密碼。因為駭客無法得知使用者的密碼,再加上密碼並不存在於瀏覽器之內 (記得要關閉瀏覽器記憶密碼的功能),所以可以有效避免使用者遭受 CSRF 攻擊。需要特別注意的是,就算採用了再次輸入密碼的保護措施,依舊不可遺漏了 Synchronizer Token Pattern 的使用。

以上這些方法都是針對網站系統開發人員而言,那麼一般使用者該怎麼做才能保護自己免於 CSRF 的攻擊呢?OWASP 對此有三項建議:

  1. 不使用網站服務時儘快登出 (Logoff immediately after using a web application)。
    嚴格來說,要做到這點越來越不容易,因為現在大部分網站系統就是強調 Alwasy On,努力增加使用者停留的時間。所以之間如何取捨,可就得由使用者自行衡量了。好消息是像網路銀行這類重要的網路系統通常在使用者停止操作後就會在很短的時間內自動登出,以減少遭受攻擊的機會。
  2. 不要使用瀏覽器記憶帳號/密碼的功能,也不要使用網站的”記住我”(Do not allow your browser to save username/passwords, and do not allow sites to “remember” your login)。
  3. 針對一般性的網路瀏覽與存取重要網站服務採用不同的瀏覽器。如果不能採用不同的瀏覽器,至少應該使用不同的視窗,也就是不要使用分頁的方式 (Do not use the same browser to access sensitive applications and to surf freely the Internet; If you have to do both things at the same machine, do them with separate browsers)。
    瀏覽器的選擇除了受到電腦環境的限制外,往往還跟使用者的習慣有很大的關係,因此採用不同的瀏覽器說起來很容易,但是卻很少使用者會這麼勤勞。好在現在已經有部分瀏覽器 (Firefox、Chrome) 推出所謂私密瀏覽的功能,我們可以使用標準模式來進行一般性的網路瀏覽,並透過私密瀏覽來存取重要的網站服務。因為私密瀏覽是一個獨立的空間,與標準模式下的空間彼此互不相干,簡單來說就是在私密瀏覽內的登入資訊 (如 Session Token) 在標準模式下是不存在的。使用私密瀏覽除了可以避免 CSRF 的攻擊外,也可以避免留下任何存取的紀錄與軌跡,這點在使用公共電腦上網時顯得格外重要。

最後,OWASP 提供了 Java、.NETPHP 的 Synchronizer Token Pattern 實作範例,有需要的讀者就請自行參考與取用了。

 

相關連結:

[技術分享] Cross-site Request Forgery (Part 1)

csrf_wizard_sleeves_tshirt-p2357758638809497577c6n_152 Cross-site Request Forgery,常縮寫為 CSRF (或 XSRF),中文翻譯稱之為跨網站的偽造要求。除了這些稱呼,其他像是 Cross-site Reference Forgery、Session Riding、One-click Attack 等等各式各樣的名稱,其實指的都是同一種攻擊手法。 CSRF 跟 XSS (Cross-site Scripting) 都是跨網站的攻擊手法,但是 CSRF 利用的是使用者對於瀏覽器的信任而達到攻擊目的,而 XSS 則是利用使用者對於網站本身的信任。

簡單來說,CSRF 就是在使用者不知情的情況下,讓瀏覽器送出請求給目標網站以達攻擊目的。 對於 HTTP 協定有所了解的讀者,看到這句話可能會覺得很困惑。因為在預設的情況下,任何人只要知道 URL 與參數都可以對網站發出任何請求,如此說來不是所有的網站都會遭受 CSRF 的攻擊了嗎?可以說是,也可以說不是。因此嚴格來說,CSRF 通常指的是發生在使用者已經登入目標網站後,駭客利用受害者的身分來進行請求,如此一來不但可以獲得受害者的權限,而且在系統的相關紀錄中也很難發現可疑之處。

在進一步談到 CSRF 的攻擊手法之前,我要先談一下一般網站應用程式是如何識別使用者的身分。對於需要辨別使用者身分的網站而言,最常見的方法就是依靠帳號/密碼。凡使用者想要進行受限制的動作時,就必須先經過帳號/密碼的驗證。但是如果在每次進行受限制動作前都要輸入一遍帳號與密碼,我想沒有多少使用者可以忍受這樣的不便。所以所有的網站系統都會把使用者輸入且通過驗證的帳號資訊記錄下來,之後就不再進行驗證的動作了。然而因為 HTTP 協定的限制 (Stateless),所以如何紀錄這個驗證過的帳號資訊就成了棘手的問題。早期有些系統會將帳號本身紀錄在 Cookie 中,因為 Cookie 的特性就是瀏覽器在每次存取網站的同時會將內容傳回去,所以網站系統就可以從 Cookie 中獲得帳號的資訊。然而因為 Cookie 存放在使用者的電腦中,算是一個極不安全的環境,因此後來的網站系統都是在 Cookie 中存放一個隨機亂數產生的代號,網站系統再經由這個代號找出相對應的帳號資訊,這個代號我們通常稱之為 Session Token。Session Token 的概念與實作雖然很簡單,但是安全性卻依舊不足,所以為了提昇 Session 的安全性就必須採用其他補強措施。像是 Session Token 自動失效、定期更新 Session Token 的數值、加上檢查 Session Token 來源 IP 位址等方式,都可以用來增加 Session 的安全性 (主要是避免 Session Hijacking)。除了利用 Cookie 來紀錄 Session Token 外,其他像是把 Session Token 放在 URL 參數中,或是使用 Basic Authentication 的方式,雖然細節上有些不同,但是基本的原理卻都是一樣的。

偷取使用者身分比較有名 (傳統) 的手法正是前述的 Session Hijacking,CSRF 雖然跟 Session Hijacking 很類似,但是跟 Session Hijacking 不一樣的是 CSRF 並沒有真正控制整個 Session (例如取得 Session Token),而只是利用瀏覽器自動回傳使用者身分識別資訊 (如 Session Token) 的功能,讓發出的請求變成受害者的身分。所以 CSRF 利用了受害者的 Session,但是卻沒有直接進行控制,這也是為什麼 CSRF 又被稱為 Session Riding 的理由。雖然 CSRF 可以產生的破壞動作不像 Session Hijacking 那般不受限制,但是因為在 CSRF 中請求確實是由受害者的瀏覽器所發出,所以事後很難追蹤問題發生的來源,而且所有用來解決 Session Hijacking 的手法也幾乎沒有辦法避免 CSRF。此外因為進行 CSRF 攻擊時請求是由受害者的瀏覽器所發出,所以可以用來攻擊內部的 (對受害者而言) 網站系統,這點往往是 Session Hijacking 所做不到的。

CSRF 可能的攻擊情境之一可以用下列圖示加以說明:

CSRF 01

CSRF 02

CSRF 03

根據 OWASP 的文件,一個 CSRF 攻擊要成功有四個要素:

  1. 瀏覽器處理 Cookie 與 Basic Authentication 的行為 (Web browser behavior regarding the handling of session-related information such as cookies and http authentication information)。
    因為這部份是 HTTP 相關協定的規範,所以我們無法針對此點做任何防範。
  2. 駭客對於網址的知悉 (Knowledge by the attacker of valid web application URLs)。
    如果目標網站是一個公開的系統,駭客取得 URL 資訊並不是什麼困難的事情。但是對於內部私有系統而言,駭客必須透過社交工程或其他手法取得這些資訊。
  3. 網站系統的 Session 管理依靠瀏覽器所擁有的資訊 (Application session management relying only on information which is known by the browser)。
    嚴格來說,這點才是 CSRF 會造成破壞的真正元兇,而且所有的防範機制也都是針對此一要素。
  4. 可以觸發使用者瀏覽器發出請求的網頁元素 (Existence of HTML tags whose presence cause immediate access to an http[s] resources; for example the image tag)。
    駭客可以將需要假冒的請求放到某個網頁的 image 標籤中 (也就是 <img src=”…” />),如此一來當受害者瀏覽到這個網頁後瀏覽器就會自動發出請求。因為瀏覽器在發出請求前無法判別請求的資源是否確實為圖檔,所以無論如何都會造成請求訊息的傳送 (除非使用者關閉了自動下載圖片的功能,但是我想應該沒有使用者會這樣做吧)。當然駭客也可以利用別的方式誘騙使用者按下連結,但是採用 image 標籤的方式並不需要使用者的點選就可以自動執行,所以算是最為有效的手法。
    這個用來發動攻擊的網頁,通常是存放在另外一個不相干的網站系統之內。可能是受駭客控制的網站,也可能是駭客利用 XSS 等手法將假冒請求指令植入的無辜網站。如果這個無辜的網站恰巧正是目標網站本身,這種攻擊手法又稱之為 Stored CSRF,其產生的危害將更加地可怕。也就是說駭客利用 XSS 等手法將假冒的請求先植入目標網站中,因為前來瀏覽目標網站的使用者已經登入系統的可能性相對提高許多,所以 CSRF 成功的機會也隨之大幅提高。而且 Stored CSRF 因為攻擊網頁與假冒的請求屬於同一個網站,所以採用多個瀏覽器進行不同網站間瀏覽的保護方式並沒有什麼作用。事實上, Stored CSRF 對使用者而言幾乎是沒有什麼方法可以加以避免的。
    除了可以使用 XSS 手法植入假冒的請求外,如果網站系統允許使用者透過 URL 連結外部圖檔但是卻沒有檢查連結資源是否確實為圖檔,也很可能遭受這樣的攻擊。也就是說像 Web Mail 這類可以接受內嵌外部圖檔的訊息網站,很容易成為駭客用來發動 CSRF 的平台。

對 CSRF 有所了解後,在下一篇的文章中我們來談談如何避免 CSRF 的危害。

2010年7月7日 星期三

[個人意見] 你的應用系統也是 DLP ready 嗎?

ipad DLP (Data Loss Prevention) 一詞對於 IT/IS 人員來說,可說是已經朗朗上口,甚至成為茶餘飯後的聊天話題。目前有很多現成的產品宣稱可以全面保護重要的資料,大多數保護的範疇以資料庫為主,但是也有一些產品以非結構性的資料 (如檔案) 為保護對象。然而除了導入技術性的產品之外,要做到更為完整的資料防護就不可以忽略資訊安全政策的重要性。因為很多時候重要資料並不一定只會以數位的形式存在,對於非數位形式 (如紙本) 的重要資料而言,唯有透過良好的安全政策才有辦法加以保護,而技術性的產品對此幾乎可以說是無任何用武之地。而且就算是針對數位形式的資料,同樣需要良好的安全政策才能讓技術性產品發揮應有的功能。舉例來說,如果公司對於資料存取的授權沒有一定的程序而任憑管理者自由心證,那麼就算佈署再好的技術性產品也是枉然。

做到了這些,資料就安全了嗎?很可惜答案還是否定的。以目前的商業環境而言,這些寶貴的資料大多會被具備網路功能的服務所取用。標準的 DLP 產品可以避免寶貴資料透過 Email、HTTP、IM 等方式外洩出去,但是對於客製化的系統 (像是 CRM 或 E-commerce 等) 通常就愛莫能助了。這個議題屬於軟體安全 (Software Security) 與應用程式安全 (Application Security) 的範圍,對許多組織來說是比較不受重視的議題。除了不受重視之外,軟體安全/應用程式安全的負責人員也跟上述 DLP 產品或資訊安全政策負責人員有所不同,因此雙方如何合作以達到無間隙的防護能力,更是需要特別費心的事項。前一陣子沸沸騰䲢的 AT&T iPad 客戶資料外洩事件,據悉並不是因為 iPad 本身設計的問題,而是網站應用系統出現安全漏洞而造成的。以 AT&T 跟 Apple 這麼知名與具備技術能量的公司都尚且出現這麼嚴重的瑕疵,可見得問題的嚴重性與影響層面之大。或許大家可以說 AT&T 跟 Apple 本來就不是以 Web 與 Security 著稱,那麼 Google 呢?這家網路原生的網路巨擘,不斷強調其服務的安全性,但是依舊免不了遭受駭客攻擊成功的下場。舉這些例子並不是為了數落這些公司,因為我相信絕大多數的組織並不見得會做的比他們更好。今天發生在 iPad 上面,或許無法改變 iPad 持續熱賣的事實。但是如果類似的事情發生在其他的組織中,會有多少組織能夠全身而退?既然問題如此嚴重,我們又怎能不認真地面對軟體安全/應用程式安全這些議題,並好好擬定對策呢?

相關連結:

2010年7月6日 星期二

[技術分享] Clickjacking

前一陣子在一次偶然的機會中,被一位高手問到 (應該說是考到) 什麼是 Clickjacking,又要怎麼防備?老實說,雖然 Clickjacking 這個手法剛被提出時我就注意到相關的新聞,但是當時尚未公布實際的手法,再加上 Clickjacking 一直不像 SQL Injection、XSS 這些手法這麼普及 (OWASP Top 10 還排不上),所以後來我就一直沒有動力去研究 Clickjacking 這個手法。因此,只記得當時我真的是比穿黑衣還掉了滿身的頭皮屑還糗。不過話說回來,學習永遠不嫌晚,所以我趕緊惡補了一下,並透過這篇文章跟各位分享一下 Clickjacking 這個很危險卻還沒有被廣泛應用的攻擊手法。

Clickjacking,簡單來說就是將使用者在瀏覽網頁的點擊動作進行綁架,讓點擊動作產生非使用者所預期的行為。Clickjacking 最初公布的 例子,也是最著名的例子,就是利用隱形頁框 (invisible iframe) 的方式,讓受害者在不知不覺中”自己”修改 Flash 的安全設定,以利駭客可以遠端控制受害者電腦的攝影機與麥克風,進而進行遠端的監聽/監視。目前常見的資料將 Clickjacing 分為 frame-based clickjacking (又稱為 UI readressing) 與 plugin-based clickjacking 兩大類,但是在阿碼外傳上的 範例 使用修改 onclick 事件處理程序的方式,也可算是另外一種實現的手法。

針對 Clickjacking 的應付之道,可以從伺服器端與用戶端兩方面來談。在伺服器端比較常見的就是使用稱之為 framekiller 的 javascript 程式碼或使用 X-FRAME-OPTIONS 這個專門為了解決 Clickjacking 而新增的 HTTP 回應表頭。 雖然 X-FRAME-OPTIONS 在 Clickjacking 被發表沒多久後就由微軟所提出,但是因為這個機制需要瀏覽器的支援,所以初期多以 framekiller 這類技術為主。framekiller 比較大的限制就是需要 javascript 的執行能力,一旦使用者關閉 javascript 的執行功能時,framekiller 就無用武之地了。或許一般使用者不太會自行關閉 javascript 的執行功能,但是更大的問題在於 IE 可以透過 <IFRAME SECURITY=restricted> 的宣告方式將 javascript 的執行能力加以關閉,也就是說駭客並不需要透過使用者就可以輕易的關閉網頁執行 javascript 的能力。好在經過將近兩年的時間,目前大多數瀏覽器的最新版本都已經支援 X-FRAME-OPTIONS 表頭,唯一的例外是 Firefox…如果你不確定你的瀏覽器是否支援 X-FRAME-OPTIONS 表頭,你可以連到這個 網頁 進行測試,”正確”的結果應該是三個有紅色字樣描述的 iframe 頁框才有顯示資料,其他頁框則為空白。這樣聽起來,Clickjacking 目前似乎是不用太擔心才對,但是事實卻不是如此。根據一份由 Stanford University 與 Carnegie Mellon University 所公布的 研究 顯示,目前大部分網站對於 Clickjacking 的防護依舊存在著明顯的問題。除此之外,上述的作法只能防範 frame-based clickjacking,對於應付 plugin-based clickjacking 並沒有任何的幫助。

前面我提到 Firefox 目前依舊不支援 X-FRAME-OPTIONS 這個表頭,但是 Firefox 的愛用者可別千萬因此而感到失望,反而應該更為高興才是。因為目前客戶端的防範機制中,最為有名且免費的工具就是 NoScript,而它是 Firefox 的 Add-on。NoScript 除了支援 X-FRAME-OPTIONS 外,也可以自動偵測網頁是否存在 framekiller 程式碼並據此限制網頁是否可以被包含在 iframe 當中,因此即使在關閉 javascript 執行能力的情況下依舊可以提供防護。事實上,NoScript 雖然名稱叫做 NoScript,它也確實可以關閉 javascript 的執行能力,但是 NoScript 並不是依靠關閉 javascript 執行能力來防範 Clickjacking 的攻擊。即使在 javascript 可以執行的情況下,NoScript 依舊可以提供 Clickjacking 的防護,也就是說 NoScript 對於 Clickingjacking 的防護跟網頁是否能夠執行 javascript 是沒有關係的。這對不想關閉 javascript 執行能力的使用者來說 (應該大多數使用者都不想關閉 javascript) ,確實是一大好消息。如 NoScript 這類客戶端的防護機制,除了不需仰賴伺服器端的 (程式) 修改就可以運作外,更大的好處是可以同時防護 frame-based clickjacking 與 plugin-based clickjacking。NoScript 最大的問題在於僅作用於 Firefox,使用其他瀏覽器的使用者就必須另尋付費軟體來提供類似的防護了。

 

相關連結:

2010年7月3日 星期六

[從電影看資安] 你的系統現在安全嗎 - 女神的報酬

電影 女神的報酬 的男主角是一位工作能力很強卻人際關係不佳的外交官黑田,他被派駐到義大利後,首件任務就是確保前來參訪的日本外相的人身安全。沒想到黑田竟被意外捲入一樁日本觀光客的綁架案件,女主角的小女兒在沒有任何線索的情況下被犯罪集團所綁架。在與綁匪交手的過程中,黑田雖然發現許多不合理的細節,但是依舊一步步試著解開謎團,最後終於有機會前往負責監視小女孩走失地點的安控中心,想要釐清一些無法理解的疑點。綁匪利用女主角進入管理嚴密的安控中心的機會,要脅女主角趁機癱瘓安控系統並取得存取的權限,之後更將保全設施加以關閉,製造想要襲擊義大利總理的假象。在層層抽絲剝繭之下,黑田發現所謂的綁架事件只是一個瞕眼法,綁匪真正的目標其實是日本外相,兩人的恩怨導因於多年前的一件國際援助事件…

男主角黑田新官上任。vlcsnap-2010-06-28-16h31m58s132

男主角主要負責安全事宜,思慮冷靜且清楚。vlcsnap-2010-06-28-16h33m50s236

女主角的小女兒不見了,是自己走失了嗎?vlcsnap-2010-06-28-16h34m07s158

男主角接到綁匪的電話,情急之下只好冒充成小女孩的父親。vlcsnap-2010-06-28-16h35m18s94

經過一番波折,男主角終於可以看到監視器畫面的原始存檔。vlcsnap-2010-06-28-16h36m36s121

監視器畫面錄影被動過手腳,難怪看不到小女孩被綁架的情形。vlcsnap-2010-06-28-16h36m49s248

綁匪要脅女主角,除了要引起混亂外,還要求操作人員聽命行事。vlcsnap-2010-06-28-16h39m39s160

整個安控系統被關閉了。  vlcsnap-2010-06-28-16h41m55s245

30 秒倒數計時中。vlcsnap-2010-06-28-16h42m02s50

駭客猜到正確的密碼,厲害。vlcsnap-2010-06-28-16h43m14s14

操作人員也發現系統被入侵了。 vlcsnap-2010-06-28-16h43m42s7

在影片中綁匪利用安控系統重新開機的機會,順利入侵系統。雖然在電影中沒有明確說明,但是綁匪大費周章地想要製造系統重新開機的機會,應該表示這樣的入侵動作只有在系統重新開機的 30 秒之內才有成功的機會。

一般我們在考量系統安全的議題時,都是假設系統已經處於正常運作的狀態,所以許多的安全措施就在此假設下加以設計。但是天底下當然沒有這麼美好的事情,系統有啟動、關閉、錯誤等不同的情況會發生,如果當初在設計系統時沒有考量到這些的可能性,那麼一旦這些情況發生時,系統將會產生何種反應可就很難說了。為了解決這些可能的問題,Secure BootingTrusted Comuting 等概念與產品因應而生。

除了在設計作業系統時需要考量這些非正常的情況,在設計各式各樣的應用系統時也同樣不能忽略這些問題所可能帶來的危害。包含初始、啟動、關閉、錯誤、失效在內的各種執行狀態,都必須確保其安全性。其中初始的安全可以採用預設安全 (Secure by Default) 的概念加以確保,而失效則有所謂的失效安全 (Fail-Safe) 原則可以遵循。不管採用什麼原則,如何確保系統 (無論是作業系統還是應用系統) 在任何情況下都可以維持其安全性,這不但是一個很重要的設計要求,同時也是一個很具挑戰性的要求,因為其中牽扯到的不只是技術性的考量,更包含了許許多多非技術性的考量 (如方便性)。

About