As três principais reocorrências de segurança no documento são: 1) A percepção de que o mainframe é seguro por padrão e que hackers não têm interesse nele. 2) Políticas e padrões de segurança desatualizados e não implementados corretamente. 3) Muitos usuários privilegiados e falta de separação de funções de segurança.

1. © 2015 IBM Corporation
Auditoria em Mainframe
EUGENIOf@br.IBM.com
IT Specialist – Consultor
MBA em Governança de TI
IBM Certified
zChampion
IBM Security
Pre Sales Support
(11) 9-9658-0594
(11) 5042-0804

2. 2
Agenda
Histórico
Segurança no Mainframe: Visão Geral
Reocorrências
Como melhorar esses pontos

3. 3
Histórico
 Realizamos um grande número de Healthcheck de
segurança em z/OS na América Latina
 Dados obtidos de colegas de outras geografias
 Há uma tendência aos mesmos dados, em clientes distintos
 A mensagem recorrente é:
“Sempre passamos em auditorias” e “Mainframe é seguro”

4. 4
Mainframe (System z) é a plataforma de escolha de …
25 dos 25 maiores bancos globais
110 dos 120 maiores bancos globais, por tamanho de ativos
23 dos 25 maiores clientes de varejo dos EUA
21 das 25 maiores seguradoras
9 das 10 maiores seguradoras globais de saúde

5. 5
System z é Seguro!!!
 Plataforma altamente segura para ambientes virtuais e cargas
heterogêneas
80% de todos códigos ativos correm em Mainframe1
80% dos dados de negócio são hospedados em Mainframe1
O que torna o Mainframe um alvo para hackers
 Segurança é contemplada na estrutura do System z
•Processador
•Hypervisor
•Sistema Operacional
 A segurança no System z possui alto nível de compliance
•Gerência de Identidades e de Acessos
•Criptografia de hardware e software
•Segurança nas comunicações
•Gravação de eventos
 Hoje o Mainframe necessita operar em um ambiente complexo,
incluindo cloud, mobile, big data e rede social, suscetível a
múltiplas vulnerabilidades
•Comunicações
•Storage
•Aplicativos
1Fonte: 2013 IBM zEnterprise Technology Summit

6. 6
No mundo de segurança voltado ao ambiente distribuído, mainframe é
80 % do dado no mundo corporativo reside no mainframe. Mainframe é a escolha
natural para armazenamento e manipulação dos dados críticos.
• Database servers contain your most valuable information
• High volumes of structured data
• Personally identifiable information
• Patient records
Políticas de Segurança desatualizadas ou não executadas propriamente
• Políticas inadequadas, ou seja, práticas de legado e padrões antigos, não atualizadas para
ambientes modernos de Web, Mobile
Por que o Mainframe é um alvo?
“O pessoal de TI vê o mainframe como mais um nó de rede e
frequentemente foca a proteção contra invasão nos PCs.”
Dan Woods, The Naked Mainframe, Forbes.com
“Como mainframe se tornou um componente nas arquiteturas
voltadas ao objeto, ele se tornou exposto ao malware. Web services
no mainframe impactam signitivamente a segurança.”
Meenu Gupta, President of Mittal Technologies Inc.
Perguntando ao John Dillinger a razão dele roubar bancos:
“Porque lá está o dinheiro”.

7. 7
Sites interessantes….
Disponibiliza dicas de como
copiar um banco de dados
de RACF
… e „crackear‟ usando “John
the Ripper”.
RACFSNOW*
• Já usou?
• Conseguiu senhas?
*RACF Password Cracking Tool
Instruções para RACFSNOW
podem ser encontrados no
Google

8. 8
Buscas Perigosas….
SHODAN pode localizar
mainframes na WEB
Localizará sessões 3270
presentes na internet
Qualquer um com um
emulador 3270 pode ser
capaz de visualizar telas
de logon

9. 9
Agenda
Histórico
Segurança no Mainframe: Visão Geral
Reocorrências
Como melhorar esses pontos

10. 10
Visão Geral da Segurança em Mainframe
Nearly all data in the computer centre.
Redes SNA para pontos específicos para TSO,
IMS e CICS.
RACF usado para proteger o sistema operacional
dos usuários internos, com melhoria da
disponibilidade.
Todos usuários do sistema são conhecidos.
Não há como acessar o mainframe, com exceção
do ambiente interno da companhia.
1980 System 390
 Crescimento de dados. Dados movem-se para
outras plataformas.
 Rede SNA são interconectadas utilizando SNI*.
 Tecnologia LPAR.
 RACF usado para proteger o sistema operacional
de usuários internos e de aplicativos. Número de
usuários cresce significativamente.
 Acesso remoto torna-se uma realidade.
1990 System 390 Parallel Enterprise Server

