#401 – Novas regras de segurança do BC

[Música] (00:02) Sejam todos muito bem-vindos e bem-vindas. Estamos de volta com o Segurança Legal, seu podcast de segurança da informação, Direito da Tecnologia e Tecnologia e Sociedade. Eu sou o Guilherme Goulart e aqui comigo está o meu amigo Vinícius Serafim. Tudo bem, Vinícius? Como vai? Olá, Guilherme, tudo bem? Olá aos nossos ouvintes.

(00:25) Sempre lembrando que, para nós, é fundamental a participação de todos por meio de perguntas, críticas e sugestões de tema. Vocês já sabem. Estamos lá no podcast@segurancalegal.com, também no YouTube, Mastodon, Bluesky e Instagram. Temos também, como você já sabe, a nossa campanha de financiamento coletivo no Apoia-se: apoia.se/segurancalegal.

(00:46) Nós sempre conclamamos que você, se puder, claro, apoie este projeto independente, Vinícius, e resistente. Insistimos, 401 episódios, então é sempre bom contar com o apoio de vocês. Ele também é importante para a manutenção deste podcast. Você também tem o blog da Brownpipe, então entre lá em brownpipe.com.

(01:11) br, consegue lá clicar no blog, ver as notícias mais importantes e se inscrever no mailing semanal para que você também fique atualizado. Inclusive, a notícia com base no nosso tema de hoje também está lá no mailing, Vinícius, que é justamente essa movimentação do Banco Central: novas regras de segurança do Banco Central depois de, pelo menos, dois grandes incidentes. Tivemos em julho de 2025 o incidente da CM, do qual nós falamos no episódio 396, e o mais recente agora da Cínquia, Vinícius. O ataque que teria desviado 710 milhões também com PSTI, afetou o HSBC na

(01:57) maior parte dos valores. Mas eles conseguiram recuperar, até o momento, 589 milhões, o que seria 83% do que teria sido desviado. Ou seja, uma boa quantia, um bom valor em termos proporcionais. Mas ainda assim, ficou cento e poucos milhões ali. Sim, mas 83% é um bom número.

(02:30) Não, você está sendo otimista. Eles poderiam ter falado 10% do valor. Aí sim. Seria um desastre. Você nota que, para uma quadrilha hoje, roubar 700, 710 milhões em espécie de um banco é uma tarefa, eu diria, próxima do impossível, envolvendo um risco e um planejamento completamente maiores, uma logística maior.

(02:56) E, Vinícius, antes de começarmos propriamente a falar sobre essa resolução do Banco Central, a resolução 498, que saiu na sexta-feira, na noite da sexta-feira, dia 5 de setembro. Sim, nós falamos sobre isso no episódio 396. Nós até fomos conferir na pauta e, claro, antecipamos, na verdade, uma tendência. Me parece que é uma tendência, pelo menos para quem conhece este mercado e para quem tem acompanhado a atuação do Banco Central, uma tendência meio óbvia. O que

(03:29) dissemos é que o Bacen deveria aprimorar suas práticas de segurança, principalmente exigindo, monitorando e acompanhando a segurança dessas instituições. E, dois meses depois, justamente veio essa regra, que também contou com uma entrevista coletiva dada pelo Galípolo, que falou sobre algumas questões e depois respondeu perguntas da imprensa. Inclusive, também fizemos um resumo dessa entrevista que ele deu, e está lá no nosso mailing, perdão, no nosso blog.

(04:05) E fica aquela sensação de que, de fato, o Banco Central se movimentou, Vinícius. Sim, sem dúvida. Acho que não teria outra resposta possível, porque se o Banco Central não fizesse um mínimo de movimento no sentido de exigir maiores controles e segurança dessas instituições, colocaria em xeque a própria confiança no sistema. E sabemos que a confiança no sistema financeiro é algo extremamente importante e conta com uma

(04:40) série de proteções. E o que não falta, e nós chegamos a comentar no nosso episódio 396, é gente para dizer bobagem, para dizer que o sistema financeiro é ruim. Não falta esse tipo de coisa. Então, é mais uma ação afirmativa no sentido de garantir a segurança do sistema financeiro, desse mecanismo todo que envolve centenas, milhares de instituições que estão vinculadas numa grande rede. E nessa rede

(05:14) temos nada mais, nada menos do que dinheiro sendo transferido. Ou seja, em vez de ter que explodir um carro-forte como acontecia alguns anos atrás (talvez ainda aconteça), em vez de ter que fechar uma cidade inteira e tentar roubar uma agência de um banco, hoje o que se precisa é de acesso à rede do Sistema Financeiro Nacional

(05:40) e interagir com o Pix, que é o meio preferido. É quase como dinheiro em espécie circulando ali. Então, nada mais natural do que o Banco Central reforçar – eu não digo tanto criar novas coisas, Guilherme Goulart, pelo que nos pareceu – mas reforçar coisas que nós já tínhamos em outras resoluções, em outros regulamentos. Sim, sem dúvida.

(06:06) Quando olhamos para a ISO 27002, por exemplo, e também para algumas resoluções e regras do Banco Central, ela meio que consolida isso. Não tem nada de muito novo aqui. Tem algumas regrinhas que vemos que foram feitas exatamente para o caso da CM, por exemplo, que vamos destacar aqui.

(06:27) Algumas dessas criações ficam bem claras, mas mesmo essas inovações, que eventualmente para alguns podem parecer uma novidade, elas estão lá na ISO, por exemplo, há anos. Inclusive, são temas que, em geral, as empresas não dão muita atenção; um deles aqui que a gente vai comentar.

(06:45) Fique conosco, não vá embora. Você vai saber. Tem que segurar a audiência, Vinícius. Vamos lá. O que vamos fazer? Vamos comentar algumas das regras aqui desta resolução. Algumas não vamos falar, porque ela é de certa forma extensa, Vinícius, tem 38, 39 artigos. Então, vamos deixar de fora algumas questões como descredenciamento dos PSTIs, algumas questões sobre planos de continuidade, a tal da saída ordenada do PSTI do sistema financeiro, que seria: se você tem problemas ou ele não cumpre com as

(07:16) regras, ele não para de prestar o serviço imediatamente, porque, claro, você vai ter outras instituições utilizando aquele serviço. E também uma questão que eles até investiram um certo tempo ali de regulação, que é a gestão de crises operacionais, que é um elemento mais, eu diria, de alto nível e que toca até nessa questão da confiança que você comentou. Ou seja, é papel do ente regulador aqui também manter a confiança no sistema. Acredito que o Banco Central tem conseguido fazer isso e

