最難的部分留到最後#
本書已涵蓋大量材料，有些相當棘手。但作者把最難的部分留到了最後。
- 保證（assurance）：系統會不會運作，而你如何確信這一點。
- 合規（compliance）：它的表親——你如何讓別人也相信這一點。
- 永續性（sustainability）：它會持續運作多久。
許多實務問題與這些相連：你如何決定出貨？你如何把安全與安全性案例賣給保險公司？你得維護它多久、成本多少？
在 2008 年版中，作者把這章叫作「評估與保證」，並在結尾說**「健全的漏洞揭露與產品更新流程，開始變得與上市前測試一樣重要」**。當時的重點是共同準則這類測試與評估方案。
那個世界如今奄奄一息：「一台裝置之所以安全，是因為五年前有人花了十萬美元請評估實驗室測試過它」的想法，在今天多數人聽來會覺得很古雅。保證不再是靜態的。
十年前，我們知道如何做兩種安全系統：
- 像手機與筆電這類含有軟體且連網的東西，它們算是安全的，因為軟體每月被修補一次；
- 像汽車與醫療裝置這類含有軟體但不連網的東西，你在上市前把它們測到死，然後祈禱最好的結果——因為修補意味著實體召回。
如今我們開始把汽車與醫療裝置連上網，所以它們也得線上修補了。
- 誘因至關重要，一如我們一再看到的。它們往往落在正式的保證流程之外，卻是「安全政策必須被定義於其中」之環境最關鍵的部分。
- 政策常被忽略：人們往往保護了錯的東西、或用錯的方式保護對的東西。
- 機制可能獨立於政策，但能靠讓某些政策選項更容易實作而與之互動。
- 保證是我們對「系統不會以某種特定方式失效」之可能性的估計。它傳統上是關於評估——在議定的安全政策與機制強度下，一個產品是否被正確實作。如今它越來越是關於廠商未來的承諾：這個系統會被修補多久、多勤？
可用性也不純粹是終端使用者的事，也是開發者的事。 許多漏洞之所以出現，是因為安全機制太難理解或太瑣碎難用。開發者常常不用作業系統的存取控制，而是直接以管理員權限跑他們的程式碼；當手機不允許這樣時，他們就為 app 要求太多權限；而密碼學常用 ECB 模式，因為那是許多密碼函式庫的預設值。
評估#
產品評估處理的是「檸檬市場」問題：當客戶無法衡量品質時，壞產品會把好產品趕出市場。
現代消費級產品，從防毒軟體到手機 app，都遠超出多數消費者的技術評估能力。若他們只打算靠品牌名稱，廠商還不如去買廣告，而不是雇用安全工程師。
警報與鎖、安全性評估體制、醫療裝置與航空
警報與鎖：
由於保險業承擔了火災與竊盜的大部分成本，誘因某種程度上是對齊的，雖然實務上這些實驗室很多收入來自測試費。
一個風險是慣性：標準可能跟不上進展。 以高安全鎖為例，2000 年的實驗室可能要求十分鐘的抗開鎖能力，卻對撞匙隻字未提。
德國等國的保險實驗室願意在攻擊變強時撤銷認證；在美國，他們似乎不太願意，也許是怕被告。一個產業容忍「標準會變」的意願，可能取決於其結構：一個只有少數大玩家的成熟產業，能比一個成長中的競爭產業拖延得多。
安全性評估體制：
- 藥品與醫療裝置的安全在美國由 FDA 管制，該局 1906 年由老羅斯福總統在記者揭露專利藥業的濫用後設立。結果發現全美最暢銷的藥不過是稀硫酸與松節油的溶液——製造起來超便宜，卻難喝到讓人相信它有效。
- 至於航空安全，第一步是 1931 年美國頂尖美式足球教練 Knute Rockne 死於結構失效造成的空難，引發公憤而導致國家運輸安全委員會的設立。FAA 則是艾森豪總統在 1956 年大峽谷上空兩架客機相撞、機上 128 人全數罹難後設立的。
- 至於汽車業，它成功推卸安全責任數十年。廠商競相用鍍鉻裝飾汽車，而不是裝安全帶，直到 Ralph Nader 的《任何速度都不安全》促使國會於 1970 年設立國家公路交通安全管理局。
歐盟已發展成全球領先的安全監理者，其機構為從航空、鐵路號誌到玩具的各產業設定安全標準。
醫療裝置安全：
這在 1980 年代因 Therac 25 醫療加速器中的 bug 造成三名病患死亡、三人受傷而受到矚目。 起因是一個以可用性問題浮現的軟體 bug：若操作者編輯機器參數太快，就能讓機器進入一個「對病患輸出過多輻射」的危險狀態。
如今最致命的醫療裝置大概是輸液幫浦，用來對住院病患輸注藥物與其他液體。許多致命事故是可用性失效。
看看兩台各自宣稱是「BodyGuard 545」的幫浦：要在左邊那台增加劑量，你按「2」；在右邊那台，你按「5」。 一間急診室可能有來自半打不同廠商的設備，全都有不同的使用者介面。醫師與護理師偶爾按錯鈕，錯誤的劑量被輸注、或八小時輸注的劑量被一次推完——然後病患死亡。
輸液幫浦殺死的人數與汽車相當，英國死亡數在低千位、美國在低萬位。
FDA 的工程投入預算大約是每台裝置半天，而廠商不會給工程師實際的裝置玩。那只是一次文書審查。 此外，可用性落在 FDA 的範圍之外——據說那是業界遊說「削減繁文縟節」的結果。「把兩台不同裝置當成同一個產品行銷」是把合規成本最小化的常見策略。
現在這裡有個有趣的問題：如果輸液幫浦殺的人跟汽車（或在美國跟槍枝）一樣多，為什麼人們不像對道路安全與槍枝管制那樣激動？
嗯，傷害既低調又分散。 在你當地的醫院，這類事故一個月大概殺不到一個人，而其中許多不會被注意到（因為用輸液幫浦的人通常本來就病得不輕）。當它們被注意到時，比較可能被怪到護理師頭上，而不是怪到「跟業務吃了幾頓好飯後、向半打不同供應商買幫浦」的醫務主任頭上。
航空安全：
這導致廠商標準化了駕駛艙設計，始於波音 757 與 767——它們從一開始就被設計得如此相似，好讓在一種機型上受訓的飛行員能飛另一種。
若護理師同樣被要求為每一款輸液幫浦取得型別檢定，那會花真正的錢；醫院主管就會注意，廠商最終會跟隨波音的做法，而許多人命能被拯救。
自波音 1997 年買下麥道、成為唯一製造大型飛機的美國公司後，FAA 已把自己的角色看成支持波音。 波音的工程師被允許接管過去由 FAA 做的大部分安全評估與認證工作。
併購更毒的效果是：麥道的高階主管接管了公司，總部從西雅圖搬到芝加哥，而公司不再由工程師經營，而是由財務人經營——他們已經毀掉過一家工程公司，而現在的目標是從這個新壟斷中榨出最大利潤。波音的傳統工程文化被邊緣化，該省的都省了。
兩起空難隨之而來（在印尼與衣索比亞），共 346 人喪生。原因讓人想起一個世代前的 Therac 案：軟體中的設計錯誤以危及生命的可用性失效浮現。
為了與空中巴士的最新機型競爭，波音需要快速讓 737 更省油，而這意味著更大的引擎、必須裝得更前面，否則就得重新設計機身、在法規上變成一架新飛機。新的引擎位置讓飛機在高速時更難配平，所以波音在飛控電腦中加入了叫 MCAS 的軟體來補償。
關鍵設計錯誤是只倚賴一個攻角感測器而非兩個（雖然這些常被地勤與鳥擊損壞）。實作錯誤是：在攻角輸入不正確時，飛機可能進入一個「飛行員需要在駕駛桿上拉約 50 公斤才能保持水平」的狀態。
這又被安全分析上的錯誤加劇：MCAS 軟體的非預期啟動未被預想到。結果波音沒做適當的失效模式與效應分析，而該軟體的行為甚至沒被寫進飛行員手冊。飛行員未受訓練如何診斷問題、或如何關掉 MCAS。
這是迄今世界上最大的軟體失敗，不論以人命損失還是經濟損害計。
從橘皮書到共同準則#
橘皮書評估在 1985–2000 年間於 NSA 進行，針對被提議供政府使用的電腦系統與密碼裝置這類安全產品。在誘因上，它是一個集體的「依賴方」方案，一如保險。
它設定了三個等級帶中的若干評估類別：C1 只意味著有存取控制系統；C2 對應仔細設定過的商用系統；B1 意味著強制存取控制；B2 加上隱蔽通道分析、從使用者到 TCB 的可信路徑與嚴苛的滲透測試；B3 要求 TCB 必須極小、防篡改、並接受形式分析與測試；最上層的 A1 加上形式驗證的要求。
系統的評估等級決定了它能處理的資訊擴散範圍：例如評到 B3 的系統能同時處理「無密、機密與極機密」或「機密、極機密與最高機密」的資訊。
政府使用者想要某產品被評估；NSA 分配人力去做；以傳統公務體系的謹慎與拖延，這可能要兩三年；產品若成功就加入已評估產品清單；而帳單由納稅人買單。已評估的產品總是過時的，所以市場一直很小，價格一直很高。
歐洲國家發展了 ITSEC，一個幫助其國防承包商與美國供應商競爭的共享方案。這引入了一項有害的創新——評估不是由依賴方（政府）安排，而是由廠商安排。
廠商開始四處比價，找「會給其產品最輕鬆過關」的實驗室，不論是靠問較少問題、收較少錢、花較少時間、還是三者兼具。理論上實驗室若偷工減料會被吊照。那從未發生過。
共同準則的細節與它出的錯
歐洲 ITSEC 模式勝過了橘皮書取徑。除最高等級外的評估都由商業授權評估設施（CLEF）進行、應在所有參與國被承認，而廠商付錢。
創新之處是支援多重安全政策。 共同準則不再期待所有系統都符合 Bell-LaPadula，而是對照一份「保護輪廓（PP）」評估產品——那是一類產品的一組安全功能需求與保證需求。你可以把它想成一份詳細的安全政策，但取向於產品而非系統。
受測產品被稱為「評估目標（TOE）」。檢驗的嚴謹度是「評估保證等級（EAL）」，範圍從 EAL1（功能測試即足夠）一路到 EAL7（不只要求徹底測試，還要形式驗證的設計）。商用產品常見的最高等級是 EAL4，而許多智慧卡被評到 EAL4+。
共同準則出了什麼錯：
- 多年來最大的抱怨是流程的成本與官僚。 一家想賣 HSM 這類裝置的新創，如今得花數百萬歐元與數年心力才能走完流程。實務上，共同準則已成為保護既有卡特爾的護城河。
- 其次是：除了迴避「技術性物理」面向（如發射安全或密碼演算法），共同準則也忽略行政性安全措施——實務上就是忽略可用性。 一般而言，使用者介面被視為別人的問題。
- 保護輪廓被其贊助公司設計來操縱市場。 智慧卡廠商要求 HSM 廠商也使用氣隙系統以推高其成本。這種操弄往往導致不安全的產品：廠商把 PP 寫成涵蓋他們容易做到的事。他們可能評估開機程式碼，卻把大部分作業系統排除在範圍外。
- 有時保護輪廓也許健全，但它對應到應用的方式並不健全。 歐洲 eIDAS 規則要求企業承認用智慧卡做出的數位簽章。這個應用的主要問題是缺乏可信介面。由於那個問題太難，它就被排除了，而最終結果是對「你 PC 中的病毒或木馬送給智慧卡的任何東西」做出一個『安全』簽章。
- 共同準則宣稱不假設任何特定開發方法論，但實務上假設瀑布式取徑。 對 PP 或產品的重新評估被宣告在範圍之外。所以它們無法應付正常的安全開發生命週期，也無法應付每月收到安全修補的商用產品。
- 準則是技術驅動的，而在多數應用中，該驅動保護決定的是業務流程。我們正在辛苦地學到：手寫紙本選票基於各種理由，遠優於投票機。安全是系統的性質，不是產品的性質。
- 評估的嚴謹度在各國之間差異極大，德國一般被認為幾乎不可能地嚴，荷蘭居中，而西班牙與匈牙利讓其 CLEF 給贊助者輕鬆過關。體制內沒人能公開這麼說而不引發外交事件，所以這無法被修正。
- 共同準則的品牌沒有被好好保護。 VISA 宣稱經共同準則評估過的 PIN 輸入裝置並不安全；GCHQ 的回應是：由於該評估未向他們登記、且這些裝置未被宣稱為「CC 認證」，那就不是他們的問題。
- 更一般地，關於責任歸屬什麼都沒有：「在認可中使用評估結果的程序，在共同準則的範圍之外。」
這種裝置有各種用途，從博取法官同情、從易受騙的政府那裡騙錢，到往人頭上敲。只是別想把嚴肅的重量壓在上面。
「最大自滿原則」#
他們的模型是一個三階段賽局：贊助者選擇認證者，認證者接著研究該產品並或許要求一些改變，最後終端使用者做出買或不買的決定。
大問題是：認證者之間的競爭會導致更好的標準，還是一場逐底競賽？
在多數情況下，「最大自滿原則」勝出：擁有者尋求單一認證者的背書，並抗拒任何要他們改善產品的嘗試。
只有在特定情況下競爭才能改善品質。 一個例子是 NGO 競相認證產品的永續性：在那裡，認證者比贊助者更在乎使用者的結果，而所欲的性質也不被單一贊助者強力控制。 另一個例子是菁英大學之間的競爭。
一家公司發明某個新產品並賣給一些客戶。客戶接著想要一個標準、以及一些能滿足其稽核員的測試。他們可能希望發明者把產品授權給既有供應商、或至少授權給第二供應商。其他發明者一擁而上，突然之間就有了一個專利池。
各公司為了把自己的專利放進去、以最大化其權利金份額而長期激烈談判；這往往導致既不安全又難以修補的糟糕標準。專利池可能變成阻止新進者的卡特爾。
簡言之，產業策略最佳化的不是好產品，而是壟斷或卡特爾。
Bob 會主張他並無過失，因為他依業界標準操作，所以不必賠 Eve。若 Charlie 曾為他的系統背書，這個論證就更有力。
所以 Charlie 的角色與其說是技術權威，不如說是責任盾牌。於是 Alice 只會做到剛好滿足 Charlie 的程度。Charlie 會與其競爭者競爭，而一場逐底競賽隨之而來。
一個有趣的案例研究是 Ben Edelman 對 Trust-e 網站認證方案的研究。他發現經認證的網站「更可能」而非更不可能試圖把惡意程式載入你的電腦。
逆向選擇把該方案變成了品質的負面訊號：較弱的廠商去認證其網站，而知名消費品牌懶得去。理由是 Trust-e 認證既然是自願的就很便宜，而認證的技術門檻也很低。
下一步#
歐洲通過了《網路安全法》，強化了歐洲網路與資訊安全局（ENISA）並把它放在其戰略的中心。ENISA 要充當專業中心，並與銀行、航空、能源與電信的部門監理機關以及資料保護機關聯繫。
作者預期這長期而言會極為重要，因為安全性與資安監理正在合流，而且無可避免會依部門管理。
英國政府多年來關切認證問題，但到 2017 年已得出結論：共同準則對安全既非必要也非充分，GCHQ 於是自 2019 年起退出贊助。
稽核員只能倚賴公司告訴他們的東西，而一家不知道如何保護自己系統的公司，只會說「我們有一套很棒的 X 流程」——即使他們沒有。
回想本書第一章提到：在企業世界，「可信系統」往往意味著保險公司可以接受的系統。也回想 NSA 有一套叫 Mugshot 的系統，爬遍網際網路尋找脆弱的系統。
Bitsight 為私部門做 Mugshot，但它不攻擊公司的系統，而是靠計算「有多少台伺服器未修補到最新、以及有多少其他淪陷指標可見」來為公司的網路安全風險評分。
他們已主宰保險市場的評估，因為他們給出單一數值評等——而此時循環性的保險業利潤被擠壓，再也無法讓客戶填寫冗長的資安問卷。
他們的評等為生態系帶來的誠實，比多數由政府與稽核公司推廣的方案要多，但有些有趣的副作用：例如服務公司如今較不願意贊助給學校辦的「奪旗」競賽——若 Bitsight 的爬蟲在你的 IP 位址空間中看到一台你為該練習所架設的脆弱標靶系統，它可能把你的 Bitsight 評等砍掉 10% 以上，那可能讓你損失真實的生意。
可依賴性的度量與動態#
隨著可依賴性成為一項終生性質，我們需要更好的量測方式。這有兩個主要面向：可靠度成長，以及漏洞揭露。
可靠度成長模型#
但大量的經驗調查顯示：在大型複雜系統中，第 t 次測試失敗的可能性不正比於
e^(−Et)，而是正比於k/t。所以可靠度成長得慢得多。由於
k/t的失效機率意味著約t/k的平均故障間隔（MTBF），可靠度隨測試時間線性成長。 這常被安全關鍵系統社群表述為：「如果你想要一百萬小時的 MTBF，你就得（至少）測試一百萬小時。」這一直是反對「開發無法在使用前被完整測試之複雜關鍵系統」（例如雷根總統的『星戰』飛彈防禦計畫）的主要論據之一。
若你能假設 bug 是統計上獨立的，那麼
k/t的可靠度成長就是可能的最佳情況；「需要一百萬小時測試才能得到一百萬小時 MTBF」的規則是無可逃避的。這可以看成「墨菲定律」的一個版本：從篩選過程中存活下來的缺陷數目被最大化。這些統計為軟體的演化模型與生物物種在選擇壓力下的演化提供了漂亮的連結，其中「bug」是降低適應度的基因。正如軟體測試移除了「與所施加測試一致」的最少可能 bug 數，生物演化也讓物種能以最小的早夭代價適應改變的環境，同時保存盡可能多的多樣性以助物種存活未來的環境衝擊。
例如若一群兔子被蛇捕食，牠們會被選擇為警覺而非快速。牠們速度上的變異性會保留下來，所以若狐狸進入鄰近地區，兔群的平均奔跑速度就能在選擇性捕食下急遽上升。
它也解釋了安全關鍵系統社群「測試結果往往是拙劣的效能指標」的觀察：測試者所量到的失效時間只取決於程式的初始品質、測試範圍與測試次數，所以它幾乎沒有進一步告訴你該程式在另一個環境中的可能表現。
還有一些出人意料、但事後看來顯而易見的結果：例如每個 bug 對整體失效率的貢獻，與「含有它的程式碼是否經常被執行」無關——直覺上，較少被執行的程式碼也較少被測試。最後，不同的測試者該平行而非串列地在一個程式上工作。
攻防的熱力學不對稱
假設像 Windows 這樣的產品有一百萬個 bug，每個 MTBF 為十億小時。假設 Ahmed 替伊朗革命衛隊工作，要造出闖入美軍網路的工具，而 Brian 是負責阻止 Ahmed 的 NSA 人員。所以他必須比 Ahmed 更早得知那些 bug。
Ahmed 只有半打人，所以他一年只能做一萬小時的測試。Brian 有完整的 Windows 原始碼、數十位博士、對商業評估實驗室的監督、CERT 的內線、與其他五眼國家的資訊分享協議，還經營著「派顧問去電力與電信這類關鍵產業」的計畫。這一切加起來相當於一年一億小時的測試。
一年後，Ahmed 找到 10 個 bug，而 Brian 找到 10 萬個。但 Brian 找到 Ahmed 那些 bug 中任一個的機率只有 10%，而他全部找到的機率微乎其微。而 Brian 的 bug 報告會變成一道消防水柱，以致微軟會找個藉口停止修補它們。
換句話說，攻擊者站在熱力學這一邊。
然而修好那一個花了好幾年（而且算不上真的修好），而新的漏洞一直出現。
逃離這個統計陷阱的一種方式是「簡單」——那把你導向強制存取控制這類政策、多層級安全郵件守衛這類架構等等。更現代的取徑是一個「觀察什麼壞了並迅速修好」的學習系統。那又意味著警覺的網路監控、外洩通報、漏洞揭露與快速修補。
敵意審查與開源#
一如我們在一個又一個案例中所見，攻擊者的動機至關重要：由「希望系統通過的人」所做的友善審查，與「認真試圖打破它的人」所做的貢獻相比，基本上毫無用處。
那正是「共同準則與 ISO 27001 中『由廠商從數家競爭評估者中挑一家付錢』的評估」根本上壞掉的基本理由。
回想我們對「稽核員長期無力偵測雇用他們之高階主管所為之詐欺」的討論。 一位靠放空 Wirecard 賺了一億美元的避險基金經理人 Jim Chanos 說：「當人們問我們稽核員是誰，我總是說『誰在乎？』幾乎每一起詐欺都被某家大型會計師事務所稽核過。」
- 前者的例子是 NASA 用於載人太空飛行的「獨立驗證與確效（IV&V）」計畫：承包商被雇來翻遍程式碼，並為找到的每個 bug 拿獎金。
- 後者的例子是核武指揮管制的評估：Sandia 國家實驗室與 NSA 競相在彼此的設計中找 bug。另一個是 IBM——它靠有兩個團隊（一個在紐約、一個在北卡）試圖打破對方的成果，維持了多年的密碼學領先地位，就像劍橋與牛津每年試圖贏得划船比賽。
- 再一個是 Google 的 Project Zero，該公司投入真正的工程力量，在其所倚賴的產品（如 Linux）與競爭產品（如 iOS）中尋找漏洞，並在 90 天通知期後積極揭露，以迫使它們被修好。這讓超過 97% 的漏洞被修好。
不過已確立的最佳實務，是用金錢激勵敵意審查，具體而言是透過漏洞獎金計畫。
自由與開源軟體：開放設計是否有助於安全？
英文第一本關於密碼學的書由克倫威爾的密碼專家 John Wilkins 於 1641 年寫成。他以這句話為「討論密碼學」辯護：「若所有那些易被濫用的有用發明都因此該被隱瞞，那就沒有任何一門技藝或科學能被合法地從事。」
1883 年 Kerckhoffs 的《軍事密碼學》建議：密碼系統該被設計成即使對手知道所用技術也不被攻陷；安全必須只取決於金鑰。
- 世界正走向更敏捷的開發風格（Eric Raymond 稱之為「大教堂與市集」）。
- 系統越來越複雜、工具鏈越來越長，所以你想抓的 bug 往往不在你寫的程式碼中，而在你倚賴的作業系統甚至編譯器裡，所以你也想能在那裡快速找到 bug。
- 若世上每個人都能檢視並把玩軟體，bug 就更可能被找到並修好（用 Raymond 的名言說：「眼睛夠多，bug 就淺」）。
- 要在這類產品中插入後門可能也更困難。
- 基於以上所有理由，開源對信心很有幫助。
許多開放產品可能沒有足夠的防守者，因為典型的志願者覺得開發程式碼比獵 bug 更有回報。其次，不同的測試者會找到不同的 bug，因為他們的測試焦點不同：志願者會看密碼學這類酷炫的程式碼，而聰明的網路戰士或漏洞獎金獵人會看裝置驅動程式這類無聊的部分。
在標準的可靠度成長模型下，我們能證明開放性對攻擊與防禦的幫助是相等的。 所以在給定應用中開放或專有取徑哪個較好，會取決於該應用是否（以及如何）偏離「漏洞獨立」這類標準假設。最終你得出去蒐集資料。
安全通過了所有這些測試。
所以雖然開放設計既非必要也非充分，它往往是有幫助的。 重要的一階問題是：有能力的人花了多少心力檢查與測試你所建的東西——以及他們是否把找到的一切都告訴你。這裡審慎的做法，是有一個慷慨的漏洞獎金計畫。
而有一個日益重要的二階問題：若你的生意依賴 Linux，你的某些工程師不該參與其開發者社群、好讓你知道那裡發生了什麼嗎？
流程保證#
任何做過系統開發的人都知道：有些程式設計師產出的程式碼，bug 比別人少一個數量級。也有些組織產出的程式碼比別人好得多。
雖然高品質與低品質開發者之間的某些差異來自天分，許多是被工作文化制約的。領導很重要；正如用財務人取代波音的工程領導層促成了 737Max 災難，作者也看過一個 IT 部門在其資訊長被一位官僚取代後士氣崩潰。
另一個問題是工程師品質有隨時間下降的傾向。 一個因素是光環：很多聰明畢業生想去新創而非大型科技公司。 另一個是人口結構：1990 年代初的微軟滿是長時間工作的年輕工程師，但十年後許多人兌現股票選擇權走了，其餘的多半成了家、只上班時間工作。
一整個顧問與稽核員產業把鼻子伸進了這個食槽。一如 ISO 27001，它是裝飾性而非有效的。
最好的情況下，它能為漸進的流程改善提供框架；但很常見的是，它是一場打勾練習，只是把混亂換成更官僚的混亂。
但可信的供應商很難認證。 政府認證者不能被看成有差別待遇，所以計畫會退化成打勾。私人認證方案則有強化卡特爾、或逐底競賽的傾向。
若你的工作做得好，你要如何讓別人知道？ 做高品質工作的小企業，通常在賣給最有辨識力的客戶時表現較好。簡言之，你通常得自己是專家，才能真正理解誰是高品質的提供者。
簡單的答案是：你得做真實的量測。
經驗上，新系統的可靠度往往先改善一陣子（因為較活躍的 bug 被找到並修好），然後在若干年間維持平衡，然後隨著程式碼變複雜、更難維護而劣化（軟體工程師有時甚至稱之為「衰老」）。
然而若維護程式碼的公司仍從中賺到足夠的錢、且有在乎品質的誘因，他們能靠重寫變得太亂的部分來修正這點——那個過程叫做「重構」。
安全性與資安的糾纏#
作者相信安全性與資安日益的糾纏，對我們的領域如此重要，以致自 2017 年起，他們把大一新生的安全性與資安教學合併了。
安全性是個比資安多樣得多的主題。 安全工程是個相當連貫的學科，而安全性工程隨時間分裂成飛機、道路車輛、船舶、醫療裝置、鐵路號誌與其他應用的各別學科。
它並未對「僅僅有我們前面討論過之安全問題」的 300 多款型號發布公告。
當你停下來想想，這相當引人注目：一個安全監理機關忽視一個「每年殺死數千名美國人」的問題，卻對一個「迄今沒殺死任何人」的安全＋資安議題驚慌失措。
也許人們直覺地掌握了那個原則：若對手能設計出觸發它所需的輸入組合，那麼「百萬分之一機率的意外致命事故」就給不了多少保證。
汽車的電子安全性與資安
一段 Consumer Reports 的影片顯示了 2009 年雪佛蘭 Malibu 與 1959 年雪佛蘭 Bel Air 的對撞測試：Bel Air 的乘客艙被壓扁、假人駕駛被方向盤刺穿——真人駕駛會喪命。拜五十年進展之賜，Malibu 的乘客艙保持完整；前方潰縮區吸收了大部分能量，安全帶與安全氣囊撐住了假人駕駛，而真人駕駛會自己走開。
作者放這段影片給大一學生看，以強調安全性工程不只是讓錯誤更不可能發生，也是減輕其效果。
接著是緊急煞車輔助（EBA）：若它認為你想做緊急停車就施加全力煞車。通常的演算法是：若你在 300 毫秒內把腳從油門移到煞車、然後施加至少 2 公斤的力，它就啟動。這是個簡單演算法，但更難評估，因為它試圖推斷駕駛的意圖。
較新的是自動緊急煞車（AEB），該在小孩或狗衝到你前面時把車停下。這更難，因為你在試圖理解前方街道上看到的一切，用的是結合傳統邏輯與基於深度神經網路之機器視覺系統的複雜處理。
加上車道保持輔助與主動車距控制巡航，你的車在高速公路上就能自己開。但你該如何測試那個？
不過實際數字有爭議。 一家保險鑑識公司對國家公路交通安全管理局提告以取得原始數據，研究後宣稱特斯拉提出、且被該局接受的分析只考慮了 13% 的資料。
完整資料顯示的不是「Autosteer 啟用後安全氣囊部署減少 40%」，而是增加 57%——從每百萬英里 0.76 次部署增加到 1.21 次。
它曾對 AEB 感到擔憂，怕若車輛在兔子衝到前面時猛煞，追撞會變多。但當資料從 2016 年開始進來後，保險公司放鬆了。
但精算成本不是公共政策的唯一驅動力。 政治人物開始擔心卡車司機的工作。哲學家開始擔心倫理：在行人與駕駛之間二擇一時，自動駕駛儀會保護它的駕駛嗎？
業界則擔心更新。 機器視覺的進展如此快速，你能想像每五年就得賣一整套新的視覺單元，因為我們現在的系統無法在五年前的硬體上跑。客戶會忍受「每幾年為新的自動駕駛儀付幾千歐元」嗎？
在 2015 年福斯排放造假醜聞（Dieselgate）——結果發現福斯在車上裝了軟體來作弊排放測試——之後，官員突然更不願意信任業界的保證。
威脅模型不再只是外部駭客，也包括廠商自己。
你要如何把好實務嵌入「從未需要思考遠方對手」的產業？ 那不只是設定最低標準的事，也是把安全思維嵌入標準機構、監理機關、測試設施與生態系中許多其他地方的事。那會是個漫長而艱辛的過程，一如汽車安全。
要讓「靠仔細檢查『英國標準手指』能否意外戳進電器」來工作的測試工程師，改以創造性的惡意來思考，會很難。
對的人必須信任它，而它必須嵌入社會與組織流程中，那意味著與更廣的系統對齊、並在夠長的時期內穩定持續。
其意涵是：監理機關該從「產品的測試」轉向「整體系統的保證」。
永續性#
多數兩年前的手機沒被修補，因為原廠與行動業者搞不定彼此。那麼我們到底要如何修補一輛「在丹麥鄉間待了十年、然後被出口到羅馬尼亞的 25 歲 Land Rover」？
這掀起了政治角力，因為汽車業不想為超過六年的軟體修補負責。
然而一輛新車的內含碳成本（製造過程中排放的二氧化碳）約等於其一生的燃料燃燒。而可以預見的是，一輛軟體未更新的車遲早不會被允許上路。
目前車輛報廢時的平均年齡約 15 年；若那被縮短到六年，環境代價會是無法接受的。我們甚至不會因為從內燃機轉向電動車而省下二氧化碳，因為電動車的內含碳成本更高。
若干其他利害關係人一直在抱怨軟體對消費品耐久性的影響，更新只在很短期間內提供、或根本沒有。
- 維修權行動者在為「消費電子裝置能在循環經濟中被再利用」而奔走，惱怒於科技公司用「安全」機制阻止維修、甚至濫用它們試圖讓維修違法。
- 消費者權益組織開始警告智慧裝置驚人的短壽命：你可能多花錢買一台「智慧冰箱」，卻在一年後廠商停止維護伺服器時發現它變成了一塊結霜的磚頭。
- 計畫性淘汰已是熱門政治議題。 燈泡過去撐得更久；利佛摩那顆百年燈泡從 1901 年就亮著。1924 年 GE、Osram 與飛利浦的卡特爾同意把燈泡平均壽命從 2,500 小時減到 1,000 小時，而此後許多產業效法了這種行為。
- 法國 2015 年把「縮短產品壽命」訂為違法；而在 Apple 2017 年承認曾用軟體更新讓舊 iPhone 變慢、促使使用者買新機後，它被起訴。2020 年它收到史上最高的罰款 12 億歐元。
商品銷售指令#
此後，銷售「帶數位元素」之商品的公司，必須在合理的服務壽命內維護那些元素。
措辭被設計成涵蓋商品本身的軟體、商品所連的線上服務、以及可能與商品通訊的 app。它們必須在售出後至少維護兩年，若那是客戶的合理期待則更久。
既有法規要求汽車與洗衣機這類耐久財的廠商至少供應零件十年，所以我們能希望新監理體制會要求至少一樣久。
指令的前言指出：「消費者通常會期待至少在『賣方對不符合負責之期間』內收到更新，而在某些情況下，消費者的合理期待可能延伸到該期間之外，特別是就安全更新而言。」
考慮到許多國家的汽車必須通過年度適路性測試才能繼續使用，而這類測試在可預見的未來很可能包括「檢查軟體是否修補到最新」，我們很可能會看到安全修補的要求延伸到十年以上。
新的研究方向#
自 1960 年代以來，拜摩爾定律之賜，我們幾乎把電腦看成消耗品。 這制約了我們的思考，從最低層的技術細節一路到最高層的政策。
我們把數千、繼而數百萬個電晶體塞進晶片以支援更精緻的管線化與快取。我們忍受又慢又沒效率的軟體，因為知道明年的 PC 會跑得更快。我們對壟斷聳聳肩，相信十年後的技術會與今天大不相同。我們像一艘郵輪，快樂地把垃圾扔進海裡，期待自己會把它遠遠拋在後頭。
摩爾定律如今已經沒力了。 CPU 效能的分析顯示：1978–86 年每年成長 25%，1986–2003 年高達 52%，但 2003–11 年放慢到 23%，2013–15 年 12%，此後 3.5%。
隨著派對散場，我們得開始清理垃圾。 那從「12 級 CPU 管線所造成的 Spectre 這類側通道攻擊」，經「我們臃腫軟體中累積的技術債」，一路到「驅動這一切的壟斷性商業生態系」。
有許多「設備長壽且更新不尋常」的環境，從石化廠到變電所。
建築與土木工程專案中的系統有點混合：有些廠商在做「盡可能穩定、維護 25 年」的 Linux 版本，而其他人在推動更積極的整體系統定期更新、並告訴我們「把一切放上雲端」。後者與「智慧建築」這個迷因相關聯，但有其自身的缺點。
一旦多個承包商與分包商需要線上存取「含有建築完整工程資訊——從變電所、空調到火警與防盜警報」的系統，就有明顯的風險。這些承包商中有些以國際規模營運，所以那裡一名被策反的員工或一台被 root 的機器，可能存取到數十個國家的關鍵國家基礎設施。我們對此自在嗎？
作為第一個試點專案，作者與同事處理了密碼軟體的維護問題。
TLS 二十年前就被證明安全，但此後每年大約有一次攻擊，多半經由側通道。 問題之一是密碼實作（如 OpenSSL）通常有「以固定時間執行密碼運算」的程式碼（好讓使用中的金鑰不會洩漏給外部觀察者），也會把含金鑰材料的記憶體位置歸零。
但每隔一陣子，就有人改進編譯器，讓它現在理解某些指令並沒做真正的工作。它把那些指令最佳化掉，於是突然之間數百萬台機器有了不安全的密碼軟體。
這極其惱人；你在外面與壞人搏鬥，而你的編譯器作者卻從背後捅你一刀，像後方的顛覆性第五縱隊。我們的工具匠該是我們的盟友而非敵人，所以他們想出了要如何妥善修正這點：由於 C 這類語言無法表達程式設計師的意圖，他們想出了用程式碼註記來做到這一點，最終做出了 LLVM 外掛形式的可行概念驗證。
在歐洲，每年約有五萬人死於道路交通事故，另有五十萬人受傷。全球每年約有一百萬人死亡。
由於汽車開始記錄控制輸入與感測器資料，關於一起典型事故有數 MB 的資料，但目前這些多半未被分析。
我們該以「學習系統」為目標。 我們一再聽到有人被自駕車以愚蠢的方式撞死的報導——例如 Uber 在亞利桑那撞死 Elaine Herzberg，因為她推著腳踏車走在路上，而其軟體只在行人穿越道上或附近才偵測行人。我們該能期待推送一次更新以阻止那再度發生。
在航空業，事故被監測，並回饋給飛行員與航管這類操作者、以及飛機與地面系統的設計者。目前我們在「有好幾起事故之後才修改路口」；那就是我們現有的全部『修補週期』。
當技術快速變化時，我們或許還能容忍對隱私與競爭的各種傷害。 若你不喜歡 1980 年代的 IBM 壟斷，你只要等到微軟出現；而等到 1990 年代末微軟成了『邪惡帝國』時，Larry 與 Sergey 正在創立 Google。
但隨著摩爾定律沒力，我們現在擁有的主宰廠商可能還會主宰一段時間——就像鐵路主宰了 19 世紀後半與 20 世紀前三分之一。我們需要更新我們對反托拉斯法的思考。
小結#
如今世界不同了。我們永遠沒做完，而任何說自己做完了的人都不該被信任。
美軍孕育了原始的橘皮書，並啟發了密碼模組的 FIPS 140 標準與共同準則。安全性認證方案則在若干產業（醫療、航太與道路車輛只是其三）分別演化。
廠商一直在玩弄這些系統，並在可能時致力於擄獲監理機關。如今一切都取得了連網能力，你沒有資安就沒有安全性，而這些生態系正在合流。
事情在緩慢改善。 回到 20 世紀，許多廠商從沒把資訊安全做對過。到 2010 年，較好的那些在第三或第四次嘗試時大致做對了。未來，每個人都會被期待在自家產品壞掉時合理迅速地修好，並在一段合理期間內持續這麼做。
正如安全經濟學是 2000 年代的熱門主題、安全心理學是 2010 年代的，作者預期安全的政治學會是 2020 年代及以後的成長主題。
研究問題#
我們真的不知道如何在「汽車與線上服務及手機 app 對話」這類複雜生態系中做保證。
第二束問題來自：隨著安全性與資安的世界緩慢合流（像兩個緩慢合併的星系），我們發現安全性工程師與資安工程師講不同的語言、有不相容的標準集、甚至有不相容的標準化取徑。要在一個又一個產業中把這件事理清楚，會花上數年。
太多研究者抱持「若不完美就不好」的看法。 我們有大批學者在寫關於可證明安全、形式方法與「因為無法規模化而不在野外出現之晦澀攻擊」的論文；我們有大量源於公司在開發上偷工減料的真實問題。
若程式設計師打算盡可能從 stackexchange 偷程式碼，我們是否需要一項公共利益的努力，去清理那裡的範例以除掉緩衝區溢位？
而我們是否有機會為密碼函式庫與裝置權限這類工具設定安全可用性標準，好讓（例如）預設使用 ECB 的函式庫被強制淘汰，就像 MD5 與 SHA1 那樣？