O caso Epic mostra por que autorização e auditoria precisam ser testadas juntas

A Epic, fabricante do MyChart, interrompeu a maior parte do desenvolvimento de produtos para reforçar a segurança após vulnerabilidades identificadas pelo modelo Mythos, da Anthropic.[8] Judy Faulkner, fundadora e CEO, estimou uma pausa de seis semanas.[8] A notícia descreve prevenção e remediação, não uma invasão confirmada à empresa.[8]

O que muda para quem desenvolve

Segundo o responsável de segurança citado na cobertura, algumas configurações de clientes poderiam permitir acesso externo a prontuários sem registrar a intrusão nos logs do software.[8] Os detalhes técnicos não foram divulgados, e não ficou estabelecido se os defeitos permitiriam modificar registros sem detecção.[8]

Minha análise é que autorização e auditoria devem compartilhar critérios de aceite. Um teste que verifica apenas o status HTTP não responde se a leitura indevida deixou evidência. Um teste que confirma apenas a existência de logs não responde se o acesso foi corretamente limitado.

Para um SaaS, proponho avaliar cada operação sensível por duas perguntas: quem pode executá-la e como a execução, ou sua recusa, pode ser investigada? A trilha deve explicar o evento sem copiar desnecessariamente o conteúdo que o sistema deveria proteger.

Como aplicar

Monte uma matriz de teste com identidade, recurso, permissão esperada e evento de auditoria esperado. Inclua leitura autorizada, tentativa por identidade sem permissão e tentativa de acesso a um recurso de outro cliente. Use exclusivamente dados sintéticos.

Execute cada caso e correlacione a resposta com os registros produzidos. Confira se é possível distinguir tentativa recusada, leitura concluída e falha interna. Teste também o que acontece quando o mecanismo de auditoria fica indisponível em homologação. A política precisa definir a reação, em vez de deixar o comportamento como acidente de implementação.

No planejamento, estabeleça quem pode interromper funcionalidades para remediação, quais critérios disparam essa decisão e como comprovar que a correção está disponível aos clientes. Separe a descoberta do defeito, o patch construído e a instalação verificada. São marcos diferentes para a gestão de risco.

Cuidados e limites

A Epic afirma não ter acesso aos dados médicos de seus clientes, cuja guarda cabe aos prestadores de saúde.[8] Isso não deve ser usado como atalho para concluir que defeitos no software seriam irrelevantes para instalações desses clientes.

A ausência de detalhes públicos impede reproduzir tecnicamente o problema relatado apenas com essa notícia.[8] O experimento proposto aqui avalia controles de uma aplicação própria, não valida uma correção do MyChart.

Auditoria detalhada custa armazenamento, processamento e cuidado com privacidade. Não recomendo registrar tudo. Recomendo definir evidência suficiente para responsabilizar operações sensíveis e verificar esse contrato junto da autorização. Uma pausa de desenvolvimento pode ser necessária; melhor é ter condições para decidir e executar essa pausa antes da emergência.

Fonte

[8] Fonte: TechCrunch