11. 11
Explosão de dados disponíveis, via internet.
TCP/IP networks substitui redes SNA. Emuladores 3270
são fáceis de se obterem.
RACF usado para controlar quantidade enorme de
usuários.
Acesso remoto é a regra.
Usuários acessam de múltiplos pontos, fora da companhia.
2000 eServer zSeries 900
 TCP/IP substitui redes SNA. Emuladores 3270 são
constantes. Tecnologia wireless é uma constante.
 LPARs e Parallel Sysplex dominam. Disponibilidade 24 x 365
é comum e esperada.
 RACF usado para controlar milhares de usuários e todos os
aspectos de acesso ao z/OS.
 Acesso remoto aos sistemas operacionais é normal e
esperado.
 Usuários operam de qualquer localidade.
 Crescimento significativo de hackers e de malware. Ameaças
persistentes nas instalações.
2010 IBM zEnterprise 196
Hackers e software malware são
associados com política de
competição e comércio
Visão Geral da Segurança em Mainframe

12. 12
Prevenção de perda de dados é a chave. Perda de
PII* pode ser catastrófico para uma companhia.
• Essa é uma preocupação?
• Hackers podem acessar dados em seu
mainframe?
EC12 com z/OS possui capacidade de criptografia,
detecção de intrusão, virtualização.
• Essas facilidades estão em uso?
• Só funcionam se são postas para funcionar!
Systemas são acessados por clientes de todos os
lugares, em todas as horas do dia / noite.
• Como identificar um ataque?
• Como ser alertado?
Segurança é um problema real.
• Quando sua segurança foi re-desenhada?
• 1980 ou 1990?
2014
IBM zEnterprise EC12
* Personal Identifiable Information
Visão Geral da Segurança em Mainframe

13. 13
Pontos interessantes . . .
• Mainframe é “seguro”: controles necessitam ser ativados
• Mainframe podem ser e serão hackeados
• http://tinyurl.com/bvcq5su
• RACF não implica em “Segurança”
• Não é seguro por default
• Os usuários internos são as maiores ameaças. . .
• Mais de 80% das vulnerabilidades são acessadas internamente

14. 14
Agenda
Histórico
Segurança no Mainframe: Visão Geral
Reocorrências
Como melhorar esses pontos

15. 15
Recorrência # 1 – Gerência de Mainframe x Segurança
 Não há uma compreensão gerencial, suporte ou direcionamento
 Ênfase em outras plataformas
 Percepção do mainframe como tecnologia velha
 Mainframe é o “Cavalo de Batalha” da companhia
 A cabeça está nos anos 80‟s & 90‟s – as ameaças se atualizaram!
 Pouca compreensão sobre o time de segurança e o valor que eles
agregam

16. 16
Recorrência # 2 – Percepção de Segurança
 Percepção global é que o mainframe é seguro
 Seguro por default
 Nunca foi atacado . .
Hackers não têm interesse ou não têm conhecimento
 Requer mais esforço que outras plataformas?
 Não é „visto‟ externamente . . .
Não há por que se preocupar… As maiores ameaças são
externas (são mesmo externas?)

17. 17
Recorrência # 3 – Padrões de Segurança
 Não há padrões de segurança
 Controles não evoluiram com as atualizações de ameaças
 Implementação atual está desatualizada: média de 15 anos
Exemplo: DASMON
 Resistência a políticas de segurança . . .
“Aqui não diz qual o valor / parâmetro a ser usado. . .”:
 e vamos ao default! …
 e vamos ao next, next, next! Minhas Políticas de Segurança
~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~
~~~~~~~~~~~~~~~~~~~

18. 18
Recorrência # 4 – Aplicativos sem Segurança
 Não há um desenho de segurança
 Controles para aplicativos tentem a ser vistos mais tarde:
adicionados ao final e não misturados com os ingredientes
 Funcionalidades de segurança não implementadas ou não
consideradas
 Sistemas mal configurados, sem “fit for purpose” (uso de standards)
 SDLC (Systems development life-cycle) – segurança não está
contida!

19. 19
Recorrência # 5 – Segurança como Limpeza
 Não há continuidade na segurança
 Operação vista como “luzes acesas e cabeça for a da água”
 Não há estudo de novas funcionalidades
 Não há Engenharia de Segurança
 Não há revisão contínua / teste de controles
Configuração ainda apropriada? Fit for purpose? Mudou algo?
 Não há registros de risco
1. Security
Policy
2. Security
Design
3. Security
Procedures
4. Security
Implementation
5. Security
Auditing
6.
Measurement
Against Policy

20. 20
Recorrência # 6 – Skills de Segurança
 Poucos investimentos em skills & conhecimento
 Pouca gerência de riscos, gerência de ameaças, gerência de
regulamentações
 Skills técnicos com pouca atualização
 Aposentadoria do Staff
Planos de Sucessão
 Pontos únicos de falha

