Mostrando postagens com marcador cloud computing. Mostrar todas as postagens
Mostrando postagens com marcador cloud computing. Mostrar todas as postagens

março 18, 2026

[Segurança] Começam a valer os novos requisitos regulatórios de cibersegurança para o setor financeiro

Desde 01 de março todas as instituições financeiras devem cumprir novas normas de segurança definidas pelo Banco Central.

Em 18 de dezembro de 2025 o Banco Central publicou duas novas regulamentações que reforçam os controles de segurança exigidos das empresas do setor financeiro, a Resolução CMN n° 5.274 e a BCB n° 538.




As duas resoluções são similares, quase idênticas - a principal diferença é para quem se aplicam, mas podemos considerar que as duas abrangem praticamente todo o mercado financeiro nacional.

As resoluções CMN n° 5.274 e BCB n° 538 substituem as anteriores, respectivamente a Resolução CMN nº 4.893, de 26 de feve​reiro de 2021 e a Resolução BCB nº 85, de 8 de abril de 2021, que dispõem sobre exigências mínimas para a política de segurança cibernética das organizações e, também, sobre os requisitos para a contratação de serviços de computação em nuvem. A 4.893, por sua vez, substituiu a Resolução nº 4.658, de 26 de abril de 2018, que na época era muito famosa por ter sido o primeiro marco normativo do setor financeiro que permitiu às empresas adotarem serviços de computação em nuvem. E foi isso que permitiu, do ponto de vista tecnológico, o boom das Fintechs e Bancos digitais que vivemos desde então.

Basicamente a Resolução CMN n° 5.274 e a BCB n° 538 trazem novos requisitos de segurança para as instituições financeiras, além dos que já eram exigidos até então. Elas detalham alguns requisitos já existentes e incluem exigências novas, que devem ser previstas nas políticas de segurança e evidenciadas em auditorias e relatórios periódicos.

O objetivo, claro, é aumentar a segurança do sistema financeito através de práticas mais rigorosas por parte das empresas. E, assim, tentar frear a onda crescente de fraudes milionárias que pipocaram desde meados de 2025.

Vou listar abaixo alguns dos principais pontos dessas resoluções:
  • Art. 3º § 2º - Nova lista com os procedimentos e controles que devem constar na política de segurança cibernética (os marcados em negrito são novos!):
I - a autenticação; 
II - os mecanismos de criptografia; 
III - os mecanismos de prevenção e detecção de intrusão; 
IV - os mecanismos de prevenção de vazamentos de informações; 
V - os mecanismos de proteção contra softwares maliciosos; 
VI - os mecanismos de rastreabilidade; 
VII - a gestão de cópias de segurança dos dados e das informações; 
VIII - a avaliação e a correção de vulnerabilidades dos recursos computacionais e dos sistemas de informação;  (antes estava como "realização periódica de testes e varreduras para detecção de vulnerabilidades")
IX - os controles de acesso; 
X - a definição e implementação de perfis de configuração segura de ativos de tecnologia;
XI - os mecanismos de proteção da rede; (antes estava como "segmentação de rede")
XII - a gestão de certificados digitais; 
XIII - os requisitos de segurança para a integração de sistemas de informação por meio de interfaces eletrônicas; 
XIV - as ações de inteligência no ambiente cibernético, incluindo o monitoramento de informações de interesse da instituição na internet, na Deep Web e na Dark Web, além de grupos privados de comunicação.
  • Art. 3º § 6º - Os controles de segurança também se aplicam nos casos de "sistemas de informação por ela adquiridos ou desenvolvidos por empresas prestadoras de serviços a terceiros";
  • Art. 3º § 7º - Exigências mais detalhadas para os "mecanismos de rastreabilidade" e tempo de retenção dos dados;
  • Art. 3º § 8º - Exigências mais detalhadas para as atividades de "avaliação e a correção de vulnerabilidades";
  • Art. 3º § 9º - O detalhamento das novas exigências para controle de acesso;
  • Art. 3º § 10º - Detalhamento das novas exigências para perfis de configuração segura;
  • Art. 3º § 11º - Exigências mais detalhadas para os mecanismos de proteção da rede;
  • Art. 3º § 12º - Detalhamento das novas exigências para gestão de certificados digitais;
  • Art. 3º-A - Traz novos requisitos de segurança:
    • I - no caso de comunicação eletrônica de dados na Rede do Sistema Financeiro Nacional (RSFN): controles de MFA, isolamento físico e lógico dos ambientes PIX e STR, monitoramento e guarde de credenciais e certificados digitais, além de "implementação de mecanismos de validação da integridade fim a fim das transações" e "vedação do acesso de empresas prestadoras de serviços a terceiros às chaves privadas associadas a certificados digitais";
    • II - no caso de conexão como participante de Sistemas do Mercado Financeiro (SMF): implementação de controles de segurança para prevenção, detecção e resposta a fraudes;
  • Art. 8º - O relatório anual sobre a implementação do plano de ação e de resposta a incidentes também deve contemplar, a partir de agora, os resultados dos testes de continuidade de negócios e os resultados dos testes de intrusão e dos testes para detecção de vulnerabilidades, além dos planos de ação estabelecidos para as suas correções;
  • Art. 22-A. - Exigências mais detalhadas para os testes de intrusão;
  • Art. 22-B. - Reforço de que os requisitos de segurança para conexão com a RSFN se aplicam independente da forma de conexão e mesmo quando "o prestador de serviços fornece serviço de processamento de mensagens no âmbito do SFN e do Sistema de Pagamentos Brasileiro – SPB";
  • Art. 23. - Inclui na lista de informações que devem ficar à disposição do Banco Central do Brasil pelo prazo de cinco anos: a documentação de casos que configurem uma situação de crise e os resultados da execução de testes de intrusão e os planos de ação;
  • Art. 24. - Inclui que o Banco Central poderá estabelecer "a especificação dos requisitos de segurança para integração de sistemas de informação por meio de interfaces eletrônicas".
Como podemos ver, as resoluções incluíram novos requisitos de segurança e também trouxe um maior detalhamento dos requisitos que já eram exigidos anteriormente.

Também chamou muito a atenção do mercado que o BC incluiu uma exigência de que as instituições financeiras tenham serviços de cyber threat intelligence (CTI), que são importantíssimos para prevenção de ataques e de fraudes. Por isso mesmo, em 20 de janeiro deste ano a Apura apresentou um webinar sobre o assunto: Sistema Financeiro em Foco: a atuação da Apura frente às resoluções do Bacen e CMN.



Para saber mais:

outubro 28, 2025

[Carreira] Jornada de aprendizado Womcy em parceria com a Google Cloud

