觀點

啟動防護 程式安全的新世代之(二)程式開發人員應該知道的3件事

2010 / 04 / 30
吳依恂
啟動防護 程式安全的新世代之(二)程式開發人員應該知道的3件事

最近聽到消息,有兩個資安人員都恰好高升,當了開發單位的頭,不知道這是一個巧合,還是需求?近來還有不少程式開發人員紛紛報名軟體安全開發課程,只是在軟體開發與資訊安全兩個領域間,真正的專家卻不多,本來就不懂資安的開發人員也很難辨別對方的程度,一名興致勃勃前往聽課的資安顧問對筆者分享他的上課心得,「寫 AP 的人出來講資安,有些論點不是很正確,不是全錯啦!只是有一兩點的解法怪怪的。」兩塊領域皆精通的人,為數甚少,這是一塊新的領域,也會是未來的方向。

 

關於軟體安全開發,不僅僅只是資安人員的事,只要深入了解就會發現,開發人員在每個階段,都必須深深涉入其中,這也是Programmer必須了解的。

 

老闆你知不知道?

程式開發人員知不知道資安很重要?都知道。可是為什麼不做?因為手上還有很多工作,因為老闆沒有說要做,因為要改的東西太多了,因為要花很多時間,因為很麻煩...等。程式碼安全的掌握,其實最多還是在開發人員身上,資安人員儘管知道哪裡有問題,能夠迅速且有效解決的,最終還是最了解程式結構的開發人員,只是,如果沒有高階主管或組織文化對資安的支持,資安人員終究孤掌難鳴,這也是高層主管所應該要理解,所要扮演的角色-衡量業務開發效率與安全的天秤。

 

遊戲橘子資訊技術處處長丁瑋明就提到,過去由於各部門的委外工作都是各自發包,在發包單位以及委外廠商都沒有資安意識的狀況下,寫出來的不安全程式當時也造成資安很大的問題。後來,接受委託的廠商都必須按照橘子開發人員所制定的函數來開發,並且經過他們code review的動作才能上線。

 

開發人員應該知道3件事:

而改善的開發工具-源碼檢測近兩、三年來也慢慢進步,不僅變得自動化、找到問題的機率變高,誤判率也變低,也因此採用工具的企業有逐漸增加的趨勢,那麼,又該如何善用這項工具呢?

 

儘管大部分的單位都願意把資安預算放在教育訓練上,但是由於課程品質跟成效也非短時間內可以衡量,所以最後到底程式開發人員懂不懂,或是有沒有照建議寫法寫,只能透過從外或從內的稽核。而大部分的稽核都是做制度面、文件的,像是ISO 27001,目前沒有並沒有一種技術性的稽核去管你程式寫得怎樣?很多管理文件都屬於很流程面的東西,卻不是在開發程式時的技術細節

 

1 白箱工具有助於開發人員理解

現階段,資安顧問多半就會採用白箱工具來達到完整稽核的目的。即使是通過國際安全標準驗證,文件上也只會寫例如「提供之服務,需修正程式弱點後方可上線」或「不可具有SQL InjectionCross Site Scripting等弱點」,類似這樣的「規範」。但沒有一家會細到去描述「怎麼寫才不會產生弱點?」也因為這樣,在專案裡面往往都還需要人力,在工具掃出來之後,顧問可能會告訴你要怎樣改,或是哪些要優先改?瑞百通資安技術長蕭智仁表示,資深的軟體開發人員也不見得都懂資安,資安顧問也不是那麼熟軟體開發設計,所以在這段過程當中,資安顧問與開發人員來來回回的討論,雙方互相激盪出來的結果,就會是這個組織的know how。

 

例如說要做資料庫存取時,或是要把東西輸出到螢幕時,就有些特定動作要做,以及當做這些動作時,常會發生什麼樣的錯誤,如何安全的寫?有些寫法就是程式人員開發出來的,剛開始資安顧問會告訴開發人員,這個地方輸入輸出沒過濾,就加個字元過濾。那難道程式裡面有5,000個地方,就全都要加嗎?最了解程式結構的還是莫過於開發人員,所以後來也都是第一線的開發人員自己寫一個函數,來迅速的收斂掉這些問題。 

 

鍾榮翰說,以過去協助10幾個單位經驗來看,即使包含各種語言(ASP、.NET、PHP、Java)的環境下,經過他們分析出來,發生同樣錯誤的樣態大概不到20種,所以技術並沒有預期中的那麼難。主要是在於個人的程式撰寫習慣問題,當初學校老師就沒教,再到業界來也沒要求,就會成為問題。

 

除了一個新專案的開啟,當然還有更多部份是已經開發完成的軟體。過去鍾榮翰曾參與過10幾個政府單位的軟體安全改善計畫,發現在白箱工具的協助之下,開發人員也比較能夠接受程式碼漏洞的問題。不過有些開發廠商基於成本考量,也會拿免費工具來輔助做掃描,但效果差很多,可能100個漏洞裡面只能掃出50個,Open Source的工具較為不成熟,堪用的目前還是只有商用工具。

 

