3.4. Nguyên tắc, Kiểm soát và Chiến lược Bảo mật

Đơn vị học tập này bao gồm các Mục tiêu sau:

• Hiểu được tầm quan trọng của nhiều lớp phòng thủ trong chiến lược an ninh
• Mô tả thông tin tình báo về mối đe dọa và các ứng dụng của chúng trong một tổ chức
• Tìm hiểu lý do tại sao quyền truy cập và quyền của người dùng nên bị hạn chế càng nhiều càng tốt
• Hiểu tại sao bảo mật không nên phụ thuộc vào tính bí mật
• Xác định các chính sách có thể giảm thiểu các mối đe dọa đối với một tổ chức
• Hiểu các mô hình bảo mật khác nhau
• Xác định các biện pháp kiểm soát mà tổ chức có thể sử dụng để giảm thiểu các mối đe dọa an ninh mạng

3.4.1. Nguyên tắc bảo mật

Trong Đơn vị học tập này, chúng ta sẽ bắt đầu khám phá một số điều có thể gặp trong suốt Hành trình học tập chuẩn bị cho các bài thivề Kiểm thử bảo mật như CEH Master, OSCP, CPENT / LPT ....

Hai nguồn tài nguyên tuyệt vời về nguyên tắc bảo mật là trang web của David Wheeler và bảng hướng dẫn OWASP .

Mặc dù chủ đề này có thể là một Mô-đun chuyên sâu riêng, nhưng hiện tại, chúng ta sẽ đề cập đến một số mô tả cấp cao.

Nguyên tắc đặc quyền tối thiểu thể hiện ý tưởng rằng mỗi phần trong hệ thống chỉ nên được cấp các đặc quyền thấp nhất có thể cần thiết để hoàn thành nhiệm vụ của mình. Cho dù là đề cập đến người dùng trên máy hay các dòng mã trong chương trình, việc tuân thủ đúng nguyên tắc này có thể thu hẹp đáng kể bề mặt tấn công.

Trước đó chúng ta đã tham khảo cuộc tấn công Capital One năm 2019. Các bạn hãy nhớ lại rằng cuộc tấn công này được tạo điều kiện thuận lợi bằng cách tận dụng Tường lửa ứng dụng web với các quyền quá cao so với các chức năng bắt buộc của nó. Điều quan trọng là phải hiểu rằng Nguyên tắc đặc quyền tối thiểu không chỉ áp dụng cho cá nhân hoặc nhóm người, mà còn áp dụng cho bất kỳ thực thể nào (bao gồm máy móc, bộ định tuyến và tường lửa) có thể đọc, ghi hoặc sửa đổi dữ liệu.

Mô hình bảo mật Zero Trust áp dụng Nguyên tắc đặc quyền tối thiểu và đưa nó đến kết luận cuối cùng. Mô hình này ủng hộ việc loại bỏ mọi sự tin tưởng ngầm định trong mạng và có mục tiêu bảo vệ quyền truy cập vào tài nguyên, thường là với các quy trình ủy quyền chi tiết cho mọi yêu cầu tài nguyên. Zero Trust bao gồm năm yếu tố chính: Just in Time Access (JITA) , yêu cầu quyền truy cập phải được xác thực ngay trước khi quyền truy cập được cấp; Just Enough Access (JEA) , phù hợp với khái niệm truyền thống về đặc quyền tối thiểu và mã hóa để bảo vệ dữ liệu; chính sách kiểm soát truy cập động (hoặc thích ứng) để đảm bảo rằng chính sách luôn phù hợp với mục đích; và microsegmentation , nhằm giới hạn quyền truy cập ở mức độ phù hợp.

Open Security , một nguyên tắc có phần phản trực giác, nêu rằng tính bảo mật của một hệ thống không nên phụ thuộc vào tính bảo mật của nó . Nói cách khác, ngay cả khi kẻ tấn công biết chính xác cách thức bảo mật của hệ thống được triển khai, kẻ tấn công vẫn phải hay có thể bị ngăn chặn. Điều này không có nghĩa là không có gì là bí mật. Thông tin xác thực là một trường hợp rõ ràng trong đó tính bảo mật của mật khẩu phụ thuộc vào tính bảo mật của nó. Tuy nhiên, chúng ta muốn hệ thống của mình được bảo mật ngay cả khi kẻ tấn công biết có mật khẩu và ngay cả khi chúng biết thuật toán mã hóa đằng sau mật khẩu đó.

Defense in Depth ủng hộ việc thêm các biện pháp phòng thủ vào càng nhiều lớp của hệ thống càng tốt, để nếu một lớp bị bỏ qua, lớp khác vẫn có thể ngăn chặn sự xâm nhập hoàn toàn. Một ví dụ về defense in depth nằm ngoài bối cảnh an ninh mạng là một gara yêu cầu nhập mã điện tử, sử dụng chìa khóa trên ổ khóa cửa chốt, và cuối cùng là vô hiệu hóa hệ thống báo động nội bộ kích hoạt bằng giọng nói để mở gara.

Nhiều tổ chức không áp dụng biện pháp phòng thủ đầy đủ cho hệ thống của họ. Họ dựa quá nhiều vào các công cụ hoặc nhà cung cấp bên ngoài tập trung vào một lĩnh vực phòng thủ cụ thể. Điều này có thể dẫn đến các điểm lỗi đơn lẻ, dẫn đến tư thế bảo mật rất yếu. Chúng ta phải học cách áp dụng nhiều lớp kiểm soát và thiết kế hệ thống của mình với biện pháp phòng thủ chuyên sâu để chống lại nhiều mối đe dọa hơn và phản ứng tốt hơn với các sự cố.