A WOMCY, em parceria com o Google Cloud, criou a Jornada de Aprendizado, um programa gratuito e exclusivo para quem quer acelerar a carreira em nuvem e cibersegurança.

Essa é uma oportunidade de conquistar certificações reconhecidas pelo mercado, aprender diretamente com uma das maiores empresas de tecnologia do mundo e se conectar com oportunidades reais de trabalho!

Etapas do programa:
  1. Google Cloud Computing Foundations — Domine os conceitos essenciais da nuvem.
  2. Google Cloud Cybersecurity Certificate — Especialize-se em segurança na nuvem (disponível para quem concluir a Etapa 1).
Benefícios exclusivos:
  • Cursos 100% gratuitos para membros WOMCY
  • Certificados e selos oficiais do Google Cloud
  • Acesso a uma Job Fair exclusiva com parceiros e clientes Google Cloud
  • Vagas limitadas — preenchidas por ordem de inscrição
Garanta sua vaga agora e venha construir o futuro da cibersegurança conosco!

Inscreva-se já: www.womcytrainingcenter.org

Atenção: Últimos dias para se inscrever! As inscrições encerram em 30/10 — e você não vai querer ficar de fora dessa!



novembro 04, 2021

[Segurança] Cloud Incident Response Framework

O pessoal da Cloud Security Alliance publicou há poucos meses atrás o Cloud Incident Response (CIR) Framework, um framework criado para servir como um guia para que os clientes de serviços de computação em nuvem se preparem e gerenciem com eficácia os incidentes da nuvem.


O framework cobre os requisitos de segurança e o nível apropriado de proteção contra incidentes, além de orientações sobre como negociar com os provedores de serviços em nuvem e dividir as responsabilidades de segurança. Ele mapeia as recomendações de planejamento e preparação para incidentes de segurança na nuvem, em cada passo do ciclo de vida da gestão de incidentes, com os principais padrões da indústria: o CSA Security Guidance For Critical Areas of Focus In Cloud Computing v4.0, o NIST 800-61r2 Computer Security Incident Handling Guide, o ITSC Technical Reference (TR) 62 – Cloud Outage Incident Response (COIR), o FedRAMP Incident Communications Procedure, o NIST 800-53 Security and Privacy Controls for Information Systems and Organizations, o Incident Handler’s Handbook do SANS Institute e o Cloud Computing Risk Assessment da ENISA. A imagem abaixo ilustra esse relacionamento e adesão a esses padrões:


O documento aborda o compartilhamento de responsabilidade entre clientes e provedores de serviço em nuvem, que é um assunto crítico quando falamos em ambientes em Nuvem, e traz muitas recomendações. Vale a pena baixar e ler o documento.

maio 12, 2021

[Segurança] Triste perspectiva dos vazamentos de dados

Você acha que já tivemos muitos vazamentos de dados até hoje?

Já não basta termos alcançado mais de 22,3 bilhões de dados vazados apenas no ano de 2019!?

Você ficou assustado com a notícia recente de que uma coletânea com 3,28 bilhões de senhas estava disponível em um fórum online?


Pois isso tudo é só a ponta do iceberg!

E o cenário atual é assustador: segundo um levantamento realizado por pesquisadores da CyberNews, foram encontrados mais de 29.000 bancos de dados online em todo o mundo, que estão desprotegidos e acessíveis ao público, representando cerca de 19 Petabytes de dados expostos.

O levantamento foi realizado buscando por bases de dados online nas três plataformas mais usadas: Hadoop, MongoDB e Elasticsearch. Em comum, a maioria dessas bases eram de empresas Chinesas e Americanas.


Esse descuido das empresas com suas bases de dados armazenadas online e em ambientes de Cloud Computing tem sido uma grande oportunidade para ciber criminosos roubarem dados pessoais. Enquanto as empresas não se conscientizarem sobre esse problema, todos estamos sujeitos ao risco de vazamento de nossas informações pessoais.

(Adicionado em 17/05): Achando que já estava ruim? Segundo um levantamento da empresa Censys, foram identificados dois milhões de banco de dados expostos nos provedores de nuvem mais comuns, além de 1,9 milhão de servidores com conexões RDP expostos, protocolo apontado como responsável por 70 a 80% das violações de rede.

(Adicionado em 21/05): As notícias ruins não param de chegar! OMG!  Pesquisadores da Checkpoint analisaram 23 aplicativos Android e concluíram que os serviços em nuvem desses apps deixaram expostos dados de mais de 100 milhões de usuários !!!

Para saber mais:

abril 20, 2021

[Segurança] Ataques de subdomain takeover

Imagina que você vai no cartório e no Correios e registra que existe uma casa na Rua José das Couves, número 51. Mas tem um detalhe: esse número não existe na rua! Aí um espertinho descobre isso, vai lá na rua e constrói uma casa e bota a plaquinha de número 51 na porta. Você tem o endereço, seus amigos mandam carta para você (faz de conta, né, porque hoje em dia ninguém manda carta), a sua compra na loja de e-commerce vai para esse endereço, mas a casa é de outra pessoa. Em vez de isso tudo chegar para você, o “espertinho” é quem fica com a sua correspondência.

Esse exemplo é bem tosco, criado por um amigo, o Julio Carvalho, que também me indicou alguns dos links que usei nesse post. Tudo isso para ilustrar o significado de um ataque de...


Subdomain Takeover

Em português, seria algo como "sequestro de subdomínios".

Esse é um ataque que acontece com frequência, aonde uma empresa cria um subdomínio apontando para algum serviço online, mas esse serviço não está ativo ou o serviço existente foi desativado. Esse subdomínio, portanto, aponta para lugar nenhum. O atacante, então, vai nesse serviço e cria uma entrada com o nome da empresa, conseguindo que o subdomínio válido aponte para um serviço malicioso. Tais casos frequentemente acontecem com serviços em nuvem oferecidos por terceiros, como o GitHub e com os serviços de bucket S3 da AWS. Nesses dois casos, por exemplo, o atacante descobre que o domínio está errado e cria um repositório com conteúdo malicioso no GitHub ou na AWS – mesmo que usando uma conta própria nesses serviços.


Com esse tipo de ataque, um ciber criminoso pode criar uma página de phishing, um site falso ou um repositório em nome da empresa, mas que esteja hospedando um conteúdo malicioso – só para citar 3 exemplos de consequências indesejáveis para as empresas.

De fato, com a popularização dos serviços de computação em nuvem e repositórios de dados em nuvem, esse ataque ganhou força. É o caso da Amazon Simple Storage Service (Amazon S3), o serviço de armazenamento de dados da Amazon.