(07:47) demonstra mais essa atuação dele nesta regra. Bom, eles estabeleceram agora também novos requisitos de credenciamento, e muitos desses requisitos estão relacionados, por incrível que pareça, a aspectos da segurança, não somente técnica, mas organizacional. Aquilo que a LGPD fala, mas outras normas de segurança também falam. O Vinícius, inclusive, tem um artigo já bem antigo, Vinícius, em que você coloca aquele que fala sobre a política,

(08:26) mecanismo e cultura. Ah, sim. Como tripé da segurança e tudo mais. Isso aparece bem aqui. Isso aí é de 2000, inclusive. Foi escrito a primeira vez que está num artigo publicado mesmo, foi numa jornada que eu, André Perez, Rafael Campelo, acho que nós três, não estou esquecendo, o Herman acho que também, escrevemos para um congresso da Sociedade Brasileira de Computação que aconteceu em Floripa. Estamos falando de 2000, 2001,

(09:01) há bastante tempo, lá se vão 25 anos. Mas é interessante, porque isso é mais teoria da segurança da informação. O que eles estão atacando aqui? Primeira definição de diretorias específicas para lidar com segurança e gestão de risco. E essas diretorias devem ter uma capacitação técnica compatível com essa responsabilidade.

(09:24) E também um diretor para gestão de crises, que é esse aspecto um pouco mais organizacional mesmo. Ou seja, não é só você responder ao incidente, não é só você sanar ou retornar ao ambiente em casos de incidentes que afetem a disponibilidade, mas também você conseguir publicamente lidar com essa crise. Estabeleceram questões como capital mínimo de 15 milhões, a comprovação da implantação de todo um mecanismo, de todo um arcabouço aqui de governança corporativa e gestão de riscos, a necessidade de se submeter à certificação de segurança de norma

(09:58) reconhecida internacionalmente ou a seguração independente aceita pelo Banco Central, além de auditoria externa anual de segurança. Anual e de segurança. Uhum. E aí, você vai ter, muito provavelmente, uma 27.001 com base nos controles da 27.

(10:18) 002 aqui como regra, norma internacionalmente conhecida, mas deixa uma abertura aqui para o Banco Central até mesmo criar regras, normas específicas. Acredito que não vai criar uma norma, mas diretrizes talvez mais específicas para isso também. Coisas assim bem básicas, eu entendo, para um PSTI que vai estar no contexto que funciona hoje, por exemplo, plano de continuidade, testes periódicos de contingência. É obrigatório, o que a gente recomenda para clientes quando faz auditoria. Isso, inclusive, já estava nas normas do Banco Central, Guilherme. É, da nuvem, sim. Da parte da

(10:48) nuvem, sim. É, dos planos de resposta a incidentes e tudo mais. E aí, sim, porque eles repetem aqui muito a política de segurança da informação e segurança cibernética, que vai trazer uma série de elementos também bem conhecidos. Quando eles começam a falar sobre governança corporativa, eles deixam claro, isso tem a ver também com gestão de riscos. Governança e gestão de riscos devem ser compatíveis com a natureza, com o porte e com a própria complexidade da instituição, o perfil de risco. E aqui uma coisa que é bem

(11:21) interessante: assegurando processos decisórios transparentes. Porque tendemos, Vinícius, e aí novamente a questão do teu artigo, a achar que “não, eu vou implantar mecanismos tecnológicos e deu”. Só que hoje, falar em governança de segurança, não só hoje, mas já há bastante tempo, envolve você conseguir tomar decisões de forma acertada, de forma ajustada, com as responsabilidades sendo devidamente segregadas, principalmente. Ou seja, eles fazem um esforço muito grande aqui. As políticas devem

(12:04) garantir segregação de funções entre gestão executiva, gerenciamento de riscos, compliance, segurança e auditoria. Ou seja, vou precisar de diretorias para cada uma dessas áreas aqui. Para quê? Justamente para evitar conflitos de interesses, Vinícius. Exatamente. Esse, Guilherme, é um problema que a gente sempre teve na segurança da informação. Aí tem dois caminhos que o Banco Central, que eu imagino, minha percepção aponta que o Banco Central quis. Um caminho no

(12:37) sentido de determinar que tu tenhas toda uma abordagem top-down para definir o que deve ser feito e garantir que vai ser feito. Então, tu tens o alinhamento que o Banco Central exige, a diretoria busca cumprir e repassa isso até que chega num ponto lá em que tu vai ter uma implementação de mecanismos, controle de navegador que o cara usa, implantação de antivírus, normas de acesso físico e outras coisas mais práticas mesmo. Por outro lado, me parece também que o

(13:21) Banco Central tem um interesse bem grande de estabelecer responsabilidades, que possam ser, vamos dizer assim, rastreadas. Porque quando acontece um incidente desses, quem determinou o quê? Como é que eu apuro a responsabilidade dentro da instituição? Porque senão fica uma coisa meio solta. “Não, isso aí, a gente viu, disse que fazia isso e aquilo, mas alguém determinou? A direção determinou ou não determinou?”

(13:56) É uma decisão tomada conscientemente pela empresa ou foi um desleixo ou foi uma omissão? Foi, foram omissos ou foi algo que a instituição decidiu não cumprir? E notem, e não adianta, e para o caso da instituição, essas novas demandas aqui só reforçam essa necessidade. Tu tendo independência, tu não tendo conflito de interesse entre esses diversos setores que tu citou, Guilherme, os avisos, as notificações, as interações entre elas vão naturalmente gerar evidências

(14:38) desses posicionamentos da empresa, seja nas direções, nas presidências. Seja uma decisão de negócio tomada lá em cima, ou seja algo que de repente, na hora de chegar lá no analista de segurança, houve uma falha ali e a coisa não foi simplesmente implementada.

(15:04) Então, me parece um pouco desses dois caminhos. O primeiro caminho é para as coisas irem bem, ou seja, as decisões sejam tomadas e elas tenham um impacto de fato nas operações da empresa. E outro caminho é para quando a coisa dá errado: saber onde esse negócio parou dentro da empresa. Os processos andaram, não andaram? Tem independência, não tem?

(15:33) As coisas foram varridas para baixo do tapete? E aí, a ausência de documentação também vai ser um problema por si. Já é um problema. Quando tu tens um incidente, tu tens que mostrar evidências de que tinhas um mínimo de controle. E se tu não tens evidência nenhuma, isso já é um baita de um problema.

