NHỮNG THAY ĐỔI CƠ BẢN TỪ ISO/IEC 27001:2013 SANG ISO 27001:2022
Phiên bản ISO 27001:2022 đã được xuất bản trong tuần cuối tháng 10/2022 vừa rồi, thực ra phiên bản này được mong chờ từ rất lâu để đáp ứng với sự thay đổi quá nhanh của công nghệ và các yêu cầu tuân thủ đặc biệt là mảng Cloud và bảo vệ quyền riêng tư (privacy).
Điểm đầu tiên là cái tên của tiêu chuẩn, phiên bản mới “Information Security, cybersecurity and privacy protection”.
Bổ sung thêm: cybersecurity và privacy protection
Rồi tiếp theo, đến các điểm thay đổi liên quan đến yêu cầu tiêu chuẩn (tức là phần mục 4 tới mục 10 của tiêu chuẩn), giờ thì bắt đầu với mục số 4
Yêu cầu bổ sung thêm được ghi nhận màu cam cam.
Trước hết, đọc điều khoản 4.2 này thì không thấy sự khác biệt gì lắm đối trong yêu cầu tiêu chuẩn, phần lớn khi thực hiện hoạt động phân tích bối cảnh việc xác định nhu cầu mong đợi của các bên liên quan đã được thực hiện và thường là cũng phải ghi rõ các yêu cầu mong đợi của các bên liên quan đối với hệ thống ISMS là gì, thông thường sẽ là một dạng tương tự như hình bên dưới
Xác định nhu cầu – mong đợi của các bên liên quan.
Thực ra nếu chỉ làm như ở trên thì chúng ta mới làm được phần a và b, phần c mới vẫn chưa được thực hiện, ở đây tiêu chuẩn ghi rõ là cần phải xác định các yêu cầu nào hệ thống ISMS đảm nhận;
ví dụ như cái hình ở trên, mục các đối tác trung gian thanh toán –> yêu cầu về PCI-DSS là một yêu cầu và/hoặc các ứng dụng phải được kiểm thử bảo mật (penetration testing) định kỳ ít nhất 1 năm/lần. Tức là cần làm rõ hơn yêu cầu cụ thể và thực tế đây là bản mapping các tiêu chí thực hiện các kiểm soát (security controls) cho từng đối tượng các bên liên quan.
Mục 4.4 này chỉ thêm vài dòng được thể hiện bằng màu chữ cam cam kia, và những dòng đó không quá xa lạ với những bạn đã làm ISO 9001. Phần này chỉ rõ Hệ thống Quản lý An toàn thông tin cũng được thiết lập bởi các Quá trình và sự tương tương tác giữa chúng (quá trình) phải được thiết lập. Đây là một điểm mới và chắc sẽ làm đau đầu những bạn chỉ làm về Hệ thống Quản lý An toàn thông tin và những bạn muốn thiết lập Hệ thống ISMS một cách cụ thể một xíu chứ không phải là vẽ các quá trình ra để đó cho dù là dựa theo PDCA.
Về mặt logic hay vận hành hệ thống thì yêu cầu của phiên bản trước ISMS không bao gồm các quá trình tương tác nên ở một góc độ nào đó sẽ chưa/không thấy rõ được sự ảnh hưởng của hệ thống ISMS đối với các sản phẩm/dịch vụ mong muốn được chứng nhận (nói cụ thể là cái phạm vi);
thêm vào đó, ISMS mặc dù được xem trọng tuy nhiên ngôn ngữ của nó cũng chưa được phổ biến nhiều và nếu không có cách thể hiện tương tác thì khó mà để các Hệ thống khác (tiêu chuẩn khác như 14001, 45001…) hiểu được anh ISMS làm là gì và sự tương quan giữa các hệ thống Quản lý như thế nào?
Còn sơ đồ tương tác và các quá trình, chuyện này cũng thực sự không khó lắm, với những bạn chinh chiến cùng Hệ thống ISMS hoặc làm về An toàn thông tin một thời gian thì sẽ nhận ra một số điểm chung khi thực hiện – đó là: Information/Asset Inventory, Vulnerability Scanning, Patch Management và Risk Management, thêm vài cái điểm cần thiết là phần Monitoring & Incident Response nữa + Awareness…Vẽ ra thì dễ và lưu ý đâu đó trong tiêu chuẩn (kể cả bản cũ) họ đều nói tới chuyện: Objectives, Interested Party/External service provider…
Ngoài cách trên thì còn cách nào khác không, nói luôn cho nhanh là có và nó cũng được thể hiện trong tiêu chuẩn ISO 27002:2022 thông qua phần Threat Modeling. Đừng nhìn Threat Modeling là một cái gì đó mông lung mà phải nói nó là rất thực tế đối với quá trình hoạt động của các công ty/doanh nghiệp mạnh về CNTT, nhất là các đội Blue team, Red Team cũng như đội Dev-Sec-Ops (dùng dấu gạch ngang ở giữa là thể hiện mối quan hệ giữa DevOps, DevSecOps hay ai đó muốn tách/gộp 2-3 nhóm ở trên vào làm 1). Đối với Threat Modeling là một cách trực quan nhất thể hiện được cả Mục tiêu (Objectives), các đối tượng liên quan (khách hàng, đối tác, các cách thức tấn công – thường gọi là threat actor/threat profile…) và đầy đủ các mô tả khác; hy vọng các Auditor khi xem tiêu chuẩn mới này cũng sẽ cập nhật góc nhìn để có thể đồng hành cùng các doanh nghiệp/tổ chức có độ trưởng thành về Security cao.
Sau khi đi dạo qua phần yêu cầu ở mục 4 thì giờ tiếp theo là sự thay đổi mục 6 nhé
Yêu cầu thay đổi ở mục 6
Phần yêu cầu này nổi bật với “be monitored” và “be available as documented information”, chỗ này thì yêu cầu trở nên rõ ràng hơn so với phiên bản cũ đó là các mục tiêu an toàn thông tin cũng như kế hoạch thực hiện phải được giám sát, thường ở phiên bản cũ chỉ ghi nhận là có mục tiêu cũng như có thể đo lường nhưng chưa có giám sát một cách cụ thể. Thật ra thì có khá nhiều mục tiêu có thể giám sát tự động được ví dụ như yếu tố Availability chẳng hạn, mấy công cụ giám sát mạng như Solarwinds hay Zabbix…có thể làm được; ngoài mấy cái đó thì còn nhiều cái khác để giám sát tự động lắm.
Điểm bổ sung ở đây là các tài liệu này cần được ghi nhận/lưu trữ lại và đảm bảo tính sẵn sàng (availability), tức là các thay đổi – điều chỉnh hay gì đó cần phải cập nhật rõ ràng (và thường là một số dự án by-pass qua ISMS nên sẽ không có phần cập nhật hoặc là tới phút cuối mới chèn vào mục tiêu…) và điểm đặc biệt hơn theo ý mình đó là cái mục tiêu – kế hoạch triển khai phải được công bố rõ ràng để theo dõi (kiểu như là 1 dạng Project online có track-change rõ ràng…). Mấy cái này thì bên DevOps (đa phần các bên mình biết đều apply Scrum, một số là Kanban) sẽ có phần rõ ràng với đầy đủ các thành phần như kế hoạch, monitored, available…chỉ là mình muốn làm ở mức độ nào thôi.
Đây là mục mới của tiêu chuẩn, và là bắt buộc phải có (shall be…) thế nhưng sao lại đưa vào ở đây và thực tế là phải làm gì? Phần này xác định việc nói rõ sự thay đổi đến hệ thống ISMS, và thường nó là các yếu tố như: thay đổi về phạm vi, thay đổi về các nhân sự chủ chốt (bao gồm sự thay đổi của ban lãnh đạo – ai biết điều gì sẽ xảy ra), thay đổi lớn về công nghệ (move từ cloud này sang cloud khác, thuê outsource / managed service, chuyển sang automation…) và một số các dự án công nghệ/giải pháp đang được triển khai (cho các yếu tố thay đổi ở trên)…Mục 6.3 này bắt buộc phải liên kết với mục 6.2 để monitored nữa nhé. Quên thì hok sao đâu, đa phần mọi người quên chính là cái nguồn lực cần thiết cho việc thực hiện sự thay đổi chiếu theo dự án đó là: scope, thời gian thực hiện và budget + chất lượng.
Ghi chú: planning of changes thì thường là những thay đổi lớn là chính, các mục tiêu được vạch ra cho việc thực hiện bảo mật an ninh thông tin như nhận thức (awareness) cho tới việc xác thực đa lớp (MFA, 2FA) cũng đủ nhiêu khê nếu áp dụng cho tất cả ứng dụng hoặc được hỗ trợ (nhớ chỗ này là enforce nhé)…Sự thay đổi planning of changes này chính là việc thực hiện theo dõi các dự án và bổ sung cho mục 6.2 cho việc thực hiện kế hoạch, sự thay đổi ghi nhận lại theo dự án… (nó còn áp dụng cho mục 8 nữa).
Mục số 7 gom chỗ mục d và e ở bên phiên bản cũ và thay bằng mục d ở phiên bản mới, chỗ communication này lúc trước phía mình làm/tư vấn thì nó là Qui định về trao đổi thông tin, truyền thông và dựa trên phần thông tin được phân loại (classified data/info) để thực hiện việc hướng dẫn cách bảo vệ và truyền thông.
Mục số 7 thì nó sẽ có những mục thông tin sẽ được truyền thông một cách tự động chẳng hạn như việc thông tin các sự kiện cần lưu ý về các trào lưu lừa đảo, cách thức tấn công mới –> giờ thì nhà nhà là app, toàn dân đều sử dụng smart-devices thế nên việc sử dụng các notification cho app cũng là 1 cách để truyền thông; đưa lên youtube hay tiktok cũng có thể.
–> tùy các nhóm thông tin như incident, disaster và các thể loại kinh dị sẽ có cách thức truyền thông cụ thể, với cách hình thức thông báo nhấn, lưu ý, hướng dẫn cho người dùng thì thông qua các yêu cầu của Privacy (liên quan đến data breach là ví dụ cho việc phải action gì, người dùng cuối làm gì và bên đối tác – processor làm gì… )
Ghi chú khác: ở mục 6.3 thì mấy cái change về quy định của luật, khách hàng là nhức đầu cực kỳ thế nên đừng quên vụ change về yếu tố luật nhé…mượn mục 7 để nói mục 6.3 thêm cho dễ lưu ý, nói chung vụ Privacy protection nói vậy thôi chứ căng lắm nhen, và thật may mắn là phần Privacy Information Management System là phần ISO 27701 chứ không phải 27001 nha, hơi lấn sân tí nhưng chưa phải là phần chính.
Mục 8.1 này có 2 chỗ highlight
Mục 8.1 này yêu cầu phải lập kế hoạch (vận hành), triển khai và kiểm soát quá trình để đạt được các yêu cầu và triển khai các hành động được xác định ở mục 6 –> lưu ý chỗ này nha, ở đây nói rõ là ở mục 6; mục 8.1 là phần vận hành (Kế hoạch vận hành và kiểm soát) do đó điểm nhấn mạnh là các tiêu chí cho các quá trình (được liệt kê ở mục 6 – tức là khá nhiều thứ từ cái phần risk treatment cho tới mấy mục đã lưu ý ở 6.3). Chỗ này cũng khá là nhiêu khê khi xác định các tiêu chí cho các quá trình thường đa phần cái mà các bên thường làm là xác định yêu cầu chấp nhận hệ thống (System acceptance), các ngưỡng của hệ thống (capacity) là một vài cách xác định tiêu chí.
Chuyện quan trọng hơn nữa sau khi xác định tiêu chí xong thì phải có các kiểm soát để đảm bảo việc vận hành đúng như mong đợi (dựa trên các tiêu chí – nằm trong ngưỡng an toàn).
Ví dụ về công nghệ thông tin thì cái cảnh báo để xử lý sớm (ví dụ như 85% của hệ thống thì alert, lên tới 95% thì bắt buộc phải action ngay và luôn…)
Phần tiếp theo là phần ghi chú cho mục nho nhỏ ở phần 8.1 tiếp
Sự thay đổi ở bên dưới thì chỉ thay đoạn outsourced…and controlled ở phiên bản cũ thành cái đoạn mới, ở đây chữ external provided processes, products or services là chỉ về các bên cung cấp dịch vụ bên ngoài như Cloud, các dịch vụ add-on dựa trên cloud như CASB và một đống các thứ khác như Firewall trên môi trường cloud chẳng hạn, một vấn đề khác đó là dùng external provided processes, products or services thì sẽ chốt luôn được các bên xử lý thông tin cho chuyên đề privacy (thường gọi là processor) + mấy bên làm agency cho từng chiến dịch như facebook ads campaign…
Lưu ý: chỗ này nhấn mạnh liên quan đến ISMS là phải được kiểm soát, và kiểm soát như thế nào thì thường SLA, hợp đồng và xử lý như mục 8.1 ở trên lưu ý.
Còn vài thay đổi về mục 9 và 10, tuy nhiên về cơ bản chỉ làm rõ hơn, nội dung cũng không khác biệt nhiều lắm.
Nguồn: CG Lương Trung Thanh
