IBM i Security Exposures Infographic

Post on 18-Nov-2014

591 views 1 download

description

IBM Power Systems servers running IBM i have a reputation as the world’s most securable server. But most IBM i security (also known as iSeries security, AS400 security, etc.) isn’t configured correctly. Find out how to secure IBM i data using the results from over 100 iSeries audits.

Transcript of IBM i Security Exposures Infographic

19%

Enhanced Operating System Security. Level 40

protection plus enhanced operating system integrity.

The best defense.

Operating System Security. Level 30 protection plus

operating system integrity. **IBM Recommended

Resource Security. Object-level security is enforced.

Users do not assume root-level authority by default.

Password Security. Every user must have a valid ID

and password, and assumes root-level authority by default.

No Security. No password required. User IDs are

created for any user who attempts to sign on.

37%

OF SERVERSHAVEQSECURITY SETAT OR BELOWLEVEL 30

*JOBCTLCan hold, release, change,

or cancel any job.

*ALLOBJCan view, change, or

delete any file or program.

USE

R P

RO

FIL

ES

USE

R/P

W M

GM

T.D

ATA

AC

CE

SSN

ETW

OR

K A

CC

ESS

SYST

EM

AU

DIT

ING

OF PROFILES ARE ENABLED,BUT INACTIVE (>30 DAYS)

These settings help make passwords harderto guess. Unfortunately, our findings show thatadministrators don’t always use them:

RECOMMENDED: Expiration intervals should be set to a maximumof 90 days. If your system is used for accounting or financialreporting, a shorter interval is better.

SHOCK ALERT: Many network interfaces allow users to run commands remotely, even without command line permission on their profile. Without an exit program, you have no way to audit this user activity.

RECOMMENDED: Experts suggest <10users with special authorities.

SYST

EM

SE

CU

RIT

Y

95% OF LIBRARIES HAVE DEFAULTCREATE AUTHORITY SET TO*CHANGE OR *ALL

Best Practices:

1. Enforce separation of duties. Avoid having one all-powerful user, all the time.

2. Monitor and report on the use of powerful authorities. Be prepared to justify their use to auditors and managers.

3. Monitor and secure the use of sensitive commands.

Best Practices:

1. Set both *SYSVAL and library values for Default Create Authority to *EXCLUDE.

2. Secure data using resource-level security when possible. Get help from your vendors in protecting application objects.

3. Use a tool to monitor changes to your database.

MEANS USERS CAN:Read, add, change, and delete data

Copy and upload dataChange object characteristics

*SPLCTLCan access any spooledfile in any output queue.

Numbersaren’t required

NO DIGIT REQUIRED

55%

New passwords canmatch the previous one

NO NEW PASSWORD

28%

Users never have tochange their PW

NO DATE EXPIRATION

30%

*USE (3%) - Users with FTP access can read the data

*EXCLUDE (2%) - Users cannot read the data without specific authority

69% HAVE NO EXIT PROGRAMS

28% HAVE EXIT PROGRAMS,BUT ARE MISSINGCRITICAL EXIT POINTS

ONLY 3% HAVE EXIT PROGRAMSWITH ALL EXIT POINTS REGISTERED

73%QAUDJRNACTIVE, NOTMONITORED

12%QAUDJRNNOTACTIVE

15%QAUDJRN

ACTIVE ANDMONITORED

DON’T BECOME ANOTHER STATISTIC.SEE HOW YOUR IBM i MEASURES UP

AT WWW.IBMiAUDIT.COM

Download the full study at www.ibmistudy.com

Provides an idealtarget for hijackers

Even when QAUDJRN is active thevolume of data is so large and thecontents so cryptic, that most ITsta� have trouble monitoringthe logged activity.

Use an automated tool to sort and interpretthe entries. These tools include reports thatreduce compliance costs.

Best Practices:

Since 2003, PowerTech has been auditingIBM i servers with alarming results.Where do the exposures occur andwhat can you do to protect your data?