Fundamentos para a arquitetura de sistemas seguros

Se você acha que pode resolver problemas de segurança utilizando apenas tecnologia, então, não entende esses problemas e também não entende tecnologia.
Bruce Schneier
Este capítulo foi escrito em colaboração com Wendel Siota – especialista em segurança na EximiaCo.

Competência tecnológica é fundamento para o sucesso nos negócios. Cadeias produtivas estão cada vez mais integradas. No “chão de fábrica”, as máquinas físicas já têm “gêmeas digitais”. No varejo, as vendas são apoiadas por tecnologia e ocorrem em multicanalidade, com curadoria individual. Fora das empresas, a tecnologia vem impactando, de maneira evidente, cada vez mais, o dia-a-dia das pessoas. Bens de consumo têm cada vez mais sensores, processadores e conexões com a internet. Produtos tecnológicos são canais por onde consumimos serviços, muitos deles essenciais. Nesse contexto, mitigar riscos é essencial.

A onipresença de sistemas digitais, tanto na indústria quanto nas rotinas individuais, além de aumentar o impacto percebido de falhas acidentais, os tornam alvos naturais para ataques criminosos. Por isso, segurança é atributo de qualidade cada vez mais importante em arquiteturas modernas. Sistemas inseguros ameaçam empresas, tanto sob aspectos diretamente financeiros e de imagem, e, não raro, a vida das pessoas!
0
Concorda?x

Fenômenos com impacto mundial, como a pandemia de COVID-19, aceleraram a adoção de recursos e ferramentas digitais, bem como a frequência e a gravidade de incidentes. Legislações ainda imaturas estão entrando em vigor e a incerteza sobre o que é obrigatório ou simplesmente responsável é parte do cotidiano.

No passado, era comum que apenas empresas que trabalhassem com dados obviamente sensíveis se preocupassem com segurança. Hoje, essa distinção não é mais aplicável.
0
Por favor, deixe seu feedback aquix

Tratar de segurança, sob a perspectiva de arquitetura implica em esforços em duas frentes:

  1. Clarificação de restrições e atributos de qualidade relacionados a sistemas seguros, explicitando prioridades e combatendo subjetividades, envolvendo especialistas;
  2. Garantindo que, de fato, todas as restrições e atributos de qualidade identificados sejam levados em conta na avaliação das propostas de design.

Uma das melhores armas que você pode ter em seu arsenal é o código limpo. Outros incluem configurações de software que são seguras por padrão, tão resilientes que mesmo código vulnerável não pode ser atacado com sucesso

Jim Allchin

The Security Development Lifecycle

Livro um pouco antigo, mas ainda consistente para definição de processos de engenharia e design de arquitetura visando a construção de software seguro.

Acessar livro

Infelizmente, sistemas dificilmente serão seguros acidentalmente, ou seja, sem projeto apropriado. O acaso, quando se trata de segurança em sistemas, é desfavorável e não dá proteção aos distraídos. 

Segurança, nos dias de hoje, é importante demais para ser tratado como um tema secundário.

Segurança é um “concern” arquitetural

Boas práticas de arquitetura de software visam contribuir para o atendimento dos objetivos de negócio, respeitando restrições, atingindo atributos de qualidade.

A segurança é, sob o ponto de vista da arquitetura de software, um atributo de qualidade. Como tal, precisa ser adequadamente descrito e priorizado de acordo com os possíveis impactos para o atendimento dos objetivos de negócio.

Segurança é como uma corrente, onde a força é determinada pelo elo mais fraco.

Bruce Schneier

A priorização da segurança durante o processo de design arquitetural determina a natureza e a severidade das restrições arquiteturais derivadas. Por sua vez, essas restrições irão governar o projeto de componentes e suas propriedades, como responsabilidades e relacionamentos, bem como a estratégia evolutiva.
0
Concorda?x

Desdobrando segurança em mais atributos de qualidade

