A Segurança na Nuvem é Simples, Absolutamente Simples.

“A segurança na nuvem é simples, absolutamente simples. Pare de complicá-la.”

Foi assim que iniciei uma apresentação que fiz na CyberRisk Alliance, Cloud Security Summit em 17 de abril deste ano. E eu realmente acredito que a segurança da nuvem é simples, o que não quer dizer que é fácil. É uma questão de se ter a estratégia correta.

Como muitas vezes me perguntam sobre estratégias para a nuvem e as complexidades que a acompanham, decidi compartilhar minha conversa recente com vocês todos.

Dependendo da sua preferência, você pode assistir ao vídeo abaixo ou ler a transcrição da minha palestra publicada logo abaixo do vídeo. Espero que você ache útil e que goste. E, como sempre, adoraria ouvir sua opinião, encontre-me em @marknca no Twitter.

Para aqueles que preferem ler a assistir um vídeo, aqui está a transcrição da minha palestra:

A segurança na nuvem é simples, absolutamente simples. Pare de complicá-la.

Eu sei que provavelmente você está pensando: “Como assim, do que esse cara está falando? Ele está maluco.”

Lembre-se, simples não significa fácil. Acredito que tornamos as coisas muito mais complicadas do que devem ser quando se trata de proteger a nuvem, e isso faz nossas vidas muito mais difíceis do que elas precisam ser. Existem algumas vantagens enormes quando se trata de segurança em nuvem. Principalmente, acho que podemos simplificar nossa abordagem de segurança por três razões principais.

A primeira é o gerenciamento integrado de identidade e acesso. Todos os três principais provedores de nuvem, AWS, Google e Microsoft, oferecem sistemas fantásticos de identidade e gerenciamento de acesso. São coisas que a segurança e os profissionais da área estão pedindo há muito tempo.

Agora que temos condições disso, precisamos aproveitar o momento.

A segunda razão principal é o modelo de responsabilidade compartilhada. Abordaremos mais sobre isso em um minuto, mas é uma ferramenta absolutamente maravilhosa para entender seu mind map, para perceber onde você precisa focar seus esforços de segurança e a terceira razão que simplifica a segurança para nós é a aplicação universal de APIs ou interfaces de programação de aplicações.

Isso nos dá, enquanto profissionais de segurança, a capacidade de orquestrar e automatizar uma enorme quantidade de trabalho braçal. Essas três coisas juntas resultam na capacidade de executar uma prática de segurança muito sofisticada ou muito difícil de executar, mas uma prática de segurança que, na verdade, é bastante simples em sua abordagem. 

É só que todos os detalhes são difíceis e usaremos essas três vantagens para tornar esses detalhes mais simples. Então, vamos voltar um segundo e ver qual é nosso objetivo.

Qual é o objetivo da cibersegurança? Isso não é algo que você ouve com frequência como uma pergunta.

Na maioria das vezes, você ouve que a definição de cibersegurança é uma questão de garantir a confidencialidade, integridade e disponibilidade de informações ou dados. A tríade da CIA, como se costuma chamar, mas eu gosto de expressar isso de uma maneira diferente. Eu acho que o objetivo é muito mais claro e o objetivo é muito mais simples.

Isto é para garantir que tudo o que você está criando funcione como planejado e somente como planejado. Agora, você perceberá que não pode atingir esse objetivo apenas como uma equipe de segurança. Você precisa trabalhar com seus desenvolvedores, trabalhar com operações, trabalhar com as unidades de negócios e também com os usuários finais da sua aplicação.

Essa é uma maneira maravilhosa de definir nosso objetivo e perceber que estamos juntos nisso para garantir que tudo o que você está criando funcione conforme o planejado e somente como planejado.

Agora, se seguirmos em frente, e olharmos contra quem estamos, quem está impedindo que nossas coisas funcionem direito? Você olha normalmente, pensa em quem está atacando nossos sistemas? Quem são os riscos? São estados-nação? Talvez sejam ameaças internas? Embora sejam ameaças válidas, elas são exageradas. Você… não precisa se preocupar com ataques de estado-nação.

Se você é um estado-nação, preocupe-se com isso. Se você não é um estado-nação, não precisa se preocupar com isso, porque, francamente, não há nada que possa fazer para detê-los. Você pode dar uma atrasada neles, mas, por definição, eles vão usar seus recursos e aí já era.

