搜尋此網誌

2010年3月29日 星期一

[研究報告] 搬家多了一項考量,那就是資訊安全?

home-buying-guide-for-dummies 大家都常聽到選用甚麼樣的作業系統、應用程式可以比較安全而不容易被駭。不管這些論述是否公平與公正,但是至少其與安全的關連性並不會讓人產生過於突兀的感覺。但是說如果安全與否跟你所在的區域有關,可能就不是那麼令人能夠直接聯想了。根據 Symantec 日前所公布的一份報告顯示,在美國的 50 個城市中西雅圖  (Seattle) 是最容易發生網路犯罪行為的地區,其次則是波士頓 (Boston) 與華盛頓 (Washington, D.C.),而最安全的城市則是底特律  (Detroit)。在公布的訊息中並沒有詳細地解釋這樣的排名是如何加以決定,不過就結果來看網路化程度越高的地區排名就愈前面。這樣的數據老實說有些無聊,因為網路化程度越高本來就有更多受害的機會,所以自然產生的網路犯罪事件就多。對使用者而言,不管居住在哪個區域,都必須做好有關資訊安全的防護,畢竟駭客 (通常) 可不會因為你的國籍而改變心態

 

相關連結:

2010年3月28日 星期日

[新聞時事] Google 帳號異常登入偵測功能再提升

gmail_logo_stylized 常用 Google (Gmail) 的使用者可能會發現,從前一陣子開始在 Gmail 畫面的下方會出現帳號登入所使用的 IP 位址資訊。這些資訊可以提供使用者有關帳號的使用紀錄,立意雖好,但是對於一般使用者而言,IP 位址與無字天書一般,因此實際上的幫助並不是那麼大。

gmail ip address

 

Google 在日前將此一功能加以提升。如果 Google 判斷出兩次來自不同地區 (國家) 的登入時間間隔過於短暫的話,會出現一段警告訊息提醒使用者帳號可能已經遭到盜用。根據公布的畫面來看,這樣的警告訊息會出現在畫面的上方,而不是下方,而且會以很顯著的方式提醒使用者。此時使用者可以自行判斷是否確實發生盜用的行為,以決定後續的處理方式 (忽略警告訊息或是重新設定密碼)。需要特別提醒的是這樣的功能依舊屬於被動的機制,並不能真正防堵帳號遭受盜用,因此使用者還是必須做好保護帳號的措施,以免成為受害者。

warning

 

相關連結:

2010年3月24日 星期三

[新聞時事] 買保險套也不保險,Durex 訂單外洩

invoiceDurex 線上購物系統於日前發生因為程式設計的錯誤,導致任何人都可以直接透過訂單編號查看訂單內容的烏龍事件。嚴格來說,這應該不只是程式設計的錯誤,亦包含了程式變更管控不佳,而這種問題絕對比單一程式設計錯誤所產生的危害更加嚴重。此外,這個問題要實際產生影響,訂單編號的可預測性是一個很重要的前提。訂單編號的可預測性,表示在系統分析階段並沒有做好安全性分析。這麼說或許有些不公平,因為表單的編號通常會被要求採用流水號的格式,因此具備了可預測性。這樣的規則對於一個內部系統 或人工作業流程有其方便性,但是對一個外部系統來說卻是充滿危機的。針對這類問題,我們有兩個可行的作法。第一個就是把訂單編號對應到另外一個不具備可預測性的號碼,所有外部系統皆以此號碼作為訂單的查詢條件。第二個作法就是利用可逆的加密函式將訂單編號加以編碼,而外部系統皆此以編碼後的號碼作為查詢條件。比較令人訝異的是 Durex 對於整件事情的反應,從一開始的道歉到後來寄出法律信件給回報此一問題的使用者,讓人覺得 Durex 面對問題的態度很有爭議性。而且 Durex 似乎並沒有主動告知其他客戶訂單資料可能外洩的問題,明顯有失責之處。嗯,說到訂單資料外洩,台灣這邊的問題似乎也頗嚴重的。所以下次買保險套或其他私人用品時,可別再相信甚麼網路購物比較不怕被人知道而避免尷尬這種爛理由了。

 

相關連結:

2010年3月23日 星期二

[新聞時事] 線上廣告新用途 - 傳播惡意程式