21. 21
 Auditores não conhecem. Não vão a fundo
 “Sempre passamos pelas auditorias”
 “Sempre explicamos a terminologia de mainframe aos auditores”
O que é R.A.C.F.?”
 Muitos pontos de auditoria não são detectados
 Testes tendem a focar no RACF
 Time técnico, suportados pela gerência, não divulgam pontos de
auditoria conhecidos às auditorias internas e externas
Recorrência # 7 – Ah, os Auditores…

22. 22
Recorrência # 8 – ITIL para Segurança
 Processos e procedimentos não estruturados, não documentados
 “Faça como a gente fez da última vez”
 Práticas inconsistentes e níveis de segurança básicos
 Documentação incompleta ou inexistente

23. 23
Recorrência # 9 – Usuários Privilegiados
 Excesso de Usuários Privilegiados
 Excesso de UPDATE / READ na base instalada
 Habilidade de desviar de controles
 Porcentagem de usuários privilegiados tendem a ser de 20% - 30%
da população
Exemplo … 300 usuários com UPDATE às bibliotecas de sistema, com
10 analistas de suporte!
Por que precisam de acesso de leitura à PARMLIB?

24. 24
Recorrência # 10 – Monitoração de Segurança
 Monitoração, alertas e relatórios: quase nada
 Poucos pontos de controle
 Alta dependência do software caseiro e software desatualizado
 Pouca interdependência: times se autopoliciam
 Degradação de controles

25. 25
Recorrência # 11 – Funções Conflitantes
 Pouca Separação de Funções
 Administrador de Segurança e Compliance frequentemente estão no
mesmo grupo ou são a mesma pessoa
 Quem verifica o implementador?
 Pessoal de suporte pode de tudo? Quem questiona?
 Organização estrutural equivocada
 Time de segurança normalmente sob Gerência de Serviços, na
qual Disponibilidade possui prioridade maior que Segurança
 Sem independência de operações de TI

26. 26
Recorrência # 12 – Revisões de Segurança
 Recertificação de segurança
 Inexistente em algumas instalações
 Relatórios com excesso de detalhe e sem lógica de negócio
 Gerentes não entendem o que estão recebendo
 “Faz de conta” que leu
 Raramente solicitam uma revisão nos relatórios, com dados mais focados à
área de interesse
 A disciplina de Papeis e Responsabilidades (Roles and Responsibilities -
R&Rs) não é clara

27. 27
Recorrência # 13 – Donos de Recursos – O que se espera deles?
 Data ownership: frequentemente inefetiva ou incompleta
 Ownership não definida
 Muitos recursos (sensíveis) sem dono
 Donos de recursos não compreendem suas responsabilidades

28. 28
Recorrência # 14 – Dados Expostos
 Arquivos, bibliotecas, dados operacionais frequentemente expostos
Reocorrência: muitos (ou … todos) podem ler dados confidenciais
E daí? Quem faz algo com um dump?
 Arquivos com dados úteis para um hacker
 Um hacker interno pode ter acesso a senhas ou a métodos de
criação de senhas
 Acesso de atualização a alguns arquivos de sistema significa posse
das “chaves do reino”
Sem segurança = sem detenção!
 Bottom line: Impacto potencial à confidencialidade, disponibilidade e
integridade dos sistemas, dados e aplicativos

29. 29
Reocorrência # 15 – Subsistemas Relevantes e Sem Segurança
 Segurança ineficiente para subsistemas
 Exemplos: Unix System Services, TCP/IP
 Não há desenho de segurança
 Uma porta dos fundos para entrar no sistema
 Aplicativos de negócio e dados dependem desses subsistemas
Estragos a vista, se esses subsistemas não estão alinhados com a
segurança!

30. 30
Reocorrência # 16 – Suporte Técnico
 Práticas de segurança ruins pelo time de suporte
Utilizam métodos pouco seguros e mais práticos
e.g. SVCs caseiras, programas caseiros que ignoram a segurança
Não consultam a segurança para parâmetros de configuração
Escolhas baseadas na conveniência ou recuperação rápida. Ou ainda
escolha „default‟
O conhecimento é restrito ao time
“Os usuários não conhecem… eles não usam… não sabem usar…”
Falta de conhecimento nas ameaças à segurança
Time de suporte normalmente é detentor de grande conhecimento do
sistema operacional, mas pouca informação/educação sobre segurança

31. 31
Reocorrência # 17 – Discos Shared
Discos compartilhados entre Desenvolvimento e Produção!
Discos de produção acessados de
outras LPARs
Na produção, não se pode
controlar o acesso a discos por
outras LPARs
Objetivo básico: recovery
Fácil copiar dados de produção
pelo time de desenvolvimento
No mínimo, deveria ser listado
como risco potencial
DEV
Development
PROD
Production
Sysprog
System z processor
RACF
RACF RACF

