Tim Hudson, ประธานของ OpenSSL Corporation – ชุดสัมภาษณ์

Tim Hudson เป็นผู้ร่วมเขียน SSLeay และเป็นหนึ่งในผู้จัด OpenSSL Conference ที่ปรากราฟ ระหว่าง 13‑15 ตุลาคม 2026 เขามีประสบการณ์ด้านระบบและความปลอดภัยเครือข่ายมากกว่า 30 ปีและดำรงตำแหน่งประธานของ OpenSSL Corporation และหัวหน้าฝ่ายเทคโนโลยี (Chief Technology Officer) ที่ Cryptsoft Pty Ltd. ตั้งแต่ปี 1995 งานของเขารวมถึงการก่อตั้งร่วม SSLeay กับ Eric Young, ไลบรารีการเข้ารหัสที่ต่อมาเป็น OpenSSL Library, การก่อตั้งศูนย์พัฒนา RSA Security Australia, การมีส่วนร่วมในการเปลี่ยนแปลงกฎระเบียบการส่งออกการเข้ารหัสของสหรัฐ, การเป็นหัวหน้าการตรวจสอบ FIPS 140 มากกว่า 30 ครั้ง, การเป็นประธานร่วมคณะกรรมการเทคนิค OASIS KMIP และ SAM, และการบรรยายในงานประชุมความปลอดภัยชั้นนำหลายงาน เช่น RSA Conference, AusCERT, ICMC, LinuxConf และ OpenSSL Conference.

OpenSSL เป็นโครงการโอเพ่นซอร์สระดับโลกที่ทำงานร่วมกันเพื่อพัฒนาและดูแล OpenSSL Library, ซึ่งเป็นหนึ่งในไลบรารีการเข้ารหัสที่ใช้กันอย่างแพร่หลายที่สุดในโลก ถูกนำไปใช้ในระบบปฏิบัติการ, แพลตฟอร์มคลาวด์, ซอฟต์แวร์องค์กรและอุปกรณ์ที่เชื่อมต่อ, OpenSSL Library ช่วยปกป้องการโต้ตอบออนไลน์ที่ปลอดภัยหลายพันล้านครั้งต่อวัน ผ่าน OpenSSL Foundation และ OpenSSL Corporation, โครงการมุ่งมั่นที่จะส่งเสริมการเข้ารหัสที่เชื่อถือได้, สนับสนุนการพัฒนาโอเพ่นซอร์สอย่างยั่งยืนและเสริมความปลอดภัยของอินเทอร์เน็ต

You co-founded SSLeay with Eric Young in 1995 after recognizing the need for a non-US implementation of SSL, and that work ultimately became the foundation for OpenSSL. What problem were you originally trying to solve, and did you have any sense at the time that the technology could become such a fundamental part of securing the internet.

ปัญหาเป็นเรื่องที่แน่นอนและเป็นปัญหาทางการค้าเป็นอันดับแรก ฉันทำงานที่ Mincom ในบริสเบน เมื่อไคลเอ็นต์ต้องการความปลอดภัยในการสื่อสารของพวกเขา แต่ไม่มีวิธีใดที่จะซื้อความสามารถนั้นได้ การควบคุมการส่งออกของสหรัฐฯ ทำให้ผลิตภัณฑ์อเมริกันไม่สามารถจัดหาให้เราได้เลย หรือถ้าได้ก็มีขนาดคีย์ที่จำกัดจนไม่สามารถใช้งานได้ นี่ไม่ใช่การคัดค้านเชิงปรัชญาต่อมาตรการส่งออก แต่เป็นปัญหาวิศวกรรมที่ส่วนประกอบที่ฉันต้องการไม่มีอยู่ในรูปแบบใดที่ฉันจะซื้อได้และลูกค้าของฉันกำลังรอคอย

สิ่งที่ฉันมีคือความรู้เกี่ยวกับสิ่งที่หลายคนลืมไป Eric Young เคยเขียนการนำเข้า DES เมื่อหลายปีก่อน : โค้ดที่ดี, สะอาด, ฟรี, เขียนเพื่อความสนุกของตนเองและไม่มีส่วนเกี่ยวข้องกับ SSL Eric ไม่ได้ทำงานเกี่ยวกับ SSL และก็ไม่ได้รับรู้ถึง SSL เมื่อ Netscape เผยแพร่สเปคฉันก็อ่านมัน, ไปหา Eric พร้อมปัญหาและอธิบายว่าเป็นขั้นตอนที่ไม่ยากเกินไปจากที่เขามีอยู่แล้ว

