DE{CODE}: Mantendo seus sites WordPress seguros em meio a um aumento nos ataques cibernéticos globais

Junte-se a especialistas do WP Engine e Cloudflare para esta sessão específica de segurança sobre como bloquear seus sites. A discussão destaca as tendências recentes de ataques cibernéticos, juntamente com exemplos específicos de como o WP Engine protege seus sites. Os desenvolvedores sairão com uma lista de verificação clara das etapas a serem seguidas para proteger seus sites.

Slides da Sessão

Transcrição de texto completo

ERIC JONES : Bem-vindo ao DE{CODE}, e obrigado por participar do que promete ser uma sessão incrível. Meu nome é Eric Jones e sou vice-presidente de marketing corporativo aqui na WP Engine. Eu não poderia estar mais animado para moderar esta discussão hoje entre Joe Sullivan, diretor de segurança da Cloudflare, e Brent Stackhouse, vice-presidente de segurança da WP Engine, que têm décadas de experiência em segurança.

Nossa discussão, Mantendo seus sites WordPress seguros em meio a um aumento nos ataques globais de segurança cibernética, não poderia ser mais oportuna, visto que os ataques cibernéticos não estão apenas aumentando, mas estão em todos os tempos, quebrando recordes. Joe, por que não começamos com você? Eu adoraria ouvir de uma perspectiva ampla e macro quais tendências você está vendo no cenário de segurança cibernética.

JOE SULLIVAN : Claro. Estou feliz em participar. Obrigado por me convidar para esta conversa. Eu também estou realmente ansioso por isso. Acho que há duas megatendências no mundo da segurança no momento. O número um é que é muito mais importante aos olhos do mundo.

Portanto, antes de abordarmos o lado técnico e os desafios reais que enfrentamos dia após dia, vale a pena reservar um momento para observar o quanto o mundo da segurança evoluiu desde que Brent e eu começamos nesta profissão, como você disse, décadas atrás.

A segurança não é mais uma equipe ou um conceito que fica no canto de uma organização. É central para tudo o que fazemos. Os CEOs estão sendo responsabilizados. Os conselhos estão fazendo perguntas difíceis. Os capitalistas de risco não contribuirão a menos que vejam o nível certo de investimento.

E, mais importante, nossos clientes e consumidores e compradores empresariais de nossos produtos estão exigindo muito mais de nós. E essa, para mim, é a tendência mais importante e por que estamos tendo essa conversa. É importante para todos os desenvolvedores em todos os aspectos de seu trabalho.

Portanto, voltar ao que realmente está acontecendo no mundo da segurança não está ficando mais fácil. E os desafios continuam chegando até nós. Se você está prestando atenção nas manchetes, você viu apenas nos últimos tempos a ascensão do ransomware. É realmente assustador.

O Ransomware mudou o jogo em termos de segurança porque passou de roubar alguns dados ou expor algo ao mundo para fechar o seu negócio. E assim todo o conceito da importância da segurança foi ampliado por esse risco, a ideia de que poderíamos acordar de manhã e não conseguir ligar nossos laptops, não fazer nosso site funcionar. Isso é realmente assustador.

As coisas geopolíticas também estão realmente começando a impactar todos nós. A situação na Ucrânia não está contida no mundo físico. Está fortemente no contexto cibernético agora. E está se espalhando para impactar o resto de nós. Portanto, os eventos geopolíticos que estão acontecendo no mundo físico têm implicações técnicas para aqueles de nós que estão tentando operar negócios na Internet.

E acho que a terceira coisa que gostaria de mencionar do ponto de vista técnico é que não vivemos em mundos com nosso próprio código. Vivemos em mundos que são uma fusão de software e código que se juntam para representar uma organização.

E assim, em segurança, usamos o termo cadeia de suprimentos para falar sobre todos esses outros códigos e outros aplicativos e tudo o que se torna parte de nossa identidade como empresa. Então, por exemplo, quando houve histórias recentes sobre o comprometimento do Okta, não era apenas uma questão de saber se o Okta estava comprometido. Era uma questão de saber se minha empresa e todas as outras empresas que usam o Okta estão comprometidas.