3.4.2. Kiểm soát và Chiến lược Bảo mật

Để đáp ứng các lý tưởng của các khái niệm như đặc quyền tối thiểu, bảo mật mở và phòng thủ chuyên sâu, chúng ta cần triển khai các Chiến lược bảo mật . Những chiến lược này có thể bao gồm các biện pháp can thiệp như:

• Cảnh giác 24/7
• Mô hình hóa mối đe dọa
• Các cuộc thảo luận trên bàn
• Đào tạo liên tục về chiến thuật, quy trình và thủ tục
• Bản vá tự động liên tục
• Xác minh chuỗi cung ứng liên tục
• Mã hóa và thiết kế an toàn
• Đánh giá nhật ký hàng ngày
• Nhiều lớp Kiểm soát bảo mật được triển khai tốt

Lúc đầu, điều này có vẻ quá sức. Đặc biệt, chiến lược phòng thủ theo chiều sâu liên quan đến con người và công nghệ tạo ra nhiều lớp rào cản để bảo vệ tài nguyên.

Trong CIA Triad Learning Unit, chúng ta đã đề cập rằng hậu quả của bảo mật mạnh có thể là giảm khả năng sử dụng. Nếu bảo mật của hệ thống được ưu tiên hơn khả năng sử dụng, thì có thể có thời gian chết tăng lên và cuối cùng là tăng sự thất vọng của người dùng. Một ví dụ về điều này có thể là sử dụng giao thức xác thực Kerberos mà không có phương pháp xác thực dự phòng. Trong GNU/Linux, Kerberos có thể được cấu hình mà không có biện pháp an toàn, không có phương pháp ủy quyền truy cập mạng thay thế. Điều này có thể dẫn đến việc không ai có thể truy cập các dịch vụ mạng nếu có sự cố Kerberos. Nếu bảo mật là ưu tiên hàng đầu, thì điều này có thể lý tưởng tùy thuộc vào mục tiêu của tổ chức . Tuy nhiên, nếu khả năng sử dụng là ưu tiên hàng đầu, thì cách tiếp cận như vậy có thể gây hại cho hệ thống bằng cách cải thiện bảo mật của hệ thống mà không cần quan tâm.

Kiểm soát an ninh cũng có thể cực kỳ tốn thời gian để sử dụng và duy trì đúng cách. Nếu một biện pháp kiểm soát đủ tốn kém, một tổ chức có thể mất lợi nhuận. Kiểm soát an ninh cũng phải cân bằng với nguồn lực tài chính và hạn chế về nhân sự.

Tiếp theo, chúng ta hãy cùng khám phá nhiều biện pháp kiểm soát bảo mật khác nhau mà một tổ chức có thể triển khai.

3.4.3. Mô hình bảo mật

Mô hình bảo mật là một loại lược đồ được sử dụng để triển khai các biện pháp kiểm soát bảo mật trong hệ thống thông tin. Chúng hiếm khi chỉ định các biện pháp kiểm soát cụ thể nhưng chúng trình bày một khuôn khổ lý thuyết và, trong một số trường hợp, một tập hợp các quy tắc có thể được triển khai trong một số bối cảnh khác nhau.

Nhiều mô hình nổi tiếng nhất nhắm vào kiểm soát truy cập. Chúng tôi sẽ tập trung vào các ví dụ về những điều này trong phần này. Một số trong số này tập trung cụ thể vào tính bảo mật hoặc tính toàn vẹn, một số khác thì tổng quát hơn.

Trước tiên, hãy xem xét một mô hình bảo mật chủ yếu liên quan đến tính bảo mật . Mô hình Bell–LaPadula được sử dụng để thực thi kiểm soát truy cập trong các hệ thống có nhiều cấp độ bảo mật (ví dụ: không được phân loại, bảo mật, bí mật và tuyệt mật). Mô hình này thường được sử dụng trong bối cảnh chính phủ hoặc quân đội để xác định ai có thể truy cập vào những đối tượng nào ở các cấp độ bảo mật khác nhau. Trong mô hình này, cá nhân không thể đọc nội dung có cấp độ bảo mật cao hơn cấp độ bảo mật của họ (được gọi là Thuộc tính bảo mật đơn giản ) hoặc viết nội dung có cấp độ bảo mật thấp hơn cấp độ bảo mật của họ (được gọi là Thuộc tính bảo mật sao ). Trong một số bối cảnh nhất định, họ có thể không được phép đọc hoặc viết ở cấp độ khác ngoài cấp độ của họ (được gọi là Thuộc tính bảo mật tùy ý ).

Tương tự như vậy, mô hình Brewer và Nash được sử dụng để thực thi kiểm soát truy cập nhằm duy trì tính bảo mật, nhưng với mục đích cụ thể là giảm thiểu xung đột lợi ích. Điều này có thể được sử dụng bởi các tổ chức kế toán hoặc tư vấn. Mô hình sử dụng phân tách dữ liệu và kiểm soát truy cập động. Kiểm soát truy cập động có thể hoạt động bằng cách từ chối quyền truy cập của một số cá nhân dựa trên thông tin khác mà họ đã xem hoặc có quyền truy cập. Ví dụ, một tổ chức làm việc với những khách hàng cạnh tranh với nhau có thể tạm thời hạn chế một cá nhân truy cập dữ liệu của công ty sau khi họ đã truy cập dữ liệu thuộc về đối thủ cạnh tranh của họ.