No caso da AWS, o ataque de subdomein takover explora a forma que a AWS trabalha com a nomenclatura dos buckets S3. É possível criar uma URL virtual para identificar e dar acesso ao seu bucket, utilizando o formato https://bucketname.s3.Region.amazonaws.com (por exemplo, "ttps://suaempresa.s3.us-west-2.amazonaws.com"), que é equivalente a URL https:// s3.Region.amazonaws.com/bucketname.

Nesse caso, um atacante pode descobrir que sua empresa tinha uma URL cadastrada no DNS, via CNAME, apontando para um bucket desativado. Assim, ele pode “sequestrar” o seu bucket na AWS criando outro bucket com o nome (bucketname) equivalente ao previamente cadastrado pela sua empresa (por exemplo, “suaempresa”) dentro da “amazonaws.com”. Quem cair numa página que tenha esse link ou quem acessar diretamente o link (por exemplo, "ttps://suaempresa.s3.us-west-2.amazonaws.com" oi "https:// s3.us-west-2.amazonaws.com/suaempresa") vai cair numa URL com o nome da sua empresa, mas o conteúdo será malicioso.

O segredo para prevenir esse ataque é, principalmente, ter uma gestão muito cuidadosa dos seus registros DNS, aqueles que apontam o nome (URL) de um site ou serviço para o serviço em si. E também o monitoramento frequente dos seus ativos na nuvem e dos seus registros no DNA, para garantir que os seus domínios continuam válidos. Normalmente esse cadastro de subdomínios é feito pelos campos CNAME do DNS.

Para saber mais:

abril 13, 2021

[Segurança] Bomb Denial of Service (BDoS) attack

Recentemente o FBI prendeu um americano que planejava "derrubar 70% da Internet" explodindo um datacenter da Amazon.

A história parece bizarra demais para ser verdade, mas é sim: é bizarra e é verdade.

O americano Aaron Pendley, do Texas, pretendia explodir um datacenter da Amazon Web Services (AWS) localizado em Ashburn, Virginia. O FBI ficou sabendo desse plano maluco quando, em Janeiro desse ano, o terrorista amador postou uma mensagem num fórum online monitorado pelo FBI, o MyMilitia - um fórum usado por radicais de direita nos EUA. Em seguida, ele compartilhou seus planos com um participante do fórum, que o denunciou para o FBI.

Um agente disfarçado do FBI, que participava do fórum, entrou em contato com esse usuário e se ofereceu para vender explosivos plásticos C-4. Detalhe: o Aaron queria destruir o datacenter da AWS para tirar do ar os sistemas da CIA, FBI e do governo americano.


O agente do FBI marcou um encontro no dia 8 de Abril para fazer a venda do suposto explosivo, e aí o Aaron foi preso. Ele pode ser condenado a até 20 anos de prisão.

Os consultores e vendedores de planos e soluções de Recuperação de Disastres devem estar adorando essa história, e vamos vê-la em muitas apresentações comerciais de agora em diante.

Eu prefiro batizar esse "ataque" de...


Bomb Denial of Service (BDoS) attack


Que comecem os jogos!

dezembro 02, 2020

[Segurança] Cinco Mitos Sobre Segurança na Nuvem

O pessoal da Fireeye publicou um whitepaper aonde discute 5 mitos sobre a segurança da Computação em Nuvem. São eles:
  1. A nuvem não é segura
  2. Minha organização não usa a nuvem
  3. Meu provedor de nuvem me manterá seguro
  4. A nuvem é apenas o computador de outra pessoa
  5. Adversários avançados não estão atacando a nuvem
Vale a pena dar uma olhada no paper para ver como eles analisam e refutam as afirmações acima.

Eu quero adicionar mais um mito a essa lista, que era frequentemente dito até há pouco tempo atrás:
  1. Bancos não usam computação em nuvem porque é inseguro - as Fintechs e os novos bancos digitais mudaram essa percepção, provando que sim, é possível montar na nuvem quase a totalidade da infra-estrutura de um negócio crítico como uma instituição financeira!
Para saber mais

agosto 13, 2020

[Segurança] O fator humano no vazamento de dados da Capital One

O vazamento de dados do banco americano Capital One, que aconteceu em Julho de 2019 e afetou mais de 100 milhões de clientes do banco, trouxe muitas oportunidades para discussão sobre o cenário de vazamento de dados, uma vez que envolveu um importante banco americano, que até então era considerado uma grande referência na adoção de computação em nuvem.

Embora o banco fosse reconhecido por possuir um grande domínio da tecnologia necessária para sua migração para a nuvem, a ponto de ser apresentado como estudo de caso no site da AWS, o fator humano pode ter sido um importante facilitador do incidente. De acordo com uma reportagem publicada no jornal The Wall Street Journal em Agosto de 2019, e reproduzida no blog da empresa BitSight, há indícios de que a moral do time de segurança estava abalada no período que antecedeu o incidente, o que causou uma evasão de talentos. E isso pode ter estimulado a falta de cuidado que fez com que o incidente (a invasão e o roubo de dados) passasse desapercebido.

Segundo a reportagem, antes do incidente a empresa havia trocado o CISO, contratando um profissional originado do setor público, que entrou em conflito com a cultura dos funcionários existentes. Devido a esse conflito, vários profissionais deixaram a empresa. A reportagem completa que a Capital One estava sofrendo um grande turnover no time de segurança, com diversas trocas nas posições de gestão do time, e que apenas em 2018 a empresa havia perdido 30% de seus profissionais!

Antes uma empresa que atraía os talentos em tecnologia, de repente a Capital One se rendeu a um cenário aonde os funcionários estavam desmotivados e os projetos se perdiam na politicagem.

Segundo consta na decisão do Office of the Comptroller of the Currency (OCC),  que estabeleceu uma multa de 80 milhões de dólares à Capital One por causa do incidente, falhas de gestão também ajudaram a permitir que o incidente acontecesse. A OCC aponta que a auditoria interna da Capital One falhou em reportar os problemas da empresa para o Comitê de Auditoria e o Board da empresa falhou em tornar o time de gestão responsável por corrigir as falhas identificadas nos controles internos e nas vulnerabilidades.

junho 04, 2020

[Segurança] A responsabilidade compartilhada na nuvem

Um aspecto muito importante, quando discutimos a segurança em ambientes de computação em nuvem, é que os cuidados de gestão, conformidade e de segurança são compartilhados entre o cliente e o provedor de serviços em nuvem. Mas esse compartilhamento de responsabilidades varia dependendo do tipo de serviço em nuvem contratado: quanto mais recursos você tem no ambiente, maior a sua responsabilidade.

Como diz a AWS, "normalmente essa diferenciação da responsabilidade é mencionada como segurança da nuvem vs. segurança na nuvem."

De uma forma geral, o provedor de serviços em nuvem é responsável pela proteção da infraestrutura que oferece suporte à nuvem e os serviços prestados, enquanto os clientes são responsáveis por tudo aquilo que colocam na nuvem ou conectam ao seu ambiente em nuvem. 

