就是資安

根據 McAfee 前一陣子所發表的 報告 中指出，包含美國在內的國家正在發展先進的網路攻擊能力 (Offensive Cyber Capabilities)。這些國家除了美國之外，還包括了中國、蘇俄、法國、以色列等，可說是網路時代的冷戰時期。儘管大家都不願意發動所謂的網路戰爭 (Cyber War)，但是這樣的攻擊行為一旦發生，受到影響的絕對不只是上網的民眾，而是所有的人民。因為這類攻擊的目標包含了基礎公共建設，例如電力系統。在報告中指出像是自動化監控 (SCADA, Supervisory Control and Data Acquisition) 系統就是一個明顯而脆弱的目標。目前很多設施都使用自動化監控系統加以管理，而且已經具備網際網路連線的能力，以提供遠端管理的功能。這類系統一旦遭受入侵或破壞，所產生的危害將是相當的嚴重。不可諱言，因為報告中講的都是屬於各個國家的機密資訊，所以其真實性與可信度都會受到一定程度的質疑。不過就歷史發展的過程來看，這樣的結果是必然的，差別只在於何時與何地罷了。   相關連結：

天使與魔鬼 講的由湯姆漢克所演出的蘭登教授，為了追蹤一宗疑似古老魔鬼教派「光明會」報復的冒險故事。故事裡反派分子用來報復的工具是一種稱之為反物質的東西，是現代科學實驗下的產品。這個實驗室就是大名鼎鼎的 CERN，網站的出現可是要拜 CERN 所賜。想當然爾，這麼重要的東西絕對是應該好好加以保護的。在實驗室最核心的部分，採用了生物辨識技術。反派分子為了順利取得所需的反物質，只好犧牲研究計劃的主持人，就是為了取得他身上的生物特徵。 這就是計畫主持人，請注意他那憂鬱的雙眼。  實驗室的核心區域使用生物辨識技術管制人員進出。 掃描眼睛以便進行判別。

在上一篇的 文章 中，我談到有關社交工程的議題。在這篇文章中，我要大家分享的內容同樣來自於 口是心非 這部電影。 在片中男主角的陣營想盡辦法想要偷取敵方陣營的機密資料，當然網際網路也是不可放棄的一個管道。不過根據劇中角色的描述，敵方陣營的網路防禦能力跟美國國防部的五角大廈一樣嚴密，所以無法成功入侵。好在男主角陣營這邊發現了另外一個可行的管道，那就是敵方陣營新採購的影印機。透過在影印機內安裝惡意程式的手法，後來男主角的陣營成功入侵敵方陣營的其他設備，並於日後順利傳出機密資料。 主角陣營稱讚敵方的網路防禦機制。 

電影 口是心非 講的是商業間諜的故事，雖然評價有點兩極，但是有別於一般電影結局時主角們總是能夠來個奇蹟式的逆轉勝，口是心非的結局顯得有趣多了。雖然商業間諜的目標不一定是數位形式的資訊，但是以現今的商業環境而言，很多重要資訊都已經變成了數位的形式。由此衍生一個很重要的問題，資訊安全的範圍在哪裡？如果將數位資訊與傳統 (非數位) 資訊分開看待，那麼兩邊能否達到相同程度的保護是必須詳加確認的。另外一方面，如果將兩者一併看待，那麼負責單位的權責又該如何重新界定？這些問題沒有一定的標準答案，但是每個組織卻都必須找到一個最適合自己的平衡點。 此一議題我先在此打住，我今天要分享的是另外一個資訊安全的議題 - 社交工程。電影中有一幕是男主角這邊發現敵方陣營有一個獨立的辦公室，這個辦公室主要負責處理公司的出差及與旅遊事宜，其安全措施自然與總公司不可相提並論。但是對作戰而言，任何資訊都是不可放過的，所以男主角這邊決定前往竊取一些相關資料。男主角在電影中利用社交工程的手法，假裝在一個酒吧裡與該辦公室的女職員不期而遇。男主角表示自己因為來不及趕上飛機前往參加救助行動而煩惱不已，此時女職員自告奮勇提供協助，將男主角帶進辦公室前往處理班機的事宜。當然這一舉動，讓男主角取得了大門的密碼，之後順利取得所需的資料。

延續前一篇的話題，既然 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 即為第三集中出現的美女機器人)，我目前不得而知，但是人類會有危害他人的行為卻是由來已久。只要有利可圖，對有心分子而言沒有甚麼是不能做的，唯一的先決條件就是這樣的電子設備是否已經具備龐大的市場規模並可以衍生出相關的非法利益。很可惜的是，安全性通常不會是這類設備在設計之初的主要考量之一，所以只要時機成熟，問題一定會發生。身為資訊安全的從業份子也別太過灰心，甚至應該樂觀以對，畢竟這樣資訊安全的任務才更有挑戰性，不是嗎？當然，如果能夠讓廠商在設計之初，就把安全性的考量放進產品需求中，便可以大幅減少從錯誤中學習的痛苦。台灣以製造/設計電子設備能力見長，如果日後能夠強化產品的安全性，我相信在特定產品上會有更搶眼的表現。