E meus clientes não se importavam com a Okta. Eles se preocupavam com o uso que faziam de nós, e que controles tínhamos para mitigar o risco de o Okta ser comprometido? Então, há muita coisa acontecendo agora. E é um bom momento para ter essa conversa.

ERIC JONES: Joe, apenas como uma pergunta de acompanhamento, como você pensa sobre a priorização de todos esses desafios específicos que você tem e que toda organização de segurança tem?

JOE SULLIVAN: Claro. Acho que essa é a pergunta final. Se tivéssemos um orçamento ilimitado e pessoas ilimitadas que pudessem fazer o trabalho, poderíamos fazer tudo. Mas essa não é a realidade em nenhuma organização em qualquer estágio de seu desenvolvimento.

Então, estamos sempre em processo de priorização. E então, o que eu diria é que você deve priorizar o básico primeiro. É chocante ver que uma grande porcentagem dos compromissos vem de falhas no básico.

Como profissionais de segurança, adoramos explorar esse ataque de dia zero ou ataque de dia O e observar essa coisa realmente complicada. Mas 90% das vezes, os comprometimentos vêm de e-mails de phishing ou de alguém que optou por usar a mesma senha que usou em um site pessoal que foi comprometido e não ativou a autenticação multifator.

Muitas vezes, na verdade, temos as ferramentas para fazer bem o básico, mas não perdemos tempo para implementá-las.

ERIC JONES: Sim, acho que você está atingindo um ponto crucial em segurança, certo? Isso é algo pelo qual somos todos responsáveis. É uma responsabilidade compartilhada em toda a organização. Ele não vive apenas dentro da equipe de segurança. Vive com cada funcionário de uma determinada empresa.

Brent, voltando para você, do ponto de vista do WordPress, o que é igual, o que é diferente no WordPress e quais são alguns dos maiores pontos de vulnerabilidade que você vê no cenário?

BRENT STACKHOUSE : Obrigado, Eric, e obrigado por me convidar. Aprecie compartilhar o tempo com Joe. Ele sabe um monte de coisas. Já estivemos no quarteirão algumas vezes. Então isso é fascinante.

WordPress de várias maneiras – as notícias geralmente são boas no sentido de que o WordPress Core é diferenciado de todos os plugins, temas e outras coisas no ecossistema WordPress. O WordPress Core continua robusto e resiliente contra ataques comuns.

Portanto, o próprio WordPress é uma plataforma boa, estável e forte que os clientes geralmente devem se sentir confortáveis ​​em usar em praticamente qualquer contexto. O desafio está principalmente no lado do plug-in, onde o wordpress.org ou os principais desenvolvedores geralmente não têm nada a ver com a maioria dos plug-ins e temas.

E a variabilidade da qualidade do código, semelhante aos aplicativos que você obtém na Play Store do Google ou algo assim, não são escritos, como eu estava dizendo, pelo Google. Eles não são escritos pelo WordPress, esses plugins e temas podem ser qualquer coisa, desde um único desenvolvedor até uma equipe. A pegada desses plugins ou temas pode ser muito pequena a muito grande. Eles podem ter um bom histórico de corrigir as coisas rapidamente ou não.

E assim depende. Portanto, à medida que o WordPress cresce em popularidade e o ecossistema cresce em popularidade, você pode presumir que os invasores continuarão a aumentar seus esforços porque os invasores vão para onde está o dinheiro, semelhante ao motivo pelo qual o Windows tem mais malware do que os Macs em geral. Isso porque é onde está a pegada e é onde está o dinheiro.

Portanto, o WordPress não é diferente e, à medida que sua popularidade aumenta, você pode esperar que os invasores continuem fazendo o que estão fazendo. A boa notícia é que, em comparação com quando iniciei o WP Engine, quatro anos atrás, o ecossistema está muito mais saudável.

Os desenvolvedores de plug-ins e de temas estão mais cientes de que receberão informações de pesquisadores de segurança ou de outras pessoas que notam vulnerabilidades. E a maioria deles está construindo esse músculo de forma responsável, para que possam mudar os patches muito, muito rapidamente.

