Proteção de recursos

Os recursos incluem itens físicos e virtuais, como portáteis, bases de dados, ficheiros e contas de armazenamento virtual. A proteção de ativos críticos para a empresa depende frequentemente da segurança de sistemas subjacentes, como armazenamento, dados, dispositivos de ponto final e componentes de aplicações. Normalmente, os recursos técnicos mais valiosos são os dados e a disponibilidade de aplicações, como sites empresariais, linhas de produção e comunicações.

A proteção de recursos implementa controlos para suportar a arquitetura, as normas e a política de segurança. Cada tipo de recurso e requisito de segurança são exclusivos. As normas de segurança para qualquer tipo de recurso devem ser aplicadas de forma consistente a todas as instâncias.

A proteção de recursos concentra-se na execução consistente em todos os tipos de controlo. Preventivo, detetive e outros alinham-se para cumprir as políticas, padrões e arquitetura.

A proteção de recursos atua como especialista em assuntos técnicos para recursos. Funciona com outras disciplinas, como governação, arquitetura, operações de segurança e equipas de cargas de trabalho. A proteção de recursos garante que a política e as normas são viáveis e permite a implementação de controlos para suportar a política e as normas. A proteção de recursos fornece feedback para melhorias contínuas.

Nota

Normalmente, a proteção de recursos é implementada por equipas de operações de TI que mantêm os recursos e são complementadas por conhecimentos especializados na equipa de segurança. Para obter mais informações, veja Controlos de estrutura como uma equipa.

Os atores de ameaças são persistentes e procuram vulnerabilidades que resultem de lacunas na aplicação de normas e políticas. Os atacantes podem direcionar diretamente os dados ou a aplicação críticos para a empresa. Também podem direcionar a infraestrutura que lhes concede acesso aos dados e aplicações críticos para a empresa. O controlo de acesso centra-se na gestão do acesso autorizado aos recursos. Endereços de proteção de recursos em todas as outras formas potenciais fora de banda para obter acesso ou controlo de recursos. Estas duas disciplinas elogiam-se mutuamente e devem ser concebidas em conjunto para cumprir a sua arquitetura, políticas e padrões. Para obter mais informações, veja Controlo de acesso.

Veja o seguinte vídeo para saber mais sobre o histórico de proteção de recursos e como manter os ativos antigos e novos seguros.

Obter segurança

Concentre-se na criação de recursos para cumprir os padrões de segurança, a política e a arquitetura atuais da sua organização. Existem dois tipos de atividades:

• Brownfield: Reajuste as normas e controlos de segurança atuais aos recursos existentes. As organizações podem conceber e operar ambientes de TI com segurança como baixa prioridade. Esta abordagem cria uma "dívida técnica": configurações de segurança fracas, software que não é atualizado, comunicação ou armazenamento não encriptado, software e protocolos legados, entre outros. Aumente os controlos de segurança para a abordagem atual. Esta melhoria é fundamental para mitigar o risco, uma vez que os atacantes melhoram continuamente a sua capacidade de explorar estas oportunidades.
• Greenfield: Certifique-se de que os novos recursos e novos tipos de recursos estão configurados para normas. Este processo é fundamental para evitar a criação contínua de legados instantâneos ou brownfield, ou sistemas que não cumprem os padrões atuais. Esta dívida técnica terá de ser resolvida mais tarde a uma maior despesa, o que resulta num aumento da exposição ao risco até estar concluída.

Financeiramente, obter uma segurança geralmente mapeia para as despesas de capital (CAPEX) dinâmicas de um investimento único. O orçamento de greenfield para a segurança deve ser mapeado o mais próximo possível da criação do recurso, com uma percentagem reservada do orçamento para a segurança para cada novo projeto de software, atualização de software importante ou iniciativa global de adoção da cloud. Muitas organizações reservam cerca de 10% do orçamento para segurança. O orçamento brownfield é normalmente um projeto especial financiado para elevar os controlos de segurança até às normas e conformidade atuais.

Mantenha-se seguro

Tudo se degrada ao longo do tempo. Os itens físicos desgastam-se. O ambiente muda em torno de itens virtuais, como software, controlos de segurança e segurança. Podem já não cumprir os requisitos de alteração. Estes turnos ocorrem rapidamente hoje devido às seguintes alterações rápidas:

• Requisitos empresariais, impulsionados pela transformação digital.
• Requisitos de tecnologia, impulsionados pela rápida evolução da plataforma cloud e lançamentos de funcionalidades.
• Requisitos de segurança, impulsionados pela inovação do atacante e pela rápida evolução das capacidades de segurança na cloud nativas.

Esta dinâmica afeta todas as partes de segurança, incluindo operações de segurança, controlo de acesso e, em particular, DevSecOps na segurança de Inovação.

