A Nova Era das Aplicações

Muito geralmente as inovações em TI não são assim não novas. Foram criadas ou desenvolvidas muitos antes, vão sendo usadas aos poucos até que o motivador, ou a necessidade, surja, e muito rapidamente tornam-se o padrão. É o caso atual do novo modo, por assim dizer, de desenvolver as aplicações. Em uma série de artigos irei discutir as implicações para a segurança, que são grandes. Antes, porém, é necessário descrever o que é esse novo modo.

Desde que a informática existe, o modo comum de desenvolver uma aplicação é em único bloco, utilizando uma linguagem de programação, e para ser executado em um determinado sistema operacional. Por mais que as técnicas tenham evoluído, com uso de objetos e tal, um aplicativo sempre continuou a ser um aplicativo único. Fábricas de software se especializaram em reaproveitar códigos e rotinas, com estas sendo compiladas em conjunto. A virtualização mudou a camada de hardware desse modelo, já que diferentes servidores virtuais passaram a funcionar compartilhando o mesmo hardware, mas o caráter das aplicações não mudou. Durante o processo, esses servidores virtuais começaram a sair dos datacenters físicos e migraram para nuvens, com seu complicado emaranhado virtual de rede e serviços, e grandes empresas acabaram por adotar o mesmo conceito em suas nuvens privadas. E é aqui que o desenvolvimento começa a mudar de fato.

A evolução da nuvem se fez em paralelo à digitalização da sociedade e do consumo, que migrou do computador pessoal para o smartphone. O ponto em que estamos hoje é o exemplo disso. De onde fazemos uma TED mais rapidamente: do computador ou do celular? E reservas de restaurantes, compras em geral, e compra de ingressos? Tudo é mais rápido e eficiente a partir de nossos dispositivos móveis. Vejam que não citei as apps que já nasceram na nuvem e no celular, como o Uber e afins. Mais recentemente, as aplicações de Internet executadas no PC e no celular passaram a convergir, a ser na prática as mesmas. O cerne de toda essa evolução, ou revolução se você preferir, é o container.

A técnica apareceu pela primeira vez no longínquo ano de 1979, atrelado ao Unix, porém permaneceu adormecido até a primeira década dos anos 2000, quando o Google começou a investir na tecnologia até que em 2013 ela finalmente começou a decolar via plataformas de software livre. As empresas símbolo da modernidade na web, como Amazon, Google e Netflix executam tudo em containers. Como alardeado pelo Google em sua página, “ele permite que os times de desenvolvimento se movam rápido, publiquem software eficientemente, e operem em uma escala sem precedentes”. A cada semana, diz a empresa, eles iniciam mais de dois bilhões de containers. Em um processo natural, a técnica chegou às empresas “tradicionais”, que viram nele uma excelente ferramenta de agilidade, eficiência e redução do custo de seus sistemas. Hoje, o container caminha rápido para tornar-se a técnica padrão de desenvolvimento de aplicações. Mas o que é ele exatamente?

Um container digital carrega o mesmo contexto de um container físico para transporte: um ambiente isolado, alguns são refrigerados por exemplo, que sai facilmente de um caminhão para um trem, e do trem para um navio, ou vice-versa. Em informática um container é um módulo que contém tudo o que necessita para rodar, inclusive o que seria o seu sistema operacional, abstraindo-se completamente do ambiente à sua volta. É diferente de uma máquina virtual, que abstrai somente o hardware, mas se comporta de maneira idêntica à uma instalada em um servidor físico. Uma máquina virtual ao iniciar carrega todas os componentes e bibliotecas padrão, inclusive as que não são necessárias. Já o container contém tudo o que necessita, e pode ser executado diretamente no kernel do sistema operacional, sendo, portanto, mais leve e mais rápido.

A tecnologia aplicada ao desenvolvimento fez com que as aplicações “explodissem”, permitindo que funções executem em diferentes containers que trocam dados entre si, dependentes na execução, mas não no desenvolvimento, como microservices. Cada módulo pode ser desenvolvido em diferentes linguagens de aplicação, estar instalado em qualquer lugar, em qualquer nuvem publica ou privada, ou em qualquer computador, e ser publicado independentemente dos outros módulos. Desenvolvedores podem testá-los em seu próprio computador, da mesma forma que é executado. O suprassumo desse modelo é a computação serverless, ou seja, a abstração total para o provedor de serviços de nuvem. A escalabilidade e resiliência desse modelo é impressionante, com os módulos se multiplicando dinamicamente, ou recuperando-se de falhas também automaticamente, e de maneira transparente.