top-logo 自去年九月紐約時報 (The New Year Times) 網站的廣告被用來當作散布惡意程式的管道後,線上廣告儼然已經成為有心分子的新大陸,各個線上廣告的平台都可以看到類似的問題接連發生。根據 Avast 最新公布的訊息顯示,線上廣告的大廠 Yahoo’s Yield Manager 與 Fox Audience Network’s Fimserve.com 也成為新一波的受害者,而這兩家合計擁有超過五成的市占率。除了這兩家外,Google 的 DoubleClick 也被 Avast 點名,並獲得 Google 的證實。這類透過線上廣告散布的惡意程式,有些並不需要使用者點選就可以進行感染的動作,所以除了廠商必須做好把關的動作外,使用者還是必須採取足夠的自保措施才能避免遭受危害。

 

相關連結:

2010年3月20日 星期六

[新聞時事] 車子發不動,駭客搞的!

vlcsnap-2010-03-25-19h37m10s39

在電影終極警探 4.0 中,年輕小夥子靠著呼攏客服人員順利”借”到一台車子。但是在現實世界中,卻有離職員工因為心生不滿而惡搞客戶的車輛,讓客戶的車子無法發動。這是發生在德州奧斯汀的真實案例,一個在德州汽車中心工作的員工,因為被公司解雇而懷恨在心,所以利用公司系統所提供的功能讓客戶的汽車無法發動。原先這個功能設計的目的是為了在客戶拒繳貸款時,能夠進行通知甚至鎖車以懲罰欠錢的客戶。只是沒想到這個員工在離職時,順手牽了另外一個員工的帳號,所以即使是自己原先的帳號已經被取消,仍舊可以進入系統並利用系統的功能進行破壞。這位員工運氣很好,取得資料庫的存取權限,所以受到影響的客戶高達上百人。這位離職員工已經被逮捕並加以起訴,而客戶除了遭受不便外,並沒有遭受財務或人身安全上的損失。

 

相關連結:

2010年3月16日 星期二

[研究報告] 雲端運算的七大安全威脅

thunder-9898-small

CSA (Cloud Security Alliance) 在這個月 (2010 年 3 月) 初發布了一份研究報告,標題是 “Top Threats to Cloud Computing V1.0”,列出了目前雲端運算所遭遇的七大安全威脅。必須特別注意的是排列順序跟威脅本身的危害程度沒有關係,而且使用者必須依據自身所處的環境決定這些威脅的影響並採取適當的控制措施。這些威脅分述如下:

  1. 濫用或利用雲端運算進行非法的行為 (Abuse and Nefarious Use of Cloud Computing)
    此一威脅主要是針對雲端運算服務的供應者而言。雲端運算服務供應商 (尤其是 IaaS 與 PaaS 供應商) 為了降低使用的門檻,通常並不會要求使用者必須經過嚴格的資料審查過程就可以直接使用其所其提供的資源,有些服務供應商甚至提供免費使用的功能或試用期。這些做法雖然可以有效推廣雲端運算的業務,卻也容易成為有心分子利用的管道。事實上,已經有包含殭屍網路、木馬程式下載在內的惡意程式運行於雲端運算的系統內。
  2. 不安全的介面與 APIs (Insecure Interface and APIs)
    使用者透過使用者介面或是  APIs 與雲端運算服務進行互動,因此這些介面與 APIs 是否安全直接影響到雲端運算服務本身的安全性。像是使用者介面的驗證與授權功能是否安全,APIs 的相依性與安全性,都是必須特別注意的地方。此外,如果有使用第三方的加值服務,這些服務的介面與 APIs 的安全性也必須一併加以考量。
  3. 惡意的內部人員 (Malicious Insiders)
    內部人員所造成的問題,這幾年來已經成為許多組織關注的重點,採用雲端運算將會讓內部人員所產生的問題更形嚴重。一個最主要的因素在於使用者無法得知雲端運算服務供應商如何規範與管理內部員工,甚至連招聘的條件與流程也屬於非公開的資訊。以安全的角度來說,”未知”絕對不是一種幸福,而是一種芒刺在背的威脅。更何況以雲端運算的業務性質而言,絕對是有心分子眼中的肥魚,所以內部惡意員工的比例應當會比一般組織來的更高。
  4. 共享環境所造成的議題 (Shared Technology Issues)
    雖然使用雲端運算的服務 (尤其是 IaaS) 時使用者好像擁有獨立的環境,但是這些環境都是從共享的實體環境中透過虛擬化的技術所產生出來的。這些虛擬化的平台能否將不同的使用者進行有效地隔離,以避免彼此之間相互干擾其服務的正常運算,甚至是避免彼此之間可以存取對方的資源,對雲端運算的安全來說是一個嚴格的挑戰。
  5. 資料遺失或外洩 (Data Loss or Leakage)
    資料遺失與外洩對於一個組織的影響不只在於實際上的金錢損失,更在於如企業形象之類的無形損失。雲端運算因為其特定的緣故,使得資料遺失或外洩的議題面臨更加嚴峻的考驗。包含是否擁有足夠的 AAA (驗證、授權、稽核)、是否採用適當且足夠的加密技術、資料持續性的需求、如何安全地刪除資料、災難復原、甚至是司法管轄的問題,都是必須認真加以考量的問題。
  6. 帳號或服務被竊取 (Account or Service Hijacking)
    儘管帳號或服務被竊取的問題由來已久,但是這類問題對於雲端運算來說更具威脅性。首先因為雲端運算不像傳統的 IT 架構般擁有實體的東西,因此一旦帳號或服務被竊取後,除非有其他的方式加以證明,否則惡意分子可以完全取代原先使用者的身分。在傳統的 IT 環境中,因為使用者至少還擁有硬體的控制權,所以即使發生帳號或服務的竊取行為,使用者還是可以進行一些事後的補救措施,但是這些補救措施在雲端運算的架構下可能無法執行。此外,對於那些公開的雲端運算服務而言,直接暴露於網際網路上也讓這些竊取行為更加容易發生。
  7. 未知的風險模型 (Unknown Risk Profile)
    如我在前面所述,以安全的角度來說,”未知”絕對不是一種幸福,而是一種芒刺在背的威脅。以雲端運算來說,不管是 IaaS、PaaS、SaaS 都是將服務包裝成一個使用者不需了解也無法了解的系統,讓使用者專注於如何”使用”該系統。但是這樣的方便性,也讓使用者無法了解這些服務所使用的網路架構、安全架構、軟體版本等等各式各樣的重要資訊。這些資訊對於評估安全狀態是很有幫助的,欠缺這些資訊將使得這樣的評估行為無法被有效地進行。

 

