~ 前言 ~

這篇我本來想一篇寫完。結果發現內容不少，要分幾篇寫。第一篇從問題陳述 Problem Statement 說起。

筆者在業界工作廿多年；在教內也廿多年。經常參與 NGO、機構、教會、事工的科技支援；或參與本地的 hackathon。也提供過軟件和科技服務給十數間教會或機構。而現在仍活躍於在教內不同場合提供科技意見。

機構對科技是又愛又恨的。愛是感知科技的能力。恨是總是能摸（或只能聽）而不能得。而又似乎是要花很多錢才能得的專門科技。但外購 outsource 回來的軟件套裝又總是很不合用。然後在教內找個能問能幫手的人都很難。

~ 三個迷思 ~

機構面向科技，常見三個現象。三項我都用粗點體框起了重點。可以方便簡化跳看。

~ 現象一：簡化生產過程 ~

由例子說起。舉例說，例如會聽到人說，找人開發社交媒體軟件。他的意思不單是軟件本身，而是他的意思是開發完，就會有數十萬或最少數百萬用戶（設計對白：相比 facebook 的十數億用戶來說，不太難吧）。這事平白來說，就是忽略了營運和營銷過程。而且設計、數據、客服等等那些全部忽略。

上例聽起來誇張可笑。但是有時聽外行人找科技，都真的這種想法。

重點是：誤解方法。這不單浪費了機構或業界的資源。也使業界長期也不能突破運作和營運上的科技樽頸。

~ 現象二：簡化條件因素 ~

遇過不少例子，是來找筆者協助之前，是去找了或聘請了個工程師，然後期望他能提供一條龍服務。結果跌到一地，便來找筆者作友好協助。

問題是，業外人不太明白工程師的工作範圍，和開發一個軟件的環境需求：

1. 技術那些還算了，但軟件發佈包含非技術部份：設計、美術、營銷、數據、項目管理、客服、公關、文案等等。
2. 技術範圍內還有：工程、雲端、資安、架構、運維、等等。都不單是一個年資淺的工程師可以完全肩負。
3. 技術那些，例如架構或運維，經驗少於五年的都差不多 99% 會製造技術債務。
4. 而且機構通常都為便宜而聘請剛畢業不久的大學生。

重點是：團隊需求。建設一個科技系統，正常來說需要一個團隊來做，而不是一個人。而且就算是科技業內，高薪挖角也往往找不到好人才。何況非牟利機構。

可能非科技行內的讀者看上述名單會看到頭昏腦脹。不要緊。可以只看這篇的幾個主要標題，然後跳過去看下篇。以上這些都會在之後的篇章，講解流程與方法。這個欄目就是為這而寫出來。

~ 現象三：簡化代價 ~

在 Hackathon 中會常見這現象。機構找免費專業協助，軟件設計上容易將需求開到很闊。例如第一版本已是開個 3-6 個月或以上、4-5 人員的需求。計出來就是 12 – 30 個 man month。試想想，若以十多年前的公價計算：手機軟件 100K man month；網站 50K – 80K man month。計出來都會是高昂的開發成本。港幣計算。

即是，若這項目是找外判公司，是需要這個收費。或倒轉說，免費的人員，若他是有能力做出這軟件，他在外面接受收費的外判工作，這也是十年前的公價。以 man month 計算。若有查找到更便宜的開發歡迎(打臉)告知（電郵、面書）。

例如筆者隨手查找的這個頁面，以美元 USD 計算。寫的成本單計開發部份是 40K USD 到 300K USD 不等。

重點是：機會成本。這成本的問題，是致使願意免費提供專業協助的人不多。而當機構不太懂善用這些昂貴（代價高）的免費資源，就會使更少人願意協助。

既已寫了前兩篇。第三篇想寫下一間科技商業公司的部門一般包括哪些。

~ 簡介 ~

平時和人討論科技商業公司管理與運作，一般外人都會不太清楚這類公司一般有甚麼部門和分類。例如現代越來越流行科技，有時一個機構想在自己建制內加入科技部門，外行人往往就是想總之聘請個工程師 / 程序員回來就搞掂晒。

這概念有點像，在公司開個員工餐廳，總之請一個識煮食的人回來就搞掂晒差不多；而背後的食物儲存管理、物流、餐飲管理、團隊、行政、預算、等等，統統都視為默認預設。誤解本身無傷大雅，但執行項目會出意外和失預算，就會使到機構蝕錢或出其他問題。