Quanto aos ataques internos, esse é um problema de RH. Trate bem o seu povo. Entre em contato com eles e tenha uma forte política de gerenciamento de informações em vigor, e você reduzirá essa ameaça naturalmente. Se você estiver caçando pessoas, criará as mesmas ameaças que está vendo.

Então, isso nos leva ao próximo conjunto. E os criminosos cibernéticos? Você sabe, precisamos nos preocupar com cibercriminosos.

Os cibercriminosos estão mirando nos sistemas simplesmente porque esses sistemas estão online, são criminosos motivados pelo lucro, organizados e com um bom conjunto de ferramentas. Portanto, precisamos nos preocupar com eles, mas há um lugar mais insidioso ou mais comum, talvez uma ameaça mais simples com a qual precisamos nos preocupar, e esse é um dos erros.

A grande maioria dos problemas que ocorrem com violações de dados e vulnerabilidades de segurança na nuvem é motivada por erros. De fato, a ponto de eu nem me preocupar com cibercriminosos simplesmente porque todo o trabalho que vamos fazer para focar na prevenção de erros.

E identificar e corrigir suas medidas realmente rápido vai ajudar você a cobrir todas as coisas que teríamos feito para bloquear os criminosos cibernéticos para início de conversa; portanto, os erros são muito comuns porque as pessoas estão usando muito mais serviços na nuvem.

Você tem muito mais componentes, muito mais complexidade no seu deploy, você vai errar e é por isso que você precisa implementar sistemas automatizados para garantir que esses erros não ocorram ou, se acontecerem, que eles serão apanhados bem, bem rápido. 

Isso se aplica ao DevOps padrão, as filosofias para construção. Também se aplica à segurança de maneira muito, muito maravilhosa. Portanto, essa é a principal coisa em que vamos nos concentrar.

Portanto, se analisarmos essa soma juntos, temos o objetivo de garantir que tudo o que estamos criando funcione como pretendido, e somente como pretendido, e nosso principal problema aqui, o maior risco para isso, são simples erros e configurações mal feitas.

Ok, então não estamos começando do zero. Podemos aprender com os outros e o primeiro lugar que vamos aprender é o modelo de responsabilidade compartilhada. A responsabilidade compartilhada se aplica a todos os provedores de serviços em nuvem.

Se você olhar o lado esquerdo do slide aqui, verá o modelo tradicional local. Temos aproximadamente seis áreas em que algo precisa ser feito quase que diariamente, seja patching, manutenção, apenas visibilidade operacional, monitoramento, esse tipo de coisa e, em um ambiente tradicional on-premises, você é responsável por tudo isso, seja sua equipe ou uma equipe sob sua organização. 

Em algum lugar dentro da sua árvore, as pessoas estão ansiosas para fazer coisas diariamente. Aqui, quando nos mudamos para uma infraestrutura, para obter uma máquina virtual de um provedor de nuvem imediatamente, metade das responsabilidades é descartada.

Essa é uma vitória gigante.

E, à medida que avançamos cada vez mais para a direita a um serviço mais gerenciado ou serviços em nível de equipe, temos cada vez menos responsabilidades diárias.

Agora, é claro, você sempre precisa verificar se o provedor de serviços em nuvem está fazendo o que eles dizem que estão fazendo, e é por isso que as certificações e os frameworks de compliance entram em jogo, mas o ponto principal é que você está fazendo menos trabalho, para se concentrar em menos áreas.

Na prática não é necessariamente menos trabalho, mas um trabalho menos extenso, vamos dizer.

Assim, você pode ter um foco mais profundo e, é claro, você precisa se preocupar com a configuração do serviço. Te dão tudo quanto é painel de controle e você tem que se virar com eles para bloquear as ameaças. O melhor conselho é usar para coisas como criptografia de dados estáticos, por exemplo.

Na maioria das vezes é tarefa fácil, mas você tem que fazer, pois é de sua responsabilidade.

Também temos a ideia de um framework de adoção, e isso se aplica ao Azure, à AWS e ao Google, e o que eles fazem é ajudar a mapear seus processos de negócios.

Isso é importante para a segurança, pois fornece uma compreensão de onde estão seus dados, o que é importante para os negócios, onde estão, quem precisa tocá-los, acessá-los e processá-los.

