Bạn có bao giờ nên phát hành một cái gì đó mà bản thân bạn có thể hack?

12

Là người tạo ra một chương trình, có lẽ bạn đang ở một vị trí tốt hơn bất kỳ ai để nhận thức được các lỗ hổng bảo mật và các vụ hack tiềm năng. Nếu bạn biết về lỗ hổng trong hệ thống mà bạn đã viết, đó có phải là dấu hiệu tăng tính bảo mật PHẢI được thêm vào trước khi phát hành hay không, nên đánh giá theo từng trường hợp để xác định mức độ nghiêm trọng của khoảng cách bảo mật?

security release

— Morgan Herlocker
nguồn

7

Chắc chắn, NSA làm điều này mọi lúc :)

— Jaap

3

@Jaap: NSA luôn bị buộc tội về điều này . Trong một trường hợp tôi nhận thức được nơi mọi người phát hiện ra điều gì đã thực sự xảy ra, đó là tiêu chuẩn mã hóa DES, hóa ra các sửa đổi của NSA thực sự làm cho mã hóa mạnh hơn , không yếu hơn, khiến nó ít bị hack bởi một kỹ thuật rằng không ai ngoài NSA thậm chí đã phát hiện ra, bởi vì họ biết rằng cuối cùng ai đó sẽ tìm ra nó.

— Mason Wheeler

6

@MasonWheeler Tôi nghĩ rằng các sự kiện gần đây đã đưa ra nhận xét của bạn, ở đây từ năm 2012, đã lỗi thời.

— aceinthehole

6

Tôi muốn nói rằng nó nên được thực hiện trên cơ sở từng trường hợp. Bạn là tác giả, bạn biết nhiều lỗ hổng. Một số lỗ hổng chỉ có thể được biết đến với bạn. Tất nhiên, điều đó có nghĩa là nếu bất kỳ câu hỏi nào trong số chúng bị khai thác, bạn có thể có một số câu hỏi khó trả lời, vì vậy có thể là một ý tưởng tốt để giảm các lỗ hổng này nếu có thể. Quan trọng hơn là nếu ai đó có thể dễ dàng hack nó như một hệ thống hộp đen.

— Thất vọngWithFormsDesigner
nguồn

3

Tôi chỉ muốn tôi biết tất cả các lỗ hổng trong phần mềm tôi đã viết. Sau đó, tôi có thể tận dụng điều đó để tìm ra tất cả các lỗi, và sẽ dễ dàng hơn nhiều để có được những thứ được viết đúng.

— David Thornley

1

@David: Ok, nhiều ...

— Thất vọngWithFormsDesigner

31

Tôi đã có trải nghiệm đáng tiếc khi ở trong tình huống hai lần. Các doanh nghiệp trong cả hai trường hợp đã đưa ra các sản phẩm có vấn đề bảo mật nghiêm trọng với dữ liệu rất nhạy cảm.

Trong cả hai trường hợp, doanh nghiệp dường như không quan tâm, bất chấp những nỗ lực tốt nhất của tôi để khiến họ nhận thức được những rủi ro mà họ đang gặp phải.

Điều duy nhất bạn có thể làm là phản đối càng lớn * (và chuyên nghiệp) càng tốt, càng rõ ràng càng tốt về hậu quả tiềm tàng, và trong khi bạn đang làm tài liệu đó mọi thứ . In các email có liên quan của bạn thành PDF và giữ các tệp đó ở nhà, hoặc bcc địa chỉ email cá nhân của bạn, hoặc tuy nhiên bạn làm điều đó. Đây là giải pháp duy nhất khi có điều gì đó tồi tệ chắc chắn xảy ra.

Bạn sẽ hy vọng rằng ban quản lý sẽ tôn trọng bạn vì lời khuyên kỹ thuật của bạn và tính đến điều đó nhưng thật không may, bạn phải tôn trọng bất cứ ai là người ra quyết định vào cuối ngày. Quyết định kinh doanh xấu được thực hiện mỗi ngày.