Toda essa longa introdução foi necessária para introduzir o tema da segurança para esse ambiente, que irei discutir nas próximas edições. Para antecipar o desafio é só pensar no modelo atual e tradicional de segurança da informação. Nem digo para o perímetro, mas para o datacenter. Vamos considerar uma empresa que deseja impedir que malware interfira com um de seus sistemas. A solução é imediata: instalar um agente de endpoint security, ou um NGFW/NGIPS. Começando pelo endpoint, onde instalamos? Não há um único servidor. Se for serverless, a empresa nem sabe onde está instalado cada módulo de microserviço. Mas mesmo que soubesse, como se instala um agente em algo que está isolado e conectado diretamente ao kernel. Vamos então para a rede. Onde instalamos o NGFW/NGIPS? É uma rede virtualizada! Então instalamos na rede virtual. Mas não há uma rede virtual, pois o ambiente está distribuído.

Assim como as soluções de segurança tradicionais não se encaixam nesse ambiente, as ameaças e vetores de ataque são também diferentes. Há novas ameaças e vulnerabilidades com o que se preocupar, e por isso há novas medidas que devem ser tomadas. Temos que pensar a segurança de maneira diferente. São esses os temas que irei tratar nos próximos artigos.

Segurança em um Mundo Complexo e Ambíguo

Essa série de artigos trata dos desafios da segurança da informação em um mundo marcado pela volatilidade, incerteza, complexidade e ambiguidade (VUCA em inglês). Para quem não teve a oportunidade de acompanhar o artigo, VUCA é acrônimo criado pelo Army War College dos Estados Unidos em 1987 para definir a nova realidade do mundo e suas ameaças. No artigo de novembro comentei sobre os desafios da volatilidade e incerteza dos ataques, e nesse artigo irei tratar da complexidade e ambiguidade.

Apesar de ambos termos parecerem autoexplicativos, cabe uma rápida análise sobre o que eles significam dentro do conceito VUCA. Por complexidade entende-se a existência de múltiplas variáveis, ou “forças envolvidas”, a confusão de diferentes problemas, nem sempre em uma cadeia de causa e efeito, além da natural complexidade que envolve a organização ou empresa. Já a ambiguidade refere-se à falta de clareza da realidade, ou do que está ocorrendo, o potencial para erros de interpretação dos eventos e das relações de causa e efeito. Todos esses significados aplicam-se à segurança da informação, e permitem ainda algumas extensões.

Segurança é por si só complexa, tanto do lado dos atacantes como dos defensores. Apesar de falarmos sempre de eliminar a complexidade, o mais correto seria reduzi-la. Para dizer a verdade, a cada ano a complexidade aumenta. Há muitos anos o perímetro das redes era o link com a Internet, e todos os sistemas ficavam por trás dele, protegidos por um firewall. Com o passar do tempo o perímetro foi desaparecendo, em um processo que culminou na transferência de sistemas críticos para os ambientes de nuvem. Também há uma década atrás as equipes de segurança preocupavam-se apenas com computadores – pessoais e servidores, para proteger. Há mais ou menos cinco anos surgiu as políticas BYOD para tratar a multiplicação de dispositivos móveis, incluindo os pessoais, até chegar na quantidade atual de dispositivos “não-informáticos”, como sistemas de controle de temperatura e máquinas de venda, entre muitos outros, conectados à rede. Não há como reduzir toda essa complexidade, mas não precisamos nos perder em meio a ela.

O outro lado da complexidade vem dos atacantes, os hackers. Costumo dizer que eles têm todo o tempo do mundo, além de uma montanha de dinheiro, para desenvolver suas técnicas e programas de invasão. Os últimos ataques foram realizados com o emprego de múltiplas técnicas, algumas delas antigas e repaginadas. Não é exagero dizer que um ataque poderia ser realizado a partir de um drone pousado no jardim, a ser usado para conectar via wi-fi as câmeras de vigilância para, a partir delas, acessar e instalar malware nos computadores alvo, e que, no meio do ataque, algumas delas poderiam lançar um DDoS contra outros servidores a fim de despistar a equipe de resposta a incidentes.