นี่ไม่ได้เป็นภาพรวมทั้งหมด แต่ละส่วนเป็นเรื่องง่ายแต่ก็มีหลายส่วนที่ซับซ้อน การนำเข้า DES ให้คุณได้เพียงหนึ่งอัลกอริทึมสมมาตร SSL ต้องการการเข้ารหัสแบบกุญแจสาธารณะ, คณิตศาสตร์ความแม่นยำไม่จำกัด, ASN.1, การจัดการใบรับรอง X.509, และเครื่องสถานะของโพรโทคอล, ทั้งหมดต้องถูกต้อง เพราะในด้านการเข้ารหัส “เกือบ‑ถูกต้อง” กับ “เสีย” คือสิ่งเดียวกัน ฉันได้อธิบายขนาดของงานอย่างมองโลกในแง่ดี Eric จึงได้คำนวนเร็วว่า มีอะไรบ้างและเขาก็ชอบมัน เพราะขนาดของงานกลับกลายเป็นแรงจูงใจ ไม่ใช่อุปสรรค ฉันไม่แน่ใจว่ามันจะเริ่มต้นอย่างอื่นได้หรือไม่

เขาทำส่วนแกนการเข้ารหัส, ซึ่งเป็นเหตุผลที่ไลบรารีมีอักษรย่อของเขาอยู่ ฉันรับผิดชอบส่วนที่ทำให้ไลบรารีกลายเป็นสิ่งที่คนอื่นสามารถใช้งานได้ : การรวมแอปพลิเคชัน, การทดสอบ, เอกสารและส่วนของชุมชน ฉันยังตามหาและแทนที่ไลบรารีการเข้ารหัสที่แข่งกันอยู่ทุกที่ SSLtelnet, SSLftp, NCSA httpd และแพคเกจอื่น ๆ อีกหลายรายการเป็นผลงานของฉัน, แอปพลิเคชันที่สร้างบนอัลกอริทึมและโพรโทคอลที่ Eric พัฒนา การผสมผสานนี้ทำให้แต่ละคนโฟกัสที่สิ่งที่ตนสนใจจริง ๆ ซึ่งเป็นเหตุผลหลักที่ทำให้โครงการดำเนินต่อไป

การอยู่ในออสเตรเลียทำให้เราสามารถแก้ปัญหาได้และต่อมาพบว่ามีคนจำนวนมากที่เจอปัญหาเดียวกันด้วยเหตุผลเดียวกัน สิ่งที่สร้างขึ้นเพื่อสนองความต้องการของลูกค้าในบริสเบนจึงเป็นประโยชน์ต่อทุกคนนอกสหรัฐและต่อผู้ใช้ภายในสหรัฐด้วย

เรารู้หรือไม่ว่าโครงการจะเป็นอย่างนี้? ไม่เลย ไม่มีใครตั้งใจจะสร้างโครงสร้างพื้นฐานสำคัญ โครงสร้างพื้นฐานสำคัญคือสิ่งที่คุณค้นพบว่าตัวเองสร้างขึ้นหลายปีต่อมาเมื่อคุณรู้ว่าใครพึ่งพามัน เราคิดว่าเรากำลังแก้ปัญหาอยู่หน้าตัวเองและตอบคำถามจากคนอื่นที่เจออุปสรรคเดียวกัน ส่วนการตอบคำถามนั้นก็สำคัญเท่ากับโค้ด

You have worked in cryptography and internet security for more than three decades. What has changed most dramatically about the threat landscape during that period, and which security problems have remained surprisingly similar despite enormous advances in technology?

การเปลี่ยนแปลงที่ใหญ่ที่สุดคือการโจมตีระบบกลายเป็นอาชีพที่มีโมเดลทางเศรษฐกิจเป็นพื้นฐาน ในช่วงกลางทศวรรษ 1990 ผู้ที่แฮ็กระบบทำเพราะมันน่าสนใจ วันนี้มีอุตสาหกรรมที่มีความเชี่ยวชาญ, เครื่องมือ, โซ่อุปทาน, การสนับสนุนลูกค้า และบางกรณีได้รับเงินสนับสนุนจากรัฐ สิ่งนี้เปลี่ยนแปลงทุกอย่างเกี่ยวกับวิธีคิด เพราะคุณไม่ได้ต่อสู้กับความอยากรู้อยากเห็นแล้ว แต่ต่อสู้กับผู้มีงบประมาณ, กำหนดเวลาและกรณีธุรกิจ

การเปลี่ยนแปลงที่สองคือขนาดและการพึ่งพา แอปพลิเคชันเฉลี่ยในปี 1995 เป็นสิ่งที่คุณเขียนเอง ส่วนแอปพลิเคชันวันนี้เป็นสิ่งที่คุณประกอบและส่วนใหญ่ของโค้ดถูกเขียนโดยคนที่คุณไม่เคยพบและไม่สามารถระบุชื่อได้ พื้นผิวการโจมตีย้ายจากโค้ดของคุณไปยังการพึ่งพา และองค์กรส่วนใหญ่ยังไม่ได้ปรับแนวคิดให้สอดคล้อง