Um documento da NSA, sobre mitigação de vulnerabilidades na nuvem, tem um diagrama que representa muito bem como funciona a responsabilidade compartilhada entre o cliente e o provedor de serviços em Nuvem:


Ou seja, quanto maior a abstração do serviço, ou seja, quanto mais recursos o provedor de nuvem oferece, maior é a sua responsabilidade. Ao mesmo tempo, quanto mais abstrato, menor a possibilidade do cliente customizar a segurança do seu serviço em nuvem.

Esse modelo compartilhado pode ajudar a reduzir a carga operacional do cliente, uma vez que tira dele parte da responsabilidade por cuidar da segurança - algo muito importante se o cliente não tem essa expertise internamente (ou se não tem condições de manter profissionais dedicados ao tema).

Para saber mais:


PS: Última atualização em 15/06.

fevereiro 21, 2020

[Carreira] AWS, Azure ou Google?

Recentemente eu encontro um artigo bem legal e extenso do pessoal da Varonis com uma pequena coletânea de infográficos sobre as funcionalidades dos 3 provedores de Cloud Computing mais populares: Amazon Web Service (AWS), Google Cloud Platform (GCP) e Azure da Microsoft.


Vale a pena dar uma lida no artigo para ver os detalhes do comparativo que eles criaram.

dezembro 05, 2019

[Segurança] Retrospectiva: Leak é o novo Deface

Os vazamentos de dados já se tornaram constantes nos últimos anos, cada vez atingindo números mais estratosféricos, impactando empresas e instituições de todos os tamanhos.

Não é de se assustar, portanto, que hoje temos uma quantidade de dados vazados que, por si só, já é maior do que a população da Terra. Isso sem falar que, em Novembro, pesquisadores encontraram um banco de dados exposto com 1,2 bilhão de registros e 622 milhões de e-mails. E a tendência é que esses vazamentos vão aumentar cada vez mais. Em 2019 vimos alguns casos de vazamento de dados que afetaram a população de todo um país, como no caso do Chile, do Equador, e até mesmo aqui no Brasil - com o site do Detran expondo os dados de todos os motoristas brasileiros.

A propósito, em 2019 os vazamentos de dados de empresas brasileiras aconteceu com uma frequência jamais vista, como por exemplo nos vazamentos recentes da Unimed, Claro (8 milhões de usuários) e Carrefour. Segundo amigos que tem um portal de notícias, eles não dão conta de noticiar todos os casos de vazamento de dados que chegam até eles.

Durante 2019, tivemos tantos vazamentos de dados expostos sem proteção em ambientes de armazenamento em nuvem que o pessoal do The Hack escreveu um pequeno tutorial de como usar e proteger o serviço Simple Storage Service (S3) na Amazon.

Como disse o Fernando Mercês, nesse ano podemos dizer que o "Leak é o novo Deface"...


Seria esse o fim derradeiro da privacidade?

PS: Veja aqui os principais Ataques e Vazamento de Dados em 2019 - ótima coletânea do Felipe Prado (adicionado em 30/12)

PS/2: Veja também o artigo The Top 12 Data Breaches of 2019 (adicionado em 08/06/2020)

outubro 11, 2019

[Segurança] O vazamento de dados da Capital One

Um dos vazamentos de dados mais comentados neste ano aconteceu com o banco americano Capital One, anunciado publicamente em julho deste ano. Através de um ataque realizado por uma pessoa com conhecimento de sua infra-estrutura, a empresa sofreu um roubo de informações que afetou 106 milhões de clientes (100 milhões dos EUA e 6 milhões do Canadá).

Esse caso é bem interessante pois há várias informações sobre o caso, uma vez que a investigação do FBI e seu relatório de acusação está disponível online. Junte a isso um post no blog da empresa ClousSploit e um artigo do Brian Krebs, e conseguimos identificar vários detalhes de como ocorreu o ataque.

O incidente, fruto de uma invasão criminosa, ocorreu nos dias 22 e 23 de março; porém, a instituição só percebeu o ataque no dia 19 de julho. O comprometimento dos dados só foi descoberto porque um pesquisador de segurança identificou a informação vazada e notificou a Capital One, via e-mail, através de seu programa de Vulnerability Disclosure.

Assim, a empresa identificou que seus dados e o script utilizado estavam disponíveis online em uma conta no GitHub. Pior ainda: o FBI identificou a suspeita da invasão pois ela publicou tudo em sua própria conta do serviço GitHub. E, ainda mais, conseguiu validar a identidade da pessoa cruzando seus perfis e comentários sobre o incidente em redes sociais. De nada adiantou usar VPN e TOR...

A acusada, chamada Paige Thompson, já trabalhou como engenheira de software para a Amazon Web Services (AWS) e  prestou serviços para a Capital One entre 2015 e 2016.

Para acessar e roubar os dados, a atacante se aproveitou de uma falha de configuração no Web Application Firewall (WAF) ModSecurity utilizado pela CapitalOne para proteger o seu servidor hospedado na AWS, e realizou um ataque de Server-Side Request Forgery (SSRF) para executar remotamente alguns comandos no servidor e, assim, acessar mais de 700 diretórios com dados de clientes.

Segundo a investigação do FBI, o script encontrado no GitHub possuía os comandos utilizados para obter o acesso ao ambiente da Capital One na AWS, listar seus repositórios de dados e copiar as informações.