Então as coisas estão muito melhores do que costumavam ser. Quatro anos atrás, muitos desenvolvedores ficavam surpresos quando as vulnerabilidades aconteciam e eles não eram tão rápidos ou capazes de atender às necessidades de seus clientes em termos de correções regulares.

Todos nós, como consumidores de tecnologia, estamos acostumados a, entre aspas, “Patch Tuesday” ou nossas atualizações regulares da Apple, etc. Portanto, não estamos surpresos com as vulnerabilidades. Ficaríamos, no entanto, muito surpresos se esse fornecedor não corrigisse algo com responsabilidade e rapidez.

Portanto, o ecossistema WordPress é, em geral, mais saudável do que era, eu acho, quatro anos atrás. Mais uma vez, o WordPress Core é ótimo, mas acho que os plugins e temas geralmente estão acompanhando. Então isso é bastante positivo.

ERIC JONES: Apenas para clicar duas vezes em algo que você disse sobre o WordPress Core, o que há na própria natureza do software de código aberto que talvez ajude com o problema de segurança? Porque eu acho que esse é um daqueles equívocos e mitos que dizem que, de alguma forma, o software de código aberto não é fundamentalmente seguro.

BRENT STACKHOUSE: Bem, essa é uma ótima pergunta. E eu estaria interessado nos pensamentos de Joe sobre isso. E não para jogar uma curva em você, Eric, mas eu sou velho o suficiente. Eu vi o que queremos dizer com mudança de código aberto um pouco ao longo do tempo.

Antigamente, o código aberto costumava ser projetos muito conhecidos, como o Apache, ou, digamos, OpenSSH, ou, digamos, Linux, e coisas assim, e quando dizemos código aberto naquela época, era o que normalmente éramos referindo-se a.

E, sim, havia muitos projetos secundários, terciários, quaisquer projetos menores por aí que não eram tão bem mantidos etc. mais pode pegar.

Você está falando sobre bibliotecas, código muito pequeno que qualquer um poderia dizer, oh, isso parece ótimo com base em seus recursos, que vamos incorporar isso. E falarei um pouco mais tarde, como Joe aludiu aos problemas da cadeia de suprimentos. Falarei um pouco mais tarde sobre os desafios específicos do desenvolvedor em termos de mitigação de riscos da cadeia de suprimentos.

Porque o código aberto – penso na sua pergunta, Eric, sobre o WordPress. É ótimo que a fonte esteja lá fora. Muitas pessoas estão olhando para isso. Eu acho que isso também é verdade antigamente com o Apache e coisas assim. Qualquer coisa que seja usada de forma generalizada vai receber muito escrutínio, tanto dos mocinhos quanto dos bandidos, e acho que isso é bom. A segurança através da obscuridade nunca foi uma boa prática. E ter o código disponível é ótimo.

Mas código aberto igualando melhor segurança do que fechado ou vice-versa é uma pergunta difícil de responder. Porque eles são literalmente maçãs e laranjas. Acho que o WordPress como uma equipe fez um ótimo trabalho usando outras entradas além de sua própria inteligência, como usar um programa de recompensa de bugs. O WordPress Core faz isso há anos. Eu acho isso inteligente.

Eles, sem dúvida, têm pesquisadores não afiliados enviando-os regularmente com suas descobertas. E as equipes inteligentes pegam essas informações e fazem a coisa certa. Tenho certeza de que eles próprios estão fazendo testes de caneta, etc. Portanto, fazemos coisas semelhantes no WP Engine, mas isso é meio que normal.

Joe, alguma opinião sobre isso? Desculpe assumir o controle, Eric, mas...

ERIC JONES: Não, isso é perfeito.

JOE SULLIVAN: Acho que você acertou bastante nos pontos altos. Quando penso em software de código aberto – quando penso em software de qualquer fonte, acho que temos que avaliá-lo antes de colocá-lo em nosso ambiente. E, às vezes, o software de código aberto será a melhor escolha do que algo proprietário. Porque você sabe o quê? A luz solar mata a infecção.

E o que acontece com muitos softwares de código aberto é que muitas outras pessoas também estão olhando para eles. Acho que é algo no mundo da segurança em geral que não fazemos bem o suficiente, todos sentamos em nossas pequenas equipes e cantos e tentamos resolver tudo sozinhos.

