Финтех и банкиране
Тестване, съобразено с финтех и банкиране.
Плащанията, отвореното банкиране и дигиталното банкиране се движат бързо и привличат най-способните нападатели. Тестваме така, както биха го правили те, и покрай това ви помагаме да докажете тестването по DORA и PCI DSS.
Защо има значение
Защо финтехът е приоритетна цел
Във финансовите услуги дефектът в сигурността може пряко да засегне пари и клиентски данни. Липсваща проверка на правата в платежно API може да позволи неправомерен превод, слабост в регистрацията — масово създаване на акаунти за измами, а несигурна интеграция — достъп до данните на множество клиенти. Последствията са трудни за ограничаване и могат да засегнат отношенията с регулатори, картови организации и партньори. Ръководството се нуждае от проверена картина на тези рискове.
Отвореното банкиране, вградените финансови услуги, облачните платформи и външните доставчици на ИКТ разширяват зависимостите и границите на доверие. Тестването показва къде защитните мерки не издържат на реалистична атака, кои рискове са съществени и какво е отстранено. Документираме резултатите във вид, подходящ за одит, надзорен преглед и проверка от партньор.
Картина на заплахите
Как нападателите се целят във финансовите платформи
Превземане на акаунт отвъд входа
Атакуващите свързват credential stuffing, прихващане на еднократни кодове чрез подмяна на SIM карта и слабо обвързване с устройството, за да превземат акаунти, след което добавят получатели или вдигат лимити. Дефектите често са в допълнителното удостоверяване, което защитава входа, но не и високорисковите действия след него.
Препратки към обекти в банковите API
Мобилните и партньорските API често се доверяват на идентификатор на сметка, карта или транзакция, подаден от клиента. Промяната на тази стойност може да изложи извлеченията на друг клиент или да задейства действия от негово име. Среща се често, защото оторизацията се налага непоследователно между микроуслугите.
Злоупотреба със съгласия и доверие към трети страни
Потоците в open banking предоставят делегиран достъп на трети страни чрез OAuth съгласия, пренасочвания и дълготрайни токени. Слабата проверка на адреса за пренасочване, прекалено широките обхвати или съгласия, които никога не изтичат, позволяват на нападател или на компрометиран доставчик да запази достъп далеч отвъд одобреното от клиента.
Състезателни условия при движението на пари
Преводите, възстановяванията, обмяната на валута и бонусите включват многостъпково състояние, което лесно се разсинхронизира. Паралелни заявки, повторени обратни извиквания или закръгляване в мащаб могат да дублират кредити или да заобиколят лимити. Скенерите не моделират бизнес намерението, затова тези дефекти оцеляват при автоматизирано тестване и преглед на кода.
Как тестваме
Как тестваме финансови услуги
Картографиране на потоците от пари и данни
Започваме с това как се движат стойността и данните: иницииране на плащане, регистрация, издаване на карти, партньорски API и инструменти за бек офис. Тази карта определя обхвата, така че усилието да попадне върху пътищата, които нападателят би осребрил първи.
Договаряне на безопасни правила за тестване
За тестване на продукционни банкови системи предварително договаряме тестови акаунти, лимити на транзакциите, периоди за работа и условия за спиране. Координираме се с екипа за противодействие на измамите, за да ограничим риска за клиентите и да избегнем непланирано задействане на реакция при инцидент.
Тестване като мотивиран противник
Старши тестери съчетават ръчно тестване на API и бизнес логиката с удостоверена оценка на мобилни и уеб приложения, след което свързват констатациите през приложния, облачния и Active Directory слой, за да покажат докъде наистина би стигнал нападател, а не само изолирани слабости.
Доклад, съотнасяне и повторен тест
Констатациите се оценяват по бизнес въздействие, съотнасят се към контролните рамки, пред които се отчитате, и се пишат както за инженери, така и за борда. Тестваме повторно корекциите, за да можете да докажете закриването пред одитори, надзорни органи и партньори.
Регулация
Регулация и тестване
Как основните режими определят какво, кога и как тествате — представено като практична насока, а не като правно тълкуване.
На какво се съсредоточаваме
- Клиентски уеб и мобилни приложения
- API за плащания и отворено банкиране
- Вътрешни мрежи и Active Directory
- Облачни акаунти и разделяне
DORA (Регламент за цифрова оперативна устойчивост)
Изисква финансовите субекти да провеждат програма за тестване на цифровата оперативна устойчивост, включително периодично тестване на критичните ИКТ системи. Субектите, определени от техния компетентен орган, трябва да преминат и тестване за проникване, водено от заплахи (TLPT), върху реално работещи продукционни системи. Вашият компетентен орган определя обхвата и честотата.
PSD2 и задълбочено удостоверяване на клиента
Доставчиците на платежни услуги трябва да прилагат задълбочено удостоверяване на клиента, а обслужващите сметки доставчици — да предоставят сигурни интерфейси за достъп на оправомощени трети страни. Тестването следва да обхване заобикалянията на удостоверяването, логиката на изключенията, динамичното свързване, обработката на съгласия и тези интерфейси. Вашият национален компетентен орган определя очакванията към доказателствата.
PCI DSS v4.0.1
Субектите, които съхраняват, обработват или пренасят данни на картодържатели, трябва да извършват вътрешно и външно тестване за проникване поне веднъж годишно и след значима промяна, плюс тестване на сегментацията, когато тя намалява обхвата. Вашият QSA или обслужваща банка потвърждава какво се прилага за вашето ниво на валидиране.
NIS2 (където е приложимо)
Банковото дело и инфраструктурата на финансовите пазари са сектори по NIS2, но DORA обикновено има предимство при ИКТ риска. Субекти от групата извън обхвата на DORA — например технологични дъщерни дружества или такива за споделени услуги — все пак може да попаднат под национални правила по NIS2, които очакват мерките за сигурност да бъдат оценявани за ефективност.
ISO 27001 и SOC 2
Нито един от двата не предписва конкретен тест за проникване, но сертифициращите органи, одиторите и корпоративните или банковите партньори рутинно очакват независимо техническо тестване като доказателство, че контролите работят. Ясният обхват, датираният доклад и документираният повторен тест подкрепят одитните доказателства и надлежната проверка от партньори.
От нашата работа
Анонимизирани примери от практиката в този сектор
-
Банкиране
Защитено, но недовършено: приложение за транзакции с висока стойност
16 констатации и план за разделение на отговорностите
Прочетете казуса -
Финансови услуги
От достъп до един контейнер до целия слой с данни
Доказана верига на компрометиране и спешен план за 24 часа
Прочетете казуса -
Банкиране
Десетгодишната парола зад Domain Admin
Потвърдени защити и план за укрепване на Active Directory
Прочетете казуса
Кога ви е нужно
Чести ангажименти
Типични ангажименти, които финтех и банкови екипи възлагат — от едно издание до пълна симулация на противник.
Готовност и изпълнение на TLPT по DORA
Подгответе се за тестване за проникване, водено от заплахи, с преглед на пропуските в обхвата, критичните функции и организацията на контролния екип, след което проведете red team тестване, съобразено с подхода, основан на TIBER-EU, който прилага вашият компетентен орган.
Оценка на open banking API преди пускане
Преди нов интерфейс по PSD2, партньорско API или мобилно издание да влезе в експлоатация, тествайте оторизацията, потоците за съгласие, обработката на токени и ограничаването на скоростта срещу реалистични случаи на злоупотреба, с констатации, приоритизирани така, че да паснат на графика ви за пускане.
Годишен тест за проникване по PCI DSS
Вътрешно, външно тестване и тестване на сегментацията с обхват, съобразен с вашата среда с данни на картодържатели, с методология и доклад, структурирани така, че да подкрепят доказателствата, които вашият QSA или обслужваща банка преглежда при оценката.
Тест с предполагаем пробив на основната банкова система
С начало от компрометиран служебен лаптоп или акаунт на доставчик се оценява докъде би могъл да се придвижи нападател през Active Directory, облака и привилегирования достъп към платежните системи, основните регистри и средите за обработка на карти.
Често задавани въпроси
Често задавани въпроси
Можете ли да тествате продукционни платежни системи безопасно?
Да, при предварително договорени ограничения. Използваме отделни тестови акаунти, лимити на сумите, определени периоди за работа и условия за спиране. Координираме се с екипите за противодействие на измамите и за оперативна дейност. При твърде висок риск тестваме в представителна тестова среда и внимателно потвърждаваме ключови резултати в продукционната.
Извършвате ли тестване за проникване, водено от заплахи, по DORA?
Предоставяме тестване, водено от заплахи, и red team тестване, проектирани около подхода на TLPT, и можем да помогнем с подготовката на обхвата, критичните функции и организацията на контролния екип. Дали даден ангажимент се брои за TLPT и какви изисквания към тестерите се прилагат, се определя от вашия компетентен орган, затова потвърждаваме тези точки с вас при определянето на обхвата.
По какво се различава от автоматизирано сканиране?
Скенерите откриват известни неправилни конфигурации и липсващи обновления. Повечето съществени проблеми във финтеха са дефекти в оторизацията и бизнес логиката — например достигане до сметката на друг клиент или заобикаляне на лимитите за преводи. Откриването им изисква тестер, който разбира предвидения поток и съзнателно го нарушава.
Ще удовлетвори ли докладът нашия одитор или регулатор?
Докладите включват обхват, методология, датирани доказателства, оценки на риска и насоки за отстраняване и могат да съотнасят констатациите към рамки като PCI DSS, DORA или ISO 27001. Приемането в крайна сметка е решение на вашия оценител или компетентен орган, затова преглеждаме очакванията им с вас, преди тестването да започне.
Можете ли да тествате нашите доставчици — трети страни, и интеграциите с тях?
Тестваме вашите компоненти и настройки във всяка интеграция. Можем да проверим и интерфейсите на доставчика, ако той даде писмено разрешение. Резултатите могат да подкрепят контрола върху ИКТ риска от трети страни според приложимите изисквания на DORA и партньорските договори.
Регулаторното съдържание на тази страница правен съвет ли е?
Не. Това е практична насока за това как тези режими обикновено влияят върху тестването на сигурността, а не правен съвет. Потвърдете конкретните си задължения с вашия екип по съответствие, правен съветник или компетентен орган.
Относими услуги
Регулаторните бележки на тази страница са обща насока, а не правен съвет. Вашият компетентен орган, одитор или оценител определя какво се отнася за вас.
Определете обхвата на ангажимент за финтех и банкиране.
Кажете ни какво искате да защитите. Опитен специалист ще ви помогне да определите обхвата и следващите стъпки. Обикновено отговаряме в рамките на един работен ден.
Поверителност от първия разговор
Можем да подпишем вашето NDA, преди да споделите чувствителни детайли. За запитването ви се прилага политиката ни за поверителност.
Как защитаваме информацията ви · Политика за поверителност