Dois últimos posts

A interseção entre os dois últimos posts é a criação do framework de segurança, levando em conta pessoas, processos e tecnologia.

Há um gap entre a arquitetura do software feito para venda e aquele para uso interno. O primeiro se sujeitará às políticas, digamos, desconhecidas. Guias de aquisição desempenham um importante papel nessa empreitada para ambos os lados -- fornecedores e consumidores. O de uso interno, em tese, seria mais previsível.

A disciplina e o exercício de pensar em segurança desde o início do projeto são aliados para mudar o quadro de incerteza que ronda o desenvolvimento. Prever políticas, enquadrar-se em normas, seguir modelos e padrões tendem sempre a ser benéfico.

Um passo seguinte poderia ser alinhar segurança ao negócio. Também é um assunto controvertido, mas rechaçar simplesmente não é sábio. Tomara que sempre haja um ROI para justificar, um BSC para acompanhar, e calculados de forma inegável, aplicável e tangível.

Unindo ou Joining Peers Together

Então é chegada a hora de unir as equipes em prol de um só objetivo. Desenvolvedores, além do cliente a assombrar, lidarão com dba's, os caras de infra e... também security officers. Uma lenda que diz que a pior atitude para acelerar um projeto atrasado é aumentar a equipe. Imagina o desassossego que alguém obstinado a mitigar riscos (leia-se procurar falhas) deve causar no moral da equipe desenvolvedora.

A Microsoft suscitou um camarada chamado security buddy -- eu chamaria de Bob Esponja -- que faria a interface entre as equipes de dev e segurança. O Esponja iria além de ser o catalisador da fúria recíproca de ambos os lados, seria na verdade o redentor de todos, seria quem viabilizaria (faria enxergar, em última análise convencer) as necessidades e limitações de cada um dos lados. É quem sabe dialogar, nos respectivos idiomas, a realidade que nem sempre respeita a teoria. É o político da TI, sem dúvidas.

O security buddy desempenha o papel de um lead auditor, ajudando equipes a passarem no crivo da outras, todos ganhando no final. Porém, viver de teoria nem sempre é possível e há vezes que o milagre da segurança deve ocorrer em condições nada propícias. Garantir segurança em produto de software sem que haja interação no design dele, é tarefa espinhosa. A solução pode -- sem nunca ter deixado de também ser -- aproximar a segurança dos dados o máximo possível. Estou falando de, na inadimissibilidade de tratar plenamente com a equipe de dev, partir para os dba's.

Se analisarmos bem, a barreira mais espessa em última instância é a dos dados, como e onde são armazenados. Reduzir a superfície de ataque dos bancos de dados e monitar seus acessos de forma adequada pode, em muitos casos, compensar displicências inevitáveis durante o desenvolvimento. Stored procedures podem incorporar mecanismos de autenticação, autorização e accountability rápidos e adequados. Estou falando não do acesso à sp, mas da própria sp, uma sp que seria executada antes daquelas com as regras de negócio.

A vantagem é requerer menos interação com a equipe de dev, facilitando a criação de uma API interna ou contrato. Longe de resolver toda a questão da segurança, é apenas um passo para envolver as equipes num único objetivo.

Regulatory Compliance Demystified

Compliance é terreno meio turvo na área de desenvolvimento, se não houver um processo definido. E mesmo quando há, o foco é absurdamente direcionado aos requisitos -- sensato, pois eles darão as dores de cabeça. Boas metodologias preveriam o levantamento das legislações as quais o negócio estaria submetido, detectando aquelas que afetam diretamente o projeto. Excelente, mas quando as legislações são posteriores a especificação ou implantação do projeto?

O artigo abaixo discute os aspectos pertinentes aos desenvolvedores em algumas das medidas regulatórias mais populares -- Sarbanes-Oxley e HIPAA, por exemplo -- indo ao que interessa a fim de desmistificá-las. Ao término, sempre fica o sentimento que boas práticas, designs patterns e arquitetura adequada (think security first) reduzem drasticamente os efeitos de atos regulatórios posteriores ao projeto. Uma boa arquitetura aderirá a questões regulatórias mais facilmente. Insistindo, softwares devem nascer naturalmente seguros e derrubar as restrições que os impedem, nosso desafio. Seria a melhor maneira, inclusive, para encarar enquadramentos futuros.

Regulatory Compliance Demystified: An Introduction to Compliance for Developers

Livro: The Security Development Lifecycle

É o cerne do trabalho que iniciei em 2004. As publicações vão se diversificando e completando o ciclo. Seria bom ter contado com essa naquela época, teria facilitado o convencimento da orientadora, mas é bom não estar sozinho. :-)

Considerações para depois...

Projetos me remetem a CFO e ROI.

Project charter, stakeholder, sumário executivo, alinhamento ao negócio (objetivos, benefícios, prioridades, riscos, dependências, recursos, orçamento, deliverables)

deliverable = A deliverable is any tangible outcome that is produced by the project. These can be documents, plans, computer systems, buildings, aircraft, etc. Internal deliverables are produced as a consequence of executing the project, and are usually only needed by the project team. External deliverables are those that are created for clients and stakeholders. // A report or product that must be completed and delivered to ensure satisfaction of contractual requirements. // A tangible, measurable output of a task. // An end product in a phase of the SDLC. // The tangible output from a task or a project, eg logical model, project agreement, database design or application.

Alinhamento ao negócio deverá ser um caso à parte. Sempre ou nunca devem ser evitados.

Respostas: Com o projeto...

Quanto o faturamento vai aumentar?
Quais custos vão diminuir?
Vamos corrigir erros críticos ou urgentes?
Vamos atender exigências legais, contratuais ou de mercado?
Vamos automatizar controles internos (manual ou aperfeiçoamento)?

Business case, roi... BSC pode ser a chave.

Lembrar de operacional e estratégico...

São pensamentos para depois.