สิ่งที่คงที่อย่างน่าประหลาดคือรูปแบบการล้มเหลว เรายังเขียนบั๊กในโค้ดที่แยกข้อมูลที่ไม่เชื่อถือได้ เรายังปล่อยระบบที่ตั้งค่าเริ่มต้นโดยไม่มีการตรวจทาน ใบรับรองยังคงหมดอายุในวันเสาร์ เครดิตยังคงรั่วไหลไปยังที่ที่ไม่ควรอยู่ และการเข้ารหัสยังคงไม่เคยถูกทำลายที่ระดับคณิตศาสตร์ แต่มักถูกข้าม, ตั้งค่าผิด หรือไม่ได้เปิดใช้งาน หากคุณเปรียบเทียบรายการสาเหตุหลักของการละเมิดในปี 1996 กับเดือนที่ผ่านมา คุณจะยากที่จะแยกความแตกต่าง เทคโนโลยีเปลี่ยนแปลงอย่างสิ้นเชิง แต่ความผิดพลาดไม่ได้เปลี่ยน

OpenSSL 4.0 was released in เมษายน 2026, marking the project’s first major release in several years. What does this release tell us about where cryptographic infrastructure is heading, and which changes do you think will ultimately matter most to organizations that depend on OpenSSL?

สิ่งที่ควรเข้าใจที่สุดเกี่ยวกับ 4.0 คือมันเป็นการปลดล้าง (subtraction) เป็นเหตุผลหลักของการปล่อยเวอร์ชันนี้

เราลบส่วนต่อประสาน ENGINE อย่างสมบูรณ์ เราลบ SSLv3 และ SSLv2 ClientHello เราปิดการใช้งานโค้งวงรีที่ล้าสมัยและโค้ง EC ที่ระบุโดยชัดเจนในขั้นตอนคอมไพล์ เราทำให้ ASN1_STRING เป็นแบบไม่เปิดเผยและทำให้ลายเซ็น API จำนวนมากเข้มงวด สิ่งเหล่านี้เป็นการเปลี่ยนแปลงที่ทำให้ผู้ใช้ต้องทำงานและเป็นสิ่งที่สำคัญ เพราะไลบรารีการเข้ารหัสที่เพียงสะสมโค้ดเก่าไม่สามารถคงความปลอดภัยได้ ทุกเส้นทางโค้ดที่ล้าสมัยที่คุณยังคงเปิดไว้เป็นพื้นผิวการโจมตีที่มีคนดูแลแทนคุณและไม่มีใครทดสอบ

มีการเพิ่มเข้ามาใหม่ : Encrypted Client Hello, การสนับสนุน RFC 8998 รวมถึงกลุ่มไฮบริด SM2/ML‑KEM, cSHAKE, SNMP และ SRTP KDFs, การเจรจา FFDHE สำหรับ TLS 1.2. ECH โดยเฉพาะปิดช่องว่างด้านความเป็นส่วนตัวที่แท้จริง เพราะ Server Name Indication รั่วไหลข้อมูลของทุกเว็บไซต์ที่คุณเยี่ยมชมตั้งแต่ TLS 1.3 เปิดตัว แต่การลบคือเรื่องหลัก

ข้อสรุปที่ฉันอยากให้องค์กรจำได้คือ : 4.0 ไม่ใช่รุ่น LTS รองรับจนถึงพฤษภาคม 2027 รุ่น LTS ปัจจุบันคือ 3.5 รองรับจนถึงเมษายน 2030 และ 3.5 มีอัลกอริทึมหลังควอนตัมอยู่แล้ว หากคุณต้องการโค้ดใหม่ที่สุดให้ใช้ 4.0 หากต้องการเป้าหมายที่มั่นคงเพื่อวางแผนการย้ายระยะห้าปีให้ใช้ 3.5 การเลือกเลขรุ่นที่สูงกว่าเพียงเพราะเป็นเลขที่สูงกว่าเป็นความผิดพลาดที่เราเห็นบ่อยทุกรอบ

Post-quantum cryptography has moved from a research problem toward a migration challenge, with OpenSSL already supporting ML-KEM, ML-DSA, and SLH-DSA and hybrid post-quantum key exchange. For business leaders who assume quantum computing is still too distant to worry about, what risks are they overlooking today?

ความเข้าใจที่พบบ่อยที่สุดคือมองว่าปัญหานี้เป็นคำถามว่า “คอมพิวเตอร์ควอนตัมที่เกี่ยวข้องกับการเข้ารหัสจะมาถึงเมื่อไหร่” นั่นไม่ใช่ตัวแปรที่ถูกต้อง คำถามที่ถูกต้องคือข้อมูลของคุณต้องการความลับนานเท่าใดและการย้ายจะใช้เวลานานเท่าใด ลบระยะเวลาที่สองจากระยะแรกจะได้กำหนดเวลาจริงของคุณ และสำหรับหลายองค์กรกำหนดเวลานั้นอาจผ่านมาแล้ว