Isso também nos dá a ideia ou a capacidade de identificar as partes interessadas, para que saibamos quem está preocupado com esses dados, quem está de olho neles e, finalmente, ajuda a criar um plano de ação.

O resultado de todos esses frameworks é um plano de ação para ajudá-lo a migrar para a nuvem e a evoluir continuamente. Bem, também é um mapa fenomenal para seus esforços de segurança.

Você deseja priorizar a segurança, é assim que você faz. Você a realiza através da estrutura de adoção, entendendo o que é importante para os negócios e isso te permite identificar sistemas e áreas críticas para sua segurança.

Mais uma vez, queremos manter as coisas simples, certo? E as outras coisas que queremos examinar são os fundamentos da CIS. Eles os possuem para AWS, Azure e GCP e estes fornecem uma orientação prescritiva.

Eles são realmente uma linha de base forte e uma lista de tarefas que você pode realizar para ter certeza que tudo que é essencial está dentro dos conformes, tipo criptografia de transmissões, dados e tal. É um ponto de referência realmente fantástico e um ponto de partida para sua prática de segurança.

Novamente, com essa ideia de manter as coisas o mais simples possível, por isso, quando se trata de examinar nossa política de segurança, usamos os frameworks e a linha de base para criar uma defesa forte, priorizando o que faz sentido pro negócio.

E, a primeira questão que precisamos nos perguntar como profissionais de segurança é: o que aconteceu? Se acontece alguma coisa, perguntamos ‘o que aconteceu’, e aí?

Temos a capacidade de responder a essa pergunta? Então, precisamos falar de registro em logs e auditoria. Isso precisa estar no lugar antes que algo aconteça. Permitam-me dizer que, novamente, antes que algo aconteça você precisa ser capaz de ter essas informações no lugar.

O lance é fazer essas perguntas importantes sobre ‘o que’ aconteceu na minha conta e ‘quem ou o que’ fez essa coisa acontecer, entende?

Portanto, isso começa na nuvem com alguns serviços básicos. Para a AWS, é o Cloud Trail, para o Azure Monitor, para o Google Cloud, costumava ser chamado Stackdriver, agora é o Google Cloud operations suite, portanto, é necessário ativar o volume máximo.

Não se preocupe: você pode usar algumas regras de ciclo de vida na fonte de dados para manter seus custos baixos.

Mas isso fornece a você essa camada, a camada básica de auditoria e logs para que você possa responder à pergunta ‘o que aconteceu?’.

Então, a próxima pergunta que você quer se perguntar ou tem a capacidade de responder é ‘quem está lá?’, certo? ‘Quem está fazendo o que na minha conta?’ E isso se resume a identidade.

Já mencionamos que este é um dos principais pilares para manter a segurança simples e obter essa segurança altamente eficaz em sua nuvem.

Então, aqui você está respondendo às perguntas de quem é você e o que tem permissão para fazer? É aqui que temos um privilégio muito simples, uh, ou princípio de segurança, que é o princípio do menor privilégio.

Você deseja dar uma identidade, seja um usuário, uma função ou um serviço, somente os privilégios que eles precisam para executar a tarefa que eles pretendem executar.

OK?

Então, basicamente, se eu precisar gravar um arquivo em um storage, pasta, ou bucket, eu só deveria ter a capacidade de escrever esse arquivo. Não preciso ler nem excluir, só preciso escrever nele, então me libera apenas isso.

Lembre-se de que o outro pilar da segurança simples aqui, da segurança essencial na nuvem, é a identidade integrada.

É aí que realmente isto decola: é que começamos a atribuir permissões de acesso muito granulares e não se preocupe, vamos usar as APIs para automatizar tudo isso, para que não seja uma dor de cabeça de gerenciamento, mas o princípio desses privilégios é absolutamente crítico aqui.

Os serviços que você usará, surpreendentemente, todos os três provedores de nuvem entraram em fila e os nomearam da mesma maneira. É o IAM, gerenciamento de acesso à identidade, seja AWS, Azure ou Google Cloud.

Agora, a próxima pergunta que faremos a nós mesmos: quais são as áreas em que vamos olhar. É realmente onde devo focar nos controles de segurança? Onde devo colocar as coisas no lugar?

