A estrutura de segurança cibernética do Instituto Pátrio de Padrões e Tecnologia dos EUA (NIST) é uma das diretrizes mais importantes do mundo para proteger redes. Pode ser aplicado a qualquer número de aplicações, incluindo SaaS.
Um dos desafios enfrentados pelos encarregados de proteger aplicativos SaaS são as diferentes configurações encontradas em cada aplicativo. Isso torna difícil desenvolver uma política de feitio que se aplique a um aplicativo de RH que gerencia funcionários, um aplicativo de marketing que gerencia teor e um aplicativo de P&D que gerencia versões de software, tudo isso desempenado aos padrões de conformidade do NIST.
No entanto, existem várias configurações que podem ser aplicadas a quase todos os aplicativos da rima SaaS. Neste item, exploraremos algumas configurações universais, explicaremos por que elas são importantes e orientaremos você na feitio delas de uma forma que melhore a postura de segurança de seus aplicativos SaaS.
Comece com administradores
O controle de aproximação fundamentado em função (RBAC) é fundamental para a adesão ao NIST e deve ser aplicado a todos os aplicativos SaaS. Existem dois tipos de permissões em um aplicativo SaaS. O aproximação funcional abrange coisas porquê gerar contas e velejar no aplicativo. As permissões de aproximação a dados, por outro lado, determinam quais usuários podem restaurar e modificar dados. A conta de gestor (ou conta de superadministrador em alguns aplicativos) é a mais sensível do aplicativo, pois tem aproximação totalidade a ambos os tipos de permissões.
Para os agentes de ameaças, violar uma conta de gestor é semelhante a lucrar na loteria. Eles têm aproximação a tudo. As organizações devem fazer tudo o que estiver ao seu alcance para manter o controle sobre essas contas. Esse controle é gerenciado por meio de configurações e práticas recomendadas.
Implementar redundância limitada
É importante ter no mínimo dois administradores para cada aplicativo. Essa redundância torna difícil para um gestor agir sozinho contra os melhores interesses da organização, já que os administradores podem monitorar uns aos outros em procura de quaisquer sinais de violação.
No entanto, cada gestor aumenta a superfície de ataque do aplicativo. As organizações devem encontrar um estabilidade entre ter administradores suficientes para atender adequadamente o aplicativo e, ao mesmo tempo, limitar a exposição. Uma revisão automatizada do número de administradores deve acionar alertas quando o número de administradores estiver fora do pausa preferencial.
Elimine administradores externos
Os administradores externos introduzem uma novidade classe de incerteza na segurança do SaaS. Porquê ficam fora da organização, a equipe de segurança não pode controlar as políticas de senha ou as ferramentas de autenticação que utilizam.
Por exemplo, se um agente de prenúncio tentar fazer login em seu aplicativo e clicar em Esqueci a senha, não há porquê saber se o agente de prenúncio pode violar a conta de e-mail do gestor extrínseco. Essa falta de supervisão de usuários externos pode levar a uma violação profunda de seu aplicativo SaaS, e é por isso que o NIST desaconselha a utilização de administradores externos. Dependendo do aplicativo, bloqueie administradores externos de obter privilégios de gestor ou identifique usuários externos com direitos de gestor e remova esses privilégios.
Para empresas que contratam uma empresa de TI externa ou terceirizam para MSSPs, esses indivíduos não devem ser considerados externos. No entanto, eles devem continuar monitorando outros usuários externos que recebem permissões de gestor.
Exigir MFA de gestor
Para estar em conformidade com os padrões NIST, todas as contas de usuário gestor devem ser obrigadas a acessar o aplicativo usando autenticação multifator (MFA), porquê uma senha de uso único (OTP). A MFA exige que os usuários apresentem no mínimo duas formas de identificação antes de autenticar o usuário. Um ator de prenúncio precisaria comprometer dois sistemas de autenticação, aumentando o nível de dificuldade do comprometimento e reduzindo o risco para a conta. Certifique-se de definir o MFA para administradores conforme necessário (também recomendamos MFA para todos os usuários, mas é obrigatório para administradores).
Baixe esta lista de verificação e saiba porquê alinhar sua segurança SaaS com o NIST
Evite vazamentos de dados
Os vazamentos de dados SaaS representam riscos significativos para as organizações e seus usuários, comprometendo potencialmente informações confidenciais armazenadas em aplicativos baseados em nuvem. Os aplicativos SaaS são comercializados porquê ferramentas de colaboração. No entanto, as configurações que permitem aos usuários trabalharem juntos também podem comprometer arquivos e dados. O NIST, por sua vez, defende o monitoramento das permissões de cada recurso.
Um calendário visível pode expor os funcionários a ataques de phishing de engenharia social, enquanto repositórios compartilhados podem fazer com que o código-fonte interno de uma empresa seja compartilhado publicamente. E-mails, arquivos e painéis contêm dados confidenciais que não deveriam ser acessíveis ao público. Embora as configurações a seguir sejam frequentemente chamadas de alguma coisa dissemelhante em cada aplicativo, quase todos os aplicativos que armazenam teor terão esse tipo de controle.
Pare o compartilhamento público
A diferença entre Compartilhar com Todos e Compartilhar com um Usuário é profunda. Quando os itens são compartilhados com todos, qualquer pessoa com um link pode acessar os materiais. Compartilhar com um usuário, por outro lado, adiciona um mecanismo de autenticação suplementar, pois o usuário precisa fazer login antes de acessar o material.
Para reduzir o teor exposto, os administradores de aplicativos devem desativar o compartilhamento em URLs públicos (“Qualquer pessoa com o link”). Ou por outra, alguns aplicativos permitem que os usuários revoguem o aproximação a URLs que já foram criados. Quando disponível, as organizações devem ativar essa feitio.
Definir convites para falecer
Muitos aplicativos permitem que usuários autorizados convidem usuários externos para o aplicativo. No entanto, a maioria dos aplicativos não implementa uma data de expiração do invitação. Nessas circunstâncias, os convites enviados anos antes podem fornecer aproximação a um agente de prenúncio que acabou de violar a conta de e-mail de um usuário extrínseco. Ativar uma data de expiração automática nos convites elimina esse tipo de risco.
É importante notar que em alguns aplicativos as alterações de feitio são retroativas, enquanto outros só terão efeito daqui para frente.
Alinhe sua segurança SaaS com os padrões NIST – baixe o guia completo
Fortalecendo senhas para fortalecer a segurança dos aplicativos
As senhas são a primeira risco de resguardo contra aproximação não autorizado. O NIST defende uma política de senha possante e muito gerenciada, que é principal para proteger dados confidenciais do usuário, informações comerciais confidenciais e ativos proprietários armazenados na infraestrutura baseada em nuvem. A exclusividade, a complicação e a atualização regular das senhas são aspectos críticos de uma postura de segurança robusta.
As senhas servem porquê elemento fundamental em uma abordagem de segurança em camadas, complementando outras medidas de segurança, porquê autenticação multifator (MFA) e criptografia. Senhas comprometidas podem ser uma porta de ingressão para atores mal-intencionados explorarem vulnerabilidades no envolvente SaaS. A gestão eficiente de palavras-passe aumenta a resiliência universal dos sistemas SaaS, contribuindo para um ecossistema do dedo mais seguro e fiável para as empresas e os seus utilizadores.
Evite ataques de spray de senha
Em um ataque de spray, os agentes da prenúncio inserem um nome de usuário e termos de senha comuns, na esperança de ter sorte e acessar o aplicativo. Exigir MFA é a maneira recomendada de evitar ataques de pulverização de senha. Para aqueles que não insistem que os funcionários usem MFA porquê segmento do processo de autenticação, muitos aplicativos permitem que as organizações proíbam o uso de palavras porquê senhas. Essa lista de palavras incluiria termos porquê senha1, letmein, 12345 e nomes de times esportivos locais. Ou por outra, incluiria termos porquê nome do usuário, produtos da empresa, parceiros e outros termos comerciais.
Acessar as configurações e somar uma lista personalizada de palavras banidas pode reduzir significativamente o risco de um ataque de pulverização de senha bem-sucedido.
Complicação da senha
A maioria dos aplicativos SaaS permite que a organização personalize a complicação da senha. Eles variam desde permitir qualquer senha até exigir caracteres alfanuméricos, letras maiúsculas e minúsculas, símbolos ou comprimento de senha. Atualize os requisitos de senha no aplicativo para corresponder à política da sua organização.
Se a sua organização não tiver uma política de senha, considere seguir as diretrizes do NIST:
- Não faça alterações obrigatórias de senha, pois os usuários tendem a escolher senhas fáceis de lembrar.
- Use senhas longas em vez de senhas complexas. Combinações de números, caracteres especiais e caracteres minúsculos/maiúsculos geralmente seguem um formato porquê leste: Senha1!. Estes são fáceis de usar a força bruta. Uma senha longa porquê MyFavoriteDessertIsPecanPie é fácil de lembrar, mas com 27 caracteres, difícil de usar com força bruta.
- Limite as tentativas de senha a no supremo 10.
- Selecione as senhas em relação às senhas publicadas e outras palavras fáceis de pressentir com uma lista de palavras proibidas.
As configurações realmente importam
Aproximadamente 25% de todos os incidentes de segurança relacionados à nuvem começam com uma feitio incorreta. Além das mencionadas cá relacionadas a aproximação, senha e vazamento de dados, que são bastante universais, são utilizadas configurações para gerenciamento de chaves, segurança traste, resiliência operacional, proteção contra phishing, proteção contra SPAM e muito mais. Configurações incorretas em qualquer uma dessas áreas podem levar diretamente a violações.
Pode parecer improvável que os agentes de ameaças gastem seu tempo procurando configurações incorretas que possam explorar. No entanto, foi exatamente isso que o grupo Midnight Blizzard, patrocinado pelo Estado russo, fez quando violou a Microsoft leste ano. Se podem ocorrer configurações incorretas na Microsoft, vale a pena revisar para ter certeza de que todos os seus aplicativos estão seguros.
Veja porquê você pode empregar os padrões NIST à sua rima SaaS