Tiếp theo, hãy xem xét một số mô hình bảo mật chủ yếu liên quan đến tính toàn vẹn . Mô hình Biba cũng được sử dụng để thực thi kiểm soát truy cập và được thiết kế để bảo vệ tính toàn vẹn của thông tin trong đó các cá nhân và thông tin được chỉ định các mức toàn vẹn khác nhau. Trong mô hình này, các cá nhân không thể đọc dữ liệu có mức toàn vẹn thấp hơn mức toàn vẹn của họ (được gọi là Thuộc tính toàn vẹn đơn giản ) hoặc viết nội dung có mức toàn vẹn cao hơn mức toàn vẹn của họ (được gọi là Thuộc tính toàn vẹn sao ). Một quy tắc khác nêu rằng các cá nhân không thể yêu cầu truy cập thông tin có mức toàn vẹn cao hơn mức toàn vẹn của họ (được gọi là Thuộc tính triệu hồi ).

Mô hình Clark-Wilson là một mô-đun khác được sử dụng để bảo vệ tính toàn vẹn của dữ liệu. Điều này được triển khai thông qua bộ ba kiểm soát truy cập , bao gồm một chủ thể , chương trình (còn được gọi là giao dịch ) và đối tượng . Theo mô hình này, các chủ thể riêng lẻ không có quyền truy cập trực tiếp vào các đối tượng dữ liệu mà chỉ có thể truy cập và sửa đổi chúng thông qua một loạt các chương trình , bản thân chúng hoạt động trên các đối tượng dữ liệu và thực thi các chính sách toàn vẹn.

Các mô-đun bảo mật kiểm soát truy cập khác tập trung vào kiểm soát truy cập nói chung hơn. Một ví dụ về điều này là Kiểm soát truy cập dựa trên vai trò (RBAC). Mô hình bảo mật này, được sử dụng rộng rãi trong điện toán đám mây Quản lý danh tính và truy cập (IAM), cấp quyền cho các vai trò, sau đó được áp dụng cho từng người dùng. Thay vì cấp quyền trực tiếp cho từng người dùng, quyền được cấp cho người dùng dựa trên các vai trò mà họ có.

Một biến thể khác là Kiểm soát truy cập dựa trên thuộc tính (ABAC). Mô hình bảo mật này dựa trên một loạt các thuộc tính được áp dụng cho người dùng và đối tượng, và các quy tắc sử dụng các thuộc tính này để xác định người dùng nào có thể thực hiện loại truy cập nào trên đối tượng nào. ABAC có lợi thế là cung cấp kiểm soát truy cập chi tiết hơn và năng động hơn.

Đây chỉ là một số ít mô hình bảo mật nhưng chúng cung cấp cho chúng ta ý tưởng chung về mô hình bảo mật là gì, mục tiêu cụ thể của các mô hình, nơi chúng có thể được sử dụng và mức độ thông số kỹ thuật mà chúng liên quan.

3.4.4. Bảo mật Shift-Left

Một trong những cách tốt nhất để tránh chi phí phát sinh và tác động đến tính khả dụng là thiết kế toàn bộ hệ thống sao cho bảo mật được tích hợp vào kiến ​​trúc dịch vụ, thay vì yêu cầu nhiều lớp phần mềm bổ sung. Để thiết kế hệ thống có bảo mật tích hợp, ý tưởng về bảo mật shift-left có thể cải thiện hiệu quả. Ý tưởng về bảo mật shift-left là xem xét kỹ thuật bảo mật ngay từ đầu khi thiết kế sản phẩm hoặc hệ thống, thay vì cố gắng đưa nó vào sau khi sản phẩm đã được xây dựng.

Nếu không có bảo mật shift-left, chúng ta có thể có các nhà phát triển vận chuyển sản phẩm mà không có bảo mật, sau đó cần thêm các lớp bảo mật bổ sung trên đầu hoặc cùng với sản phẩm. Nếu nhóm bảo mật tham gia vào quá trình phát triển, chúng ta có nhiều cơ hội hơn để tạo ra một sản phẩm có các biện pháp kiểm soát được tích hợp sẵn, tạo ra trải nghiệm người dùng liền mạch hơn cũng như giảm nhu cầu về các dịch vụ bảo mật bổ sung.

Hầu hết các ứng dụng không có bảo mật tích hợp sẵn mà thay vào đó dựa vào các biện pháp kiểm soát bảo mật cấp nền tảng xung quanh các dịch vụ. Điều này có thể hiệu quả; tuy nhiên, nó có thể khiến bảo mật yếu hơn hoặc dễ bị bỏ qua hơn. Ví dụ: nếu một công nghệ cụ thể (ví dụ: mô-đun Kubernetes) cung cấp tất cả các dịch vụ bảo mật, thì người kiểm soát công nghệ đó (trong trường hợp này là quản trị viên Kubernetes) có thể xóa hoặc can thiệp vào công nghệ đó và bỏ qua bảo mật cho tất cả các dịch vụ.

Tuy nhiên, một lần nữa chúng ta cần xem xét tác động kinh doanh. Cụ thể, việc dịch chuyển sang trái có khả năng khiến thời gian sản xuất chậm hơn vì các nhà phát triển sẽ cần phải suy nghĩ rõ ràng về bảo mật ngoài các thông số kỹ thuật của sản phẩm. Do đó, một tổ chức sẽ cần phải quyết định những sự đánh đổi nào họ có thể thực hiện trong hoàn cảnh cụ thể của mình. Mặc dù có khả năng làm giảm tư thế bảo mật, nhưng việc tập trung vào các biện pháp kiểm soát bảo mật ở cấp độ nền tảng có thể mang lại ma sát thấp nhất cho các nỗ lực phát triển và thời gian đưa ra thị trường nhanh nhất cho các nhà phát triển ứng dụng trong khi vẫn tạo ra tư thế bảo mật hợp lý.