O meio de reduzir complexidade é o entendimento, ou conhecimento, do ambiente de negócios e TI da empresa, e de toda a correlação que existe entre cada um dos seus componentes. Há relações de causa e efeito entre sistemas que podem ser mapeadas, e que serão vitais para a rápida resposta, além de permitir a eliminação de redundâncias e complexidades desnecessárias. A empresa precisará também de especialistas – próprios ou terceirizados – que a ajude a compreender a fundo cada pedaço de cada componente. Alguns desses especialistas estarão fora da área de redes ou TI, nos departamentos de negócio. Especialistas em ataques avançados serão também necessários para tratar as ameaças reais e potenciais, e ainda mais necessários na hora de responder ou mitigar um desses ataques, ajudando a interpretar eventos correlacionados por sistemas de gerência de ataques ou SIEMs. 

Já a ambiguidade é a prima da complexidade. Quanto menos entendimento, menos clareza quanto ao que está ocorrendo e às próximas ações a executar.  Ou seja, mais ambiguidade. O remédio é portanto, conhecimento, aliado à experimentação e testes. Como experimentação me refiro à análise dos impactos de uma nova tecnologia de acesso ou de um novo negócio na segurança. Em uma situação que a empresa decide migrar alguns de seus sistemas para um provedor de nuvem, a área de segurança deveria realizar todas as simulações dos efeitos da mudança na estratégia de defesa. A análise deverá ir além do óbvio ou aparente, buscando relações não imediatas. Eventualmente um teste de vulnerabilidade/risco pode ser executado para identificar cenários possíveis de ataque. O segundo teste comum é o conhecido teste de invasão, ou penetration test em inglês, mas não como a maioria das empresas o executa. Já há oito anos defendo que os testes de invasão realizados hoje são quase inócuos, e que a abordagem deveria ser diferente. 

Os testes comuns hoje são os chamados “testes cegos”, em que o consultor possui o mínimo de conhecimento prévio do seu cliente a fim de executar a invasão. O primeiro problema é que consultor terá um tempo fixo para realizar seu trabalho e nem sempre irá testar todas as possibilidades. Além disso o teste cego é uma foto no tempo, e nada garante que no dia seguinte ao fim das provas uma nova técnica não seja desenvolvida.

A abordagem que considero mais correta é confirmar se a empresa sabe o que fazer se for invadida. Esse método é parecido com uma simulação de incêndio em um edifício. Não se põe fogo no prédio, mas se testa alarmes, rotas de fuga, tempo de evacuação do prédio, pontos de encontro e organização da brigada de incêndio. Em TI significaria uma invasão controlada, mesmo que para isso fosse plantada uma vulnerabilidade no servidor, com o objetivo de testar os mecanismos que a empresa instalou para detecção e prevenção de intrusos. O objetivo final é testar o plano de resposta. Essas simulações servirão como treinamento para todos os envolvidos, ajudando a entender o ambiente e dessa forma reduzir ambiguidades.

Seja qual for o ataque, o tempo e precisão da resposta serão vitais na redução e contenção dos danos, e esses são proporcionais ao nível de preparação e treinamento de todos os envolvidos. Deixar isso para o calor do momento é ajudar a quem menos precisa: o hacker. 

Segurança em um Mundo Volátil e Incerto

No último artigo comentei sobre os desafios da segurança da informação em um mundo marcado pela volatilidade, incerteza, complexidade e ambiguidade (VUCA em inglês). Para quem não teve a oportunidade de acompanhar o artigo, VUCA é acrônimo criado pelo Army War College dos Estados Unidos em 1987 para definir a nova realidade do mundo e suas ameaças. Esse mês irei me aprofundar em como planejar a segurança em um cenário de volatilidade e incerteza.

Volatilidade se define como a dinâmica dos eventos, inesperados tanto em sua natureza como em seu alcance. O oposto de volatilidade é a estabilidade, ou a quantidade de eventos e nível de criticidade considerado como padrão, e que a empresa enfrenta na maior parte do ano. Em um ambiente estável espera-se o que irá ocorrer, que é conhecido e, portanto, a resposta está documentada e treinada. No entanto, algo desconhecido e inesperado pode ocorrer a qualquer momento. Dizer que segurança é volátil é reconhecer que não há garantia de estabilidade nos elementos que estão fora do alcance de controle da empresa: hackers e usuários mal-intencionados.

Incerteza é o grau de imprevisibilidade dos eventos. Como os grandes ataques mostraram, as técnicas, vetores e extensão da invasão são somente identificados após o inicio e, em alguns casos, após seu êxito. Em alguns casos as vítimas apenas perceberam que havia uma invasão em curso depois que os sistemas saíram do ar, os dados foram roubados ou o computador ficou inacessível. Os resultados de não saber o que está ocorrendo são a surpresa, não saber como reagir e a sensação de impotência.  Volatilidade e Incerteza estão ligados. Um evento pode ocorrer a qualquer momento sem aviso prévio, e não temos como conhecer de antemão seus métodos e consequências.