Segurança é um conceito amplo e, por isso mesmo, difícil de ser ponderado durante avaliações arquiteturais. Por causa disso, é comum encontrar na literatura a recomendação de “desdobrar” segurança em mais atributos e princípios arquiteturais. Há anos, o acrônimo CIA tem sido utilizado para associar segurança com confidencialidade (confidentiality), integridade (integrity) e disponibilidade (availability).

  • A confidencialidade tem relação com a garantia de que o acesso a leitura e modificação de informações será restrito a aqueles que possuem autorização.
  • A integridade, por sua vez, indica que apenas dados válidos são aceitos.
  • Finalmente, disponibilidade garante que dados permanecerão disponíveis quando necessários, frente a conduta maliciosa, inocência ou estúpida dos usuários.

Segurança é CIA

Não há exatamente um criador para a tríade CIA, mas foi Don Parker , que  em 1998, no livro “Fighting Computer Crime”,  provocou a popularização da tríade e onde também propôs o Parkerian Hexágono.

Parker argumenta que a CIA Triad cobre apenas metade dos pilares de segurança da informação e apresenta outras três propostas que são Posse ou Controle, Autenticidade e Utilidade. O argumento de Parker é de que os três pilares CIA contemplam apenas tecnologia, enquanto o Hexágono adicionaria o elemento humano.

Recentemente, tem-se considerado também authentication nonrepudiation.

  • Authentication indicando que devem haver meios claros de assegurar que os usuários são quem afirmam ser antes de terem acesso a dados sensíveis ou confidenciais.
  • Nonrepudiation, provendo “evidências confiáveis” de que ações sensíveis tenham sido completadas em todos os agentes envolvidos (incluindo, por exemplo, em um sistema cliente/servidor, ambos os lados).

Garanta a existência de pelo menos um ADR relacionado a cada um dos atributos de qualidade relacionados a segurança indicados aqui, determinando fitness functions para cada uma deles.

Fighting Computer Crime

Donn Parker é reconhecido como um dos maiores especialistas mundiais em cybersecurity. Nesse livro, ele apresenta a ideia de “desdobrar” segurança nos atributos CIA.

Acessar livro

Segurança demanda atenção continuada (não isolada)

Problemas de segurança têm origem na maldade, inocência, estupidez ou infortúnio humano. As medidas para tornar sistemas mais seguros incluem mecanismos para coibição de ações maliciosas, prevenção de uso inadequado ou descuidado e, finalmente, planos de contingência.

Segurança não “acontece”, tampouco é “ligada” em sistemas. Na prática, ela é garantida por projeto cuidadoso, implementação precisa, manutenção disciplinada e operação monitorada.
0
O que acha?x

Segurança é um processo.

Bruce Schneier

World Trade Center

Há dezenas de relatos de empresas que mantinham sistemas principais e suas redundâncias distribuídas nas duas torres do World Trade Center, tragicamente atacadas em 11 de setembro de 2001. Essa estratégia, aparentemente lógica em primeira análise, se mostrou catastroficamente equivocada.

Imprudência ou infortúnio?

Sistemas desenvolvidos e mantidos com métodos que não dão ênfase para a segurança têm alta probabilidade de serem “vitimados” direta ou indiretamente.

Segurança bem implementada desencoraja e coíbe condutas maliciosas, previne enganos e protege contra infortúnios (afinal, acidentes acontecem). Por isso, diminui desperdícios de tempo e dinheiro, protegendo a privacidade das pessoas e a reputação das marcas.

Segurança é um atributo de qualidade “invisível”

Os custos relacionados com segurança têm relação com a prevenção de perdas e não com a geração de ganhos. Por isso, embora necessários são sempre questionados. Segurança é um atributo “invisível”, ou seja, só percebido quando há problemas.
0
Consideraçõesx

Importante destacar que o Brasil, hoje, é segundo colocado mundial na relação de países com maior volume de ataques cibernéticos identificados. Logo, os riscos associados a operações tecnológicas em nosso país são inerentemente mais altos.

Cabe aos arquitetos a responsabilidade de evidenciar os benefícios de priorizar a segurança. Para isso, é útil estimar os custos possíveis na ocorrência “eventos ruins”.
0
Concorda?x

Segurança pode “conflitar” com a confiabilidade

As decisões arquiteturais relacionadas a segurança tratam de riscos diferentes daqueles relacionados a confiabilidade. Embora os temas aparentem similaridade, na prática, são bem distantes.