3.4.5. Phân đoạn hành chính

Có vẻ ổn khi để một quản trị viên bỏ qua các biện pháp kiểm soát bảo mật dựa trên vai trò và nhu cầu chức năng của họ. Chúng ta không nên tin tưởng vào các quản trị viên của mình sao? Tuy nhiên, khi một mối đe dọa là nội bộ hoặc có thể có được thông tin xác thực quản trị hợp lệ, thì thế trận bảo mật của chúng ta trở nên yếu hơn. Để đánh bại các mối đe dọa nội bộ và các mối đe dọa đã có được thông tin xác thực hoặc khả năng xác thực hợp lệ, chúng ta phải phân đoạn các biện pháp kiểm soát để không có một thẩm quyền nào có thể bỏ qua tất cả các biện pháp kiểm soát. Để thực hiện được điều này, chúng ta có thể cần phân chia các biện pháp kiểm soát giữa các nhóm ứng dụng và quản trị viên hoặc phân chia quyền truy cập để quản trị giữa nhiều quản trị viên, như với Shamir's Secret Sharing (SSS).

Với SSS, chúng ta có thể thiết kế một hệ thống sao cho cần có ba quyền quản trị viên khác nhau để cấp quyền cho bất kỳ quyền truy cập gốc quản trị nào. Sơ đồ chia sẻ bí mật của Shamir cho phép một hệ thống chia nhỏ các yêu cầu cấp quyền truy cập giữa nhiều hệ thống hoặc nhiều người. Với điều này, chúng ta có thể thiết kế một hệ thống sao cho không một người nào có thông tin xác thực gốc.

3.4.6. Mô hình hóa mối đe dọa và tình báo mối đe dọa

Trước khi nghiên cứu các mối đe dọa tiềm ẩn đối với một tổ chức, điều quan trọng đối với một tổ chức là phải có một bản kiểm kê chi tiết về tài sản của mình. Sẽ không có ý nghĩa gì khi dành thời gian và năng lượng để xác định các mối đe dọa tiềm ẩn đối với các thiết bị Cisco khi một tổ chức chỉ sử dụng các thiết bị Juniper . Sau khi chúng tôi hoàn thành bản kiểm kê cho cả hệ thống và phần mềm và chúng tôi hiểu các yêu cầu của tổ chức mình, chúng tôi đã sẵn sàng bắt đầu nghiên cứu các mối đe dọa tiềm ẩn. Các nhóm bảo mật nghiên cứu (hoặc tận dụng nghiên cứu của nhà cung cấp về) các mối đe dọa đối với các ngành công nghiệp và phần mềm khác nhau.

Chúng ta có thể sử dụng thông tin này trong Mô hình hóa mối đe dọa của mình . Mô hình hóa mối đe dọa liên quan đến việc lấy dữ liệu từ các đối thủ trong thế giới thực và đánh giá các kiểu tấn công và kỹ thuật đó đối với con người, quy trình, hệ thống và phần mềm của chúng ta. Điều quan trọng là phải xem xét cách thức xâm phạm một hệ thống trong mạng của chúng ta có thể ảnh hưởng đến các hệ thống khác.

Threat Intelligence là dữ liệu đã được tinh chỉnh trong bối cảnh của tổ chức: thông tin có thể hành động mà một tổ chức đã thu thập thông qua mô hình hóa mối đe dọa về mối đe dọa hợp lệ đối với sự thành công của tổ chức đó. Thông tin không được coi là thông tin tình báo về mối đe dọa trừ khi nó dẫn đến một mục hành động cho tổ chức. Sự tồn tại của một khai thác không phải là thông tin tình báo về mối đe dọa; tuy nhiên, đó là thông tin có khả năng hữu ích có thể dẫn đến thông tin tình báo về mối đe dọa.

Một ví dụ về tình báo đe dọa xảy ra khi các mẫu tấn công của đối thủ có liên quan được học và các mẫu tấn công đó có thể đánh bại các biện pháp kiểm soát hiện tại trong tổ chức và khi đối thủ đó là mối đe dọa tiềm tàng đối với tổ chức. Sự khác biệt giữa thông tin bảo mật và tình báo đe dọa thường là thông tin bảo mật chỉ được nghiên cứu ngoài bối cảnh của tổ chức cụ thể. Khi tình báo đe dọa thực sự được thu thập, một tổ chức có thể thực hiện hành động sáng suốt để cải thiện các quy trình, thủ tục, chiến thuật và biện pháp kiểm soát của mình.

3.4.7. Chiến thuật trên bàn

Sau khi nhận được thông tin tình báo về mối đe dọa hoặc thông tin quan trọng khác, các doanh nghiệp có thể được hưởng lợi từ việc lập lịch thảo luận liên tổ chức ngay lập tức . Một loại thảo luận được gọi là thảo luận nhóm , tập hợp các kỹ sư, bên liên quan và chuyên gia bảo mật để thảo luận về cách tổ chức có thể phản ứng với các loại thảm họa và tấn công khác nhau. Tiến hành các cuộc thảo luận nhóm thường xuyên này để đánh giá các hệ thống và môi trường khác nhau là một cách tuyệt vời để đảm bảo rằng tất cả các nhóm đều biết Chiến thuật, Kỹ thuật và Quy trình (TTP) để xử lý các tình huống khác nhau. Các tổ chức thường không xây dựng các TTP phù hợp, dẫn đến thời gian phản hồi sự cố lâu hơn.

