在信息系統安全所涉及的方方面面中，有太多東西需要CIO、CSO們特別關注，面對來自各方面的提醒，很多人已經有些麻木了。但是，安全專家還是要再次提醒一下這些負責人，毫無疑問，有充足的理由證明，下面將要
探討的問題應該被列為他們的關注重點，這就是軟件安全（也有一些人稱為應用安全）。
CIO要介入軟件開發流程
也許有人會問，這些年作為信息安全主要負責人的CIO、CSO們不是一直在測試應用系統的安全嗎？為什麼還要說他們根本沒有考慮應用軟件的安全呢？這裡先進行一下解釋。
這 些年來，為了信息安全，CIO們的確已經慢慢接近這一層次，比如通過操作系統進入了網絡層，最近也開始考慮應用層。但是，這裡要說的是，這種「接近」太膚 淺了。是的，我們曾經購買了各種各樣的安全產品，我們安裝了防火牆，安裝了入侵檢測系統或者入侵防護系統，還有個人防火牆、反垃圾郵件和防間諜軟件系統、 防病毒等等，我們一直在不停地購買和安裝系統，我們希望某個產品或者某個軟件組合能夠保證我們業務的正常運營。
但是下面這個事實不可否認，今天我們的經營活動很大程度上是在應用軟件的基礎上開展的。儘管這些系統本身也在安全方面進行了充分的考慮，筆者也不提倡完全拋棄這些安全措施，但是我們不能希望他們能夠提供我們需要的應用軟件安全。
解決這個問題的唯一辦法就是儘早動手，親自參與到軟件開發的流程中去，也就是進入軟件安全領域，包括軟件的設計、開發和軟件安全性的測試等。
根 據筆者的經驗，由於採用了軟件外包，在大型企業中軟件開發工作不管是涉及的範圍還是開發量都在減少，對企業而言，只要軟件滿足了這些企業的需求就可以了。 因此，在大多數情況下，企業的CIO和軟件的真正開發工作聯繫並不緊密，甚至可以說很少有CIO會真正介入到軟件的實際開發過程中，除了在軟件已經開發完 成即將交付，需要對軟件進行所謂的安全測試以外。這時的測試通常是攻擊測試（Penetration Test），這正是目前我們在軟件安全上做得不好的地方。
要保證軟件的安全，就必須介入到從軟件產品開發的早期直到軟件的最終結束整個過程。現階段，我們很難看到有人這麼做，而事實上，的確需要這樣的工具（或者服務）。
這 聽起來很簡單但真正做起來卻並不容易。這一點比較容易理解，因為在達到這個目標之前所需要跨越的障礙實在太多了。CIO手下的人，即使最合格的信息安全工 程師，也很少能說在軟件開發上非常精通，他們並不瞭解究竟有哪些技術能對此提供幫助，而另一方面，對於開發者而言，他們缺乏對現代的軟件面對的攻擊工具和 技術的瞭解，不具備獨立地開發出能夠應對這些攻擊的軟件的能力。
跨越鴻溝
在開發人員和信息安全人員之間存在很大的鴻溝，這是一個真正必須跨越的鴻溝，其解決辦法也不像把IT人員送去參加軟件培訓或者把軟件開發人員送去參加「黑客家園」這麼簡單，實際上要比這困難而且複雜得多，這涉及到多個團隊或者組織的協作。
首 先，目前我們可以看到的軟件開發過程非常多，有崇尚個人英雄主義的非常原始的作坊式的開發方法，也有古板的程式化的軟件開發生命週期理論。儘管軟件過程各 異，但是這些方法都有一個共同點，那就是最後都會有一套產品拿出來。這些產品包括設計文檔（依據軟件過程不同，具體內容也不同）、軟件源代碼和測試計劃/ 結果。
如果仔細審查一下這些產品，我們就可以發現在安全方面還是有機會進行改善的，甚至有很多機會能讓我們改善軟件的安全性。下面對這些機會進行簡單的介紹。
需求 很多（但不是全部）軟件開發人員會把收集和整理功能需求作為軟件開發的第一步，他們會形成需求文檔或用例，用來描述用戶最終會如何使用該軟件。
這 一步是保證軟件產品安全的第一個機會。一種辦法是進行通常所說的濫用案例分析（Abuse Case Analysis）。這是一種簡單的辦法，其思路是考察軟件中的某些功能是否可能被攻擊者濫用。比如，假設有一個Web應用想在其中添加一項訂閱新聞組功 能。這一功能是有可能被攻擊者濫用的，比如，黑客用工具自動進行訂閱，可以訂閱上萬次，這樣下次有新聞組郵件發出來的時候，這個Web應用就會向這些訂閱 者發送，變成了一個垃圾郵件的製造者。如果在頁面設計和訂閱流程沒有考慮這些問題，其最終很可能給運行這些應用的企業帶來非常不好的影響。
設 計 幾乎所有的軟件開發者都會在把他們的設計整理成文檔，這裡我們也可以有機會從安全的角度對設計進行一次評估。正如人們所知道的，有幾種方法可以做到這一點 （這裡不再對此進行贅述），這些方法都有一個共同點，就是會進行深入分析，包括組件和接口等有可能被攻擊的對象。
在最低程度上，對設 計的評審至少要包括瞭解軟件所支持的經營活動、認真研究具體的設計、與設計人員進行溝通。另外，除了進行業務風險分析外還要進行技術評估等。一旦有所發 現，就要把他們立刻記錄下來，並區分出輕重緩急。如果有必要，還要對設計進行修改和完善，或者至少，針對這些風險要制定出相應的應對措施，特別是其中非常 關鍵的那些。
聽起來這像是老生常談，但是，除了極端複雜的情形外，只有軟件開發者們與信息安全工程師通力協作就能完成上述目標。
通力協作
編碼 很長時間以來，由於各種各樣的原因，信息安全的有關人員一直沒有介入到軟件的開發過程。而事實上，與開發人員一起對這個過程進行評審是信息安全人員最困難的工作之一，因為這需要對開發時採用的技術、編程語言等有非常深入的瞭解才行。
好消息是，現在已經有了幾個實用的商業軟件可以幫助開發人員分析他們的源代碼的安全性。開發人員和信息安全人員可以一起共同對這些工具的分析結果進行分析，並對分析工具發現的各種問題和可能帶來的後果進行評估，從而改善軟件的安全性。
測試 正如前面所述，今天很多的安全測試不過就是攻擊測試而已。甚至所謂的「應用攻擊測試」也不過就是一種「黑盒子」測試，使用一些我們已經非常瞭解的攻擊工具和技術從遠程對軟件進行攻擊。
但這是不夠的。在軟件測試領域，覆蓋（Coverage）是一種比較普遍用來對測試效果進行評估的方法。覆蓋包括很多方面，比如測試時運行過的代碼佔全部代碼的百分比。
根據覆蓋有關的理論，除非有特別的原因，攻擊測試只是安全測試的一個組成部分，它需要與代碼檢查、錯誤條件檢查、邊界檢查一起共同保證軟件的安全性，這才是一個完成的過程。
這裡，CIO的人需要發揮自己的作用。因為軟件測試通常屬於軟件質量保證隊伍的工作，而質量保證測試員更關注軟件是否滿足功能需求、是否符合有關的規範，換句話說，他們測試軟件如何工作，而不關心軟件如何被破解或者被別有用心的人濫用。
為了充分測試應用軟件的安全，除了功能方面外，測試計劃和場景必須考慮攻擊者如何進行攻擊，這也是需要負責信息安全的人參與的地方。
毫 無疑問，應用軟件安全這個問題很複雜，這裡只是觸及了皮毛。不過，最根本的問題是大多數CIO還沒有意識到要介入到軟件開發過程，從中發現機會與軟件開發 人員共同協作保證軟件的安全。另一方面，為了有效地利用這個機會，CIO們也需要對技術發展有充分瞭解。目前需要在企業中建立一種合作的環境和氛圍，而在 實踐中，我們聽到CIO的人和開發人員用太多的「我們」和「他們」來稱呼對方。很顯然，要保證應用軟件的安全，單靠開發人員，或者靠各種測試工具和產品都 是做不到的，需要大家的共同努力。
探討的問題應該被列為他們的關注重點，這就是軟件安全（也有一些人稱為應用安全）。
CIO要介入軟件開發流程
也許有人會問，這些年作為信息安全主要負責人的CIO、CSO們不是一直在測試應用系統的安全嗎？為什麼還要說他們根本沒有考慮應用軟件的安全呢？這裡先進行一下解釋。
這 些年來，為了信息安全，CIO們的確已經慢慢接近這一層次，比如通過操作系統進入了網絡層，最近也開始考慮應用層。但是，這裡要說的是，這種「接近」太膚 淺了。是的，我們曾經購買了各種各樣的安全產品，我們安裝了防火牆，安裝了入侵檢測系統或者入侵防護系統，還有個人防火牆、反垃圾郵件和防間諜軟件系統、 防病毒等等，我們一直在不停地購買和安裝系統，我們希望某個產品或者某個軟件組合能夠保證我們業務的正常運營。
但是下面這個事實不可否認，今天我們的經營活動很大程度上是在應用軟件的基礎上開展的。儘管這些系統本身也在安全方面進行了充分的考慮，筆者也不提倡完全拋棄這些安全措施，但是我們不能希望他們能夠提供我們需要的應用軟件安全。
解決這個問題的唯一辦法就是儘早動手，親自參與到軟件開發的流程中去，也就是進入軟件安全領域，包括軟件的設計、開發和軟件安全性的測試等。
根 據筆者的經驗，由於採用了軟件外包，在大型企業中軟件開發工作不管是涉及的範圍還是開發量都在減少，對企業而言，只要軟件滿足了這些企業的需求就可以了。 因此，在大多數情況下，企業的CIO和軟件的真正開發工作聯繫並不緊密，甚至可以說很少有CIO會真正介入到軟件的實際開發過程中，除了在軟件已經開發完 成即將交付，需要對軟件進行所謂的安全測試以外。這時的測試通常是攻擊測試（Penetration Test），這正是目前我們在軟件安全上做得不好的地方。
要保證軟件的安全，就必須介入到從軟件產品開發的早期直到軟件的最終結束整個過程。現階段，我們很難看到有人這麼做，而事實上，的確需要這樣的工具（或者服務）。
這 聽起來很簡單但真正做起來卻並不容易。這一點比較容易理解，因為在達到這個目標之前所需要跨越的障礙實在太多了。CIO手下的人，即使最合格的信息安全工 程師，也很少能說在軟件開發上非常精通，他們並不瞭解究竟有哪些技術能對此提供幫助，而另一方面，對於開發者而言，他們缺乏對現代的軟件面對的攻擊工具和 技術的瞭解，不具備獨立地開發出能夠應對這些攻擊的軟件的能力。
跨越鴻溝
在開發人員和信息安全人員之間存在很大的鴻溝，這是一個真正必須跨越的鴻溝，其解決辦法也不像把IT人員送去參加軟件培訓或者把軟件開發人員送去參加「黑客家園」這麼簡單，實際上要比這困難而且複雜得多，這涉及到多個團隊或者組織的協作。
首 先，目前我們可以看到的軟件開發過程非常多，有崇尚個人英雄主義的非常原始的作坊式的開發方法，也有古板的程式化的軟件開發生命週期理論。儘管軟件過程各 異，但是這些方法都有一個共同點，那就是最後都會有一套產品拿出來。這些產品包括設計文檔（依據軟件過程不同，具體內容也不同）、軟件源代碼和測試計劃/ 結果。
如果仔細審查一下這些產品，我們就可以發現在安全方面還是有機會進行改善的，甚至有很多機會能讓我們改善軟件的安全性。下面對這些機會進行簡單的介紹。
需求 很多（但不是全部）軟件開發人員會把收集和整理功能需求作為軟件開發的第一步，他們會形成需求文檔或用例，用來描述用戶最終會如何使用該軟件。
這 一步是保證軟件產品安全的第一個機會。一種辦法是進行通常所說的濫用案例分析（Abuse Case Analysis）。這是一種簡單的辦法，其思路是考察軟件中的某些功能是否可能被攻擊者濫用。比如，假設有一個Web應用想在其中添加一項訂閱新聞組功 能。這一功能是有可能被攻擊者濫用的，比如，黑客用工具自動進行訂閱，可以訂閱上萬次，這樣下次有新聞組郵件發出來的時候，這個Web應用就會向這些訂閱 者發送，變成了一個垃圾郵件的製造者。如果在頁面設計和訂閱流程沒有考慮這些問題，其最終很可能給運行這些應用的企業帶來非常不好的影響。
設 計 幾乎所有的軟件開發者都會在把他們的設計整理成文檔，這裡我們也可以有機會從安全的角度對設計進行一次評估。正如人們所知道的，有幾種方法可以做到這一點 （這裡不再對此進行贅述），這些方法都有一個共同點，就是會進行深入分析，包括組件和接口等有可能被攻擊的對象。
在最低程度上，對設 計的評審至少要包括瞭解軟件所支持的經營活動、認真研究具體的設計、與設計人員進行溝通。另外，除了進行業務風險分析外還要進行技術評估等。一旦有所發 現，就要把他們立刻記錄下來，並區分出輕重緩急。如果有必要，還要對設計進行修改和完善，或者至少，針對這些風險要制定出相應的應對措施，特別是其中非常 關鍵的那些。
聽起來這像是老生常談，但是，除了極端複雜的情形外，只有軟件開發者們與信息安全工程師通力協作就能完成上述目標。
通力協作
編碼 很長時間以來，由於各種各樣的原因，信息安全的有關人員一直沒有介入到軟件的開發過程。而事實上，與開發人員一起對這個過程進行評審是信息安全人員最困難的工作之一，因為這需要對開發時採用的技術、編程語言等有非常深入的瞭解才行。
好消息是，現在已經有了幾個實用的商業軟件可以幫助開發人員分析他們的源代碼的安全性。開發人員和信息安全人員可以一起共同對這些工具的分析結果進行分析，並對分析工具發現的各種問題和可能帶來的後果進行評估，從而改善軟件的安全性。
測試 正如前面所述，今天很多的安全測試不過就是攻擊測試而已。甚至所謂的「應用攻擊測試」也不過就是一種「黑盒子」測試，使用一些我們已經非常瞭解的攻擊工具和技術從遠程對軟件進行攻擊。
但這是不夠的。在軟件測試領域，覆蓋（Coverage）是一種比較普遍用來對測試效果進行評估的方法。覆蓋包括很多方面，比如測試時運行過的代碼佔全部代碼的百分比。
根據覆蓋有關的理論，除非有特別的原因，攻擊測試只是安全測試的一個組成部分，它需要與代碼檢查、錯誤條件檢查、邊界檢查一起共同保證軟件的安全性，這才是一個完成的過程。
這裡，CIO的人需要發揮自己的作用。因為軟件測試通常屬於軟件質量保證隊伍的工作，而質量保證測試員更關注軟件是否滿足功能需求、是否符合有關的規範，換句話說，他們測試軟件如何工作，而不關心軟件如何被破解或者被別有用心的人濫用。
為了充分測試應用軟件的安全，除了功能方面外，測試計劃和場景必須考慮攻擊者如何進行攻擊，這也是需要負責信息安全的人參與的地方。
毫 無疑問，應用軟件安全這個問題很複雜，這裡只是觸及了皮毛。不過，最根本的問題是大多數CIO還沒有意識到要介入到軟件開發過程，從中發現機會與軟件開發 人員共同協作保證軟件的安全。另一方面，為了有效地利用這個機會，CIO們也需要對技術發展有充分瞭解。目前需要在企業中建立一種合作的環境和氛圍，而在 實踐中，我們聽到CIO的人和開發人員用太多的「我們」和「他們」來稱呼對方。很顯然，要保證應用軟件的安全，單靠開發人員，或者靠各種測試工具和產品都 是做不到的，需要大家的共同努力。