Até agora, conversamos realmente sobre como aproveitar o que está disponível nos provedores de serviços em nuvem, e você deve estar absolutamente disponível para maximizar o uso de suas estruturas nativas e primitivas. Primitivo eu digo no sentido de essencial, não de atrasado, só para ser claro.

São controles muito avançados, mas há momentos em que você precisará colocar seus próprios controles, e essas são as áreas em que você vai se concentrar, então você começará com a rede, certo?

Portanto, em sua rede, você maximizará as estruturas nativas disponíveis na nuvem em que está. Assim, seja uma estrutura de projeto no Google Cloud, seja um serviço como Transit Gateway na AWS e todos eles têm a ideia de uma VPC ou nuvem virtual privada ou rede virtual que é um limite muito forte para você usar.

Lembre-se de que na maioria das vezes você não é cobrado pela criação deles. Você tem limites em suas contas, mas as contas são gratuitas e pode continuar adicionando mais, uh, redes virtuais. Você pode estar dizendo, “espere um pouco, estou tentando simplificar as coisas”.

Na verdade, ter várias redes virtuais ou nuvens privadas virtuais acaba sendo muito mais simples, porque cada uma delas tem uma tarefa. Você resolve que tal aplicação é executada em uma determinada nuvem privada virtual, e não numa que é enorme e compartilhada. E isso te dá limites de segurança maravilhosamente fortes e uma maneira muito simples de ver uma VPC. Uma ação e muito da filosofia Unix em jogo.

A chave aqui, porém, é entender que, embora todos os controles de segurança em vigor para o seu provedor de serviços lhe ofereçam, sejam VPCs, tabelas de roteamento, listas de controle de acesso, grupos de segurança e todos os SDN recursos que eles implementaram…

Isso realmente ajuda você a descobrir se o serviço A ou o sistema A tem permissão para conversar com B, mas eles não informam o que estão dizendo. E é aí que entram os controles adicionais chamados IPS, ou sistema de prevenção de intrusões, e você pode querer obter um controle de terceiros para fazer isso, porque nenhum dos três grandes provedores de nuvem oferece IPS até este momento.

Mas isso dá a você a capacidade de não apenas dizer: “Ei, vocês podem conversar um com o outro”. Mas também de monitorar essa conversa para garantir que não haja código malicioso sendo transmitido entre os sistemas, que ninguém está tentando mandar um DDoS.

Um monte de coisas extras existem, então é aí que o IPS entra em jogo na sua defesa de rede. Agora, olhamos para a computação, certo?

Podemos ter computação de várias formas, seja em funções serverless, seja em contêineres, gerenciamento de contêineres, seja em máquinas virtuais tradicionais, mas todos os princípios são os mesmos.

Você quer entender onde está a linha de responsabilidade compartilhada, quanto está no seu colo, quanto está nos CSPs?

Você quer entender que precisa proteger o EOS, o serviço ou ambos, em alguns casos, se certificar de que está bloqueado, para ter senhas de administrador. Complicado demais.

Não logue nesses sistemas, porque você vai preferir consertar as coisas de uma outra forma.

Você quer consertar as coisas no pipeline de desenvolvimento, não entrar nesses sistemas diretamente, e isso é algo muito importante para as pessoas de sistemas superarem, mas é absolutamente essencial para a segurança.

E, assim, vai demorar um pouco, mas há alguns truques que você pode seguir comigo. Você pode ver  nos slides do Mark, que vai estar feliz em orientá-lo nos próximos passos.

A ideia dessa apresentação é realmente apenas o básico simples, para lhe dar uma visão geral de onde você deve concentrar seu tempo e afastar o mito de que a segurança da nuvem está complicando as coisas.

É um caminho interessante de se seguir, é foco no simples, é foco no que importa para a segurança.

Portanto, a última área que você deseja focar aqui é em dados e armazenamento. Quer se trate de bancos de dados, um grande Blob Storage ou de buckets na AWS, isso realmente não importa os princípios, novamente, são todos iguais.

Você deseja criptografar seus dados em repouso usando a funcionalidade de nuvem nativa fornecida pelo provedor de serviços em nuvem porque apresenta na maioria das vezes apenas um endereço chave e uma checkbox, e você está pronto para começar.