Các cuộc thảo luận trên bàn giúp các tổ chức nâng cao nhận thức giữa các nhóm. Điều này giúp các nhóm hiểu được điểm yếu và lỗ hổng trong các biện pháp kiểm soát để họ có thể lập kế hoạch tốt hơn cho các tình huống khác nhau trong chiến thuật, quy trình và thiết kế hệ thống của mình. Việc có các kỹ sư và chuyên gia tham gia vào các cuộc thảo luận trên bàn có thể giúp các nhóm khác tìm ra giải pháp cho các vấn đề bảo mật hoặc ngược lại.

Hãy tưởng tượng một kịch bản trong đó chúng ta biết rằng một cuộc tấn công email lừa đảo vào một quản trị viên sẽ đại diện cho một sự xâm phạm toàn diện của công ty. Để xây dựng các biện pháp kiểm soát phòng thủ của mình, chúng ta có thể quyết định tạo một cổng truy cập email cho các quản trị viên được cô lập về mặt vật lý. Khi các quản trị viên xem email của họ, họ sẽ thực hiện việc này thông qua một màn hình hiển thị chế độ xem của khách hàng vào một hộp cát email được bảo mật nghiêm ngặt. Theo cách này, các email được mở bên trong một máy được bảo vệ bằng hộp cát trên phần cứng riêng biệt, thay vì trên các máy trạm quản trị có quyền truy cập sản xuất.

Các phiên họp bảo mật theo nhóm là một phần của Kế hoạch duy trì hoạt động kinh doanh (BCP). BCP cũng bao gồm nhiều khía cạnh khác như phản ứng diễn tập trực tiếp đối với các tình huống như phần mềm tống tiền và xâm phạm chuỗi cung ứng. BCP mở rộng ra ngoài các trường hợp khẩn cấp về an ninh mạng để bao gồm các quy trình và thủ tục đối với thảm họa thiên nhiên và bạo lực súng đạn. Các phiên họp theo nhóm thường lệ và việc thu thập liên tục thông tin tình báo có liên quan cung cấp nỗ lực chủ động để giảm thiểu các vấn đề trong tương lai cũng như diễn tập các chiến thuật, quy trình và thủ tục.

3.4.8. Vá lỗi liên tục và xác thực chuỗi cung ứng

Một kỹ thuật phòng thủ khác được gọi là vá lỗi tự động liên tục được thực hiện bằng cách kéo mã nguồn thượng nguồn và áp dụng nó vào môi trường phát triển thấp nhất. Tiếp theo, thay đổi được kiểm tra và chỉ chuyển sang sản xuất nếu thành công. Chúng ta có thể tận dụng cơ sở hạ tầng của nhà cung cấp đám mây để tạo ra các bản sao hoàn chỉnh của môi trường để kiểm tra những thay đổi này. Thay vì liên tục chạy một môi trường kiểm tra bản vá đầy đủ, chúng ta có thể tạo một môi trường tương đối dễ dàng bằng cách sử dụng nhà cung cấp đám mây của mình, chạy các bài kiểm tra có liên quan, sau đó xóa nó. Rủi ro chính của cách tiếp cận này là sự xâm phạm chuỗi cung ứng.

Xác thực chuỗi cung ứng liên tục xảy ra bởi cả nhà cung cấp và người tiêu dùng. Nó xảy ra khi mọi người và hệ thống xác thực rằng phần mềm và phần cứng nhận được từ nhà cung cấp là vật liệu mong đợi và không bị can thiệp. Đối với nhà cung cấp, nó đảm bảo rằng phần mềm và vật liệu được gửi đi có thể được khách hàng và đối tác kinh doanh xác minh.

Xác thực chuỗi cung ứng liên tục rất khó và đôi khi đòi hỏi nhiều hơn các kiểm tra phần mềm, chẳng hạn như kiểm tra thực tế các thiết bị đã đặt hàng. Về mặt phần mềm của bảo mật chuỗi cung ứng, chúng ta có thể sử dụng các kỹ thuật kiểm tra và thử nghiệm sâu hơn để đánh giá dữ liệu thượng nguồn chặt chẽ hơn. Chúng ta có thể lựa chọn tăng thời gian kiểm tra bảo mật để cố gắng phát hiện phần mềm độc hại ẩn được cấy vào các nguồn thượng nguồn. Phần mềm độc hại ẩn là phần mềm không hoạt động trong khi ở trên hệ thống trong một khoảng thời gian, có thể là nhiều tuần trước khi bắt đầu hành động.

Sử dụng danh mục vật liệu phần mềm (SBOM) như một cách để theo dõi các phụ thuộc tự động trong quá trình xây dựng ứng dụng giúp chúng ta đánh giá rất nhiều về sự can thiệp vào chuỗi cung ứng. Nếu chúng ta xác định các phụ thuộc phần mềm, tạo SBOM với chúng và đóng gói container và SBOM lại với nhau theo cách có thể xác minh bằng mật mã, thì chúng ta có thể xác minh chữ ký SBOM của container trước khi tải nó vào sản xuất. Loại quy trình này đặt ra thêm nhiều thách thức cho đối thủ.

3.4.9. Sao lưu

Sao lưu là bản sao dữ liệu được tạo tại một thời điểm nhất định. Sao lưu cho phép chúng ta khôi phục dữ liệu nếu dữ liệu đã bị xóa hoặc bị hỏng. Dữ liệu có thể bị xóa hoặc bị hỏng theo nhiều cách khác nhau, ví dụ, do bị tấn công (phần mềm tống tiền, phần mềm độc hại xóa dữ liệu, v.v.), do lỗi của con người hoặc do thiên tai (sốc điện, hỏa hoạn, v.v.), trong số những khả năng khác.

