Khi xây dựng giải pháp bảo mật cho hệ thống công nghệ thông tin, người ta cần xác định các mức độ ưu tiên bằng việc phân tích các rủi ro có thể xảy ra. Tuy nhiên, trong thực tế nhiều hệ thống bảo mật được làm ra nhằm mục đích tìm cách chối bỏ trách nhiệm pháp lý của chủ thể hệ thống với các bên liên quan hơn là giảm thiểu rủi ro thực tế. Giáo sư Ross Anderson của trường đại học Cambridge, dựa trên kinh nghiệm thực tiễn đã đưa ra một số nguyên tắc hữu ích trong xây dựng hệ thống này.
Sử dụng chứng cứ mã hóa
Đầu những năm 1980, nhiều loại mật mã thương mại đã được phát triển nhằm giải quyết các vấn đề an toàn trong hệ thống thanh toán dùng thẻ ATM. Từ đó, kỹ thuật mã hoá được áp dụng cho nhiều hệ thống khác nhằm bảo đảm an toàn cho các giao dịch trực tuyến và bảo vệ quyền lợi của người tiêu dùng. Việc sử dụng các bằng chứng liên quan tới mật mã cũng bắt đầu xuất hiện, vì khi có tranh chấp pháp lý xảy ra, luật pháp sẽ phải xem xét và tiến tới chấp nhận các chứng cứ do các hệ thống bảo mật cung cấp. Hệ thống giao dịch thương mại có sử dụng mật mã phổ biến nhất là các máy rút tiền tự động ATM. Đã có nhiều vụ kiện liên quan đến ATM vì nó được sử dụng sớm nhất, là mục tiêu của bọn tội phạm và chính là nơi thử nghiệm đầu tiên của việc sử dụng các bằng chứng mã hoá. Trong rất nhiều vụ án, phía ngân hàng cho rằng hệ thống mã PIN được xây dựng và hoạt động dựa trên các thiết bị bảo mật bằng phần cứng, không có sự can thiệp của nhân viên ngân hàng. Khi đó, bất kỳ giao dịch nghi ngờ nào đều do lỗi từ phía khách hàng. Tuy nhiên, ở Anh đã có quy định pháp lý yêu cầu ngân hàng phải cung cấp một bộ tài liệu đầy đủ về bảo mật, bao gồm chế độ bảo mật và các chuẩn, thủ tục quản lý khoá và truy cập, báo cáo của các thanh tra viên và kiểm toán sổ sách, bảng cân đối của ATM, chi tiết những ý kiến của khách hàng trong 7 năm gần nhất. Khi có tranh chấp pháp lý xảy ra, ngân hàng thường khẳng định chắc chắn vào tính tin cậy hệ thống bảo mật của họ, nên không phát hiện được những lỗ hổng và lấy lý do an ninh để trốn tránh việc phải cung cấp thông tin về hệ thống này. Nhiều trường hợp, trong quá trình điều tra, cảnh sát đã phải sử dụng bên thứ ba tham gia để đưa ra những chứng cứ về lỗi kỹ thuật trong hệ thống bảo mật của ngân hàng. Nguyên tắc 1: Những hệ thống bảo mật – nguồn cung cấp bằng chứng pháp lý, phải được thiết kế và thử nghiệm trên các giả định sẽ được kiểm tra chi tiết bởi một chuyên gia độc lập. Đây có thể coi là nguyên tắc quan trọng nhất. Một vấn đề khác là rất nhiều nhà thiết kế không nhận thấy rằng hầu hết những lỗi trong hệ thống bảo mật xảy ra là do sai lầm trong chương trình ứng dụng và quản lý, vì thế cần tập trung vào việc xây dựng một hệ thống kỹ thuật tốt mà họ có thể tin tưởng, chứ đừng trông đợi vào những điều kỳ diệu (chẳng hạn như thuật toán mã hoá mới, thẻ thông minh hoặc một bộ chuẩn ITSEC). Điều này được minh họa bởi hệ thống ATM ở Na Uy. Những ngân hàng ở Na Uy đã gửi hàng triệu thẻ smartcard tới khách hàng và cam đoan là không có khoản nợ nào có thể xuất hiện trong tài khoản của khách hàng nếu không có thẻ và mã PIN của họ. Nhưng một số vụ rút trộm tiền đã xảy ra, trong đó nạn nhân là nhân chứng đáng tin cậy, họ hoàn toàn tin rằng PIN của họ không bị lộ. Các ngân hàng từ chối hoàn tiền và điều này được Ngân hàng Trung ương Na Uy cùng các thanh tra địa phương ủng hộ, mặc dù những giao dịch nghi ngờ đã vi phạm vào hạn mức rút tiền theo chu kỳ và lỗi này là do phần mềm ứng dụng. Các nạn nhân ở vào thế yếu và không có cơ sở để xác định được lỗi là do chiếc thẻ, bộ đọc, mạng, hệ thống thanh toán hay chi nhánh ngân hàng, thậm chí vấn đề cũng có thể nằm ở thủ tục hướng dẫn kỹ thuật sử dụng thẻ hoặc là tổng hợp những khâu đó. Nhiều tổ chức có đội ngũ chuyên gia và kinh phí cần thiết để tìm ra kỹ thuật và thủ đoạn tấn công. Nhưng hầu hết tội phạm (vừa không có kỹ năng vừa không có tiền) chỉ lợi dụng những cơ hội dễ dàng, do đó hầu hết các cơ hội chúng có được là do sai lầm từ một khâu trong hệ thống. Nguyên tắc 2: Những vấn đề thực tế xảy ra bắt nguồn từ sai lầm trong việc thiết kế ứng dụng và trong phương thức hoạt động của hệ thống.
Mục tiêu của bảo mật
Cho đến nay, dường như những vụ án về các giao dịch gây tranh cãi đều bị quên lãng nếu yêu cầu một trong hai đối tác phải đưa ra chứng cứ. Khách hàng nói “Tôi không rút tiền”, nhưng ngân hàng nói “Bạn đã rút tiền”, khi đó toà án sẽ làm gì? Nếu nạn nhân phải tìm hiểu xem chính xác lỗi xảy ra ở đâu trong hệ thống ngân hàng, thì họ khó mà thành công. Mặt khác, nếu yêu cầu ngân hàng thiết lập bảo mật cho hệ thống, thì làm thế nào để chống lại ý kiến của các chuyên gia độc lập? Chúng ta hãy so sánh hoạt động giữa ngân hàng ở Anh và ngân hàng ở Mỹ. Các ngân hàng ở Anh khẳng định hệ thống của họ không thể sai lầm được, không thể ghi nợ tài khoản của một ai đó, trừ khi người đó dùng thẻ và mã PIN tại ATM. Vì vậy, những ai phàn nàn đều bị quy kết rằng họ chắc chắn nói không đúng sự thật hoặc nhầm lẫn…. Các ngân hàng ở Mỹ lại xử sự khác. Ví dụ, trong một vụ kiện giữa Dorothy Judd và ngân hàng CitiBank, Judd khẳng định rằng cô ta không rút số tiền mà ngân hàng Citibank đã trừ vào tài khoản của mình. Ngân hàng thì lại khẳng định chắc chắn Judd có rút. Thẩm phán đã kết luận: ngân hàng Citibank sai khi khẳng định các hệ thống trong ngân hàng “không thể sai sót được”. Kể từ đó, nếu một khách hàng của ngân hàng nào ở Mỹ khiếu nại về khoản ghi nợ điện tử thì ngân hàng phải hoàn lại số tiền trong vòng 30 ngày, trừ khi có thể chứng minh lời khiếu nại đó là sai. Một trong những vấn đề đang được khai thác là mối quan hệ giữa rủi ro và đầu tư cho bảo mật. Một số ý kiến cho rằng, các ngân hàng ở Mỹ phải trả cho những khoản “lừa dối”, nên họ sẽ đầu tư chi phí nhiều hơn vào vấn đề bảo mật so với các ngân hàng ở Anh. Một nghiên cứu khác cho thấy, trong khi các ngân hàng ở Anh và một số tổ chức xã hội sử dụng các môđun bảo mật bằng phần cứng để quản lý mã PIN thì hầu hết các ngân hàng ở Mỹ lại tập trung vào phần mềm mã hoá PIN. Thực ra, việc sử dụng các môđun bảo mật bằng phần cứng này có thể là một phần để ngân hàng có cớ trốn tránh trách nhiệm. Giám đốc ngân hàng ở Anh muốn sử dụng các môđun bảo mật của họ để chống lại những lời phàn nàn của khách hàng. Chiến lược của các ngân hàng Anh đã không có tác dụng, không ai có thể xây dựng những hệ thống vượt qua được mọi sự kiểm tra mang tính phản biện. Nguyên tắc 3: Trước khi bắt đầu xây dựng một hệ thống bảo mật máy tính thì cần làm rõ mục đích thực sự của hệ thống là gì? Ở Mỹ, các bản ghi của máy tính chỉ có thể được chấp nhận là chứng cứ nếu chúng nằm trong một tiến trình quản lý kinh doanh theo đúng thông lệ. Việc sử dụng máy tính cho mục đích khác sẽ khiến cho dữ liệu của chúng không được sử dụng. Ở Anh cũng vậy, toà án đã không công nhận những chứng cứ ATM nếu chúng được lưu ở hệ thống hoạt động không theo chuẩn.
Chuyển đổi trách nhiệm
Mỗi hệ thống đều có một điểm chung nhất là mục đích thực của hệ thống, tất nhiên là khác với mục đích quảng cáo. Chủ sở hữu hệ thống thường cố tránh bị đổ lỗi khi có sự cố hỏng hóc. Ví dụ trong nền công nghiệp phần mềm, thông lệ là có dịch vụ cài đặt với chi phí đáng kể và người bán sẽ cử một kỹ thuật viên đến để thực hiện. Nhiều người sử dụng tiết kiệm tiền bằng cách tự cài đặt phần mềm và chính việc làm này khiến họ không thể kiện nhà cung cấp khi dữ liệu bị sai sót. Mọi việc sẽ trở nên phức tạp hơn khi một bên sử dụng quyền lực trên thị trường, đe doạ pháp lý hoặc tác động chính trị để trốn trách nhiệm. Nếu trách nhiệm không thể chuyển sang nhà nước, nhà cung cấp, các bộ phận khác hoặc tư vấn thì bên quản lý sẽ cố gắng để chuyển trách nhiệm đó cho khách hàng, đặc biệt là trong những lĩnh vực kinh doanh độc quyền. Nguyên tắc 4: Cần phân định rõ trách nhiệm được chuyển dịch như thế nào trong hệ thống đang xây dựng hay sử dụng.
Giới hạn của quy trình pháp lý
Trong mật mã học, người ta thường giả định rằng luật pháp có độ tin cậy và độ chính xác của lý thuyết số. Nếu như vậy thế giới sẽ thật đơn giản. Bởi vì trong thực tế, thậm chí khi có một hệ thống được thiết kế hoàn hảo và có những chương trình ứng dụng tốt thì chúng ta cũng không thể hoàn toàn yên tâm. Ngược lại, nếu chúng ta bị ảnh hưởng bởi các ứng dụng không an toàn do người khác xây dựng thì cũng không thể tin tưởng vào khả năng chúng ta đánh bại họ ở toà án. Các luật sư nhận thức rõ rằng, việc sử dụng những chứng cứ kỹ thuật, đặc biệt là những chứng cứ trên máy tính rất khó. Hầu hết thẩm phán đều có kiến thức chủ yếu về xã hội chứ không phải về kỹ thuật. Hãy xét vụ kiện giữa R và Munden. Một cảnh sát trở về sau kỳ nghỉ thấy tài khoản ngân hàng của anh ta mất hết tiền. Anh ta yêu cầu kiểm tra thì thấy có ai đó đã rút 6 lần với tổng số tiền là 460 USD và đã phàn nàn với ngân hàng. Đáp lại, Munden bị ngân hàng kiện là đã dối trá. Quá trình xét xử cho thấy hệ thống thông tin của ngân hàng hoạt động với nhiều sai sót: không có hệ thống quản lý bảo mật hay chức năng quản lý chất lượng. Phương châm phát triển phần mềm là “sai đâu sửa đấy“ và mã chương trình thường thay đổi 2 lần một tuần; Không có kiểm định độc lập, người quản lý đưa ra những bằng chứng kỹ thuật chính là người thiết kế và xây dựng ra hệ thống cách đây 20 năm và vẫn vận hành hệ thống đó; Những giao dịch nghi ngờ không bao giờ được nghiên cứu một cách nghiêm chỉnh. Họ chỉ quan sát trên nhật ký của máy chủ và không tìm thấy bất cứ cái gì sai sót. Nhưng thật đáng kinh ngạc là sau khi tất cả mọi chuyện được đưa ra ánh sáng, người cảnh sát vẫn bị tuyên bố là có tội. Một cách khái quát, khi áp dụng công nghệ mới, một vài vụ kiện đầu tiên thường bị kết luận sai. Đặc biệt, trong lĩnh vực tội phạm tài chính, do sự hạn chế kiến thức về lĩnh vực CNTT của hội đồng xét xử. Bởi vậy, người ta thường bàn cãi xem có nên thành lập hội đồng xét xử đặc biệt gồm các chuyên gia máy tính hay không. Vấn đề cuối cùng là khi những công việc thuộc về pháp lý đã ổn định thì chúng chưa chắc đã giúp để đi đến một kết luận chung. Ví dụ ở Mỹ, việc xác định chữ ký thay đổi rất nhiều, tùy thuộc vào từng loại văn bản. Lúc cần chữ ký “tươi”, lúc chỉ cần bản fax, đôi khi lại cần thêm con dấu. Trong nhiều trường hợp rất khó để phân biệt được chúng, một số hợp đồng các chữ ký nằm ở ngay trang đầu, nhưng một số trường hợp khác thì chúng lại nằm ở mọi trang. Nguyên tắc 5: Quy định pháp luật đối với những loại bằng chứng kỹ thuật mới có thể cần nhiều năm để ổn định và không chắc đã quy về một số tiêu chí nhất quán.
Xây dựng pháp luật để trợ giúp xét xử các vấn đề về tin học
Ví dụ được xem xét là vụ án giữa R với Gold & Schifreen (Anh). Hai kẻ tấn công mạng đã phá hoại dịch vụ thư điện tử của hãng British Telecom bằng cách gửi các thông báo “from British Telecom” đến cho những người không ưa, để thông báo về việc trúng thưởng. Ban đầu hai hacker này đã bị kết án, tuy nhiên họ lại được trả tự do sau khi xử lại. Điều này được đưa tin trên báo chí, được gọi là Bản hiến chương về tấn công mạng, gây lo ngại trong Quốc hội Anh và đã dẫn đến việc ra đời của Luật về Tội phạm máy tính (Computer Misuse Act). Luật này đã xác định, tấn công mạng là một loại tội phạm đặc biệt và quy định một số chi phí kiểm soát truy cập chuyển từ chủ sở hữu hệ thống sang cơ quan quản lý là Crown Prosecution Service. Nguyên tắc 6: Quá trình xây dựng các điều luật dành cho các vấn đề bảo mật máy tính thường bị ảnh hưởng của quy tắc Murphy (những kết quả không mong đợi thường xảy ra). Các chính phủ thường thử xây dựng một hệ thống các tiêu chuẩn bảo mật. Thông thường, những hệ thống này được thiết kế để tìm ra những thuận lợi về mặt pháp lý cho những hệ thống có sử dụng một số kỹ thuật đặc biệt. Ví dụ, để thúc đẩy việc ứng dụng CREST (hệ thống mua bán cổ phiếu mới của Bank of England), người ta đã đề xuất sửa đổi luật pháp của nước Anh để chấp nhận sự tồn tại các chữ ký số. Tình huống có thể trở lên phức tạp khi các tiêu chuẩn được thông báo chính thức mà lại có sai sót hoặc mâu thuẫn với những chuẩn khác. Điều này đã xảy ra với X509, tranh cãi về ISO 11166 hay tranh cãi về tính bảo mật của RSA và DSA. Trong nhiều trường hợp, các tiêu chuẩn được sử dụng trong cuộc chiến tranh giành thị trường. Một chuẩn nào xuất hiện an toàn, hoạt động tốt hôm nay có thể trở thành chủ đề gây nhiều thách thức trong vài năm sau. Nguyên tắc 7: Không nên dựa vào các chuẩn công nghệ để giải quyết những vấn đề pháp lý. Mặc dù toà án thường tin tưởng vào thực tiễn công nghệ khi quyết định một trong hai đương sự là vô ý gây ra lỗi, khi này những chuẩn bảo mật máy tính hiện có không giúp giải quyết được vấn đề. Phần lớn thời gian, người quản lý hệ thống phải làm việc với những tính năng ở mức hệ điều hành, trong khi bản thân thực tiễn công nghệ có khuynh hướng được diễn đạt chi tiết trong ứng dụng, chính là nơi các vấn đề bảo mật xuất hiện. Trong một vụ tranh chấp pháp lý, khi có xung đột giữa các chuyên gia, toà án có khuynh hướng không để ý đến ý kiến của chuyên gia từ cả 2 phía và quyết định vụ án dựa trên những bằng chứng khác, mà những bằng chứng này sẽ được diễn giải bằng phương pháp thông thường. Nguyên tắc 8: Các mục tiêu và giả định bảo mật nên dựa trên thông lệ thực tiễn trong từng lĩnh vực của ứng dụng chứ không nên dựa trên những khái niệm máy tính mang tính khái quát.
Trách nhiệm và bảo hiểm
Ở những phần trên đã cho thấy, việc quản lý nghĩa vụ pháp lý của hệ thống bảo mật máy tính vượt khỏi tầm kiểm soát của các doanh nghiệp. Khi đó, có thể chuyển vấn đề bảo mật tới các chuyên gia – các công ty bảo hiểm. Khi các công ty bảo hiểm có nhận thức đầy đủ hơn về bảo mật hệ thống, họ sẽ có nhiều ý tưởng trong việc thiết lập các chuẩn bảo mật. Sự chứng nhận dựa vào bảo hiểm không có nghĩa là làm cho hệ thống đạt mức độ bảo mật cao hơn mà là tìm ra một hoặc nhiều mức độ bảo hiểm mà công ty bảo hiểm vẫn có thể thu được lợi nhuận.Việc bảo vệ phải có chi phí hợp lý để có thể bán được bảo hiểm và vừa đủ để giữ mức tiền bảo hiểm trong tầm kiểm soát. Bảo mật dựa trên bảo hiểm sẽ mang lại nhiều lợi ích khác, ví như việc phân xử những tranh cãi giữa hai đối tác sẽ được giải quyết giữa công ty bảo hiểm của các đối tác này, nhờ đó tiết kiệm chi phí tại tòa án. Việc tiếp cận dựa trên trách nhiệm cũng có thể trả lời cho những câu hỏi về sự tin cậy. Hiện tại, định nghĩa của bộ Quốc phòng Hoa Kỳ phát biểu rằng, một thành phần tin cậy là thành phần nếu bị hỏng có thể làm lộ bí mật hệ thống. Còn Needham lại định nghĩa: một thành phần tin cậy là thành phần mà người chủ sở hữu hệ thống bảo đảm sự tin cậy của thành phần này đối với nhân viên (nếu thành phần hỏng và bảo mật hệ thống bị ảnh hưởng, nhân viên không bị quy trách nhiệm). Tất nhiên, trên quan điểm về trách nhiệm, một thành phần có thể được tin cậy là thành phần mà khi bi hỏng hóc và gây hại cho bảo mật hệ thống thì người sở hữu không bị mất một khoản tiền không thể dự báo. Điều này có thể được phát biểu như sau: Nguyên tắc 9: Một thành phần hay một hệ thống đáng tin cậy là một thành phần (hệ thống) mà bạn có thể được bảo hiểm.
ThS.Nguyễn Anh Tuấn – Viettinbank (lược dịch)