(15:52) Só que eu acredito que isso aqui vai gerar ainda outro tipo de evidência: evidências de que coisas são comunicadas и não são feitas. Aí acho que é um pouquinho pior. Sim, porque a norma fala em “segregação de funções” entre essas atividades. Está escrito ali e “segregação de funções” é algo que já é falado no mundo das instituições financeiras de maneira geral há bastante tempo, não somente nessa questão de segurança, porque você tem outros riscos, por exemplo, risco de crédito e outras questões que não nos interessam, que não

(16:25) é nossa área. Mas quando você estabelece, no mínimo, que você vai ter uma diretoria de segurança de informação, separada de riscos e compliance, separada de relacionamento do Bacen e separada de gestão de crises, pelo menos tendo uma diretoria de riscos, compliance e controles internos, isso é o que vai fazer сom que a própria segurança da informação confirme para essa outra diretoria que as medidas que foram estabelecidas foram tomadas. É quase como quando você tem aquela questão dos poderes harmônicos entre si que a gente tem, dos três poderes e

(17:06) tudo mais. É quase como uma contenção, uma harmonia e um trabalho que vai fazer com que não seja possível, a não ser que uma dessas diretorias comece a mentir ou a não fazer o seu trabalho. Mas se todas elas funcionarem adequadamente, fazendo a sua parte, não tem como você ter conflitos de interesses ou processos que não sejam transparentes. Isso fica bem claro aqui. Depois, ainda seguindo, Vinícius, vai me interrompendo sempre que tu quiseres comentar, eles começam a falar

(17:40) sobre gestão de riscos. E dentro de gestão de riscos, deve ter uma política de gestão de riscos que deve abordar coisas como segurança da informação e cibernética, continuidade de negócios, gestão de crises, gestão de fraudes. Que daí é uma outra questão, lá pelas tantas eles vão começar a comentar: “Olha, você tem que começar a cuidar aqui do perfil de operações que se dão”. Que isso sim é um… porque até agora a avaliação dos perfis de operações ficava do lado do cliente do PSTI. Agora o que o Banco Central está dizendo é: “Você

(18:14) também vai ser um agente para verificar possíveis fraudes”. Ou seja, deixa bem mais complexa a atividade do PSTI. Controles internos de conformidade e auditoria interna. Claro, segurança e auditoria, compliance, gerenciamento de riscos são todas essas áreas que vão trabalhando entre si, que vão se cobrando. O que acontece se você deixa todas essas áreas em uma diretoria, por exemplo? Aí você pode ter eventuais problemas de conflitos de interesses, que é o que a norma, entre outras coisas, tenta evitar. Também fala sobre os requisitos de uma política de segurança da informação.

(18:55) Só destacando, Vinícius, até aqui não tem nada de novo. Uhum. Não tem absolutamente nada que não seja conhecido da comunidade de segurança e de quem conhece normas como a ISO 27002. Quando então fala sobre a PSI, lá no artigo 17, eles vão colocar coisas que no mínimo a política deve ter. A ISO já faz isso, mas vamos colocar: criptografia, detecção de intrusão, prevenção de vazamento, backup, avaliação de risco, avaliação de vulnerabilidades, controle de acesso, aplicação regular de

(19:28) correções de segurança (patch management), segregação de ambientes. E aqui uma novidade, talvez não bem novidade, mas uma coisa mais específica seria: isolamento físico e lógico do ambiente Pix e STR dos outros sistemas da instituição. Isso aqui está com uma carinha de ser uma regra criada lá para o caso da CM. É, isolamento físico e lógico de… bom, físico, aí vai depender de ambiente para ambiente, Guilherme. Porque muitas empresas até têm alguma coisa local, mas têm muito serviço, tudo em nuvem. É difícil falar em

(20:11) físico. Mas assim, vamos estar separando em ambientes… Eu diria que está entre o físico e o lógico, entre ambientes virtuais diferentes que seja. E essa acho que é a parte talvez mais fácil. Mas a questão mais complicada é o isolamento lógico. Uhum.

(20:39) Eu acho que quando tu falas em isolamento lógico é um pouco forte demais, porque eu entendo isolamento como isolar mesmo, particionar, não ter acesso. E, no entanto, tu precisas que vários outros sistemas interajam com esses sistemas. Então, vai haver um controle da comunicação entre sistemas. Tem que ter uma separação, uma segmentação, digamos assim, e um ponto de controle da comunicação entre esses sistemas.

(21:09) Isso é perfeito e natural que exista. Agora, um isolamento eu acho complicado. E aí caímos no nosso metiê. A gente analisa, vamos fazer um jabá para a Brown Pipe, Guilherme. A gente nunca lembra de fazer. Vai lá, vai lá. Mas aí entra na nossa metida, na parte de pentest e tudo mais que a gente faz. Tu vais ter uma aplicação, tu vais ter uma aplicação que usa uma API que se comunica com esse ambiente. E tu até podes isolar logicamente, digamos, separar logicamente, mas tu

(21:43) ainda assim vais ter que permitir algum grau de interação entre esses sistemas. E aí tu tens sistemas com certas vulnerabilidades que vão acabar expondo esse ambiente. Então, é uma cadeia de coisas, não tem. É por isso que eu acho um pouco forte essa questão de isolamento lógico, porque de fato tu não vais conseguir isolar logicamente. Vais ter que permitir algum tipo de comunicação entre eles. E aí tem todo tipo de problema aqui que acaba aparecendo.

(22:14) Mas sabe o que me chama a atenção aqui nessas regrinhas que são bem específicas? Veja, eles não nos deram as informações para o grande público do que exatamente aconteceu. Mas se você for cuidadoso e olhar essas regras, eu acho que você começa a ter umas dicas do que eventualmente pode ter acontecido, porque são regras muito específicas. É, talvez o carinha que fez os acessos para mexer no que ele mexeu e não deveria, não tivesse acesso direto aos sistemas que faziam, que

(22:44) executavam o Pix e tudo mais. E a regra de baixo: gestão de certificados também. Gestão de certificados. Isso aqui é bem interessante, porque é o velho problema do gerenciamento de chaves, no final das contas. Certificado não é o problema em si, é o gerenciamento das chaves. Mas isso aqui está com muita cara de chave que estava em e-mail, chave que estava também, acho, em alguma pasta compartilhada em algum lugar. Porque esses certificados que ficam andando para cima e para baixo, que o pessoal tem que instalar nos sistemas, cara, é seguido isso passar por

(23:24) e-mail. Seguido. “Ah, está aí o certificado, não sei quê”. E sabe o que reforça mais essa tua avaliação? Parágrafo primeiro ali do artigo 17: “O PSTI não deverá ter acesso às chaves privadas utilizadas para a assinatura das mensagens no âmbito dos arranjos e sistemas de pagamentos providos pelo Banco Central.”