A estratégia sai um pouco do senso comum de adquirir produtos ou serviços de segurança unicamente, contando que eles irão eliminar o risco ou reduzi-lo a níveis aceitáveis. No entanto, como já comentei, mesmo um residual de risco de 1% pode tirar uma empresa do ar e afetá-la durante dias.

O primeiro passo é estar preparado. Se não sabemos quando e como um ataque irá ocorrer, e nem sua natureza e dimensão, mas concordamos que um ataque bem-sucedido em algum momento poderá e irá ocorrer, o primeiro passo é estar sempre preparado. O contrário infelizmente é impossível. Não há como eliminar todo o risco.

Estar preparado implica na empresa (não apenas TI) possuir um plano de resposta a incidentes (PRI) que defina as ações das diferentes áreas em uma hipotética invasão e dê ordem e agilidade à reação. O que farão TI, segurança e redes? Como as operações essenciais serão mantidas? O plano deve incluir as áreas de marketing e comunicações para monitorar eventuais repercussões com clientes e da área jurídica para eventuais processos decorrentes da afetação de serviços ou vazamento de dados de clientes. Um bom PRI requer equipes especializadas e não custa barato, seja montado internamente ou contratado de provedores especializados, mas é necessário. Deve também sofre atualizações continuas para acompanhar mudanças nos negócios e ser testado periodicamente. Qualquer semelhança com planos de continuidade de negócios não é coincidência.

Com o PRI a empresa não será pega de surpresa, mas não podemos esquecer que estar preparado não significa saber o que está acontecendo. Ataques são incertos, não dá para adivinhar como eles se desenrolam. Para isso há duas características essenciais que todas as empresas deveriam buscar em seu planejamento de segurança: visibilidade e contexto.

Visibilidade significa simplesmente ver tudo o que está trafegando em rede. Como já comentei em artigos anteriores, é comum a análise do tráfego de rede em pontos específicos, como os perímetros externos e internos, sendo esta análise executada por um firewall ou IPS. A proposta é inspecionar todo o tráfego de rede em busca de anomalias ou tráfego suspeito, aquele que se comporta similarmente a ataques. Exemplo de tráfego suspeito é aquela direcionado à países com os quais a empresa não possui conexões comerciais, mas há muitos outros. Como em todas as tecnologias, há soluções hoje disponíveis para todos os tamanhos de empresa, como produtos ou serviços, alguns já fornecidos desde a nuvem. Devem também estar visível o tráfego de dispositivos de infraestrutura como câmeras e controles de ar-condicionado, dentre outros.

A análise do tráfego requer o que chamo de contexto, a correlação de vários dados a respeito do tráfego: (1) quem está acessando (o usuário mais que o endereço IP), (2) de qual computador (o normalmente usado pelo usuário ou não); (3) de qual sistema operacional (é o que ele possui em seu computador ou não); (4) de qual localidade (dentro ou fora do escritório); (5) quando (dentro do horário de trabalho ou comumente usado) e (6) o que está fazendo na rede (está acessando algum servidor ou serviço fora do seu padrão).  Quanto mais dados correlacionados, melhor e mais confiável a análise.

Notem que ambos, visibilidade e contexto, podem ser usados também na prevenção e detecção de ataques, o que nos leva ao quarto elemento da estratégia: antecipação. Não podemos adivinhar o que irá ocorrer, mas podemos aumentar nosso grau de alerta em resultado de ocorrências internas – detectadas pelos sistemas de visibilidade – e externas. Para este último devemos buscar inteligência em segurança. Inteligência é conhecimento e informação. Saber os ataques que estão ocorrendo no mundo e relacioná-los com a infraestrutura da empresa. Se algo está ocorrendo, mesmo que do outro lado do mundo, certamente chegará até você. Antecipe-se. Esteja preparado.

Também não estamos sozinhos no mundo. Os hackers compartilham informações o tempo todo, porque não nós? Convide pares de empresas de seu segmento e crie fóruns para intercambio permanente. Esqueça concorrência, pois nesse assunto os concorrentes são os hackers. Finalmente, nunca esteja em uma área de conforto. O invasor só precisa acertar uma vez. O defensor precisa acertar em todas.