Câu hỏi này có thể không có câu trả lời hoàn hảo và thậm chí là một vòng luẩn quẩn. Luôn có một sự căng thẳng giữa các developer và các chuyên gia bảo mật. Bên này đổ lỗi cho bên kia về các rủi ro bảo mật trong bảo mật ứng dụng và các lĩnh vực khác. Dù là lỗi của ai, phòng thủ kỹ thuật số (digital defense) nhìn chung sẽ bị ảnh hưởng trừ khi hai bên hợp tác với nhau. Các chuyên gia của Security Intelligence thuộc IBM đã nói chuyện với Vikram Kunchala, người đứng đầu về hoạt động đám mây mạng của Deloitte tại Mỹ, về việc làm thế nào để các chuyên gia bảo mật và các nhà phát triển làm việc cùng nhau.
Ai chịu trách nhiệm về bảo mật ứng dụng?
Kết quả từ một cuộc khảo sát GitLab gần đây cho thấy hầu hết các chuyên gia bảo mật thiếu niềm tin vào khả năng viết code an toàn của các developers, trong khi hầu hết các developers lại cảm thấy họ thiếu sự hướng dẫn thích hợp. Điều tồi tệ hơn, nhiều công ty được khảo sát đã cho thấy họ không đủ nghiêm túc trong việc bảo mật.
Tuy nhiên, điều thiếu nhất là sự rõ ràng. Cần phải có sự đồng thuận rõ ràng hơn về việc ai là người chịu trách nhiệm về vấn đề này.
Cũng theo kết quả khảo sat của Gitlab, một phần ba số người được khảo sát bày tỏ rằng họ rất quan tâm đến vấn đề bảo mật. Nhưng nhiều người trong số họ (29%) cho rằng mọi người đều có trách nhiệm. Những người khác (21%) thì cho đó là trách nhiệm của các developer, trong khi 12% tin rằng đội ngũ vận hành phải có trách nhiệm.
Vậy làm thế nào để hai đội có thể làm việc cùng nhau vì lợi ích lớn hơn?
Shifting left (Dịch chuyển sang trái) sẽ là một khởi đầu tốt. Đây là một thuật ngữ bạn nên làm quen, với ý nghĩa là đưa vấn đề bảo mật vào quy trình phát triển sớm hơn thay vì để sau. Di chuyển sang trái cho phép giải quyết các vấn đề phòng vệ sớm và xuyên suốt trong toàn bộ quá trình.
Tầm quan trọng của secure code trong bảo mật ứng dụng
Kunchala nói rằng secure code (code bảo mật hay code an toàn) ngày nay quan trọng hơn bao giờ hết do làm việc từ xa ngày càng tăng. Việc nắm bắt các rủi ro khi làm việc từ xa là rất quan trọng để có thể xây dựng một cơ chế bảo mật tốt.
“Ngày càng nhiều các vụ tấn công. Nó không nằm trong bốn bức tường của doanh nghiệp của bạn, ”ông nói. “Bảo mật ứng dụng nên được ưu tiên hàng đầu. Mục tiêu tấn công lớn nhất là lớp ứng dụng”.
Việc tập trung vào bảo mật ứng dụng không có gì mới. Hầu hết các cuộc tấn công xảy ra ở lớp ứng dụng, việc tập trung vào việc xây dựng mã bảo mật đã diễn ra trong hàng thập kỷ qua. Tuy nhiên, điều đó cũng tăng việc đẩy và kéo giữa các developer và các chuyên gia bảo mật.
Làm việc với nhiều khách hàng trong nhiều ngành khác nhau, Kunchala nhận ra rằng những khách hàng mà trong đó việc phòng vệ được xây dựng trong văn hóa sẽ ít có xung đột hơn trong việc bảo mật ứng dụng. Tất nhiên, nó phụ thuộc nhiều vào ngành cụ thể. Đối với một số lĩnh vực như chăm sóc sức khỏe và tài chính, bảo mật có thể được đặt lên hàng đầu. Đối với những ngành khác, nó có thể không quá quan trọng.
Ông nói: “Đó là một vấn đề không khá phức tạp và phần lớn được xác định bởi cách công ty nhận thức về bảo mật và mức độ quan trọng của bảo mật đối với các sản phẩm và giải pháp của họ”.
Tư duy của developer
Với nhu cầu ngày càng cao về các phần mềm và ứng dụng trong môi trường kinh doanh ngày nay, ưu tiên hàng đầu đối với bất kỳ nhà phát triển nào phát hành code một cách nhanh chóng. Đó là một thực tế khắc nghiệt và gây áp lực không nhỏ lên các bộ phận phát triển. Trên thực tế, cuộc khảo sát của GitLab cho thấy 82% nhà phát triển đang phát hành code nhanh hơn và trong một số trường hợp, tốc độ tăng gấp hai đến năm lần.Thông tin trong bảng báo cáo phản ánh những gì mà các developer xem là quan trọng nhất
Kunchala nói: “Nếu tôi là một nhà phát triển, quy tắc của tôi là đưa ra những mã có chức năng và chất lượng tốt, và phải nhanh chóng để đưa ra thị trường. Vì vậy, an ninh có lẽ không nằm trong tâm trí của tôi.”
Đối với các developer và trong hầu hết các tổ chức kinh doanh, mã chất lượng tốt có nghĩa là đáp ứng mọi mục tiêu của tổ chức và doanh nghiệp.
“Đó là quan điểm của nhà phát triển,” anh nói. “Vấn đề là cả hai đều đang hoạt động trên các ưu tiên khác nhau.” Từ quan điểm của nhà phát triển, việc làm cho bảo mật trở nên tốt nhất có thể giống như một cảnh sát với khẩu súng bắn tốc độ làm chậm họ lại trong khi họ chỉ muốn đi nhanh hơn.
Chuyên gia bảo mật: Cách tìm điểm chung
Từ quan điểm của chuyên gia bảo mật, không khó để xác định cách chúng ta đang nghĩ. Họ muốn các nhà phát triển viết code với tính năng bảo mật ứng dụng được tích hợp sẵn. Nhưng thay vì nói về tư duy, điều quan trọng hơn là khám phá cách các chuyên gia bảo mật có thể làm việc với các nhà phát triển để đạt được mục tiêu chung là code an toàn.
Khi nói đến cảnh sát có súng bắn tốc độ, các chuyên gia an ninh phản đối điều đó bằng cách ví von “đây là tài xế lái xe không thắt dây an toàn hoặc không điều khiển phù hợp”. Nhưng dây an toàn không được tạo ra để làm bạn giảm tốc độ. Đồng thời, bảo mật cũng không có nghĩa là làm chậm các nhà phát triển. Kunchala nói: “Bảo mật sẽ giúp bạn tiến nhanh hơn với tư cách là một nhà phát triển, nếu bạn biết rằng các hệ thống bảo vệ và kiểm soát phù hợp được đặt ra. Điều quan trọng là tạo ra kết nối đó.” Theo Kunchala, có ba bước quan trọng mà các chuyên gia bảo mật nên cân nhắc khi trợ giúp các nhà phát triển với code an toàn.
1. Không nhất thiết phải hoàn hảo
Rào cản lớn nhất đối với các nhà phát triển trong việc áp dụng tư duy bảo mật là biết cách phòng thủ tốt sẽ như thế nào. Bạn không cần nó phải hoàn hảo. Không có thứ gì có thể hoàn hảo, trong bảo mật ứng dụng hay ở những bất kỳ lĩnh vực nào. Nhưng các nhà phát triển cần phải có một khuôn khổ để nói những điều như, “Nếu tôi làm được mười điều này, thì tôi đang đi đúng hướng.”
2. Bảo mật cho các nhà phát triển phải dễ sử dụng và dễ sử dụng
Nếu một nhà phát triển mất bốn tuần để viết code và sau đó cần năm tuần để giải quyết vấn đề bảo mật, thì đó chính là công thức dẫn đến thảm họa. Các chuyên gia bảo mật cần phải đưa ra các dịch vụ bảo mật của họ thông qua giao diện lập trình ứng dụng liền mạch. Bằng cách đó các nhà phát triển, như một phần của quy trình của họ, hiểu chính xác nơi sử dụng dịch vụ này.
3. Shift left – Chuyển sang trái
Thay đổi sang trái là tư duy mà trong đó bạn cần xây dựng bảo mật sớm thay vì thực hiệ vào trong giai đoạn cuối. Đối với các nhà phát triển đang xây dựng một sản phẩm hoặc một ứng dụng, họ cần phải tham gia với các nhóm bảo mật ứng dụng để trả lời một số câu hỏi dẫn đến các yếu tố rủi ro khác nhau:
- Bạn đang xây dựng loại ứng dụng nào?
- Rủi ro đối với các doanh nghiệp là do dữ liệu mà ứng dụng thu thập được hay do các yếu tố địa lý?
- Bạn đang làm việc với các ứng dụng tại chỗ (on-prem) hay các ứng dụng dựa trên đám mây?
Sau khi hiểu được các rủi ro, chúng ta có thể đưa ra các biện pháp kiểm soát cần được thực hiện. Đồng thời xử lý các biện pháp kiểm soát không được bỏ qua. Các nhóm đó phải tìm cách sử dụng các kiểm soát này một cách dễ dàng như một phần của quá trình phát triển và tiến trình CICD (continuous integration/continuous delivery), tức tích hợp liên tục / phân phối liên tục. Bằng cách này, bạn có thể phát triển một phương pháp thu hẹp số lượng sai sót nghiêm trọng có thể phát sinh.
Kunchala nói: “Đó thực sự là một trò chơi hợp tác. Phải hy sinh một ngôi làng để có thể làm đúng.”
Chống lại sự đẩy lùi
Trong vài năm qua, trước các mối đe dọa ngày càng tăng, phản ứng mặc định từ các nhóm phát triển ứng dụng là đẩy lùi. Giờ đây, các chuyên gia bảo mật cần làm cho việc phòng thủ dễ dàng hơn. Kunchala đề nghị giải quyết các vấn đề phổ biến nhất trước khi bắt đầu giải quyết các lĩnh vực bảo mật ứng dụng khó hiểu hơn.
Trước tiên, hãy giải quyết top 10 lỗ hổng bảo mật web phổ biến theo chuẩn OWASP. Ví dụ: bạn không nên có bất kỳ lỗ hổng chèn SQL hoặc lỗi tấn công SQL injection nào. Sau khi tập trung vào những rủi ro cơ bản, bạn có thể giúp các nhà phát triển xây dựng trên phần còn lại của các lớp.
Tiếp theo, đảm bảo rằng bảo mật ứng dụng và quét bảo mật khác được thực hiện sớm trong quy trình. “Ngay sau khi bạn xây dựng, hãy quét mã,” Kunchala nói. “Khi bạn viết mã, bạn sẽ có thể xem liệu có cách nào tốt hơn để viết một dòng lệnh hoặc một phần của chương trình hay không.”
Có lẽ lời khuyên quan trọng nhất mà bạn nên truyền đạt cho nhóm phát triển là thời gian khắc phục sự cố càng lâu thì càng tốn kém. “Nó không khác gì xây một ngôi nhà,” anh nói. “Nếu có vấn đề về nền móng, bạn không thể đợi sau khi mái nhà dựng lên để khắc phục sự cố nền móng”.
Điều quan trọng không kém là định lượng tác động của mã không an toàn. Ví dụ: nếu một ứng dụng không sử dụng được hoặc bị khai thác, tác động đến thương hiệu của công ty, lòng trung thành của khách hàng là sẽ rất lớn. Nếu hệ thống đặt phòng của một khách sạn gặp sự cố, doanh nghiệp đó có thể nhanh chóng bị lỗ hàng triệu đô la. Việc đưa ra lập luận của bạn trong bối cảnh kinh doanh thua lỗ giúp các nhà phát triển nhận ra sự cần thiết phải đặt vấn đề bảo mật lên hàng đầu.
Kunchala nói: “Có chuẩn bị tốt và biết được việc xây dựng các giải pháp an toàn thực sự cải thiện yếu tố tin cậy của công ty”.
Chiến thắng cho Bảo mật ứng dụng và hơn thế nữa
Cuối cùng, việc giải quyết tình thế tiến thoái lưỡng nan giữa nhà phát triển và các chuyên gia bảo mật này không khác gì vượt qua các rào cản quốc phòng khác. Bất kỳ công ty nào áp dụng văn hóa bảo mật sẽ luôn đi trước một bước so với những công ty không áp dụng. Điều đó cũng áp dụng cho quá trình phát triển.
Bên cạnh đó, khi công ty của bạn đặt vấn đề bảo mật ứng dụng và các biện pháp bảo vệ khác lên hàng đầu, bạn cũng đang đặt khách hàng lên hàng đầu. Khi các cuộc khảo sát cho chúng ta biết rằng 78% người được hỏi ở Mỹ tin rằng việc giữ bí mật dữ liệu của họ là cực kỳ quan trọng đối với một công ty, việc xây dựng bảo mật cho sản phẩm hoặc dịch vụ của bạn là đặt khách hàng của bạn lên hàng đầu. Và, có rất nhiều chiến lược để thúc đẩy một nền văn hóa với bảo mật được ưu tiên.
Trên hết, bạn cần đảm bảo được sự ủng hộ của cấp lãnh đạo. Đừng quên bao gồm các nhà quản lý, các bên liên quan chính và các nhóm CNTT có liên quan trong quá trình này và cập nhật chúng (với các tài liệu dễ đọc) thường xuyên nếu cần.
Kunchala nói: “Với bất kỳ quy trình nào, tính năng bảo mật phải được tích hợp sẵn chứ không phải bắt buộc. Bất cứ điều gì mà các tổ chức có thể làm để xem xét việc chuyển sang trái và bắt đầu tham gia bảo mật ở giai đoạn hình thành sẽ có lợi.”
Bài gốc trên Security Intelligence