Nunca foi tão fácil criptografar as coisas, e não há desculpa para isso, e nenhum dos provedores cobra mais pela criptografia, o que é incrível, e você absolutamente deseja tirar proveito disso e deseja ser tão granular quanto possível com o seu IAM e o mais razoável possível.

Portanto, há uma linha aqui e muitos armazenamentos de dados nativos dos provedores de serviços em nuvem, você pode ir até o nível da célula de dados e dizer: Mark tem acesso ou Mark não tem acesso a essa célula.

Isso pode ser altamente eficaz e talvez adequado para o seu caso de uso. Pode ser que seja demais também, depende da situação.

Mas, o bom é que você tem essa opção. Para fechar,  você vai querer examinar as estratégias do ciclo de vida para manter seus custos sob controle.

Os dados realmente ficam fora de controle quando você não precisa se preocupar com capacidade. Todos os provedores de serviços em nuvem possuem algumas automações fantásticas.

Basicamente, basta fornecer regras muito simples para dizer: “Ok, depois de 90 dias, mude para um armazenamento mais barato. Depois de 180 dias, você se livra dele completamente ou coloca-o em armazenamento refrigerado”.

Aproveite essas vantagens ou sua conta ficará fora de controle e – e isso está relacionado à disponibilidade e confiabilidade porque quanto mais você gasta com esse tipo de coisa, menos precisa gastar em outras áreas, como segurança e eficiência operacional.

Então, isso nos leva à nossa próxima grande questão de segurança. Isto está funcionando?

Como você sabe se alguma dessas coisas está funcionando? Bem, você quer falar sobre o conceito de rastreabilidade. A rastreabilidade é uma definição formal, mas para mim, ela realmente se resume a ‘de onde isso veio?’, ‘quem pode acessá-lo?’ e ‘quando eles acessaram?’.

Isso está intimamente ligado ao conceito de observabilidade. Basicamente, a capacidade de analisar sistemas fechados e inferir o que está acontecendo por dentro, com base no que está entrando nesse sistema e o que está deixando esse sistema… realmente o que está acontecendo.

Existem algumas ótimas ferramentas aqui dos provedores de serviços. Novamente, você deseja examinar o Amazon CloudWatch, o Azure Monitor e o Google Cloud Operations Suite e aqui isso nos leva à chave, ok?

Essa é a chave para simplificar tudo, e eu sei que abordamos um montão de coisa nesta apresentação, mas eu realmente quero que você dê uma boa olhada neste slide e, novamente, entre em contato comigo, @marknca, vou ficar muito feliz em responder a quaisquer perguntas, perguntas feitas depois por aqui também porque isso realmente simplificará as coisas, e isso levará sua prática de segurança para o próximo nível.

Imagina qualquer evento  em seu ambiente cloud, ok? Na sua implantação, há um gatilho e, em seguida, ele está gerando um evento ou um log.

Se você for à linha inferior aqui, terá um log, no qual poderá reagir em uma função para fornecer algum tipo de resultado. Essa é a parte lenta.

Estamos falando de minutos aqui. Você também tem a faixa superior onde seu gatilho dispara um evento e, em seguida, reage a isso com uma função e, depois, obtém um resultado rápido – ou seja, o oposto do caso anterior.

Essas coisas acontecem em segundos, frações de segundos. Você começa a desenvolver sua prática de segurança com base nesse modelo.

Você começa a automatizar cada vez mais essas funções, seja Lambda, seja Cloud Functions, Azure Functions, não importa.

Todos os CSPs oferecem a mesma funcionalidade principal aqui. Essa é a métrica crítica de sucesso: quando você começa a reagir no atalho automaticamente às coisas, então, se você vir um evento de segurança acionado, como seu malware na sua máquina virtual, você pode bloquear isso e ativar uma nova automaticamente.

Se você está procurando coisas de compliance, você tem que pensar naquele primeiro exemplo, porque leva alguns minutos.

As reações acontecem no topo, mas, tipo, quando alguém loga, esse indivíduo impacta tanto no topo quanto na base da estrutura, então, falando da parte de cima, se acontece um login numa VPC ou em uma máquina virtual ou instância, você deveria ter um gatilho ativo que ia chegar e perguntar: “Mark, você entrou no sistema? Porque você, sabe, você não deveria”.

