就是資安

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 持續熱賣的事實。但是如果類似的事情發生在其他的組織中，會有多少組織能夠全身而退？既然問題如此嚴重，我們又怎能不認真地面對軟體安全/應用程式安全這些議題，並好好擬定對策呢？

俗話說：『黑貓、白貓，只要能抓到老鼠的就是好貓。』在資訊安全領域中，也有一個跟黑白有關的概念，那就是黑名單 (Blacking listing) 與白名單 (White listing)，兩者多使用於存取控制的機制中。 所謂的黑名單，簡單來說就是列出一堆不被允許的事物，除此之外都是被許可的。常見的黑名單應用包含惡意網址過濾、垃圾郵件黑名單 (如 DNSBL)，以及大家很熟悉的防毒軟體。而白名單與黑名單恰恰相反，應該被許可的事物都必須明確地列出，而所有沒有列出的事物都是不被許可的。最常見的白名單應用就是登入系統，所有想要使用系統的人員，都必須擁有合法的帳號與密碼才能放行。 除了黑名單與白名單之外，另外還有一種稱之為灰名單 (Grey listing) 的機制。不過灰名單通常單指電子郵件中用來對付垃圾信件的一種機制，跟其他存取控制倒是沒有太大的關係。 黑、白名單在使用上相當簡單方便，但是比較缺乏彈性，因此還有其他各種不同的機制來實現存取控制。跟黑、白名單比較接近的還有一種稱之為規則清單 (rule-based ) 的概念，防火牆的規則通常都屬於這一類。規則清單的特色是可以在每一個規則中指定待驗證的事物是否應該被許可，甚至除了許可之外，還可以包含其他的可能性 (像是再使用其它的規則加以驗證)。規則清單除了擁有較大的彈性之外，使用得當也可以增進處理的效能。效能來自於規則的順序，將常用的規則放到前面可以有效地提升處理效能。例如一個網頁伺服器的流量大多是來自於 TCP Port 80，所以把這條放行的規則放到防火牆規則的前面，可以減少許多不必要的規則判斷。然而，規則的順序不但影響效能，更與設定的正確與否有關。也因此在一個複雜的系統中，如何設定為可使用且足夠安全的規則，往往不是一件容易的事情。所以，防火牆設定完成之後的確認動作，比較嚴謹的作法並不是只看規則的設定值，更需要實際對防火牆進行測試，確定沒有任何不該放行的流量可以通過才算完成。

經過這幾年的發展後，內部員工對於資訊安全的威脅與重要性，已經成為大家無所不知的觀念。很多管制措施只要扯上這個議題，都很容易獲得組織高層的買單。當然，這類措施要成功導入有很多非技術性的問題需要克服，但是基本上這些管制措施所面臨的問題已經不是是否有其必要性的進入門檻。以廣泛的角度來，”人”確實是資訊安全最重要卻往往也是最脆弱的一環。但是這裡所謂的”人”，不應該只是 (基層) 員工，而是組織內的所有組成人員。事實上，如果以重要性而言，高階主管 (尤其是所謂董事會與 Executive 層級的長官) 對資訊安全的影響更甚於一般員工。 這句話包含兩個基本的層面。以積極面來說，所有資訊安全措施的實施都需要組織所提供的資源。資源包含人員與預算等有形的事物，以及組織制度與文化支持等無形的事物。有形資源與無形資源之間或許互有關聯，但是如果連無形的資源都不願提供，直接將資安問題推託給組織預算不足，可真得是很不負責任的說法。在實務上錢少有少的作法，只要保持正確的觀念與心態，一樣可以獲得適當的保護。反之，如果只想砸錢了事，那麼想要真正增進資訊安全就跟緣木求魚沒甚麼兩樣。不管是有形或無形的資源，說到頭來都需要組織的高階長官支持才有可能實現。所以說，高階長官才是組織資訊安全成敗最重要的因素。事實上，如果高階長官對於資訊安全沒有展現出足夠的支持，當遇到資安事件時將無法免除法律上的責任。另外一個消極面則是當組織開始執行措施時，高階長官如果不願意遵守這些規範而要求例外處理，那麼這些高階主管就造成了機制的漏洞。再加上高階主管所經手的重要與機密資料較多，一旦發生問題時所產生的危害自然也大於一般員工。所以高階長官的支持不但在於口頭上，更在於行動上。高階長官確實遵守公司的資訊安全政策，不但能夠免除資訊安全管理上的困擾與漏洞，更能達到帶領員工一同遵守的目的。

