Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
Conforme você estabelece a disciplina arquitetura de segurança, este artigo fornece diretrizes sobre como aplicar 10 leis imutáveis de risco de segurança como dicas práticas à medida que você estabelece e moderniza a disciplina de Arquitetura de Segurança.
Examine as leis imutáveis de segurança
A arquitetura existe para identificar requisitos desafiadores e convertê-los em diretrizes acionáveis para reduzir o risco de segurança, limitar danos e manter os sistemas disponíveis ao longo do tempo. Na base deste trabalho estão as leis imutáveis de segurança.
Essas leis descrevem verdades desconfortáveis sobre segurança que ajudam você a planejar o controle efetivo, evitar equívocos comuns que minam a arquitetura de segurança e criar riscos organizacionais.
| Lei imutável | Impacto na arquitetura |
|---|---|
| 1. Se um ator ruim pode convencê-lo a executar seu programa, não é o seu computador | A execução de código não autorizada causa perda de controle. A prevenção por si só é insuficiente. |
| 2. Se um agente mal-intencionado pode alterar o sistema operacional, não é o seu computador | O comprometimento do plano de controle é um risco sistêmico. Isso se aplica se o plano de controle é um sistema operacional local, um sistema de gerenciamento de identidade, uma ferramenta de segurança ou qualquer outra coisa com acesso de nível de sistema/raiz. |
| 3. Se um agente mal-intencionado tiver acesso físico irrestrito, então não é o seu computador | A exposição física deve ser assumida, não tratada como uma exceção. |
| 4. Se um ator ruim pode executar conteúdo ativo em seu site, não é o seu site | Os limites de execução definem limites de confiança. |
| 5. Senhas fracas comprometem até mesmo a segurança robusta | Falhas de identidade derrotam controles em camadas. |
| 6. Um computador é tão seguro quanto seu administrador | O acesso privilegiado é uma prioridade de segurança extremamente importante. |
| 7. Os dados criptografados são tão seguros quanto sua chave de descriptografia | A criptografia sem governança é frágil. |
| 8. Um scanner antimalware desatualizado é marginalmente melhor do que nenhum | As defesas estáticas decaem. |
| 9. O anonimato absoluto não é alcançável | A visibilidade é inevitável. |
| 10. A tecnologia não é uma panaceia | Falhas humanas e de processo devem ser previstas. |
Aplicar as dez leis de risco de segurança cibernética
Mesmo depois de entender como o controle de segurança é potencialmente perdido e o impacto na arquitetura de segurança, essas informações não são suficientes para projetar um sistema. Os arquitetos de segurança também devem entender:
- Qual é o nosso objetivo de otimização? Onde concentramos o esforço? - Quais compensações são aceitáveis?
Para descobrir essas perguntas, podemos aplicar 10 leis comuns de risco de segurança cibernética. Cada conjunto de leis lida com diferentes aspectos da segurança cibernética.
| Lei | Implicação da arquitetura | Diretrizes de modernização |
|---|---|---|
| 1. O sucesso de segurança está arruinando o ROI do invasor | Criar arquiteturas que aumentam o custo do invasor e reduzem o pagamento, especialmente para ativos de alto valor. | - Concentre controles em torno de identidade, acesso privilegiado e dados confidenciais. - Reduza zonas de confiança sem segmentação; segmente os sistemas para que um comprometimento não ganhe escala. – Priorize as proteções que quebram cadeias de invasores comuns, não casos especiais. |
| 2. Não acompanhar é ficar para trás | As arquiteturas estáticas falham. A arquitetura deve assumir a evolução contínua. | – A arquitetura de segurança nunca é feita. Ela deve ser operacionalmente sustentável e continuamente melhorada. – Design para atualização contínua (aplicação de patch, configuração, política). – Prefira serviços gerenciados e nativos de nuvem que evoluam mais rapidamente do que sistemas locais ou sob medida. – Verifique se a visibilidade e o inventário são requisitos de arquitetura, não reflexões posteriores. |
| 3. A segurança é um habilitador de negócios (a produtividade sempre vence) | Se a arquitetura criar atrito, ela será ignorada. | – Uma boa arquitetura de segurança permite a produtividade por padrão. - Favoreça o acesso baseado em identidade em relação à complexidade da rede. – Integrar controles de segurança a fluxos de trabalho padrão de usuários e desenvolvedores. – Faça dos caminhos seguros os mais fáceis. |
| 4. Os invasores não se importam | Os invasores usam qualquer caminho de acesso disponível no ambiente. A arquitetura deve eliminar os caminhos mais baratos, não defender apenas os óbvios. | – A arquitetura deve refletir o comportamento real do invasor, não as crenças idealizadas em controles individuais. – Assuma o comprometimento por meio de phishing, configuração incorreta ou protocolos herdados. – Remover pontos únicos arquitetônicos de falha catastrófica. - Proteja-se contra todo o ciclo de vida do ataque (movimento lateral, execução dos objetivos), e não apenas o acesso inicial. |
| 5. A priorização implacável é uma habilidade de sobrevivência | Você não pode proteger tudo. | – Arquitetura é sobre escolher o que não fazer. - Identifique os ativos mais críticos e implemente “defesa em profundidade” neles. – Aceite uma garantia mais baixa em que o impacto nos negócios seja menor. – Use cenários de negócios para orientar o investimento em arquitetura. |
| 6. A segurança cibernética é um esporte em equipe | A arquitetura deve integrar o trabalho entre disciplinas e equipes. | - Arquitetos projetam coordenação, não apenas controles. – Alinhar a arquitetura com equipes de plataforma, desenvolvedores e operações. – Delegar controles a plataformas que podem fazer melhor (provedores de nuvem, sistemas de identidade). – Evite soluções personalizadas em que os serviços compartilhados sejam suficientes. |
| 7. Sua rede não é tão confiável quanto você pensa que é | A confiança na rede nunca deve ser o principal nem o único mecanismo de controle. | - Essa lei sustenta o afastamento do design centrado no perímetro. – Altere as decisões de confiança para o contexto de identidade, dispositivo e aplicativo. - Arquiteturas de design que pressupõem que a rede seja observável e hostil. – Mantenha controles efetivos, como firewalls/WAFs (firewalls de aplicativo Web), mas não confie neles para detectar/bloquear tudo. - Use modelos de acesso Confiança Zero consistentemente em todos os ambientes. |
| 8. As redes isoladas não são automaticamente seguras | O isolamento só é eficaz quando rigorosamente projetado e mantido. | – Manter o isolamento de rede que funciona bem. Certifique-se de mantê-lo, e os invasores não podem facilmente contornar isso. – A arquitetura deve considerar as pessoas e o processo, não apenas a topologia. – Trate o isolamento como um sistema, não uma regra de filtragem de rede. - Proteja todos os pontos de ponte (mídia, acesso do fornecedor, administradores). - Pressuponha comprometimento e aplique controles robustos de identidade e operacionais, mesmo em uma arquitetura isolada da rede. |
| 9. A criptografia por si só não é uma solução de proteção de dados | A criptografia é tão segura quanto as chaves que a desbloqueiam. | - A criptografia é importante, mas é ineficaz sem a implementação e a operação seguras. – Arquitete o gerenciamento centralizado de chaves e a governança de acesso. - Proteja caminhos de descriptografia tão agressivamente quanto o armazenamento criptografado. – Combinar criptografia com identidade, monitoramento e imposição de política. |
| 10. A tecnologia não resolve as pessoas e processa problemas | A arquitetura deve assumir processos e humanos imperfeitos. | – Modernizar a arquitetura de segurança para reduzir o raio de explosão do erro humano. Não deixe que clicar em um único email de phishing faça com que sua postura de segurança falhe. – Projetar sistemas que são resilientes ao erro. - Automatize os guardrails sempre que possível. – Evite arquiteturas que dependam de uma operação manual impecável. |
Criar uma arquitetura
Como arquiteto de segurança, você pode usar essas duas tabelas como lentes complementares. Um para validar a solidez técnica e o outro para impulsionar a priorização baseada em risco. Quando combinados, eles formam uma estrutura de decisão prática para o design e a modernização da arquitetura.
| Leis | Objectivo | Uso de arquitetura | Perguntas respondidas |
|---|---|---|---|
| Leis imutáveis de segurança | Capte verdades técnicas que são sempre válidas. | Verifique se as arquiteturas não violam a realidade técnica. Suposições de teste Validar limites de confiança. Evite a falsa confiança. |
A arquitetura é fundamentalmente sólida? O design depende de algo que pode ser facilmente ignorado? Estamos supondo que a tecnologia possa compensar administradores não confiáveis, senhas fracas ou métodos de acesso físico? Estamos confundindo criptografia, isolamento ou ferramentas para controle real? |
| Leis de risco de segurança cibernética | Decida o que mais importa. | Identifique onde investir esforços de arquitetura. Defina roteiros de modernização. Justifique as compensações aos líderes empresariais. |
Onde os atacantes recebem o maior pagamento pelo menos esforço? Quais controles realmente alteram o comportamento do invasor? Que trabalho não vale mais a pena fazer? |
Example
Portanto, se tomarmos um exemplo que aplique as duas tabelas juntas.
| Decisão de design | Lente das leis imutáveis | Dez lentes de leis |
|---|---|---|
| Reduzir a dependência de ACLs de rede ao acesso baseado em identidade | Redes não são confiáveis, a identidade importa. | Aumenta o custo do invasor e está alinhado com os princípios do Confiança Zero. |
| Priorize a autenticação multifator (MFA) para os administradores antes de fortalecer os firewalls de borda. | Senhas fracas comprometem até mesmo uma segurança robusta. | Maneira mais barata de quebrar cadeias de ataque comuns. |
| Segmente as cargas de trabalho em vez de depender de isolamento físico | O isolamento não é seguro automaticamente. | Reduz o raio de explosão quando os invasores entrarem. |
| Automatizar a aplicação de patches e a detecção de desvio de configuração | As defesas desatualizadas falham. | Não se manter atualizado é ficar para trás |
Usar ambas as tabelas em conjunto leva a arquiteturas de segurança que:
- Assuma o compromisso, concentre-se na redução de riscos e limitação de danos, em vez de prometer prevenção absoluta.
- Concentre-se na identidade, privilégio e movimento lateral, não apenas na defesa de perímetro.
- Suponha uma alteração e evolução contínuas, e não diagramas estáticos.
- Balancear a produtividade dos negócios com redução de risco. Alinhe os controles de segurança ao valor comercial.
- Integrar pessoas, processos e tecnologia.
- Reduza o ROI do invasor em vez de perseguir a segurança perfeita.
- Aplique os princípios de Confiança Zero de ponta a ponta.
Próximas Etapas
Verifique se você revisou as outras disciplinas de segurança.