การจราจรที่เข้ารหัสสามารถดักจับได้ในวันนี้และเก็บไว้ได้ตลอด หากข้อมูลนั้นมีความสำคัญต่อการใช้งานเป็นเวลา 20 ปี (บันทึกผู้ป่วย, เอกสารบุคคล, ทรัพย์สินทางปัญญา, เอกสารการทูต, สถานะการเงิน) ผู้โจมตีไม่จำเป็นต้องมีคอมพิวเตอร์ควอนตัมในขณะนี้ พวกเขาต้องการคอมพิวเตอร์นั้นในภายหลังและต้องการที่เก็บข้อมูลราคาถูกในระหว่างนั้น นี่ไม่ใช่การโจมตีเชิงสเปคูเลทีฟ แต่เป็นการตัดสินใจด้านการจัดเก็บ

สิ่งที่สองที่มักมองข้ามคือการย้ายไม่ใช่โครงการเดียว การแลกเปลี่ยนคีย์เป็นส่วนที่ง่ายและหลายองค์กรทำอยู่แล้ว : OpenSSL 3.5 ทำให้การแลกเปลี่ยนคีย์หลังควอนตัมแบบไฮบริดเป็นค่าเริ่มต้นของ TLS ดังนั้นหลายองค์กรกำลังใช้การเจรจาคีย์หลังควอนตัมอยู่แล้วโดยไม่ได้ตัดสินใจเรื่องนี้ การลงลายเซ็นและโครงสร้างใบรับรองเป็นส่วนที่ยาก เพราะต้องเกี่ยวข้องกับผู้ให้บริการใบรับรอง, รากความเชื่อถือของฮาร์ดแวร์, คีย์การลงลายเซ็นเฟิร์มแวร์, โมดูลความปลอดภัยฮาร์ดแวร์, และอุปกรณ์ที่มีอายุการใช้งานสนามสิบห้าปีที่สร้างบนสมมติฐานว่า RSA จะใช้งานได้ตลอดไป

สิ่งที่สามคือข้อจำกัดที่ไม่มีใครจัดสรรงบประมาณให้ : ลายเซ็นหลังควอนตัมมีขนาดใหญ่ ML‑DSA‑65 มีขนาดประมาณห้าสิบเท่าของลายเซ็น ECDSA P‑256 และ SLH‑DSA ใหญ่กว่าอีก การเพิ่มขนาดนี้ทำให้เกิดปัญหาในขนาดการจับมือ, อุปกรณ์ที่มีข้อจำกัด, โปรโตคอลที่มีขีดจำกัดฟิลด์, ลิงก์ดาวเทียมและ IoT คุณจะพบปัญหาเหล่านี้จากการทดสอบ ไม่ได้จากการอ่านมาตรฐาน

One of the challenges with post-quantum migration is that organizations may not even know everywhere cryptography is being used across their applications, infrastructure, devices, and third-party dependencies. How should companies approach cryptographic inventory and crypto‑agility so that the next major algorithm transition does not become an emergency?

เริ่มต้นด้วยความจริงที่ไม่สบายใจ : คุณไม่สามารถสร้างรายการตรวจสอบการเข้ารหัสได้โดยส่งแบบสอบถามให้ผู้จำหน่าย คุณจะได้รับการตอบที่เป็นการผสมผสานระหว่างคัดลอกการตลาด, ความไม่แน่ใจที่ซื่อสัตย์, และคำตอบที่ถูกต้องเมื่อ 3 รุ่นที่แล้ว ฉันพูดอย่างนี้เพราะเพิ่งใช้เวลามากอ่านเอกสารผู้จำหน่ายฮาร์ดแวร์ในสาขาที่เกี่ยวข้องและช่องว่างระหว่างสิ่งที่เอกสารอ้างอิงและสิ่งที่ผลิตภัณฑ์ทำจริงกว้างกว่าที่ผู้ซื้อส่วนใหญ่คาดคิด

คุณต้องมองหา มีสามชั้นและต้องใช้เทคนิคที่แตกต่างกัน โค้ดที่คุณเขียน : การวิเคราะห์แบบสถิตย์, การสแกนการพึ่งพา, และการค้นหาอัลกอริทึมที่คุณเขียนแบบฮาร์ดโค้ดหลายปีก่อน โค้ดที่คุณลิงก์ : รายการวัสดุซอฟต์แวร์ (software bill of materials) ที่ขยายเป็นรายการวัสดุการเข้ารหัส (cryptographic bill of materials) ซึ่งเป็นที่ทำงานของ CBOM ที่เป็นประโยชน์จริง สิ่งที่คุณซื้อหรือเชื่อมต่อ : การสังเกตเครือข่าย, เพราะสิ่งที่ระบบของคุณเจรจาบนสายเป็นความจริงพื้นฐานและบ่อยครั้งไม่ตรงกับที่ใครก็เชื่อ