Envolver a comunidade é uma coisa boa. A transparência e o diálogo sobre os riscos em torno de partes específicas do software são uma coisa boa. E estamos melhorando nisso. Seu exemplo de programa de recompensas por bugs é outra forma de trazer transparência e convidar terceiros a fazer furos.

O software de código aberto atrai muitas pessoas quando falamos sobre as partes mais usadas e importantes do software de código aberto. Mas, da mesma forma, eu não pegaria um código do GitHub e colocaria no meu produto sem realmente examiná-lo.

Eu também diria que você precisa ter o mesmo cuidado ao comprar uma licença de software proprietário. Você ainda precisa ver quem está fazendo isso, quais práticas eles têm e quão robusto é.

BRENT STACKHOUSE: Sim, muito disso é sobre– e este é um termo nerd de risco– mas sobre garantia. Que garantia podemos obter para qualquer coisa que estamos fazendo em um sentido técnico de quão seguro é uma vez que fazemos A, B, C. E muitas garantias, dependendo da situação com código fechado, é mais difícil de obter.

No código aberto, você pode ter uma ideia melhor e mais fácil de quem fez o quê para verificar o código. É um pouco mais complicado com código fechado. Você está tendo que usar insumos indiretos que mostram que esta empresa teve boas práticas de segurança ao longo do tempo, etc.

Mas, sim, obter garantias é, no final das contas, o que você está tentando fazer quando está implantando, usando qualquer tecnologia em geral. Obrigado.

ERIC JONES: Então, para os desenvolvedores que estão por aí, quais são essas garantias específicas que vocês procuram nas empresas? Se esses projetos ou softwares tiverem essas coisas, você os considera bons, um pouco mais seguros do que poderiam ser.

BRENT STACKHOUSE: Você quer uma resposta WordPress? Vou deixar Joe ir se você quiser começar em geral.

ERIC JONES: Sim, Joe, se você pudesse fornecer talvez uma perspectiva ampla e, em seguida, Brent, você pode fornecer a perspectiva mais específica do WordPress.

JOE SULLIVAN: Sim, de onde estou, penso nessa questão como comprador e como vendedor porque trabalho na Cloudflare, onde as pessoas estão implementando nossos produtos. E a pergunta número um que qualquer cliente da Cloudflare tem antes de implementar a Cloudflare é: devo confiar na Cloudflare? Porque estamos sentados na frente de todo o negócio deles. E esse é um lugar muito arriscado para colocar alguém, a menos que você confie nele.

Mas também, porque estamos crescendo e precisamos construir nossos produtos, também dependemos de terceiros. E então estou do lado receptor das perguntas difíceis, e do lado que faz as perguntas difíceis.

E, olhe, nenhum de nós tem tempo para ir ou os recursos para entrar e auditar todas as vezes que vamos trabalhar com terceiros. Não temos equipes grandes o suficiente. Não temos a habilidade definida para isso. Então começamos com as certificações de segurança como um conceito que importa aqui.

Quando digo certificações, quero dizer coisas como um SOC 2, um SOC 2 Tipo II como o WP Engine, ou o ISO 27001 ou PCI. Quando você ouve essas palavras e certificações, o que você deve pensar é que um terceiro usou um conjunto reconhecido de padrões para auditar essa empresa e avaliar se eles estavam atendendo a todos os controles dessa área.

E assim cada um de nós– Cloudflare tem um relatório SOC 2 Tipo II que podemos compartilhar. O WP Engine possui um relatório SOC 2 Tipo II que podemos compartilhar. E o bom de quando digo Tipo II, significa que não foi apenas uma auditoria pontual. Foi um longo período de tempo.

Assim, por exemplo, com nosso SOC 2 Tipo II, isso significa que, no ano passado, em qualquer momento durante o qual essa certificação existe, estávamos em conformidade com esses controles mínimos de segurança. Muitas vezes isso é o suficiente para um cliente. Tipo, ah, aquela empresa tem um SOC 2 Tipo II. OK, vou confiar neles.