(23:48) Talvez mais uma dica aí do que possa ter acontecido também. Só para quem nos ouve, para quem é da área, acho que já entendeu o problema. Agora, quem talvez não saiba muito ou não tenha uma intimidade muito grande com isso, é o seguinte: as operações têm que ser assinadas digitalmente, certo? Mas não pelo PSTI.

(24:10) O PSTI só fornece o serviço para a instituição que não se conecta diretamente na rede da STFN, do Sistema Financeiro Nacional. Então, eu uso o PSTI, só que o PSTI só faz esse meio de campo para essa comunicação. E eu, Vinícius, vamos supor que eu contrate o serviço do PSTI. Eu tenho minha chave privada lá para assinar as minhas operações, assinar as mensagens que eu quero mandar. Só que aí acontece um detalhe.

(24:43) Idealmente, eu deveria ter o meu próprio sistema, separado do sistema do PSTI, para fazer essas assinaturas dessas mensagens e encaminhar isso lá para o Banco Central. Só que, com uma certa frequência, o que a gente vê é um pacote de solução que vem o software no qual tu tens que instalar tua chave privada lá dentro, tens que botar lá dentro do sistema para ele poder assinar quando tu usas uma API para fazer determinadas operações.

(25:18) E isso, estou curioso até para saber mais detalhes nesse sentido, mas me parece que isso vai acabar tendo que virar um outro “pedaço”. Vocês vão ter que separar esses pedaços de software. Ou seja, vai ter empresas que têm os seus próprios, claro, não tem problema. Mas empresas que querem contratar PSTI para não ter muito trabalho com isso, estão acostumadas com uma solução pronta em que só largam uma chave privada lá dentro.

(25:44) Aí tem uma senha para autenticar e diz assim: “Ah, faz a operação aí para mim”. Ele faz, assina a mensagem e manda. Manda, recebe, verifica, faz o que tiver que fazer, mas a chave fica lá. E aí, de repente, tu estás a falar que o sistema do PSTI não pode ter acesso às chaves. Quando tu falas “o PSTI não pode ter acesso às chaves”, se eu estiver a usar um sistema que o próprio PSTI está a me fornecer, o PSTI tem acesso às chaves, entendes? Isso significa que o PSTI tem acesso às chaves? Aham. Ou, uhum.

(26:15) Se eu tenho uma peça de software fornecida pelo PSTI e que eu rodo na minha infraestrutura, e às vezes o PSTI nem gosta que tu olhes este sistema, mas ele está a ser específico na chave privada, Vinícius. Pois é, mas aí é que está. Eu ter um sistema, vamos supor, fornecido pelo PSTI dentro da minha infraestrutura, e olha que, via de regra, tu não podes nem mexer ali. Tu não podes mexer nesse sistema.

(26:43) Os caras nem dão detalhes, tem uma série de situações meio chatas, algumas situações que já aconteceram. Mas aí tu tens que botar a tua chave privada ali, embora esteja na tua infraestrutura. Isso significa que o PSTI tem acesso à tua chave privada, ou a intenção do Banco Central é que o sistema que assina a mensagem tem que ser outro? Entendi.

(27:13) Aí esse sistema fica com a chave privada, ele já entrega a coisa assinada para o PSTI, seja para o software, e aí o PSTI se vira e faz o que tem que fazer. Porque isso vai quebrar com muito modelo de prestação de serviço de PSTI. Mas você percebe que a exploração desse tipo de vulnerabilidade, essa questão da chave privada aqui, pode ter sido um dos vetores ou uma das vulnerabilidades que permitiram essa fraude? Não, mas eu acho que não. Não pode. Acho que com certeza. Acho não. Com certeza não dá para dizer.

(27:49) Não, as operações tiveram que ser assinadas para serem realizadas. Uhum. Elas têm que ser assinadas e têm que ser assinadas com a chave privada do lugar. Agora, o que parece aqui é que, bom, primeiro, tem isso que eu falei. Normalmente o sistema tem um software fornecido pelo PSTI, no qual tu instalas a tua chave privada. Então, se isso significa que o PSTI tem acesso à chave, bom, aí já foi.

(28:23) A falta de isolamento permitiria que o cara que fez a fraude, o funcionário que fez a fraude, e a falta de isolamento dos ambientes e tal, ele tivesse acesso direto ao serviço via aplicação do PSTI, que faz a integração lá com o PSTI. Então, me parece que é uma sequência bem plausível dentro daquilo que a gente já viu, do que a gente conhece.

(28:48) Me parece uma sequência bem plausível de situações. Tu tens o PSTI que fornece um serviço, a chave privada fica ali, tu precisas de uma credencial tua para se autenticar com o serviço do PSTI que está local na tua estrutura — não fisicamente, necessariamente, local, mas numa infraestrutura que tem acesso — e faz tal operação.

(29:10) O próprio sistema assina as operações e encaminha isso de forma automática. E, ao mesmo tempo, tens um funcionário que, por falta de isolamento adequado ou de controle de permissões, etc., conseguia chegar até esse serviço e tinha as credenciais para operar nesse serviço. E aí, feita a caca, entendes? É uma boa discussão essa aqui. É, mas é que são, na verdade, estamos aqui imaginando o que aconteceu. Mas, enfim, falamos sobre isso no 396.

(29:37) Você tem dúvida, vai lá, escuta. Outras coisas que eu acho que são aqui… essa até não, que é: ações de inteligência cibernética, monitoramento de clientes, chaves, vulnerabilidades na internet, deep web, dark web. Tem empresas que fazem, que prestam esse serviço.

(29:59) Isso se alinha bem a um controle novo, entre aspas, da 27002 de 2022, que é o controle de inteligência de ameaças, que não tinha na versão anterior, que é justamente isso. O nome é isso, inteligência de ameaças. Você começar, você ter alguma atividade, seja sua ou de um terceiro prestando, que faz essa avaliação. De certa forma, o nosso mailing tem um pouco essa função também: você ficar atualizado, ver eventuais… claro que devem ter coisas bem mais específicas.

(30:28) Você tem um ambiente X com sistemas X, Y, Z, você vai buscar vulnerabilidades, zero-days e aquelas coisas todas para você manter, acompanhar também o cenário e a evolução do cenário de risco no qual tu estás inserido. Mas aí tem umas coisas bem interessantes aqui também, que é muito uma resposta direta ao caso: a avaliação de vulnerabilidades deve envolver, e isso é bem específico, varreduras físicas periódicas para identificar dispositivos indevidamente conectados. E, aí, Vinícius, isso é bem