Com base no material do FBI, no blog da CloudSploit e no artigo do Krebs, podemos reconstruir os principais passos realizados pelo atacante:
  • O ataque SSRF permitiu enganar o servidor para executar comandos em nome de um usuário remoto, permitindo que o usuário obtenha acesso a serviços no ambiente privado, não públicos;
  • A configuração incorreta do WAF permitiu ao invasor induzir o firewall a encaminhar os comandos para um recurso padrão no back-end na plataforma da AWS, conhecido como "serviço de metadados" (acessado através do endereço http://169.254.169.254);
  • Combinando o ataque SSRF com o acesso ao serviço de metadados contendo credenciais temporárias do ambiente, a invasora conseguiu induzir o servidor a fazer uma solicitação para obter as credenciais de acesso. Ao usar a URL http://169.254.169.254/iam/security-credentials, a atacante teve como retorno informações de AccessKeyId e SecretAccessKey. Tais credenciais permitiram executar comandos no ambiente AWS via API, CLI ou algum SDK;
  • Com essas credenciais, a invasora executou várias vezes o comando "ls" (para listar os Buckets da AWS S3), que retornou uma lista completa de todos os buckets do AWS S3 na conta comprometida da Capital One ("$ aws s3 ls");
  • Ao final, a atacante utilizou o comando "sync" da AWS para copiar os dados desses buckets para sua máquina local da invasora ("$ aws s3 sync s3://bucketone ."). Esse comando permitiu ao atacante o acesso a mais de 700 buckets, de acordo com a acusação.
É interessante notar também que todos os acessos acima foram realizados através de TOR e VPN, para ocultar a origem do ataque.

Um exercício legal é mapear todos os passos do ataque de acordo com o framework ATT&CK do MITRE, como na imagem abaixo, criada pela empresa exabea:


A propósito, eu senti que no framework ATT&CK falta nomear uma técnica relacionada a exploração de falha de configuração em dispositivo de segurança existente (o WAF da Capital One, nesse caso), que na minha opinião poderia ser incluída na categoria de "Defense Evasion". Ao menos temos algo similar na lista de técnicas "PRE-ATT&CK", como "Analyze architecture and configuration posture".

Como esse ataque poderia ter sido evitado? O próprio framework ATT&CK nos dá algumas dicas, pois ele também descreve, para cada técnica de ataque conhecida, as principais recomendações de mitigação e detecção que podem ser utilizadas, quando for aplicável. Alguns controles são relativamente óbvios na primeira leitura do caso, como por exemplo:
  • Falha de controle de acesso, permitindo o acesso a infra-estrutura a partir de endereços IP da rede TOR e de serviços de VPN;
  • Falha na gestão da solução WAF. Faltou também auditoria de configuração e auditoria de vulberabilidades que poderiam ter identificado essa falha;
  • Monitoramento insuficiente do ambiente de Cloud Computing. O ambiente AWS possui o recurso CloudTrail, um serviço de auditoria que registra e monitora as ações executadas na infraestrutura, inclusive ações executadas via Console de Gerenciamento da AWS, dos SDKs e das ferramentas da linha de comando;
  • Monitoramento insuficiente do tráfego de saída do ambiente na AWS, permitindo a exfiltração de grande volume de dados sensíveis.
Após resultado do julgamento em junho de 2022, em setembro a Paige Thompson recebeu sua sentença de prisão e cinco anos de liberdade condicional após sua condenação em junho nos tribunais federais dos EUA por cinco acusações de crimes e duas contravenções. Thompson deverá prestar 50 horas de serviço comunitário a cada ano durante o período de liberdade condicional, ficando sujeita a monitoramento por três anos restrita a ficar em sua casa, e seu uso de computadores e internet estará sujeito a monitoramento federal.

Para saber mais:
PS: Post atualizado em 05 e 06/10/2022.

outubro 09, 2019

[Segurança] O que deveríamos ter aprendido com o vazamento do McDonnald's?

O pessoal da The Hack reportou, com exclusividade. um vazamento de dados de uma prestadora de serviços que deixou exposto mais de 2,3 milhões de registros sensíveis da rede McDonald's Brasil, incluindo informações pessoais de funcionários e dados de fornecedores.


Segundo The Hack apurou junto a Arcos Dorados (responsável pela marca McDonald’s na América Latina), o ambiente vulnerável era de propriedade de um prestador de serviços chamado DoxTI, que foi contratado para desenvolver um sistema de indicadores de Mc performance. Pois, mas esta empresa colocou os dados dos funcionários do Mc em um ambiente Elasticsearch desprotegido, com livre acesso para usuários não-autenticados - uma falha que tem se tornado uma verdadeira epidemia nos últimos meses.

Conforme explica a reportagem da The Hack, o Elasticsearch é uma ferramenta popular utilizada em ambientes em Cloud Computing para facilitar a consulta de grande volumes de dados. Porém, por padrão, ao ser instalada, ela é configurada com acesso público — o que significa que qualquer pessoa com a URL certa é capaz de acessar as informações indexadas pela plataforma. Já noticiamos outros casos similares, como este app de relacionamento e servidores contendo dados cadastrais de quase toda a população equatoriana e chilena.

Lições que deveriam ser aprendidas:

  • Exigir e atirar a segurança de prestadores de serviço e fábricas de software. Um vazamento num prestador de serviço pode causar grande dor de cabeça para a empresa, mesmo que seja um terceiro contratada para fazer um sistema bobinho, simples ou baratinho;
  • Testar e auditar sempre. Principalmente ao colocar algum ambiente na nuvem (independente de ser um ambiente para desenvolvimento, homologação ou produção). Nunca suba um ambiente exposto na Internet sem fazer todos os testes de segurança possívels - nem mesmo sem fazer os testes mais básicos (como tentar acessar sem autenticação).


setembro 27, 2019

Posts que não foram escritos

Artigo bem legal: "Como obtive dados de todos os participantes da maratona IBM Behind The Code"
  • Resumindo: "Gere logs de erros para consumo interno dos desenvolvedores — Nunca exponha exceptions e stacktraces."
Artigo muito bom da The Hack: "Conhecendo um pouco mais sobre o serviço Amazon S3"

Sobre os vazamentos de dados do Banco Inter:


Análise interessante de um vazamento de dados que expos documentos internos do FBI: "Out of Commission: How the Oklahoma Department of Securities Leaked Millions of Files"

Um vazamento de dados que mostra que não podemos confiar nem nos X-9s: "Thousands of people trusted Blind, an app-based “anonymous social network,” as a safe way to reveal malfeasance, wrongdoing and improper conduct at their companies. But Blind left one of its database servers exposed without a password, making it possible (for anyone who knew where to look) to access each user’s account information and identify would-be whistleblowers."

Treta sobre várias vulnerabilidades críticas no iPhone / iOS:
A propósito, o lançamento do iPhone 11 gerou muita zoeira...





setembro 09, 2019

[Segurança] Estatísticas sobre Segurança em Computação em Nuvem

Recentemente a Checkpoint e a Symantec disponibilizaram relatórios interessantes sobre Segurança da Nuvem, com várias estatísticas recolhidas do mercado. São relatórios que abordam questões de segurança na adoção de cloud computing, incluindo quais sÃo os maiores riscos, desafios e dificuldades - não é a toa, ambos os relatórios destacam a dificuldade em identificar mão de obra qualificada nesse assunto.

As pesquisas trazem vários dados muito interessantes, e elas se complementam em vários pontos. Entre os dados apresentados nesses relatórios, eu destaco os seguintes:
  • Segundo a Checkpoint...
    • O SaaS (Software como Serviço) é o modelo de nuvem mais implementado (51%), seguido por IaaS (Infraestrutura como Serviço) (39%) e PaaS (Plataforma como Serviço) (22%);
    • Os cinco aplicativos SaaS mais populares são o Microsoft Office 365 (66%), o Microsoft Exchange (37%), Salesforce (32%), o Google G Suite (29%) e o Dropbox (26%);
    • O e-mail é a informação mais comum armazenada na nuvem (63%), seguido por dados de clientes (45%) e dados de funcionários (incluindo RH e folha de pagamento com 42%);
    • A segurança dos dados e os riscos de segurança em geral (um total de 57%) figuraram no topo da lista de obstáculos para a adoção mais rápida da nuvem, seguidos pela falta de orçamento (26%), desafios de conformidade (26%) e falta de equipe qualificada (26%);
    • 66% dos entrevistados afirmam que soluções de segurança tradicionais não funcionam ou apresentam funcionalidade limitada em ambientes de nuvem;
    • As maiores dores de cabeça em relação à segurança na nuvem se referem à conformidade (34%) e à falta de visibilidade na segurança da infraestrutura (33% no total). A definição de políticas de segurança consistentes na nuvem e localmente e a falta contínua de equipes de segurança qualificadas estão empatadas em terceiro lugar (com 31% cada);
    • O acesso não autorizado e interfaces inseguras empatam em primeiro lugar como as maiores vulnerabilidades da segurança na nuvem (42% cada). Eles são seguidos pelos erros de configuração da plataforma da nuvem (40%) e sequestro de contas (39%);
    • Os maiores obstáculos são a falta de conhecimento especializado e de treinamento das equipes (41%), seguido por desafios orçamentários (40%), preocupações com a privacidade de dados (38%) e falta de integração com as plataformas locais (34%);
    • A criptografia de dados em repouso (38%), a automação da conformidade (37%) e APIs para denúncia, auditoria e alerta sobre eventos de segurança (34%) são os três controles de segurança mencionados com mais frequência;
  • Segundo o Relatório da Symantec, realizada em parceria com a Cloud Security Alliance (CSA)...
    • 53% das organizações já estão avançandas na implementação da nuvem em seu ambiente de TI;
    • A maioria das organizações está subestimando o volume de uso de aplicações na nuvem: enquanto uma organização acredita que seus funcionários estão usando em média 452 aplicativos na nuvem, na verdade, de acordo com os dados da própria Symantec, o número real de aplicativos de TI em uso por organização é de 1.807 (quase 4 vezes a mais do que eles estimam);
    • 73% das empresas pesquisadas acreditam que os incidentes na nuvem aconteceram devido à práticas de segurança imaturas - incluindo o uso de contas pessoais, falta de serviços de Autenticação Multifator (MFA) ou Prevenção de Perda de Dados (DLP);
    • 54% dos entrevistados dizem que a segurança na nuvem de sua organização não conseguiu acompanhar a expansão do uso de novos aplicativos;
    • Segundo dados da Symantec, o acesso não autorizado a contas é responsável pela maior parte dos incidentes de segurança na nuvem (64%);
    • 85% das empresas não estão usando as práticas recomendadas de segurança na nuvem
      • Por exemplo, 65% das organizações não implementaram Autenticação Multifator (MFA) na configuração de IaaS e 80% não usam criptografia;
    • A maioria (92%) disse que precisa melhorar as habilidades de segurança na nuvem, enquanto 84% confirmaram que precisavam adicionar pessoas na equipe para eliminar a deficiência.
O relatório da Symantec também fala muito da Nuvem como sendo o "novo shadow IT" (eu gosto e chamar isso de "Shadow Coud"), ou seja, quando a empresa cria recursos e serviços de tecnologia sem conhecimento, nem participação e aprovação, da área de TI. Assim, os dados da empresa se propagam nos serviços de nuvem SaaS autorizados e não autorizados. Mais da metade dos entrevistados (52%) consideram problemático o aumento do uso de aplicativos na nuvem para armazenar e compartilhar dados corporativos confidenciais. A grande maioria (93%) informou que seus usuários compartilham arquivos na nuvem contendo dados confidenciais e relacionados à conformidade

Ao final, o relatório da Symantec aponta algumas das melhores práticas para desenvolver a maturidade da segurança na Nuvem:
  • Desenvolver uma estratégia de governança;
  • Adotar um modelo de Zero Trust (Confiança Zero);
  • Promover a responsabilidade compartilhada;
  • Aproveitar automação e inteligência artificial sempre que possível;
  • Abrir caminho para DevSecOps.
Ambas pesquisas revelam que o maior desafio que as organizações estão enfrentando não é apenas na tecnologia, mas também nas pessoas e nos processos. Elas dão uma boa visibilidade de como as organizações estão se adaptando a evolução das ameaças na nuvem, examinando questões como visibilidade de seu ambiente, perda de controle de dados e práticas de segurança imaturas, com uso insuficiente de tecnologias, processos inadequados e pessoal sem a devida capacitação.

Para saber mais:

OBS: Post atualizado em 11/09/2019.

maio 31, 2019

[Humor] Pizza as a Service

Recentemente eu vi essa imagem, que explica muito bem os diferentes modelos de computação em nuvem:


novembro 02, 2018

[Segurança] Os cinco principais desafios para os líderes de segurança

O pessoal da Fortinet preparou um pequeno infográfico com alguns dados sobre o que eles consideram serem os cinco principais fatores que estão gerando as mudanças no cenário das ciberameaças.

Segundo eles, os principais desafios são relacionados a proliferação de dispositivos IoT, a dificuldade de proteger ambientes na Nuvem, os ataques dos Ransomwares, os ataques que passam desapercebidos por utilizarem comunicação criptografada e a falta de profissionais de segurança.


maio 02, 2018

[Segurança] Nova regulamentação do Banco Central sobre Política de Segurança e Computação em Nuvem

No dia 26 de Abril, o Banco Central do Brasil (BCB) divulgou uma nova regulamentação para as instituições financeiras que aborda exigências sobre a política de segurança cibernética, com grande destaque ao tratamento de incidentes, e também os requisitos de segurança para a contratação de serviços de computação em nuvem.

Essa norma define o conteúdo mínimo da política de segurança cibernética das instituições financeiras, a necessidade de treinamento e conscientização, e que ela deve ser compartilhada com o Banco Central e revisada periodicamente. A norma dá muita importância para as exigências contratuais mínimas para serviços de computação em nuvem e sua adequação as políticas de riscos e segurança da instituição, além de que essa contratação deve ser previamente  aprovada pelo BCB. Além disso, há uma seção específica para diversas exigências relativas ao tratamento dos incidentes de segurança, incluindo ações para o compartilhamento de informações sobre esses incidentes.

A Resolução nº 4.658, de 26/4/2018 foi fruto de uma consulta pública realizada em Setembro de 2017. A norma merece ser lida e consultada, e acredito que a regulamentação sobre contratação de serviços em nuvem foi o aspecto mais importante e esperado da norma.

Em geral, os principais pontos são os seguintes:
  • Seção I - "Da Implementação da Política de Segurança Cibernética" (Artigos 2º ao 3º): Define que as instituições financeiras devem implementar e manter uma Política de Segurança Cibernética que dite os princípios, diretrizes, procedimentos e contoles para assegurar a confidencialidade, a integridade e a disponibilidade dos dados e dos sistemas, de informação utilizados. Aqui ela não traz nenhuma novidade, pois essas exigências já são práticas de mercado. Mesmo assim, destaco os seguintes pontos:
    • Art. 3º, inciso VI (caput), item a) - a implementação de programas de capacitação e de avaliação periódica de pessoal;
    • Art. 3º, inciso VII (caput) - as iniciativas para compartilhamento de informações sobre os incidentes relevantes, mencionados no inciso IV, com as demais instituições referidas no art. 1º.
    • Art. 3º, § 2º - Os procedimentos e os controles de que trata o inciso II do caput devem abranger, no mínimo, a autenticação, a criptografia, a prevenção e a detecção de intrusão, a prevenção de vazamento de informações, a realização periódica de testes e varreduras para detecção de vulnerabilidades, a proteção contra softwares maliciosos, o estabelecimento de mecanismos de rastreabilidade, os controles de acesso e de segmentação da rede de computadores e a manutenção de cópias de segurança dos dados e das informações.
  • Seção II - "Da Divulgação da Política de Segurança Cibernética" (Art. 4º e 5º) - Dita que a política de segurança cibernética deve ser divulgada aos funcionários da instituição e às empresas prestadoras de serviços a terceiros, além de ter um resumo divulgado ao público;
  • Seção III - "Do Plano de Ação e de Resposta a Incidentes" (Art. 6º ao 10º) - Seção relativamente longa, em minha opinião, para detalhar essa que deveria ser apenas uma das diversas práticas dentro da área de segurança, mostrando a importância que as instituições financeiras devem dar ao tratamento de incidente. Aqui, o BCB define que devem existir rotinas, os procedimentos, os controles e as tecnologias a serem utilizados na prevenção e na resposta a incidentes, sob responsabilidade de um diretor:
    • Art. 7º - As instituições (...) devem designar diretor responsável pela política de segurança cibernética e pela execução do plano de ação e de resposta a incidentes.
  • Capítulo III - "Da Contratação de Serviços de Processamento e Armazenamento de Dados de Computação em Nuvem" (Art. 11 ao 18) - Este é o capítulo que define as exigências de segurança e riscos para serviços em nuvem, no Brasil ou no exterior. Em linhas gerais, diz que as políticas, estratégias, procedimentos e ferramentas que se aplicam a terceirização de serviços também se aplicam a Nuvem. Os pontos mais importantes desse capítulo, na minha opinião, são:
    • Art. 11. - As instituições referidas no art. 1º devem assegurar que suas políticas, estratégias e estruturas para gerenciamento de riscos previstas na regulamentação em vigor, especificamente no tocante aos critérios de decisão quanto à terceirização de serviços, contemplem a contratação de serviços relevantes de processamento e armazenamento de dados e de computação em nuvem, no País ou no exterior.
    • Art. 12, § 3º - No caso da execução de aplicativos por meio da internet, referidos no inciso III do art. 13, a instituição deve assegurar que o potencial prestador dos serviços adote controles que mitiguem os efeitos de eventuais vulnerabilidades na liberação de novas versões do aplicativo.
    • Art. 14. - A instituição contratante dos serviços mencionados no art. 12 é responsável pela confiabilidade, pela integridade, pela disponibilidade, pela segurança e pelo sigilo em relação aos serviços contratados, bem como pelo cumprimento da legislação e da regulamentação em vigor.
    • Art. 15. - A contratação de serviços relevantes de processamento, armazenamento de dados e de computação em nuvem deve ser previamente comunicada pelas instituições referidas no art. 1º ao Banco Central do Brasil.
    • Art. 16. - A contratação de serviços relevantes de processamento, armazenamento de dados e de computação em nuvem prestados no exterior deve observar os seguintes requisitos:
      I - a existência de convênio para troca de informações entre o Banco Central do Brasil e as autoridades supervisoras dos países onde os serviços poderão ser prestados;
      II - a instituição contratante deve assegurar que a prestação dos serviços referidos no caput não cause prejuízos ao seu regular funcionamento nem embaraço à atuação do Banco Central do Brasil;
      III - a instituição contratante deve definir, previamente à contratação, os países e as regiões em cada país onde os serviços poderão ser prestados e os dados poderão ser armazenados, processados e gerenciados;
    • Art. 16, § 2º - Para atendimento aos incisos II e III do caput, as instituições deverão assegurar que a legislação e a regulamentação nos países e nas regiões em cada país onde os serviços poderão ser prestados não restringem nem impedem o acesso das instituições contratantes e do Banco Central do Brasil aos dados e às informações.
    • Art. 17. - Os contratos para prestação de serviços relevantes de processamento, armazenamento de dados e computação em nuvem devem prever:
      (...)
      VII - a permissão de acesso do Banco Central do Brasil aos contratos e aos acordos firmados para a prestação de serviços, à documentação e às informações referentes aos serviços prestados, aos dados armazenados e às informações sobre seus processamentos, às cópias de segurança dos dados e das informações, bem como aos códigos de acesso aos dados e às informações;
      VIII - a adoção de medidas pela instituição contratante, em decorrência de determinação do Banco Central do Brasil;
  • Capítulo IV - Disposições Gerais
    • Art. 20. Os procedimentos adotados pelas instituições para gerenciamento de riscos previstos na regulamentação em vigor devem contemplar, no tocante à continuidade de negócios:
      (...)
      III - a comunicação tempestiva ao Banco Central do Brasil das ocorrências de incidentes relevantes e das interrupções dos serviços relevantes, citados no inciso I, que configurem uma situação de crise pela instituição financeira, bem como das providências para o reinício das suas atividades.
    • Art. 22. Sem prejuízo do dever de sigilo e da livre concorrência, as instituições mencionadas no art. 1º devem desenvolver iniciativas para o compartilhamento de informações sobre os incidentes relevantes de que trata o art. 3º, inciso IV.
      § 1º O compartilhamento de que trata o caput deve abranger informações sobre incidentes relevantes recebidas de empresas prestadoras de serviços a terceiros.
  • Capítulo V - Disposições Finais
    • Art. 23. - Ele determina que todas as informações sobre a política de segurança e sobre as exigências desta regulamentação devem ficar à disposição do Banco Central do Brasil pelo prazo de cinco anos.
    • Art. 25. - O prazo máximo para as instituições financeiras adequarem seus serviços existentes de processamento, armazenamento de dados e de computação em nuvem é 31 de dezembro 2021.
    • Art. 26. - A aprovação da política de segurança cibernética, referida no art. 2º, e do plano de ação e de resposta a incidentes, referido no art. 6º, deve ser realizada, na forma do art. 9º, até 6 de maio de 2019.

