Báo cáo hàng quý được xuất bản bởi nền tảng bảo mật và ứng dụng tích hợp tường dành sự quan tâm chi tiết đến mối lo ngại bảo mật ít được thảo luận nhưng quan trọng đối với các công ty fintech – API của họ. Các báo cáo được phát triển từ các nguồn có sẵn công khai.
Đồng sáng lập và CEO của Wallarm Ivan Novikov cho biết mục tiêu của ông đối với các báo cáo là ước tính phạm vi của các mối đe dọa và nhóm chúng thành các phần hợp lý. Điều này giúp CISO và các nhà quản lý an ninh mạng đo lường các mối nguy hiểm và xây dựng mô hình rủi ro. Mỗi quý, nhóm Wallarm phân tích mọi sự cố có sẵn, kết hợp nó với thông tin bổ sung và làm phong phú thêm nó.
Novikov cho biết trọng tâm tạo ra phân tích thời gian thực với những hiểu biết sâu sắc hơn so với các báo cáo khác được xuất bản ít thường xuyên hơn. Nó cũng xác định một số nhóm mối đe dọa mới có thể là do việc sử dụng API ngày càng phổ biến.
Rò rỉ từ API là mối đe dọa mới nổi
Cho đến nay, tiêm thuốc là vấn đề hàng đầu trong quý. 59 lần xuất hiện đã biết của chúng chiếm 25% trong số 239 hành động được theo dõi. Việc tiêm xảy ra khi ai đó gửi các lệnh API nguy hiểm thông qua trường nhập của người dùng. Lỗi xác thực đứng thứ hai với 37 lỗi. Điều này liên quan đến lỗi xác minh danh tính. Các vấn đề liên địa điểm đứng thứ ba với 30.
Rò rỉ API chiếm hơn 10% sự cố. Họ đã tấn công Netflix, các nhà cung cấp phần mềm nguồn mở và các công ty phần mềm doanh nghiệp. Novikov cho biết rò rỉ API là một vấn đề được phát hiện gần đây.
Có hai loại API và một loại đặc biệt ảnh hưởng đến fintech: API mở cho ngân hàng. Novikov cho biết các tổ chức quan tâm đến hai điều, điều đầu tiên là theo dõi dữ liệu tài chính của họ di chuyển đến đâu. Điều này bao gồm thông tin nhận dạng cá nhân và thông tin tài khoản ngân hàng nội bộ. Họ cần biết liệu nó có bị hút đi đâu đó không.
Novikov nói: “Nếu bạn nhận thấy rằng các số tài khoản ngân hàng nội bộ được kết nối dưới dạng số định tuyến, (tội phạm) có thể làm nhiều việc. “Họ có thể chạy các lược đồ lừa đảo hoàn toàn khác nhau. Nếu bạn nhớ những bộ phim có James Bond, họ sẽ nói, ‘Tôi biết số tài khoản của bạn ở Thụy Sĩ’, điều đó cũng giống hệt như vậy.”
Những phần dữ liệu này có thể là quyền truy cập riêng tư khi nói chuyện với API của bạn. Chúng có thể là chứng chỉ bạn cấp cho ngân hàng đối tác đã bị xâm phạm. Mọi bên mà bạn chia sẻ khóa đều chịu trách nhiệm về khóa đó, nhưng bạn chịu trách nhiệm về dữ liệu mở.
Mặc dù các ngân hàng có nhiều cách truy đòi để tự bảo vệ mình nếu mật khẩu và thông tin đăng nhập bị xâm phạm, Novikov cho biết API có một khóa và chỉ có một khóa đó. Một ngân hàng chấp nhận nó và bạn là đối tác.
“Đó là lý do tại sao chúng tôi đang xây dựng các giải pháp để giải quyết vấn đề này vì vấn đề này rất lớn”.
Cơ sở hạ tầng cũ kỹ làm vấn đề trở nên trầm trọng hơn
Thời đại của nhiều API ngân hàng làm tăng thêm thách thức. Với những cái cũ hơn, việc tìm ra người đã xác định khóa sẽ khó hơn. Nó ở đâu đó trong mã. Novikov đã thấy các ví dụ trong COBOL từ năm 1998.
“Nó nằm ở đâu đó trong mã và bạn có thể trích xuất nó từ đó,” Novikov nói. “Đó là một chiếc chìa khóa mã hóa cứng được ai đó đặt vào đó. Kết nối với XML và bạn đã sẵn sàng. Và bây giờ chúng tôi đặt một cổng API ưa thích lên trên đó và đặt tên là ngân hàng mở. Nó mở, nhưng nó mở từ một góc độ khác. Nó được khoan rất nhiều lỗ.”
Giám sát đối tác của bạn
Với rủi ro lớn, các tổ chức tài chính có trách nhiệm phải đảm bảo họ có thể tin tưởng vào đối tác của mình. Novikov cho biết các ngân hàng sẽ cảm thấy thoải mái hơn khi có thể xác định các tiêu chuẩn mà nhà cung cấp dữ liệu của họ phải tuân theo.
Nó lỏng lẻo hơn một chút đối với fintech. Novikov khuyến khích họ đặt ra các tiêu chuẩn của mình. Chia sẻ khóa với người hỗ trợ fintech và họ chịu trách nhiệm về việc đó.
Novikov nói: “Là một công ty fintech, họ không bị quản lý như một ngân hàng. “Họ nên làm điều đó cho chính họ. Trong trường hợp này, họ dựa vào (ngân hàng) và nên dựa vào chính mình. Đó là một vấn đề lớn vì nếu tôi muốn kết nối Robinhood với ngân hàng của mình, tôi không có lựa chọn nào khác.”
Không có tiêu chuẩn ngành, fintech có thể quyết định sử dụng mức độ bảo mật như thế nào. Và khi toàn bộ hoạt động kinh doanh của bạn tập trung vào API, khả năng bảo mật đó sẽ tốt hơn.
Phó Giám đốc Tiếp thị Girish Bhat cho biết Wallarm đang xây dựng một nền tảng gốc đám mây cũng có thể được sử dụng tại chỗ. Nó có thể phát hiện các cuộc tấn công trong thời gian gần như thực. Nó có thể cung cấp các đề xuất sửa chữa và khả năng khắc phục bằng cách làm việc với các công cụ khác trong hệ sinh thái fintech.
Bhat cho biết: “Có hàng tỷ lệnh gọi API đang diễn ra. “Chúng tôi có thể phân tích điều đó trong thời gian thực và cung cấp khả năng chủ động để giảm thiểu chúng.”
Các vấn đề về thông tin xác thực và mật mã yếu là những nguyên nhân đáng ngạc nhiên lọt vào danh sách 10 vấn đề hàng đầu. Novikov cho biết nhiều hãng sử dụng khóa tiêu chuẩn và khóa mặc định.
Ông nói: “Mọi người đều thấy rõ rằng bạn không nên sử dụng khóa tiêu chuẩn hoặc khóa mặc định, nhưng điều này vẫn xảy ra ngày càng nhiều. “Thật không may, vì lý do nào đó, chúng tôi vẫn không thể loại bỏ ngành này.”
ChatGPT đã giúp phát triển hệ thống AAA của Wallarm như thế nào
Wallarm đã sử dụng ChatGPT để giúp sắp xếp các mối đe dọa vào hệ thống AAA (xác thực, ủy quyền và kiểm soát truy cập). Xác thực là tuyến phòng thủ đầu tiên. Bằng cách cô lập nó, Wallarm có thể tập trung vào các lỗ hổng chuyên khai thác các lỗ hổng xác thực.
Khi ủy quyền được tách biệt khỏi xác thực, nó sẽ giúp xác định khi nào hệ thống cấp các quyền không cần thiết. Kiểm soát truy cập xem xét các yếu tố như thiết bị, địa chỉ IP và thời gian trong ngày. Nó giúp loại bỏ những sai sót trong cơ chế thực thi.
Novikov cho biết: “Chúng tôi có thể tập trung vào API ngân hàng hoặc ứng dụng ngân hàng để kiểm tra cụ thể xem người quản lý có thể làm điều gì đó ngoài các đặc quyền thiết kế hay không”. “Và chúng tôi nhận thấy rằng các ứng dụng doanh nghiệp khó có thể vượt qua các biện pháp kiểm soát bảo mật, máy quét và bất cứ thứ gì chúng có.
“Tuy nhiên, tương đối dễ mắc một số sai sót trong kiểm soát truy cập vì kiểm soát truy cập thường chỉ được quản lý; nó không phải là một phần của mã. Nó sẽ cho phép chúng tôi không chỉ nhấp vào hộp kiểm trong khi chạy trong một số ứng dụng hoặc API tuân thủ và kiểm tra. Kiểm soát truy cập kém thì khác - bạn phải kiểm tra riêng.”