(30:59) interessante, porque a norma ISO fala sobre isso. Eu comentei antes, esse aspecto de segurança física não é muito valorizado pelas empresas, e nas notícias da época daquele incidente, disseram que teria sido instalado lá um “appliancezinho” ou… não se sabe se era um appliance, era um pedaço de software e tal.

(31:27) E essa regra talvez nos faça intuir, olhando para o caso concreto e tentando descobrir o que aconteceu pela regra, que pode ser, sim, que os caras tenham conseguido instalar um Raspberry, alguma coisa do gênero, lá dentro da infraestrutura. Alguém está assistindo Mr. Robot. Mas é aí que está. Percebe que esse é um recurso que se usa para pentest quando tu precisas de acesso, quando tu vais fazer isso remotamente, Guilherme? Uhum. Então, por exemplo, quando tu tens uma situação que vais fazer um pentest que envolve infraestrutura, tu

(31:55) terias que estar conectado à rede local, mas o teu cliente está distante, tu não vais até lá presencialmente fazer e tal. O que é bem normal? Tu instalares, tu pedires que o cliente forneça ou tu enviares para o cliente um equipamento que ele deve conectar na rede dele. E a partir desse equipamento, ele dá acesso, liberar lá o acesso às redes que a empresa tem para a gente conseguir usar esse equipamento como ponto de presença na rede do cliente e realizar as varreduras, as verificações que tiver que fazer, que tiver que realizar. Então, esse é um procedimento bem normal. E se tu tens um ambiente no qual talvez

(32:34) tu tenhas um usuário limitado, com acesso limitado ao que ele pode fazer no computador, não é administrador, por exemplo. Não tem acesso administrativo para instalar software, etc. Então o cara não pode instalar uma VPN, não pode fazer alguma coisa assim. O que é mais fácil do que pegar um Raspberry Pi? Caixinha pequenininha, não faz, não precisa de cooler, não precisa de nada. Tamanho de uma carteira de cigarro. Um pouquinho mais grosso. Talvez se tu

(33:00) pegares umas caixinhas, aí sim, fica menor, mais fino que uma carteira de cigarro. Não que eu saiba exatamente a espessura de uma carteira de cigarro, mas ele… tu pegas um equipamento desses e se a rede não tem segmentação, se a rede não tem uma segmentação interna, não separa os ambientes… Pelo que a gente está pressupondo aí, talvez não tenha mesmo.

(33:26) Basta que essa caixinha seja ligada, ela se conecta, a partir dali estabelece uma VPN com algum lugar na internet, não precisa nem ser diretamente com uma máquina do atacante. E a partir daí, o atacante vem e faz o acesso à infraestrutura interna. Aí faz bastante sentido. Porque se o funcionário, do que a gente viu nas matérias e tal, não era alguém conhecedor de TI, que tinha que ficar anotando comando em caderninho e não sei o quê, o cara tinha que ficar olhando os caderninhos e fazendo… olhando

(33:56) e fazendo… Imagina fazer o ataque todo dependendo desse cara. Então, me parece bem interessante. Me parece bem interessante colocar, mandar um equipamento: “ó, liga aí na rede, já que não tem separação nenhuma, liga aí que daí eu consigo acessar direto essas coisas e fazer o que tenho que fazer. Aí só me arranja as senhas”.

(34:15) É muito interessante. Deixa eu te ler uma outra. Eu vou te ler uma outra aqui, que é sobre controle de acesso também. Revisão periódica de permissões, OK. Especialmente de colaboradores terceirizados. É mais uma vez uma regrinha específica para o caso da CM. Outra resposta direta aqui. E aí, utilizar múltiplos fatores de autenticação para o acesso administrativo dos sistemas que envolvem a atuação direta no Pix e no STR. Aqui parece mais um reforço, mas, assim, eu não consigo imaginar você não ter múltiplos fatores de autenticação para acesso ao STR, por

(34:52) exemplo, ou acesso ao Pix que te permitissem simular ou falsificar ali transações. Porque me parece que foi isso que aconteceu também. Outra coisa, Vinícius: proteção de rede, além de firewall, claro. Definição de critérios especiais de monitoramento, em especial em horário noturno ou não convencional. Mais uma resposta direta ao caso, que parece que se deu de madrugada e tal.

(35:20) E também monitoramentos de eventos atípicos, como abertura de VPNs, tentativas de acesso privilegiado em horários especiais. Ficou bem marcada aqui a questão do horário especial também. E o parágrafo sexto ainda desse artigo 17: a gestão de certificados envolvendo o monitoramento de uso e guarda dos certificados.

(35:39) Mais uma vez a preocupação que a gente colocou aqui também. Tá, Guilherme, eu tô com a tua… Mostra aí a imagem pronta aqui. Só deixa eu… parei que eu, sem querer, cortei a faixa aqui do The Register para aparecer a fonte, cara. Tem que aparecer a fonte pro nosso… Não, isso aqui eu procurei aleatoriamente quando a gente falava aqui, um “Raspberry Pi Cigarette Case”. E, de fato, tem ali, mas isso aqui acho que o cara… isso aqui é de 2012. Mas a ideia… Opa, não.

(36:10) Ih, opa, entrou o vídeo da… Não, para aí, é que tem o… eu estava… se tivesse me avisado antes. Mas aqui, aqui. Pronto, pronto. Está aí. Vai lá. Aí, ó. Mas é uma boa ideia, cara. Não, dentro de uma carteira de cigarro de verdade, que aquilo ali é papelão. É claro, mas, assim, dá tranquilamente para colocar. É interessante. É isso.

(36:35) É segurança física, e aquela história: só vai chamar a atenção essa tralha em cima de uma mesa com cabo de rede saindo dela. Tudo bem que se tiver Wi-Fi, tu só precisas de um… ainda assim, precisas de um cabinho aí para manter funcionando, mas pões uma bateria escondida junto.

(36:52) É, isso é de 2012. 15 anos já. Bom, aí depois tem aqui também coisas bem interessantes sobre a PSI aqui e outras regras, outras questões aqui que a PSI deve tratar lá no artigo 17 também, que é a certificação técnica das soluções de tecnologia da informação utilizadas pelas instituições e outras instituições supervisionadas pelo Banco Central para integrar por meio das interfaces eletrônicas.

(37:25) Eu acho que ele deve estar querendo se referir às APIs aqui com serviços providos pelo PSTI. Ou seja, o que me parece que essa regra coloca, e eu acho que ela vai precisar de uma regulamentação adicional e posterior para dizer como que essa certificação técnica vai se dar, é que o que parece estar sendo dito aqui — lembrando, esta é uma regra que saiu sexta-feira passada, a gente leu, deu uma estudada nela, mas admitem-se aqui outras interpretações mais refletidas —, mas, enfim, o que se está dizendo aqui é que os sistemas que forem se conectar por meio de APIs aos serviços dos PSTIs