32. 32
Reocorrência # 18 – UACC=READ é o Padrão!
 Page data sets, Spool data sets, System dump data sets, SMF data sets
Frequentemente… UACC=READ ou * = READ
Deveria ser:-
UACC = NONE
ID = * not present
Restrição a lista de acessos
Controle de auditoria
Por que?
• Podem conter informações sensíveis. O que há em um dump do
CICS?
• Um hacker interno (qualquer um com usuário de TSO) pode ter
acesso (ah… Quem sabe ler um dump? Quem sabe o que procurar
no SMF?)

33. 33
Reocorrência # 19 – USS – O Primo Pobre
 Unix System Services
 Quem verifica segurança para USS?
 Quem tem acesso ao USS?
 Quem tem UID zero?
Por que soluções de mercado „requerem‟ UID(0)?
 Quem tem autoridade de MOUNT?
 UNIXPRIV é utilizado?
 USS é o órfão do mainframe… ninguém faz desenho de segurança
para esse ambiente.

34. 34
Reocorrência # 20 – SYS1.** São Apenas Arquivos de Controle
 UACC alto demais para SYS1.**
 Nunca, jamais: UACC=READ ou ID* = READ
Ah… mas o default da IBM é UACC=READ
 Novos arquivos em novas versões do zOS já vêm com UACC=READ

35. 35
Reocorrência # 21 – APFs, Essas Autorizadas
 Bibliotecas APF
 Cada APF deve ter seu próprio profile
 Auditoria de atualização deve ser implementada
 Nunca, jamais UACC=UPDATE
 Controle para todas atualizações nessas bibliotecas (PTFs, inclusão,
exclusão, rename de membros)
 Alerta para definições de APF na PARMLIB de bibliotecas não
existentes ou em discos não montados
 Quem tem autoridade para criar bibliotecas APF?
Dúvida: APF podem ter * = READ?
Resposta: Talvez

36. 36
Reocorrência # 22 – WARNING MODE!!!
 Profiles em WARNING mode!
 WARNING mode possibilita acesso ALTER
 Mensagens são geradas, ao mesmo tempo que as portas estão
abertas
 Use com parcimônia, durante curtos períodos de teste, para
determinados recursos

37. 37
Reocorrência # 23 – SYS1.BRODCAST como Lenda Urbana
 SYS1.BRODCAST
 SYS1.BRODCAST não precisa de UACC=UPDATE
 Lenda urbana. Ou melhor, verdade para velhos sistemas operacionais
 Não é mais necessário há mais de 20 anos

38. 38
Reocorrência # 24 - BLP
 Acessos a Bypass Label Processing (BLP)
 BLP permite acesso a todos arquivos e cartuchos
 BLP permite que labels sejam processados como dado
 BLP pode ser protegido por classe de job
 Quantas classes em suas instalações possuem autoridade BLP?

39. 39
Reocorrência # 25 - IDCAMS
 IDCAMS na AUTHTSF
 Não coloque IDCAMS na lista AUTHTSF na PARMLIB(IKJTSO00)
 É uma exposição. É possível obter atributo SPECIAL, quando
IDCAMS está na AUTHTSF
 Há programas de software houses que solicitam IDCAMS na
AUTHTSF como necessário. Não permita!

40. 40
Agenda
Histórico
Segurança no Mainframe: Visão Geral
Reocorrências
Como melhorar esses pontos

41. 41
Como Melhorar Esses Pontos - Sugestões
 Altere sua maneira de pensar . . .
 Pense como hacker! Como isso comprometeria o sistema? Onde se
encontra essa informação? Como prevenir isso?
 Pense em Segurança de ponta-a-ponta
O dado termina no z, mas… onde começa? Por onde passa?
 Pense com uma cabeça de hoje
O mainframe mudou dos anos 80/90 até hoje
 Pense do ponto de vista de negócio
Controles precisam suportar os objetivos do negócio
 Pense em segurança como uma responsabilidade da corporação,
não sua somente
Os colegas na ponta são sempre o ponto fraco da cadeia

42. 42
 Expresse suas preocupações
 Prepare-se com fatos e realize testes
 Padrões de segurança, alinhados com a política de segurança
 Audite todos os sistemas, ou seja, ganhe o controle
 Não se limite a controlar acessos. Pense em controles administrativos, controles
gerenciais, controles forenses . . . .
 Produza relatórios concisos e distribua seletivamente para as áreas afins
 Trabalhe com registros de riscos
 Faça amizade com os auditores e compreenda seus problemas
 Também faça amizade com o suporte de z/OS
 Suporte de zOS possui responsabilidades de segurança!
Bottomline: PROCESSO DE SEGURANÇA É UM PROCESSO CONTÍNUO!
Como Melhorar Esses Pontos - Sugestões