Chỉnh sửa: jasonk đã đề cập "Xin hãy cẩn thận BCCing địa chỉ nhà của bạn", và tôi rất đồng ý. Xin vui lòng không vi phạm chính sách của công ty và có nguy cơ đưa lỗ hổng bảo mật ra ngoài nhiều hơn so với hiện tại.

— aceinthehole
nguồn

21

+1 cho TÀI LIỆU MỌI THỨ !!! Khi một thảm họa lớn xảy ra và công việc của người quản lý đang trên đường, anh ấy / cô ấy sẽ làm BẤT K to việc thay đổi trách nhiệm theo bất kỳ cách nào họ có thể. Nếu bạn ghi lại các vấn đề, email, thông báo, ghi nhớ và các tài liệu khác liên quan đến quyết định thì bạn đang tự bảo vệ mình khỏi một tình huống xấu.

— maple_shaft

11

Af cking-men. Bất cứ ai đủ nhếch nhác để vận chuyển sản phẩm bị lỗi nghiêm trọng đều có thể, và sẽ, làm * bất cứ điều gì để tránh viên đạn cuối cùng.

— Peter Rowell

Xin hãy cẩn thận BCCing địa chỉ nhà của bạn.

— jasonk

2

@jasonk: Tại sao bạn nói vậy? BCC có nghĩa là những người nhận khác không thể nhìn thấy nó ...

— Mason Wheeler

3

@Mason: Người nhận không thể, nhưng CNTT có thể, và nếu bạn đang gửi thông tin nhạy cảm (mà lỗ hổng bảo mật chắc chắn nhất) ở bên ngoài, bạn có khả năng bị rơi vào thế giới bị tổn thương.

— Nhật thực

12

Tôi sẽ tranh luận ngược lại - là người sáng tạo, bạn thường xuyên quá gần với mã để xem các lỗ hổng.

Nếu bạn biết hoặc được thông báo về các lỗ hổng, chúng giống như bất kỳ lỗi nào khác - đánh giá, ưu tiên, sau đó sửa chữa.

— DaveE
nguồn

+1: Bạn biết chương trình của tôi sẽ hoạt động như thế nào và ở một mức độ nào đó chỉ nghĩ về việc sử dụng nó như thế. Có ai đó không biết cách "chính xác" để sử dụng chương trình là một trong những thử nghiệm tốt nhất bạn có thể làm.

— unolysampler

Là một người tương đối mới với QA, tôi đã tham gia vào công việc mong đợi các lỗi "lỗ hổng bảo mật" sẽ gặp phải lực hấp dẫn cực độ. Nhưng tôi đã thấy rằng nhãn "bảo mật" không phải lúc nào cũng tạo ra nhu cầu về phản ứng không khoan nhượng. Một số công ty hoàn toàn vui mừng chấp nhận rủi ro bảo mật nếu lỗ hổng này dường như không gây nguy hiểm cho uy tín thương hiệu hoặc cung cấp cho tin tặc ít lợi ích và các bản phát hành trong tương lai có thể bao gồm sửa lỗi (hoặc thay đổi tính năng).

— Greg Gauthier

4

Tôi nghĩ rằng câu trả lời phụ thuộc vào mức độ thiệt hại sẽ xảy ra nếu hệ thống bị xâm nhập bởi một tin tặc độc hại. Rõ ràng một kỹ sư dân sự không thể phê duyệt thiết kế của một cây cầu không an toàn trong lương tâm tốt. Việc xây dựng một cây cầu như vậy có thể dẫn đến thương tích hoặc tử vong. Kỹ sư cũng cố tình làm điều này là bất hợp pháp, nhưng thực tế là các kỹ sư phần mềm (ít nhất là ở Hoa Kỳ) không bị ràng buộc về mặt pháp lý theo cách tương tự không loại bỏ trách nhiệm chuyên môn của họ đối với các hệ thống bị lỗi. Thật không may, công ty của bạn có thể không cần chữ ký của bạn để phát hành phần mềm.

