Ferramentas para atingir e manter a conformidade com a norma SOC 2

Atender à conformidade com o Sistema de Controles Organizacionais (SOC) 2 é mais do que um simples processo implementado uma única vez para ser aprovado em uma auditoria. Mudanças permanentes nos procedimentos são tediosas e demoradas, mas são necessárias para garantir que a organização seja aprovada em uma auditoria SOC 2. Não se trata apenas de fornecer uma documentação ao contador. É preciso ter os controles e as ferramentas certas em vigor para manter a conformidade de forma permanente, ou correr o risco de violar as normas de conformidade. Perder a conformidade com o SOC 2 não é uma opção para a maioria das organizações, mas as ferramentas certas garantirão sua conformidade e ajudarão a facilitar a conformidade contínua em auditorias futuras.

Índice

1. Uma breve visão geral do SOC 2
2. Cumprimento das normas do SLA
3. Acompanhamento de métricas para determinar a conformidade
4. KPIs que afetam outras métricas
5. Ferramentas para manter a conformidade
6. Conclusão

Uma breve visão geral do SOC 2

Para as organizações que estão atualmente buscando a conformidade com o SOC, a quantidade de informações a ser considerada pode ser avassaladora. Pode parecer que tudo precise de uma reformulação completa. A maioria das organizações busca a conformidade com o SOC 2 ou o SOC 3. A principal diferença entre a conformidade com o SOC 2 e a conformidade com o SOC 3 é que os relatórios de auditoria do SOC 3 são disponibilizados publicamente. Os requisitos para ambos os tipos são os mesmos, mas o SOC 3 geralmente é divulgado publicamente no site do provedor. Por exemplo, a plataforma de nuvem do Google está em conformidade com o SOC 3 e os relatórios podem ser consultados em seu site.

As auditorias SOC 2 se concentram na capacidade da sua organização de proteger os dados e nos controles utilizados para garantir a disponibilidade e a integridade contínuas dos dados dos seus clientes. Os cinco princípios principais de uma auditoria são:

• Privacidade: Sua organização garante a privacidade dos dados por meio de controles de acesso, autenticação multifatorial (MFA) e criptografia, além de cumprir normas como a conformidade com a FIPS 140-3 para segurança criptográfica?
• Segurança: Vocês impedem que invasores acessem os dados por meio de firewalls, sistemas de detecção de invasão e autenticação multifatorial (MFA)?
• Disponibilidade: Sua infraestrutura inclui monitoramento de desempenho, recuperação de desastres e capacidade de gerenciar incidentes?
• Integridade do processamento: O seu ciclo de vida de desenvolvimento de software (SDLC) e o controle de mudanças incluem garantia de qualidade e monitoramento de processos?
• Confidencialidade: O armazenamento de dados inclui criptografia, controles de acesso e firewalls para proteger contra usuários não autorizados?

Observe que a conformidade com a SOC 2 não é uma certificação como outras normas de conformidade. Trata-se de uma auditoria dos seus procedimentos e infraestrutura atuais para garantir que você atenda a um padrão de alto nível de segurança e disponibilidade de dados.

Cumprimento das normas do SLA

Muitas vezes, na pressa de revisar e aprimorar a infraestrutura de segurança cibernética, os padrões do Acordo de Nível de Serviço (SLA) são negligenciados. Os SLAs são as promessas que você faz aos seus clientes, e essas promessas são contratuais e devem ser cumpridas. Por exemplo, se você prometer aos clientes um prazo de resolução de 5 dias para um problema de nível médio, ele deverá ser resolvido dentro desse prazo; caso contrário, você não cumprirá a meta do SLA.

Na KernelCare, somos ao mesmo tempo clientes e prestadores de serviços. Prestamos serviços aos clientes, mas nossa equipe interna de TI precisa dar suporte aos funcionários da empresa e cumprir os SLAs estabelecidos por nossos próprios padrões e pelas promessas feitas aos funcionários internos. Por sermos ao mesmo tempo clientes e prestadores de serviços, compreendemos a importância de cumprir os SLAs e também a importância de definir expectativas razoáveis.

Os SLAs podem ser negociados, mas, uma vez assinado o contrato, é fundamental que as organizações se empenhem em cumprir os requisitos do SLA. Os requisitos e as métricas do SLA são geralmente monitorados em aplicativos internos, como sistemas de tickets. Um desses requisitos do SLA é o tempo de atividade, que abrange o princípio de disponibilidade da auditoria SOC 2.

Acompanhamento de métricas para determinar a conformidade

Para as organizações que buscam a conformidade, um dos primeiros passos é gerar relatórios e coletar métricas na forma de Indicadores-chave de Desempenho (KPIs). Os KPIs são utilizados para medir diversas métricas distintas em todos os sistemas de TI. Eles podem indicar em que áreas você se destaca e onde há espaço para melhorias. Além disso, podem apontar onde é necessário se concentrar em estratégias mais eficazes e eliminar gargalos.

Um KPI comum utilizado na conformidade com a norma SOC 2 são as medições de tempo de atividade. O tempo de atividade (ou tempo de atividade do sistema) é o período durante o qual um sistema permanece disponível ao longo do ano. O sistema pode ser um servidor, um equipamento de rede ou um dispositivo de armazenamento. Qualquer tempo de inatividade prejudica essa métrica, incluindo manutenções programadas que deixam o serviço fora do ar e exigem uma reinicialização.