Riscos relacionados a confiabilidade são, por natureza, relativos a infortúnios, a ingenuidade ou incompetência humana, mas não à maldade. São riscos para a confiabilidade, por exemplo, falhas na atualização de componentes ou no hardware. Riscos de segurança, por outro lado, geralmente decorrem da existência de “adversários” atuando, de forma ativa ou passiva, para explorar vulnerabilidades.

Decisões de design relacionadas a confiabilidade devem assumir que alguma coisa pode “dar errado” em algum momento. Já as decisões relacionadas à segurança devem assumir que há, sempre, algo ou alguém tentando “fazer as coisas darem errado”.

Decisões relacionadas a confiabilidade frequentemente implicam na adição de redundância aos sistemas. Entretanto, enquanto a redundância é uma coisa boa para quando algo “dá errado” ela amplia a superfície de ataque para quem está tentando “fazer as coisas darem errado”.
0
Consideraçõesx

A recuperação de incidentes relacionados a confiabilidade geralmente envolvem várias mais pessoas, com mais “pontos de vista”, atuando para identificar e mitigar causas raiz. Em contraste, incidentes relacionados com segurança geralmente têm poucos envolvidos e somente compartilham informações que realmente precisem ser compartilhadas.

Não raro, informações em logs que cooperam para resolução mais rápida de sistemas em produção também são valiosas para agentes mal-intencionados que, aliás, precisam de apenas “um caminho aberto”.

Segurança pode “convergir” com confiabilidade

Tanto segurança quanto confiabilidade são atributos de qualidade emergentes, ou seja, resultantes de decisões de design.

Sistemas confiáveis e seguros geralmente emergem de um design cuidadoso, atento a ambos atributos, desde o início. Para não serem “vítimas” de erosão arquitetural, sistemas precisam ser testados constantemente, preferencialmente, através de Fitness Functions.
0
Considerações?x

Em sistemas mais complexos, os maiores desafios, tanto para a confiabilidade como para segurança, decorrem da interação entre os componentes. Manter sistemas simples colabora para ambos atributos, indiretamente, colaborando para o MTTR.

MTTR ou MTBF? Depende! Mas sempre com MTTD

Muitos times de engenharia priorizam aumentar o MTBF (tempo médio entre falhas) no lugar de reduzir o MTTR (tempo médio para se recuperar de falhas).

A escolha pelo MTBF acaba justificando deploys menos frequentes (ninguém quer mexer em um sistema que está funcionando), logo, pacotes de atualização maiores, o que causa mais dificuldade para detectar problemas, gerando mais rollbacks e aumentando o leadtime.

MTTR, por outro lado, é incentivo para pacotes de atualização menores, gerados por deploys mais frequentes, teoricamente com impactos menores, menos rollbacks, minimizando o leadtime.

MTTR ou MTBF? Depende muito das implicações para segurança. Entretanto, independente da opção, é importante observar uma tercerira métrica: MTTD (tempo médio para detecção de falhas).

O MTTD refere-se ao tempo médio necessário para descobrir (ou perceber) um possível incidente. Em termpos práticos,  a quantidade de tempo que o time do SOC ou Segurança da Informação precisou para reconhecer uma ocorrência.

Segurança implica combinação de software, infraestrutura e operações

O atendimento da segurança, como atributo de qualidade, demanda cooperação dos times responsáveis por: 1) projeto, implantação e manutenção de software; 2) projeto, deploy e manutenção de infraestrutura; e 3) sustentação das operações. Por isso, especialistas em infraestrutura e operações são mais que bem-vindos nas discussões arquiteturais dedicadas a segurança, sobretudo para revisão do conjunto de restrições desenvolvidos.
0
Concorda?x

Recomendações básicas para mitigação de riscos de segurança

Projetar sistemas seguros é tarefa difícil. Quanto maiores os riscos associados, também maiores são as demandas de envolver especialistas de maneira ativa em todo o ciclo de vida da solução. Entretanto, há algumas estratégias básicas que podem e devem ser observadas sempre nas atividades relacionadas à arquitetura, pelos arquitetos.

Reduzir “privilégios” ao mínimo possível

Riscos de segurança são consideravelmente mitigados quando o projeto de interação do software restringe privilégios ao mínimo necessário, solicitando “elevação de autoridade” para operações com impactos mais altos. Medidas assim, previnem problemas provenientes de descuidos, como, por exemplo, usuários que “esquecem” sistemas logados mercê de agentes mal-intencionados.
0
Consegue dar mais exemplos?x

