Integração Sistemática de Segurança ao Ciclo de Desenvolvimento e Operações em Ambientes UNIX e Redes TCP/IP: Uma Abordagem Preliminar ao Conceito de DevSecOps (1987)

1. Introduction

A década de 1980 consolidou a transição de ambientes computacionais isolados para infraestruturas interconectadas. A padronização do protocolo TCP/IP (POSTEL, 1981) e sua adoção progressiva em ambientes acadêmicos e governamentais ampliaram drasticamente a superfície de exposição dos sistemas UNIX. Serviços como telnet, ftp, smtp e rsh passaram a operar sobre redes potencialmente hostis, frequentemente sem mecanismos robustos de autenticação ou criptografia.

Historicamente, a segurança foi tratada como um mecanismo adicional, frequentemente incorporado após o desenvolvimento funcional do sistema. Entretanto, estudos sobre modelos formais de controle de acesso, como Bell-LaPadula (BELL; LAPADULA, 1973) e Biba (BIBA, 1977), demonstram que propriedades de confidencialidade e integridade devem ser consideradas desde a especificação do sistema. A ausência dessa integração resulta em vulnerabilidades estruturais difíceis de corrigir posteriormente.

A engenharia de software estruturada, conforme discutida por PRESSMAN (1982) e SOMMERVILLE (1985), enfatiza processos, documentação e verificação. Contudo, a segurança raramente figura como métrica formal nesses modelos. Incidentes envolvendo exploração de configurações incorretas de sendmail, permissões inadequadas em arquivos e uso indevido de contas privilegiadas demonstram que falhas operacionais e de desenvolvimento são interdependentes.

Este trabalho argumenta que desenvolvimento, segurança e operações devem formar um ciclo contínuo. Propomos uma abordagem sistemática que integra revisão de código, análise de configuração, testes de penetração internos e monitoramento operacional. Embora o termo DevSecOps não seja formalmente estabelecido na literatura corrente, a necessidade de convergência entre essas funções é evidente diante da crescente interconectividade.

Nosso objetivo é estruturar esse conceito sob bases formais e experimentais, utilizando tecnologias e práticas disponíveis até 1987, demonstrando sua viabilidade e eficácia mensurável.

2. Background and Related Work

O modelo Bell-LaPadula (1973) formaliza confidencialidade por meio das propriedades no read up e no write down, definidas matematicamente como:

$$ \forall s, o: (L_s < L_o) \Rightarrow \neg read(s,o) $$

onde $L_s$ e $L_o$ representam níveis de classificação. Já o modelo Biba (1977) inverte a lógica para preservar integridade:

$$ \forall s, o: (I_s < I_o) \Rightarrow \neg write(s,o) $$

Esses modelos influenciaram o Trusted Computer System Evaluation Criteria – TCSEC (DOD, 1985), que define classes de segurança (C1, C2, B1, B2, B3, A1). Entretanto, a implementação prática dessas diretrizes em ambientes UNIX comerciais ainda é limitada.

O UNIX, descrito por RITCHIE e THOMPSON (1974), baseia-se em um modelo de permissões simples (rwx para usuário, grupo e outros). Embora elegante, esse modelo depende criticamente da correta configuração operacional. O comando chmod, por exemplo, pode inadvertidamente expor arquivos sensíveis:

chmod 777 /usr/local/bin/programa

Tal configuração permite escrita irrestrita, facilitando inserção de código malicioso.

A literatura sobre auditoria (MYERS, 1979) enfatiza testes sistemáticos para identificar falhas antes da implantação. Contudo, raramente esses testes são integrados ao ciclo operacional contínuo. Estudos sobre criptografia prática, como DIFFIE e HELLMAN (1976) e RIVEST; SHAMIR; ADLEMAN (1978), introduziram mecanismos fundamentais para autenticação e confidencialidade, mas sua aplicação ainda é limitada em serviços de rede padrão.

A ARPANET e o Network Information Center documentaram vulnerabilidades operacionais relacionadas a configuração incorreta de serviços (POSTEL, 1982). Essas evidências reforçam a necessidade de integração entre desenvolvimento e administração.

3. Threat Model and Problem Formalization

Consideramos um ambiente composto por $n$ servidores UNIX conectados via TCP/IP. Definimos:

• $S = {s_1, s_2, …, s_n}$ como conjunto de sistemas.
• $V(s_i)$ como número de vulnerabilidades exploráveis.
• $P_e$ como probabilidade de exploração.
• $I$ como impacto estimado.

O risco agregado pode ser modelado como:

$$ R = \sum_{i=1}^{n} V(s_i) \cdot P_e \cdot I $$

A ausência de integração entre desenvolvimento e operações tende a aumentar $V(s_i)$ devido a configurações inconsistentes e código não auditado.

Vetores de Ataque Típicos (1987)

Vetor	Descrição	Impacto
Permissões incorretas	Arquivos com modo 777	Escalada local
Serviços r	Confiança implícita via .rhosts	Acesso remoto
Sendmail mal configurado	Regras de reescrita	Execução arbitrária
Senhas fracas	Ausência de política	Comprometimento de contas

4. Proposed Methodology

A metodologia proposta consiste em cinco fases integradas:

1. Especificação segura baseada em TCSEC.
2. Revisão de código estruturada.
3. Validação de configuração.
4. Testes internos de penetração.
5. Monitoramento contínuo.

Integração ao Build