Manter-se seguro inclui muitos elementos. Concentre-se nestas duas áreas específicas de proteção de recursos:

• Melhoria contínua da cloud: Abrace a melhoria contínua das capacidades de segurança que a cloud traz. Por exemplo, muitos serviços no Azure, como o Armazenamento do Azure e a Base de Dados SQL do Azure, adicionaram funcionalidades de segurança para se defenderem contra atacantes ao longo do tempo.
• Fim de vida do software: Qualquer software, incluindo sistemas operativos, atinge sempre o fim de vida, quando as atualizações de segurança já não são fornecidas. Esta situação pode expor dados críticos para a empresa e aplicações a ataques baratos e fáceis. Embora o software como um serviço (SaaS) e a infraestrutura e plataformas da cloud sejam mantidos pelo fornecedor de cloud, as empresas têm muitas vezes uma quantidade significativa de software que instalam, criam e têm de manter.

Planeie atualizar ou extinguir software de fim de vida. Investir na sua postura de segurança reduz o risco de um incidente de segurança grave. Manter-se seguro faz parte da dinâmica das despesas operacionais (OPEX) de um investimento contínuo regular.

O dilema do patch

É fundamental que os líderes empresariais apoiem as suas equipas e líderes de TI e segurança. Executar software complexo num ambiente hostil tem um risco inerente. Os líderes de segurança e TI tomam constantemente decisões difíceis sobre riscos operacionais e riscos de segurança.

• Risco operacional: Uma alteração ao software em que o sistema é executado pode interromper os processos empresariais. Estas alterações afetam os pressupostos efetuados quando o sistema foi personalizado para a organização. Este facto cria pressão para evitar alterar o sistema.
• Risco de segurança: Um ataque traz o risco comercial de tempo de inatividade. Os atacantes analisam todas as principais atualizações de segurança no lançamento. Podem desenvolver uma exploração de trabalho em 24 a 48 horas para atacar organizações que não aplicaram a atualização de segurança.

A sua organização pode ter este dilema muitas vezes devido às constantes alterações à tecnologia e à evolução da técnica de ataque. Os líderes empresariais têm de reconhecer o risco de executar uma empresa através de software complexo. Suporte para a atualização de processos empresariais, como estes exemplos:

• Integrar a manutenção de software nos pressupostos operacionais do negócio, agendamento, previsão e outros processos empresariais.
• Investir em arquiteturas que facilitam a manutenção e reduzem o impacto nas operações empresariais. Esta abordagem pode envolver a atualização de arquiteturas existentes ou a mudança para novas arquiteturas inteiramente ao migrar para serviços cloud ou para uma arquitetura orientada para o serviço.

Sem o apoio à liderança empresarial, a segurança e os líderes de TI estão distraídos a apoiar objetivos empresariais importantes. Têm de gerir constantemente a política de uma situação sem vitórias.

Isolamento da rede

O isolamento de rede pode ser uma opção válida para proteger recursos mais antigos que já não podem ser protegidos, mas que não podem ser imediatamente descontinuados. Normalmente, este cenário pode ocorrer para aplicações e sistemas operativos de fim de vida. É comum em ambientes de tecnologia operacional (OT) e sistemas legados.

O isolamento em si é considerado controlo de acesso, embora os recursos que não podem ser protegidos sejam identificados como parte da proteção de recursos. Para obter mais informações, consulte Evitar firewall e esquecer.

Alguns sistemas no fim da vida são difíceis de desligar e isolar completamente. Não recomendamos que deixe estes sistemas inseguros totalmente ligados a uma rede de produção. Esta configuração pode permitir que os atacantes comprometam o sistema e obtenham acesso aos recursos na organização.

Nunca é barato ou fácil atualizar ou substituir a tecnologia informática que tem funcionado bem há uma década ou mais. Pode haver documentação limitada sobre a respetiva funcionalidade. O potencial impacto comercial de perder o controlo de vários ativos críticos para a empresa excede frequentemente o custo de atualização ou substituição. Para estes recursos que não podem ser isolados, as organizações consideram frequentemente que a modernização da carga de trabalho com tecnologia e análise da cloud pode criar um novo valor empresarial que pode compensar ou justificar o custo da atualização ou substituição.

Manter-se seguro é um desafio num mundo que está em constante mudança. É fundamental decidir constantemente quais os recursos a modernizar e o que proteger o melhor possível. Utilize o risco empresarial e as prioridades empresariais para avaliar.

Introdução

Para começar a utilizar a proteção de recursos, recomendamos que as organizações sigam os seguintes passos.

• Concentre-se em recursos bem conhecidos primeiro: Pense em máquinas virtuais, redes e identidades na cloud com as quais a equipa já está familiarizada. Esta técnica permite-lhe fazer progressos imediatos e, muitas vezes, é mais fácil gerir e proteger com ferramentas de cloud nativas, como Microsoft Defender para a Cloud.

