Điểm mù an ninh tối thượng mà bạn không biết mình có

Điểm mù an ninh
Các nhà phát triển thực sự dành bao nhiêu thời gian để viết mã?

Theo các nghiên cứu gần đây, các nhà phát triển dành nhiều thời gian để duy trì, thử nghiệm và bảo mật mã hiện có hơn là viết hoặc cải thiện mã. Các lỗ hổng bảo mật có thói quen xấu là xuất hiện trong quá trình phát triển phần mềm, chỉ xuất hiện sau khi một ứng dụng đã được triển khai. Phần đáng thất vọng là nhiều lỗi và lỗi bảo mật này có thể đã được giải quyết trong giai đoạn trước đó và có các phương pháp và công cụ thích hợp để phát hiện ra chúng.

Nhà phát triển dành bao nhiêu thời gian để học viết mã hoạt động? Và bao nhiêu được chi cho việc học về bảo mật mã? Hay học cách không viết mã? “

Sẽ tốt hơn nếu loại bỏ vấn đề khỏi hệ thống hơn là để nó ở đó, sau đó cố gắng phát hiện và ngăn chặn một cuộc tấn công đang diễn ra nhắm vào nó?

Bạn có thể kiểm tra kỹ năng mã hóa an toàn của mình bằng cách tự đánh giá ngắn này.

Cái giá thật sự của lỗi

Mọi người đều mắc lỗi, ngay cả những nhà phát triển. Lỗi phần mềm là không thể tránh khỏi và được chấp nhận như là “chi phí kinh doanh” trong lĩnh vực này.

Điều đó đang được nói, bất kỳ lỗi nào chưa được sửa chữa trong mã đều là mạch máu của những kẻ tấn công. Nếu họ có thể tìm thấy ít nhất một lỗi trong hệ thống có thể được khai thác theo đúng cách (tức là lỗ hổng phần mềm), họ có thể tận dụng lỗ hổng đó để gây ra thiệt hại lớn, có khả năng lên tới hàng chục triệu đô la – như chúng tôi xem qua các trường hợp được công khai nổi tiếng hàng năm.

Và ngay cả khi nói đến các lỗ hổng ít nghiêm trọng hơn, việc sửa chữa chúng có thể rất tốn kém – đặc biệt nếu một điểm yếu được giới thiệu sớm hơn nhiều trong SDLC do lỗi thiết kế hoặc thiếu yêu cầu bảo mật.

Xem tiếp:   Israel cấm bán công cụ giám sát và tấn công cho 65 quốc gia

Tại sao cách tiếp cận hiện tại đối với bảo mật phần mềm lại bị hạn chế?

1 – Phụ thuộc quá nhiều vào công nghệ (và không đủ vào con người)

Tuy nhiên, các công cụ tự động hóa và được cho là sẽ giảm bớt khối lượng công việc cho các nhà phát triển và nhân viên bảo mật ứng dụng bằng cách quét, phát hiện và giảm thiểu các lỗ hổng phần mềm:

Mặc dù những công cụ này đóng góp vào nỗ lực bảo mật không gian mạng, nhưng các nghiên cứu cho thấy rằng chúng chỉ có thể phát hiện ra 45% lỗ hổng tổng thể. cảm giác an toàn sai cực kỳ nguy hiểm 2 – Ngắt kết nối DevSec

Việc ngắt kết nối DevSec đề cập đến sự căng thẳng nổi tiếng giữa các nhóm phát triển và nhóm bảo mật do các ưu tiên khác nhau (và thường là xung đột) khi nói đến các tính năng mới và sửa lỗi.

Kết quả của sự xung đột này, 48% các nhà phát triển kết thúc thường xuyên đẩy mã dễ bị tổn thương vào sản xuất. Các lỗ hổng được phát hiện sau đó trong chu kỳ phát triển thường không được giảm thiểu, hoặc cuối cùng tạo ra chi phí bổ sung, sự chậm trễ và rủi ro hơn nữa. Đây là những hậu quả của suy nghĩ ngắn hạn: cuối cùng, sẽ tốt hơn nếu khắc phục sự cố tại nguồn thay vì dành thời gian và nguồn lực để tìm kiếm các lỗi mã sau đó trong vòng đời phát triển phần mềm.

3 – Giám sát chuỗi cung ứng của bạn nhưng không phải phần mềm của riêng bạn

Một sai lầm phổ biến khác là chỉ tập trung vào bảo mật chuỗi cung ứng phần mềm và chỉ giải quyết các lỗ hổng đã biết trong các gói và sản phẩm phần mềm hiện có được liệt kê trong cơ sở dữ liệu Các lỗ hổng phổ biến và Phơi nhiễm hoặc Cơ sở dữ liệu Quốc gia về Lỗ hổng bảo mật.

Xử lý bất kỳ lỗ hổng nào trong các thành phần của bên thứ ba, phụ thuộc của bạn hoặc môi trường hoạt động là điều cần thiết, nhưng điều này sẽ không giúp bạn giải quyết các lỗ hổng trong mã của riêng bạn.

Tương tự, theo dõi các cuộc tấn công tiềm ẩn thông qua hệ thống phát hiện xâm nhập (IDS) hoặc tường lửa, theo sau là phản ứng sự cố là một ý tưởng hay – và được OWASP Top 10 công nhận là cần thiết – nhưng những hoạt động này chỉ giải quyết hậu quả của các cuộc hơn là nguyên nhân.

Xem tiếp:   Các chuyên gia tìm thấy điểm tương đồng giữa LockBit 3.0 mới và BlackMatter Ransomware