延續前一篇的話題，既然 Facebook 不是一個要不要的選擇題，而是要如何面對與管理，那麼有甚麼好的建議嗎？ IDC 於今年中發表了一份 white paper ，主題是如何有效的強化使用 Web 2.0 網站 (如 Facebook) 時的安全性。裡面提到十大需要考量的重點： Dynamic Web 2.0 defenses Real-time content classification Employee access Data loss prevention Application control Remote access Unified policy management Comprehensive reporting and logging Performance and scalability The server side of Web 2.0

Facebook 偷菜引發的爭議至今餘波盪漾，今天最新的相關新聞是台北市的學校也開始禁止使用 Facebook ，因而造成部分教師的反彈。新聞標題下的是”學校禁facebook 被罵管太多”，對此我個人相當不以為然。公私部門想要管理 Facebook ，甚至是所有網路使用行為，並不是管太多，甚至是絕對必要的作為。但是片面性的全面禁止，顯示出的是主管單位對於問題的不瞭解，或者該說是不關心。 Facebook註 對於工作(效率)的影響是好是壞，至今仍有相當的爭議。甚至一些提出數據的研究報告，正反兩方的意見都有。其實這倒也沒甚麼好奇怪的，就是因為有爭議，才會有這麼多不同的研究報告，不是嗎？我在此不想討論 Facebook 究竟是好是壞這種永遠沒有正確答案的議題。我只能說人不是可以線性預測的”工具”，而且現在大部分的工作也不是線性的工作。工作時間長短跟產出的質與量不是正比的關係，而且短期的工作效率跟長期的工作效率也不全然是正比的關係。更重要的是每個人都不同，每個團隊的文化也不同，所以 Facebook 所產生的影響也會不同。 以積極面來說，如何利用 Facebook 幫助業務的進行，是主管單位必須加以好好思考的。而在消極的那面，則包含如何處理 Facebook 所引起的問題(如時間與資源的”過度”浪費、機密資料的外洩等)。 對絕大多數的企業而言，Facebook 不是一個要或不要的選擇題，而是要如何面對的申論題。此外，員工上班時間效率不彰，更不會是因為 Facebook 單一因素所造成，員工對於工作的投入程度不高或許才是主因。如果倒因為果，不但徒勞無功，甚至可能造成反效果。今天禁了 Facebook ，明天還有 Plurk (我個人認為經營 Plurk 所需花費的時間不會少於 Facebook )。就算能禁的都禁了，最終也無法禁止員工神遊。就像有人說過，你可以關住我的身體，但是關不住我的思想。如果把工作搞的像坐牢，限制再多也是無法提升工作效率。反之，如果公司能夠提供員工積極工作的動機，員工自然不會過度分心於工作之外的事物。更何況適當的休閒(包含工作中)，對於所有的工作者都是有其正面的意義。