Uma grande diferença entre a regulamentação e a versão da consulta pública é a retirada da limitação de que os serviços em Nuvem só poderiam ser baseados no Brasil. Em vez de restringir, o Banco Central optou por exigir que a contratação de serviços em nuvem no exterior seja previamente comunicada pela instituição financeira (Art. 16) e que o BCB tenha os devidos acessos as informações armazenadas na nuvem, quando necessário (Art. 16 e 17).

Um ponto preocupante para o mercado de segurança, e que pode passar desapercebido, é o § 1º do Artigo 22, pois diz que as instituições financeiras devem compartilhar entre si informações sobre incidentes relevantes que tenham sido recebidas de empresas prestadoras de serviços a terceiros. Ou seja, se um banco contratar uma empresa de inteligência e esta lhe fornecer alguma informação relevante sobre um novo ataque, por exemplo, ese banco deve compartilhar a informação com os demais. Ou seja, um banco mais "preguiçoso" não precisa investir em capacidade própria de inteligência: basta ele ficar sentado esperando que os demais bancos lhes envie as informacões que obtiver.

março 26, 2018

[Segurança] Segurança para Cloud Computing no governo Federal

O Departamento de Segurança da Informação e Comunicações (DSIC), o órgão de segurança do governo Brasileiro subordinado ao Gabinete de Segurança Institucional (GSI) da Presidência da República, publicou recentemente uma revisão da norma complementar sobre os requisitos de segurança para a contratação de serviços de Cloud Computing.

