Ambiente de DR: sua empresa está realmente preparada?

Como a maioria dos profissionais de TI sabem, ambiente de contingência ou ambiente de DR (Disaster Recovery) é a infraestrutura que entrará em uso caso um problema grave ocorra por causa de incêndios, enchentes, quedas de energia, erro humano ou caso um malware/ransonware prejudique os servidores ou um datacenter. O ambiente de DR  permitirá que a empresa se mantenha em funcionamento enquanto o problema no ambiente produtivo está sendo solucionado.

Entendido o que é um ambiente de DR, precisamos ter em mente que não é consenso entre muitos gestores se devemos usar ou não usar um ambiente de DR, já que na maior parte do tempo ele não será usado. Mas esta não é a pergunta correta a ser feita. Eles deveriam estar se perguntando “qual será o prejuízo que a minha empresa terá se tivermos uma parada inesperada em algum sistema crítico para o negócio?

A palavra prejuízo neste texto nos leva a refletir sobre diversos aspectos. Dentre eles podemos citar danos à imagem, impacto na reputação do ambiente, perda de clientes, penalidades para o fechamento de contratos, riscos de ciberataques, ausência de treinamento para uma recuperação rápida e muitos outros pesadelos que tiram o sono de qualquer diretor financeiro.

De acordo com a empresa BackBox, especializada em backup e recuperações, 50% de todos os negócios já tiveram algum desastre ruim o bastante para interromper alguma aplicação, sendo 18,5 horas a média para o tempo de inatividade de uma aplicação (downtime). A mesma empresa afirma que pequenos negócios podem enfrentar perdas de US$ 8.000,00 por hora, enquanto empresas médias sofrem perdas entre US$74,000 a US$90,000 por hora. Já empresas de grande porte podem ter perdas que variam de US$700,000 a até US$800,000 por hora que a aplicação crítica ficou sem funcionar.

O estudo da BackBox aponta que cerca de 81% das paralizações duram pelo menos um dia e apenas 35% das pequenas empresas possuem planos de recuperação contra desastres. É impressionante observar que 75% das empresas pesquisadas informaram que seus planos contra paradas inesperadas (desastres) são inadequados. Comecei a me questionar quais passos estariam sendo desenhados de maneira errada?

Insatisfeito com os números, decidi examinar o que revelava o relatório “The State Of Disaster Recovery Preparedness 2017”, feito com a participação da Forrester Research e  o Disaster Recovery Journal. O relatório mostra diversos estudos, envolvendo estratégias para Continuidade de Negócio (BC-Business Continuity) e Recuperação de Desastres (DR-Disaster Recovery). O relatório entrevistou 73 tomadores de decisão, mostrando que:

Note que 45% (34%+11%) dos entrevistados não estão contentes com suas estratégias e sentem-se inseguros. Se realmente uma falha em seus sistemas críticos ocorrer estará em risco não só o impacto nos negócios, mas a reputação e a carreira de todos os responsáveis.

A mesma pesquisa revela que diversos motivos foram revelados para a criação de um ambiente para DR dentre eles podemos citar: competitividade e necessidade de permanecer online, motivos legais, custos das próprias empresas paradas, elevação de riscos naturais ou riscos causados pelo homem, elevação da disponibilidade de uma aplicação crítica, responsabilidade legal, ambiente de DR identificado como prioridade máxima pela diretoria.

Independente do motivo, desenvolver uma estratégia para a contratação de um ambiente de contingência é inevitável para qualquer empresa. Mas se a justificativa for custos, basta olharmos os valores que serão gastos com os prejuízos de uma parada inesperada em um ambiente crítico. Claramente estes custos são superiores do que os custos da grande maioria dos ambientes de contingência. É esta conta que os responsáveis pelo negócio de uma instituição devem fazer, sendo o papel dos gerentes de infraestrutura primordial para que esta visão seja considerada pela diretoria.

Ok, vamos assumir que a contratação do ambiente de DR é prioritária e foi aprovada pela diretoria, é importante destacar que frequentemente um ambiente de Backup é confundido com um ambiente de DR e isto pode trazer sérias complicações.

Pode-se dizer que Backup é a cópia de dados em um disco, fita ou em um ambiente de Cloud e o retorno desta informação em caso de necessidade pode ser muito longo e o tempo cíclico para elaborar a atualização dos dados tende a ser muito longo. Outro ponto importante é o baixo uso de automação, além de grande carga de horas da equipe de TI para guiar a recuperação do ambiente produtivo. Resumindo: muito suor e elevada possibilidade para grandes perdas financeiras.

Se imaginarmos os conceitos ligados a um ambiente de DR, veremos que o tempo entre replicações ou atualização das informações é chamado de RPO (Recovery Point Objective) e que o tempo para recuperar as informações e ativar o ambiente ou recuperar a aplicação prejudicada é chamado de RTO (Recovery Time Objective). Nem sempre isto é compreendido pelas empresas e o resultado é um projeto incompleto ou confuso. Importante destacar que:

 

“Não existem melhores práticas para serem usadas, tudo vai depender do negócio de cada empresa.”

 

Em um ambiente envolvendo o conceito de Disaster Recovery (DR) veremos que é indispensável a presença de mecanismos para a automação, estejam eles ligados a replicação de informações ou estejam eles ligados a orquestração para que as máquinas e bancos de dados sejam ligados na ordem correta.  Resumindo: temos aqui baixíssimo suor usando ferramentas para obter mínimas perdas financeiras.

Com isto em mente, muitas empresas acreditam que é suficiente, mas isto é um grande engano. É necessário ter uma equipe bem treinada, sendo apoiada por um bom run book. Um run book é um documento com a sequência de procedimentos e rotinas que devem ser seguidas por cada equipe envolvida no ambiente de DR.

Para finalizar, vamos imaginar um ambiente produtivo virtualizado que necessita ser protegido com a presença de uma estrutura de DR operando em um Data Center remoto. Quais as atividades recomendadas para a construção deste ambiente?

  • Primeiro deve-se mapear todas as aplicações realmente críticas para o negócio, juntamente com o impacto caso estas aplicações parem inesperadamente o seu funcionamento;
  • Depois é importante analisar se as aplicações identificadas estão devidamente configuradas, sem a configuração excessiva de disco, processamento ou memória RAM;
  • Com a validação do size correto das aplicações, é necessário analisar o impacto financeiro. Quanto tempo o negócio aceita ficar com suas principais aplicações sem atividade? O resultado desta análise é a definição do RPO e RTO;
  • Definidos o RTO e RPO, basta criar o run book;
  • O quinto ponto é o mais importante, estando ele centrado em pessoas. Sendo necessário:

I. Nomear uma equipe multidisciplinar para a elaboração das atividades quando for decretado o uso do ambiente de DR. Importante considerar não só membros da equipe técnica, mas também membros da diretoria ou da equipe jurídica. Deve-se nomear uma pessoa que será a representação da empresa para elaborar comunicados aos jornalistas e a mídia eletrônica, reduzindo as perdas na imagem da instituição;