Seguindo a mesma linha de raciocínio, processos “rodando” sistemas devem “usuários próprios” com privilégios junto ao ambiente operacional reduzidos para o essencial. No caso de intermediação com sistemas externos, deve-se considerar a adoção de redes DMZ ou arquiteturas Zero Trust.

DMZ

DMZ ou zona desmilitarizada, é uma sub-rede que contém e expõe serviços de uma organização para uma rede maior e não confiável, geralmente a Internet.

As regras de segurança relacionadas a redes DMZ são:

  • A rede interna pode iniciar conexões a qualquer uma das outras redes, mas nenhuma das outras redes pode iniciar conexões nesta.
  • A rede pública (internet) não pode iniciar conexões na rede interna, mas pode na DMZ.
  • A DMZ não pode fazer conexões à rede interna, mas pode na rede pública.

Zero Trust

O modelo de segurança Zero Trust (também conhecido como, arquitetura Zero Trust ou arquitetura de rede de confiança zero, ZTA, ZTNA), às vezes também chamado como segurança sem perímetro, descreve uma abordagem para o projeto e implementação de sistemas de TI. 

O principal conceito por trás do modelo de segurança de confiança zero é “nunca confie, sempre verifique”, o que significa que os dispositivos não devem ser confiáveis ​​por padrão, mesmo que estejam conectados a uma rede autorizada, como uma LAN corporativa e mesmo que tenham sido verificados anteriormente .

 A maioria das redes corporativas modernas consiste em muitas zonas interconectadas, serviços e infraestrutura em nuvem, conexões com ambientes remotos e móveis e conexões com TI não convencional, como dispositivos IoT. 

O raciocínio para confiança zero é que a abordagem tradicional — confiar em dispositivos dentro um “perímetro corporativo” , ou dispositivos conectados via VPN —  não é relevante no ambiente complexo de uma rede corporativa. 

A abordagem Zero Trust defende a autenticação mútua, incluindo a verificação da  identidade e integridade dos dispositivos sem respeito à localização e fornecendo acesso a aplicativos e serviços com base na confiança da identidade do dispositivo e da integridade do dispositivo em combinação com a autenticação do usuário.

Decompor sistemas em “contextos delimitados” (de segurança)

A decomposição de sistemas em componentes autônomos, além de facilitar o evolvability e a estruturação de times, é excelente estratégia para desenvolvimento de sistemas seguros.
0
Concorda?x

Componentes independentes devem ter acesso apenas a recursos sensíveis relacionados às responsabilidades que cumprem. Módulos fiscais (e seus usuários), por exemplo, não devem ter acesso aos recursos utilizados por módulos de venda e vice-versa.

Estabelecer relações de confiança (entre componentes)

Idealmente, a interação entre componentes deve ser planejada. Quanto maior o acoplamento aferente de um componente, maiores são riscos potenciais que deste componente para a segurança.

Sempre que possível, a restrição de acessos de fontes não planejadas deve ser garantida em infraestrutura, adotando certificados ou outros mecanismos de identificação.

Monitorar sistemas consistentemente

Todos os eventos sensíveis relacionados a segurança devem ser monitorados e logados em bases não violáveis.

Em cenários onde segurança for realmente prioridade, todas as alterações em “entidades” críticas devem ser armazenadas e gerenciadas em bases de dados append-only .

Observabilidade como atributo relacionado a segurança

Observabilidade, geralmete associada como meio para garantia da saúde e performance de sistemas, também é extremamente valiosa na detecção de eventos de segurança e na análise postmortem destes eventos.

Adotar práticas defensivas em diversos níveis de “profundidade”

Componentes com criticidade para a segurança não devem “confiar” em verificações prévias, Por isso, implementam e avaliam solicitações de outros componentes seguindo alguma forma de controle de acesso.

Projetar segurança como se “ofensores” pudessem “ler o manual”

Não projete sistemas de segurança assumindo que seus “segredos” estão seguros. Eventualmente, dados e estratégias preservados de maneira ingênua se tornam públicos.

Não “reinventar a roda”