Para obter excelentes avaliações de disponibilidade e tempo de atividade, os provedores buscam atingir um número de “noves”. Quanto mais “noves” houver na porcentagem de tempo de atividade, melhor será a qualidade do tempo de atividade e da disponibilidade que um provedor pode oferecer aos clientes. Por exemplo, uma organização que possa prometer apenas 52,60 minutos de tempo de inatividade por ano tem uma porcentagem de disponibilidade ou tempo de atividade de 99,99%, ou seja, quatro “noves”. Quanto menor for o tempo de inatividade, maior será a porcentagem de tempo de atividade. Todas as organizações buscam atingir 100%, mas a realidade é que surgem problemas que interrompem um serviço de forma inesperada, mesmo que apenas por alguns milissegundos, e o monitoramento, os alertas e a resposta da equipe são fundamentais para o cumprimento dos SLAs de correção.

O tempo de atividade não é a única métrica utilizada nas avaliações de conformidade. Normalmente, as organizações acompanham vários KPIs para determinar a eficácia dos procedimentos atuais. Algumas outras métricas incluem:

• O número de aplicativos identificados como vulneráveis a CVEs (Common Vulnerability Exposures), classificados por nível de gravidade (por exemplo: Alto, Médio, Baixo).
• Tempo médio necessário para aplicar correções em softwares vulneráveis, incluindo o sistema operacional
• Disponibilidade por serviço
• Carga e latência do servidor ou da rede

KPIs que afetam outras métricas

Em alguns casos, você pode perceber que há KPIs conflitantes que confundem a situação e dificultam a compreensão do que está acontecendo. Um KPI comum é a famosa “lacuna de vulnerabilidade”, que é o tempo que leva para aplicar uma correção em um sistema depois que uma varredura detecta que o software está vulnerável ou desatualizado. Essa lacuna aumenta a cada hora que passa sem que a correção seja aplicada ao sistema.

Organizações que adiam a aplicação de patches podem considerar essa métrica alta demais para fins de conformidade. O que geralmente acontece é que a aplicação de patches é agendada para um dia específico a cada mês (ou, possivelmente, a cada semana). O problema é que as vulnerabilidades já são de conhecimento público e algumas são anunciadas acompanhadas de código de exploração. Ao adiar as atualizações de software, o servidor permanece vulnerável e exposto a explorações. Em 2019, 60% das violações de dados foram causadas por vulnerabilidades para as quais já havia um patch disponível.

Uma métrica de KPI pode afetar outra e comprometer várias metas. Por exemplo, a lacuna de vulnerabilidades e a aplicação de patches podem afetar o tempo de atividade se for necessário reiniciar o servidor. Novos CVEs são anunciados e correções são implantadas todos os dias, o que pode tornar difícil para as organizações acompanharem o ritmo e evitarem uma reinicialização, o que, por sua vez, gera tempo de inatividade que afeta os SLAs. Por exemplo, se você precisar aplicar uma correção em um sistema em até 30 dias e cada sessão de correção programada exigir uma reinicialização, sua porcentagem de tempo de atividade diminuirá.

Ferramentas para manter a conformidade

Uma boa estratégia para garantir a conformidade e cumprir os requisitos do SLA é utilizar a automação. A automação permite detectar muitos problemas antes que se tornem falhas críticas ou violações de conformidade. Ela também pode ser utilizada para corrigir alguns problemas, como a aplicação de patches. As ferramentas de automação de gerenciamento de patches se integram bem com muitas das ferramentas de varredura de vulnerabilidades disponíveis no mercado, podendo, portanto, ser utilizadas em conjunto para reduzir as lacunas de vulnerabilidade.

Quando as vulnerabilidades são corrigidas manualmente, isso pode ser uma tarefa exaustiva para os administradores. Eles precisam ler relatórios, determinar a versão correta do software, testar as correções e, em seguida, implantá-las no ambiente de produção. Para uma organização com centenas de servidores, isso exigiria uma equipe inteira dedicada exclusivamente à gestão das correções. Esse sistema representaria um desperdício de recursos para a organização, uma vez que existem ferramentas de automação disponíveis. Em vez da correção manual, as ferramentas de automação de conformidade economizam tempo e recursos, ao mesmo tempo em que ajudam a manter o alinhamento com os requisitos de auditoria em constante evolução.

Aqui estão algumas ferramentas de conformidade de TI que a KernelCare utiliza para atender aos requisitos da norma SOC 2 e melhorar a segurança em todos os servidores:

• Tenable Nessus: O Nessus é um dos scanners de vulnerabilidades mais populares do mercado. Ele fará uma varredura na sua rede e identificará vulnerabilidades, incluindo softwares sem patch.
• Ivanti: A Ivanti identificará os ativos e gerenciará a automação da aplicação de patches.
• KernelCare: Utilizamos nosso próprio produto para manter o software atualizado, incluindo bibliotecas de terceiros e o kernel do Linux. Além de aplicar as atualizações automaticamente, o KernelCare é uma solução que não requer reinicialização, o que significa que os servidores não precisam ser reiniciados após a aplicação das atualizações. Esse serviço mantém nossa métrica de tempo de atividade o mais alta possível, sem perder pontos percentuais devido ao tempo de inatividade causado pela reinicialização.

Conclusão

Manter os servidores atualizados com os patches mais recentes contra vulnerabilidades é essencial para garantir a conformidade, mas o mesmo vale para o cumprimento dos SLAs de tempo de atividade. Esse conflito pode dificultar que as organizações encontrem as ferramentas certas e desenvolvam procedimentos que atendam a todos os requisitos. Com a automação, incluindo a aplicação de patches sem reinicialização, as organizações podem manter uma alta porcentagem de tempo de atividade e, ao mesmo tempo, aplicar patches em sistemas vulneráveis em até 30 dias. O resultado é que essas ferramentas aproximam você ainda mais da conformidade com a norma SOC 2 após passar por uma auditoria.