相關連結:

2010年3月14日 星期日

[教戰守則] 保護資料庫最重要的十個原則

the-divider

資料外洩的議題持續成為資訊安全的熱門話題,不但 DLP 相關產品獲得許多的關注,連資料外洩所造成的事件也同樣吸引媒體的報導。以現在企業資訊化的程度,很多資料都是以數位的形式散落於資訊系統的各處。在這些地方中,資料庫 (尤其是關聯資料庫,如 MSSQL) 內所存放的數位資料可能最為大宗,也最容易成為有心分子覬覦的目標。

Imperva 的安全策略長 Brian Contos 發表了一份文章,標題為”Top-10 guide for protecting sensitive data from malicious insiders”。不管標題為合,以 Imperva 的背景來看,所描述的內容自然與該公司的產品 (Database Firewall、Database Activity Monitoring) 有關。所以我們可以將這份內容所講的要項當作是闡述資料庫稽核的重要性,以及如何選擇一個合適的工具。也因此,如果你需要導入資料庫安全的相關產品,這些要項應該可以提供你一些參考的方向。

  1. 你必須先了解資料才有辦法保護它 (To secure it you have to know about It)
    也就是說必須先知道資料在哪邊,並做好資料分類的動作。
  2. 不要相信內建的資料庫工具 (Don’t trust native database tools)
    當資料庫遭受攻擊時,資料庫內建的工具也可能同時被成功地加以攻擊,因此需要一個獨立運作的工具以確保資料庫使用紀錄的安全性。
  3. 監視合法的使用者以及特權使用者 (Monitoring the good and the privileged)
    除了非法的使用者外 (不管是內部或外部),內部合法的使用者同樣會造成資料庫的危害。尤其在一個正常規劃的架構下,資料庫幾乎都是經由內部合法的使用者加以存取,因此監測的角度必須據此加以思考。此外,特權使用者因為擁有更大的權限,因此其使用記錄必須特別注意。
  4. 分析不再只是 FBI 的工作 (Profiling isn’t just for the FBI any more)
  5. 你不能逮捕一個 IP 位址 (You can’t arrest an IP address)
    各式各樣的資料庫與應用系統擁有不同格式的使用紀錄,必須擁有透過這些紀錄追蹤使用者連線 (Session) 的能力,才能確保事件發生時找到其源頭。
  6. 以人為導向的自動分析能力 (Augmenting machine-based analytics with human intuition)
    組織內不同角色的人員會從不同角度切入資料庫安全的議題,所以必須具備自動且多樣性的分析能力。
  7. 利用稽核紀錄了解犯罪現場的情形 (Forensic crime scene investigation through audit logs)
    透過分析的結果讓使用者可以快速了解:發生了甚麼事、事件發生的時間點與持續的時間、甚麼人可能參與了此一事件等重要議題。
  8. 機密的資料存放於資料庫內 (Sensitive data resides in databases)
    使用 Database Firewall (DBFW) 與 Database Activity Monitoring (DAM) 之類的工具來保護資料庫內重要的數位資產。
  9. 使用者透過 Web 應用程式來存取資料庫 (Users get to databases through web applications)
    因為使用者大多透過應用程式 (尤其是現今主流的 Web 應用程式) 來存取資料庫內的資料,因此如何確保 Web 應用程式的安全對資料庫本身的安全來說是一個很重要的工作。Web Application Firewall (WAF) 是一個不錯的起點。
  10. 大海撈針 (Needles hiding in stacks of needles)
    因為現今資訊系統的複雜度很高,所以如果沒有一個完整且全面的防禦機制並搭配上合適的工具,想要有效解決地問題將有如大海撈針般的困難。