II. Capacitar e treinar a equipe para elaborar simulações validando as atividades contidas com testes de DR. O resultado dos testes deve gerar um relatório com todos os pontos de melhoria;

III. Com os resultados das simulações, a equipe deve elaborar testes de DR duas vezes no ano. O resultado dos testes deve gerar um relatório apontando as evidências de cada atividade feita proporcionando auxílio ao processo de auditoria ou aos investidores da empresa;

Tenha em mente que as atividades “a” e “b” possuem o objetivo de reduzir custos do ambiente de DR. Este ambiente deve impactar minimamente a equipe envolvida, sem abrir mão de transparência, simplicidade operacional e deve-se ter suporte de uma equipe externa devidamente capacitada sempre que necessário.

 

Denis Souza

 

Links Recomendados:

 

4 fatores importantes sobre nuvem e continuidade de negócios que você precisa saber agora mesmo

Os departamentos de TI estão sob constante pressão para disponibilizar novas tecnologias que permitam que a empresa mantenha dados críticos, aplicações, processos seguros e em funcionamento 24 x 7.

Some a isto ofertas de nuvem que permitem que a empresa terceirize parte da responsabilidade pela gestão e garantia de segurança e confiabilidade e temos o ambiente perfeito para a continuidade de negócios e recuperação de desastres ser deixada para segundo plano frente aos desafios do dia-a-dia de gerenciamento de TI.

Ao utilizar serviços baseados na nuvem é fácil perder de vista os principais riscos de continuidade de negócios e por isso listamos aqui 4 pontos importantes que você deveria ter em mente enquanto utiliza cloud computing para sua empresa.

 

1. Continuidade de negócios é mais que recuperação de desastres

A indústria é permeada com termos como “continuidade de negócios” e “recuperação de desastres”, o que pode torná-lo confuso para os líderes empresariais. Mesmo o termo “recuperação de desastres” leva a maioria dos profissionais de TI para o caminho errado.

Soluções de DR são normalmente utilizadas para “cenários de desastres” e “desastres” relacionados a causas naturais não são a causa mais comum de interrupção de TI.

Falhas de software, hardware e erro humano são as principais categorias responsáveis ​​por algum tipo de interrupção no negócio.

As empresas precisam de parar de pensar apenas em desastres e começar a considerar maneiras de evitar interrupções.

 

2. As nuvens nem sempre incluem alta disponibilidade e / ou garantia de continuidade de negócios

A todo momento o serviço de nuvem é entregue a partir de um Data Center.

Se esse Data Center tiver problemas, o fornecedor de nuvem pode mover suas cargas de trabalho rapidamente para um novo Data Center?

Sempre verifique como a empresa lida com isto para poder decidir como se preparar para isto.

Muitas vezes os players de nuvem pública disponibilizam maneiras de garantir a continuidade de negócios utilizando replicação de dados em Data Centers localizados em regiões distintas.

Fique atento: este recurso não é padrão na oferta de nuvem e precisa ser configurado individualmente na maioria dos casos.

 

3. A localização dos servidores garante mais do que latência

A nuvem não é um lugar mágico – onde seus arquivos são armazenados fisicamente realmente importa.

A localização dos servidores da nuvem pode afetar a velocidade de acesso e preços, mas é um erro pensar em localização apenas por este prisma.

Quando falamos em continuidade de negócios, localização em região diferente da principal e eventualmente o uso de fornecedores distintos realmente é algo a ser considerado.

 

4. Backup nem sempre é parte da oferta padrão

Fornecedores de nuvem nem sempre oferecem backup de dados armazenados dentro das métricas necessárias para o negócio de sua empresa.

Alguns fornecedores sequer oferecem backup dos dados como parte padrão de sua oferta.

Por padrão assuma que o fornecedor não oferece garantias e verifique com o mesmo como ele lida com backup, antes de definir um plano para isto.

 

Continuidade de negócios é um tema importante para você?

Se você quiser discutir os cenários de continuidade de negócios, com garantia de alta disponibilidade, segurança e conectividade integradas às ofertas em nuvem, entre em contato conosco pelo telefone (11) 3092 6161 ou pelo nosso formulário de contato.

 

Oracle Database Vault: introdução a Realm

RESUMO

Objetivo deste artigo é explorar uma outra feature do Oracle Database Vault, o Realm. Veremos como é possível impedir o acesso de super users a determinado objeto, role ou mesmo a schemas inteiros.

 

INTRODUÇÃO

Este é o terceiro de uma série de artigos introdutórios a Oracle Database Vault (ODV). Vimos como configurar, as principais mudanças nas atividades do DBA e a segregação de funções em [1]. Vimos também como funcionam Factor, Rule, Ruleset e Command Rule em [2] e como podemos combiná-los para proteger um objeto, um schema ou mesmo o DB inteiro contra determinada instrução SQL.

Usaremos novamente um DB na versão 12.1.0.2 com o ODV habilitado com as configurações defaults, acrescentando apenas com as mudanças realizadas nos artigos anteriores, mas elas não necessárias. Teremos o C##DONO que possui a role DV_OWNER e o C##CONTAS com a DV_ACCTMGR.

O componente que trataremos neste artigo será o Realm (Domínio) e tentaremos ilustrar sua funcionalidade com alguns exemplos. Ele atua como um nível de proteção “mais forte” que os conhecidos privilégios de sistemas/objetos. O escopo pode ser específico a nível de determinado objeto ou amplo como tipos de objeto ou schemas.

 

CENÁRIO PARA TESTE

Para preparar nossos testes, vamos começar com a criação de users e roles que serão necessários. Contextualizando também o cenário inicial, vemos que é possível com o SYS consultar todos os objetos do schema HR mesmo com o ODV habilitado.

 

Vamos criar um user USER_CONSULTA_HR que possuirá permissão de leitura em HR.EMPLOYEES e HR.DEPARTMENTS.

 

Criaremos também uma Role que utilizaremos no último exemplo:

 

REALM

O Realm é como uma zona de proteção em que você pode colocar roles, objetos ou mesmo schemas inteiros. Com ele, é possível blindar os dados contra usuários com privilégios de sistema (como SELECT ANY TABLE, por exemplo). E isso inclui, especialmente, proteção contra o DBA [3].

Adicionar o schema HR dentro de um Realm, por exemplo, provocará erros de falta de privilégios caso seus objetos sejam acessados por um DBA ou alguém que possua SELECT ANY TABLE.

Os atributos de um Realm são:

– Name

– Description

– Enable

– Autid Option

– Type

Os dois primeiros são triviais, olhemos então para o Enable. Mas este também é trivial! Sim, só gostaríamos de chamar a atenção de como devemos utilizá-lo aplicando a API disponibilizada. Os valores aceitos para Enable são estes abaixo:

– DBMS_MACUTL.G_YES (default)

– DBMS_MACUTL.G_NO

 

Podemos também definir quando auditaremos os acessos. As opções são simplesmente não auditar, auditar falhas, auditar sucessos ou ambos.

Audit_options:

– DBMS_MACUTL.G_REALM_AUDIT_OFF (default)

– DBMS_MACUTL.G_REALM_AUDIT_FAIL

– DBMS_MACUTL.G_REALM_AUDIT_SUCCESS

– DBMS_MACUTL.G_REALM_AUDIT_FAIL + DBMS_MACUTL.G_REALM_AUDIT_SUCCESS

Quanto ao tipo, a discussão é interessante e tentaremos mostrar em detalhes através de exemplos. Há dois tipos: o REGULAR (0) e o MANDATORY (1).

A diferença entre começa no fato de que o REGULAR protege apenas os objetos contra users com “privilégios de sistema” (SELECT ANY TABLE). Porém, isso não impede de usuários que tenham privilégio de objetos de realizar a consulta (grant de SELECT/READ explícito nos objetos do HR ou via ROLE).

Já o Realm MANDATORY é um pouco mais restritivo. Nem mesmo os usuários com privilégio de objeto poderão consultá-los. Neste caso, é necessário conceder “privilégio no Realm” ao usuário que pretende fazer o acesso. Vale frisar que esta discussão inclui o owner dos objetos protegidos. Ou seja, se protegermos o HR com um Realm MANDATORY, ele perde a permissão de consultar os próprios objetos. Interessante, não?

 

Vejamos como funciona primeiramente os Realms do tipo REGULAR.

 

Aqui temos um Realm, entretanto, ele ainda não protege nada. Precisamos dizer quais são os objetos que ele deve englobar. Podemos especificar owner, nome do objeto ou mesmo seu tipo e caso precise generalizar, pode ser utilizado o “wildcard”: ‘%’. Vamos começar adicionando a tabela HR.EMPLOYEES abaixo dele.

 

A partir de agora, usuários com privilégios de sistema não conseguirão mais ver os dados desta tabela. Veja o que ocorre com o SYS:

 

Porém, aqui ainda é possível o acesso de users que possuam privilégios do objeto, como é o caso do USER_CONSULTA_HR:

 

Antes de avançar, vamos ver como estão as configurações e aproveitaremos para conhecer as views com os metadados de Realms:

 

Até aqui nenhum segredo, falamos de todos estes atributos. Vejamos como está nosso ambiente.

 

Note que tivemos um outro efeito com esta proteção: não é mais possível conceder permissão de leitura nesta tabela. Resolveremos este ponto adiante.

 

Explorando um pouco mais o conceito de Realm, vamos falar do tipo que é mais restritivo, o MANDATORY. Como citado acima, ele impede quem tenha privilégios de sistema, privilégios de objetos e até mesmo o owner de fazer consultas em objetos protegidos.

Para ilustrar, vamos alterar o tipo do Realm PROTECT_HR para MANDATORY e, com isso, esperamos que o USER_CONSULTA_HR perca o acesso de leitura, visto que será necessário um privilégio a mais para conseguir “chegar” aos dados [4].

 

Consultando novamente, vemos que temos um Realm MANDATORY:

 

Vamos testar o acesso de USER_CONSULTA_HR aos dados protegidos (EMPLOYEES) e não protegidos (DEPARTMENTS).

 

Veja o que ocorreu com o HR:

 

O próprio owner perdeu acesso a seus dados. É nesse sentido que afirmamos que o MANDATORY é mais restritivo. Segundo a documentação, com sua utilização é necessária autorização explícita ao Realm. Ou seja, para acessar os dados, além dos devidos privilégios de objeto, será necessária autorização no Realm.

O que seria esta autorização no Realm? São dois os tipos de permissão: Participante (DBMS_MACUTL.G_REALM_AUTH_PARTICIPANT) ou Owner (DBMS_MACUTL.G_REALM_AUTH_OWNER). A principal diferença no tipo de autorização é que o tipo PARTICIPANT não permite a concessão de privilégios sobre os objetos protegidos. Para isso, é necessário a autorização do tipo OWNER.

Autorizando o USER_CONSULTA_HR como PARTICIPANT, resolverá o problema da falta de privilégio. Veja:

 

Precisamos também aumentar nossa query (removemos alguns campos para simplificar) que verifica a configuração atual, adicionando outra view:

 

E agora podemos ver que USER_CONSULTA_HR é PARTICIPANT do Realm PROTECT_HR. Será que isso resolve o problema de falta privilégio? Resolvido.

 

Para ilustrar a diferença, vamos conceder o mesmo nível de privilégio para o HR e em seguida vamos resolver um outro ponto citado acima.

 

O problema citado foi o user HR não conseguir conceder privilégio de leitura em uma tabela protegida, embora consiga agora acessar a tabela.

 

Para que seja possível, precisamos alterar o tipo de privilégio do HR para OWNER do Realm.

 

Agora temos:

 

Isto resolve nosso problema, confira:

 

