 | 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.
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.
Tratar de segurança, sob a perspectiva de arquitetura implica em esforços em duas frentes:
- Clarificação de restrições e atributos de qualidade relacionados a sistemas seguros, explicitando prioridades e combatendo subjetividades, envolvendo especialistas;
- 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. |
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 |
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 e 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. |
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 é 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”
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.
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”.
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.
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
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
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)
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 e 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. |
 | 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. |
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. |
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:
- (SQL|NoSQL|OS|LDAP|*)-Injection
- Autenticação mal-implementada
- Exposição não-planejada de dados sensíveis
- XXE (XML External Entities)
- Controle de acesso mal-implementado
- Configuração ineficaz de segurança
- Cross-site scripting (XSS)
- Desserialização insegura
- Uso de componentes com vulnerabilidades conhecidas
- 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:
- Segurança está relacionada entre os atributos de qualidade do sistema que está desenvolvendo? Com que prioridade?
- Que restrições foram desenvolvidas a partir de segurança?
- Você conhecia OWASP?
