Phần thưởng nào dành cho người làm bảo mật?
Nên đọc bài này nếu bạn có ước muốn trở thành chuyên gia bảo mật:
Nếu ta chia nhỏ người làm bảo mật ra hai nhóm, nhóm chuyên thực hiện công tác bảo vệ và nhóm chuyên thực hiện công tác tấn công, thì công việc của nhóm đầu cũng không đem lại nhiều pleasure như công việc của nhóm sau. Ví dụ như triển khai mod_security sẽ không hấp dẫn bằng việc tìm và khai thác XSS, CSRF hay SQL Injection. Hay triển khai SELinux sẽ không thú vị bằng việc phát hiện và khai thác lỗi tràn bộ đệm trong một phần mềm mà công ti bạn đang sử dụng hoặc phát triển. Nhóm tấn công cũng dễ có nhiều credit hơn là nhóm bảo vệ, bởi lẽ họ chứng minh được hiệu quả thực tế công việc của họ (bằng cách tìm ra lỗi và khai thác chúng). Tôi kiêm nhiệm luôn hai công việc này và kinh nghiệm cho thấy sếp quan tâm đến những lỗ hổng mà tôi tìm thấy hơn là những giải pháp mà tôi sẽ triển khai để đề phòng các tấn công sẽ xảy ra (hoặc không bao giờ xảy ra).
Trong thực tế, phần thưởng của tôi phần nhiều đến từ những dự án hoàn toàn không liên quan gì đến bảo mật. Đó là những dự án xây dựng và triển khai hệ thống thông tin, những dự án tạo ra được một kết quả cụ thể mà sếp và sếp của sếp có thể thấy được. Đây cũng là điều dễ hiểu, nó cho thấy quan điểm bảo mật là một vấn đề kinh tế của Bruce Schneier là hoàn toàn có cơ sở. Nếu sếp tôi chỉ trả tiền để tôi bảo vệ những hệ thống có quá nhiều lỗ hổng, rõ ràng sếp tôi chỉ đang làm giảm nhẹ cái risk của công ti hơn là giải quyết vấn đề thực sự: xây dựng được hệ thống an toàn ngay từ đầu. Đây mới chính là nhiệm vụ của người làm bảo mật. Bảo mật không thể là một qui trình đi sau qui trình phát triển sản phẩm hay xây dựng hệ thống, bảo mật phải diễn ra song hành cùng các qui trình này. Nghĩa là bạn, một chuyên gia bảo mật, phải giúp cho sếp của bạn xây dựng được những hệ thống thông tin an toàn, hiệu quả và kinh tế ngay từ đầu. Lúc đó khả năng của bạn mới được phát huy tối đa và lẽ dĩ nhiên, phần thưởng của bạn cũng sẽ rất xứng đáng.
-Thái
One of the problems with the field of Information Security, particularly secure application development, is that it is not an inherently rewarding practice. Development is a rewarding practice when you add new functionality, or make existing processes easier to use or more efficient.Đây chính xác là những gì tôi cảm nhận được sau hơn hai năm làm việc như một người gác cổng. Nếu cho rằng sự tín nhiệm của sếp và lương bổng là phần thưởng lớn nhất của một người đi làm thuê thì chắc chắn rằng phần thưởng của tôi phần nhiều không đến từ công tác bảo mật. Bảo mật là một công tác quan trọng, sếp của tôi hiểu điều đó nhưng rõ ràng những gì mà công tác này đem lại cho công ty là hết sức mơ hồ. Tôi đã ngăn chặn được bao nhiêu vụ tấn công? Mỗi vụ tấn công đó nếu xảy ra sẽ làm cho công ty mất bao nhiêu tiền? Thật khó mà đưa ra một con số cụ thể.
The really dangerous part of this lack of reward is that hacking is inherently rewarding for those with that mindset. I've told co-workers many times that if I didn't really have a concern with the legality or the morality of it, (we won't get into whether Robin Hood was virtuous or not), I would probably want to be a hacker. In a development world, or even in support of a development world, you're driven by project deadlines and feature sets that the users covet. Security is (generally) an afterthought. In the black hat world, unless you're being directly paid for something you're supposed to produce ultimately, you're driven by your own creativity and your own ability to come up with an effective attack, and to do so without being caught, and before everybody else does.
To me, the second sounds very rewarding. In the former, you're paid to implement somebody else's creativity, and on their timeline, etc. In the latter, you're driven by the good idea. - new and crazy ideas are rewarded, not dismissed.
Nếu ta chia nhỏ người làm bảo mật ra hai nhóm, nhóm chuyên thực hiện công tác bảo vệ và nhóm chuyên thực hiện công tác tấn công, thì công việc của nhóm đầu cũng không đem lại nhiều pleasure như công việc của nhóm sau. Ví dụ như triển khai mod_security sẽ không hấp dẫn bằng việc tìm và khai thác XSS, CSRF hay SQL Injection. Hay triển khai SELinux sẽ không thú vị bằng việc phát hiện và khai thác lỗi tràn bộ đệm trong một phần mềm mà công ti bạn đang sử dụng hoặc phát triển. Nhóm tấn công cũng dễ có nhiều credit hơn là nhóm bảo vệ, bởi lẽ họ chứng minh được hiệu quả thực tế công việc của họ (bằng cách tìm ra lỗi và khai thác chúng). Tôi kiêm nhiệm luôn hai công việc này và kinh nghiệm cho thấy sếp quan tâm đến những lỗ hổng mà tôi tìm thấy hơn là những giải pháp mà tôi sẽ triển khai để đề phòng các tấn công sẽ xảy ra (hoặc không bao giờ xảy ra).
Trong thực tế, phần thưởng của tôi phần nhiều đến từ những dự án hoàn toàn không liên quan gì đến bảo mật. Đó là những dự án xây dựng và triển khai hệ thống thông tin, những dự án tạo ra được một kết quả cụ thể mà sếp và sếp của sếp có thể thấy được. Đây cũng là điều dễ hiểu, nó cho thấy quan điểm bảo mật là một vấn đề kinh tế của Bruce Schneier là hoàn toàn có cơ sở. Nếu sếp tôi chỉ trả tiền để tôi bảo vệ những hệ thống có quá nhiều lỗ hổng, rõ ràng sếp tôi chỉ đang làm giảm nhẹ cái risk của công ti hơn là giải quyết vấn đề thực sự: xây dựng được hệ thống an toàn ngay từ đầu. Đây mới chính là nhiệm vụ của người làm bảo mật. Bảo mật không thể là một qui trình đi sau qui trình phát triển sản phẩm hay xây dựng hệ thống, bảo mật phải diễn ra song hành cùng các qui trình này. Nghĩa là bạn, một chuyên gia bảo mật, phải giúp cho sếp của bạn xây dựng được những hệ thống thông tin an toàn, hiệu quả và kinh tế ngay từ đầu. Lúc đó khả năng của bạn mới được phát huy tối đa và lẽ dĩ nhiên, phần thưởng của bạn cũng sẽ rất xứng đáng.
-Thái
Comments
Cám ơn anh đã cho người đọc những góc nhìn thú vị :).