ส่วนของความคล่องตัว หลักการง่าย ๆ แต่การปฏิบัติไม่ง่าย : อัลกอริทึมควรเป็นการตั้งค่าผ่านการกำหนดค่า ไม่ใช่การเปลี่ยนโค้ด หากการเปลี่ยนรหัสต้องอาศัยนักพัฒนา, การสร้าง, รอบการทดสอบและการปล่อย คุณไม่มีความคล่องตัว คุณมีโครงการเดียว ให้รวมการดำเนินการเข้ารหัสไว้หลังอินเทอร์เฟซที่คุณควบคุม เพื่อให้มีจุดเดียวที่ต้องเปลี่ยนแทนสี่ร้อยจุด

และส่วนที่หลายคนข้ามไป : ทดลองทำจริง การคล่องที่คุณยังไม่เคยใช้เป็นเพียงการอ้างอิง ไม่ใช่ความสามารถ จับวันหยุดสุดสัปดาห์ที่เงียบ ๆ ปิดอัลกอริทึมในสภาพแวดล้อมที่ไม่ใช่การผลิตและดูว่าอะไรพัง สิ่งใดจะพัง ควรค้นพบก่อนที่เหตุฉุกเฉินจะบังคับให้คุณต้องย้าย

ฟังก์ชันบังคับที่เป็นประโยชน์คืออายุการใช้งานของใบรับรอง อุตสาหกรรมกำลังย้ายไปสู่ใบรับรองที่มีอายุสั้นมาก ซึ่งทำให้การจัดการใบรับรองด้วยมือเป็นไปไม่ได้และบังคับให้ต้องอัตโนมัติ หากคุณทำระบบอัตโนมัติในการออกและหมุนใบรับรองอย่างถูกต้อง คุณก็ได้สร้างกลไกส่วนใหญ่ที่การเปลี่ยนแปลงอัลกอริทึมในอนาคตจะต้องใช้

AI is changing both cybersecurity defense and the capabilities available to attackers. Where do you believe AI genuinely changes the security equation, and where do you think organizations may be focusing too much on the technology while overlooking more fundamental weaknesses?

AI ทำการเปลี่ยนแปลงสิ่งหนึ่งจริง ๆ และฉันพูดถึงมันโดยตรงเพราะมันเกิดขึ้นกับเรา

จำนวนมากของช่องโหว่ที่เปิดเผยใน OpenSSL ปีนี้พบโดยการวิเคราะห์ที่ขับเคลื่อนด้วย AI ในเดือนมกราคมเราออกเวอร์ชันที่แก้ไข 12 ปัญหา, ส่วนใหญ่จากกลุ่มวิจัยหนึ่งที่ใช้การวิเคราะห์อัตโนมัติและพวกเขายังส่งแพตช์พร้อมกับรายงาน ในเดือนมิถุนายนเราแก้ไขการใช้‑หลัง‑อิสระที่รุนแรงในการตรวจสอบ PKCS#7 ที่พบโดยนักวิจัยที่ทำงานกับระบบ AI นั่นเป็นการเปลี่ยนแปลงความสามารถจริง ๆ ในการค้นหาบั๊กด้านความปลอดภัยหน่วยความจำและการพาร์สในโค้ด C ที่ผ่านการตรวจสอบโดยผู้เชี่ยวชาญหลายปี ฉันได้เห็นรูปแบบเดียวกันในไลบรารีการเข้ารหัสอื่น ๆ การวิเคราะห์ชุดของ CVE ของ Bouncy Castle ปีนี้ทำให้เห็นรอยของการวิเคราะห์โค้ดอัตโนมัติอย่างชัดเจน

ผลสรุปที่ชัดเจนคือเทคนิคเดียวกันสามารถใช้ได้กับผู้ที่ต้องการใช้มันบนโค้ดฐานเดียวกันและผู้ป้องกันไม่ได้มีสิทธิ์เข้าถึงแบบเฉพาะ

ผลสรุปที่น้อยกว่าที่ฉันอยากเน้นคือภาระที่เพิ่มขึ้นต่อผู้ดูแล การสร้างรายงานช่องโหว่ที่ดูเหมือนจริงตอนนี้เกือบฟรี แต่การคัดกรองยังต้องใช้คนผู้เชี่ยวชาญจริง ๆ ใช้เวลาจริง ทีมความปลอดภัยโอเพ่นซอร์สซึ่งมักเป็นทีมเล็ก ๆ และมักอาสา กำลังรับมือกับปริมาณรายงานที่เพิ่มขึ้นและคุณภาพแปรผัน รายงานที่ดีเช่นการวิจัยที่กล่าวมามาพร้อมกับโค้ดทดสอบและแพตช์ รายงานที่แย่เป็นการโจมตีแบบปฏิเสธการให้บริการต่อผู้ที่คุณพึ่งพา หากองค์กรของคุณใช้ AI เพื่อตรวจสอบโค้ดโอเพ่นซอร์ส ควรจัดสรรงบประมาณสำหรับการคัดกรองที่อีกด้านหนึ่ง