Quase nunca é boa idéia criar tecnologia de segurança dentro de casa. Não implemente seu mecanismo de criptografia, mecanismos de identidade, tecnologia de persistência inviolável, etc. Tenha humildade!

Tecnologias e protocolos consagrados eventualmente são difíceis de aprender e adotar, mas esta característica não é indevida. Não cometa o erro de querer simplificar as coisas “reinventando a roda”.

Considerações sobre modelagem de ameaças

Se você for fazer apenas uma atividade do SDL, esta deve ser a modelagem de ameaças.

Michael Howard

Modelagem de ameaças (threats modeling) é tema amplo que demanda abordagem profissional especialista. Entretanto, é útil para arquitetos, sobretudo em projetos intensivos em segurança, conhecer, pelo menos alguma terminologia. A Microsoft, por exemplo, utiliza o modelo STRIDE para categorizar diferentes tipos de ameaças e simplificar discussões a respeito de segurança.

STRIDE é acrônimo para Spoofing, Tampering, Repudiation, Information Disclosure, Denial of Service Elevation of Previlege. Onde:

  • Spoofing é sobre acessar ilegalmente e, em seguida, usar as informações de autenticação de usuários, como nome de usuário e senha;
  • Tampering envolve a modificação maliciosa de dados. Os exemplos incluem alterações não autorizadas feitas em dados persistentes, como os mantidos em um banco de dados, e a alteração dos dados à medida que fluem entre dois computadores em uma rede aberta, como a Internet;
  • Repudiation acontece quando usuários que negam a realização de uma ação sem que outras partes tenham como provar o contrário. Não-repúdio refere-se à capacidade de um sistema de conter ameaças de repúdio;
  • Information Disclosure é sobre exposição inadequada de dados;
  • Denial of Access trata de ataques de agentes mal-intecionados que impedem acesso de usuários válidos – por exemplo, tornando um servidor indisponível;
  • Elevation of Previlege quando um usuário sem privilégios obtém acesso privilegiado e, portanto, tem acesso suficiente para comprometer ou destruir todo o sistema.

STRIDE Threat Modeling using Microsoft Threat Modeling Tool

Uma demonstração básica de utilização de uma ferramenta de modelagem de ameaças da Microsoft considerando o médoto STRIDE.

Acessar vídeo

Threat Modeling: A Practical Guide for Development Teams

Ao contrário da crença popular, a modelagem de ameaças não requer conhecimento avançado de segurança para iniciar ou um esforço hercúleo para sustentar. Mas é fundamental para identificar e abordar possíveis preocupações de maneira econômica antes que o código seja escrito – e antes que seja tarde demais para encontrar uma solução.

Acessar livro

Conhecendo OWASP

Open Web Application Security Project (OWASP) é uma fundação sem fins lucrativos, iniciada em 2001, que objetiva melhorar a qualidade da segurança em sistemas de software. Trata-se de uma comunidade aberta dedicada a capacitar organizações na concepção, desenvolvimento, aquisição, operação e manutenção de aplicações confiáveis. Sem dúvidas, é ativo de conhecimento para qualquer arquiteto.

OWASP Spotlight - OWASP THREAT DRAGON

Boa apresentação da OWASP de sua ferramenta autoral de modelagem de ameaças.

Acessar vídeo

Riscos mais frequentes para segurança (segundo OWASP)

Há anos, a organização mantém um guia com as 10 falhas de segurança mais comuns. Atualmente, são elas:

  1. (SQL|NoSQL|OS|LDAP|*)-Injection
  2. Autenticação mal-implementada
  3. Exposição não-planejada de dados sensíveis
  4. XXE (XML External Entities)
  5. Controle de acesso mal-implementado
  6. Configuração ineficaz de segurança
  7. Cross-site scripting (XSS)
  8. Desserialização insegura
  9. Uso de componentes com vulnerabilidades conhecidas
  10. Logging e Monitoramento insuficientes

Um padrão para verificação de sistemas seguros

OWASP mantém um padrão para aplicação de verificações  de controles de segurança que, também, serve como referência para desenvolvedores e arquitetos verifiquem “conformidade” com práticas de desenvolvimento seguro. Trata-se do ASVS (Application Security Verification Standard).
O objetivo principal do ASVS é normalizar a abrangência e o nível de rigor disponível no mercado quando se trata de realizar a verificação de segurança de aplicativos da Web usando um padrão aberto comercialmente funcional. O padrão fornece uma base para testar os controles técnicos de segurança do aplicativo, bem como quaisquer controles técnicos de segurança no ambiente, que são usados para proteger contra vulnerabilidades, como Cross-Site Scripting (XSS) e injeção de SQL.