這篇是為解釋這個思想誤區而設。

~ 一圖勝千言 ~

為免文字書寫太複雜，筆者製造了上面一幅圖。用一幅圖解釋完整個概念。差不多看圖就夠明白到。惟有是加一些註腳：

1. 每一個最內層的方格，代表著一個功能或團隊。大小不一，重要度視乎每個行業需要而不同。
2. 這圖是以廣博和綜合的原則而畫。即是，大致上都包括了這類公司會有的部門。而這類公司未必是有齊全圖中的所有部門或功能。
3. 有些部門是會按著理念和管理原則的不同，有實現上的不同。明顯的例如 QA 和 Devops。例如QA 有些人會認為應該跟 Product / Biz Dev 產品設計部門；也有些人會認為應該跟 Development。Devops 也有認為應該跟 Development。背後有不同理念。因為這篇的目的不是深入討論不同的管理理念，所以略過不贅。
4. 規模小的公司，有些部門(A)是未必會有。但其功能一定存在在其他的部門內。這些部門(A)包括：Architects、Cybersecurity、QA、Devops、Legal、Product、等等。

~ 總結 ~

從上圖可以想像到，營運一個科技公司其實可以很複雜。而這本身是一個專業知識。是包括各種部門之間怎樣協作，商業項目怎樣推動，行政和管理上的功能操作應該怎樣做。大約就是這些。

這個欄目最初是想分享下資訊安全（簡稱資安），所以簡介後第一篇不如由資安講起。寫資安的原因，是因為留意到行內行外對資安的了解都不太足夠。有時資安也會給人一種神祕面紗。所以這篇會寫下資安行內包括了甚麼。

~ 簡介 ~

Cybersecurity 資安的神祕面紗下，若談分類有個反差萌，是可以用個幾繽紛色彩的顏色圖來介紹機構內的主要資安功能。

資安的基本分類通常都會用 Blue Team 和 Red Team 來做基礎分類；這兩個字用藍隊和紅隊也是可以的。為了行文的貫徹性就是用這中文翻譯來寫。

這兩者都是機構內，負責保護機構的資安部門。可以很簡單地定義：藍隊是從防守方的方法來保護；紅隊就是從模擬攻擊方的方法來保護。通常還會有個 Purple Team 的；紫隊。紫就是紅加藍喔。即是兩者都從攻守兩者的思考方法上來做保護。紫隊這部門設計，是有一些效率上的優點。

下面先講解下作為保護目標對象的數碼資產。然後用個表來講解下分類。

~ 數碼資產 ~

任何有關資訊安全的課題，無論是(模擬)攻擊或防守，的對象都是軟件或電腦系統。一般用字是數碼資產 Digital Assets。

數碼資產的定義，是但凡以數碼形式存在的任何東西，而且是有其使用權限。這在機構包括了

1. 任何形式的資料 Data（例如檔案、電郵、媒體等等）；
2. 任何形式的軟件（例如代碼、執行中的軟件、舊版本的代碼、代碼版本系統例如 Git 等等）；
3. 任何形式的基礎建設 Infra（例如運作系統 OS、網絡 Network、資安設備例如門卡等等）
4. 任何形式的架構（例如運作中的服務器/伺服器、架構藍圖、系統藍圖、架構代碼 IaC、系統設定 configurations 等等）；
5. 任何形式的政策（例如項目管理系統、產品路線圖、運作政策設定 Policy、管治策略 IT Governance、事故處理程序 Incidence Response Plan 等等）

~ 繽紛色彩的部門 ~

從一些功能上較容易明的部門開始：

黃隊：從黃隊開始，因為黃隊就是工程師和架構師。就是建築和提供數碼資產的團隊。

藍隊：藍隊是建立主要的防守方法。包括了政策和管治策略的設定。也包括了事故處理程序的設定，和事故處理的執行。科技鑑證 Forensics在這分類上也是歸入藍隊的功能，是事故處理程序的一部份。科技鑑證包括搜證、證據分析、資料還原、事件報告、事件重建等等；鑑證這部份行內也有分類為 DFIR (Digital Forensics & Incident Response)。

綠隊：綠隊就是藍+黃，即防守+開發。簡化說就是 Devops 或所謂 DevSecOps。就是用工程去建築一些有效和自動化運維和資安保護的方法。例如代碼掃描、自動修復機制、自動化事故處理、系統維護等等。行內也有分類為 SOAR (Security Orchestration, Automation and Response)。