สิ่งที่ฉันคิดว่าความสนใจผิดพลาด : AI ไม่ได้แก้ไขระบบของคุณ มันไม่ทำรายการสินทรัพย์ของคุณ ไม่หมุนครีเดนเชียล ไม่ถอดอุปกรณ์ที่ไม่ได้รับการสนับสนุน หรือทำให้ใครรับผิดชอบต่อใบรับรองที่หมดอายุในเดือนหน้า องค์กรที่ซื้อเครื่องมือ AI ด้านความปลอดภัยแต่ยังรันซอฟต์แวร์ที่มีช่องโหว่ที่ยังไม่ได้แก้ไขนั้นจัดลำดับความสำคัญผิด การทำงานที่ไม่โดดเด่นยังคงเป็นที่ที่ความเสี่ยงอยู่

Many organizations invest heavily in tools but remain vulnerable because of configuration mistakes, outdated systems, weak processes, or poor incident preparation. What are the most consequential security mistakes you continue to see, and what should leadership teams have in place before an attack actually occurs?

ความผิดพลาดที่สำคัญที่สุดคือมองความปลอดภัยเป็นกิจกรรมจัดซื้อเครื่องมือ เครื่องมือถูกซื้อ, งบประมาณบรรลุ, แดชบอร์ดเป็นสีเขียว, และไม่มีใครถามว่าองค์กรทำสิ่งพื้นฐานที่จำเป็นได้หรือไม่

ความผิดพลาดที่สองคือไม่รู้ว่าตัวเองรันอะไร คุณไม่สามารถแพตช์ซอฟต์แวร์ที่คุณไม่รู้ว่ามีอยู่ และหลายองค์กรค้นพบเนื้อหาจริงของทรัพย์สินของตนระหว่างเหตุการณ์ นี่คือเหตุผลที่งานบิล‑ออฟ‑เมเทอเรียลสำคัญ ไม่ใช่แค่เอกสารการปฏิบัติตามกฎระเบียบ แต่เป็นสิ่งที่คุณต้องการเมื่อตอนตี 2 ของเช้าวันที่มีคำแนะนำสำคัญตกลงและมีคนถามว่าคุณได้รับผลกระทบหรือไม่

ความผิดพลาดที่สามคือค่าเริ่มต้น ระบบถูกติดตั้ง, ทำงาน, และการตั้งค่าไม่เคยตรวจทานใหม่ 5 ปีต่อมาการตั้งค่านั้นกลายเป็นความรับผิดชอบและไม่มีใครที่ทำการตัดสินใจแรกยังทำงานอยู่

ความผิดพลาดที่สี่คือการจัดการคีย์และใบรับรองให้กับบุคคลหนึ่ง ๆ จำนวนมากของการหยุดทำงานที่เกิดจากตัวเองมาจากใบรับรองที่หมดอายุซึ่งคนหนึ่งคนเดียวติดตามในสเปรดชีตจนกระทั่งเปลี่ยนงาน

ก่อนเหตุการณ์, ผู้นำต้องมีสี่สิ่งพร้อม: ผู้ตัดสินใจที่มีอำนาจสั่งปิดระบบธุรกิจได้, กำหนดไว้ล่วงหน้าเป็นลายลักษณ์อักษร, เพราะข้อโต้แย้งว่าใครมีอำนาจนั้นไม่ใช่สิ่งที่คุณต้องการให้เกิดขึ้นขณะฉุกเฉิน; สัญญาจ้างงานล่วงหน้ากับผู้เชี่ยวชาญฟอเรนซิกส์และที่ปรึกษาพิเศษ, เพราะการจัดซื้อใช้เวลาหลายสัปดาห์และคุณจะมีเพียงไม่กี่ชั่วโมง; ช่องทางสื่อสารที่ไม่พึ่งพาระบบที่อาจถูกโจมตี; และความสามารถในการกู้คืนที่ได้ทดสอบอย่างครบถ้วนจากต้นจนจบ, ไม่ใช่แค่ระบบสำรองข้อมูลที่ตรวจสอบว่าการทำงานสำเร็จเท่านั้น

จากนั้นให้ฝึกซ้อม การฝึกจำลองระดับผู้บริหารปีละครั้งจะเปิดเผยช่องว่างที่แท้จริงมากกว่าการเพิ่มเครื่องมืออีกชิ้น

When a serious cyberattack does happen, executives can suddenly find themselves making technical, legal, operational, and communications decisions under enormous pressure. What separates organizations that respond effectively from those that allow an incident to become substantially worse?

องค์กรที่จัดการได้ดีคือได้ทำการตัดสินใจสำคัญล่วงหน้าแล้ว, ดังนั้นในเหตุการณ์พวกเขากำลังดำเนินการแทนที่จะต้องคิดใหม่ นั่นคือส่วนใหญ่ของความแตกต่าง

นอกเหนือจากการเตรียมการ, มีหลายสิ่งที่แยกการตอบสนองที่ดีออกจากที่แย่

พวกเขาแยกการสืบสวนเชิงเทคนิคออกจากเส้นทางผู้บริหารและการสื่อสาร, มีอินเทอร์เฟซที่กำหนดชัดเจนระหว่างสองส่วน หากคนเดียวพยายามกักข้อบกพร่องและร่างการแจ้งลูกค้า งานทั้งสองมักทำได้แย่