OWASP

Um modelo de maturidade para garantia de segurança em software

Eventualmente, mais do que desenvolver aplicações seguras, é desejável desenvolver empresas que desenvolvem aplicações seguras. Para este fim, existe o SAMM.

OWASP SAMM (Software Assurance Maturity Model) é a estrutura OWASP para ajudar as organizações a avaliar, formular e implementar uma estratégia para segurança de software, que pode ser integrada ao seu ciclo de vida de desenvolvimento de software (SDLC) existente. O OWASP SAMM é adequado para a maioria dos contextos, se sua organização está principalmente desenvolvendo, terceirizando ou adquirindo software, ou se você está usando um método em cascata, um método ágil ou DevOps, o mesmo modelo pode ser aplicado.

OWASP

// TODO

Antes de avançar para o próximo capítulo, recomendo as seguintes reflexões:

  1. Segurança está relacionada entre os atributos de qualidade do sistema que está desenvolvendo? Com que prioridade?
  2. Que restrições foram desenvolvidas a partir de segurança?
  3. Você conhecia OWASP?

Referências bibliográficas

ADKINS, Heater; BEYER, Betsy; BLANKINSHIP, Paul; LEWANDOWSKI, Piotr; OPREA, Ana; STUBBLEFIELD, Adam. Building Secure and Reliable Systems: best practices for designing, implementing and maintaining systems. Sebastopol, Ca: O’Reilly, 2020.

Information Is Beautiful (org.). World’s Biggest Data Breaches & Hacks. 2021. Disponível em: https://informationisbeautiful.net/visualizations/worlds-biggest-data-breaches-hacks/. Acesso em: 12 jun. 2021.

OWASP (org.). OWASP Top Ten. 2020. Disponível em: https://owasp.org/www-project-top-ten/. Acesso em: 12 jun. 2021.

OWASP (org.). OWASP Application Security Verification Standard. 2020. Disponível em: https://owasp.org/www-project-application-security-verification-standard/. Acesso em: 12 jun. 2021.

OWASP (org.). OWASP Software Assurance Maturity Model. 2020. Disponível em: https://owaspsamm.org. Acesso em: 12 jun. 2021.

KASPERSKI (org.). CYBERTHREAT REAL-TIME MAP. 2021. Disponível em: https://cybermap.kaspersky.com. Acesso em: 12 jun. 2021.

SCHNEIER, Bruce. Secrets and Lies: digital security in a networked world. Indianapolis, In: Wiley Publisher, Inc, 2000.

SEVERO JÚNIOR, Elemar R. Dispositivos conectados e inteligentes estão revolucionando a competição. 2021. Disponível em: https://elemarjr.com/dispositivos-conectados-e-inteligentes-estao-revolucionando-a-competicao/. Acesso em: 12 maio 2021.

Compartilhe este capítulo:

Compartilhe:

Comentários

Participe da construção deste capítulo deixando seu comentário:

Inscrever-se
Notify of
guest
0 Comentários
Feedbacks interativos
Ver todos os comentários

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Mentorias

para arquitetos de software

Imersão, em grupo, supervisionada por Elemar Júnior, onde serão discutidos tópicos avançados de arquitetura de software, extraídos de cenários reais.

Consultoria e Assessoria em

Arquitetura de Software

EximiaCo oferece a alocação de um Arquiteto de Software em sua empresa para orientar seu time no uso das melhores práticas de arquitetura para projetar a evolução consistente de suas aplicações.

ElemarJúnior

Fundador e CEO da EximiaCo, atua como tech trusted advisor ajudando diversas empresas a gerar mais resultados através da tecnologia.

Podcast

Arquitetura de Software Online

55 51 9 9942 0609  |  me@elemarjr.com

+55 51 99942-0609 |  contato@eximia.co

+55 51 99942-0609  contato@eximia.co

0
Quero saber a sua opinião, deixe seu comentáriox
()
x