Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Rủi ro
  3. /SolarWinds Orion (2020): khi chính bản cập nhật …
Quản lý Rủi ro

SolarWinds Orion (2020): khi chính bản cập nhật phần mềm tin cậy trở thành vũ khí xâm nhập hàng nghìn tổ chức

Kẻ tấn công cài mã độc vào quy trình build của SolarWinds, khiến các bản cập nhật Orion từ tháng 3 đến tháng 6/2020 mang theo cửa hậu; khoảng 18.000 khách hàng tải về. Vụ việc chỉ lộ ra khi FireEye điều tra vụ xâm nhập chính mình. Phân tích dưới góc nhìn rủi ro: tài sản nào cần được bảo vệ như "sản phẩm", và vì sao rủi ro phần mềm bên thứ ba phải nằm trong sổ đăng ký rủi ro của người mua lẫn người bán.

HP
Nguyễn Thu Hà, PMP
15/10/2026
4 phút đọc 2 lượt xem
Bình luận0

Bối cảnh thực tế

SolarWinds phát triển Orion, nền tảng giám sát hạ tầng mạng được nhiều chính phủ và doanh nghiệp lớn dùng với quyền quản trị rất cao. Theo các nguồn công khai, công ty có khoảng 300.000 khách hàng, trong đó khoảng 33.000 dùng Orion.

Diễn biến chính được ghi nhận:

  • Dấu vết xâm nhập vào hạ tầng phát hành của SolarWinds có từ chậm nhất tháng 9/2019; tháng 10/2019 kẻ tấn công thử nghiệm sửa đổi mã (bản chứng minh khái niệm).
  • Từ tháng 3 đến tháng 6/2020, các phiên bản Orion 2019.4 đến 2020.2.1 HF1 được phát hành kèm mã độc ngay trong bản cập nhật có chữ ký hợp lệ của hãng; công cụ chèn mã vào quá trình build sau này được các nhà nghiên cứu đặt tên là SUNSPOT.
  • Ngày 8/12/2020, FireEye thông báo bị đánh cắp bộ công cụ kiểm thử xâm nhập của mình; ngày 15/12/2020 xác nhận vector tấn công là bản cập nhật Orion.
  • Khoảng 18.000 khách hàng chính phủ và tư nhân đã tải bản cập nhật bị cài mã độc, dù kẻ tấn công chỉ khai thác sâu vào một số mục tiêu được chọn lọc.

Điểm đáng chú ý là không khách hàng nào có lỗi trong quy trình mua sắm thông thường: họ cập nhật phần mềm từ nhà cung cấp đáng tin cậy, đúng như khuyến cáo an toàn. Sau sự việc, CEO SolarWinds nghỉ hưu vào ngày 7/12/2020, công ty gỡ danh sách khách hàng tiêu biểu khỏi website và bị nhà đầu tư kiện tập thể vào đầu năm 2021.