Mas então você pode querer se aprofundar um pouco mais com base em sua implementação específica. Portanto, quando penso em comprar um produto, penso não apenas na qualidade do código, mas em como ele se integra ao meu ambiente.

E algo que importa muito para mim é a autenticação. Posso integrar isso com meu logon único para que eu possa gerenciar quem dentro e fora da minha organização tem acesso a ele? Porque é daí que, como eu disse antes, vem uma grande porcentagem dos problemas de segurança.

Portanto, você deseja escolher produtos como o WP Engine, onde pode integrá-lo ao seu SSO e deixar a segurança passar pelas ferramentas sem que você precise fazer muito trabalho prático. Portanto, para mim, são certificações mais a combinação de tudo o mais que você deseja para seu ambiente específico.

ERIC JONES: E, Brent, devolvendo a pergunta para você, como você pensa sobre isso no contexto do WordPress?

BRENT STACKHOUSE: Sim, acho ótimo. Quando as pessoas estão procurando estender o ecossistema WordPress, por assim dizer, usando plug-ins e temas, algumas coisas a serem observadas, mesmo em um contexto de negócios ou camada de negócios, quão popular é esse determinado pedaço de código, plug-in ou tema? E posso ver em seu changelog que eles estão atualizando regularmente, inclusive para atualizações de segurança?

Essas são medidas ou insumos muito qualitativos, mas ainda são relevantes. Normalmente, desenvolvedores de plugins ou desenvolvedores de temas que têm uma grande pegada– eles têm muitos clientes– eles têm algo a perder e ganhar, por assim dizer, mantendo seu código bem ou mal, dependendo de como você quer virar isso. E, portanto, simplesmente escolher os mais populares para o que você precisa geralmente é uma boa prática.

No nível do desenvolvedor, você pode aplicar mais controle, por assim dizer. Você pode usar ferramentas de segurança de aplicativos estáticos para um determinado plug-in. Você provavelmente encontrará algo que outro pesquisador de segurança não encontrou? Talvez não, mas ainda é uma boa ideia executar essas coisas em qualquer que seja o seu ferramental. E há muitas ferramentas gratuitas de código aberto por aí ou mesmo ferramentas comerciais com custo muito baixo ou licenças gratuitas que podem permitir que você obtenha uma melhor garantia sobre qualquer código que esteja usando em seu ambiente.

Uma coisa que Joe tocou e que falarei um pouco com você também é que o WP Engine também é um consumidor de código e também um produtor e, portanto, também somos um provedor de serviços e estamos muito preocupados com a integridade de nossos esforços de desenvolvimento de ponta a ponta. E é um desafio contínuo.

Portanto, uma das coisas para nossos desenvolvedores que executam sites WordPress é que eles devem estar cientes, esperançosamente, do contexto de risco de sua organização. Em que vertical eles estão, por exemplo? Quanta tolerância a organização tem para coisas ruins acontecendo? Certos setores ou organizações são muito mais suscetíveis a coisas como ataques DDoS, etc.

Então, pensando nisso e potencialmente codificando para essas coisas, você não pode codificar para DDoS, mas certamente pode estar ciente disso e trazer isso à tona. Acho que é muito importante para os desenvolvedores fazerem a coisa certa.

ERIC JONES: Mudando um pouco de assunto e com o objetivo de tentar fornecer algumas recomendações muito específicas, Joe, de uma perspectiva de segurança de alto nível, o que você recomendaria que os proprietários de sites fizessem para ajudar a reforçar sua segurança?

JOE SULLIVAN: Sim, do jeito que penso sobre isso, um grama de prevenção vale um quilo de cura. E, no contexto de segurança, isso significa escolher as ferramentas e plataformas corretas que você usará antes de começar, em vez de tentar construir algo, e agora vamos descobrir como inicializar a segurança em cima disso.

Então, quando você está selecionando plataformas, quando está selecionando ferramentas, quando está selecionando código, você deve pensar nisso com a segurança em mente desde o início. E então, como eu disse, se você conseguir que a segurança aconteça automaticamente por meio das ferramentas que você escolher, você estará em um lugar muito melhor do que se tivesse que contratar pessoas para entrar no lado e fazer um monte de auditorias e, em seguida, tente consertar tudo enquanto o navio está navegando pelo oceano.