(38:02) também devem ser certificados. E aí, isso vai colocar todo mundo que utilizava os serviços do PSTI pela facilidade, pela simplicidade, claro. Você usa o serviço de PSTI para não ter que se conectar diretamente à rede do SFN. Você vai ter aqui obrigações adicionais de certificar as tuas soluções que vão ser conectadas com ele. Por exemplo: a certificação técnica de que trata este artigo deve considerar, no mínimo, a definição e a execução periódicas de testes destinados a certificar que os sistemas computacionais utilizados pelas

(38:38) instituições financeiras e demais instituições supervisionadas do Banco Central para integrar, por meio das interfaces, as APIs, os serviços providos pelo PSTI, estão em conformidade com os requisitos operacionais e de segurança estabelecidos. Eles deram um passo para além do PSTI, indo nos contratantes dos serviços de PSTI, mas ainda não está claro como que isso vai ser feito, como é que o Banco Central vai certificar as aplicações dos clientes dos PSTIs. E isso vai atingir muita gente aqui, Vinícius, se por

(39:17) isso, exatamente. Essa interpretação que a gente está colocando vai atingir muita gente. Cara, aqui me parece que a maneira mais simples é o Banco Central dizendo que essas aplicações têm que passar por um pentest da Brown Pipe. Quer dizer, eles não citaram especificamente. Sim, não, mas, em essência, quer dizer que essas aplicações têm que ser testadas, cara, e têm que ser testadas regularmente.

(39:42) Então, para quem é da área de segurança, é uma coisa meio óbvia. Aplicações têm problemas de segurança, aplicações acabam eventualmente tendo erros de codificação, um erro de projeto ali, um mecanismo mal implementado ou mal definido, às vezes bem definido, e aí ocorre um erro na implementação. Então, a gente tem várias situações aí que colocam esses sistemas em risco, e são sistemas, vamos dizer assim, bastante críticos, porque dão um prejuízo diretamente em grana, em valor.

(40:21) Mas a gente tem uma série de situações que não apenas envolvem o sistema financeiro. Sistemas ligados à saúde, hospitais, etc. Quem já viu, por exemplo, quem já esteve perto de algum sistema hospitalar, já acompanhou, e principalmente aqueles sistemas antigos para caramba que estão rodando há 30 anos no hospital e o hospital не substitui, não altera, porque equipamento tal não é compatível e não sei o quê, aquela coisa toda. Legados ali. Sim, sistemas têm problemas. Então, o

(40:57) Banco Central, eu não vou dizer que se enganou… se, hipoteticamente, o Banco Central acreditou que garantir a segurança da rede do sistema financeiro nacional e das empresas imediatamente conectadas, se cuidar desse entorno era suficiente… Se eles pensaram isso, se enganaram redondamente. Porque, obviamente, eu tenho várias outras peças de software que não fazem parte desse pequeno círculo, digamos assim, e que interagem, ainda que de forma indireta, com esse sistema. E essas peças de software, elas

(41:39) obviamente… “ah, mas ela não pode agir diretamente porque ela passa por uma PSI”. Sim, mas a partir do momento que tu confias no que esses softwares fazem, e tu tens que confiar no que eles estão fazendo, na forma como eles estão implementados, tu vais executar as ordens que eles mandarem. Desde que, claro, se encaixe no protocolo e aquela coisa toda, nos limites, tudo mais, mas vai executar. E o que se descobriu é que a gente tem problema para fora disso. Estamos tendo problemas, temos PSTIs com problemas que já

(42:10) estão ligados diretamente à rede, e o pessoal está se dando conta de que не adianta cuidar só do que está ligado direto na rede, porque o PSTI tem que confiar em peças de software que estão, em artefatos e tudo mais, que estão depois dele. E agora, o Banco Central está se mexendo para demandar um controle também dessas coisas que entram em contato por meio do PSTI com o sistema financeiro nacional.

(42:40) Então, me parece assim… sabe quando saiu o Pix e aí o pessoal começou a fazer aquelas consultas malucas lá no diretório de chaves? É, no diretório. Aham. Isso. Aí o Banco Central se deu conta de que tinha que botar um limite nisso. E assim aconteceu. E eu acho que agora nós estamos vendo um outro tipo de limite aí sendo imposto, porque realmente não dá para simplesmente confiar em qualquer artefato de software que está vinculado.

(43:05) É, mas a mudança aqui, me parece, não, a mudança é: o Banco Central deu um passo para além dos PSTIs. Isso, exatamente. Então, todo mundo que usa PSTI agora vai ter que… Isso não ficou claro agora, isso não ficou claro na entrevista que o Galípolo deu. Eu acho até que ele disse uma frase lá que a gente até replicou no nosso mailing ali, mas, assim, os contratantes têm novas obrigações. E isso é, para mim, um ponto de virada bem importante. Sabe, quase como se fosse assim: “Ah, não, eu uso PSTI, o problema de segurança é lá do PSTI”. E, claro,

(43:49) acho que ninguém pensou isso exatamente assim. Mas, na perspectiva do Banco Central agora, você também responderá para o Banco Central. Você, contratante do PSTI. Depois tem plano de resposta a incidentes aqui, que é uma questão aí também nada de novo.

(44:09) Claro, o plano deve ser compatível com o perfil de risco e deve ser testado e atualizado. E isso também não é novo, mas, assim, nem sempre isso vai ser bem observado pelas instituições. Política para gestão de fraudes. Isso aqui também é uma questão interessante. Ou seja, a partir de agora, os PSTIs vão ter que também realizar atividades de gestão de fraude com base em padrões históricos e comportamentais.

(44:38) O PSTI passa a ser uma parte ativa na gestão de fraude que antes estava lá do lado do contratante do PSTI. Ou seja, era um papel do contratante verificar se um dos clientes dele não está fazendo operações atípicas. Passava para o PSTI assinado, o PSTI jogava aquela operação lá para dentro do SPB. Agora, caso fosse o Pix. Mas o interessante é que agora o PSTI vai ter que… ou seja, muda o papel do PSTI no âmbito da gestão de fraudes. Padrões históricos e comportamentais. E isso, meu amigo, envolve um caminhão de dados

