Auditoria em Mainframe. (Eugênio Fernandes)

© 2015 IBM Corporation

Auditoria em Mainframe

[email protected] IT Specialist – Consultor MBA em Governança de TI IBM Certified zChampion IBM Security Pre Sales Support (11) 9-9658-0594 (11) 5042-0804

mailto:[email protected]

2

Agenda

Histórico

Segurança no Mainframe: Visão Geral

Reocorrências

Como melhorar esses pontos

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

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

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

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

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

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

Agenda

Histórico


Reocorrências


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

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


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


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

http://tinyurl.com/bvcq5su

14

Agenda

Histórico


Reocorrências


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Agenda

Histórico


Reocorrências


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

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

Auditoria em Mainframe. (Eugênio Fernandes)

Technology

Transcript of Auditoria em Mainframe. (Eugênio Fernandes)