Você não pode corrigir isso dessa maneira. E então, para mim, estou sempre procurando, o que posso tirar da caixa do ponto de vista da segurança? Quais são as configurações que existem para mim? E se eu pegar o básico de segurança, acho que existem apenas algumas áreas.

O número um, para mim, é sempre o gerenciamento de identidade e acesso. É por isso que falei sobre a capacidade de integrar logon único desde o início. Se eu estivesse começando uma empresa, uma das primeiras coisas que escolheria seria a configuração de logon único certa que será dimensionada com minha organização. E eu sempre tentaria escolher produtos que se integrassem a ele.

A segunda coisa em que pensaria é: OK, vou ter um monte de código voltado para a Internet. Como resistir a ataques da Internet? Vou ter que seguir meu… Brent mencionou ataques de negação de serviço.

Tenho que descobrir pessoalmente como ter balanceadores de carga e gerenciar tudo isso e comprar produtos como o Cloudflare? Ou vem integrado com uma plataforma que estou comprando para não ter que pensar em segurança. Eu sei que já está embutido, e assim por diante. Então, eu passaria metodicamente por meus funcionários e gerenciamento de identidade e acesso, o código voltado para a Internet.

E então, como o terceiro pilar é provavelmente– sobre o qual não estamos realmente falando aqui– é, como eu configuro os laptops e coisas assim?

ERIC JONES: E, Brent, talvez passando para você, quais são algumas coisas específicas que os desenvolvedores do WordPress devem pensar para criar os sites mais seguros que puderem?

BRENT STACKHOUSE: Sim, minha resposta inicial é interessante. Muito do que estamos falando é uma decisão sobre quando construir ou comprar. Você vai construir seus próprios plugins e todas as coisas que deseja fazer para estender seu ecossistema WordPress? Ou você vai comprar, por assim dizer, mesmo que seja de graça?

Mas isso se aplica, eu acho, a Joe e a mim também, no sentido de que consumimos o código de outras pessoas por meio do GitHub ou qualquer outro mecanismo e poderíamos contratar desenvolvedores e fazer tudo isso do zero. Ou podemos usar algo que outra pessoa já fez.

E por que recriar a roda quando você não precisa? Mas então como você pode ter certeza de que o código que está usando está em boas condições? Então, voltando ao WordPress especificamente, acho que há algumas coisas – isso provavelmente é senso comum para um público de desenvolvedores, mas vamos dizer de qualquer maneira. Quando estiver codificando, codifique com segurança, ou seja, saiba o que está tentando fazer. Tente limitar o que você está tentando fazer em termos de suas funções, todos esses tipos de coisas.

Mas lembre-se do Top 10 da OWASP. O OWASP Top 10 provavelmente é bem conhecido do nosso público. Mas, novamente, o básico é importante, como Joe mencionou anteriormente e, portanto, o básico para o desenvolvedor certamente inclui o OWASP Top 10.

Em seguida, use uma daquelas ferramentas de segurança de aplicativos estáticos que mencionei que são muito boas pré-implantadas ou durante a implantação. Você pode fazer isso automaticamente, por assim dizer. E certifique-se de que o código que você está enviando está realmente em boa forma e que não há vulnerabilidades óbvias conhecidas com seu próprio código se você estiver desenvolvendo um código personalizado.

A terceira coisa está ligada à questão da cadeia de suprimentos de que falamos. E o GitHub tem algumas funções gratuitas que podem realmente informar quando suas dependências upstream têm vulnerabilidades conhecidas. Portanto, o Dependabot, um bot de dependência, é uma ótima coisa que o GitHub fornece, e você deve absolutamente habilitá-lo em seus repositórios. E pode realmente criar PRs automaticamente. E então você terá a opção de mesclar isso, se achar necessário, para que suas dependências upstream pelo menos não tenham nenhuma vulnerabilidade conhecida.