(45:21) pessoais também sendo tratados aqui. Ou seja, se isso passava talvez sem um tratamento outro aqui, agora os PSTIs também vão ter que começar a tratar esses dados que, em última análise, podem envolver dados pessoais aí. Depois, políticas de controles internos. Ou seja, qual é a ideia do controle interno? Você ter internamente um grupo e uma diretoria e pessoas dentro dos PSTIs também para garantir que as medidas de segurança implementadas por outras diretorias e pela avaliação de risco e tudo mais estão sendo

(45:57) realizadas. Com o destaque de que a política de auditoria interna, seja a política de controles internos e de auditoria interna, devem promover a segregação das funções e das responsabilidades das unidades de negócios com os controles e com os órgãos de gestão de risco, controles internos e conformidade.

(46:23) Esse é um ponto que nós já conhecemos e falamos sobre isso há bastante tempo. E agora fica mais claro do que nunca para os PSTIs. Mas outra coisa, Vinícius: agora é PSTI, eu acredito que isso vai se ampliar mais ainda. Isso já está se capilarizando para os clientes dos PSTIs. Claro que o PSTI é, de fato, o ente mais sensível aqui, mas isso vai se capilarizar também para outras instituições.

(46:52) É uma demonstração que o Banco Central está dando aqui, me parece. Depois, aí, obrigações adicionais de informações que eles devem dar para o Banco Central. Ou seja, incidentes operacionais que afetem os atributos da segurança da informação ou que possam afetar os serviços devem ser imediatamente comunicados

(47:17) claro, após a ciência. Ou seja, após a ciência, devem ser imediatamente comunicados e, em 10 dias, tem que entregar um relatório técnico. Ou seja, eles vão ter que estar muito bem preparados para entregar essas informações em 10 dias, que é um prazo exíguo. Depois, também precisam… diga, Vinícius. Não, mas nota que a notificação de que houve é imediata. É, depois da ciência, não tem.

(47:41) É depois da ciência, mas, assim, uma vez que se tem ciência de que há um ataque, ela é imediata, ela não tem prazo. É de imediato, e tem 10 dias para fazer um relatório. A gente já falou sobre isso. Um relatório preliminar, acho que é bem preliminar assim, um relatório sujeito a correções, é possível entregar em 10 dias. Um relatório final sobre o que aconteceu, dependendo da situação, não vai ser possível em 10 dias.

(48:14) Mas, enfim, tem outras comunicações que eles devem fazer: alterações de arquitetura, entregar relatórios anuais de auditoria, das auditorias internas e externas. Mais uma questão aí de segregação também, por empresa registrada na CVM, a externa. Seja mais um critério adicional aí dessa auditoria.

(48:45) Mas o Banco Central também passa, eles passam a prever algumas medidas cautelares. Sejam medidas cautelares em incidentes que possam afetar o funcionamento do sistema de pagamentos, ou aqueles que não têm causa raiz identificada ou comprovação de resolução definitiva. Ou seja, não é só você ter o incidente, comunicar e depois entregar o relatório, porque o Banco Central pode ficar em cima e, se for o caso, ele pode intervir ali com uma medida cautelar, se não ficar exatamente claro que se identificou, por exemplo, a causa raiz,

(49:16) ou seja, o que deu causa, e qual foi a medida de resolução definitiva. Resolução definitiva, tem que ter um certo cuidado aqui, porque a gente fala em gestão de risco. Às vezes você pode, eventualmente, até conviver com uma fonte de risco e tudo mais, mitigar. Resolução definitiva, às vezes, pode ser, em segurança, um pouco complexo, mas enfim.

(49:42) E também eles podem aplicar limites operacionais de valores e tal, suspender serviços, exigir auditoria extraordinária, planos de ações corretivos, restringir contratação de novos clientes ou, no pior caso, executar o plano de saída ordenada. O seguinte: você vai sair, o Banco Central dizendo “saia do SPB de forma ordenada”. E também, e este também é um grande ponto de virada aqui, no artigo 35, que as instituições contratantes também vão cumprir, além daquilo que a gente falou antes, elas, e isso me chamou bastante atenção, Vinícius, as instituições

(50:22) contratantes dos PSTIs vão ter que garantir ou assegurar que os contratos contenham as regras desta resolução, aqui, e monitorar a adequação do PSTI no cumprimento das regras da segurança, as regras de segurança do Banco Central, gestão de riscos, e o demais ali que está nesta resolução.

(50:52) E aí, o que me chama a atenção é que o Banco Central está dizendo que os contratantes dos PSTIs vão ter que monitorar também e acompanhar se os PSTIs estão cumprindo as suas obrigações de segurança. E isso é bem delicado. Não sei se te parece. Não, sem dúvida. Porque já é difícil tu cuidares do teu, tu ainda vais ter que cuidar do outro assim.

(51:18) E daí tem que ver até que nível que isso vai acontecer, Guilherme. Se de repente basta, concordo. Se de repente basta aparecer como com a LGPD, por exemplo. Se eu vou contratar o serviço de uma empresa, eu posso solicitar que essa empresa me dê evidências de que ela está respeitando a LGPD, de que os processos dela estão OK, ou que o sistema dela me dá recursos para gerenciar adequadamente os direitos dos titulares e blá blá blá.

(51:45) Eu vou poder fazer isso? Ou seja, vou poder: “ó, PSTI, beleza, eu sou obrigado a acompanhar aí para monitorar se tu estás OK. Eu quero, todo ano, o relatório de vulnerabilidade de vocês. Eu quero relatório de auditoria, de pentest e tudo mais”. E nota que lá na resolução do Banco Central, nesta resolução que a gente está discutindo, ele fala justamente de dar os dados e as informações.

(52:13) Tu viste a listinha? Não é só 35 dias. Eu não sei, não lembro o número do artigo aqui agora, mas não é só a questão de tu dizeres que, mostrar que fez uma auditoria. Tu tens que demonstrar, tu tens que mostrar o que foi encontrado, o que foi corrigido. Assim, não é qualquer coisa. É até meio complicado isso, dependendo do que vai ser mostrado.

(52:36) Eu não sei se é muito viável o PSTI fornecer isso para o Banco Central. Beleza. O PSTI fornecer isso para todos os clientes que ele tem. Também acho. Pode ser problemático. É, não sei. Eu acho problemático. Mas o cliente, então, se for nos termos do cliente do PSTI, diz assim: “Eu quero, me dá evidência de que tu passou por uma auditoria independente, me dá a evidência de que tu fez pentest, me dá evidência este ano, ano que vem eu quero de novo”. E aí eu acho tranquilo. Qual a diferença de comunicar isso para o