Phân tích nguyên nhân theo chuẩn PMP

  • Nhận diện rủi ro (Identify Risks) bỏ sót hạ tầng build như một tài sản trọng yếu

    Rủi ro thường được nhận diện ở sản phẩm cuối, còn chuỗi công cụ (máy chủ build, tài khoản phát hành, kho chứng chỉ ký) lại bị coi là hạ tầng nội bộ. Nhưng với nhà cung cấp phần mềm, đường ống phát hành chính là điểm tập trung rủi ro cao nhất: một lần xâm nhập ở đó lan ra toàn bộ khách hàng. Danh mục rủi ro của dự án phát triển cần có hạng mục "tính toàn vẹn của quá trình build".

  • Phía người mua chưa quản lý rủi ro bên thứ ba (Plan Risk Management + Procurement)

    Phần mềm giám sát chạy với quyền rất cao, nhưng nhiều tổ chức coi nó là "đáng tin mặc định" vì đến từ nhà cung cấp lớn. Khi đánh giá nhà cung cấp và điều khoản hợp đồng, rủi ro cần được định lượng theo mức quyền mà sản phẩm nắm giữ trong môi trường của mình, kèm yêu cầu minh bạch về quy trình bảo mật phát hành.

  • Phát hiện nhờ may mắn thay vì nhờ giám sát (Monitor Risks)

    Kẻ tấn công ở lại trong nhiều tháng; vụ việc chỉ vỡ ra khi FireEye điều tra sự cố của chính họ. Kế hoạch giám sát rủi ro thiếu các chỉ báo sớm như kiểm tra hành vi bất thường của công cụ quản trị, tách mạng quản lý, và so sánh kết quả build với mã nguồn gốc (reproducible build).

  • Kế hoạch ứng phó sự cố và truyền thông chưa được diễn tập

    Khi hàng nghìn khách hàng đồng thời cần biết "tôi có bị ảnh hưởng không", nhà cung cấp phải có sẵn kế hoạch thông báo, danh sách phiên bản bị ảnh hưởng và hướng dẫn gỡ bỏ. Thiếu diễn tập khiến phản ứng chậm và mất niềm tin của các bên liên quan.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Đưa đường ống phát hành vào phạm vi bảo vệ của dự án

      Coi quy trình build và phát hành là một "sản phẩm" có yêu cầu bảo mật riêng, có chủ sở hữu rủi ro và kiểm tra định kỳ:

      • Cách ly và kiểm soát truy cập

        Máy chủ build tách khỏi mạng văn phòng, xác thực đa yếu tố cho mọi tài khoản có quyền phát hành, nhật ký truy cập được giám sát.

      • Kiểm chứng đầu ra

        So sánh bản build với mã nguồn đã duyệt (build tái lập được), lưu bản ghi cấu thành phần mềm để truy vết khi có nghi ngờ.

      • Ngưỡng dừng phát hành

        Khi có dấu hiệu bất thường ở môi trường build, tạm dừng phát hành cho đến khi điều tra xong, kể cả khi trễ mốc giao hàng.

    2. 2

      Bước 2: Đưa rủi ro nhà cung cấp phần mềm vào sổ rủi ro của người mua

      Với phần mềm có quyền cao, PM phía khách hàng đánh giá nhà cung cấp theo mức quyền, đòi hỏi bản kê thành phần phần mềm và cam kết thông báo sự cố, đồng thời giảm quyền và tách mạng cho công cụ quản trị để giảm thiệt hại nếu bị xâm nhập.

    3. 3

      Bước 3: Xây kế hoạch ứng phó và truyền thông cho kịch bản "chính ta bị lợi dụng"

      Chuẩn bị sẵn quy trình xác định phiên bản bị ảnh hưởng, kênh thông báo khách hàng, bản vá và hướng dẫn gỡ bỏ; diễn tập định kỳ cùng bộ phận pháp lý và truyền thông.

    PM Takeaway (Bài học rút ra)

    Rủi ro không chỉ nằm trong sản phẩm bạn giao mà còn trong cách bạn làm ra nó. Nhà cung cấp phải bảo vệ đường ống phát hành như bảo vệ sản phẩm; người mua phải đo rủi ro theo quyền mà phần mềm nắm giữ chứ không theo uy tín của thương hiệu.

    Nguồn tham khảo

    • Wikipedia — 2020 United States federal government data breach
    #Quản lý rủi ro#Chuỗi cung ứng phần mềm#SolarWinds#an-ninh-mang#Rủi ro bên thứ ba#Pipeline CI/CD

    Nguồn: Wikipedia — 2020 United States federal government data breach ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Bạn là PM của một công ty phần mềm. Nhóm bảo mật phát hiện dấu hiệu bất thường trên máy chủ build, nhưng bản phát hành lớn đã hứa với khách hàng vào cuối tuần. Bạn nên làm gì ĐẦU TIÊN?

    Bạn chọn phương án nào?

    Là PM phía khách hàng dùng phần mềm giám sát có quyền quản trị cao từ một nhà cung cấp lớn, bạn chọn hướng nào?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Rủi ro

    Target 2013: kẻ tấn công vào mạng qua nhà thầu điều hoà, cảnh báo của hệ thống phát hiện xâm nhập không ai xử lý

    Cuối năm 2013, tin tặc đánh cắp thông tin khoảng 40 triệu tài khoản thẻ và dữ liệu cá nhân của tới 70 triệu khách hàng Target. Báo cáo của Uỷ ban Thương mại Thượng viện Mỹ cho thấy điểm vào là tài khoản của một nhà thầu điều hoà, mạng không được phân tách và các cảnh báo không được hành động. Phân tích dưới góc nhìn rủi ro: nhận diện, đánh giá và ứng phó rủi ro từ bên thứ ba.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/10/2026
    Quản lý Rủi ro

    Log4Shell (2021): một thư viện nguồn mở do tình nguyện viên duy trì và cuộc chạy đua tìm xem "mình đang dùng nó ở đâu"

    Lỗ hổng CVE-2021-44228 trong thư viện ghi nhật ký Log4j có điểm CVSS 10, tồn tại từ năm 2013 và ảnh hưởng 93% môi trường đám mây doanh nghiệp theo khảo sát của Wiz và EY. Hội đồng Rà soát An toàn Mạng Mỹ gọi đây là lỗ hổng "đặc hữu". Bài học rủi ro: không có bản kê thành phần phần mềm thì không thể ứng phó nhanh, và phụ thuộc nguồn mở cần được quản lý như phụ thuộc nhà cung cấp.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận09/10/2026
    Số 333Quản lý Rủi ro

    Qantas QF32 (2010): ống dẫn dầu sai lệch bị đánh giá "không ảnh hưởng", động cơ A380 nổ tung và tổ bay ứng phó thành công

    Bốn phút sau khi cất cánh từ Singapore, động cơ Rolls-Royce Trent 900 của chiếc A380 chở 469 người nổ tung, phá hỏng hàng loạt hệ thống. Tổ bay năm phi công xử lý suốt gần một giờ và hạ cánh an toàn. Điều tra chỉ ra một ống dầu sản xuất sai, và các sai lệch tương tự từng được phát hiện nhưng được đánh giá là không ảnh hưởng khách hàng. Bài học về đánh giá rủi ro của sai lệch và năng lực ứng phó.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận06/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)