幾個月前我的 T 牌 MP3 撥放器壞了，因為還在保固期內，所以就送回原廠維修。維修完後去拿取的當下，我因為一時無聊，就問了客服人員故障的原因，他回答我說應該是"中毒"了！我聽了之後，還開玩笑的問他 MP3 播放器也會中毒喔？他給了肯定的答覆，還說有些歌曲會造成中毒的現象，不過很好處理，只要重置就可以恢復正常了。與其說是中毒，我倒更認為是因為設計不夠完善，所以造成在播放特定的歌曲時產生了機器的異常。當然，這是我自己心裡的想法，並沒有說出口。 不管說法是甚麼，MP3 播放器會因為撥放特定歌曲而失效是事實，這在以前的世界中是很難想像的。在數位化的世界裡，每種電子設備跟電腦一樣包含了硬體、韌體、軟體等元素，所以電腦會產生的問題，在這些設備身上也有可能發生。好在 MP3 播放器並不是什麼重要的設備，除非你是一天沒有音樂就會活不下去的人，不然對生活不會有任何負面的影響，頂多就是花錢再買一台就好了。更重要的是，失效的 MP3 播放器並不會攻擊你，所以就算你不想處理也沒關係。但是如果今天發生問題的是居家照顧的電子設備(如清潔或保全用的機器人)、甚至是看護病人用的電子設備，這就是人命關天的議題。尤其是功能越多的設備，如果再加上具備遠端連線的能力(透過無線網路、藍芽、紅外線等)，甚至有可能成為有心分子為惡的工具，成為最難防範的內應。從被動的監視/監聽，到主動的攻擊，都是有可能發生的情況。 這是杞人憂天嗎？機器人會不會產生智慧並進行對人類的反撲 (就像魔鬼終結者的劇情，T-X 即為第三集中出現的美女機器人)，我目前不得而知，但是人類會有危害他人的行為卻是由來已久。只要有利可圖，對有心分子而言沒有甚麼是不能做的，唯一的先決條件就是這樣的電子設備是否已經具備龐大的市場規模並可以衍生出相關的非法利益。很可惜的是，安全性通常不會是這類設備在設計之初的主要考量之一，所以只要時機成熟，問題一定會發生。身為資訊安全的從業份子也別太過灰心，甚至應該樂觀以對，畢竟這樣資訊安全的任務才更有挑戰性，不是嗎？當然，如果能夠讓廠商在設計之初，就把安全性的考量放進產品需求中，便可以大幅減少從錯誤中學習的痛苦。台灣以製造/設計電子設備能力見長，如果日後能夠強化產品的安全性，我相信在特定產品上會有更搶眼的表現。

雲端運算 (Cloud Computing) 一詞延續之前的熱度，持續成為資訊業界一個大家朗朗上口的名詞。而且這樣的知名度，更因為一些新聞的報導，連非資訊人員也開始”了解”雲端運算強大的威力 (潛力)。 雲端運算於資訊安全的議題主要有兩個面向，一個是使用雲端運算所應該注意的安全議題 (請參考我的另外一篇文章 - 你準備好降落傘了嗎？ - 談雲端運算的安全議題)，另外一個議題則是如何利用雲端運算提供更好的安全性產品/服務。最先”炒”熱後者這個話題應屬趨勢科技這家公司，而現在包含賽門鐵克在內的眾多公司也都不斷強調在產品/服務之中導入雲端運算，而且一定還要同時提到是好多年前就已經開始著手進行。 儘管雲端運算一詞出現至今已經過了許多年，而且也有些大眾化，但是許多人對於何謂雲端運算似乎仍是認知有限，甚至可能有所誤解。網路上已經有一些不錯的說明文章，所以我在此就拾人牙慧，不多贅述，僅摘要一些重點項目以及我個人的補充。 雲端運算指的不是一種技術，更不是一種特定的商品，而是一項概念。 雲端運算可以算是分散式運算、網格運算的延伸，實際雲端運算的實現可能運用了這些不同型式的架構。如果真要區分，可以說雲端運算是利用 TCP/IP、SOAP(HTTP)、REST等各式各樣公開標準所形成的分散式運算架構。 舉例來說，SETI@home 剛開始大家都說是網格運算，但是現在又歸類成雲端運算，顯見之間的分隔其實並不是那麼明確。或者該說是這些定義是因時、因地、因人而會有所不同。因為 SETI@home 是架構在 TCP/IP 等公開標準上，所以現在被歸類為雲端運算也是再自然不過。 知名分析公司Gartner的分類方式，將「雲端運算」區分為兩大類，分別為「雲端服務」(Cloud Computing Services)與「雲端科技」(Cloud Computing Technologies)。「雲端服務」專注在於藉由網路連線從遠端取得服務，而「雲端科技」則是著眼於利用虛擬化以及自動化等技術來創造和普及電腦中的各種運算資源。 承上可知虛擬化是雲端運算的一種實現方式，但是並不是所有雲端運算都必須使用虛擬化的技術，同時也並非所有的虛擬化都可稱之為雲端運算。 雲端運算目前大概可以區分為三種商品模式，亦及 IaaS (Infrastructure as a Service)、PaaS (Platform as a Service) 與 Software as a Service (SaaS)。 在雲端運算的三種商品模式中，SaaS 是最為人所熟知的一種，也可能是目前擁有最多實例的模式。 IaaS、PaaS 與 SaaS 可以說是雲端運算由下而上的三個層次 (layer)，每個層次目前都有相對應的產品/服務。 舉例來說，IaaS 有 Amazon Web Service，PaaS 有 Google App Engine，而 GMail 則屬於 SaaS。 SaaS 其實可以說跟 Application Service Providers (ASP) 是同一個東西，甚至在網路泡沫化前不少人只聽過 ASP 這個名詞。只是在網路泡沫化後幾乎全部的 ASP 廠商都出局了，所以後來大家當然就不太想 (敢)繼續用 ASP 這個名詞。 成功度過網路泡沫化而且採用 SaaS/ASP 概念中的產品最為人所熟知的當屬 salesforce.com，而且可以說是第一個掛上雲端運算且獲得成功的商業化產品，也因此有不少人誤以為雲端運算就是指 SaaS。 SaaS 不但僅是雲端運算的模式之一，甚至在底層的技術上也不一定會使用到像是虛擬化這類雲端技術。這樣模糊的定義讓廠商在行銷上有更多可以操作的空間，也造成一般大眾對於何謂雲端運算更加難以理解。 SaaS 在資安業界還有另外一個意義，叫做 Security as a Service。基本上我個人認為是為了搭上順風車而產生的新名詞，並沒有甚麼特殊之處。當然，如果原本是賣軟體的廠商，勉強也可以算是 Software as a Service。但是如果原本就是做服務的廠商，這樣的 SaaS 跟原本雲端運算的 SaaS 的關係真的是很牽強。 就像所有的事物都有正反兩面，雲端運算也是優缺點並存，而實際的優缺點會跟使用的模式 (SaaS、PaaS 或 IaaS) 有所關聯。 除了技術上的優缺點，雲端運算在法律、政治、甚至於自由的議題上也有其爭議之處。但我個人認為所有的爭議最後終究會屈服在商業利益之下，也就是說有沒有商業利益才是其能否成功(或者說能夠獲得多大的成功)的唯一因素。 換另外一個角度來看，某項產品或服務到底是不是歸類為雲端運算，對大多數人來說根本也不重要。因為對大多數使用者而言，要的只是結果，至於叫什麼名字，讓廠商去傷腦筋就好了。