พวกเขาเก็บหลักฐานก่อนทำการแก้ไข สัญชาตญาณที่รีบสร้างเครื่องที่ถูกคุกคามใหม่ทันทีเป็นสิ่งรุนแรงและทำลายข้อมูลที่จำเป็นต่อการกำหนดขอบเขต หากคุณไม่สามารถตอบ “พวกเขาได้แตะต้องอะไรบ้างอีก” คุณก็ไม่สามารถบอกได้อย่างเชื่อถือได้ว่าเหตุการณ์จบแล้ว

พวกเขายอมรับว่าข้อมูลเริ่มแรกเป็นเพียงข้อมูลชั่วคราวและสื่อสารตามนั้น ความเสียหายต่อชื่อเสียงส่วนใหญ่ที่ฉันเห็นไม่ได้มาจากการละเมิดเอง แต่จากคำแถลงที่มั่นใจแต่ต้องถอยกลับ การบอก “นี่คือสิ่งที่เรารู้, นี่คือสิ่งที่ยังไม่รู้, เราจะอัปเดตคุณเมื่อไร” ไม่ใช่ความอ่อนแอ แต่เป็นตำแหน่งเดียวที่คุณไม่ต้องถอยกลับ

และสำคัญที่สุด : พวกเขาสร้างสภาพแวดล้อมที่วิศวกรสามารถบอกผู้บริหารข้อมูลไม่ดีได้ รูปแบบความล้มเหลวที่ฉันเห็นบ่อยที่สุดคือองค์กรที่ความเสี่ยงทางกฎหมายชัดเจนจนไม่มีใครอยากเป็นคนเขียนว่าจริง ๆ เกิดอะไรขึ้น เหตุการณ์จึงแย่ลงในความเงียบ หากวิศวกรต้องรับผิดชอบต่อความรับผิดของตนเองแทนเหตุการณ์ คุณมีปัญหาการกำกับดูแลที่ไม่มีเครื่องมือใด ๆ สามารถแก้ไขได้

OpenSSL sits in an unusual position as critical open-source infrastructure used throughout the technology ecosystem, while the OpenSSL Corporation focuses on serving commercial communities alongside the independently operated OpenSSL Foundation. How do you balance the needs of enterprises, developers, regulators, and the broader open-source community when decisions about security and compatibility can affect such a large portion of the internet?

คำตอบที่ตรงไปตรงมาคือคุณไม่พยายามทำให้ทุกคนพอใจในแต่ละการตัดสินใจ คุณทำให้สมดุลโดยมีนโยบายที่เผยแพร่และนำไปใช้แบบคาดการณ์ได้, เพื่อให้ผู้คนสามารถวางแผนได้แม้พวกเขาไม่พอใจกับผลลัพธ์บางอย่าง

การคาดการณ์คือสิ่งที่เราต้องให้กับผู้ใช้ เราปล่อยเวอร์ชันฟีเจอร์ในเดือนเมษายนและตุลาคม เราบอกล่วงหน้าว่าเวอร์ชันใดเป็น LTS และจนถึงเมื่อไหร่ เราแจ้งการลบคุณลักษณะสำคัญล่วงหน้า การลบ ENGINE ใน 4.0 ถูกอธิบายสาธารณะหลายเดือนก่อนการปล่อยและได้รับความเห็นชอบจากทั้ง Corporation และ Foundation ผู้ที่ประหลาดใจในเดือนเมษายนไม่ได้ใส่ใจและเราทำให้การติดตามง่ายที่สุดเท่าที่เราสามารถทำได้

คำตอบเชิงโครงสร้างคือการแยกออกจากกันเองเองเอง : Foundation มีไว้เพื่อให้บริการไลบรารีโอเพ่นซอร์สและชุมชนที่อยู่รอบ ๆ มัน Corporation มีไว้เพื่อให้บริการองค์กรที่มีความต้องการเชิงพาณิชย์ (การสนับสนุน, การตรวจสอบ FIPS, กำหนดเวลาที่เฉพาะเจาะจง) และทำให้โครงการทั้งหมดยั่งยืนทางการเงิน การแยกเหล่านี้หมายความว่าความต้องการของแต่ละฝ่ายไม่ได้ถูกแก้ไขโดยเงียบ ๆ ในฝ่ายอื่น เมื่อความต้องการขององค์กรและของชุมชนขัดแย้งกันจริง ๆ ความขัดแย้งจะเกิดขึ้นระหว่างสององค์กรที่มีขอบเขตชัดเจน แทนที่จะอยู่ในหัวของคนคนเดียว

