Sáu ý tưởng ngớ ngẩn về bảo mật máy tính (2005)
(ranum.com)- Bảo mật máy tính là lĩnh vực mà sản phẩm, hội nghị, sách và dự luật mới liên tục xuất hiện, nhưng gốc rễ của những thất bại lặp đi lặp lại nằm ở các giả định nền tảng sai lầm như Default Permit và Enumerating Badness
- Vấn đề cốt lõi là cấu trúc liên tục chạy theo những thứ “cần chặn” thay vì định nghĩa hẹp những gì “được phép”, và nếu không chọn Default Deny trong tường lửa, thực thi mã và ứng phó sâu máy tính, bạn sẽ rơi vào cuộc chạy đua vũ trang với kẻ tấn công
- Việc liệt kê những thứ xấu là cách theo dõi hơn 75.000 virus và 200~700 mối đe dọa mới mỗi tháng, nên kém hiệu quả hơn việc quản lý Enumerating Goodness với khoảng 30 ứng dụng hợp lệ thực sự cần thiết
- Cách tìm lỗ hổng rồi vá, văn hóa tiêu thụ việc hack như thứ gì đó ngầu, và chiến lược phụ thuộc vào đào tạo người dùng đều chỉ lặp lại ứng phó sau sự cố thay vì giảm lỗi thiết kế
- Với công nghệ mới, chờ đợi và kiểm chứng thay vì triển khai ngay có thể an toàn hơn, và người làm bảo mật nên ưu tiên thiết kế hợp lý theo lẽ thường cùng thái độ hoài nghi hơn là chạy theo trào lưu
Những “ý tưởng phản tốt” tạo ra thất bại bảo mật
- Trong bảo mật máy tính, sản phẩm mới, hội nghị mới, sách mới và dự luật mới liên tục xuất hiện nhưng vấn đề vẫn lặp lại
- “Ý tưởng ngớ ngẩn” là những cách tiếp cận nằm ở phía đối lập với ý tưởng tốt, xuất hiện khi cố làm điều bất khả thi hoặc phớt lờ thực tế
- Những cách tiếp cận này đôi khi đến từ sự hiểu lầm có thiện ý, đôi khi đến từ các sản phẩm được đóng gói khéo léo để kiếm tiền nhanh
- Sáu ý tưởng được sắp xếp theo thứ tự thường gặp, và đặc biệt nếu tránh được ba ý đầu tiên thì có thể xem là thuộc nhóm ít chuyên gia bảo mật thực sự xuất sắc
1. Default Permit: mặc định cho phép
- Default Permit là cách cho phép mọi thứ không bị cấm rõ ràng, và dễ nhận thấy nhất trong các quy tắc tường lửa
- Các quản trị viên mạng thời kỳ đầu chỉ chặn telnet, rlogin và FTP đi vào, còn lại đều cho phép
- Mỗi khi phát hiện lỗ hổng mới, quản trị viên lại phải quyết định có chặn hay không, và phải chạy nhanh hơn trước khi bị tấn công
- Đáng ra phải biến mất từ khi sâu máy tính xuất hiện trong thập niên 1990, nhưng nhiều mạng vẫn có cấu trúc lõi mở, không phân đoạn chi tiết
- Vấn đề tương tự lặp lại trong thực thi mã
- Nếu người dùng bấm vào thì mặc định gần như bất cứ thứ gì cũng chạy được, chỉ bị từ chối khi antivirus hoặc công cụ chặn spyware ngăn lại
- Trên thực tế, ứng dụng thường dùng chỉ khoảng 15 cái, thi thoảng dùng khoảng 20~30 cái, vậy mà hệ điều hành vẫn mặc định cho phép virus hoặc spyware thực thi
- Dự án bảo mật E-banking dùng cách tiếp cận ngược lại
- Thay vì để bộ cân bằng tải đưa các cuộc tấn công đã biết vào blackhole, mọi lưu lượng không khớp với danh sách URL hợp lệ đều được chuyển tới một máy chủ khóa chỉ trả về hình ảnh và trang 404
- Đây không phải Default Permit chỉ chặn các cuộc tấn công đã biết, mà là cách từ chối những yêu cầu đi lệch khỏi cấu trúc bình thường
- Nếu đang chạy đua vũ trang với kẻ tấn công, đó là dấu hiệu đã rơi vào Default Permit
- Khái niệm ngược lại là Default Deny, đòi hỏi cam kết triển khai, suy nghĩ và hiểu biết, nhưng là cách tiếp cận tốt hơn
2. Enumerating Badness: liệt kê những thứ xấu
- Enumerating Badness là cách lập danh sách mọi thứ xấu đã biết rồi phát hiện hoặc chặn chúng
- Ban đầu điều này có vẻ khả thi vì số lỗ hổng bảo mật đã biết còn ít, nhưng khoảng từ năm 1992 trở đi, “những thứ xấu” trên Internet đã nhiều hơn hẳn “những thứ tốt”
- Một sản phẩm antivirus điển hình biết hơn 75.000 virus
- Một máy tính cá nhân thường chỉ có khoảng 30 ứng dụng hợp lệ được cài đặt
- Nếu theo dõi 30 ứng dụng hợp lệ đó và ngăn mọi thứ khác chạy, có thể đồng thời giảm spyware, virus, trojan điều khiển từ xa và các khai thác thực thi mã có sẵn mà người dùng ít khi cần
- Theo một số phân tích trong ngành, mỗi tháng có 200~700 “thứ xấu” mới xuất hiện trên Internet
- Trước phản biện rằng mạng doanh nghiệp quá phức tạp để xác định ứng dụng hợp lệ, tác giả đáp rằng nếu CTO còn không nắm đại khái công nghệ đang làm gì thì cũng không thể lập kế hoạch năng lực, kế hoạch khôi phục thảm họa hay kế hoạch bảo mật
- Việc phân tích log của sản phẩm tường lửa năm 1994 lúc đầu là tìm các điều kiện xấu, nhưng phiên bản thứ hai dùng Artificial Ignorance
- Loại bỏ những log đã biết là không đáng quan tâm
- Phần log còn lại được xem là đáng chú ý
- Cách tiếp cận này đã phát hiện ra các điều kiện vận hành và lỗi mà trước đó không nghĩ tới
- Antivirus, phát hiện xâm nhập, ngăn chặn xâm nhập, bảo mật ứng dụng và tường lửa kiểm tra gói sâu thường dựa vào cách làm này
- Nếu một hệ thống cần cập nhật chữ ký định kỳ hoặc để lọt một sâu máy tính chưa từng thấy, đó là dấu hiệu của Enumerating Badness
- Cách chữa là Enumerating Goodness, nhưng tác giả cho rằng hệ điều hành gần như không hỗ trợ kiểm soát mức phần mềm kiểu này
3. Penetrate and Patch: xâm nhập rồi vá
- Penetrate and Patch là vòng lặp tấn công từ bên ngoài vào tường lửa, phần mềm, website... để tìm lỗi, sửa lỗi đó rồi lại tiếp tục tìm
- Cách này không tạo ra hệ thống tốt hơn về mặt thiết kế, mà chỉ tạo ra hệ thống cứng cáp hơn nhờ thử-sai
- Richard Feynman với bài Personal Observations on the Reliability of the Space Shuttle là tài liệu đáng đọc về cách đạt được độ tin cậy cho hệ thống phức tạp
- Thông điệp cốt lõi gần với ý rằng “nếu hệ thống không được thiết kế để có thể bị hack thì nó không nên bị hack được”
- Trào lưu công bố lỗ hổng và cập nhật bản vá cũng dựa trên cách tiếp cận này
- Nhà nghiên cứu lỗ hổng cho rằng họ giúp cộng đồng bằng cách tìm lỗ trước hacker để vá
- Nhà cung cấp cho rằng họ đang làm điều đúng vì phát hành bản vá trước khi hacker và tác giả sâu máy tính khai thác
- Nhưng nếu mã được thiết kế an toàn và đáng tin cậy ngay từ đầu, việc tìm ra lỗ hổng sẽ trở thành công việc nhàm chán và ít phần thưởng
- Nếu Internet Explorer có lỗi bảo mật suốt 10 năm, mỗi tháng 2~3 lỗi, thì khó có thể nói Penetrate and Patch là hiệu quả
- Một số ứng dụng như PostFix và Qmail được thiết kế để mô-đun hóa quyền hạn và xử lý, phân vùng rõ ràng, nên có lịch sử lỗi bảo mật rất ít
- Kiểm thử xâm nhập cũng có cùng giới hạn
- Một mạng có thiết kế nền tảng hoặc thực hành bảo mật sai vẫn sẽ tiếp tục bị hack dù đã kiểm thử xâm nhập nhiều lần
- Với mạng được thiết kế ngay từ đầu để chỉ cho phép đúng hướng, đúng loại lưu lượng và các máy chủ cấu hình cẩn trọng đi qua, kiểm thử xâm nhập thông thường có thể trở nên vô nghĩa
- Nếu lúc nào cũng dễ bị tổn thương trước “lỗi của tuần này”, nghĩa là đang mắc kẹt trong Penetrate and Patch
- Phần mềm và hệ thống phải secure by design, và cần được thiết kế với việc xử lý lỗi ngay từ đầu
4. Hacking is Cool: coi hack là ngầu
- Hacking is Cool là lời phê phán văn hóa thưởng hoặc tô hồng hacker bằng stock option, sách, khóa học và các đợt kiểm thử xâm nhập giá cao
- Donn Parker cho rằng điện toán từ xa đã loại bỏ nhu cầu phải ở gần về mặt vật lý khi phạm tội, còn tính ẩn danh và việc không phải đối diện nạn nhân làm giảm rào cản cảm xúc của hành vi phạm tội
- Hack gần với vấn đề xã hội hơn là vấn đề kỹ thuật
- Internet tạo ra không gian hoạt động mới cho những người thiếu tính xã hội
- Khi người làm bảo mật biến hacker thành anh hùng, họ đang ngầm khuyến khích việc hack
- Truyền thông đôi khi miêu tả hacker là “whiz kids” hay “brilliant technologists”
- Việc người làm bảo mật học kỹ thuật hack cũng được xem là một phần của ý tưởng này
- Exploit và cách dùng chúng nhanh chóng lỗi thời khi lỗ hổng tương ứng được vá
- Năng lực chuyên môn vì thế bị phụ thuộc vào cuộc chạy đua vũ trang của Penetrate and Patch
- Hợp lý hơn là học cách thiết kế hệ thống bảo mật chống chịu tốt với hack thay vì học cách tìm hệ thống có thể bị hack
- Tác giả dự đoán “Hacking is Cool” sẽ biến mất trong vòng 10 năm, nhưng chưa thấy dấu hiệu điều ngược lại là “Good Engineering is Cool” sẽ thay thế
5. Educating Users: đào tạo người dùng
- Educating Users gần giống Penetrate and Patch áp dụng cho con người
- Việc đào tạo tự nó nghe có vẻ tốt, nhưng nếu hiệu quả thì đáng ra hiệu quả đó đã phải xuất hiện từ lâu
- Nhiều nghiên cứu cho thấy tỷ lệ đáng kể người dùng sẵn sàng đưa mật khẩu chỉ để đổi lấy một viên kẹo
- Sâu Anna Kournikova được dùng như ví dụ cho thấy gần một nửa nhân loại sẽ bấm vào bất cứ thứ gì trông như có ảnh khỏa thân của một phụ nữ hơi nổi tiếng
- Nếu coi đào tạo người dùng là chiến lược, có thể bạn phải “vá” người dùng mỗi tuần
- Câu hỏi thật sự không phải là “có thể đào tạo người dùng an toàn hơn không” mà là “tại sao ngay từ đầu lại phải đào tạo người dùng”
- Tại sao người dùng lại nhận file đính kèm thực thi
- Tại sao người dùng lại mong đợi email từ một ngân hàng nơi họ thậm chí không có tài khoản
- Xử lý file đính kèm và phishing cũng là vấn đề Default Permit
- Nếu cho phép mọi người dùng nhận file đính kèm email, tức là mặc định cho phép mọi thứ được gửi tới
- Cách tốt hơn là cách ly mọi file đính kèm, xóa file thực thi và chỉ giữ các định dạng được cho phép trên một máy chủ trung gian
- Người dùng có thể đăng nhập bằng trình duyệt hỗ trợ SSL để lấy file, và việc yêu cầu mật khẩu sẽ lập tức làm suy yếu nhiều cơ chế lây lan của sâu máy tính
- Công cụ miễn phí như MIMEDefang có thể được dùng để tách file đính kèm khỏi email đến, lưu vào thư mục riêng cho từng người dùng, rồi thay file đính kèm trong thư bằng URL tương ứng
- Khi vận hành một startup bảo mật nhỏ, nhân viên muốn dùng Windows phải tự biết cài đặt và quản trị nó, nếu không thì sẽ không được tuyển
- Tác giả dự đoán rằng trong vòng 10 năm, những người dùng còn cần đào tạo sẽ либо bị loại khỏi thị trường lao động công nghệ cao, либо sẽ tự rèn luyện ở nhà để giữ sức cạnh tranh
6. Action is Better Than Inaction: tin rằng hành động luôn tốt hơn không hành động
- Các lãnh đạo IT được chia thành “early adopters” và “pause and thinkers”, và tác giả cho rằng những người tạo ra hệ thống trọng yếu thành công và an toàn thường gần với nhóm sau hơn
- Khi có công nghệ mới, chờ đợi, xem kết quả từ những bên áp dụng sớm khác, rồi triển khai sau khi đã có người dày dạn kinh nghiệm có thể an toàn hơn là cài đặt ngay
- Một lãnh đạo IT cấp cao đã lập kế hoạch triển khai mạng không dây doanh nghiệp bằng cách “đợi 2 năm rồi tuyển người đã từng triển khai wireless thành công ở công ty lớn hơn chúng ta”
- Trong thời gian đó, công nghệ trưởng thành hơn và giá cũng giảm đi rất nhiều
- Mệnh đề phụ cốt lõi là “thường thì tránh làm điều ngớ ngẩn còn dễ hơn làm điều thông minh”
- Lời khuyên tiếp theo là cũng nên trì hoãn việc thuê ngoài bảo mật 1~2 năm và lắng nghe khuyến nghị, ý kiến từ các tổ chức còn sống sót sau giai đoạn đó
- Trong một trường hợp khách hàng định chi số tiền lớn mà chưa được kiểm chứng, tác giả đề xuất gửi nhân viên tới hội nghị LISA để tìm người đã dùng thực tế
- Nhân viên đó có thể mời những người từng trải nghiệm sản phẩm đi ăn tối để nghe đánh giá không chính thức
- Một quản lý IT kể rằng bữa tối 200 USD đã giúp giảm hơn 400.000 USD đau đớn kỹ thuật
- “Kung-fu” chuyên nghiệp nằm ở chỗ tránh làm điều ngớ ngẩn bằng cách không làm gì cả, rồi khiến cấp trên công nhận công lao cho sự né tránh đó
Những điều ngớ ngẩn nhỏ khác
- “Chúng tôi không phải mục tiêu”
- Sâu máy tính không đủ thông minh để phán đoán website hay mạng gia đình có đáng quan tâm hay không
- “Nếu mọi người dùng một hệ điều hành bảo mật đang là mốt thì sẽ an toàn”
- Hệ điều hành vốn phức tạp nên luôn có vấn đề bảo mật, và quản trị hệ thống vẫn chưa phải bài toán đã được giải xong
- Đổi theo mốt có thể còn khiến quản trị viên khó tích lũy chuyên môn nhờ thời gian hơn
- “Có bảo mật host tốt rồi nên không cần tường lửa”
- Nếu không thể tin vào hạ tầng mạng, thì mọi ứng dụng đi qua mạng đều là mục tiêu tiềm năng
- Domain Naming System được nêu làm ví dụ
- “Có tường lửa tốt rồi nên không cần bảo mật host”
- Nếu tường lửa cho lưu lượng đi qua tới các host phía sau, thì vẫn phải xem xét bảo mật host của các hệ thống đó
- “Cứ đưa lên production đã rồi bảo mật làm sau”
- Nếu bây giờ không có thời gian làm cho đúng, thì hãy tự hỏi liệu sau khi hỏng rồi có thời gian làm lại không
- Chỉ vì không dành vài ngày đầu mà có thể phải sửa liên tục suốt nhiều năm
- “Những vấn đề thỉnh thoảng mới xảy ra thì không thể ngăn được”
- Nếu ngành hàng không cũng tiếp cận như vậy đối với sinh mạng, liệu bạn có dám ngồi máy bay chở khách thương mại không
Thái độ cần có của người làm bảo mật
- Tác giả cho rằng bảo mật máy tính đã quá mê mẩn “công nghệ mới của tuần này” đến mức vứt bỏ lẽ thường
- Công việc của người làm bảo mật là chất vấn quan niệm phổ biến và hiện trạng, và nếu cần thì thách thức trực diện chúng
- Bài viết kết lại bằng vấn đề rằng nếu quan niệm phổ biến thực sự hiệu quả thì tỷ lệ hệ thống bị xâm nhập lẽ ra phải giảm xuống
1 bình luận
Ý kiến trên Hacker News
Lại nói chuyện này nữa à: https://hn.algolia.com/?q=six+dumbest+ideas+in+computer+secu...
Bài này có nhiều điểm để mổ xẻ, nhưng điều tôi luôn muốn chỉ ra là suy nghĩ bên trong của Ranum về nghiên cứu lỗ hổng mà ông phản đối. Cuối thập niên 90 đến đầu thập niên 2000, Marcus Ranum và Bruce Schneier là những trí thức tiêu biểu cho quan điểm rằng việc công bố lỗ hổng gây hại nhiều hơn có lợi, và đó là việc vendor nên làm chứ không phải các nhà nghiên cứu bên ngoài. Góc nhìn đó rốt cuộc đã không đúng; năm 2002 còn có thể gộp nghiên cứu lỗ hổng công khai hoàn toàn từ bên ngoài vào dưới nhãn “hacking”, nhưng giờ thì hoàn toàn không. Không chỉ 4 hội nghị học thuật lớn trong lĩnh vực bảo mật, mà cả tài liệu mật mã học cũng bàn về nghiên cứu tấn công
Không biết có bị bỏ sót không, nhưng tôi ngạc nhiên là không thấy nói về mật khẩu. Tôi cho rằng các quy tắc bắt buộc về thành phần, ngoại trừ độ dài tối thiểu, việc thay đổi định kỳ, và các nỗ lực “thay thế mật khẩu” về bản chất đều ngớ ngẩn. Quy tắc thành phần dẫn đến việc ghi ra giấy, tái sử dụng cùng một mật khẩu, thêm số 1 ở cuối; còn các phương án thay thế thì UX tệ hại hoặc gây rối, rồi cuối cùng lại quay về mật khẩu. Cứ cho tôi tạo mật khẩu dài ít nhất X ký tự bằng các ký tự tôi chọn, thì dù không có điện thoại hay máy tính, hoặc đang ở nước ngoài, tôi vẫn thực sự nhớ được
suckmyDICK123!!. Dù vậy thường cũng không dễ bị chiếm, vì thông lượng brute force không đủ hoặc sai 5 lần là tài khoản bị khóa. Ngày nay hầu hết mọi người đều biết đại khái rằng “bot thử mật khẩu với tốc độ siêu phàm”, và không chính sách mật khẩu nào ngăn được việc chọn mật khẩu kém. Đây là trường hợp những người “có trách nhiệm” lãng phí cực nhiều thời gian để giải quyết thực tế. Trừ một hai tài khoản nhạy cảm như ngân hàng, với các dịch vụ bắt tạo tài khoản một cách miễn cưỡng, kiểu 80 trò chơi chỉ chơi thử 1 phút, người ta sẽ muốn dùng cùng một mật khẩu. Nhiều trường hợp còn là GUI riêng nên không dán được, và dù có thể dùng trình quản lý mật khẩu, thật sự chẳng có lý do gì phải làm vậyHacking có thể rất ngầu. Không phải là truy cập dữ liệu và hệ thống của người khác, mà là hiểu sâu hệ thống mình sở hữu để tìm cách khiến nó “hoạt động sai” theo hướng có lợi cho mình, điều đó rất ngầu. Mở khóa nhà hàng xóm thì không hay, nhưng mở khóa của chính mình thì ngầu; thao túng máy tính từ xa để có quyền truy cập bất chính thì không hay, nhưng khiến máy tính của mình làm việc vốn bị ngăn không cho làm thì ngầu. Tinh thần khám phá rìa của những điều có thể mới là thứ đẩy thế giới tiến lên, và có lẽ hiếm xã hội loài người thành công nào lại tôn vinh việc ở yên trong khuôn khổ
Bài này có rất nhiều phán đoán cực tệ. Những câu kiểu “tôi đã thiết kế, triển khai và cấu hình hệ thống của mình cẩn thận nên không cần kiểm thử” có thể là quan điểm bảo mật tệ nhất tôi từng nghe. Câu “hacking là vấn đề xã hội chứ không phải vấn đề kỹ thuật” cũng gần với bảo mật dựa vào che giấu, và không phải lúc nào cũng là vấn đề xã hội. Nhìn vào gián điệp doanh nghiệp hay tác nhân cấp quốc gia thì không phải vậy
Vấn đề cốt lõi thường là sự đánh đổi đáng tiếc giữa tính dễ dùng và bảo mật, và phần lớn những thứ được nêu là ý tưởng ngớ ngẩn ở đây là kết quả của việc hy sinh bảo mật để giảm bất tiện cho người dùng trung bình. Ví dụ, mặc định cho phép là điều tệ nhất đối với bảo mật và là nguyên nhân của nhiều vấn đề trên Windows, nhưng người dùng lại ghét việc phải cho phép rõ ràng mỗi khi có chương trình mới. Ngay cả khi Microsoft thêm hộp thoại xác nhận, nhiều người vẫn xem đó là thiết kế tệ khiến phần mềm phiền phức hơn nhiều. Vì vậy “mặc định cho phép”, “liệt kê cái xấu”, “vá sau khi bị xâm nhập” đã trở thành mặc định. Cá nhân tôi cho rằng bản thân mật khẩu là một trong những ý tưởng ngớ ngẩn nhất trong bảo mật. Bởi định nghĩa của một mật khẩu tốt chính là khó nhớ, khó nhập trên thiết bị không có bàn phím tử tế, và bất tiện với người dùng ở hầu như mọi khía cạnh. Nhưng cũng không có lựa chọn thay thế thực tế. Liên kết qua email thì nếu quyền truy cập email bị chiếm là mất tất cả, và đặt lại mật khẩu thường cũng tương tự. Thiết bị xác thực vật lý khiến người dùng không thể đăng nhập khi ra khỏi nhà hoặc phải luôn mang theo một món phụ kiện; gần như mọi cách đều đòi hỏi thói quen bảo mật tốt, trong khi 99,9% dân số không mấy quan tâm
Nhận định “học nhiều exploit và cách sử dụng chúng tức là dành thời gian học các công cụ và kỹ thuật sẽ trở nên lỗi thời khi chúng sớm được vá” là sai. Trên thực tế, đó là học khía cạnh thực hành song song với lý thuyết, và rất hữu ích
Tôi sẽ bỏ “hacking thì ngầu” khỏi danh sách này và thêm tin tưởng client. Gần đây có nhiều nỗ lực muốn tin tưởng client hơn. Chẳng hạn ứng dụng di động yêu cầu chứng minh rằng hệ điều hành chưa bị chỉnh sửa, hoặc việc Google từng cố đưa một dạng DRM tương tự vào web. Nếu mô hình an ninh mạng phụ thuộc vào việc tin tưởng phần mềm client thì nó đã hỏng sẵn rồi
Về “mặc định chặn”, có câu rằng “không khó hơn mặc định cho phép nhiều và sẽ giúp bạn ngủ ngon hơn vào ban đêm”; người phụ trách bảo mật IT có thể ngủ ngon hơn, nhưng những người còn lại trong công ty sẽ cực kỳ bực vì việc gì cũng phải qua lại với bộ phận IT ba lần. Và con người càng bực bội thì càng dễ dùng các cách lách làm sụp đổ khái niệm bảo mật. Kiểu như ép đổi mật khẩu hằng tháng thì người ta sẽ dùng
password1,password2,password3. Bảo mật IT tốt không phải chỉ là rút cáp mạng, mà phải vô hình và không gây vướng víu như phép thuật đối với người dùngCác bài viết lấy bảo mật làm trung tâm thường do những người cực kỳ coi trọng bảo mật viết, và hay bỏ qua những khó khăn mà cách tiếp cận thuần túy xoay quanh bảo mật gây ra cho người dùng phần mềm an toàn. Tôi luôn nhìn bảo mật như một thanh trượt giữa an toàn và tiện lợi. Một thiết kế hoàn toàn an toàn sẽ bất tiện đến mức hầu như không có người dùng, còn một thiết kế hoàn toàn tiện lợi cũng không đủ an toàn và cuối cùng có thể đi đến cùng một kết cục. Dù vậy, nhìn chung bài này vẫn đáng đọc, nhưng tôi phản đối mạnh mẽ ý nghĩ rằng chuyên gia bảo mật viết exploit hoặc học cách lạm dụng một hệ thống cụ thể là ngu ngốc. Tôi đã học được về bảo mật nhiều hơn rất nhiều từ việc nghiên cứu lỗ hổng và exploit, rồi tự triển khai chúng theo kiểu white-hat, so với việc học “thiết kế an toàn”. Nó giống câu “muốn hiểu hắn thì phải thử trở thành hắn”
Đây phần lớn là một danh sách tệ hại từ 19 năm trước. Nói rằng “phần mềm và hệ thống phải an toàn ngay từ khâu thiết kế, và đáng lẽ phải được thiết kế có tính đến cả việc xử lý lỗi” chẳng khác nào nói “trong một thế giới hoàn hảo, mọi thứ đã an toàn ngay từ đầu”. Chuyện đó sẽ không bao giờ xảy ra, nên phải dùng kỹ thuật phát hiện rồi vá, và nó đã hoạt động tốt với những công ty thực sự vá các lỗ hổng được phát hiện và học từ sai lầm để cải thiện thực hành lập trình về sau. Hơn nữa, phần lớn hệ thống không tĩnh. Không phải cứ phát hành một hệ thống an toàn một lần rồi không bao giờ cập nhật nữa; hầu hết ứng dụng và hệ thống được cập nhật thường xuyên, và khi đó các lỗ hổng mới lại được đưa vào
scripthoặconclick