Presumivelmente, todo código tem bugs, mesmo quando você o envia, e tem um subconjunto que provavelmente é bugs de segurança, mas pelo menos precisamos evitar os desafios óbvios aos quais Joe aludiu anteriormente. Não queremos sair nos jornais porque perdemos o óbvio. Tipo, ei, você deveria consertar as coisas. Então, sim, essas são três coisas que acho que os desenvolvedores devem ter em mente para se manterem fora do fogo, por assim dizer.

ERIC JONES: Acho que a pergunta para vocês dois é: quais são as coisas que você vê descendo o pique que não estão no radar agora? E quais são as coisas que as pessoas, desenvolvedores, proprietários de sites deveriam estar pensando e que não estão pensando agora? E essa é uma questão em aberto para qualquer um de vocês.

BRENT STACKHOUSE: Bem, sim, eu quero entrar porque Joe respondeu à Okta antes. Então esse grupo em particular - isso é interessante. Então nós já vimos isso. Portanto, não posso nem dizer que isso está quase caindo no pique.

Mas o grupo que explodiu Okta e também outros grandes nomes que não precisamos necessariamente mencionar neste podcast ou nesta entrevista, eles usam técnicas de engenharia social muito, muito interessantes principalmente, ataques não muito técnicos.

E talvez os desenvolvedores não sejam suscetíveis a esse tipo de ataque. Depende da organização e de onde o desenvolvedor se encaixa. Mas certamente qualquer pessoa que atue como equipe de TI ou pessoa com acesso a ativos, por assim dizer, para uma determinada organização pode muito bem ser alvo de ataques de engenharia social.

Isso é algo sobre o qual não gostamos de falar porque não podemos apenas consertar tecnicamente. Mas os humanos honestamente continuam a ser o ponto fraco. Passar pela porta da frente, como chamamos, ou seja, um ataque externo, geralmente é tecnicamente mais difícil e mais trabalhoso para os invasores. E às vezes, ou muitas vezes, eles passam por ataques de engenharia social. O phishing ainda é muito, muito eficaz por qualquer meio.

Então eu acho que é algo que ainda está se mostrando um desafio. E as organizações provavelmente não concentram seu tempo nisso tanto quanto deveriam.

JOE SULLIVAN: Sim, acho que outra maneira de dizer o que Brent disse em uma voz um pouco diferente é que, na verdade, não quero que os desenvolvedores gastem muito tempo com uma bola de cristal, tentando antecipar o próximo problema de segurança. É mais importante acertar o básico.

E esses princípios cuidarão da maior parte da próxima grande novidade, seja ela qual for. E, a título de exemplo, mencionei que houve uma mudança fundamental em termos do surgimento do ransomware. Ele paralisou as empresas de uma forma que o cibercrime nunca fez antes.

Mas não é como se você saísse e comprasse um produto para bloquear o ransomware. Você volta e faz exatamente as mesmas coisas que já deveria ter feito para lidar com as ameaças anteriores. O que é ransomware? É um software malicioso que é colocado em seu ambiente.

Bem, sempre que um intruso entra em seu ambiente, é ruim. Portanto, temos o direito: se continuarmos focando apenas no perímetro e não permitirmos que nossos funcionários sejam comprometidos ou que nosso código seja comprometido, não precisaremos lidar com o ransomware.

Portanto, em vez de sentar e se preocupar com qual será o próximo ransomware, continue focando no básico. E deixe o resto de nós no mundo da segurança especular sobre o futuro.

ERIC JONES: Joe e Brent, muito obrigado por sua perspectiva, seu tempo e seus conselhos hoje. Tanto para pensar sobre como acertar os fundamentos, a importância da transparência, o que procurar do ponto de vista de um seguro.

E talvez o mais importante de tudo é que a segurança nunca deve ser uma reflexão tardia. Você precisa incorporá-lo desde o início. Encorajo a todos, se você estiver interessado em aprender mais sobre as ofertas de segurança WP Engine ou Cloudflare, consulte nossos sites. E, claro, no WP Engine, temos uma grande quantidade de informações de segurança disponíveis para todos em nosso Centro de Recursos, se você estiver interessado em uma perspectiva específica do WordPress. Então, novamente, para todos aqueles que sintonizaram hoje, obrigado por gastar seu tempo e por se juntar a nós hoje.