A Norma Complementar nº 14/IN01/DSIC/GSIPR1, divulgada pelo GSI em 19/03/2018, foi publicada originalmente em 30 de janeiro de 2012. Ela estabelece quais são os princípios, diretrizes e responsabilidades de Segurança da Informação que os órgãos e entidades do governo federal devem considerar na contratação e no tratamento da informação em ambientes de Computação em Nuvem. A norma vale para todos os órgãos da Administração Pública Federal (APF), direta e indireta.

Esta norma tem como objetivo orientar a Alta Administração de cada órgão ou entidade da APF sobre como considerar os riscos dos ambientes de Cloud Computing na Gestão de Riscos de Segurança da Informação e Comunicações (GRSIC) existente, de modo a salvaguardar dados, informações e serviços sob sua responsabilidade, de acordo com os interesses de entidade, da sociedade e do Estado.

É interessante notar que a norma estabelece a obrigatoriedade de armazenamento dos dados em território nacional (item 5.3), limitando assim a contratação de Cloud Computing a empresas que tenham infraestrutura baseada no Brasil, e também estabelece que é vedado o armazenamento de dados sigilosos em ambiente na Nuvem (item 5.2.2).

Na minha opinião, dentre as diversas diretrizes listadas nessa norma, os pontos mais importantes são os seguintes:
5 PRINCÍPIOS E DIRETRIZES