相關連結:

2010年3月13日 星期六

[技術分享] RSA 1024-bit 私鑰在 100 小時內被破解

3-8-10-rsahardwarefaultattackgraphic

三位在密西根大學的學生於日前發表了一份有關破解 RSA 私鑰的論文,在論文中他們採用錯誤為主 (Fault-based) 的攻擊手法,以運行於 FPGA 上的 Linux 系統在 100 個小時之內成功地破解了 1024-bit 的 RSA 私鑰。Fault-based 的攻擊手法簡單來說就是想辦法讓攻擊目標產生錯誤,進而由攻擊目標的行為或輸出結果來找到隱含的秘密。在這次的攻擊手法中,三位學生利用改變系統電壓的方法,造成處理器運算錯誤而產生錯誤的結果。在收集到足夠的錯誤資料後,就可以利用這些資料進行破解私鑰的攻擊。1024-bit 的 RSA 依舊是目前 SSL 常使用的金鑰長度,不過還好這種攻擊手法需要先能夠取得實體環境的控制能力才行。除了硬體式的攻擊手法外,Fault-based 的攻擊方式也可以是軟體式的,亦即不需要取得實體環境的控制就可以進行攻擊。除此之外,許多攻擊手法也都會利用到 Fault-based 的觀念,想辦法讓系統產生錯誤並加以觀察,以找到可能有效的破壞管道。例如在登入頁面輸入一些特殊字元到使用者的帳號欄位中,觀察系統是否會產生錯誤以及相關的錯誤訊息,以便猜測系統是否存有 SQL Injection 之類的安全漏洞。所以如何做好 Fault Protection,不單只是產品穩定性的議題,同時也是安全性的議題。

 

相關連結:

2010年3月12日 星期五

[研究報告] 搞定人才有資訊安全可言

laptop_stolen_theif_theft_thief_lost_recover

根據一份由 Absolute Software 與 Ponemon Institute LLC 在前一陣子所發表的研究報告中顯示,人依舊是筆記型電腦安全的最大危害來源。儘管各式各樣的資安新聞事件已經讓越來越多的人注意到筆記型電腦對於資料外洩所產生的重大危害,甚至也導入了一些防範措施 (如加密技術),但是問題依舊存在,很多安全的使用規範並沒有被確實地加以了解或是遵守。