(53:04) Banco Central? Aí é o trabalho do banco, aí vai dar trabalho para o Banco Central. Não, mas assim, qual é a diferença de tu, PSTI, comunicares isso para o Banco Central e também seres monitorado pelos teus clientes? Porque o que a resolução diz é que os contratantes devem monitorar continuamente a adequação do PSTI contratado aos requisitos de governança corporativa, gestão de risco, segurança cibernética, gestão de fraude. Parece-me uma distribuição… isso dá para chamar, Guilherme, se

(53:36) tu quiseres, de uma distribuição peer-to-peer de trabalhos do Banco Central. Uhum. Estás ligado? Não estou dizendo que o Banco Central não vai fazer o trabalho dele, não é isso. Mas tu estás meio que jogando para as pontas: “ó, tu vais contratar um PSTI. Embora o PSTI tenha que passar pela minha avaliação e eu tenha que autorizar o cara e tudo mais, mas tu aí tens que monitorar o PSTI que tu estás a contratar”. Aham.

(54:05) De acordo com as regras que eu defini. A parte mais próxima. E detalhe, e detalhe: a não observância do disposto neste artigo, ou seja, se tu, contratante, não fizeres isso, você fica sujeito às sanções previstas na legislação em vigor. Tem outras coisas: manter posse das chaves privadas, não utilizar o mesmo certificado entre ambientes de homologação e produção, manter à disposição do Banco Central documentação relativa à contratação e ao monitoramento e supervisão do PSTI.

(54:36) É um dever adicional de monitoramento e supervisão do contratante do PSTI que pode ser exigido pelo Banco Central. Isso é bem interessante, cara. E, ao mesmo tempo, preocupante talvez para as empresas que vão ter que começar a cumprir esse dever de uma hora para outra. É.

(54:56) E aí, o seguinte: essa aí que eu coloquei, as empresas podem simplesmente pedir a comprovação de que estão fazendo isso. É uma possibilidade. Então, me dá evidência. Eu contrato o PSTI e digo: “PSTI, me dá as evidências de que tu estás seguindo as coisas”. Esse caminho acho que é fácil. Mas, por outro lado, se precisar de monitorar, acompanhar, daqui a pouco tu vais ter o cliente do PSTI pedindo para o PSTI não a evidência de um pentest, mas autorização para ele, cliente, pegar uma empresa terceira e fazer um pentest no sistema do PSTI, entendes? Ou pegar algum

(55:39) tipo de monitoramento mais ativo, sabes? Eu acho mais, eu acho mais provável pedir… mais fácil pedir evidência do que ficar, do que jogar essa questão de monitoramento constante para o colo do cliente, entendes? É, mas não esquece que o cliente aqui ele tem a obrigação de comunicar de imediato ao Banco Central as falhas ou os descumprimentos identificados na atuação do PSTI.

(56:12) Você monitora, você tem que guardar as informações, você tem que acompanhar e tem que denunciar o cara para o Banco Central, tem que “dedurar” o cara. E para isso você vai ter que ter um setor interno de controles. Ou seja, você vai ter que avaliar o controle do PSTI. Isso é muito delicado. Isso é muito delicado porque eu entendo que o Banco Central tem mais condições, por exemplo, do que o PSTI para fazer esse tipo de controle de segurança. E entendo que o PSTI, por sua vez, tem mais condições do que o seu cliente lá

(56:43) na ponta para fazer esses controles, esses cuidados com segurança. E aí tu dás ao cara lá na ponta, que é o cliente do PSTI, a responsabilidade de monitorar o PSTI. Não, não é responsabilidade, é obrigação. Obrigação. E ainda esse cara tem que coletar a evidência.

(57:03) Ele tem que monitorar, sei lá como, tem que coletar a evidência e tem que entregar esse cara para o Banco Central quando esse cara descumpre. E se é obrigação e tu não fazes, tu não monitoras, tu ficas sujeito à sanção. Cara, mas pensa, pega o caso concreto, Vinícius, para a gente já ir terminando. O PSTI pede: “Me passa a tua chave privada aí, porque sem a tua chave privada não vai dar para implementar”.

(57:32) E tu passas e tal, e depois te dás conta e tu dizes: “Olha, Banco Central, ele me pediu a chave privada aqui”. Não, você não poderia ainda. Você teria que identificar que ele não pode. Tu vais ter que dizer: “Olha, eu não posso fazer isso. E você está descumprindo o parágrafo primeiro do artigo 35. E eu estou notificando o Banco Central de que você está me pedindo isso”. É isso aí. Exatamente isso.

(58:00) Ai, ai. Exatamente isso. Enfim. Tem mais outras coisas aqui, uma norma complexa. Eu acho que, como a gente colocou aqui, outras coisas vão acabar acontecendo aqui também. E vamos ficar atentos, como sempre. Lembrando que eu acho que isso vai dar uma mexida no sistema financeiro. Ou seja, quem utiliza serviço de PSTI vai ter que ficar bem atento agora. E, enfim, vamos ver o que vai acontecer a partir de agora. Sem

(58:35) esquecer também, Vinícius, que essas regulações também entram no momento em que o sistema financeiro também foi utilizado nessas investigações recentes aí de fintechs sendo usadas para lavar dinheiro. Então não acabou, cara. Agora sim, ó. Agora essas fintechs todas vão entrar.

(58:56) O Banco Central vai regular tudo. Sim. Não vai ter mais essa coisa aí de “conta bolsão”, com essa conta com um dinheiro… Lembrei lá do bolsão do… do… Ah, o “bolseiro”. Aham. É. Não, não vai ter essa brincadeira aí. Então, esse vai ter mais um monte de gente regulada, cara.

(59:23) É uma… é assim, acabou a festa. A festa no mau sentido. E acho que não tem outro caminho. Sistema financeiro tem que ser regulado, cara. Tem que ser monitorado. E aquela história: não precisa mais explodir carro-forte. Não precisa mais, tu vais direto nos sistemas, cara.

(59:43) E com Pix e com Bitcoin… O Bitcoin que eu digo, com criptomoedas. Pix, cara, o negócio é perfeito. Assim, é o caminho… o caminho é perfeito. O Pix dá movimentação instantânea de dinheiro. Essa movimentação instantânea de dinheiro te permite ter teu dinheiro disponível na conta que tu precisas que esteja disponível rapidamente.

(1:00:08) Tu convertes isso em criptomoeda e puf. Então, a gente vai ter mais problemas a acontecer. Vão ter problemas. Os problemas são novos problemas. É um novo mundo. Novo mundo, novos problemas. Novas soluções, novos problemas, novas obrigações. Bom, é isso aí. Não tem muito… Esperamos então que tenham gostado do episódio 401 e aguardaremos todos no próximo episódio do podcast Segurança Legal. Até a próxima.

(1:00:40) Até a próxima.