Entrega Email: Ódio e-mails de phishing? Você vai adorar DMARC
Em 01 de agosto de 2012, alta frequência de acções comerciante Knight Capital perdeu US $ US462 milhões após sistemas de negociação automatizados ficou confuso, uma confusão que já foi atribuída a um erro por um único sysadmin.
O incidente viu as encomendas da empresa para muito mais ações do que seus clientes queriam comprar. Cavaleiro acabou segurando o bebê, para a quantia de $ 462m em um evento que veio a ser conhecido como o "Knightmare".
Knight Capital afundou na sequência do erro e, desde então, se fundiu com outra empresa. Também foi golpeado com uma multa de US $ 12 milhões, e de os EUA Segurança Comissão de Valores ordem (PDF) explicando porque oferece um olhar apenas o que deu errado no departamento de TI em e antes daquele dia fatídico.
Um aplicativo chamado "SMARS" foi o principal culpado. Uma das funções "SMARS era receber ordens de" pai "para comprar acções, que depois se transformou em ordens" filho "que realmente compraram as acções. Ajudar as coisas ao longo era um recurso chamado "Power Peg" que não havia sido usado há anos, mas não havia sido removido do SMARS também.
Em 2012, Knight Capital atualizado SMARS para que ele pudesse interagir com um novo "Programa de Liquidez Varejo (RLP)", oferecido pela New York Stock Exchange. Essa atualização, a SEC diz: "reaproveitado uma bandeira que antigamente era usado para ativar o código Peg Power". O plano era que o novo código RLP para substituir Peg Poder.
Quando a nova versão do SMARS foi introduzido, "Cavaleiro implantado o novo código de PLR em SMARS em estágios, colocando-o em um número limitado de servidores em SMARS em dias sucessivos."
Durante esse processo, realizada a um funcionário de erro crítico, descrito pela SEC como se segue:
"Durante a implantação do novo código, no entanto, um dos técnicos de Knight não copiar o novo código para um dos oito servidores SMARS. Cavaleiro não tinha uma segunda revisão técnico essa implantação e ninguém na Cavaleiro percebeu que o código Peg de energia não havia sido removido do oitavo servidor, nem o novo código RLP acrescentou. Cavaleiro não tinha procedimentos escritos que exigiam tal avaliação ".
Eis o que aconteceu quando o servidor que perdeu o update SMARS passou ao vivo:
"Em 01 de agosto, Knight recebeu ordens de corretores cujos clientes eram elegíveis para participar do RLP. Os sete servidores que receberam o novo código estas ordens processadas correctamente. No entanto, as ordens enviadas com a bandeira reaproveitado para a oitava servidor acionado o código Peg Poder defeituoso ainda presente no servidor. "
O servidor sem patch, portanto, continuou fazendo encomendas "filho" para mais ações do que cavaleiro ou de seus clientes queriam. Então, muitas ordens, de fato, que alguns preços das ações oscilou descontroladamente e Cavaleiro ficou segurando partes ninguém queria que ele havia adquirido a preços que ninguém estava disposto a pagar. No momento em que o mercado tinha se mudado, ele foi deixado com US $ 462m de perdas.
Scorches documento Knight Capital da SEC por suas práticas de gestão de risco negligentes e sistemas pobres para detectar dogy o futuro trades. Também o processo de cílios fraco desenvolvimento e distribuição de software, como se segue:
"Cavaleiro não ter escrito o desenvolvimento de código e procedimentos para a implantação SMARS (embora outros grupos de Cavaleiro tinha procedimentos escritos) e Cavaleiro não requerem um segundo técnico para rever a implementação do código em SMARS. Cavaleiro também não têm um protocolo relativo à escrita acessamento o código utilizado nos seus servidores de produção, como por exemplo um protocolo que exige o teste de qualquer tipo de código depois de ter sido acedida para assegurar que o código ainda funcionou adequadamente. "
Em outra parte, o documento sugere Knight Capital poderia ter previsto o problema. Anteriores testes de recuperação de desastres encontrados problemas relacionados, ea SEC ressalta que "um procedimento escrito que exigem um simples double-check da implantação do código RLP poderia ter identificado um servidor que havia sido perdido e desviou os eventos de 01 de agosto."
O Reg sente para o sysadmin que realizou a atualização do servidor, porque enquanto eles cometeram um erro as conseqüências que fluíam a partir dele pode ser atribuído à prática de desenvolvimento de software desleixado que deixou Peg de energia no lugar anos depois que alguém parou de usá-lo. Falta de rigor de gestão de risco do cavaleiro deixou-lhe horrivelmente exposta.
Falhas nessa escala geralmente acabam sendo usados como exemplos de como não fazê-lo. Quanto tempo você acha que vai ser antes de seus problemas de chefe de um novo manual de política sobre como você trabalha e que verifica suas atividades? Ou você pediu-lhes para fazer isso já? ®
Nenhum comentário:
Postar um comentário