Ví dụ các bạn có thể sao lưu với hệ thống One Drive của Security365 (các bạn khi đăng kí sách này sẽ được tặng kèm 1 tài khoản Security365 để truy cập vào thư viện chứa video và các tài liệu cần thiết)

Vì bản sao lưu là bản sao dữ liệu tại một thời điểm cụ thể, nên việc khôi phục dữ liệu bằng bản sao lưu chỉ trả dữ liệu về trạng thái khi bản sao lưu được thực hiện. Nếu dữ liệu đó không thay đổi theo thời gian, điều này cho phép chúng tôi đảm bảo tính khả dụng và tính toàn vẹn của dữ liệu. Nếu dữ liệu thay đổi theo thời gian, việc khôi phục cho phép chúng tôi giảm thiểu mất dữ liệu.

Trong trường hợp thứ hai, việc sao lưu thường xuyên là một phần quan trọng của việc quản lý dữ liệu vì nó làm giảm sự khác biệt giữa trạng thái sao lưu và trạng thái của dữ liệu khi sự cố xảy ra, từ đó giúp giảm thiểu tình trạng mất dữ liệu.

Có một số loại sao lưu khác nhau: sao lưu đầy đủ, sao lưu gia tăng và sao lưu khác biệt. Sao lưu đầy đủ là sao chép toàn bộ dữ liệu. Đây là giải pháp đơn giản nhất và dễ khôi phục vì chúng ta chỉ cần khôi phục toàn bộ bản sao lưu. Nhược điểm là sao chép lượng dữ liệu lớn có thể chậm. Hơn nữa, việc lưu trữ nhiều bản sao khác nhau có thể tốn kém, điều mà chúng ta có thể muốn làm nếu muốn giữ lại các phiên bản khác nhau của dữ liệu.

Sao lưu gia tăng sao chép các tệp đã thay đổi kể từ lần sao lưu cuối cùng, có thể là bản sao lưu đầy đủ hoặc bản sao lưu gia tăng khác. Điều này làm giảm lượng dữ liệu được sao lưu, thời gian cần thiết để sao chép dữ liệu và không gian cần thiết để lưu trữ dữ liệu. Tuy nhiên, điều này làm cho việc khôi phục phức tạp hơn một chút vì phiên bản dữ liệu gần đây nhất phải được xây dựng lại từ nhiều bản sao lưu khác nhau.

Sao lưu khác biệt sao chép các tệp đã thay đổi kể từ lần sao lưu đầy đủ cuối cùng. Điều này tương tự như sao lưu gia tăng ngoại trừ việc nó không tính đến các bản sao lưu gia tăng trước đó khi xác định tệp nào đã thay đổi. Vì lý do này, thời gian và không gian lưu trữ cần thiết cho sao lưu khác biệt ít hơn sao lưu đầy đủ nhưng nhiều hơn sao lưu gia tăng. Mặt khác, phục hồi từ sao lưu khác biệt phức tạp hơn phục hồi từ sao lưu đầy đủ nhưng ít phức tạp hơn phục hồi từ sao lưu gia tăng.

Bảng sau đây tóm tắt các loại sao lưu này.

Kiểu	Sao lưu	Hỗ trợ	Sự hồi phục	Trị giá
Đầy	tất cả các tập tin	chậm nhất	đơn giản	đắt nhất
Chênh lệch	tập tin đã thay đổi kể từ lần sao lưu đầy đủ cuối cùng	nhanh hơn	phức tạp hơn	ít tốn kém hơn
Tăng dần	các tập tin đã thay đổi kể từ lần sao lưu đầy đủ hoặc gia tăng cuối cùng	nhanh nhất	phức tạp nhất	rẻ nhất

Bảng 1 - So sánh các loại sao lưu

Luôn là một ý tưởng hay khi kiểm tra quy trình sao lưu và khôi phục theo lịch trình trước khi xảy ra sự cố như một phần của quy trình phục hồi thảm họa để đảm bảo chúng hoạt động như mong đợi.

Có hai loại sao lưu khác liên quan đến trạng thái của hệ thống khi sao lưu được thực hiện: nóng và lạnh. Sao lưu nóng được lấy từ một hệ thống đang chạy, trực tuyến. Chúng ta có thể tạo các bản sao lưu này mà không cần tắt hệ thống hoặc dịch vụ. Bản sao lưu có thể được lưu trữ trên cùng một máy tính với các tệp gốc hoặc trên một máy tính được chỉ định khác. Sao lưu nóng có thể được thực hiện định kỳ, theo lịch trình hoặc được kích hoạt bởi các thay đổi hoặc điều kiện cụ thể. Dù bằng cách nào, điều này cũng tạo ra bản sao lưu trạng thái hiện tại của hệ thống hoặc các tệp.

Ngược lại, sao lưu lạnh được thực hiện khi hệ thống hoặc dịch vụ ngoại tuyến. Sao lưu lạnh an toàn hơn về mặt tính nhất quán của dữ liệu nhưng yêu cầu thời gian ngừng hoạt động của hệ thống, đây có thể là một nhược điểm đáng kể đối với các hệ thống yêu cầu khả dụng toàn thời gian.