Mas então eu respondo e falo: “Sim, eu, eu fiz login”. Então, imediatamente, você não precisa responder. Não chega a ser um cenário de resposta a incidentes, mas, na parte inferior, talvez você esteja acompanhando quantas vezes entrei.

E depois da terceira ou quarta vez, talvez alguém apareça, converse comigo e diga: “Ei, você continua acessando esses sistemas? Você não pode corrigi-lo antes da implantação e criar um pipeline, porque é para onde precisamos nos mover?”

Então, você encontrará esse equilíbrio e esse conceito. Eu só queria entrar em suas cabeças agora para automatizar sua prática de segurança. Se você tem uma checklist, ela deve estar em um modelo como este, porque ajudará você a reduzir seu workload, certo?

A ideia é automatizar o máximo possível e manter as coisas em limites muito claros e simples, e o que é mais simples do que ter todas as ações de segurança listadas como uma função automatizada, de bobeira em um repositório de código em algum lugar?

Abordagem fantástica às práticas modernas de segurança na nuvem. Muito simples e muito claro. Sim, difícil de implementar. Pode ser, mas é um modelo mental fácil e incrível de lembrar que tudo é automatizado como uma função com base em um gatilho em algum lugar.

Então, quais são as chaves para o sucesso? Quais são as chaves para manter essa coisa de segurança em nuvem simples? E espero que você tenha percebido a diferença entre um mind map simples e os desafios na implementação. 

Pode ser difícil. Não é fácil de implementar, mas o mapa precisa ser mantido de um jeito fácil, certo? Mantenha as coisas em suas próprias VPCs e em suas próprias contas, automatize tudo. Abordagem muito, muito simples. Tudo se encaixa nessa estrutura, então as chaves aqui estão lembrando o objetivo.

Certifique-se de que a segurança cibernética esteja garantindo que tudo o que você construa funcione como pretendido e somente como pretendido. É a compreensão do modelo de responsabilidade compartilhada, tem que pensar em ter um plano através de frameworks em nuvem, como desenvolver bem, que cai na questão do Well-Architected Framework. 

É específico para a AWS, mas seus princípios, podem ser aplicados em qualquer lugar. Nós não tratamos aqui, mas eu vou colocar os links nos materiais para você bem como na lembrança dos sistemas antes de pessoas, certo? 

Adicionar os controles certos na hora certa e aí, finalmente, observar e reagir. Seja vigilante, pratique. Você não vai conseguir isso perfeitinho logo de cara.

Você precisará refinar, iterar e, em seguida, ser extremamente amigável com a nuvem. Esse é o modelo de cloud, divulgue-o, itere rapidamente, mas, colocando as estruturas no lugar, você não garantirá que não esteja fazendo isso de maneira insegura.

Muito obrigado, aqui estão alguns links que ajudarão você antes de fazermos algumas “perguntas e respostas” aqui. trendmicro.com/cloud levará você aos produtos para saber mais. Também estamos fazendo esse streaming muito legal.

Eu apresento um programa chamado Let’s Talk Cloud. Nós entrevistamos especialistas e temos vários bate-papos sobre o que eles estão falando na nuvem, sobre o que estão trabalhando, e não apenas sobre segurança, mas no que eles estão criando em geral.

Você pode acessar isso em trendtalks.fyi. Hum, e novamente, me encontre nas redes sociais @marknca.

E então, temos algumas perguntas para iniciar, e você pode colocar mais perguntas no webinar aqui, e elas as enviarão ou responderão da mesma forma, se puderem.

É exatamente disso que se trata, é a interação que está conseguindo isso, essa troca de experiências. Então, a primeira pergunta que eu queria abordar é interessante, e é realmente sobre sistema antes de pessoas.

Você me ouviu mencionar isso no final e a pergunta é realmente o que isso significa sistemas antes de pessoas? A segurança não é realmente sobre a expertise das pessoas?

E sim e não, então se você é analista de SOC, se está trabalhando em uma função de segurança  agora, estou realmente confiante em dizer que 80%, 90% do que você faz agora pode ser delegado para um sistema.

Então, se você estava olhando para as linhas de log e as coisas que deveriam ser feitas pelos sistemas e surgir, apenas o objetivo de você investigar para fazer o que as pessoas são boas no que os sistemas são ruins, então os sistemas estão lá para inserir a verificação de contêineres no pipeline de build, só para dar um exemplo, para que você tenha que verificar manualmente as coisas, para se livrar do básico. Isso é um pentest? 100% não.