紅隊：紅隊 Red Team 是在資安行內比較觸目的部門。紅隊就是白帽駭客（古稱），現代正式用語是滲透測式（Penetration Tester, aka Pen-tester），也曾稱為道德駭客（Ethical Hacker）。紅隊是藉著做模擬攻擊，去實際測試數碼資產的安全性。紅隊的訓練，資深的會有著廣泛的五花八門的攻擊方法。從代碼、運作系統、服務接口、網絡、人員程序、分散式阻斷服務(DDOS)、資安研究、工具開法等等。

橙隊：橙隊是黃+紅。是幫助將模擬攻擊的經驗，反饋到工程和架構的開發團隊中。主要是教育功能。例如內部培訓、事件經驗學習、資安行業趨勢分享等等。

紫隊：紫隊是紅+藍。上文提過，紫隊是為提供效率優化而存在。原理是因為紅藍隊的設計上，紅隊為了有效做模擬攻擊，就未必會分享一些觀察到的常見模式。因為若紅隊分享這些，模擬攻擊就會越來越難做；因為會越來越難找到漏洞。那麼本來是紅隊付出的功勞，就似乎變成了防守方的成績。在管理上形成了懲罰 Penalized。所以在這個運作上的矛盾邏輯下，就會有些機構用紫隊來解決這個矛盾。紫隊就是紅隊藍隊的工作都做，是較多紅隊的功能；所以機構內也可以用紫隊和藍隊，代替紅隊加藍隊。這樣的設計下，紫隊就可以負責和模擬攻擊直接相關的攻擊測試與防守；而藍隊就可以較多在其他事項例如事故處理和政策維護。

白隊：白隊就是資安架構上的管理團隊。白隊包括管理行政人員例如 C-level、合規部門 Compliance、法律部門等等。

~ 前言 ~

一直想寫個欄目內容，是講下科技商業行內的模式上的心得。嚴格上所謂「科技行內」是多於一個行業。凡是以科技產品為主的公司或機構，都可以算是「科技行內」。這可以包括金融銀行、電訊、科技巨頭、媒體、遊戲開發等等。

科技之所以能稱為一個行業分類，是因為這些機構需要的人才都是相近 / 差不多。在管理的設計上，有大部份的共通點。所以可以歸類在一起研究探討。

在行內幾十年，見過好的模式、也見過不好的模式。「模式」是意指包括商業模型、行政架構、管理風氣、營運資訊系統、營運方式，等等。就是公司內的運作方式。這些運作方式，做得好和做得不好，可以是天堂和地獄的分別。絕對和公司的成功、投資者的獲利、員工的生活福祉、等等，這些都息息相關。這是管理這回事的被賦與的召命。

而這些模式，大學不會教，也沒有很多書會講。也沒有培訓班會講。而且行內的知識很參差。所以既然在行內幾十年，不如就藉博客分享一下。

~ 甚麼是科技商業 ~

科技商業又稱為「互聯網商業」，定義包括了兩個：(A) 第一個是凡是以科技產品所提供的主要產品或服務，都可歸類為互聯網商業。常見的互聯網商業例如國際科技巨頭（微軟、谷歌、蘋果電腦、Meta/面書、甲骨文、等等）、本地的電訊商、軟件服務供應商、電子遊戲開發商、媒體、等等。(B) 也包括一些科技佔了產品服務的大部份內容，但主要價值不只是科技的。例如金融科技、銀行、網上購物、數碼營銷顧問服務、等等。

為甚麼 (B) 類別也會歸類進科技商業？主要是因為 (A) 和 (B) 表面似乎是很不同，行業分類上也是分開的；但運作模式上，(A) 和 (B) 是有很多相似點。例如 (B) 也會有包括一部份是 (A) 的模式，例如部門的分類、人力需求和職位設計上、開發流程、科技管理等等。

~ 題目 ~

這個題目會分開幾篇寫。而有關原委，最初我想寫這個題目的原因，本來只是想簡介下 cybersecurity 資訊安全（一般簡稱資安）；因為科技行內行外其實普遍也對資安的認識不多。然後我想想，行外對科技行內的運作、分類、方法，也知道不多。所以不如整理這樣一個欄目，將科技行內的不同模式寫一下出來分享。