「專業」就是有知識，以及不斷更新的經驗
這兩天很急促的吸收及思考了許多關於平台保護的事。經過2代組織的更迭，我不僅曾經是個開發者，也曾經是參與設計的一部分，直到現在我不得不變成主導者。雖然我不是這一塊的專業，但我有足夠的責任感，願意承擔這個重任，去做任何我應該去做的事。就像之前在「儲備幹部研討會」的課程中，我教給學員關於《責任》的定義那樣。如果現在有這個難關就在眼前，必須有人出來有所回應(Response)，而我是那個有能力(Ability)的人，那我就應該要站出來承擔。
產品保護這件事，我們本來以為不是太困難的事，只要抓好正確的方向，我們自己有能力可設計及實作。在8年後產品才被破解後的今天，並不能說是”錯了”，但我們確實有些不容易看見的疏失。才導致今天大家都承受著極大的壓力，每天都分秒必爭似的問接下來要怎麼辦？產品還要不要賣？下一步的行動方案呢？何時要同步進度？…
在分析這次被破解的根因後，確認最明顯的一個疏失就是「雞蛋放在同一個籃子裡」。
EFUSE在晶片廠的保證中，是不會被抽取金鑰出來的。「開蓋(Decapsulation)」這種物理式的破壞，並不是我們不知道，而是我們認為那成本太高，不用列入考慮。8年後的今天才被開蓋，我們不能說過去的觀念是錯的，但我們疏忽的一件事就是「開蓋」對破解者的成本是很高，但對我們的成本，也很高。這「成本很高」不只是錢的問題，最重要的是這個前提，讓我們沒有預留「反應空間」。這有點像是…我們不想花時間去關心滅火器的鋼瓶氣壓或裝藥的保存期限，直到8年後的今天真的失火了，我們才發現噴不出東西來，然後現在急跳腳要找東西滅火一樣。
當然，這對我們而言，是一次寶貴的「黑天鵝」事件。開蓋成本很高，但我們不能當作是不會發生的事。我們的規劃不能再認為金鑰放那邊是安全的，而是從Day1開始就必須是「分散式保護」的思維去設計，也就是所謂的「反脆弱」。認證鏈的”強度”很高，並不代表整個產品的保護”韌性”夠高。
我自己覺得另一個疏失是對「專業」的忽視。
今天我們的產品是遊戲，我們的專業自然不會是平台保護或資訊安全。即便我們學了些重要的正確觀念，可以設計或實作自己的的保護架構，但終究會像今天被開蓋的晶片一樣：那就是8年前的設計了。今天我們要設計的是超過5年以上，這種關於產品生命的超長期的保護架構，我們無論如何，似乎都不應該由自己操刀來做這件事。我們既然不會請一個年資不到3年的軟體工程師，來設計我們整個app平台的系統架構，那我們為什麼會覺得，防盜版的資安措施，是我們自己可以處理的，是我們可以省下來的一筆花費？
這幾天常跟保護鎖原廠請教問題，他們除了能細心的回答以外，也能提出許多實務經驗，客戶常犯的毛病，以及成本效益的甜蜜點(Sweet Spot)在哪裡。我相信對於保護該怎麼做，他們也一定是與時俱進的，不會像我們抱著過時的觀念，一點準備都沒有。我想這就是我們該尊重的專業，不只是知識的部分，更重要的不斷更新的經驗。
這次的解決方案雖然是個「極短期」擠出來的東西，但導入專業第三方來設計，或許是我們早應該看待的一件事。