根據 Trusteer 近日公布的一項報告分析顯示，幾乎所有的防毒軟體都無法有效地阻擋 Zbot 這個用來竊取網路銀行帳號/密碼的惡意程式。比較使用最新的防毒軟體與不使用防毒軟體的結果發現只改進了 23% 的阻擋效果。Zbot 利用了 rootkit 的技術來躲過防毒軟體的偵測。Zbot 除了會竊取資料外，也會讓受感染的電腦成為僵屍網路的一員，並且具有自我更新的能力。 而另外一份由 Trend Micro 所發布的研究報告中顯示，大多數的電腦一旦被惡意程式感染後，將會持續一段相當長的時間，其中超過 50% 的電腦在被感染 10 個月後依舊沒能將之移除。其實這也難怪，因為如果使用者已經安裝了最新的防毒軟體，通常就不會去考量系統被入侵的可能性。事實上，真要考量也可能無從下手。對於沒有安裝防毒軟體的電腦而言就更不用說了，被持續感染也只是”順理成章”。 針對一些比較刁鑽的惡意程式 (如使用 rootkit 技術加以隱匿)，往往我們必須透過其他的安全產品加以防範。例如使用其他開機工具以便進行完整的硬碟掃描，或是利用網路流量分析工具找出可疑的封包與流量。這些外加的方式在使用上可能不若防毒軟體一般方便，但卻是這組防禦體系中不可或缺的一環。傳統防毒軟體的重要性不是完全消失，而是因為其有效性隨著惡意程式的演進而降低，也因此我們再也不能光靠防毒軟體來保護我們的電腦。   相關連結：