ส่วนอื่นคือการฟังอย่างถูกต้อง ซึ่งต้องมีกลไกจริง ๆ ไม่ใช่สมมติฐาน นั่นเป็นส่วนใหญ่ของเหตุผลที่เราจัด the conference ซึ่งจัดที่ปรากราฟเดือนตุลาคมนี้, และทำให้โครงสร้างพื้นฐานของชุมชนมีอยู่ มันง่ายมากที่ผู้ดูแลจะพัฒนาทฤษฎีที่มั่นใจเกี่ยวกับความต้องการของผู้ใช้ แต่การอยู่ในห้องกับพวกเขานั้นมีประโยชน์มากกว่า

10.Looking at the next decade, what security or cryptographic transition do you believe organizations are still underestimating today, and what lessons from the evolution of SSL, OpenSSL, and the past 30 years of internet security should leaders apply as they prepare for it?

การเปลี่ยนแปลงที่ฉันคิดว่าถูกประเมินต่ำที่สุดไม่ใช่ post‑quantum cryptography ในแง่ของอัลกอริทึม แต่คืออัตลักษณ์ของเครื่องจักรและโครงสร้างใบรับรองที่อยู่ใต้ทุกอย่าง

การแลกเปลี่ยนคีย์หลังควอนตัมจะได้รับการแก้ไขส่วนใหญ่โดยค่าเริ่มต้นและส่วนใหญ่ก็ทำแล้ว สิ่งที่ค่าเริ่มต้นไม่สามารถแก้ได้คือโครงสร้างความเชื่อถือ : ใบรับรองรากในฮาร์ดแวร์, คีย์การลงลายเซ็นเฟิร์มแวร์ที่ฝังอยู่ในอุปกรณ์, HSM ที่เหลืออายุการใช้งานอีกสิบปี, ระบบอุตสาหกรรมและการแพทย์ที่จะยังคงทำงานจนถึงปี 2040 พร้อมสมมติฐานการเข้ารหัสที่ฝังไว้ตั้งแต่การผลิต สิ่งเหล่านี้ไม่สามารถอัปเดตได้โดยการส่งไลบรารีใหม่และบางกรณีอาจไม่อัปเดตได้เลย ขนาดของปัญหาการแทนที่นี้ยังไม่สะท้อนในแผนการลงทุนของใคร

ขนานกับนั้นคือการเปลี่ยนแปลงด้านกฎระเบียบ Cyber Resilience Act ในยุโรปและกรอบงานที่คล้ายกันในที่อื่น ๆ จะเปลี่ยนภาระหน้าที่ของการส่งซอฟต์แวร์ที่มีส่วนประกอบที่คุณไม่ได้เขียนเอง ส่วนใหญ่ขององค์กรยังไม่ได้พิจารณาว่ามันหมายความว่าอย่างไรต่อการพึ่งพาโอเพ่นซอร์สหรือผู้ที่ดูแลมัน

สามบทเรียนจากสามทศวรรษ :

1. การเปลี่ยนแปลงใช้เวลานานกว่าที่ประกาศไว้หนึ่งทศวรรษ SSLv3 ถูกยกเลิกในปี 2015, ปิดการใช้งานโดยค่าเริ่มต้นในปี 2016, และเราลบโค้ดนั้นในเดือนเมษายน 2026 นั่นคือสิบเอ็ดปีสำหรับโพรโทคอลที่ทุกคนเห็นว่าเสียหาย ควรวางแผนการย้าย post‑quantum ตามความเป็นจริงนี้ ไม่ใช่ตามข่าวประชาสัมพันธ์
2. ค่าเริ่มต้นเป็นการควบคุมความปลอดภัยเดียวที่ทำงานได้ในระดับใหญ่ สิ่งใดที่ต้องการให้ผู้ดูแลทุกคนตัดสินใจอย่างถูกต้องจะไม่มีวันเกิดขึ้น เหตุผลที่การแลกเปลี่ยนคีย์หลังควอนตัมแบบไฮบริดถูกนำไปใช้เร็วขนาดนี้คือเปิดใช้งานโดยค่าเริ่มต้นและไม่ต้องการการตัดสินใจใด ๆ ออกแบบสำหรับผู้ที่ไม่มีวันอ่านเอกสารของคุณ เพราะนั่นคือเกือบทุกคน
3. คุณพึ่งพาผู้คนน้อยกว่าที่คิด เกือบทุกองค์กรบนโลกพึ่งพาโค้ดการเข้ารหัสที่ดูแลโดยบุคคลจำนวนเล็กมาก ซึ่งเป็นความจริงตั้งแต่เราสองคนในบริสเบนและโครงสร้างยังไม่ได้เปลี่ยนแปลงแม้ความเสี่ยงจะเพิ่มเป็นหลายเท่าตัว สิ่งที่คุณกำลังวางแผนสำหรับทศวรรษหน้า, ส่วนหนึ่งของมันพึ่งพาผู้ดูแลที่คุณไม่เคยติดต่อและไม่ได้ให้เงินสนับสนุน นั่นคือสิ่งที่ควรรู้ก่อนที่คุณจะต้องพึ่งพาเขา

Thank you for the great interview. Readers who wish to learn more should visit OpenSSL.