最近 Facebook 火紅的程度，不但在網路界引起關注，連一般使用者與政府官員都不得不加以談論一番。其中最主要的助力來自於一款叫做開心農場的遊戲。嚴格說來，開心農場只是眾多農場遊戲中的一支，而且既不是原創也不是最好玩的一支。或許是因為中文化的關係，所以在台灣成了最受歡迎的 Facebook 遊戲之一。不過也因為不少人玩得過火，再加上”偷菜”這種不道德的行為，所以引發了公私部門的反彈。因此有人因為”偷菜”而寫悔過書，更有人因為”偷菜”而偷了飯碗。不論上層的理由為何，限制上班時偷閒並種種菜，對許多基層員工來說可是天大的罪惡，今天我要介紹一個很簡單的辦法，可以突破一般的限制方法。 首先我們看在一般的情況下，我們連到 Facebook 開心農場時，瀏覽器會使用 http://apps.faceboo.com/farmgame_tw/ 這個網址，這也是一般工具用來加以判斷或限制的依據。我們只要讓這個網址加以隱藏，就可以讓很多阻擋工具失效。使用的方法很簡單，只要透過一種叫做 Anonymous Proxy 的工具就可以隱藏你真正要進行連結的網址。

一般情形下連結開心農場所使用的網址

雲端運算 (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) 有所關聯。 除了技術上的優缺點，雲端運算在法律、政治、甚至於自由的議題上也有其爭議之處。但我個人認為所有的爭議最後終究會屈服在商業利益之下，也就是說有沒有商業利益才是其能否成功(或者說能夠獲得多大的成功)的唯一因素。 換另外一個角度來看，某項產品或服務到底是不是歸類為雲端運算，對大多數人來說根本也不重要。因為對大多數使用者而言，要的只是結果，至於叫什麼名字，讓廠商去傷腦筋就好了。

前面我們介紹過 PMD 與 FindBugs 這兩個用來檢視 Java 程式碼 (Source Code 或是 ByteCode) 是否有問題產生的工具，這次我要介紹的兩個工具則是著重在檢測註解本身 (JavaDoc) 是否符合要求。為什麼會有這樣的需求？或許長久以來對於程式註解要包含哪些東西以及要如何撰寫沒有統一的共識，但是對於良好註解的重要性我想幾乎沒有人會加以反駁。良好的註解至少包含兩個重點，一致的格式與清楚且有意義的內容。清楚且有意義的內容有些抽象，但是一致的格式卻是可以明確的加以定義，所以我們訂定的寫作規範通常也會包含註解的格式。只是規定訂定下去以後，是否所有開發人員都會確實遵守又是另外一回事。在Code Review的時候一併檢驗？Code Review應該是用來找尋必須人工檢驗的問題，對於符合格式這種可以自動化的工作，用人工來做可是吃力不討好。透過使用 DoctorJ 或 JCSC，我們可以把格式確認的工作交由程式自動化執行，除了快速方便外，更可以避免開發人員因為抱持心存僥倖的心態而沒有撰寫合乎規範的註解。 DoctorJ 與 JCSC 在使用上都相當簡單，主要是透過命令列的形式。JCSC 另外提供了一個 GUI 的工具可供修改檢測的規則，而 DoctorJ 則沒有辦法修改檢測規則。但是 DoctorJ 可以一次檢測目錄下所有的程式檔，而 JCSC 則一次僅能檢測一個程式檔。嚴格說來，這兩個工具在使用的方便性都嫌不足，而且兩個工具也已經沒有再更新，不過這似乎是使用社群開發軟體常會遇到的問題。也因此要不要使用這些軟體，只能自己先好好做個評估了。 DoctorJ 下載軟體。 解開下載的軟體。 打開 Microsoft Windows 的命令列模式。 在解開的目錄下，執行 ant install 指令進行安裝的動作。沒有安裝 ant 的系統需先進行 ant 的安裝。 雖然最後出現錯誤訊息，但是那僅是要將 jar 檔案複製時使用了 *nix 的路徑表示法，所以造成在 Microsoft Windows 無法執行。我們直接找到產生的 jar 檔案就可以了，該檔案為 share\doctorj\doctorj.jar。 使用 doctorj 很簡單，只要透過 java –jar doctorj.jar filename|path 就可以進行檢測。 不過因為 doctorj 會將結果顯示於畫面上，所以我們可以透過轉向機制將結果儲存於檔案中。
檢測單一的檔案
檢測整個目錄 使用文字編輯器打開儲存檢測結果的檔案。