• Comece com as linhas de base do fornecedor/do setor: Inicie a configuração de segurança com uma solução bem conhecida e comprovada, por exemplo:

  • Linhas de base de segurança na Referência de Segurança do Azure. A Microsoft fornece orientações de configuração de segurança adaptadas a serviços individuais do Azure. Estas linhas de base aplicam os testes de referência de segurança do Azure aos atributos exclusivos de cada serviço. Esta abordagem permite que as equipas de segurança protejam cada serviço e refinem as configurações conforme necessário. Para obter mais informações, veja Linhas de base de segurança do Azure.
  • Linhas de base de segurança da Microsoft. A Microsoft fornece orientações de configuração de segurança para tecnologias mais utilizadas, incluindo o Windows, o Microsoft Office e o Microsoft Edge. Para obter mais informações, consulte Linhas de base de segurança da Microsoft. Microsoft-security-baselines) para obter mais informações
  • Referências cis. O Centro de Segurança da Internet (CIS) fornece orientações de configuração específicas para muitos produtos e fornecedores. Para obter mais informações, veja Referências cis.

Informações importantes

Estes elementos-chave ajudam a orientar o processo de proteção de recursos:

Equipas responsáveis e responsáveis

A responsabilidade pela segurança deve residir sempre com o proprietário final do recurso na empresa que detém todos os outros riscos e benefícios. As equipas de segurança e os especialistas em assuntos são coletivamente responsáveis por aconselhar o proprietário responsável sobre os riscos, qualquer mitigação e sobre a realização da implementação real.

As responsabilidades de proteção de recursos podem ser executadas por operações de TI que gerem recursos de toda a empresa, equipas de DevOps e DevSecOps responsáveis pelos recursos das respetivas cargas de trabalho ou equipas de segurança que trabalham com as equipas de TI ou DevOps e DevSecOps.

À medida que as organizações passam para a cloud, muitas destas responsabilidades podem ser transferidas para o fornecedor de cloud, por exemplo, atualizar soluções de firmware e virtualização ou facilitar, por exemplo, a análise e a remediação da configuração de segurança.

Para obter mais informações sobre o modelo de responsabilidade partilhada, veja Responsabilidade partilhada na cloud.

Elasticidade da cloud

Ao contrário dos recursos no local, os recursos da cloud podem existir apenas por um curto período de tempo. Conforme necessário, as cargas de trabalho podem criar mais instâncias de servidores, Funções do Azure e outros recursos para fazer uma tarefa. Posteriormente, o Azure remove os recursos. Este cenário pode ocorrer dentro de meses, mas por vezes dentro de minutos ou horas. Tenha em conta esta possibilidade para os seus processos e medições de proteção de recursos.

A elasticidade da cloud requer o ajuste de muitos processos. Melhora a sua visibilidade, com o inventário a pedido em vez de relatórios estáticos. A elasticidade da cloud também melhora a sua capacidade de corrigir problemas. Por exemplo, a criação de uma nova máquina virtual por motivos de segurança pode ocorrer rapidamente.

Gestão de exceções

Depois de identificar uma melhor prática para um recurso, aplique-a de forma consistente a todas as instâncias do recurso. Poderá ter de criar exceções temporárias, mas gerir as exceções com datas de expiração específicas. Certifique-se de que as exceções temporárias não se tornam riscos comerciais permanentes.

Desafios com a medição do valor

Pode ser difícil medir o valor comercial da proteção de ativos. O impacto de um problema não é óbvio até que haja uma falha no mundo real. O risco de não atualizar a segurança para vulnerabilidades é silencioso e invisível.

Preferir política automatizada

Favoreça a imposição automatizada e mecanismos de remediação, como Azure Policy para proteção de recursos. Esta abordagem ajuda a evitar questões de custo e moral de realizar repetidamente tarefas manuais. Também diminui o risco de erros humanos.

Azure Policy permite que as equipas centrais especifiquem configurações a utilizar para recursos em clouds.

Controlos de estrutura como uma equipa

Todos os controlos devem ser concebidos como uma parceria com os principais intervenientes:

• A proteção de elementos fornece conhecimentos sobre os recursos, os controlos disponíveis e a viabilidade da implementação dos controlos.
• A equipa de governação fornece contexto sobre como os controlos se enquadram na arquitetura de segurança, nas políticas e nas normas e nos requisitos de conformidade regulamentar.
• As operações de segurança aconselham sobre os controlos dos detectives. Integram alertas e registos em ferramentas de operações de segurança, processos e formação.
• Os fornecedores e fornecedores de cloud podem fornecer conhecimentos aprofundados sobre os assuntos sobre sistemas e componentes para evitar problemas conhecidos vistos em toda a base de clientes.

Passos seguintes

A próxima disciplina a rever é a governação de segurança