Bản sao lưu có thể được lưu trữ ở một số nơi khác nhau. Ví dụ, chúng có thể được lưu trữ trên máy nguồn, trên máy khác hoặc trên một số loại phương tiện bên ngoài như ổ cứng ngoài, DVD, ổ đĩa flash USB, băng từ hoặc thiết bị lưu trữ khác.

Sau khi tạo bản sao lưu, chúng ta có thể tách phương tiện sao lưu và lưu trữ ngoại tuyến . Điều này gây ra những thách thức về mặt hậu cần rõ ràng cũng như đầu tư đáng kể về thời gian và chi phí vì chúng ta phải mua phương tiện bên ngoài và quản lý phương tiện đó về mặt vật lý. Tuy nhiên, điều này bảo vệ các bản sao lưu khỏi các mối đe dọa trực tuyến, mặc dù chúng vẫn có nguy cơ bị đe dọa về mặt vật lý. Nếu kẻ thù đánh cắp được bản sao lưu vật lý, rõ ràng chúng có thể lợi dụng điều đó như một phần của kế hoạch tống tiền. Để chống lại điều này, chúng ta có thể sử dụng các dịch vụ sao lưu ký quỹ trong đó chúng ta vận chuyển các bản sao lưu vật lý cho bên thứ ba, bên này sẽ khóa bản sao lưu ở một vị trí an toàn. Điều này cung cấp sự dự phòng, tách biệt và đảm bảo hơn nữa rằng chúng ta sẽ có thể bảo vệ và khôi phục dữ liệu đó.

Ngược lại với lưu trữ sao lưu ngoại tuyến, các giải pháp lưu trữ trực tuyến cung cấp sự tiện lợi, cho phép chúng ta lưu trữ dữ liệu trên các máy chủ chuyên dụng và khôi phục nhanh chóng trong trường hợp mất dữ liệu. Tuy nhiên, các bản sao lưu trực tuyến dễ bị xóa hoặc thay đổi bởi đối thủ.

Chúng ta có thể bù đắp điều này bằng cách tạo các bản sao lưu được bảo vệ, chỉ đọc, chống xóa và sửa đổi. Để tạo các bản sao lưu nóng được bảo vệ, chúng ta cần xóa quyền truy cập của riêng mình vào một số chức năng nhất định, thêm các lớp bảo mật như MFA hoặc thêm xác thực nhiều người dùng. Ngay cả khi áp dụng các biện pháp này, chúng ta vẫn có nguy cơ bị khai thác không lường trước hoặc các chiến thuật kỹ thuật xã hội mà kẻ thù có thể sử dụng để xóa các bản sao lưu trước khi kích hoạt phần mềm tống tiền.

Mặc dù có thể khó để thiết kế giải pháp sao lưu nóng được bảo vệ của riêng mình, nhưng có nhiều giải pháp của bên thứ ba bao gồm giải pháp do Veeam cung cấp , cung cấp các tính năng sao lưu và sao chép toàn diện và Acronis , nổi tiếng với các dịch vụ sao lưu đám mây và bảo vệ an ninh mạng.

Một phương pháp kết hợp sử dụng sao lưu dự phòng là phương pháp an toàn nhất. Chúng ta có thể kết hợp các chiến lược sao lưu nóng và lạnh, cũng như các giải pháp lưu trữ trực tuyến và ngoại tuyến. Chúng ta nên cân nhắc một chiến lược hợp lý nhất với nhu cầu kinh doanh và mức độ rủi ro được chấp nhận của mình.

Cụ thể, chúng ta nên tập trung vào dự phòng. Chúng ta nên áp dụng một số kỹ thuật sao lưu khác nhau để nếu một hệ thống sao lưu bị lỗi, chúng ta có một hệ thống khác để sử dụng. Điều này tạo ra khả năng phòng thủ chuyên sâu , một chiến lược bao gồm nhiều lớp kiểm soát và biện pháp bảo mật để bảo vệ chống lại nhiều mối đe dọa khác nhau. Ý tưởng là không có biện pháp bảo mật nào là hoàn hảo, vì vậy nhiều lớp phòng thủ có thể giúp giảm thiểu rủi ro của một cuộc tấn công.

Sao lưu cũng phải được lưu trữ an toàn. Một trong những cách chúng ta có thể làm là mã hóa chúng. Chúng ta sẽ thảo luận về mã hóa trong phần tiếp theo.

3.4.10. Mã hóa

Ngoài phần mềm theo dõi, nhiều tổ chức có thể muốn tận dụng mã hóa . Mã hóa thường bảo vệ chúng ta khỏi kẻ thù nhiều hơn bất kỳ loại kiểm soát nào khác. Mặc dù sử dụng mã hóa không giải quyết được mọi vấn đề, nhưng mã hóa tích hợp tốt ở nhiều lớp kiểm soát sẽ tạo ra thế trận bảo mật mạnh mẽ hơn.

Ghi nhớ điều này, có một số cảnh báo cần cân nhắc khi nói đến mã hóa. Mã hóa tất cả dữ liệu của chúng ta sẽ không hữu ích nếu chúng ta không thể giải mã và khôi phục khi cần. Chúng ta cũng phải cân nhắc một số loại dữ liệu mà chúng ta không muốn giải mã vì thông tin chỉ được sử dụng tạm thời. Một ví dụ về mã hóa tạm thời là TLS . Ở đây, chỉ máy chủ và máy khách của tương tác cụ thể đó mới có thể giải mã thông tin (kể cả quản trị viên). Trên hết, khóa giải mã chỉ tồn tại trong bộ nhớ trong một thời gian ngắn trước khi bị loại bỏ.