Faltou ainda falar de um outro atributo da “autorização” a nível de Realm, os Rulesets. Deseja permitir o acesso apenas se determinadas condições forem verificadas? A partir de determinado host? Apenas em certos horários? Este é o ponto chave para atingir este objetivo. Falamos de Rulesets em [http://www.oracle.com/technetwork/pt/articles/idm/rule-ruleset-command-rule-vault-3038750-ptb.html] e citamos que elas poderiam ser utilizadas aqui.

Aumentando a especificidade do nosso exemplo, aproveitarei para incluir um questionamento que nosso time recebeu da equipe de Sec. Como fazer para que a concessão de privilégios tenha prazo de validade? Com os pontos que já discutimos nos artigos anteriores, temos condições de resolver este ponto.

Faremos agora com que o Realm só permita acesso do USER_CONSULTA_HR aos dados até um horário determinado: 10h 35min do dia 18/06/2016. É uma forma não depender de uma ação manual para removê-lo no futuro. Vale enfatizar que o Ruleset está vinculado com a autorização e, portanto, pode afetar apenas determinado user.

Vamos criar uma Rule e um Ruleset e associá-los.

 

Precisamos também alterar a autorização dada ao USER_CONSULTA_HR para que seja também validado o Ruleset:

 

Verificando a configuração, temos:

 

E finalmente, só admirar o resultado:

 

Último ponto que discutiremos nesta introdução a Realms, será como proteger também as Roles. No começo do artigo criamos uma role ROLE_READ_SCOTT. Vamos conceder privilégio de leitura em uma tabela do SCOTT e em seguida criar um Realm para proteger a Role. Depois, tentaremos conceder outro privilégio.

 

Grant concedido com sucesso. Agora a criação do Realm e incluindo a Role na proteção.

 

Analisando o resultado:

 

E agora que a Role está protegida, podemos conceder privilégio de leitura na SCOTT.DEPT?

 

A forma de “resolver” a violação é fazer com que o SCOTT tenha autorização de OWNER no Realm.

 

E o resultado:

Desta forma, vimos que podemos evitar que privilégios sejam adicionados ou removidos de determinada Role se a protegermos com Realm. Somente quem for autorizado como OWNER do Realm poderá fazer o Grant/Revoke.

 

CONCLUSÃO

Neste artigo exploramos uma outra feature poderosa do Oracle Database Vault. Este é o componente responsável por impedir o acesso de usuários privilegiados aos dados sensíveis. Vimos os diferentes tipos de Realms e que podemos escolher quando auditaremos os acessos (ou tentativas). Falamos também o quão específico ou genéricos podemos ser quando o assunto é proteger os dados.

Há ainda pontos a serem explorados nós próximos artigos como autorização para datapump e patches, auditoria, roles, schedulers, etc. Faremos na medida do possível.

 

REFERÊNCIA

[1] http://www.oracle.com/technetwork/pt/articles/idm/seguranca-oracle-database-vault-2999070-ptb.html

[2] http://www.oracle.com/technetwork/pt/articles/idm/rule-ruleset-command-rule-vault-3038750-ptb.html

[3] https://docs.oracle.com/database/121/DVADM/cfrealms.htm#DVADM70144

[4] https://docs.oracle.com/database/121/DVADM/cfrealms.htm#DVADM71156

 

Ataques DDoS atingem novo patamar, qual será o futuro?

Sempre me questionei a respeito do que aconteceria se um ataque digital fosse feito usando centenas de milhares de dispositivos móveis ao redor do mundo, e me deparei no passado perdendo o sono diversas vezes com algo desta magnitude. Infelizmente hoje podemos dizer que algo similar aconteceu recentemente no mês de setembro e outubro deste ano. Neste cenário, é fácil dizer que não foi surpresa o ataque ter acontecido, mas foi realmente uma surpresa a forma como foi feito.

Preocupado com este cenário, venho acompanhando o crescimento do número de dispositivos conectados à internet, sejam eles celulares, tablets, câmeras, roteadores wireless ou diversos outros tipos de equipamentos, há mais de 3 anos e facilmente ver-se que existe um crescimento surpreendentemente a cada ano. Segundo o Juniper Research, uma empresa especializada na elaboração de pesquisas, em 2020 teremos mais 38,5 bilhões de dispositivos conectados em todo o mundo. Considerando que todos nós certamente pensamos em segurança em um dispositivo antes de conectá-lo a internet, imagine o tamanho do estrago que teremos quando 38,5 bilhões de dispositivos estiverem enviando e recebendo informações em diversos cantos do mundo? Só no Brasil, segundo um estudo realizado pela Fundação Getúlio Vargas, existem mais usuários de smatphones do que de notebooks e tablets, adivinhe o novo resultado desta pesquisa quando tivermos mais opções a um preço menor para compra.

Olhando de forma ampla, podemos dizer que as opções para este post são muitas. Poderia eu aqui falar do crescimento espantoso de malwares bancários para dispositivos móveis, já que um recente levantamento da Kaspersky Lab, uma importante referência para pesquisas envolvendo o tema segurança, detectou mais de 77.000 trojans bancários, sendo 98% projetados para o sistema operacional Android, mas não vou! Poderia também discutir neste post a ameaça que expos mais de 100 milhões de usuários do WhatsApp, mas também não vou abordar isto hoje! Então, pelo amor de Deus, que tema você vai falar Denis?

Vamos detalhar o ataque digital que ocorreu em 21 de outubro nos servidores da Dynamic Network Services, conhecida como Web Dyn. Primeiramente é importante saber que a Dyn conduz o acesso a sites como Twitter, Netflix, Spotify ou CNN através dos seus servidores de DNS (Domain Name System) e ao receber este ataque, mais de 1,2 mil sites ficaram inacessíveis. Entenda que quando navegamos pela internet, precisamos dos servidores de DNS para apontar onde estão os sites desejados e sem eles nenhum ambiente Web pode ser alcançado.

As análises iniciais da própria Dyn apontam que o ataque superou 50 vezes a volumetria de seu acesso normal, recebendo uma volumetria maior que 1.2Tbps com origem em localidades como Ásia, América do Sul, Europa e US. Observe que a complexidade deste ataque poderia prejudicar qualquer site isoladamente, seja em grande ou pequena escala de impacto, mas acredito que neste caso certamente foi feito um estudo detalhado envolvendo a relação fragilidades vs impacto. Não tenho dúvida que a Dyn tinha diversas proteções, poderia ter sido bem pior se não tivesse, mas nada poderia preparar para o que aconteceu. O objetivo final de quem fez o ataque era afetar o máximo de empresas possível e isto segue o padrão do novo atacante digital, que é capaz de elaborar atividades focadas sempre em maior poder de devastação.

Entretanto, como podemos classificar ou identificar este ataque? Primeiro ponto, o alvo foi a infraestrutura da Dyn, impedindo que seu principal negócio fosse acessado. O volume de requisições recebido foi muito superior ao planejado. O segundo ponto que devemos analisar baseia-se em no fato de que o acesso à internet e a consulta a dispositivos como firewalls, roteadores e switchs recebeu tantas conexões que saturou, prejudicando seu funcionamento. Provavelmente foi até o momento o ataque mais complexo e sofisticado deste tipo já feito. Com isto podemos concluir que é o comportamento devastador de um ataque chamado Distributed Denial of Service/Ataque de Negação de Serviço (DDoS).

O primeiro ponto importante do ataque a Dyn é que o atacante estava se preparando há algum tempo, fazendo uso de maneira inteligente e coordenada do código público pertencente ao malware mirai, que afeta ambientes com o sistema operacional Linux e transforma-os em ambientes controlados remotamente.  Em linhas gerais podemos dizer que o atacante digital se aproveitou do conceito que guia a Internet of things/Internet das Coisas (IoT) e infectou diversos dispositivos ligados a internet, principalmente câmeras e dispositivos caseiros de armazenamento usando seus acessos conhecidos. Um ambiente infectado pelo Mirai vasculha continuamente a internet procurando por dispositivos não contaminados usando uma tabela com nomes comuns de usuários e senhas padronizados por fabricantes.

Note que nenhum ataque complexo buscando por falhas em programas foi feito e para remover o controle do Mirai basta remover o cabo de rede, reiniciar o dispositivo e mudar a senha do usuário administrador no dispositivo. Veja que as bases para um ataque desta magnitude estão na fragilidade humana, que novamente não seguiu regras simples baseadas na modificação de um usuário e senha.

Quem estuda segurança da informação identifica estes traços na técnica chamada de engenharia social. Tal técnica está presente na séria de ficção Mr. Robot, que em pouco tempo se tornou a primeira produção original do USA a ser indicada na categoria Melhor Série Dramática concorrendo a um Emmy, um dos maiores prêmios da TV. Mr Robot é uma série criada por Sam Esmail, Steve Golin (True Detective) e Chad Hamilton, sendo produzida pela Universal Cable Productions e encontra-se na segunda temporada, sendo exibida aqui no Brasil pelo canal Space.  A história acompanha a vida de Elliot (Rami Malek, de The Pacific), um jovem programador que sofre de uma desordem que o torna antissocial. As atividades de Elliot chamam a atenção de Mr. Robot (Christian Slater, de Mind Games), um misterioso anarquista que o convida a fazer parte de uma organização que atua na ilegalidade com o objetivo de derrubar as corporações americanas.

Retornando ao tema do nosso post, quero concluir dizendo que infelizmente tenho visto minhas previsões se concretizarem e a tendência é que encontremos pesadelos mais frequentes nas mesas de CSO, Gerentes de TI e diversos membros do board de corporações. Segurança é algo que não podemos descartar, precisamos ter sempre em mente que ataques como o sofrido pela Dyn estão e estarão cada dia mais presentes, necessitando do apoio de empresas de Data Centers, provedores de acesso internet e diversos especialistas que saibam quais são os caminhos para proteger contra quaisquer ataques digitais.

 

Denis Souza

 

Links indicados:

Kaspersky Lab detecta mais de 77 mil trojans bancários em dispositivos móveis

27ª Pesquisa Anual do Uso de TI, 2016 – Estudo da Fundação Getúlio Vargas

Quantidade de objetos conectados no mundo alcançará 38,5 bilhões em 2020

Dyn Analysis Summary Of Friday October 21 Attack

 

Por onde anda o seu dinheiro? – O início da investigação

Quem de nós nunca se referiu à pessoal escassez econômica ou mesmo viu alguém referir-se ao triste desprovimento monetário, com aquele gesto universal onde o sujeito puxa para fora, e expõe seu límpido e inócuo bolso, em prova à total falta de notas ou moedas.

fsf

Porém, em tempos modernos, onde a circulação de cédulas bancárias ou moedas têm sido cada vez mais sufocadas pelos usuais e funcionais evolutivos métodos de “escambo” (chegaremos lá), tal gestual expressão ainda é comum. Mas vamos falar num sentido mais amplo, onde a dúvida maior sobre o paradeiro do seu dinheiro, realmente ainda é um mistério para muitos.

Desmistificando o dinheiro …

… mas antes, não temos como fugir da história, afinal a moeda, como hoje a conhecemos, é o resultado de uma longa evolução.

Há muitos e muitos séculos atrás ele não existia, mas, como sempre existiu a necessidade de comprar, as pessoas da época tiveram que dar um jeitinho e resolver o problema.

A primeira solução foi fazer trocas, então, como por exemplo se uma pessoa tinha colhido muitas frutas, mas precisava de peixe, e partia à procura de quem estivesse interessado nas frutas, mas também tivesse pescado em excesso, por exemplo. (*Daí o uso do sistema de comércio, chamado também de escambo). *Atualmente ainda encontramos pessoas que se utilizam dessa prática, inclusive há sessões específicas nos classificados ou dos jornais para anúncios de trocas, mas é claro que em escala muito menor do que antigamente. Outra situação identificada apenas pelos pais dos pequeninos, é o caso, por exemplo, da criança que troca com o coleguinha um brinquedo caro por outro de menor valor, qual deseja muito, sem preocupar-se com o valor diretamente relacionado.

dgsgrs

Contudo, embora de certa forma esse sistema suprisse as necessidades de sobrevivência, muitas vezes era difícil ter a noção do real valor da mercadoria a ser trocada. Assim, cada civilização arrumou uma forma de dar valor às mercadorias baseado em elementos que tinham algum significado. Aceitas por todos, assumiram a função de moeda, elementos dos mais variados como troca: gado, sal (que deu origem na Roma antiga ao nosso bendito salario), bambu etc.

sgerhgdf

Avançando rapidamente alguns séculos para seguirmos a velocidade que o nosso tempo exige, passamos da moeda-mercadoria, para a moeda metálica (ouro, prata e cobre), moeda-papel, cheques, … (proposital o não menção dos ‘modernos’ meios atrelados ao sistema bancário, afinal, esse exigiria alguns extensos tópicos adicionais)

Enfim, o que antes exigia-se do palpável elemento monetário, onde a expressão do bolso vazio, fazia muito mais sentido e que expressava literalmente a realidade, agora está sendo amplamente substituído pela praticidade do que o sistema bancário, tecnologicamente munido da praticidade do avanço que a internet (incluamos toda a tecnologia imputada nela) e necessidade de mobilidade têm trazido.

Isso responde inicialmente à pergunta: “Por onde anda seu dinheiro? ”

Proporcional ao consumo do meio escolhido, ele está em geral, de modo superficial, navegando e ‘voando’ pela rede mundial… sendo processados pelas administradoras de cartões, de passagem por algum smartphone, smartwatch, carteiras eletrônicas, instituições financeiras ou outro meio que surge ou é utilizado à cada novo momento ou boom inovador. (Esse artigo apenas abre a oportunidade de aprofundarmo-nos no tema)

O que antes era ficção nos tempos dos Jetsons, hoje é um presente passageiro, onde avançamos rapidamente para ser passado.

Então, fará cada vez menos sentido a gestual exposição do pano vazio de nossos bolsos físicos, sendo substituídos por indicativos azuis, verdes ou vermelhos, apontando positivo ou negativo de nossas contas, aplicativos ou instituições que que as fintechs estão cada vez mais em velocidades estrondosas, nos apresentando e dando continuidade ao estímulo que a criatividade humana  e encontrar novas formas de intermediar as trocas de aquisição de bens e serviços.

Abraços e até o próximo post.

Rodrigo Godoi

 

 

Indisponibilidade de aplicações: Qual é o prejuízo para a sua empresa?

Passei alguns anos da minha carreira construindo projetos em ambiente de Data Center requisitados por diversas empresas de setores industriais distintos e muitas vezes percebi que o tema indisponibilidade e seus efeitos para o negócio como um todo não eram abordados com o aprofundamento necessário ou eram esquecidos ao se “espremer” por redução de custos. Lembro que em muitas reuniões tive que revelar este tema e perceber que era tratado com certa surpresa.

Se observarmos o relatório publicado pela Veeam (2016 Veeam Availability Report) feito com 1.140 tomadores de decisão de TI de 24 países, veremos claramente que as necessidades da corporação estão bem distantes de serem atendidas, e que as empresas de uma forma mais macro, precisam fazer da disponibilidade uma prioridade estratégica ou estarão arriscando a perda de até 16 milhões de dólares por ano em receita. Para ficar mais claro, vamos comparar os dados de 2014 com as informações obtidas em 2016:

  • O tempo de inatividade anual não planejado foi elevado:
    • 1,4 a 1,9 hora para aplicações essenciais.
    • 4 a 5,8 horas para aplicações não essenciais.
    • O número médio de eventos aumentou (de 13 para 15 eventos).
  • O custo médio anual do tempo de inatividade para uma organização pode chegar até US$ 16 milhões (US$ 6 milhões a mais que 2014).

É sempre importante destacar que o preço de uma indisponibilidade para um ambiente de produção pode ser mais impactante do que se pode imaginar. Observe a figura seguinte:

 

blog56546

 

Veja que mais da metade dos entrevistados (68%) revela que a confiança na organização pode ser afetada e 62% afirma que a confiança na marca pode sofrer danos. Os dados revelam que foram notadas quedas nos preços das ações, juntamente com a presença de processos judiciais. São dados que precisam e devem ser levados em consideração.

Imaginemos este acontecimento em empresas que operam com bolsa de valores ou com compras pela internet. É inaceitável imaginar que os consumidores de hoje aceitariam esperar 1 minuto para um site retornar ao funcionamento com o objetivo de concluir a sua compra. Questionar suas instituições se estão à altura deste desafio é uma tarefa que todos os líderes de negócio deveriam fazer.

Outro ponto importante para ser avaliado está centrado na causa do e nos efeitos do temido downtime (quedas funcionais) de uma aplicação. Quase metade dos entrevistados (48%) reportaram que suas organizações tiveram repetitivas experiências com quedas causadas pelo uso de upgrades na aplicação ou problemas gerados por correções feitas no sistema operacional. Aqui vale o questionamento: onde estão os ambientes para homologação e onde estão as metodologias para aplicação das correções em ambientes com cluster balanceados por cargas de trabalho?

Observe que a presença de um balanceamento de cargas é um importante aliado para corrigir um grupo de aplicações que apresentou algum tipo de problema. Outro elemento importantíssimo é o teste de backup. Somente 41% dos entrevistados afirmaram que usam seus backups como parte dos testes de recuperação e ainda assim, este backup possui uma recuperação em dias relativamente pequena. No Brasil, a média foi de 11 dias de dados recuperados por mês, na Alemanha 12 dias e na Itália 14.

Para concluir, é importante termos em mente que o desenho de qualquer projeto, seja ele físico ou virtual, deve considerar a sobrevivência da aplicação mesmo em condições de falhas. Claro que o desafio é sempre alinhar custos com perdas financeiras causadas pela ausência funcional da aplicação. Acredito que os números apresentados pela Veeam mostram que existe um longo caminho a ser trilhado, mas que existe solução se pensarmos estrategicamente com cuidado.

 

Denis Souza

 

Links indicados:

https://go.veeam.com/2016-availability-report-latam-br.html

http://convergecom.com.br/tiinside/home/internet/19/02/2016/indisponibilidade-de-aplicacoes-gera-prejuizo-de-us-16-milhoes-por-ano-as-empresas/

http://computerworld.com.br/brasileiras-perdem-us-18-milhoes-com-indisponibilidade-de-aplicacoes

6 mitos inacreditáveis sobre segurança em nuvem

Toda semana dedico um bom tempo a entender quais são os principais problemas e oportunidades que a área de TI das empresas enfrenta no dia a dia e em uma das pesquisas encontrei um artigo da Forbes que colocava segurança como uma das principais preocupações de CIOs para 2016.
Descobri ao mesmo tempo que este é um dos fatores que tem desestimulado a adoção rápida de cloud computing por algumas empresas.

Segurança em cloud? Como assim?

Conversei com diversos especialistas em cloud e segurança, e em nenhum momento consegui chegar à conclusão de que a tecnologia aplicada à maioria das nuvens era determinante para tornar a computação em nuvem mais vulnerável que um ambiente tradicional de TI.

Então, por que tanta insegurança com a segurança?

insegurança
sensação ou sentimento de não estar protegido, seguro.

Um dos motivos é comportamental. O fato da tecnologia de nuvem ser nova pode causar um comportamento mais conservador, fazendo com que alguns profissionais prefiram aguardar testes e casos de sucesso de outras companhias para tomar sua decisão – mesmo isto implicando em agir de forma mais lenta e reativa com relação ao mercado.

O outro motivo é basear-se em informações incorretas. A verdade é que alguns pontos que tenho observado sobre esta insegurança são na verdade fruto de mitos propagados constantemente pela internet e que apenas reforçam uma informação imprecisa, impedindo que profissionais de TI tomem decisão com base em fatos.

Há ainda uma parcela das decisões de adoção de nuvem que estão de fato baseadas em características muito específicas e incomuns que fazem com que a segurança seja um impeditivo.

Chegou a hora de separar verdade de ficção e acabar com alguns mitos sobre segurança na nuvem (IaaS)!

MITO 1: NUVENS PÚBLICAS NÃO SÃO SEGURAS.

O ambiente de nuvem pública pode ser ainda mais seguro do que um ambiente on-premisses ou mesmo um Data Center. O fato é que nenhuma nuvem é igual a outra e por isso o importante é que as empresas tenham critérios claros de controle e visibilidade desejados.

Por se tratar de um ambiente compartilhado, na maioria das vezes os controles aplicados à nuvem são mais rígidos do que em ambientes on-premisses.
Diversas regras de segurança são aplicadas na camada física da infraestrutura, além de existir isolamento lógico entre todos os clientes, fazendo com que os ambientes estejam blindados contra acessos não autorizados.

Um exemplo disso é que o UOLDIVEO, para reduzir os riscos de clientes e do próprio UOL, atualiza constantemente suas tecnologias, regras de firewalls, planos de mitigação de vulnerabilidades para todos componentes de infraestrutura baseado na detecção de tentativas de ataques, além de segmentação de rede e aplicação de patchs de segurança.

MITO 2: SEGURANÇA EM NUVEM É UM NOVO DESAFIO.

A verdade é que a segurança na nuvem não é uma preocupação nova.
A computação em nuvem tem mudado muita coisa no mundo da infraestrutura, mas a maioria das preocupações de segurança, como proteger a infraestrutura e os dados sensíveis, são preocupações antigas.
Requisitos de segurança e de governança são os mesmos independentemente de componentes físicos, virtuais ou de nuvem. Na nuvem, a maneira pela qual as mudanças na infraestrutura acontecem tornam controle e visibilidade ainda mais importantes.

MITO 3: COMPLIANCE É O MESMO QUE SEGURANÇA.

Muitas empresas acreditam que se o provedor de nuvem é certificado, seus sistemas são seguros e invulneráveis à ataques.
Na verdade, o certificado não garante a segurança. Apenas confirma que o que estava definido, foi cumprido no momento da auditoria.
Muitas vezes, os padrões de conformidade às políticas e procedimentos dependem de pessoas ao invés de sistemas automatizados e por isso podem ocorrer falhas entre auditorias. Acreditar que ter certificação é o mesmo que ter segurança – e vice-versa – coloca a empresa em risco.

MITO 4: CLIENTES DE UMA MESMA NUVEM PODE ATACAR UNS AOS OUTROS.

Em uma nuvem pública como VMware vCloud Air, OpenStack, AWS ou Microsoft Azure, os clientes compartilham recursos de computação, armazenamento e recursos de rede.
Como os recursos físicos são compartilhados, muitas empresas se preocupam que sejam atacadas por outros clientes que utilizam o mesmo serviço. Na verdade, existem diversas questões que garantem a proteção entre clientes.

Invadir a camada de virtualização, por exemplo, não é simples. Há poucos relatos deste tipo no mundo e casos deste tipo ocorreram elevando o nível de permissão de um usuário existente, dentro do painel de gestão.

Para evitar isto, é possível isolar a camada de gerenciamento, colocando-a em uma rede separada e ainda que estejam na mesma rede, é possível fazer o isolamento da VLAN.

MITO 5: INVASÕES VIA INTERNET SÃO MAIS AMEAÇADORAS NA NUVEM DO QUE EM UM DATA CENTER.

Ameaças vindas da Internet são reais, mas não são mais ameaçadoras na nuvem do que para qualquer outro ambiente.
Alguns dos principais problemas de segurança em nuvem incluem violações de dados, invasão de conta, APIs inseguras e negação de serviço (DDoS). Estas preocupações não são novas quando falamos em serviços conectados à Internet.
Uma variedade de proteções pode ser utilizada contra esses ataques, que vão desde firewalls, varredura de vulnerabilidades e criptografia para prevenção de intrusão de rede, até credenciais inteligentes.

MITO 6: VOCÊ NÃO PODE CONTROLAR ONDE SEUS DADOS RESIDEM NA NUVEM.

A localização dos dados é uma preocupação importante e muitos países têm leis que não permitem a exportação de dados pessoais ou o seu armazenamento em outro país.
Quando a residência de dados é uma preocupação, especialmente para informações pessoais como informações de saúde, impostos e financeiras, a escolha do provedor de nuvem deve basear-se onde o service provider mantém seus Data Centers em nuvem.
Empresas que fornecem serviços em vários continentes devem, pelo menos, escolher um provedor de serviços que possa satisfazer essas necessidades com Data Centers aderentes à política de cada país.

 

Gostou deste post? Aproveite e baixe gratuitamente nosso whitepaper “Nuvem híbrida: deixe as preocupações com segurança no passado” e saiba mais sobre segurança em nuvem.

Dica: Este whitepaper acima pode ser ainda mais interessante se sua empresa utiliza ambiente virtualizado em tecnologia VMWare.

Alerta: Novo malware se espalha agressivamente pela internet

A internet recebeu mais um convidado indesejado e provavelmente vai fazer muito mais que simples barulho. Estamos falando de um malware que usa o código do conhecido BARTALEX. Já é possível identificar uma elevação muito acentuada de e-mails contendo-o, principalmente para usuários do Office 365.

O BARTALEX explora os recursos de macros e já é conhecido desde abril de 2015. Inicialmente era disseminado por SPAMs usando URLs que exibiam uma página pedindo para o usuário habilitar macros em um documento Microsoft Word. Se esta atividade fosse feita, um download do malwareTSPY_DYRE.YUYCC era feito para monitoramento de atividades bancárias.

O novo malware deposita o BARTALEX no campo de formulário de um arquivo do tipo “dotm” para evadir a detecção de macros. O mesmo apresenta alto grau deobfuscação (técnica usada para evitar que seu código seja visto e seu funcionamento entendido), além de utilizar codificação RC4 para proteger e dificultar sua detecção. O código do BARTALEX foi modificado para fazer o download do Ransomware Cerber. Indicações da Check Point (equipe Threatcloud Incident Response) apontam que o CERBER está sendo distribuído via Botnet Dridex.

Importante destacar que até hoje de manhã, nenhuma das principais engines de antivírus do mercado conseguiam detectar este malware.

Acredito que este não será o primeiro, nem o último ataque deste tipo. Se analisarmos os ataques via macro, veremos que existe um crescimento com o passar dos anos. Possivelmente encontraremos muitos Ransomware como o RANSOM_LOCKY.A ou como o CERBER e ainda diversos outros meios destrutivos usando macros.

O dia 23 de junho de 2016 pode ser uma data importante para as empresas em todo o mundo. Devemos observar de perto a evolução para o ciclo de contaminação do BARTALEX e do CERBER. Aliado a isto devemos evitar que funcionários ativem macros para documentos não assinados por suas empresas e fazer uso de mecanismos que monitorem o tráfego Web ou o fluxo de Correio Eletrônico para identificar comportamentos comuns nos ataques de ransomware.

Entre em contato agora com o UOLDIVEO e entenda como podemos ajudar sua empresa a solucionar este e outros problemas de segurança.

http://uoldiveo.com.br/contato/
comercial@uoldiveo.com

 

Denis Souza

 

Referências:

  • Check Point Threatcloud Incident Response (Time de Resposta à Incidentes), Check Point ThreatCloud e Threat Intelligence (Nuvem Colaborativa de Segurança).
  • Trend Micro Blog.

Segurança em cloud: além da tecnologia

Hoje ouvimos falar muito de Cloud como algo importante para os negócios de uma organização, fazendo com que sejam feitos investimentos financeiros, redesenho de ambientes ou mudanças estratégicas importantíssimas de alto impacto para a organização. Mas, muitas vezes, esquecemos que como qualquer projeto, imaginar o uso de cloud Computing, sem pensar em segurança e compliance é cometer quase que um haraquiri sem a cerimônia obrigatória dos samurais.

Além disto, muitas empresas estão negligenciando o impacto que problemas de segurança podem causar à marca, muitas vezes destruindo em pouco tempo, o valor construído pela empresa durante anos.

Antes da segurança

É importante destacar que antes de imaginarmos um projeto de Cloud ou mesmo como a segurança impacta este novo paradigma, devemos avaliar muito bem qual o modelo de cloud mais aderente para a aplicação desejada e avaliar também qual o impacto desta aplicação no negócio como um todo.

Sabemos que ao falarmos de Cloud, referenciamos geralmente os modelos Público, Privado e Híbrido.

Devemos questionar sempre qual o esforço que será feito para adequar a aplicação ao modelo escolhido? Vai haver alguma perda para ter a sonhada agilidade em TI ou para atingir a liberdade de adicionar ou remover recursos a qualquer momento? Vamos manter estes questionamentos em mente e identificar os modelos de Cloud existentes.

O Gartner define nuvem pública (Public Cloud Computing) como um ambiente computacional que possui escalabilidade e elasticidade provido como serviço de forma automatizada e orquestrado para clientes que, em sua essência, estão externos ao provedor usando tecnologias acessíveis pela internet em elementos de infraestrutura compartilhados. Completando o que diz o Gartner, é importante também entendermos que esta infraestrutura de Cloud é algo compartilhado por todos os clientes e que aceita menos requisitos de negócios, ou seja, é preciso se enquadrar dentro das características oferecidas pelo provedor de serviços.

A nuvem privada (Private Cloud Computing) posiciona-se como um ambiente de nuvem onde a infraestrutura é usada exclusivamente por uma empresa ou onde uma organização é completamente isolada das outras sem perder escalabilidade ou elasticidade, sendo auxiliada pela automatização e orquestração. Esta empresa tem os recursos de infraestrutura reservados para o seu uso, como se fosse a dona dela, detendo muito mais liberdade na definição do ambiente.

Dizemos que a nuvem híbrida (Hybrid Cloud Computing) é aquele que equilibra workloads entre nuvens públicas e ambientes privados (sejam eles em nuvem ou não). Um exemplo deste modelo é quando a empresa precisa manter certos workloads na Cloud Privada, por questões de compliance e soberania dos dados, e outros na nuvem pública, em uma região mais próxima dos usuários finais.

Brokers de segurança

Entrando mais fundo no universo Cloud Computing, vemos um conceito que cresce com bastante força, firmando-se na representação da sigla CASB (Cloud Access Security Brokers). Pode-se dizer que um ambiente CASB é aquele que pode ser posicionado dentro do próprio cliente ou em um ambiente de Cloud externo controlando as regras de segurança que gerenciam o acesso ao ambiente em nuvem do cliente. O CASB é posicionado entre o cliente e o Provedor de Cloud e as políticas de segurança podem incluir elementos como single sign-on, autorização, mapeamento de credenciais, criptografia, uso de token para duplo fator de autenticação, registro de acesso (logging), geração e alertas, detecção e prevenção de malware.
Segundo o Gartner, até o final e 2018, 50% das organizações com mais de 2.500 usuários estarão com uma plataforma de CASB para controlar o uso dos produtos mantidos como SaaS (Software as a Service). Ainda segundo o Gartner, em 2020, 85% das maiores empresas usarão um produto de CASB. Desta forma, a camada de segurança não precisa estar por padrão incluída no ambiente de Cloud, mas ele precisa estar pronto para ambientes que usem CASB.
Com o holofote em Segurança da Informação e olhando para os dias atuais, ver-se que independentemente do modelo de Cloud escolhido, ele tem que possuir mecanismos que protejam a autenticação para acessar o painel de gerenciamento. É comum termos o atacante digital descobrindo o usuário responsável pela administração das máquinas em Cloud e pedir resgate para devolver o acesso e não apagar ou danificar as máquinas virtuais que foram criadas. Tem-se assim, perdas financeiras reais. É importante ter um ambiente de contingência e um plano bem detalhado e ensaiada com simulações periódicas para recompor de forma rápida o ambiente em Cloud.

Além da indisponibilidade

Acredito que devemos sempre olhar nossos projetos com análises bem mais críticas e observar o que acontece no restante do mundo para identificar se é possível aproveitar algo. Um exemplo deste tipo de análise pode ser encontrado na pesquisa feita pela Veeam Software. A Veeam Software é uma empresa reconhecida pelos produtos de Backup, Replicação e Disponibilidade. Esta pesquisa mostra que muitas empresas estão tendo perdas financeiras por não avaliarem corretamente se suas aplicações estão realmente respondendo as necessidades de seus usuários. A pesquisa elaborou 1.140 entrevistas com os principais responsáveis pelo departamento de TI em 24 países. Segundo a pesquisa, 84% dos entrevistados admitiram que suas organizações possuem problemas com disponibilidade de seus serviços. Isto implica em danos na marca ou na imagem da corporação.

A Veeam revela também que para tentar solucionar estes problemas, muitas instituições estão investindo em Data Centers próprios ou melhorando os que já existem. Mesmo assim as paradas continuaram se multiplicando, indo de 13 para 15 eventos em 2015. A média de cada parada subiu de 1,5h para 2h por aplicação de missão crítica. O resultado é um custo médio anual do superior a US$ 16 milhões (US$ 6 milhões a mais que 2014).

Isto é extremamente assustador, mas o que precisa ser entendido é que existem diversos impactos mais devastadores. Observe que 68% destas empresas entrevistadas apontaram perda da confiança do cliente, 62% indicaram dano a integridade da marca, 51% revelaram perda de confiança dos parceiros, 31% disseram que houve redução do preço dos estoques e 26% tiveram ações legais de parceiros ou clientes alegando perdas financeiras.

Observe que os custos para refazer a imagem de uma instituição podem ser gigantes. Este foi o tema da pesquisa International Business Resilience Survey 2015. A pesquisa revela que 73% dos executivos informam ter uma falta de planejamento de gestão de crise nas empresas. Para se proteger dos ataques cibernéticos, 28% deles afirmam ter apólices de seguros especiais para coberturas ataques cibernéticos. Outros 21% contratam seguros também para se proteger de possíveis danos à reputação das empresas após uma violação de dados e ainda assim, 60% dos CEOS e gestores entrevistados têm dado pouca importância na resiliência dos sistemas de TI em relação à gestão de reputação de suas empresas.

As ameaças são muitas, mas como o UOLDIVEO pode ajudar a proteger seu negócio, evitando perda da confiança dos seus clientes e fornecedores, dano a integridade das suas marcas e problemas jurídicos?

Com os serviços de segurança do UOLDIVEO, sua empresa pode encontrar diversos serviços que buscam a continuidade do negócio e proteção de informações dos clientes.

Os serviços são diversos e vão desde DDoS Protection, um pilar para sustentar a disponibilidade dos seus serviços, e evitar perdas financeiras importantíssimas, até a proteção específica para a aplicação Web, por meio do Web Application Firewall (WAF), um produto destinado a aplicações web, protegendo-as contra ataques à sua aplicação exposta à internet, deixando seu acesso mais rápido ou auxiliando na defesa contra o furto de informações existentes nas bases de dados usada pela sua aplicação.

Sabemos que não basta ter uma infraestrutura confiável ou hardwares tecnicamente reconhecidos pelo marcado, é importante termos o apoio de uma equipe especializada em ciberataques (cyberattack). Protegemos o maior portal de serviços da América Latina, o UOL, além das aplicações de 250 das 500 maiores empresas do Brasil.

Muitas vezes uma Tecnologia é cercada por medos, sejam eles posicionados em Cloud ou não. Na grande maioria das vezes o medo é algo benéfico, pois nos inspira a repensar nossas estratégias. Entretanto, é importante termos em mente que o uso da Segurança Digital precisa ser avaliado em conjunto com o custo da perda financeira para entender que a salvação de qualquer modelo de negócio dependerá de como definimos e implantamos a Segurança Digital como um todo envolvendo: pessoas, tecnologia e processos. Quando isto é feito, Segurança Digital será sempre a salvação para qualquer negócio.

 

Denis Souza

 

Fontes: