[TechPM#3] Những gì mình học qua 2 tháng probation với domain mới - Cybersecurity 101

Ghi chép cá nhân của một Product trong 2 tháng đầu từ Fintech sang Cybersecurity (một domain nặng tech), ngụp lặn trong ngợp thuật ngữ-mindset-công cụ mới.

“Khi xu hướng vibe coding bùng nổ, ai cũng có thể tự tạo ra sản phẩm web hoặc mobile, bất kể có nền tảng kỹ thuật hay không. Nhưng chính vì rào cản công nghệ giảm xuống, vấn đề bảo mật lại càng trở nên quan trọng.

Đặc biệt, nhóm non-tech thường ưu tiên tốc độ ra sản phẩm, mà chưa chú trọng đến các rủi ro bảo mật nền tảng. Điều này khiến ứng dụng dù trông đẹp và chạy được, nhưng lại tiềm ẩn nhiều lỗ hổng nghiêm trọng từ dữ liệu người dùng bị lộ, cho đến nguy cơ bị chiếm quyền hoặc gian lận giao dịch”

Keyword “Vấn đề bảo mật” trong đoạn văn trên chỉ là dẫn đề cho bài viết liên quan đến một domain mới trong career path mà mình có may mắn được trải nghiệm - Cybersecurity (chi tiết hơn Cybersecurity B2B trong BFSI-Banking, Financial Service, and Insurance, gọi là cũng có tí liên quan domain Fintech trước đó)

Một domain khá là nặng về tech, có rất nhiều thuật ngữ mới. Trải nghiệm này khá giống với trước đó (khi mới chuyển ngành từ Engineer sang Product hay chi tiết từ domain ERP sang Fintech) cũng cơ số thuật ngữ mới làm mình gặp nhiều khó khăn trong công việc khi trao đổi với team engineer internal và external. Nhưng vui vì có nhiều thứ để học

Nói thêm, domain mới - technical stakeholders của mình được mở rộng thêm nên thuật ngữ được nghe cũng nhiều cái lạ hơn:

• Fintech

  • Tech lead / FrontEnd Dev / Backend Dev / QA / DevOps (internal)

  • Tech lead / Backend Dev / QA (đối tác bank)

  • …

• Cybersecurity

  • Tech lead / Security Engineer (internal)

  • Tech lead / Backend Dev / Application Dev (đối tác BFSI)

  • Security Engineer / DevSecOps (đối tác BFSI)

  • Solution Architect (đối tác BFSI)

  • SRE / DevOps (đối tác BFSI)

  • Infra / Cloud Engineer (đối tác BFSI)

  • Compliance & Risk (đối tác BFSI)

  • …

Lần này mình cũng áp dụng cùng công thức, cố gắng “đắm chìm” nhất có thể để có thể hiểu hết tất cả các khái niệm, thuật ngữ mà đội ngũ tech đang trao đổi với nhau. Một số thuật ngữ đã nghe khi làm Fintech thì lần này được hiểu sâu hơn, một số thuật ngữ thì “chân trời mới lạ”. Và như mọi lần, sau khi tìm hiểu, mình phải viết xuống các ghi chú / trải nghiệm cá nhân do mình tích cốp được trong quá trình này để lưu trữ kiến thức liền (cũng như sharing cho mọi người), kẻo kiến thức nó trôi đi nhanh lắm, quên ngay.

Disclaimer:
+ Mình xin phép tạm gọi bài viết dưới là Cybersecurity 101.
+ Mình sẽ sử dụng xen lẫn giữa tiếng Anh và tiếng Việt vì nhiều từ để bản tiếng Anh gốc sẽ dễ hiểu hơn và mình cũng không biết dịch ra sát nghĩa thế nào cho chuẩn. Mọi người hỏi thêm chatGPT nha.
+ Nếu trong bài viết có điều chi chưa chính xác, nhờ mọi người góp ý để mình sửa và học hỏi thêm nhé. Thanks! 

Cybersecurity 101

A.Những mindset mới

1. Focus hơn vào Client - 2 - Server

Khi mình còn làm Fintech (ví trả sau), đa số mình làm nhiều với mô hình Server-2-Server qua API (tích hợp hệ thống - hệ thống), còn domain mới này sẽ cần mở rộng thêm phía Client-2-Server

Server-2-Server: an toàn vì có các phương thức xác thực giữa 2 hệ thống. Nên khó bị tấn công, giả mạo

Client-2-Server: kém an toàn hơn khi dễ bị tấn công bằng nhiều phương pháp khác nhau như MITM (Man-in-the-Middle), Proxy…

Khi đi sâu hơn vào mobile security (Client-2-Server). Có một giả định quan trọng mà hầu hết các giải pháp nghiêm túc đều phải chấp nhận: kẻ tấn công có thể kiểm soát hoàn toàn thiết bị phía client. Thiết bị đó có thể đã bị root hoặc jailbreak, đang chạy trên emulator, bị bật USB debugging, developer mode, thậm chí sử dụng custom ROM hoặc môi trường ảo như Parallel Space, Dual Space, Virtual App…

Một trong những rủi ro lớn nhất ở client-side là kỹ thuật dịch ngược (reverse engineering). Khi hacker decompile được app và có thể:

• Hiểu logic nghiệp vụ

• Tìm API endpoint, secret key

• Viết script brute-force, automation hoặc replay request

→ Đây là lý do Whitebox Cryptography xuất hiện như một lớp bảo vệ sâu. Khác với mã hóa truyền thống (vốn giả định môi trường tin cậy), whitebox được thiết kế để hoạt động trong môi trường không tin cậy, ngay cả khi hacker kiểm soát thiết bị. Whitebox Cryptography thường đi kèm với:

• Obfuscation (xáo trộn mã nguồn)

• Mã hóa string, constant

• Anti-tampering (phát hiện app bị resign, debug, hook)

Mục tiêu không phải là “không ai phá được”, mà là khiến việc phá không còn hiệu quả về mặt chi phí và thời gian. Không chỉ phân tích tĩnh, hacker còn dùng hooking, debug, dynamic instrumentation để can thiệp trực tiếp khi app đang chạy (debug, USB debugging, developer mode, hooking, injection, thiết bị đang chạy proxy hệ thống, screen mirroring, virtual display)

Nếu mà các ứng dụng mobile (client-2-server) mà có luồng eKYC (Xác thực danh tính người dùng), rủi ro không chỉ là bypass logic, mà là giả mạo con người để mở tài khoản ảo, reset mật khẩu, thực hiện giao dịch tài chính. Hacker có thể thực hiện qua:

• Dùng ảnh có sẵn, video deepfake, virtual camera

• Stream khuôn mặt qua video call hoặc screen sharing

• Gọi API trực tiếp để bỏ qua app

Nói chung, nhìn tổng thể, khi lượng người dùng sử dụng các ứng dụng BFSI ngày càng nhiều, đặc biệt trên Android, thì xác suất người dùng rơi vào một môi trường “không còn sạch” là rất cao.

Không phải vì người dùng cố tình làm sai, mà vì:

• Android là hệ sinh thái mở

• Người dùng dễ root máy, cài app ngoài store, bật developer mode mà không ý thức rủi ro

• Điện thoại cũ, không được update OS

• Thiết bị bị nhiễm malware từ app thứ ba

• Dùng song song nhiều app clone / virtual app để “tiện việc cá nhân”

Và từ góc nhìn của hệ thống, chỉ cần một tỷ lệ rất nhỏ thiết bị bị kiểm soát, là đã đủ để tạo ra rủi ro lớn ở quy mô toàn hệ thống: gian lận tài khoản, lạm dụng ưu đãi, chiếm đoạt tài sản, hay thậm chí là làm suy giảm niềm tin vào nền tảng. Client-side security không phải để bảo vệ app, mà để bảo vệ con người phía sau app đó (vì với các luồng nhạy cảm như eKYC, reset credential hay giao dịch tài chính, chỉ cần một lỗ hổng nhỏ ở client-side, thì thứ bị đánh cắp không còn là “logic kỹ thuật”, mà là niềm tin của người dùng vào hệ thống)

2. Mô hình CIA triad (Confidentiality-Integrity-Availability)

Lần đầu tiên nghe đến khái niệm CIA triad này, tưởng là cảnh sát CIA hay thấy trên phim. Tuy nhiên, mô hình CIA triad được xây dựng để giải quyết những vấn đề cốt lõi nhất của an ninh mạng: bảo mật dữ liệu, quyền riêng tư và tuân thủ pháp luật. Ở tầng ý nghĩa sâu hơn, cybersecurity không chỉ nhằm bảo vệ hệ thống hay hạ tầng kỹ thuật, mà là bảo vệ con người phía sau dữ liệu đó.

• Confidentiality nhấn mạnh rằng chỉ những người được ủy quyền mới có quyền truy cập vào dữ liệu và tài sản cụ thể (như dữ liệu cá nhân)

• Privacy protection, với trọng tâm là bảo vệ thông tin cá nhân khỏi việc sử dụng trái phép. Các loại dữ liệu như PII (personally identifiable information) hay SPII (sensitive personal information) nếu bị lộ không chỉ là sự cố kỹ thuật, mà có thể gây ra những hậu quả nghiêm trọng cho người dùng, từ mất an toàn cá nhân đến thiệt hại tài chính → Thật ra ở VN mình cũng lộ quá trời mà, bị gọi điện thoại tín dụng hay mời chào chứng khoán, bất động sản đấy.

• Law yếu tố đặt ra ranh giới rõ ràng cho mọi hành động trong không gian số. Với vai trò là người làm cybersecurity, tuân thủ pháp luật không phải là một lựa chọn mang tính tình huống, mà là nghĩa vụ bắt buộc.

Nhìn từ góc độ Product, đây là một lời nhắc nhở rất rõ ràng xây dựng những sản phẩm xử lý dữ liệu người dùng không chỉ là bài toán kỹ thuật hay tuân thủ quy định, mà là một cam kết dài hạn về niềm tin giữa sản phẩm và người dùng (nếu dữ liệu người dùng bị lọt ra ngoài)

B.Những khái niệm mới

Thuật ngữ mới trong Cybersecurity nhiều như lá mùa thu. Mình tích góp trong quá trình làm việc, khi đọc tài liệu, khi ngồi nghe các anh tech trao đổi, khi học khoá học online về cybersecurity,…lụm được gì lụm:

1.Phishing (lừa đảo)

Là việc sử dụng các phương tiện truyền thông thông thuộc số để lừa mọi người tiết lộ dữ liệu nhạy cảm hoặc triển khai phần mềm độc hại gì đấy

• Business Email (Cái này hay được mấy anh ANBM (An ninh bảo mật) trong công ty thử lòng mình lắm nà): Đại khái hacker gửi một tin nhắn email có vẻ như đến từ một nguồn đã biết để đưa ra một yêu cầu nào đó

• Spear phishing: tấn công email độc hại nhắm vào 1 nhóm người dùng

  • Whaling: Một dạng của spear phishing, nhưng nhắm vào các vị trí cao như giám đốc điều hành công ty

• Vishing: khai thác thông tin liên lạc bằng giọng nói điện tử để thu thập thông tin nhạy cảm

• Smishing: sử dụng tin nhắn văn bản để lừa người dùng

2.Malware

Là phần mềm được thiết kế để gây hại cho các thiết bị hoặc mạng. Mục đích đa số là xấu như lấy thông tin, tống tiền. Có nhiều loại malware (giờ mình mới phân biệt là nó khác nhau như nào)

• Viruses: Mã độc hại can thiệp vào hoạt động của máy tính và gây thiệt hại cho dữ liệu và phần mềm.

  • Virus cần được khởi động bởi hacker, truyền virus qua một tệp đính kèm độc hại hoặc tải xuống tệp.

  • Khi ai đó mở tệp đính kèm độc hại hoặc tải xuống, virus sẽ ẩn mình trong các tệp khác trong hệ thống hiện đã bị nhiễm.

  • Khi các tệp bị nhiễm được mở, nó cho phép virus chèn mã riêng của nó để làm hỏng và/hoặc phá hủy dữ liệu trong hệ thống.

• Worms: Malware có thể tự nhân bản và tự lan truyền qua các hệ thống. Trái ngược với virus, worm không cần được tải xuống bởi người dùng. Thay vào đó, nó tự sao chép và lan truyền từ một máy tính đã bị nhiễm sang các thiết bị khác trên cùng một mạng.

• Ransomware: hacker mã hóa dữ liệu của một tổ chức và tống tiền để khôi phục quyền truy cập vào dữ liệu đó

• Spyware: Malware được sử dụng để thu thập và bán thông tin mà không có sự đồng ý. hacker thu thập dữ liệu cá nhân, chẳng hạn như email riêng tư, tin nhắn văn bản, bản ghi âm giọng nói và hình ảnh, và vị trí.

3.Social engineering

Là một kỹ thuật thao túng cực kỳ hiệu quả, khai thác sự thiếu cảnh giác của con người để có được thông tin cá nhân, quyền truy cập, hoặc các thứ có giá trị. Nhìn vào các lý do khiến social engineering trở nên hiệu quả, có thể thấy hacker dẫn dắt hành vi người dùng cực kỳ bài bản. Hacker hiểu mental model của người dùng rất rõ, thậm chí rõ hơn nhiều đội Product.

• Social media phishing: Hacker thu thập thông tin (digital footprint) của người dùng từ các trang mạng xã hội. Sau đó sẽ tìm cách tấn công dựa trên các thông tin đó.

• USB baiting: hacker chiến lược để lại một USB malware cho một nhân viên tìm thấy và cài đặt, để vô tình làm nhiễm một mạng.

• Physical social engineering: hacker mạo danh 1 người nào đó như nhân viên, khách hàng, hoặc nhà cung cấp để có được quyền truy cập trái phép vào đâu đó.

Ví dụ vài cách Hacker hiểu mental model

> Con người hiểu nỗi sợ hãi và áp lực tâm lý. Khi bị đe dọa, thúc ép hoặc tạo cảm giác “nếu không làm ngay sẽ có hậu quả”, người dùng dễ bỏ qua các bước kiểm tra logic vốn dĩ họ vẫn làm trong trạng thái bình thường.

> Con người còn có xu hướng tin vào bằng chứng xã hội. Khi nghe rằng “những người khác đã làm rồi”, “cả phòng ban đều đã cung cấp thông tin”, người dùng sẽ mặc định đó là hành vi an toàn và hợp lệ. Hacker tận dụng chính cơ chế này để hợp thức hóa yêu cầu của mình.

> Yếu tố khan hiếm và khẩn cấp tiếp tục đẩy người dùng vào trạng thái ra quyết định nhanh. Khi cơ hội có vẻ sắp biến mất, hoặc thời gian bị giới hạn, não bộ ưu tiên hành động hơn là phân tích. Đây là lúc lý trí thường thua cảm xúc....

4.Cái loại tấn công khác

• Password attack: hành vi cố gắng truy cập trái phép vào các thiết bị, hệ thống, mạng hoặc dữ liệu được bảo vệ bằng mật khẩu.

  • Brute force: thử tất cả các khả năng mật khẩu cho đến khi tìm ra mật khẩu đúng

  • Rainbow table: sử dụng các bảng băm được tính toán sẵn để dò ngược mật khẩu

• Physical attack: tác động trực tiếp đến môi trường thật, nơi hệ thống được triển khai như:

  • Cáp USB chứa mã độc

  • USB / ổ flash chứa mã độc

  • Sao chép thẻ và đánh cắp dữ liệu thẻ

• Supply-chain attack: tấn công nhắm vào các hệ thống, ứng dụng, phần cứng và/hoặc phần mềm để tìm ra điểm yếu nơi mã độc có thể được cài cắm. Do hầu hết các sản phẩm đều phải trải qua nhiều 3rd party trong quá trình phát triển. Càng nhiều layer thì càng dễ có lỗ hổng bảo mật có thể xuất hiện

• …

5. Hacker (người tấn công)

Nãy giờ mình dùng khá nhiều từ “hacker”, nghe thì có vẻ như đang gom tất cả vào một nhóm “kẻ tấn công”. Nhưng thực tế, hacker không phải lúc nào cũng là người xấu, và cũng không phải ai có kỹ năng hack đều có cùng động cơ.

Trong cybersecurity, “hacker” chỉ đơn giản là những người có khả năng hiểu sâu và thao tác được với hệ thống, từ mạng, ứng dụng cho đến dữ liệu. Điều tạo ra sự khác biệt không nằm ở kỹ năng, mà nằm ở mục đích và giới hạn họ tự đặt ra.

• Có những hacker được tổ chức thuê hoặc làm việc nội bộ (internal) để tìm ra lỗ hổng trước khi kẻ xấu kịp phát hiện. Những hoạt động này thường được gọi là penetration testing (pentest) mô phỏng các kịch bản tấn công có kiểm soát nhằm đánh giá mức độ an toàn của hệ thống.

• Các hacker tham gia vào những hoạt động này tuân thủ pháp luật và chuẩn mực đạo đức, thường được gọi là white hat hacker hoặc ethical hacker.

• Trong nhiều tổ chức, hoạt động này được tổ chức thành hai vai trò rõ ràng: Red team và Blue team.

  • Red team đóng vai trò như kẻ tấn công, liên tục tìm cách khai thác điểm yếu trong hệ thống, quy trình và thậm chí cả con người.

  • Ngược lại, Blue team là đội phòng thủ, chịu trách nhiệm giám sát, phát hiện và phản ứng trước các hành vi bất thường. Việc để hai đội này “đối đầu” nhau trong phạm vi kiểm soát giúp tổ chức hiểu rõ hơn hệ thống của mình đang yếu ở đâu, và cần cải thiện điều gì.

• Bên cạnh đó là các security researcher: những người nghiên cứu bảo mật, chủ động phát hiện vấn đề chỉ để cảnh báo và cải thiện an toàn hệ thống, chứ không khai thác lỗ hổng để trục lợi.

• Có những hacker sẵn sàng vượt qua mọi ranh giới để trục lợi, phá hoại hoặc đánh cắp dữ liệu. Nhưng cũng có những hacker không đứng hẳn về một phía nào. Họ làm việc theo hợp đồng, có thể là hợp pháp hoặc phi pháp, tùy vào người thuê và bối cảnh.

Vì vậy, trong phần còn lại của bài viết, khi mình nhắc đến hacker, mọi người có thể hiểu đó là một tập hợp rất đa dạng các vai trò và động cơ, chứ không đơn thuần là “kẻ tấn công” như cách chúng ta thường nghe trên báo chí. Hiểu đúng điều này cũng là bước đầu để hiểu vì sao cybersecurity không chỉ là câu chuyện công nghệ, mà là câu chuyện về con người, động cơ và niềm tin.

6.Hiểu đúng Threat, Risk, Vulnerability

Trong cybersecurity, việc nói đến “rủi ro” sẽ rất mơ hồ nếu không phân biệt rõ ba khái niệm nền tảng: threat (mối đe dọa), risk (rủi ro) và vulnerability (lỗ hổng).

• Threat (mối đe dọa) là bất kỳ sự kiện, hoàn cảnh hay tác nhân nào có khả năng gây tác động tiêu cực đến tài sản của tổ chức. Hiểu rõ các loại threat phổ biến là điều bắt buộc, bởi threat chính là nguồn gốc của rủi ro.

  • Insider threats: nhân viên, đối tác hoặc vendor lạm dụng quyền truy cập hợp pháp để thu thập hoặc làm rò rỉ dữ liệu, gây tổn hại cho tổ chức

  • Advanced Persistent Threats (APT): các tác nhân đe dọa có chủ đích và trình độ cao, duy trì quyền truy cập trái phép trong hệ thống suốt thời gian dài mà không bị phát hiện

  • Tuy nhiên, sự tồn tại của threat chưa đồng nghĩa với rủi ro ngay lập tức. Rủi ro chỉ xuất hiện khi mối đe dọa đó có khả năng ảnh hưởng đến tài sản cụ thể.

• Risk (rủi ro) là khả năng một mối đe dọa có thể làm tổn hại đến CIA triad (confidentiality, integrity hoặc availability) của một “tài sản”. Nói cách khác, rủi ro không đơn thuần là “có bị tấn công hay không”, mà là xác suất xảy ra và mức độ thiệt hại nếu điều đó xảy ra. Một cách hình dung dễ hiểu: đi trễ giờ làm là rủi ro (risk), còn kẹt xe, tai nạn là các mối đe dọa (threat) dẫn đến rủi ro đó. Các loại rủi ro:

  • External risk: các mối đe dọa từ bên ngoài, như hacker tìm cách truy cập dữ liệu

  • Internal risk: rủi ro đến từ nhân sự nội bộ

  • Legacy systems: các hệ thống cũ không còn được cập nhật nhưng vẫn kết nối và ảnh hưởng đến tài sản

  • Multiparty risk: rủi ro phát sinh khi chia sẻ dữ liệu hoặc hệ thống với bên thứ ba

  • Software compliance và licensing: phần mềm không được cập nhật, vá lỗi chậm

• Vulnerability (lỗ hổng) Yếu tố còn lại giúp threat biến thành risk. Lỗ hổng có thể đến từ cấu hình sai, phần mềm lỗi thời, hoặc quy trình vận hành thiếu chặt chẽ.

Ở góc nhìn Product, đây là một điểm cực kỳ quan trọng: mọi quyết định về tính năng, kiến trúc hay tích hợp bên thứ ba đều đang tạo ra hoặc làm giảm rủi ro, dù chúng ta có chủ động gọi tên nó hay không.

7.Kiến thức Network

Khi làm Fintech, mình từng gặp một issue liên quan đến network khiến mình vật vã vì không nắm kiến thức network nên không đặt ra các câu hỏi đúng, chỉ là forwarder thông tin giữa team network nội bộ và đối tác.

Thời điểm đó mình cũng chưa nghiêm túc nghiên cứu. Còn trong domain mới này, một số cuộc họp có sự tham gia của anh em bên Network và Security, mình buộc phải nghiêm túc tự học thêm các khái niệm network nền tảng. Không phải để trở thành network engineer, mà để hiểu hệ thống đang được bảo vệ như thế nào, các lớp phòng thủ nằm ở đâu, và mình đang đứng ở vị trí nào trong bức tranh tổng thể đó.

Mình bắt đầu từ những khái niệm tưởng chừng rất cơ bản như firewall. Trước đây, mình chỉ xem firewall như một “cái cổng chặn” traffic. Nhưng khi đào sâu hơn, mình hiểu rằng firewall chính là tuyến phòng thủ đầu tiên giữa mạng nội bộ và thế giới bên ngoài. Toàn bộ traffic ra vào đều đi qua đây và được kiểm soát bằng các rule do tổ chức cấu hình. Việc mở hay đóng một rule không chỉ ảnh hưởng đến khả năng kết nối, mà còn trực tiếp làm tăng hoặc giảm attack surface của hệ thống. Và cũng cần nhớ rằng firewall chỉ là một lớp phòng thủ, không phải “lá chắn toàn năng”.

Tiếp theo là server và mô hình client-server. Khi hiểu rằng mọi request từ client - web browser, mobile app đều phải đi qua server để được xử lý, mình bắt đầu hình dung rõ hơn dòng chảy dữ liệu: request đi đâu, được xử lý ở đâu, và response quay lại như thế nào. DNS server, file server, mail server hay application server đều có vai trò riêng, và mỗi server nếu bị cấu hình sai hoặc bảo vệ không đủ chặt đều có thể trở thành mục tiêu tấn công.

Ở tầng kết nối ra internet, mình hiểu thêm về modem và wireless access point cách hệ thống nội bộ kết nối với ISP, cách tín hiệu được chuyển đổi, và vì sao trong enterprise environment người ta thường dùng các công nghệ băng thông cao khác thay vì modem truyền thống

Song song với hạ tầng vật lý và thiết bị mạng, mình buộc phải hiểu cách dữ liệu thực sự “di chuyển” thông qua các mô hình TCP/IP và OSI. Việc chia network thành nhiều layer không phải để học thuộc lòng, mà để xác định chính xác sự cố hoặc tấn công đang xảy ra ở đâu. Một vấn đề có thể nằm ở ARP (network access layer), ở IP routing (internet/network layer), ở TCP retransmission (transport layer), hoặc ở HTTP/DNS (application layer). Khi hiểu được điều này, việc trao đổi với network và security team trở nên rõ ràng hơn rất nhiều: không còn nói chung chung “mạng có vấn đề”, mà là “issue đang nằm ở layer nào”.

OSI Model Layers

Ở transport layer, việc phân biệt TCP và UDP cũng rất quan trọng. TCP đảm bảo dữ liệu được truyền đầy đủ, đúng thứ tự phù hợp với các giao dịch cần độ tin cậy cao như login hay payment. UDP thì ưu tiên tốc độ, chấp nhận mất gói thường dùng cho các ứng dụng real-time như streaming. Hiểu điều này giúp mình đánh giá đúng impact khi gặp timeout, packet loss, thay vì quy hết trách nhiệm cho application.

Khi nhìn lên các layer cao hơn của OSI model, mình bắt đầu thấy rõ mối liên hệ giữa network và trải nghiệm người dùng. HTTP/HTTPS, DNS, SMTP ở application layer; SSL/TLS ở presentation layer; session management ở session layer , tất cả đều là những thứ người dùng không nhìn thấy.

Sau tất cả, mình nhận ra việc học network không phải để “lấn sân” kỹ thuật, mà để đứng đúng vai trò của một PM trong domain cybersecurity: hiểu ngôn ngữ của hệ thống, đặt câu hỏi đúng với đúng team. Và việc biết thêm network nó cũng khá là thú vị nữa :D

8.Kiến trúc Microservices

Các hệ thống backend trong domain BFSI mà mình gặp tới hiện tại, thì đa số theo Microservices Architecture (lúc còn ở Fintech gặp, qua Cybersecurity trong BFSI chắc chắn sẽ gặp tiếp for sure)

Thay vì một hệ thống monolith lớn, microservices chia ứng dụng thành nhiều service độc lập, mỗi service đảm nhiệm một phần logic nghiệp vụ riêng và chỉ service đó mới được quyền truy cập vào database của mình. Các service kết nối với nhau để tạo thành một hệ thống hoàn chỉnh. Cách tiếp cận này giúp hệ thống lớn, phức tạp có thể triển khai nhanh hơn, linh hoạt hơn và ít rủi ro hơn khi thay đổi.

Ở điểm vào của toàn bộ hệ thống là API Gateway. Đây không đơn thuần chỉ là một lớp “forward request”, mà là cửa ngõ kiểm soát truy cập: mọi request từ client, ứng dụng bên thứ ba, hoặc các hệ thống tích hợp đều phải đi qua đây. API Gateway chịu trách nhiệm routing, load balancing, xác thực (ví dụ JWT), rate limiting… Nói cách khác, đây là nơi đầu tiên có thể giảm thiểu rủi ro trước khi request chạm vào logic nghiệp vụ.

Technical Foundations for PMs: [TechPM#1] API Basics

Mỗi service trong kiến trúc này thường chịu trách nhiệm xử lý logic nghiệp vụ và kết nối với database. Một nguyên tắc quan trọng là service nào chỉ được truy cập database của service đó, nhằm giới hạn blast radius nếu có sự cố xảy ra.

Đối với giao tiếp giữa các service, không phải lúc nào cũng là syncAPI call. Trong nhiều trường hợp, hệ thống sử dụng Message Broker như ActiveMQ hoặc Kafka để xử lý giao tiếp không đồng bộ. Cách này giúp tăng độ ổn định và khả năng mở rộng, nhưng cũng mở ra thêm bề mặt tấn công nếu hàng đợi hoặc message không được bảo vệ đúng cách.

Ở tầng dữ liệu, một điểm mình thấy rất quan trọng là cách hệ thống tách read và write. Với các use case chỉ đọc dữ liệu, hệ thống có thể sử dụng Replica Database thay vì Primary Database. Replica được đồng bộ gần như real-time từ Primary thông qua cơ chế replication, giúp giảm tải cho database chính, cải thiện hiệu năng đọc, và quan trọng hơn là giới hạn rủi ro truy cập dữ liệu nhạy cảm. Customer Portal khi thực hiện các tác vụ read sẽ truy vấn Replica, sau đó kết quả được trả ngược lại qua API Gateway để hiển thị cho người dùng.

Vì sản phẩm của mình có một phần gắn trực tiếp với API Gateway, nên việc hiểu rõ vai trò của lớp này trở nên đặc biệt quan trọng, bản đồ giúp nhìn thấy dữ liệu đi qua đâu, rủi ro phát sinh ở lớp nào, và đâu là vị trí hợp lý để đặt thêm các lớp bảo vệ.

C.Những công cụ mới

1.SIEM tools (Security Information and Event Management)

Trong thực tế vận hành an ninh mạng, việc “nhìn thấy” chuyện gì đang xảy ra trong hệ thống quan trọng không kém việc có công cụ phòng thủ. Đây là lúc các SIEM tools (Security Information and Event Management) phát huy vai trò.

• SIEM là các hệ thống thu thập và phân tích log data tức là toàn bộ dấu vết sự kiện diễn ra trong hệ thống của tổ chức. Với quy mô dữ liệu lớn, việc tự lọc log bằng tay có thể mất hàng giờ, thậm chí hàng ngày. SIEM giúp giảm tải đáng kể cho đội ngũ security bằng cách tự động phát hiện các mẫu hành vi bất thường và đưa ra cảnh báo cho những mối đe dọa, rủi ro hoặc lỗ hổng cụ thể.

• Các SIEM tool thường cung cấp nhiều dashboard trực quan, gom dữ liệu thành từng nhóm để người dùng dễ theo dõi và phân tích theo nhu cầu. Tùy từng công cụ, dashboard và mức độ chi tiết sẽ khác nhau. Về mặt triển khai, SIEM có thể được cài đặt on-premise hoặc cloud. Nhiều tổ chức lựa chọn bản cloud vì dễ setup, vận hành và bảo trì hơn, đặc biệt với những đội security chưa quá dày dạn kinh nghiệm.

Mình được tuyển vô làm Product trong team này, một phần task là để build cái dashboard cho sản phẩm của công ty. Make it useful / insightful / user-friendly / better UI hơn cho end users.

• Ví dụ 1 SIEM tool phổ biến mà anh tech lead của mình có nhắc mình vô nghía để học hỏi coi người ta build dashboard thế nào

  • Splunk

    • Security posture dashboard (Dashboard này thường được sử dụng trong SOC). Nó hiển thị các sự kiện bảo mật nổi bật trong 24 giờ gần nhất, giúp đội ngũ security đánh giá nhanh xem hệ thống và các chính sách bảo mật có đang hoạt động đúng như thiết kế hay không. Đây là nơi analyst theo dõi các tín hiệu bất thường theo thời gian thực, ví dụ như traffic đáng ngờ từ một IP cụ thể.

    • Executive summary dashboard: giúp tổng hợp xu hướng sự cố, mức độ rủi ro theo thời gian, để security team có thể báo cáo ở mức high-level cho stakeholder hoặc leadership, thay vì đi vào chi tiết kỹ thuật.

    • Incident review dashboard: Dashboard này hỗ trợ phân tích khi một sự cố đã hoặc đang xảy ra, nhìn thấy timeline các sự kiện dẫn đến incident, từ đó hiểu được chuỗi nguyên nhân và xác định điểm cần can thiệp.

    • Risk analysis dashboard: Đây là nơi rủi ro được gán cho từng đối tượng cụ thể như user, máy tính hay IP address. Những hành vi bất thường ví dụ đăng nhập ngoài giờ làm việc hoặc lưu lượng mạng tăng đột biến. Dashboard này giúp security ưu tiên xử lý đúng chỗ, thay vì dàn trải nguồn lực.

À nói thêm, mấy anh ANBM 1 tay công cụ rồi, còn 1 tay khác là các tài liệu hướng dẫn chi tiết cách hành động trong từng tình huống cụ thể, kiểu như “kịch bản ứng phó”, mô tả từng bước cần làm khi xảy ra một sự cố an ninh. Mỗi tổ chức thường có kịch bản khác nhau, nhưng chung mục tiêu xử lý sự cố một cách nhất quán, đúng quy trình và có thể audit lại được.

2.Open-source/Operating systems/Automation

Mình quan sát thấy mấy anh tech sử dụng các Open-source tools vì 1 nó miễn phí và 2 là triết lý phát triển mở (phần mềm được xây dựng cộng tác bởi cộng đồng, với mã nguồn được công khai). Nhờ đó, mà dễ tùy biến linh hoạt theo nhu cầu, đồng thời các vấn đề bảo mật thường được phát hiện và vá nhanh hơn do có nhiều người cùng kiểm tra và đóng góp.

Linux là một ví dụ điển hình, một hệ điều hành mã nguồn mở rất phổ biến, cho phép cộng đồng đóng góp và cải tiến liên tục. Linux cho phép người dùng tùy biến hệ thống sâu thông qua command-line interface. Thông qua các command, analyst có thể kiểm tra trạng thái hệ thống, theo dõi tiến trình, phân tích log và xử lý sự cố nhanh chóng..

Mình thấy việc các anh trong cybersecurity dùng command line rất thành thạo, nhiều khi chả cần dùng chuột, cứ bấm bàn phím rồi mọi thứ chạy ầm ầm.

Bên cạnh đó, các security analyst thường sử dụng những ngôn ngữ như Python để viết script xử lý các tác vụ lặp đi lặp lại automation (tự động hóa): phân tích log, rà soát dữ liệu, phát hiện hành vi bất thường. Automation giúp tiết kiệm thời gian, tăng tốc phản ứng và giảm rủi ro do lỗi con người.

3.Network protocol analyzer

Song song với việc phân tích log ở tầng ứng dụng và hệ thống, đội ngũ security còn cần quan sát những gì đang diễn ra ở tầng mạng. Đây là nơi các hành vi tấn công thường để lại dấu vết sớm nhất.

Một nhóm công cụ tiêu biểu là network protocol analyzer, hay còn gọi là packet sniffer. Những công cụ này ghi lại và phân tích dữ liệu truyền qua mạng, giúp đội ngũ security thấy được các máy trong hệ thống đang “giao tiếp” với ai, trao đổi dữ liệu theo cách nào, và có điều gì bất thường trong luồng kết nối hay không. Packet sniffer thường được sử dụng nhiều trong điều tra sự cố hoặc phân tích chuyên sâu khi cần hiểu rõ bối cảnh của một hành vi đáng ngờ.

Bên cạnh đó là Intrusion Detection System (IDS): hệ thống giám sát hoạt động của mạng và hệ thống nhằm phát hiện các dấu hiệu xâm nhập. IDS liên tục phân tích các network packet, tìm kiếm các mẫu hành vi có thể cho thấy truy cập trái phép, đánh cắp dữ liệu hoặc các hoạt động bất thường khác.

Điểm mạnh của IDS nằm ở khả năng phát hiện sớm và cảnh báo kịp thời, giúp đội ngũ security có cơ hội phản ứng trước khi sự cố leo thang. Tuy nhiên, cần lưu ý rằng IDS chủ yếu đóng vai trò “phát hiện và cảnh báo”, chứ không trực tiếp ngăn chặn hành vi tấn công. Việc phản ứng và xử lý vẫn cần đến con người và các quy trình đi kèm.

4.Encryption

Encryption là nền tảng để đảm bảo tính bảo mật của dữ liệu. Thay vì lưu trữ dữ liệu ở dạng có thể đọc được (plaintext), encryption chuyển dữ liệu sang dạng mã hóa (ciphertext), khiến người không được phép gần như không thể hiểu hoặc sử dụng được dữ liệu đó. Phần mã hoá này xưa mình cũng có đề cập ở bài APIs

Technical Foundations for PMs: [TechPM#1] API Basics

5.Penetration testing

Ở khúc hacker phía trên, mình có nhắc trước về Penetration testing (pentest), nói lại lần nữa nó là hoạt động mô phỏng các cuộc tấn công vào hệ thống để tìm ra lỗ hổng trước khi kẻ xấu kịp khai thác. Đây là một hình thức đánh giá rủi ro rất toàn diện, có thể xem xét cả mối đe dọa từ bên ngoài lẫn bên trong tổ chức.

Pentest không chỉ kiểm tra công nghệ, mà còn kiểm tra quy trình và con người. Kết quả pen test thường là đầu vào quan trọng để cải thiện security posture của tổ chức.

6. Các công cụ can thiệp, giả lập và phân tích động

Bên mình triển khai POC (Proof of Concept) cho khách hàng khối BFSI, , một phần rất quan trọng là làm rõ năng lực bảo vệ của sản phẩm thông qua báo cáo thực tế. Để làm được điều đó, đội ngũ kỹ thuật không chỉ ngồi đọc tài liệu hay mô phỏng lý thuyết, mà phải chủ động sử dụng các công cụ tấn công để can thiệp, phân tích và thao túng ứng dụng để thử khai thác chính mobile app của khách hàng trong môi trường kiểm soát. Những công cụ này có thể được sử dụng cho nhiều mục đích khác nhau, từ phân tích bảo mật, reverse engineering, cho đến gian lận hay kiểm thử hệ thống

Các bài test này mô phỏng những kịch bản mà ứng dụng có thể gặp ngoài đời thực: từ việc chạy app trên thiết bị đã root hoặc jailbreak, can thiệp bằng các công cụ hooking, phân tích động hành vi ứng dụng, cho đến bắt gói tin và thao túng lưu lượng mạng. Mục tiêu không phải là “phá” ứng dụng, mà là chứng minh rõ ràng sản phẩm đang chặn được gì, phát hiện được gì và còn thiếu ở đâu.

Kết quả của quá trình này được tổng hợp thành các POC report, trong đó thể hiện rất cụ thể: với từng kỹ thuật tấn công, sản phẩm có phát hiện hay không, phát hiện ở tầng nào, phản ứng ra sao, và mức độ rủi ro được giảm thiểu như thế nào. Với khách hàng BFSI, những báo cáo này không chỉ phục vụ việc đánh giá giải pháp, mà còn là đầu vào quan trọng cho các quyết định liên quan đến risk management, compliance và audit nội bộ.

• Công cụ hooking cho phép can thiệp trực tiếp vào hành vi chạy của ứng dụng. Trên Android, những cái tên quen thuộc bao gồm Xposed, EdXposed, LSPosed, Frida, Riru, Zygote injected, Zygisk và Zygisk trên KernelSU. Phần lớn các công cụ này hoạt động bằng cách can thiệp vào Android Runtime (ART) hoặc quá trình khởi tạo của hệ thống (Zygote), từ đó cho phép chỉnh sửa logic ứng dụng khi đang chạy. Đáng chú ý là nhiều cờ phát hiện liên quan đến các công cụ này không thể tắt, do mức độ can thiệp quá sâu vào hệ thống. Một số công cụ cũ như TaiChi hay VirtualXposed hiện không còn được sử dụng rộng rãi, và đã được thay thế bằng Xposed kết hợp repackage hoặc chạy trong môi trường ảo.

• Công cụ root và jailbreak, vốn mở rộng quyền truy cập hệ thống vượt ra ngoài giới hạn mặc định của hệ điều hành.

  • Trên Android, Magisk là công cụ phổ biến nhất, cho phép tuỳ chỉnh hệ điều hành trên thiết bị đã root, đồng thời hỗ trợ nhiều module can thiệp sâu vào hệ thống.

  • Trên iOS, các công cụ jailbreak như Dopamine, checkra1n hoặc mô hình Rootless cho phép vượt qua cơ chế bảo vệ của Apple để phân tích và chỉnh sửa hành vi ứng dụng.

• Công cụ phân tích động và gỡ lỗi (debugger), bao gồm GDB, LLDB và Java Debug Wire Protocol (JDWP). Những công cụ này cho phép theo dõi luồng thực thi, bộ nhớ và hành vi của ứng dụng trong thời gian thực, thường được sử dụng kết hợp với các công cụ hooking như Frida. Với Frida, một frida server sẽ chạy nền trên thiết bị (thường là thiết bị đã root hoặc jailbreak), và khi ứng dụng khởi chạy, Frida có thể can thiệp trực tiếp để phân tích hoặc thay đổi hành vi của ứng dụng.

• Công cụ bắt gói tin (proxy) như Mitmproxy và Burp Suite, dùng để chặn và phân tích lưu lượng mạng giữa ứng dụng và server. Để hỗ trợ chống lại các kỹ thuật này, hệ thống có thể sử dụng cơ chế Proxy CA, nhằm ngăn việc cài đặt chứng chỉ CA giả của proxy và chặn các module như Magisk Trust User Certs, từ đó tăng hiệu quả của cơ chế chống Man-in-the-Middle.

• Môi trường ảo và giả lập (virtual environment / emulator). Android cho phép một ứng dụng chạy trong môi trường của ứng dụng khác, nhằm mục đích chạy nhiều bản ứng dụng với dữ liệu khác nhau. Các công cụ như Genymotion tạo ra môi trường giả lập gần giống thiết bị thật, thường được dùng cho kiểm thử, nhưng cũng có thể bị lợi dụng cho gian lận hoặc reverse engineering.

• Nhìn tổng thể, các công cụ trên không tồn tại riêng lẻ mà thường được kết hợp với nhau: giả lập + root/jailbreak + hooking + proxy + debugger. Chính vì vậy, trong mobile security, bài toán không chỉ là phát hiện một công cụ cụ thể, mà là nhận diện cả một tập hợp hành vi và môi trường bất thường.

Kết

Đây là những gì mình lụm nhặt (liệt kê) được sau 2 tháng probation với domain Cybersecurity. Cybersecurity là câu chuyện về con người, rủi ro và niềm tin rằng hệ thống đang bảo vệ đúng thứ cần bảo vệ, và người dùng phía sau dữ liệu đó được an toàn.

Hai thứ mình dùng nhiều nhất trong quá trình học domain này vẫn là những thứ rất “cũ”: system thinking và viết lại mọi thứ mình vừa hiểu (cùng với hỗ trợ của chatGPT for sure)

• System thinking giúp mình không bị ngợp trước một rừng khái niệm: từ network, microservices, log, SIEM cho tới các kịch bản tấn công. Còn việc viết lại (note, diagram, blog) buộc mình phải trả lời câu hỏi khó nhất: “Mình có thật sự hiểu chưa?”

Technical Foundations for PMs: [TechPM#2] System Thinking, Visualization & Diagrams 101

• Một Product giỏi không phải là người biết nhiều thuật ngữ nhất, mà là người kết nối được các mảnh rời rạc thành một bức tranh có ý nghĩa cho team và cho người dùng.

👉 Nếu bạn cũng đang bước vào một domain mới, đặc biệt là những domain nặng tech như Cybersecurity, vùng vẫy giữa biển kiến thức, nếu hoảng thì kệ nó, hãy cho nó chìm luôn.. “Đắm chìm” học chậm lại một chút, viết lại những gì mình học được rồi từng chút một, mọi thứ sẽ vào form. Và biết đâu, vài tháng sau, khi quay lại đọc những dòng note đầu tiên này, bạn sẽ mỉm cười và nhận ra: “À, mình cũng đã đi được khá xa rồi đó.”

---

Nếu những chia sẻ này mang đến cho bạn giá trị và bạn muốn đồng hành để mình có thể phát triển bền vững hơn, bạn có thể cân nhắc ủng hộ mình theo một trong những cách dưới đây 👇

🎁 Chuyển khoản ngân hàng:

• Vietcombank - 1041611760 - NGUYEN DUC THIEN

• Techcombank - 19036068036017 - NGUYEN DUC THIEN.

📖 Buy me a book: https://buymeacoffee.com/imthiennguyen

🙏 Mỗi sự ủng hộ, dù nhỏ, đều là động lực để mình tiếp tục viết, đọc, và chia sẻ nhiều điều hữu ích hơn đến cộng đồng. Cảm ơn bạn đã đồng hành cùng mình!