Khóa giải mã trong trường hợp như vậy không bao giờ nằm ​​trên đĩa và không bao giờ được gửi qua mạng. Loại quyền riêng tư này thường được sử dụng khi gửi bí mật hoặc Thông tin nhận dạng cá nhân (PII) qua đường truyền. Bất kỳ dữ liệu theo dõi và kiểm tra nào được yêu cầu đều có thể được xuất ra từ các ứng dụng thay vì bị chặn và các bí mật và PII có thể bị loại trừ, mã hóa hoặc xóa. PII có thể bao gồm tên, địa chỉ, số điện thoại, địa chỉ email, SSN và các thông tin khác có thể được sử dụng để theo dõi hoặc do thám một người.

Cùng với việc đảm bảo chúng ta có thể mã hóa dữ liệu, chúng ta nên đảm bảo rằng chỉ những người hoặc hệ thống tối thiểu cần thiết mới có thể giải mã dữ liệu đó. Chúng ta cũng có thể muốn sao lưu được mã hóa bằng các khóa khác nhau. Nhìn chung, chúng ta không muốn sử dụng lại các khóa mã hóa cho các mục đích sử dụng khác nhau, vì mỗi khóa chỉ nên có một mục đích. Một khóa mã hóa tệp có thể mã hóa hàng triệu tệp, nhưng khóa đó chỉ nên được sử dụng cho mục đích đó, chứ không phải, ví dụ, ký hoặc TLS.

Mặc dù sử dụng mã hóa và sao lưu là những biện pháp tuyệt vời, chúng ta cũng nên triển khai các giao thức để khôi phục thường xuyên từ các bản sao lưu để đảm bảo rằng chúng ta biết cách và quy trình hoạt động cho mọi thành phần. Trong một số trường hợp, chúng ta không cần sao lưu dữ liệu nhật ký chi tiết; tuy nhiên, hầu hết các tiêu chuẩn tuân thủ và kiểm toán đều yêu cầu nhật ký lịch sử. Một số thông số kỹ thuật thậm chí có thể yêu cầu các hệ thống phải được thiết lập để truy vấn và xóa các bản ghi nhật ký lịch sử cụ thể.

3.4.11. Ghi nhật ký và kiểm tra hỗn loạn

Có thể truy cập dữ liệu chi tiết nhanh chóng mang lại lợi ích to lớn cho một tổ chức. Ghi nhật ký được thiết kế tốt là một trong những khía cạnh bảo mật quan trọng nhất của thiết kế ứng dụng. Với việc ghi nhật ký nhất quán, dễ xử lý và đủ chi tiết, nhóm vận hành có thể phản ứng nhanh hơn với các vấn đề, nghĩa là các sự cố có thể được phát hiện và giải quyết nhanh hơn.

Việc ghi nhật ký không chỉ giới hạn ở những gì xảy ra trên mạng. Thiết bị mạng như bộ định tuyến, bộ chuyển mạch và tường lửa, xương sống của mạng công ty cũng cần được ghi nhật ký. Kiểu ghi nhật ký này có thể bao gồm ngày mua, phiên bản hệ điều hành và ngày kết thúc vòng đời. Việc có kho lưu trữ này cho phép ban quản lý không chỉ lập ngân sách cho các giao dịch mua lớn khi ngày kết thúc vòng đời xuất hiện mà còn cho phép nhóm bảo mật tham chiếu nhanh đến các thiết bị mạng của họ.

Hãy tưởng tượng một quản trị viên mạng thức dậy vào buổi sáng khi SolarWinds bị tấn công. Liệu quản trị viên có dễ dàng kiểm tra cơ sở dữ liệu hàng tồn kho để xác minh xem công ty có sử dụng thiết bị SolarWinds hay phải gọi đến các trang web từ xa và nhờ ai đó kiểm tra phòng máy chủ không.

Có sổ đăng ký tài sản cũng cho phép các công ty theo dõi các thiết bị như máy tính xách tay hoặc thiết bị di động. Điều này giúp ích trong trường hợp thiết bị bị mất, bị đánh cắp hoặc khi thiết bị đã hết hạn sử dụng.

Khi thiết bị cũ đi, chúng sẽ hết hạn bảo hành và cần được thay thế. Việc có một kho tài sản cho phép công ty chuẩn bị cho việc mua thiết bị lớn.

Kiểm soát cuối cùng mà chúng ta sẽ khám phá là Kiểm thử hỗn loạn . Kiểm thử hỗn loạn là một loại thực hành BCP hoặc phục hồi thảm họa (DR) thường được xử lý thông qua tự động hóa. Ví dụ, chúng ta có thể tận dụng một máy ảo có thông tin xác thực quản trị hợp lệ trong mạng sản xuất để gây ra thảm họa cố ý từ bên trong.

Kỹ thuật hỗn loạn bao gồm nhiều cách tiếp cận khác nhau, chẳng hạn như để các nhóm đỏ tạo ra sự hỗn loạn trong tổ chức để kiểm tra xem tổ chức có thể xử lý tốt như thế nào, lên lịch tắt máy theo chương trình ở nhiều khoảng thời gian khác nhau hoặc gửi các lệnh API nền tảng độc hại đã xác thực. Mục tiêu là thực sự kiểm tra các biện pháp kiểm soát trong các tình huống hỗn loạn và không thể đoán trước. Nếu một hệ thống sản xuất và tổ chức có thể xử lý sự hỗn loạn một cách tương đối nhẹ nhàng, thì đó là dấu hiệu cho thấy tổ chức đó sẽ mạnh mẽ và có khả năng phục hồi trước các mối đe dọa bảo mật.