Giải pháp: làm cho mã hóa an toàn trở thành một môn thể thao đồng đội

An ninh mạng của bạn chỉ mạnh bằng liên kết yếu nhất của bạn. Phát triển phần mềm không phải là một công việc trong dây chuyền lắp ráp, và – bất chấp mọi dự đoán – nó sẽ không sớm được tự động hóa hoàn toàn. Các lập trình viên là những người giải quyết vấn đề sáng tạo, những người cần phải đưa ra hàng trăm quyết định mỗi ngày khi họ viết mã, bởi vì phát triển phần mềm là một loại hình thủ công.

Khi nói đến nó, một đoạn mã có an toàn hay không là tùy thuộc vào kỹ năng của từng nhà phát triển.

Các quy trình, tiêu chuẩn và công cụ có thể giúp thúc đẩy và củng cố các phương pháp hay nhất, nhưng nếu nhà phát triển không biết về một loại phương pháp xấu cụ thể, họ có thể sẽ tiếp tục phạm phải cùng một lỗi (và đưa ra cùng một loại lỗ hổng trong mã) lặp đi lặp lại.

6 mẹo để trao quyền cho mã hóa an toàn

Số lượng lỗ hổng bảo mật mới được phát hiện đang tăng lên và các mối đe dọa do các tác nhân mạng độc hại gây ra ngày càng tinh vi hơn. Hầu hết các tổ chức bắt đầu triển khai vòng đời phát triển an toàn sau một sự cố, nhưng nếu bạn hỏi chúng tôi khi nào bạn nên bắt đầu, tất nhiên câu trả lời sẽ luôn là càng sớm càng tốt.

Đó là bởi vì khi nói đến các lỗ hổng nghiêm trọng, thậm chí hàng giờ có thể có nghĩa là sự khác biệt giữa không có thiệt hại lâu dài và một thảm họa tài chính.

Dưới đây là các mẹo hàng đầu của chúng tôi để thực hiện chính xác điều đó:

1 – Dịch chuyển sang trái – mở rộng quan điểm bảo mật sang các giai đoạn phát triển ban đầu

Chỉ dựa vào tự động hóa công cụ bảo mật kiểu DevSecOps là chưa đủ, bạn cần phải thực hiện thay đổi văn hóa thực tế. SAST, DAST hoặc kiểm tra thâm nhập nằm ở bên phải trong SDLC; chuyển sang trái theo hướng bắt đầu của vòng đời phát triển phần mềm để có phạm vi bao phủ toàn diện hơn.

Xem tiếp:   CERT Ukraina cảnh báo công dân về làn sóng tấn công mới phát tán phần mềm độc hại Jester

2 – Áp dụng phương pháp tiếp cận vòng đời phát triển an toàn

Ví dụ như MS SDL hoặc OWASP SAMM sẽ cung cấp một khuôn khổ cho các quy trình của bạn và hoạt động như một điểm khởi đầu tốt cho sáng kiến ​​an ninh mạng của bạn.

3 – Bao phủ toàn bộ hệ sinh thái CNTT của bạn

Các lỗ hổng của bên thứ ba gây ra rủi ro rất lớn cho an ninh mạng của doanh nghiệp bạn, nhưng các nhà phát triển của chính bạn cũng có thể gây ra các vấn đề cho ứng dụng. Bạn cần có khả năng phát hiện và giải quyết các lỗ hổng bảo mật trên cơ sở, trên đám mây và trong môi trường của bên thứ ba.

4 – Chuyển từ phản ứng sang phòng ngừa

Thêm các khái niệm lập trình phòng thủ vào hướng dẫn mã hóa của bạn. Mạnh mẽ là những gì bạn cần. Rốt cuộc thì bảo mật tốt là do hoang tưởng.

5 – Tư duy quan trọng hơn công nghệ

Tường lửa và IDS sẽ không tự phần mềm của bạn khỏi tin tặc; họ chỉ giải quyết hậu quả của các lỗ hổng đã tồn tại. Giải quyết tận gốc vấn đề: tư duy của nhà phát triển và trách nhiệm giải trình cá nhân.

6 – Đầu tư vào đào tạo mã an toàn

Tìm kiếm một ngôn ngữ lập trình bao gồm nhiều loại ngôn ngữ lập trình và cung cấp phạm vi bao quát kỹ lưỡng về các tiêu chuẩn mã hóa an toàn, cơ sở dữ liệu về lỗ hổng bảo mật và các loại điểm yếu quan trọng của phần mềm nổi tiếng trong ngành. Các bài tập thực hành trong phòng thí nghiệm trong môi trường gốc của các nhà phát triển là một điểm cộng rất lớn để giúp họ bắt kịp tốc độ một cách nhanh chóng và thu hẹp khoảng cách kiến ​​thức khó khăn đó.

Hành trình học tập kết hợp của Cydrill cung cấp đào tạo về mã hóa an toàn chủ động và hiệu quả cho các nhà phát triển từ các công ty trong danh sách Fortune 500 trên toàn thế giới. Bằng cách kết hợp đào tạo do người hướng dẫn hướng dẫn, học trực tuyến, phòng thí nghiệm thực hành và trò chơi, Cydrill cung cấp một cách tiếp cận mới và hiệu quả để học cách viết mã an toàn.

.

Related Posts

Check Also

Tin tặc chủ động khai thác lỗ hổng mới của tường lửa Sophos RCE

Công ty phần mềm bảo mật Sophos đã cảnh báo về các cuộc tấn công …