既然是資安的論壇，我們在這系列的最後一篇文章中就來看看資怎麼下手解決複雜的資安問題。我會用一個假想的例子來加以說明。 假設今天有一個抽獎系統，原本的設計是在每次抽獎時會從所有會員中隨機抽出特定數目的會員致贈出豪華獎品。因為每次抽獎的獎品數量、種類都不盡相同，所以順帶提供了一個後台介面讓有權限的人可以設定獎品的數量、種類、以及抽獎的時間。在一次的抽獎結果中，事後卻意外發現頭獎(百萬獎金)的中獎人與該系統的系統管理員竟是一家人，而此系統管理員已於此次抽獎後的隔天無故離職，而得獎者也已經把獎金領走了。進一步的追蹤發現，此系統管理員到職僅約半年的時間，而且之前的工作經驗都在別的地區。 為了追蹤問題發生的原因，我們必須先找到為何得獎者”剛好”是該系統管理員的家人。是抽獎程式被修改而未被發現，還是抽獎程式執行時被其他程式干擾而產生異常的結果，還是在公布結果前得獎者的資料被置換了，甚至有可能是公布後原先得獎者的個人會員資料被換掉了。經由我們的分析發現，原來是因為程式被修改而未被發現，所以抽獎程式在該次抽獎中”一定”會抽中特定的會員(原系統管理者的家人)。 這次事件發生的"直接”原因被發現後，我們可能的立即反應就是如何避免抽獎程式執行異常(如抽出特定的會員)的行為。但是如果這樣就開始要找解法稍嫌過早了。首先，抽獎程式被修改而未被發現，至少還可以衍生出員工素質不良、程式碼管控不當、沒有做好程式的完整性檢查、CM機制不足等更深層的原因。除了這些原因外，因為系統本身還有其它的管道可供有心份子做手腳，所以如果不一併加以考慮，就算今天補了第一個缺口，其他缺口依舊存在。這也是我在第一篇文章中提到有關解決問題的第四個階段 ─ 避免類似問題再發生。這個階段(避免類似問題再發生)對於資安議題特別重要，原因在於資安問題不像一般資訊系統，就算再小心問題還是會”主動”發生。如果沒有抱持未雨綢繆的心態來加以面對，恐怕不只是疲於應付問題，我想應該是連飯碗都不保才是。 事實上，我們認真的看待所有的可能性後，發現都有一個共通的原因，那就是素質不良的員工。為了因應這個問題，包含員工背景調查、責任劃分(Separation of duty)、Two-man control、定期輪調等管理措施或許是更有效的防範方法。對於程式碼管控，則有責任劃分、權限管控等機制可以運作。

在理想的世界中，我們只要想辦法找出最有效率的解法就天下太平了。但是在現實的環境中，除非問題本身很單純(不一定是簡單)，否則真正”問題”才剛開始。最大的可能性在於，邏輯性的問題變成了非邏輯性的問題，而背後的因素幾乎都跟”人”有關。 舉例來說，如果你是一個工程師，正在解決電腦主機板所造成的當機問題。經過一番努力後，你發現原來是主機板上的音效晶片在播放特定訊號時，會因為處理不當而造成當機。而且你也已經證明是晶片本身設計的問題，而不是主機板設計或相關軟體的問題。更糟的是，這種錯誤沒有辦法經由主機板或軟體的修改加以修正。正常來說，除非修改主機板的功能，否則唯一的(最佳)解法就是換一組晶片。但是很不幸的是此一音效晶片的上游廠商，是公司很重要的夥伴。所以要不要換，能不能換，已經不是單純技術性(邏輯性)的問題，而是政治性(非邏輯性)的問題。相關團體彼此之間的利害關係，成了左右問題解決方案的重要因素。 另外一個可能的因素就是時間因素。幾乎所有的問題都有其時效性，如果解法所需花費的時間大於該問題的時效性，那麼是否需要執行就有很大的思考空間。尤其是當外界對於解決問題充滿了急迫性的期待時， Quick Fix 往往就成了優先執行的項目，甚至有時候得做出一些沒有效果的”假動作”以杜悠悠之口。雖說是時間因素，但是時間的急迫與否同樣是以”人”的觀點才有意義。 除此之外，如果問題的解決方法涵蓋廣泛的範圍(如跨越多個不同的部門)時，為了減少初期遭遇的阻力，我們需要採用縮小範圍的解決方案。待達到一定的效果後，才做更全面的問題解決。縮小範圍的另外一個好處是，投入的資源相對較少，因此較容易獲得相關人士(尤其是CEO/CFO)的首肯。