- Lỗ hổng bảo mật của SharePoint đã cho phép tin tặc nước ngoài xâm nhập vào cơ sở vũ khí hạt nhân của Hoa Kỳ
- Vụ việc này vượt ra ngoài một sự cố CNTT đơn thuần và cho thấy tiềm năng ảnh hưởng tới môi trường vận hành như hệ thống kiểm soát chất lượng và hệ thống SCADA
- Sự không đồng bộ về bảo mật IT và OT đã lộ rõ là một vấn đề quan trọng trên toàn bộ các cơ quan liên bang
- Chính phủ liên bang đã thúc đẩy chiến lược zero trust cho mạng lưới IT truyền thống, nhưng việc áp dụng cho môi trường OT thì vẫn còn chậm
- Bộ Quốc phòng đang thúc đẩy phát triển các biện pháp kiểm soát zero trust cho OT, dự kiến sẽ hình thành một chiến lược bảo mật tích hợp bao trùm cả IT lẫn OT trong tương lai
Lỗ hổng SharePoint và vụ xâm nhập cơ sở vũ khí hạt nhân Hoa Kỳ
- Một vụ việc đã xảy ra khi tin tặc nước ngoài tiếp cận cơ sở vũ khí hạt nhân của Hoa Kỳ bằng cách khai thác lỗ hổng của SharePoint
- Chuyên gia Sovada nhấn mạnh rằng việc tiếp cận này có thể ảnh hưởng đến hệ thống điều khiển phân tán quản lý kiểm soát chất lượng hoặc các hệ thống SCADA chịu trách nhiệm cho điều khiển điện lực và môi trường
- Vấn đề này cho thấy đây không phải là một lỗ hổng IT đơn thuần
Sự phối hợp IT/OT và khoảng cách trong an ninh zero trust
- Vụ Kansas City làm nổi bật một vấn đề mang tính cấu trúc: sự không thống nhất giữa thực hành bảo mật IT và OT trong toàn bộ hệ thống liên bang
- Chính phủ liên bang đang tiếp tục phát triển lộ trình zero trust cho mạng IT hiện có
- Tuy nhiên, trong môi trường vận hành (OT), việc xây dựng khung bảo mật tương tự đang bị chậm trễ tương đối
- Gần đây, việc phát triển khung bảo mật công nghệ vận hành (OT) cũng đã có tiến triển
Nỗ lực tích hợp bảo mật IT và OT
- Sovada cho biết đã có các công cụ quản lý IT (playbook) cho zero trust, phân hoạch mạng, xác thực và quản lý danh tính
- Bộ Quốc phòng đang phát triển một playbook để áp dụng zero trust trong môi trường OT
- Mục tiêu cuối cùng là tích hợp hướng dẫn quản lý zero trust cho cả IT và OT, nhằm đạt được bảo mật toàn diện trên mọi loại mạng
1 bình luận
Ý kiến Hacker News
Một trong những việc đầu tiên khi nhận đề nghị chuyển việc là kiểm tra MX record của miền email công ty. Đó là cách kiểm tra trong 1 giây xem công ty đó có phải dùng nền tảng của Microsoft hay không. Nếu là Microsoft, với tôi đó là tín hiệu cảnh báo lớn. Dù đây chỉ là cảm nhận cá nhân vì sản phẩm Microsoft quá phổ biến, nhưng sau hơn 20 năm làm việc, tôi nhận thấy các công ty dùng stack IT dựa trên MSFT có xác suất cao sở hữu văn hóa kỹ thuật mà tôi không thích. Chỉ cần họ dùng Outlook, SharePoint, Teams thì chưa thể kết luận ngay đó là công ty văn hóa xấu, nhưng nó vẫn là một chỉ báo có xác suất cao hơn hầu hết câu hỏi phỏng vấn khác về môi trường kỹ thuật kém, nên tôi vẫn làm vậy. Có thể nghe có vẻ thô với các kỹ sư tâm lý “Microsoft-first”, xin lỗi, đây là lỗi của tôi.
Thành thật mà nói, suy nghĩ vậy có thể làm người khác nghĩ mình là nhân viên có vấn đề. Các công ty không dùng Microsoft phần lớn dùng Google, và theo kinh nghiệm của tôi thì thậm chí còn tệ hơn. Thực tế, khi từng làm việc cùng những người ghét Microsoft, họ thường là kiểu luôn không dùng công cụ công ty chọn, nên liên tục kéo chân đội. (Bổ sung: không biết vì sao bài cũ lại đột nhiên bị giảm điểm.)
Nếu công ty cấp laptop Mac cho nhân viên thì với tôi là tín hiệu tốt; ngược lại, cấp Windows là tín hiệu xấu. Công ty tốt nhất tôi từng làm đã cấp mỗi kỹ sư phần mềm một laptop Mac và desktop Linux làm thiết bị chuẩn.
Hoàn toàn đồng tình. Tôi đã làm ở cả hai môi trường, và giờ trong môi trường MS tôi không muốn quay lại nếu lương không phải 7 chữ số (cỡ triệu).
Cá nhân tôi cảm thấy mức độ tôn trọng lao động thấp (ví dụ: lạm dụng visa H-1B) có mối liên hệ với việc dùng MS. Ở California, đặc biệt là gần như không có sự tôn trọng dành cho nhân tài địa phương hoặc người lao động. Bầu không khí đó còn làm công đoàn lẫn cả chính quyền tiểu bang nhanh chóng bị bào mòn.
Môi trường này thật sự cực kỳ tệ. Nó gieo vào đầu mọi người rằng software và máy tính vốn không quan trọng, và văn hóa đó dường như cũng ảnh hưởng xấu đến người làm phần mềm.
Khi có bài như vậy, mọi người thường nói “Microsoft thật dở”, nhưng tôi nghĩ họ không cân nhắc đến lý do kinh doanh khiến nó vẫn tồn tại. Chẳng dùng Exchange à? Giải pháp thay thế nào? Có sản phẩm nào phục vụ từ 15 đến 150.000 người không? Tôi từng vận hành một cluster Exchange cho 70.000 người dùng. Có phần mềm email nào thay thế được hệ thống backup cluster cho hệ thống single-endpoint dùng đĩa không chia sẻ không? SharePoint lại nữa có thêm hai RCE? Không có gì lạ, bản thân phần mềm này vốn không quá tốt. Dù vậy, nó vẫn chịu tải lớn rất tốt. Nhiều giải pháp mã nguồn mở ổn trong môi trường nhỏ nhưng hay đổ vỡ khi quy mô lớn. Tôi cũng hiểu tại sao các dev OSS không muốn tự nguyện làm việc miễn phí để giao tiếp với người dùng “vô dụng, mù công nghệ” như vậy. Microsoft cũng giữ được một mức tương thích ngược nào đó. Ở công ty, đâu đâu cũng có tài liệu legacy đã bị bỏ hoang nhiều năm, và file Excel có macro. Dù giảm bớt bảo mật ở Registry, nhưng file macro Excel năm 97 vẫn chạy được. Tôi thấy khó tìm được sản phẩm office tương thích với MS Office như vậy. Tóm lại, Microsoft có cái nút Gordian thực sự, gần như không có đáp án nào ngoài “đã đủ rồi với tương thích ngược, nâng cấp hết lên”. Trong khi đó, cách đây vài năm công ty cũ từng nhờ mình nâng cấp giải pháp làm bằng Exchange Web Services. Microsoft đã tắt Exchange Web Services trong Office365, giờ họ muốn chuyển sang GraphAPI.
Có vẻ như đang bàn về lợi thế của các sản phẩm MS quanh Exchange, nhưng vấn đề hiện tại là SharePoint. Giống như Windows, Microsoft đã xây hàng rào phòng thủ bằng Exchange. Điều làm tôi thật tò mò là tại sao lại nhiều công ty chọn toàn hệ sinh thái Microsoft như vậy. Đặc biệt ở mảng web, Microsoft làm cực kì tệ, mà SharePoint là tệ nhất. Nhưng dường như vẫn có không ít ví dụ triển khai mail server quy mô lớn kiểu Postfix/Dovecot. chia sẻ kinh nghiệm triển khai hệ thống mail server quy mô lớn trên Reddit
Tôi nói SharePoint gặp RCE thì tức là phần mềm đó rất nghiêm trọng. Nhưng rốt cuộc đó đâu phải là server file sharing rồi? (Mình chưa dùng.) Tôi nghĩ Samba hay FTP server cũng xử lý ổn khối lượng lớn. Thực chất có vẻ chỉ là UI.
Tôi tò mò các nhà máy sản xuất vũ khí cũ đã vận hành bằng cách nào nếu không có hệ thống này.
Tôi hoài nghi có bao nhiêu công ty thật sự cần Exchange cho 150.000 người. Với nhà máy sản xuất thông thường, khả năng rất ít.
Lập trình viên OSS gần như không nhận phần mềm cho ngách khó chịu, người dùng ngớ ngẩn và mù máy tính như vậy. Đây là thứ chính phủ có thể thuê họ làm để đóng góp cho lợi ích công bằng cách phát triển phần mềm nguồn mở. Mỹ đã lập tổ chức 18F trong thời Obama và thực sự tạo ra phần mềm hữu dụng cho công dân. Các bài toán cổ điển kiểu phần mềm khai thuế đều được làm rất hiệu quả, nhưng Trump đã giải thể ngay sau nhiệm kỳ hai. (Xem thêm: Lịch sử và giá trị của 18F, Lawfare: Bài học từ di sản của 18F)
Tôi không hiểu tại sao người ta có thể đặt SharePoint vào cơ sở trọng yếu của quốc gia. Cả MS Office 365, Teams, Edge đều có cả. Có vẻ cần phải thiết kế lại chính sách bảo mật ngay.
Tin xấu thật sự cho tình huống này.
Vậy có giải pháp thay thế nào được đề xuất không?
Có người còn kể chuyện để tài liệu mật tối mật ở nhà vệ sinh công cộng của resort...
Nhưng như vậy thì ai cũng dùng free /đùa thôi
Tôi từng vô tình làm sập hệ thống cảnh báo bằng Excel. (Nói thật thì đây không phải chuyện “do Microsoft muốn làm hại”, mà là side effect.) Tôi vận hành hệ thống alert và có cấu trúc tìm từ khóa
alert_logtrong log. Tôi tạo một sheetalert_logtrong bảng theo dõi dữ liệu làm bằng Excel. Nhưng vì dùng Excel bản cloud nên mọi văn bản nhập vào đều đi qua firewall. Log firewall ghi lại chuỗialert_log. Hệ thống cảnh báo thấy từ khóa này rồi cứ tự trigger cảnh báo liên tục. Alert thứ hai lại chèn thêm nội dung log firewall, tạo vòng lặp vô hạn. Các hệ thống có thể tương tác ngoài ý muốn với nhau và gây ra sự kiện ngoài dự đoán. Bởi vậy việc audit, red team, defense in depth theo nhiều lớp rất quan trọng.SharePoint là phần mềm tệ nhất, lỗi nhất mà tôi từng dùng. Khi tích hợp với Solidworks (công cụ thiết kế 3D), đã có lỗi file đột nhiên không mở được kéo dài nhiều năm. Microsoft biết lỗi đó và không thấy lý do không thể sửa, nhưng lại để đó mãi. Cloud storage của Microsoft như mê cung, không biết file cần tìm đang ở đâu hay có hoạt động được không. Một số tính năng chỉ chạy trên browser, số khác chỉ trên app, và không có tài liệu tổng hợp về danh sách này. Vì vậy tôi tin chắc vẫn còn nhiều lỗ hổng tiếp tục bị khai thác vô hạn.
Dù gần đây sản phẩm Microsoft (đặc biệt cloud) mỗi lần dùng tôi lại gặp một loạt bug, lỗi và chậm hơn tôi tưởng. Gần đây để gửi mail bằng subdomain mới, tôi tìm menu DKIM trong 365 cực vất vả. Cuối cùng phát hiện khóa DKIM cho email subdomain cũng phải đặt ở root domain. Rất lãng phí.
Hiện tôi đang triển khai dự án hợp đồng chính phủ và bị ép migrate từ Slack sang MS Teams. Gần hai thập kỷ không dùng sản phẩm Microsoft đã khiến tôi nhận ra các doanh nghiệp/hệ thống công đều có sức chịu đựng cực lớn với đau đớn UX.
Chúng tôi đồng bộ file sang SharePoint do Microsoft host bằng rsync. Với file thuộc hệ sinh thái MS (ví dụ Excel), khi file đến nội bộ metadata thay đổi, checksum đổi, nên rsync coi như file thay đổi và phải đồng bộ lại.
MS Word online ít nhất đã 2 năm có bug xóa text trên Firefox Linux (có thể cả OS khác). Nhiệm vụ số một của text editor là ghi nội dung vào tài liệu, nhưng nó không làm được và bug vẫn không sửa. Hơn nữa, chuyển sang Overleaf trả phí và dạy người không chuyên dùng LaTeX hay editor tích hợp còn hay hơn. Kết xuất tài liệu đẹp, và Overleaf chạy mượt không bị gián đoạn. Rất hài lòng. Mặc dù tôi là khách hàng Microsoft 365 trả phí, tôi thấy thứ tự ưu tiên của Microsoft là rất kỳ lạ. Q&A chính thức về lỗi xóa văn bản trên web version của Word
Các dịch vụ của Microsoft như SharePoint là cốt lõi nội bộ nhưng dường như bị xem như vấn đề cũ kỹ bị bỏ quên.
Nếu SharePoint không tốt như vậy thì tại sao chưa có vụ lạm dụng quy mô lớn? Tôi từng làm việc với đa số công ty Fortune 500, cảm giác hơn 90% dùng SharePoint. Dĩ nhiên cách triển khai khác nhau, nhưng nếu dựng chuẩn thì khá dùng được. Dù có giải pháp tốt hơn, duy trì 5-10 sản phẩm từ nhiều vendor sẽ khiến việc vận hành còn nặng hơn. Tôi không hiểu vì sao có người ghét Teams. Tôi dùng Zoom, Slack, Discord... và Team đủ dùng cho lịch, cuộc họp, ghi hình, Copilot... Chia sẻ đa màn hình thời gian thực và kênh mời tự do của Discord thích hợp cho debug/pair programming, nhưng Teams đủ để đáp ứng nhu cầu cơ bản.
Với tư cách công ty hỗ trợ hệ thống OT, mỗi lần thấy quyền write trực tiếp cấp 5 xuống cấp 1/0 theo Purdue model tôi thấy nản hết sức. (Bổ sung) Purdue model này được giải thích tại đây
Khi nhìn vào sự cố này, tôi nhớ đến phần MSSQL của howfuckedismydatabase.com
(Liên kết đến vụ mới nhất về CVE-2025-53770)
Người nào đưa cơ sở phân hạch hạt nhân ra Internet đáng vào tù, theo tôi.