在這份長達 24 頁的報告中,提出了下列幾項主要的發現:

  • 高達 95% 的 IT 人員表示在他們的組織中曾經發生過筆記型電腦遺失或遭竊的事情,因而造成資料外洩的比例則為 72%。僅有  44% 的 IT 人員可以確認這些筆記型電腦有使用加密機制保護其中的資料。由這些數字交互比較後可以發現,即使經過加密技術的保護,依舊會導致資料外洩的資安事件發生。
  • 33 % 的 IT 人員相信加密技術就可以完全保護筆記型電腦中的資料,而不再需要其他的防護措施。針對業務經理而言,有這樣錯誤認知的比例更高達 58%。有時候對於一個工具過分的加以信賴,反而會帶來更大的危害。
  • 針對業務經理而言,有 36% 的人仍舊對於加解密的密碼沒有做好足夠的保護措施。像是把密碼寫在便利貼或是與其他人分享密碼,都使得加密技術的保護作用大大地減低。IT 人員在這方便的表現,明顯優於業務經理們。由此可見很多基本的資訊安全概念 (例如如何保護密碼),不但不可或缺,其重要性更不會因為採用新技術而降低。
  • 60% 的業務經理表示他們關閉了筆記型電腦的加密功能,其中 48% 更明白表示這樣作已經違反了組織的安全政策。顯見政策的規劃一定需要搭配適當的資訊安全教育訓練與查核機制,方能確保政策的有效落實。
  • 高達  55% 的業務經理在外使用筆記型電腦時,會將筆記型電腦留在陌生人附近而離開至其他地方。

原始報告可以在這裡下載

 

相關連結:

2010年3月7日 星期日

[研究報告] 研究顯示程式開發人員缺乏足夠的安全教育

imageson-20the-20job-20training-small-123

Veracode 將它們在近來一年半內所掃描過的程式結果進行分析,於本月初 (2010 年 3 月) 發表了一份報告,標題是 “State of Software Security Report: Volume I”。報告中有下列幾項重要的發現:

  1. 大多數的軟體是不安全的。
    以 Veracode 自行建立的測試方法而言,有 58% 的軟體是不安全的。如果採用 OWASP Top 10 (2007) 或是 CWE/SANS Top 25 Most Dangerous Programming Errors (2009) 的方式加以檢測,內部開發的系統有高達 88% 的比例無法通過測試。如何建立一個有效的安全軟體開發流程是刻不容緩的任務。
  2. 企業軟體架構中採用為數眾多的第三方軟體,而應用程式則使用了許多的第三方元件。
    不管是哪種形式的架構或軟體,第三方軟體/元件都佔有相當的比例。因此在評估上必須注意到這些第三方軟體/元件本身的安全性,以及如何與之進行安全的整合。
  3. 開放源碼在安全性方面並沒有與其他類型的軟體有太大的差距,但是在修正時間與 (疑似) 後門程式數量上的表現優於商業軟體或是委外開發的軟體。
    開放源碼在修正問題上擁有最快速的反應,而商業軟體則需花費最長的時間來修正問題,這個現象應該與商業軟體公司的生態環境較為複雜有關。因為開發源碼的程式碼為可公開取得的資料,所以在疑似後門程式的數量上同樣擁有最好的表現。不過不管是那一種類型的軟體,最好在導入前都能夠進行相關的評估,尤其是針對一些重要的系統,評估動作更是不可省略。
  4. 使用 C/C++ 程式語言所開發的軟體依舊佔有相當的比例,而這些軟體所含有的漏洞很容易被攻擊者利用以取得系統的控制權。
    C/C++ 是商業軟體中最常見的開發用程式語言,且在樣本中有高達 42% 的 C/C++ 應用程式含有可以引發遠端程式執行 (remote code execution) 的漏洞。對於內部開發的系統而言,C/C++ 程式語言所佔的比例則低了許多。
  5. 很多顯而易見且容易修正的錯誤充斥於各個軟體之間,由此可見開發人員欠缺有關如何進行安全程式設計的教育訓練。
    包含 Cross-site Scripting (XSS)、SQL Injection  這類存在已久的安全議題,依舊是軟體中最常見的安全性錯誤。目前已經有一些工具可供使用,以減少程式受到這些類型問題的影響。由分析結果可見開發人員對於此類問題與防範方法的認知誠屬不足,應該予以加強。
  6. 金融與政府部門的軟體相較於其他產業的軟體而言較為安全。
    這兩個產業的軟體雖然同樣還有很多必須加以改進的地方,但是也有不少可供其他產業參考的做法。
  7. 在受評估的軟體類型中,委外開發軟體所佔的比例最低,顯見合約通常欠缺有關安全需求的接受標準。
    雖然委外開發軟體的比例越來越高,但是在送檢軟體中所佔的比例卻相當低 (2%)。除了委外開發的軟體外,很多自行開發的系統/軟體也包含了這些委外開發的程式碼,因此其影響層面是全面的。針對這類軟體,將安全性需求與驗收標準明載於合約之中是一項很重要的工作。

 

相關連結:

About