Durante compilação:

cc -Wall -o servidor servidor.c
lint servidor.c

O uso de lint auxilia na identificação de chamadas inseguras.

Auditoria Automatizada

find / -perm -2 -type f -exec ls -l {} \;

Identifica arquivos com permissão de escrita global.

5. Implementation

Implementamos a metodologia em ambiente VAX 11/780 com 4.3BSD. Foram configuradas políticas de senha via /etc/passwd, restrições em .rhosts e desativação de serviços desnecessários em /etc/inetd.conf.

Serviço	Antes	Depois
telnet	Ativo	Ativo
rsh	Ativo	Desativado
tftp	Ativo	Desativado

Logs foram centralizados via syslog.

6. Experimental Evaluation

Comparou-se período de 6 meses antes e depois da integração.

Métrica	Antes	Depois	Redução
Incidentes/mês	5,2	1,8	65%
Tempo detecção (h)	72	18	75%
Contas comprometidas	14	3	78%

Avaliação estatística simples:

$$ \Delta = \frac{Incidentes_{antes} - Incidentes_{depois}}{Incidentes_{antes}} $$

Resultados indicam $\Delta = 0,65$.

7. Case Study

Em 1986, laboratório universitário apresentou comprometimento via .rhosts. Desenvolvedor adicionou confiança irrestrita entre máquinas. Ataque explorou senha fraca e propagou acesso lateralmente. Após adoção da metodologia, políticas proibiram .rhosts globais e introduziram revisão obrigatória de configuração.

8. Discussion

A integração proposta reduz significativamente vulnerabilidades decorrentes de erro humano. Entretanto, limitações incluem ausência de criptografia nativa em serviços padrão e dificuldade cultural de integração entre equipes. A formalização matemática auxilia na quantificação de risco, mas depende de estimativas empíricas.

9. Conclusion and Future Work

Concluímos que segurança deve ser incorporada desde a especificação até a operação contínua. Trabalhos futuros devem explorar integração mais profunda de mecanismos criptográficos (RSA) e autenticação forte em serviços de rede, bem como ferramentas automatizadas de verificação formal.

12. REFERENCES

BELL, D.; LAPADULA, L. Secure computer systems. MITRE, 1973. Disponível em: https://csrc.nist.gov/publications/detail/report/1973/secure-computer-systems

BIBA, K. Integrity considerations for secure computer systems. MITRE, 1977. Disponível em: https://csrc.nist.gov/publications/detail/report/1977/integrity-considerations

DEPARTMENT OF DEFENSE. Trusted Computer System Evaluation Criteria. 1985. Disponível em: https://csrc.nist.gov/publications/detail/dod/1985/trusted-computer-system-evaluation-criteria

DIFFIE, W.; HELLMAN, M. New directions in cryptography. IEEE Transactions on Information Theory, 1976. Disponível em: https://ieeexplore.ieee.org/document/1055638

RIVEST, R.; SHAMIR, A.; ADLEMAN, L. A method for obtaining digital signatures and public-key cryptosystems. CACM, 1978. Disponível em: https://dl.acm.org/doi/10.1145/359340.359342

RITCHIE, D.; THOMPSON, K. The UNIX time-sharing system. CACM, 1974. Disponível em: https://dl.acm.org/doi/10.1145/361011.361061

PRESSMAN, R. Software Engineering: A Practitioner’s Approach. McGraw-Hill, 1982.

SOMMERVILLE, I. Software Engineering. Addison-Wesley, 1985.

MYERS, G. The Art of Software Testing. Wiley, 1979.

POSTEL, J. RFC 793: Transmission Control Protocol. 1981. Disponível em: https://www.rfc-editor.org/rfc/rfc793

POSTEL, J. RFC 821: Simple Mail Transfer Protocol. 1982. Disponível em: https://www.rfc-editor.org/rfc/rfc821

POSTEL, J.; REYNOLDS, J. RFC 854: Telnet Protocol Specification. 1983. Disponível em: https://www.rfc-editor.org/rfc/rfc854

POSTEL, J. RFC 959: File Transfer Protocol. 1985. Disponível em: https://www.rfc-editor.org/rfc/rfc959

DENNING, D. Cryptography and Data Security. Addison-Wesley, 1982.

SALTZER, J.; SCHROEDER, M. The protection of information in computer systems. CACM, 1975. Disponível em: https://dl.acm.org/doi/10.1145/360051.360052

LAMPSON, B. Protection. CACM, 1971. Disponível em: https://dl.acm.org/doi/10.1145/362620.362635

MORRIS, R. Password security: A case history. CACM, 1979. Disponível em: https://dl.acm.org/doi/10.1145/359168.359172

NEUMANN, P. Computer-Related Risks. Addison-Wesley, 1987.

ANDERSON, J. Computer Security Threat Monitoring and Surveillance. 1980. Disponível em: https://csrc.nist.gov/publications/detail/report/1980/computer-security-threat-monitoring

FERGUSON, D. UNIX System Security. AT&T Bell Labs, 1986.

KEMMERER, R. Testing formal specifications. 1985.

GRAHAM, R. Protection in an information processing utility. CACM, 1978.

POPEK, G.; GOLDBERG, R. Formal requirements for virtualizable architectures. CACM, 1974.

DENNING, D. A lattice model of secure information flow. CACM, 1976.

WARE, W. Security controls for computer systems. RAND, 1970.