在前一篇文章中，我們看到解決一個問題的基本做法。但是有一個必須注意的事項就是，通常原因背後還有其發生的原因，或者換個角度說問題後面還有問題(QBQ - Question behind Question)。所以我們必須發現的可能不是一個原因，而是一堆(可參考 Root Cause Analysis)或一連串的原因(可參考 Fault Tree Analysis)。既然如此，我們怎麼知道是不是該往下繼續找出原因背後的原因呢？除非發生問題的事物有明確的邊界，否則這個問題並沒有很明確的分界點，往往得靠自己的直覺加以判斷。不過，基本的準則是至少要把原因分析到你無法掌握或改變的事項。至於解決方法是不是一定要斬草除根呢？我認為倒是不一定，理由後述。
再以程式開發為例。當我們發現交付給客戶的產品 (軟體)有一個程式寫作的錯誤時，除了修改程式外，我們更可以(應該)分析為何這樣的錯誤沒有在交付客戶之前就被發現。所以問題變成了品管的問題，甚至是品質保證、流程管控等議題。這些議題涵蓋範圍之廣，已經足以影響整個工作的流程，而不僅僅是修改程式那麼單純。
在我自己軟體與資安產品開發的工作經驗中，經常需要解決所謂的”問題”。雖然問題種類有各種形式，但是在面對這類問題時通常都有一定的方法可以遵守。很可惜的是，大部分的人都憑著直覺在解決問題，而直覺很多時候其實也並不是那麼直覺。甚至有人說，解決問題是一門藝術。真的是如此嗎？不只在工作上，其實在日常生活中我們也常常需要面對問題、解決問題。一個看似簡單的動作，往往卻存在了很多必須小心應付的陷阱。稍有不慎，輕則問題依舊，重則問題一發不可收拾。
以我個人從事軟體開發的經驗而言，因為軟體是大多數使用者接觸系統的”介面”，所以通常一遇到問題就認為是軟體的問題。更不幸的是，程式設計師通常又是軟體的最直接關係人，所以問題不用考慮就是丟到程式設計師的身上。而此時，程式設計師就必須具備良好的問題分析能力，才能將問題的責任歸屬釐清，甚至是解決問題。此外因為軟體是架構在硬體、作業系統、相關協定(如網路協定)之上，如果對這些底層的技術沒有一定的了解，往往除了啞巴吃黃蓮外，更無法解決問題。
在去年底的時候，有密碼專家宣稱可以破解部分 WPA (Wi-Fi Protected Access) 的加密機制。時隔近一年後的現在，有日本的研究員 (Toshihiro Ohigashi 與 Masakatu Morii) 宣稱可以在一分鐘之內破解使用 TKIP 機制的 WPA 加密機制。此兩人已經於日前在中山大學舉辦的 Joint Workshop on Information Security 會議中發表了他們採用的方法與理論，並預計於 9/25 作進一步的討論與說明。
經由此一研究報告的揭露，等於正式宣告 WPA 不再具備提供保護資料機密的能力。雖說攻擊方法侷限於使用 TKIP 機制的 WPA 標準，但是由於 WPA 正式的標準只規範了 TKIP 的機制，所以比較保險的說法就是放棄 WPA ，而採用較為安全的 WPA2 規範。 WPA2 使用 AES 作為資料加密的演算法，是目前已知相當安全的演算法。
