Hãy ngắt kết nối Internet
(computer.rip)- Sau các sự cố bảo mật lớn như vụ CrowdStrike, thường xuất hiện phản ứng rằng “đáng lẽ không nên kết nối Internet”, nhưng với nhiều hệ thống nghiệp vụ, trao đổi thông tin là chức năng cốt lõi nên không thể giải quyết bằng cách đơn giản là chặn kết nối
- Những hệ thống vượt qua ranh giới tổ chức và địa lý, như hệ thống đặt chỗ và lập lịch hàng không, gần giống hạ tầng truyền thông thay thế điện thoại và điện tín; nếu loại bỏ mạng, giá trị vốn có của chúng cũng biến mất
- “Không kết nối Internet” có thể bao gồm từ một thiết bị đơn lẻ, air gap nghiêm ngặt, diode dữ liệu, WAN riêng, đường hầm VPN, định tuyến hạn chế cho đến AWS private VPC, nên mô hình đe dọa khác nhau rất lớn
- Trong môi trường ngoại tuyến hoặc kết nối hạn chế, mọi thứ từ cập nhật hệ điều hành, trình quản lý gói, kho nội bộ, kho tin cậy TLS, giấy phép đám mây, cập nhật nội dung cho đến xử lý image Docker đều làm thời gian và chi phí tăng lên
- Có thể áp dụng chính sách mạng hạn chế cho nhiều hệ thống hơn và xây dựng phần mềm có tính đến vận hành ngoại tuyến, nhưng hệ sinh thái phần mềm hiện nay vẫn coi kết nối Internet là mặc định
Giới hạn của lời khuyên “đừng kết nối Internet”
- Mỗi khi một sự cố bảo mật lớn lên tin tức, phản ứng “những hệ thống như thế này không nên được kết nối Internet” lại lặp lại
- Nhận định này có sức hấp dẫn trực giác về mặt bảo mật và ổn định, nhưng trên thực tế không có nhiều môi trường được vận hành như vậy
- Vấn đề cốt lõi là chỉ nói “không kết nối Internet” thì không đủ để xác định cụ thể thiết kế thực tế, chi phí vận hành và mô hình đe dọa
Hệ thống nghiệp vụ hiện đại gần giống thiết bị truyền thông
- Về mặt trừu tượng, máy tính có thể tạo ra giá trị thông qua tính toán, nhưng các hệ thống trong ngành công nghiệp mang tính chất công nghệ thông tin nhiều hơn là tính toán
- Công nghệ thông tin phải nhận và xuất thông tin; cách vận hành viên đưa băng vào như trước đây đắt hơn và chậm hơn truyền thông thời gian thực
- Phần lớn máy tính dùng cho nghiệp vụ hiện đại hoạt động như thiết bị truyền thông
- Không có nhiều hệ thống tạo ra giá trị mà không kết nối với các hệ thống nghiệp vụ khác
- Những kết nối như vậy thường vượt qua ranh giới tổ chức và địa lý
- Hệ thống đặt chỗ và lập lịch hàng không bắt đầu từ các hệ thống thay thế điện thoại và điện tín, trong đó mạng là một phần của chính chức năng
Bảo trì và vận hành cũng cần mạng
- Ngay cả với các hệ thống mà truyền thông thời gian thực không thiết yếu cho mục đích nghiệp vụ, kết nối mạng vẫn có giá trị vận hành lớn
- Nếu không có kết nối Internet, vấn đề sẽ bế tắc ngay từ việc lấy cập nhật phần mềm và giám sát hệ thống như thế nào
- Ngay cả khi quyết định rằng hệ thống đã “hoàn thiện” và không cần cập nhật hay giám sát thời gian thực, yêu cầu kinh doanh vẫn thay đổi theo thời gian
- Kết nối mạng làm giảm đáng kể chi phí xử lý những thay đổi này
“Không kết nối Internet” có nhiều cấp độ
- Trạng thái “không kết nối Internet” không có một ý nghĩa duy nhất, mà là tập hợp của nhiều cách triển khai
- Các hình thức có thể trải rộng từ ngắt kết nối hoàn toàn đến kết nối hạn chế
- Một thiết bị đơn lẻ hoàn toàn không có kết nối mạng
- Air gap nghiêm ngặt, chỉ có LAN riêng và dữ liệu không vượt qua ranh giới bảo mật
- Air gap trong đó dữ liệu được đưa vào bên trong ranh giới bảo mật bằng DVD-R
- Cấu trúc dùng cross-domain solution hoặc data diode để chuyển dữ liệu từ mạng bảo mật thấp sang mạng bảo mật cao
- Cấu trúc dùng cross-domain solution không có chứng nhận của NSA
- Mạng diện rộng riêng cũng được chia thành nhiều cấp
- WAN riêng có hạ tầng vật lý hoàn toàn độc lập và các biện pháp chống can thiệp
- Hình thức dùng ống dẫn chung, leased dark fiber hoặc wavelength của lit fiber
- Virtual private ethernet dựa trên MPLS
- Virtual private ethernet dựa trên tunneling có mã hóa và xác thực
- Lưu lượng riêng trên mạng truyền thông công cộng đôi khi cũng được gọi là “không kết nối”
- Hình thức thiết bị phần cứng thiết lập đường hầm mã hóa và xác thực trên common-carrier network như Internet
- Hình thức dùng thiết bị không có chứng nhận của NSA
- Đường hầm phần mềm đã được kiểm chứng, cấu hình network stack của hệ điều hành ở mức thấp để ngăn vượt đường hầm
- Đường hầm phần mềm có mức độ kiểm chứng thấp
- Hình thức kết hợp WireGuard với script iptables
- Kết nối Internet hạn chế cũng được gom vào cùng một cách gọi
- Mạng riêng chỉ cho phép các luồng lưu lượng cực hẹp bằng policy-based routing, v.v.
- Cấu trúc trong đó các luồng được phép nằm trong những ticket Jira cũ, và một số được thêm vào chỉ để “cho chạy được”
- Cấu trúc dựa trên tường lửa, tương đối thoáng với outbound và nghiêm ngặt với inbound
- Trong môi trường đám mây, phạm vi cũng dao động
- AWS private VPC không có định tuyến ra bên ngoài
- VPC giao tiếp với private VPC khác qua PrivateLink, v.v.
- Cấu trúc trong đó một số VPC được kết nối có định tuyến với Internet
- Cấu trúc có NAT Gateway và Internet Gateway nhưng security group được thiết lập nghiêm ngặt hai chiều
- Tất cả các hình thức này từng được gọi là “không kết nối Internet”, nhưng bề mặt tấn công và rủi ro của từng loại khác nhau
- Khi nói với hệ thống đặt chỗ hàng không rằng “đừng kết nối Internet”, nếu không có ý chỉ trạng thái hoàn toàn không có mạng, thì trên thực tế đó là một trong các cấp trung gian, và mỗi cấp lại có những cân nhắc thực tiễn khác nhau
Môi trường ngoại tuyến làm tăng mạnh chi phí và lịch trình
- Khi vận hành phần mềm trên mạng không có kết nối Internet hoặc bị hạn chế mạnh, ước tính lịch trình và chi phí tăng lên đáng kể
- Dạng yếu như AWS private VPC có thể ước tính khoảng 3–5 lần
- Dạng mạnh gần như tách biệt hoàn toàn có thể từ 10 lần đến còn cao hơn nhiều
- Gần như toàn bộ hệ sinh thái phần mềm được thiết kế với giả định có kết nối Internet
- Hệ điều hành cố lấy cập nhật từ máy chủ trực tuyến
- Nhà cung cấp hệ điều hành trả phí có thể cung cấp hạ tầng cập nhật trong mạng riêng dưới dạng giấy phép trả phí riêng
- Hệ điều hành miễn phí có thể tự xử lý, nhưng nếu dùng công nghệ mới thì có thể phát sinh nhiều phiền toái
- Trong quá trình phát triển và triển khai, vấn đề với nhiều trình quản lý gói và kho nội bộ lặp đi lặp lại
- Mức độ hỗ trợ kho nội bộ riêng khác nhau tùy từng trình quản lý gói
- Độ phức tạp tăng lên khi kết hợp nhiều trình quản lý gói, cách gọi và môi trường thực thi
- Chứng chỉ TLS của dịch vụ nội bộ cũng tạo ra công việc lặp lại
- Dịch vụ trong mạng riêng thường không dùng chứng chỉ thuộc root program của các CA phổ biến
- Có các thành phần như JRE có trust store riêng, và trong một số stack công nghệ, hành vi khác nhau tùy thư viện
- Ngay cả khi hệ điều hành có trust store, nếu từng công cụ dùng kho riêng thì vẫn cần điều chỉnh riêng
- Kiểm tra giấy phép đám mây và entitlement cũng trở thành trở ngại
- Một số phần mềm cố kết nối ra ngoài để kiểm tra giấy phép đám mây
- Cách vòng tránh có thể rất đa dạng và tốn thời gian, từ thêm ngoại lệ tường lửa quy mô lớn đến phát hành hệ thống giấy phép tùy chỉnh
- Cập nhật nội dung ngoại tuyến có thể trở nên phức tạp chỉ riêng vì quy trình của nhà cung cấp
- Trong một trường hợp phần mềm doanh nghiệp, phải đi qua cổng hỗ trợ khách hàng cũ và một cổng entitlement riêng
- Việc mở tài khoản và escalation mất hơn 3 tháng, và cổng cuối cùng có chứng chỉ TLS không hợp lệ
- Quy trình áp dụng cập nhật được tài liệu hóa không còn hoạt động, nên phải trao đổi email dài với kỹ sư
- Dù đã trả số tiền 5 chữ số cho giấy phép 1 năm, gần như hết hạn trong quá trình chuẩn bị sử dụng; việc chậm phát hành giấy phép gia hạn còn khiến pipeline CI bị gián đoạn
- Khó khăn của vận hành ngoại tuyến không phải do một tác vụ riêng lẻ nào đó là bất khả thi, mà gần giống death by a thousand cuts, khi mọi tác vụ đều khó hơn một chút
- Sản phẩm không tính đến môi trường ngoại tuyến thường ứng phó bằng script tạm và vá víu, và khoản nợ kỹ thuật đó được chuyển sang khách hàng vận hành môi trường ngoại tuyến
- Red Hat xử lý lĩnh vực này tương đối tốt, nhưng phần thời gian tiết kiệm được sẽ phải trả bằng tiền mặt
Những môi trường này hiếm và tập trung ở một số ngành
- Các môi trường không kết nối Internet theo dạng mạnh chủ yếu xuất hiện trong quốc phòng và cơ quan tình báo
- Một số ngân hàng cũng có thực hành phân tách mạng mạnh
- Quốc phòng, cơ quan tình báo và ngân hàng cũng được biết đến là các ngành có chi phí cao và thời gian dài; điều này không tách rời khỏi cách vận hành đó
- Môi trường kết nối hạn chế dạng yếu chủ yếu phổ biến trong các ngành chịu quản lý chặt như tài chính và y tế
- Đôi khi cũng có các công ty phần mềm thông thường rất coi trọng bảo mật và khóa chặt mạng ở mức mạnh
Ứng phó thực tế có thể làm ngay
- Bản thân hướng để ít hệ thống kết nối Internet hơn không phải là ý tưởng tệ
- Tuy nhiên, ngành phần mềm hiện tại chưa được chuẩn bị để vận hành thuận tiện trong môi trường không có Internet hoặc bị hạn chế
- Ứng phó thực tế gần với việc tăng kết nối hạn chế và khả năng vận hành ngoại tuyến hơn là kêu gọi tách biệt hoàn toàn
-
Hạn chế chính sách mạng tối đa
- Cần áp dụng chính sách mạng hạn chế cho càng nhiều hệ thống càng tốt
- Các nhà cung cấp đám mây đang làm cho những cấu hình này dễ tạo hơn trước
- Trên AWS, vận hành một môi trường định tuyến không Internet thực dụng không hẳn rất dễ, nhưng cũng không khó đến mức bất khả thi
- Nếu ở trong phạm vi AWS managed service thì nhìn chung ít đau đớn hơn, nhưng sẽ phát sinh chi phí
-
Xây dựng phần mềm có tính đến môi trường ngoại tuyến
- Những chức năng cần kết nối ra ngoài nên có thể bị vô hiệu hóa nếu có thể
- Nếu khó vô hiệu hóa, khách hàng phải có thể thay đổi endpoint sẽ sử dụng
- Nếu cho phép thay đổi endpoint, cũng cần có cách để khách hàng vận hành endpoint của riêng họ
- Nếu chỉ là file tĩnh đơn giản, có thể cung cấp dễ dàng bằng nginx và một thư mục
- Nếu là API, có thể phải phân phối phần triển khai nội bộ cho khách hàng và phát sinh gánh nặng bảo trì
-
Giảm giả định về TLS và phụ thuộc
- Trong môi trường ngoại tuyến, những giả định nhỏ rằng có thể kết nối tới dịch vụ khác trở nên phức tạp
- Không được giả định rằng có thể kết nối tới Let’s Encrypt
- Môi trường ngoại tuyến hầu như luôn đi kèm cơ quan chứng thực nội bộ
- Phải sử dụng system trust store
- Không được lấy yêu cầu hoặc phụ thuộc tại thời điểm triển khai
- Docker từng có ưu điểm là đóng gói theo kiểu tự chứa, nhưng cũng có container không khởi động được nếu không truy cập được kho npm, v.v.
- Có trường hợp phải sửa TLS trust store cho từng container Docker, nên trong môi trường ngoại tuyến, Docker có thể khiến việc quản lý còn khó hơn
Mối quan hệ giữa sự cố CrowdStrike và kết nối Internet
- Với sự cố CrowdStrike, phản ứng “tại sao lại kết nối Internet” đã xuất hiện nhiều lần, nhưng việc có kết nối Internet hay không gần như vuông góc với vấn đề xảy ra lúc đó
- Cập nhật nội dung của CrowdStrike là loại cập nhật mà trong môi trường lý tưởng cũng nên được cung cấp nhanh cho môi trường ngoại tuyến
- Trong môi trường ngoại tuyến mạnh trên thực tế, mirror cập nhật CrowdStrike nội bộ có thể chậm vài ngày, vài tuần, vài tháng hoặc vài năm
- Sự chậm trễ như vậy có thể giúp tránh được vấn đề, nhưng đó gần như là tình huống hai cái sai tình cờ khớp với nhau
1 bình luận
Ý kiến trên Hacker News
Tôi làm trong mảng bảo mật/hệ thống/vận hành, nhưng về cơ bản không đồng ý với tiền đề này. Tôi hiểu và hoàn toàn đồng ý khi tác giả nói “không dễ như vậy”, nhưng điều đó không có nghĩa là họ đang làm tốt công việc
Đáng tiếc là đa số làm không tốt, và toàn ngành được thiết kế để vẫn trụ được dù làm dở, đồng thời khiến việc làm tốt trở nên khó khăn
Nếu triển khai digital signage, quyền truy cập mạng chỉ nên được đưa vào allowlist cho địa chỉ IP máy chủ của tôi, và chỉ chấp nhận các kết nối được thiết lập bằng bản cập nhật đã ký và certificate pinning
Làm như vậy thì kẻ tấn công từ xa gần như không thể đụng tới. Nhìn vào ngành bảo mật phình to do sự lan rộng của Internet vạn vật (IoT), chắc chắn có các bảng signage hoặc thiết bị IoT/SCADA/triển khai khác vẫn còn cổng mở và mật khẩu mặc định
IoT chỉ là máy tính, nhưng cũng là những máy tính còn bị bỏ bê hơn cả các máy chủ hay máy ảo vốn đã không được vận hành đúng cách
Cũng có nơi làm tốt, nhưng cực kỳ ít, vì cấu trúc hiện tại không thưởng cho việc làm tốt. Việc tuân theo “best practices” hay hướng dẫn của nhà cung cấp không có nghĩa là làm tốt; nhiều khi chỉ có nghĩa là làm vừa đủ để nhà cung cấp hỗ trợ, và trong nhiều trường hợp là cho phép truy cập mạng không giới hạn
Vẫn phải lo về lỗi mạng, lỗ hổng mật mã, cấu hình sai, và những vấn đề khác có thể cho phép kẻ tấn công từ xa khai thác hệ thống. Nếu muốn đưa ra lập luận này, cần nêu ví dụ đúng nghĩa là không kết nối Internet, chứ không chỉ là một trường hợp được khóa chặt hơn
Tôi không rõ bạn bất đồng với tác giả bài blog ở điểm nào. Hay ý bạn là về cơ bản không thể cải thiện bảo mật của các hệ thống kết nối Internet vì con người không có đủ năng lực để làm vậy?
Ở Thụy Điển có một mạng riêng tách khỏi Internet tên là Sjunet, được các nhà cung cấp dịch vụ y tế sử dụng. Mục đích là biến máy tính thành thiết bị liên lạc có giá trị, nhưng không phơi bày IT của bệnh viện ra toàn bộ Internet
Các thành viên Sjunet được kỳ vọng là phải hiểu rõ mạng của mình và kiểm soát IT nghiêm ngặt
Có thể xem Sjunet như một môi trường air-gap ở cấp ngành. Nó cải thiện bảo mật, đồng thời theo tôi chi phí thấp hơn so với việc mỗi tổ chức tự vận hành một mạng air-gap riêng với danh sách allowlist khổng lồ
Nó tạo cảm giác an tâm giả tạo và còn trở thành cái cớ cho các chính sách bảo mật tệ. Băng thông thấp mà đắt
Đây là mạng kết nối các cơ quan như văn phòng quận, tòa thị chính để họ truy cập cơ sở dữ liệu trung tâm lưu thông tin cá nhân của công dân. Nó được dùng cho các việc như đổi địa chỉ, cấp thẻ căn cước mới, đăng ký khai sinh hoặc kết hôn
Theo tôi biết, ứng dụng “Źródło” chạy trên một máy tính “air-gap” riêng, không có Internet nhưng truy cập được mạng nội bộ, và xác thực bằng chứng chỉ client mật mã học thông qua smart card
Tất cả đã được vá bản mới nhất chưa? Có biết chắc là mọi người không cắm bừa bất kỳ thiết bị USB nào không?
Kiểu giống Tor nhưng không có những thứ đáng ngờ thì tốt
Tôi từng làm kỹ sư điều khiển và đã chế tạo hàng trăm máy móc. Có cáp Ethernet cho mạng fieldbus, nhưng tuyệt đối không được kết nối Internet.
Ở mỗi xưởng dụng cụ/khuôn mẫu trong khu công nghiệp địa phương đều có máy CNC với cổng Ethernet không được phép đưa lên Internet. Mọi nhà máy sản xuất có thiết bị tùy chỉnh, dây chuyền băng tải, máy ép, robot, CNC, trạm bơm, v.v. đều dùng Ethernet, nhưng lại sử dụng các hệ thống PLC và HMI không phù hợp để phơi ra Internet.
Bài viết nói rằng máy tính làm việc hiện đại gần như chủ yếu là thiết bị liên lạc, và không có nhiều hệ thống nghiệp vụ tạo ra giá trị mà không kết nối với các hệ thống công việc khác, nhưng như vậy là bỏ qua toàn bộ ngành sản xuất và các thiết bị điện tử mà ngành sản xuất đó tạo ra.
Hàng triệu hệ thống nhúng và PLC cứ mỗi 1 mili giây lại kiểm tra xem trạng thái đầu vào số vật lý/logic có thay đổi không, và nếu có thì thay đổi trạng thái đầu ra số vật lý/logic, qua đó tạo ra giá trị suốt cả ngày.
Không cần đưa hệ thống bảo mật đời 2024 vào một máy hàn điện trở có phần đúc được làm từ hơn 100 năm trước, lần cập nhật cuối cùng là năm 2003 khi gắn thêm PLC và màn hình đen trắng để thiết lập công thức. Chỉ cần cầm clipboard đi tới, nhập giá trị mục tiêu và làm nóng chảy thép cho đúng là được.
Thông thường, muốn kết nối với các máy kiểu này thì phải mang laptop và cáp Ethernet patch đi tới tận trước máy. Nếu cần hơn thế, chúng tôi kỳ vọng khách hàng đặt nó trong mạng công nghệ vận hành (OT) có tường lửa, hoặc dùng thiết bị SCADA/VPN như Tosibox, Ixon để nối giữa công nghệ thông tin (IT) và OT.
Thứ bạn xử lý có thể không phải là mục tiêu mà ai đó muốn khai thác, nhưng vì PLC thường xuất hiện trong hạ tầng trọng yếu và các cơ sở sản xuất cao cấp, chúng là mục tiêu hấp dẫn đối với tác nhân độc hại. Họ có thể muốn khai thác hạ tầng trọng yếu, hoặc một ngày nào đó lây nhiễm vào một thiết bị bảo mật lỏng lẻo mà điểm cuối giá trị cao như laptop kỹ thuật có thể kết nối trực tiếp.
https://www.cisa.gov/news-events/cybersecurity-advisories/aa... - Water Infra
https://claroty.com/team82/research/evil-plc-attack-using-a-...
Tôi vẫn không bị thuyết phục bởi lập luận rằng không nên air-gap hệ thống chỉ vì như vậy không thể dùng các thực hành phát triển lấy Internet làm trung tâm. Tôi thấy lập luận đó thật vô lý.
Nếu một hệ thống cần phải bịt cổng Ethernet bằng epoxy, thì ngay từ đầu nó đã không nên được lập trình theo thực hành phát triển lấy Internet làm trung tâm. Máy MRI khi khởi động lại kéo dependency JS từ NPM à? Đi tù ngay. Không phải ví von, mà là thật sự.
Sau khi xem video một người táy máy kiosk McDonald’s, tôi bắt đầu thử làm điều tương tự với các thiết bị thấy ở nhiều nơi.
Ở một khu food court có kiosk chạy Windows và truy cập Internet hoàn toàn. Ai đó có thể tải mã độc về để đánh cắp dữ liệu thẻ tín dụng. Mỗi lần dùng tôi đều tắt nguồn hoặc để lại thông báo trên màn hình, và cuối cùng họ bắt đầu đưa nó về chế độ kiosk.
Một cái khác là kiosk bãi đỗ xe, hoàn toàn không được harden. Có vẻ bọn tội phạm vẫn chưa nhận ra.
Cái thứ ba là màn hình tương tác của một thương hiệu bia. Nó không phải thứ có thể gây thiệt hại lớn, nhưng mở Notepad và để lại dòng “Drink water” thì cũng hay. Cuối cùng họ tắt nó đi, mà đó cũng là một cách giải quyết.
“Đừng đưa tiền cho người qua đường ngẫu nhiên” lẽ ra phải nằm khá cao trong danh sách yêu cầu, nhưng thực tế thì không.
Đoạn này thì tôi thật sự đồng cảm. Tôi đã cố làm cho trust store JRE của IntelliJ hiểu rằng nó phải dùng chứng chỉ mới cho zscaler, nhưng có hai ba JDK có thể chọn, và dù tôi đã đưa chứng chỉ mới vào trust store của từng cái, nó vẫn không hoạt động và tôi không biết vì sao.
Còn có hamnet nữa. Trên khối IP 44Net, một phần có thể định tuyến ra Internet, một phần thì không.
https://hamnetdb.net/map.cgi
Vì dùng các dải tần vô tuyến nghiệp dư nên có những ràng buộc thú vị. Cấm hoàn toàn việc sử dụng thương mại.
Đó là khế ước xã hội của các dải tần này: bạn có thể tiếp cận nhiều băng tần từ 136kHz đến 241GHz với chi phí rẻ, nhưng không được kiếm tiền từ đó.
Nó chỉ khá phổ biến ở Hà Lan và Đức: https://hamnetdb.net/map.cgi . Ở Tây Ban Nha chỗ tôi thì quanh tôi không có nơi nào dùng được.
Có vẻ khá hiển nhiên là hệ thống đặt chỗ của hãng hàng không ít nhất phải được kết nối mạng, và tôi cũng hiếm khi nghe ai khẳng định mọi thứ phải hoàn toàn ngoại tuyến. Nhưng chẳng hạn tôi cũng nghe nói máy tiện trong xưởng đã bị dừng vì sự cố lần này.
Cần nghĩ xem nó có thật sự phải online không. Tất nhiên sẽ có lý do, nhưng lý do đó phải được cân nhắc so với rủi ro.
Ngoài ra còn có nhiều ví dụ ngớ ngẩn hơn về các thứ kết nối Internet như tủ lạnh, ấm đun nước, cửa gara. Tôi không biết những thứ này có bị ảnh hưởng bởi sự cố CrowdStrike không, nhưng kể cả chưa thì lần sau cũng chỉ là vấn đề thời gian.
Về lập luận rằng hệ thống không kết nối “cực kỳ, cực kỳ phiền toái”, thì theo trải nghiệm của tôi với tư cách người dùng, mọi thứ bảo mật đều “cực kỳ, cực kỳ phiền toái”. Xác thực hai yếu tố, bắt buộc đổi mật khẩu, thiết bị bị khóa, trình quét mã độc, bộ lọc liên kết—một số là cần thiết, một số là nhảm nhí, nhưng tôi không có tư cách phân biệt cái nào là cái nào, và chắc chắn là tất cả đều tạo ra ma sát.
Kết luận lớn tôi rút ra không phải là “tất cả các hệ thống này không được kết nối Internet”, mà là một vài điều khác
Thứ nhất, các hệ thống như vậy không nên cho phép luồng mạng outbound. Khi đó mọi cập nhật tự động sẽ bị chặn, và sau này có thể quản lý qua kênh triển khai nội bộ
Thứ hai, ngay cả khi không làm vậy, nhiều sản phẩm phần mềm doanh nghiệp vẫn cho phép tắt cập nhật tự động. Windows là ví dụ tiêu biểu, và bản thân CrowdStrike cũng vậy. Tôi nghe nói trong số khách hàng của CS, có nơi đã tránh được thiệt hại nhờ tắt cập nhật tự động và triển khai thủ công
Thứ ba, bổ sung cho điểm 2, nên triển khai cập nhật dần dần sau khi đã qua một chút smoke test. Để phòng bất trắc. Tôi cũng nghe nói trong số khách hàng của CS, có nơi đã triển khai dần dần nên chỉ một phần thiết bị bị ảnh hưởng
Đây là bài viết tóm tắt khá đúng thời kỳ tôi cung cấp các giải pháp AI tiên tiến cho khách hàng quân sự. 80% nỗ lực được dành cho việc khiến các công cụ giả định có Internet chạy trơn tru trong môi trường air-gap