5.1 O órgão ou entidade da APF deve observar, no mínimo, ao adotar o tratamento da informação em ambiente de Computação em Nuvem:
5.1.4 As informações tratadas em ambiente de computação em nuvem devem passar por um processo de GRSIC;
5.1.9 A prevalência da legislação brasileira sobre qualquer outra.
5.2 Sobre o tratamento da informação:
5.2.1 Informação sem restrição de acesso: pode ser tratada, a critério do órgão ou entidade da APF, em ambiente de computação em nuvem, considerando a legislação vigente e os riscos de SIC;
5.2.2 Informação sigilosa: como regra geral, deve ser evitado o tratamento em ambiente de computação em nuvem, conforme disposições a seguir:
5.2.2.1. Informação classificada: é vedado o tratamento em ambiente de computação em nuvem;
5.2.2.2. Conhecimento e informação contida em material de acesso restrito: é vedado o tratamento em ambiente de computação em nuvem;
5.2.2.3. Informação com restrição de acesso prevista em legislação vigente: a critério do órgão ou entidade da APF, pode ser tratado em ambiente de computação em nuvem, considerando a legislação vigente e os riscos de SIC. O órgão ou entidade da APF deve adotar medidas que assegurem a disponibilidade, integridade, confidencialidade e autenticidade (DICA);
5.2.2.4. Documento Preparatório: a critério do órgão ou entidade da APF, pode ser tratado em ambiente de computação em nuvem, considerando a legislação vigente e os riscos de SIC. O órgão ou entidade da APF deve adotar medidas que assegurem a DICA;
5.2.2.5. Documento preparatório que possa originar informação classificada deve ser tratado conforme o item 5.2.2.1; e
5.2.2.6. Informação pessoal relativa à intimidade, vida privada e imagem: a critério do órgão ou entidade da APF, pode ser tratado em ambiente de computação em nuvem, considerando a legislação vigente e os riscos de SIC. O órgão ou entidade da APF deve adotar medidas que assegurem a DICA.
5.3 Deve ser assegurado que dados, metadados, informações e conhecimento, produzidos ou custodiados por órgão ou entidade da APF, bem como suas cópias de segurança, residam em território brasileiro;
Esta norma tem um objetivo claro de alinhar a contratação de serviços em nuvem com as normas, políticas e procedimentos existentes (incluindo gestão de risco e tratamento de incdentes), além de explicitar a proibição de armazenamento de informações fora do território brasileiro e a preocupação com o sigilo dos dados.

agosto 24, 2017

[Segurança] Posts que nunca foram escritos

Está na hora de dar uma limpada na minha coletânea de artigos, histórias e idéias que nunca viraram posts nesse blog.

E viva o vazamento de dados...
Alguns posts sobre política, governos e ciber espionagem:
Notícias sobre Ransomware:
Alguns artigos sobre o mercado de segurança:


"Legítima defesa digital": https://www.bleepingcomputer.com/news/legal/proposed-us-bill-would-legalize-aggressive-hack-back-attacks/
  • O interesse é que há quase 10 anos atrás o PL de crimes cibernéticos do Eduardo Azeredo tinha uma cláusula sobre isso.
Indústria 4.0

Reportagens com estatísticas do Gartner sobre o mercado de segurança baseado em Cloud Computing: Serviços mundiais de segurança baseados em nuvem devem crescer 21% em 2017 e devem movimentar US$ 5,9 bi neste ano no mundo

Alerta: ladrões clonam contas no WhatsApp e pedem transferência em dinheiro

"Mini guia para se manter mais “seguro” na Internet" - apresentação bem legal do Corvolino feita na Cryptorave 2017

Creative Commons License
Disclaimer: The views expressed on this blog are my own and do not necessarily reflect the views of my employee.