Phó chủ tịch phụ trách các Giải pháp Bảo mật, thuộc Bộ phận Ứng dụng và Bảo mật Mạng của Keysight, ông Scott Register nhận định, trong cơn sốt làm việc từ xa, bộ phận bảo mật đã phải ra những quyết định đột ngột đầy rủi ro trong "chế độ bình thường mới". 

Chúng ta phải thiết lập lại cấu hình các kiểm soát bảo mật, tạo ra những ngoại lệ chính sách tạm thời và đưa thiết bị đến nhà nhân viên. Trong khi đó các nhóm SecOps của chúng ta lại làm việc từ xa, khiến giảm khả năng giám sát được hệ thống có thể bị xâm phạm. Hơn nữa, làm việc từ xa thường bị thiếu quyền truy cập vào các báo cáo, cảnh báo và bảng điều khiển. Làm việc “mò mẫm” là ác mộng của các chuyên gia bảo mật. 

Lỗi cấu hình gây ra sự cố

Theo phân tích của chuyên gia Keysight, dữ liệu cho thấy rằng một trong những mối đe dọa lớn nhất của chúng ta phát sinh từ lỗi cấu hình sai, chính sách lỏng lẻo và các lỗi đơn giản. Báo cáo điều tra vi phạm dữ liệu năm 2020 của Verizon (DBiR) (DBiR) xác nhận điều đó và cho thấy sự gia tăng đáng kể lỗi cấu hình sai của thiết bị bảo mật đã dẫn đến các vụ xâm phạm dữ liệu. 

Khi vấn đề "những mối đe dọa nội bộ" đang được thảo luận rất nhiều trong ngành, thì chúng ta cần phải suy nghĩ rộng hơn về các mối đe dọa cụ thể này. Nó không phải là vì một nhân viên có ác ý, mà chủ yếu vì công việc hàng ngày của bộ phận an ninh bảo mật, CNTT và những nhân viên khác gây ra lỗi cấu hình và dẫn đến các vụ xâm phạm. 

Nhiệm vụ của bất kỳ nhóm SecOps nào cũng là bắt đầu việc thường xuyên tìm hiểu những lỗi cấu hình này nằm ở đâu và tìm ra cách khắc phục. Lỗi cấu hình có thể chỉ là những sự việc rất đơn giản như: Để mở một số cổng nào đó; Các giá trị mặc định không được thiết lập phù hợp để phát hiện việc đánh cắp dữ liệu; Không có đủ thời gian và nguồn lực để theo kịp số lượng bản cập nhật lớn do các nhà cung cấp giải pháp bảo mật tin cậy phát hành.

Cửa trước là các ứng dụng web

Báo cáo DBiR cho thấy 43% các vụ xâm phạm đi qua các ứng dụng web. Các ứng dụng web phát triển nhanh tới mức làm chóng mặt các chuyên gia CNTT và bảo mật. Kỷ nguyên của DevOps và AWS/Azure đã khiến bất cứ ai cũng có thể phát triển ứng dụng và triển khai nó trong công ty. Thông thường, những ứng dụng này không bao giờ được quét để phát hiện những lỗ hổng phổ biến nhất theo khuyến nghị của OWASP (Open Web Application Security Project - Dự án bảo mật ứng dụng web mở), hơn nữa vì thường được triển khai mà không cần biết đến SecOps, nên các ứng dụng đó thường không được bảo vệ bởi WAF (Web Application Firewall - Tường lửa ứng dụng web). 

Ngay cả khi được đặt cấu hình "đúng", WAF vẫn có thể vận hành không như kỳ vọng do thiếu kiến thức về các quy tắc WAF và sự thay đổi liên tục từ phía ứng dụng Các đội ngũ SecOps và CNTT cần xem xét kỹ hơn việc bảo mật ứng dụng web, NHƯNG cần làm sao để không ảnh hưởng tới năng lực sáng tạo và tăng trưởng. Các nhóm bảo mật cần đặt ra các chính sách WAF dễ hiểu cho các ứng dụng web, sau đó giám sát thường xuyên các WAF này để đảm bảo đặt đúng cấu hình cho các quy tắc đó.

Tìm kiếm lỗi cấu hình

Sai và lỗi cấu hình là điều không mong muốn nhưng luôn có cách giải quyết. Kiểm soát hồ sơ rủi ro là một động thái hiệu quả trong an ninh bảo mật, nhưng trong một số tổ chức cần phải thay đổi tư duy để làm được việc này. Cùng với việc luôn tìm kiếm những công cụ bảo mật mới nhất và tốt nhất để ngăn chặn và phát hiện lỗi, chúng ta còn cần phải tính đến cách kiểm thử hoạt động và sửa chữa những công cụ này khi chúng không vận hành như mong muốn. Điều gì sẽ xảy ra nếu bạn có thể nhìn thấy những rủi ro ẩn trong sai lỗi, lỗi cấu hình và các ngoại lệ trong chính sách bảo mật? 

Để phát hiện và khắc phục những lỗi cấu hình phiền phức, ông Scott Register khuyến nghị các doanh nghiệp cần thực hiện ngay 6 đánh giá nội bộ, bao gồm:

Thứ nhất, lỗi cấu hình giải mã SSL   — Việc giải mã có thể ảnh hưởng đến hiệu năng mạng và ứng dụng của bạn. Hệ thống IPS không có tác dụng khi việc giải mã SSL bị cấu hình sai, nhưng chúng ta thường tắt chức năng SSL để nâng cao hiệu năng hoặc xử lý sự cố. Luôn kiểm thử khi chức năng được bật để bảo đảm hệ thống IPS thực sự có tác dụng.