Mas já alivia de coisas do tipo você sacar que faltou atualizar para uma biblioteca mais recente e tal.

Tudo isso é automatizado, e, quanto mais sistemas você instalar, mais você como profissional de segurança ou sua equipe de segurança poderão se concentrar em onde eles podem realmente agregar valor e, francamente, onde é um trabalho mais interessante. Então é isso que ‘sistemas antes de pessoas’ significa, é basicamente automatizado o máximo possível para que as pessoas façam aquilo em que elas são realmente boas e para garantir que os sistemas captem o que fazemos como erros o tempo todo.

Se você acidentalmente tentar enviar uma versão antiga, você sabe que os sistemas devem interromper isso, se você enviar uma versão que não foi verificada pela varredura do contêiner ou se ela não tem a política de segurança apropriada em vigor.

Os sistemas devem capturar tudo o que os humanos não precisariam se preocupar em capturar. Isso significa sistemas acima do processamento. Você viu isso no slide “chaves para o sucesso” aqui. Eu vou colocar aqui porque é fundamental.

Outra pergunta que tínhamos, foi sobre o que não abordamos aqui, que era em torno do Well-Architected Framework. Este é um documento que foi publicado pela AWS há vários anos e eles continuam firmes com ele.

Eles o desenvolveram e, essencialmente, tem cinco pilares. Desempenho, eficiência, confiabilidade, segurança, otimização de custos e excelência operacional. Olha que legal, eu lembrei de todos os cinco.

Em essência, isso aqui é sobre como tirar proveito dessas ferramentas na nuvem.

Agora, a AWS publica, mas, honestamente, aplica-se ao Azure, aplica-se também ao Google Cloud. Não é um serviço específico. Ele ensina como desenvolver na nuvem e, obviamente, a segurança é um desses grandes pilares. Então, o lance é falar sobre como fazer essas trocas, como criar um volante de inovação, para que você tenha uma ideia, teste, obtenha o feedback e siga em frente.

Isso é realmente muito importante. Novamente, agora você deve ler que, mesmo que seja um cliente do Azure ou GCP é aí que você está colocando o máximo de suas coisas, porque é realmente sobre os princípios e tudo o que fazemos e incentive as pessoas a desenvolver bem, significa que há menos problemas de segurança, certo?

Especialmente sabemos que o problema número um são os erros.

Isso leva à última pergunta que temos aqui, que é sobre isso, como posso dizer que cibercriminosos, bom, você não precisa se preocupar com eles.

Você precisa se preocupar com erros? Esta é uma boa pergunta. É válido e a Trend Micro publica uma porrada de pesquisas sobre cibercriminosos. Eu mesmo faço várias pesquisas sobre eles.

Por treinamento e por experiência profissional, eu sou um investigador forense. É isso que faço: é acabar com os crimes cibernéticos. Mas acho que os erros são a principal coisa com a qual lidamos na nuvem, simplesmente por causa da complexidade subjacente.

Eu sei que é irônico, e para falar sobre simplicidade ter que falar sobre complexidade, mas a ideia é que você analise todas as principais violações, especialmente em torno de buckets S3, todas baseadas em erro.

Houve bilhões, bilhões e bilhões de registros e milhões de dólares de danos expostos por causa de erros simples, e isso é muito mais comum do que cibercriminosos.

E sim, crimes cibernéticos que você tem visto são motivo de preocupação. Você precisa se preocupar com eles, mas tudo o que você fará para corrigir erros e implementar sistemas para impedir que esses erros ocorram também será para a sua proteção contra esses caras e honestamente, se você é o cara que circula pela empresa gritando sobre eles o tempo todo, você tem muito menos credibilidade do que se dissesse: “Ei, no final, o que eu quero é garantir que a gente desenvolva da melhor forma possível, de preferência com erro zero”.

Obrigado pelo seu tempo. Meu nome é Mark Nunnikhoven. Sou vice-presidente de pesquisa em nuvem da Trend Micro. Eu também sou um herói da comunidade da AWS e adoro essas coisas. Entre em contato comigo em @marknca. Ficarei feliz em conversar mais.