Bạn không chỉ định bản chất chính xác của hệ thống bạn đang làm việc. Nếu nó liên quan đến hồ sơ y tế, ngân hàng, kiểm soát không lưu hoặc một số cơ sở hạ tầng thực sự quan trọng khác, tôi sẽ nói rằng bạn sẽ được chứng minh rõ ràng khi nhấn mạnh vào mức độ bảo mật cao nhất có thể trước khi phát hành.

— Peter ALLenWebb
nguồn

+1 Đối với ngữ cảnh, tôi sẽ thêm rằng bất kỳ dữ liệu nào bao gồm số an sinh xã hội, số nhận dạng hoặc số thẻ tín dụng cũng cần chú ý đến bảo mật. Các hệ thống không lưu trữ bất kỳ thông tin nào và các hệ thống không quan trọng này có dữ liệu rủi ro thấp và bạn sẽ không cần phải lo lắng về bảo mật.

— maple_shaft

3

Có, bạn NÊN sửa nó trước khi phát hành. Đừng bao giờ đánh giá thấp sự khéo léo của một hacker. Bạn sẽ đi nghỉ một tuần với cửa sau mở rộng? Lý do của bạn sẽ là,

"Ồ nó ở phía sau và nó không đối diện trực tiếp với đường phố. Không ai sẽ thấy nó treo rộng .."

Chắc là không.

Nhưng tôi thực sự hiểu những ngày này với Thủ tướng không biết làm thế nào ngày phát hành thiêng liêng nhất quan trọng hơn một vấn đề trách nhiệm rất lớn với an ninh. Nếu đây là trường hợp của bạn thì tôi khuyên bạn nên gọi nó để chú ý, ghi lại vấn đề, đảm bảo rằng nó được ghi chép rõ ràng, được biết đến và các rủi ro được giải thích rõ ràng và để Thủ tướng quyết định làm gì.

Nếu Thủ tướng đưa ra một quyết định tồi tệ và quyết định bỏ qua điều này và tiếp tục phát hành theo lịch trình thì bạn sẽ được miễn trách nhiệm kể từ khi bạn thổi còi.

Mặt khác, nếu bạn tìm thấy điều này và giữ nó cho riêng mình và điều gì đó xảy ra thì BẠN có thể phải chịu trách nhiệm cá nhân về hậu quả.

Sự lựa chọn là của bạn.

— phong_shaft
nguồn

4

Ở Mỹ, ít nhất, đó không phải là một vấn đề trách nhiệm rất lớn, bởi vì gần như không có phần mềm nào đi kèm với bất kỳ loại bảo đảm nào. Phần mềm thiết bị y tế là một ngoại lệ, và có thể có những phần mềm khác, nhưng hầu hết các dịch vụ dựa trên phần mềm và phần mềm chủ yếu dựa trên cơ sở "không bảo đảm".

— David Thornley

1

Không bảo đảm? Tại sao bạn không nói điều đó với hàng triệu khách hàng của Sony, những người có số an sinh xã hội và dữ liệu nhạy cảm khác bị đánh cắp vì CHÍNH XÁC những lỗ hổng bảo mật như OP đang đề xuất.

— maple_shaft

2

Trong khi David là chính xác, việc thiếu trách nhiệm dân sự có thể thi hành có thể là sự thoải mái lạnh lùng khi danh tiếng của công ty bạn bị hủy hoại, hoặc công ty nhỏ của bạn chỉ đơn giản là bị kiện tụng bởi một công ty lớn hơn.

— Peter ALLenWebb

@maple_shaft: Và Sony có trách nhiệm gì? Họ đã cung cấp một năm dịch vụ bảo vệ tín dụng, nhưng tôi không nghĩ họ có bất kỳ trách nhiệm pháp lý nào. Đó là một cú đánh vào danh tiếng của họ, nhưng họ đã sống sót như vậy trước đây.

— David Thornley

1

@Rory: Chúng ta hãy nhìn vào nó hai năm kể từ bây giờ. Tôi muốn nghĩ rằng rootkit fiasco, loại bỏ OtherOS tùy tiện và rò rỉ này sẽ khiến Sony trở nên ít phổ biến hơn trong thời gian dài, nhưng tôi hoàn toàn không tự tin.

— David Thornley