資安廠商多半會有些範本(template),有些code review工具掃完之後會告訴你哪行有問題,但改還是要自己改,不過由於這些是制式的範本,有可能程式照著建議套上去改以後,不一定會動,這是由於程式邏輯、或是程式面的寫法不同的關係。最好的方法就是掃出來,可以直接給一個標準答案,劉俊雄說,這是他認為code review廠商應該要努力的地方,裡頭會有些編譯引擎可以根據你的寫法,提供標準答案,因為寫法是可以收斂的,並不會發散到幾千種,在技術上的理論上應該是可以做得出來,只是這塊市場的成熟度還有待考驗。

 

2 將技術細節化零為整(SOP)

很多開發廠商為了要快速因應這幾年出現的資安需求,也沒有辦做好教育訓練,只好先寫好一個大概的安全檢查程式,檢查單引號濾掉、特殊符號濾掉等,做一個大略的檢查,但仍有不足或闕漏,只能期待未來可以納入標準流程,而這類函數都有可能必須配合開發平台跟開發目的,需要微調。 

 

此外以目前業界現況看來,被委外的軟體開發廠商(Independent software vendor),幾乎都是因為業主要求而被動的去改善資安,否則無法通過驗收。

 

曾經就有一個案例,是某單位有大量的應用程式交給同一間委外廠商,檢測出問題之後,要求不能再有類似問題發生,否則就不再續約,在評估過長遠效益後,該ISV才購買相關工具。


資拓科技便是承接不少政府委外專案的系統整合商,目前正在進行軟體安全開發生命週期的規劃。資安顧問周祥清提到,品質政策越嚴謹,成本就越高,但很少公司會投入太多成本,一旦進入品質政策,則所有案子都要進行資安的檢核,所以一般都是將軟體品質保證跟資安分開,但資拓目前正打算將資安放到品質政策當中,確保往後的開發流程當中,都會有資安的規範包含其中。

 

很明顯的,一來這種臨時性的安全檢查程式尚有不足,二來,沒有人統整這些技術細節,其實,為了避免出錯或是安全問題,各個程式設計師可能都會有自己一套的防範措施,但不一定每個設計師所看的到的點都相同,一定會有疏漏,所以可能某A產出的有問題1,某B產出的有問題2,而有的人可能根本就不知道要防範。所以必須將這些零碎片段,不成文的訂成文,並且將程序建立的更嚴謹,這便需要有人站出來統整這一塊,把它明文規定之後列入Regular SOP,未來大家只需要針對此SOP去做修正補訂即可。

3 訓練再訓練   教育成習慣

最後,則是如何把這件事情視為業務活動的流程之一,在自我開發或委外過程,甚至必要的時候去尋求第三方公正的認證,將這套系統安全改進的過程,轉化成教材、教育訓練,而習慣問題就是要透過訓練來解決,所以後期就會推導出一些secure coding的課程,成為組織文化,避免下一個新進人員,造成這個循環裡的新問題。

 

過往累積的這些know how,如果可以針對弱點有效的改善方式,在新的軟體開發或是維護過程中,把這個機制加進來,重新一直審視,刺激它形成一個小的生命週期循環,問題才能很快的去收斂。

 

 

 結論:

儘管軟體安全開發的技術流程在實務上的落實是相當困難的,重視安全的單位,依然會想盡辦法克服。

 

敦陽科技資安資深資安顧問楊伯瀚提出他的看法,困難點主要在於台灣的開發環境問題,就像為什麼印度的軟體規範可以做得很好?因為印度的專業軟體外包廠商把程式的撰寫,包括用什麼語言寫,寫作方法、怎麼呼叫函數,都是制式的規範,每個programmer有固定的分工,都只是其中的一個小螺絲釘,即使是換了程式開發人員,軟體開發計劃都還是可以按照原先的規範來進行,唯有在這種模式之下,軟體安全開發的標準作業流程會比較容易被達到。而由於要付出的時間和成本高昂,其實在越小的單位裡才越有可能執行。中國文化大學推廣部科技研發中心主任邢溢將也說,採行方法論雖然很好,但也會面臨到相當耗時、耗成本的問題,於是僅能在少數的特殊專案時施行,例如說金流系統。

 

不過,目前已經有些金融、電信業者,早已將這樣的安全考量放進程式開發標準流程,例如只要呼叫資料庫或是做什麼處理,就一定要按照該標準範本寫,若不這樣做就驗收不過,在這樣的要求之下,的確是會達到一定的安全效果,只是問題在於,世界上並沒有所謂的統一標準範本,根據開發環境及需求等因素,只能各家自己做,無法大量的被應用。而要做到上述的整合,勢必得要資安與開發團隊配合,從此,也可看出一家公司對於資訊安全的重視態度。這些技術細節散落各處,很難加以管控,勢必還是得要進行統合

針對軟體開發安全生命週期標準規範,已有些較有資安觀念的單位開始動作,今年已有金融、電信業者正在推行中,預計在下半年可以看見更進一步的成果。