Thứ hai, hồ sơ bảo vệ mặc định  - Các hồ sơ bảo vệ lỗi thời có thể gây ra vấn đề. Hãy xác nhận các hồ sơ này của bạn nằm ở đâu, thông thường trong trình duyệt web và bảo mật ứng dụng web. Chúng ta thường không nghĩ tới hoặc thay đổi hồ sơ này để nâng cao hiệu năng. Việc không rà soát hồ sơ bảo vệ tạo rủi ro cho các ứng dụng web và hoạt động kinh doanh.

Thứ ba, không hoặc hạn chế phân đoạn đến mức tối thiểu trong vùng an ninh  — Một vấn đề về bảo mật là kiểu tấn công dạng lan truyền ngang (Lateral Movement). Chúng ta thường quên phân đoạn lại các vùng an ninh mạng sau khi tắt tạm thời (để xử lý sự cố hoặc bảo trì). Cần luôn nhớ khôi phục lại các vùng an ninh này để bảo đảm giảm thiểu rủi ro lan truyền ngang.

Thứ tư, bảo vệ chống mất dữ liệu không hiệu quả (DLP)  — Mất dữ liệu nhạy cảm là một vấn đề bảo mật nghiêm trọng. Nguyên nhân thông thường là do kiến thức về hành vi vận hành của DLP và vị trí để lập cấu hình DLP. Cần phải thiết lập cấu hình đúng cho NGFW/DLP để bảo đảm rằng nhân viên (hay những người khác) không thể vô tình hay hữu ý tải dữ liệu nhạy cảm ra ngoài.

Thứ năm, bảo vệ không hiệu quả các quy tắc WAF trên đám mây  — Một đám mây điện toán bị thủng hoặc rò rỉ có thể tạo ra các điểm yếu. Các quy tắc WAF, giống như NGFW, có thể khá phức tạp và luôn thay đổi. Hãy kiểm thử WAF của bạn trước những cuộc tấn công ứng dụng web mới nhất để có định hướng rõ ràng cho việc thiết lập và tinh chỉnh các quy tắc nhằm ngăn chặn những kẻ tấn công.

Thứ sáu, lỗi cấu hình chính sách lọc URL  — Thực hiện tìm kiếm trên web có thể dễ gây rủi ro cho nhân viên làm việc từ xa, ngay cả khi sử dụng VPN. Các chính sách lọc URL thường được cấu hình lại trong quá trình di chuyển văn phòng hoặc khi cho phép nhân viên làm việc từ xa và qua VPN. Hãy kiểm thử xem bạn đã có các quy tắc lọc hay chưa, thậm chí qua VPN, để giúp nhân viên tránh làm lây lan các cuộc tấn công “quảng cáo độc hại” hoặc phần mềm độc hại.

Phương Dung

DMA sẽ buộc Apple phải cho phép người dùng tải ứng dụng từ chợ bên thứ ba, thay vì chỉ từ App Store như bình thường (sideload). Ngoài ra, các ứng dụng bên thứ ba cũng được phép dùng các nền tảng thanh toán bên thứ ba cho mua sắm trong ứng dụng.

Theo Bloomberg, nhà sản xuất iPhone đã chuẩn bị cho ngày này từ năm 2023 và dự kiến triển khai trong vài tuần tới. Hạn chót để các công ty chấp hành quy định là ngày 7/3. Năm ngoái, Phó chủ tịch phần mềm Craig Federighi thừa nhận Apple phải tuân thủ quy định của EU.

Tuy nhiên, thay đổi không áp dụng cho mọi người dùng iPhone, iPad vì chỉ diễn ra ở châu Âu.

Điều đó đồng nghĩa Apple sẽ chia App Store thành hai phiên bản, một dành cho các nước thành viên EU và một dành cho phần còn lại của thế giới. Dường như điều này nhằm giúp Apple chấp hành quy định của EU dễ hơn mà không ảnh hưởng đến các thị trường khác.

Năm 2023, blog 9to5mac đưa tin iOS 16.2 giới thiệu hệ thống nội bộ mới, giúp Apple hạn chế các tính năng hệ thống dựa trên vị trí của người dùng. Hệ thống này có thể được sử dụng để đảm bảo chỉ người dùng tại EU có thể tải ứng dụng từ chợ bên thứ ba lên thiết bị của họ. Nếu được yêu cầu, Apple có thể “bật công tắc” này để kích hoạt sideload tại nhiều nước khác.

Theo Nikkie, Nhật Bản cũng đang chuẩn bị quy định chống độc quyền buộc Apple cho phép sideload trong iOS. Dự luật dự kiến đệ trình lên Quốc hội trong năm nay và tập trung vào 4 lĩnh vực: chợ ứng dụng và thanh toán, tìm kiếm, trình duyệt, hệ điều hành. Nếu được chấp thuận, Ủy ban Thương mại Công bằng Nhật Bản sẽ có thể phạt tiền đối với các công ty vi phạm luật mới.

Năm 2020, chính phủ Nhật Bản bắt đầu điều tra Google, Apple, Amazon và Facebook vì những lo ngại liên quan đến chống độc quyền. Cùng năm này, nhiều nhà phát triển Nhật Bản bày tỏ không hài lòng với mô hình kinh doanh của App Store. Năm 2023, cơ quan quản lý Nhật Bản đã hoàn thành nghiên cứu và kết luận rằng thị trường ứng dụng di động đang bị Apple và Google chi phối.

Bên cạnh đó, Bộ Tư pháp Mỹ dường như cũng đã sẵn sàng buộc Apple cho phép sideload ứng dụng trên iPhone, iPad.

(Theo 9to5mac)