IBM i Security Best Practices

IBM i Security
Best Practices
Jeff Uehling
Product Management Director, Security

Today’s Topics
 Security assessment, staying current and physical security
 Staying current on fixes
 Virus and ransomware protection
 System security levels
 System value settings
 Security audit journal
 Resource security, authority collection and RCAC
 Cryptography
 Network security and intrusion detection
2 | IBM i Security Best Practices

Corporate Security Assessment ̶
an IT Budget Requirement

Security Assessment - Network
Perform a complete security assessment of all
network infrastructure
• Intruders are knocking on your door
• Rogue employees have easy access
• Hackers with a hobby
• Intruders with a criminal intent
Your Network IS being Attacked
• Many, many, many times…. Every Day!
• Statistics show you will have holes
in your infrastructure

How many security vulnerabilities are
reported each year?
~40 per day, 14,500 per year and growing!

Perform a periodic security assessment of all infrastructure by:
• Your Corporate Security Team
• IBM X-Force security team (network experts)
• IBM i Security Consultants, Syncsort
This is NOT just an IBM i statement, it’s everything. Perform a
Security Assessment and Penetration testing on:
• Networks
• Laptops/Desktops & Mobile devices and strategy
• Servers
• Applications
Security Assessment
Recommendation
Do you have the necessary skills?
If not, resources do exist to help you!

Physical Security, Networking
• Firewalls, routers, switches, cabling, power
• Prevent configuration changes and sniffing equipment
• Wireless poses a challenge, secure networks are necessary (WPA, WPA2 etc)
Physical Security, Server
• Front panel
• Power, cabling
• Racks/Storage devices
Physical Security, Peripherals
• Tape drives/cartridges, Printers/output, Fax, etc.
• Printed output and backup media
• SAN attached DASD
Physical Security, Mobile Devices
• Mobile Device Management considerations (ownership, “Secure Wipe”, etc)
Physical Security – a Necessity

Staying Current with Technology
Staying current is vitally important for security
IBM i release level
• Older releases cannot be kept current
• New technology changes cannot move backward
Open Source technology
• Changes rapidly and fixes for old versions are not
developed by the open source community
• Includes Java, OpenSSL/SSH, Apache, etc.
Hardware technology
• Like everything, advances with new technology
• Includes routers, switches, firewall, IDS/IPS,
laptops/desktops/mobile devices, servers and more

Staying Current on Fixes ̶
Required Now More than Ever!

Security Vulnerabilities
• Numerous independent researchers
• Lots of open source so easy to review code and look for issues
• Common OS in many products (Linux, Unix, Windows)
• When a vulnerability is found, it’s likely to be everywhere
• Tools are available to exploit technology (look for holes)
• Hacker tools, penetration testing tools, code scanners
• High use technology, like Java, SSL, OpenSSL, is scrutinized
• Vendors are doing more penetration testing thus finding bugs
Many security vulnerabilities are being reported…
Spectre/Meltdown, Heartbleed, Bash/Shellshock, Poodle,
Ghost, Freak, Bar Mitzvah plus many, many more!
What’s happening and why so many?

Security Vulnerabilities – IBM i
• Java (quarterly updates, you need to stay current)
• OpenSSL / SSH
• Web and Application Servers
• Samba
• Networking technology and (infrequently) cryptographic
algorithms
• IBM i OS
IBM i technology with multiple (recent) reported vulnerabilities
Typically, apply the PTF/Fix/Product Update
and the vulnerability is fixed, but not always.
Additional actions may be required.

Security Vulnerabilities –
Not just the OS
• IBM i OS, LIC and Products
• VIOS, IBM i, AIX, Linux partitions
• HMC & Firmware
• 3rd party (vendor) applications
• SAN/Storage, Tape, Printers
• Networking Switches, Firewalls & Routers
• Each and every server, client (including mobile) and HW component
in your enterprise
• Nearly everything includes an OS and/or FW
• Where there is code, a vulnerability is a possibility
Staying Current on Fixes is not just a client and server problem.
The vulnerabilities affect most everything in your enterprise.

Security Fixes
IBM i Security PTF Group
• Not all PTFs/Fixes can be added to the Security PTF Group
because of installation requirements!
• Java updates
• IBM i Access
• Web and Application Servers
• Lotus Products
• etc.
IBM My Notifications (Customer Subscription)
• Security Bulletins
• Technotes
If necessary, contact IBM
for registration instructions

Virus Scanning for IBM i & Ransomware

IFS Security Considerations,
Virus/Ransomware
Virus/Ransomware can affect IBM i objects
• Mapped drives with write access to files
• Virus can be inserted into a file (IBM i as a “carrier”)
• Ransomware can encrypt data on IBM i
• IBM i native files can be deleted
Recommendation
• Virus scan software, on the client device, is required

IFS Security Considerations,
Virus/Ransomware
IBM i File shares (Netserver / Samba)
Define read/write shares ONLY if updates needed from client
Share only what is needed
• When shared, the entire subtree is accessible
Avoid sharing root (‘/’)
• Access to all objects on the system
• If needed - share read-only
• Use QPWFSERVER *AUTL to protect QSYS.LIB and iASP QSYS.LIB
(special checks in Netserver jobs)

System Security Levels
System Value: QSECURITY

Security Levels ̶
Why Run at a High Level?
System security level 50... Good reasons to run there.
The System Integrity support, listed here, is activated:
1. Object Domain Checking
2. Hardware storage protection
3. Parameter validation
Running at security level 40 and 50 is required as these two
security levels support the integrity protection that all other
security levels DO NOT!

Authority Checking and Integrity
Support at Levels 40 & 50
User written programs, running at security level 40 or 50,
MUST use system interfaces (commands and APIs) to gain
access to the objects.
• Authority checking is enforced by the system interface
• Parameter Validation is enforced
• Object Domain checking is enforced
• Object Hardware Storage Protection checking is enforced
Direct access [defined as “direct object access via
address”] by user programs to system objects is not
allowed at Security Levels 40 and 50 due to domain and
hardware storage protection attributes

MI object overview
Object Attributes – Integrity Protection Required
Encapsulated MI Object header, available to LIC
Associated space, byte addressable area for use
by above MI (user and OS) programs.
–Object domain (Most objects are *SYSTEM domain)
–Object owner
–Public authority
–Hardware storage protection setting
–Encapsulated object data
The associated space is used to store operating
system and user data for objects, i.e. *CMD,
*DTAARA, *JOBD, *USRSPC, *USRPRF, etc.
Encapsulated Data Segment, *FILE, *STMF, etc
LIC Only
LIC Only
OS & LIC
Protecting the object is
required as every object
has security parameters
stored within the object

SST/DST Security
Considerations

Securing Service Tools
Controlling access to the Service Tools is necessary for a secure system
• Create as few Service Tools User IDs (SST/DST) as possible
• Create a Service Tool user with the same privileges as QSECOFR
(QSECOFR can become disabled)
• Never use QSECOFR Service Tool USERID (save the password in
a secure location)
DSPSSTUSR (Display Service Tool User CL command)
• Command line interface to “audit” service tool
users and privileges

System Value Settings
NOTE:
Lock down system values
via SST after setting

Altered Program Description
Altered programs are created by modifying a program object
in an unsupported way
Program alterations include:
• Modifying the program to run in system state
• Modifying the program instruction stream
• Modifying the program validation value
Several methods are available to alter a program:
• Using the system service tools to alter program
• Saving the program and modifying it offline

Set these system values on your production machine when NOT
in the maintenance window – control the restore of a program
QALWOBJRST - Consider value *NONE
QFRCCVNRST - Consider value 6 or 7
• 6 – for executables without valid digital signatures, recreate
the instruction stream thus removing any patch
• 7 – for all executables, recreate the instruction stream thus
removing any patch (would also remove the digital signature)
QVFYOBJRST - Consider value 5
• Only allow the restore of programs that are digitally signed
Integrity Related System Values

Controlling System Interfaces
The "RST" interfaces are shipped as PUBLIC(*EXCLUDE).
• Only trusted users should be authorized to use the restore interfaces
• Note: BRMS interfaces are PUBLIC(*USE) but call the system "RST"
interfaces which are PUBLIC(*EXCLUDE)
Verify the list of users authorized to “SAVE” data
• Data escaping your control once it is “off the box”
Protect the use of the system service tools (SST/DST) and Service
related commands (DMPxxx, TRCxxx, etc)
• Dangerous tools/services exist in SST/DST

System Value Settings
(continued)
NOTE:
Lock down system values via SST
after setting

Auditing Related System Values
QAUDCTL - Audit on/off switch
QAUDLVL and QAUDLVL2
QAUDENDACN and QAUDFRCLVL - Use default values
QCRTOBJAUD - Audit newly created objects
NOTE: See chapter 9 and appendix E & F of
the security reference .pdf for audit doc

Auditing Continued
Create the QAUDJRN audit journal
Set QAUDCTL to *OBJAUD, *AUDLVL and *NOQTEMP
Set QAUDLVL to *AUDLVL2
Set system wide auditing values in QAUDLVL2 sysval
• Many QAUDLVL2 values exist, see QAUDLVL2 help text
Audit sensitive objects via CHGOBJAUD
Turn on audit and save the audit journal receivers.
You may need the audit data in the future!

Auditing Continued – Data Objects
Security Audit provides who accesses what object
A combination of security audit and “data object” journaling provides the
complete audit trail
Turn on journaling for *FILE and IFS *STMF sensitive objects to get the
complete audit of changes, including change to data
• CRTJRNRCV JRNRCV(MYLIB/MYRCV0001)
• CRTJRN JRN(MYLIB/MYJRN) JRNRCV(MYLIB/MYRCV0001)
• STRJRNPF FILE(MYLIB/MYFILE) JRN(MYLIB/MYJRN)
IMAGES(*BOTH)
• QSYS/STRJRN OBJ(('/mydir/dir1/stmf1' *INCLUDE))
JRN('/qsys.lib/mylib.lib/myjrn.jrn')

System Value
QAUDCTL
*AUDLVL
*NOQTEMP
*OBJAUD
System Value
QAUDLVL
QAUDLVL2
*SECCFG
*AUTFAIL
*DELETE
…
Object 1
OBJAUD(*NONE)
Audit Journal
Journal Receiver
JRNLIB/AUDRCV
Object 2
OBJAUD(*ALL)
Audit Journal
Journal
QSYS/QAUDJRN
Object 3
OBJAUD(*USRPRF)
User Profile
OBJAUD(*CHANGE)
AUDLVL(*CMD
*CREATE)
Analyze
Audit Journal
DSPJRN
CPYAUDJRNE
Initial setup steps
IBM and XYZ Company Confidential – Security Health Check
IBM i Audit Journal Implementation Overview
One step configuration with CHGSECAUD (Change Security Audit) command
CHGOBJAUD
CHGUSRAUD
1
3
4
5
2
5
6

Syncsort products are available to monitor and
report:
• Control and Monitor object level access
• Monitor & Report on Security Configuration
̶ And direct the information out to a SIEM
Web based dashboard to monitor and report on
IBM i security and audit
Monitoring and Reporting
for Compliance

WRKSYSVAL SYSVAL(QPWD*)
• Set password composition rule system values
• Min/Max length, required characters, etc
• Consider using enhanced password support (QPWDLVL)
• Case sensitive long passwords (128 characters)
Use the ANZDFTPWD command to check for default passwords
Password Composition
System Values
NOTE: Passwords are well protected when on IBM i but can be exposed
when saved and on media. (They are encrypted on the save media but
subject to a brute force attack.)

WRKSYSVAL SYSVAL(*SEC) for the entire list
• QINACTITV - Set to a reasonable number of minutes
• QINACTMSGQ - *ENDJOB/*DSCJOB
• QMAXSIGN - Consider setting to 3
• QMAXSGNACN - Set to disable profile
• QNET* - Network Auditing
• QSSL* - Control system SSL parameters
Additional Security Related
System Values

Resource Security
Resource Security -
Protecting your Objects

Resource Security – Network Layer
Locking the IBM i doors and windows – keeping the intruder out
• Minimal support in the IBM i OS – authentication via passwords
or Kerberos
Syncsort provides the network layer of protection
• Product for network security and audit
• Define rules to block access INTO IBMi
• Define rules to block access once the user has authenticated
• Plus multi-factor authentication
• And monitoring, reporting and SIEM integration

Resource Security – A Layered Approach
= Syncsort capability

IBM i OS provides an excellent base security infrastructure
However, an intruder who gains access and complete privileges (security officer authority) has
full access and must be stopped before entry into the system or stopped before sensitive data
is compromised.
Syncsort provides additional layers of protection
• Products for network security and audit
• Monitoring and report for compliance
• Elevated Authority Manager
• Multifactor Authentication
• Encryption and encryption key management
• SIEM integration
• And much more!
Resource Security – Privilege User Concerns

Resource Security - Protecting your Objects
EDTOBJAUT
Interface to
assign object
level authorities
Authority List
Public AUT
Owner
Private AUT

Keep the number of security officers and security administrators to a minimum
• *ALLOBJ, *SECADM, etc. special authority
• Service tool userIDs
• Syncsort Elevated Authority Manager to minimize the need for powerful profiles
Audit the actions of the Powerful user
• CHGUSRAUD CL command
• *CMD action audit value, *SECURITY, etc.
• Control and Monitor users via Syncsort products
Resource Security – Restrict Powerful Users
Make sure the security officer understands, procedurally,
that audit cannot be turned OFF!

Protecting your objects with resource security is necessary to protect your data
• Run at a security level 50
• Secure your confidential data with *EXCLUDE public authority
• *USE access for Db2 and IFS stream files exposes data
• Objects that are not security sensitive (public objects) should be protected with *USE public
authority. This gives good performance for read operations on the object.
• Add Layers of security via Syncsort products
• Network, audit, MFA, etc.
Resource Security - Protecting your Objects

Row and Column
Access Control
Release 7.2 - RCAC

Additional layer of data security available with Db2 in 7.2
Complementary to table level security (object authority
checking)
Controls access to table data at the ROW, COLUMN or BOTH
Two sets of rules
• Permissions for rows
• Masks for columns
IBM Advanced Data Security for i
• No-charge feature, OS Option 47 required for RCAC
What is RCAC (Row & Column Access Control)?
IBM Advanced Data Security for i
(Boss option 47)
No Charge
http://www.redbooks.ibm.com/redbooks.nsf/Redpiece
Abstracts/redp5110.html?Open

View the data via
“Run SQL Scripts” and
SQL “select”
statement & RUNQRY
• iNav session user is
“UEHLING” & no
group profile
Example: Multi-Row *FILE with
Row Permissions and Column Mask Enabled
Select all rows from table EMPTBL
via
select * from empdta.emptbl
results
Row Permissions and Column Masking activated

NOTE: See chapter 10 of the Security Reference
PDF in the IBM Knowledge Center for Authority
Collection documentation
Release 7.3 Authority
Collection, Managing Object
Level Authority

Customers run many applications on a single partition
• No detailed knowledge of the applications… where is the data?
• Data in Db2 or IFS … but where?
• Once found, how do you lock down security without application breakage?
• What is the “minimum” authority level that can be granted for the end user?
• Many customers have little to no knowledge of what interfaces an application uses so the authority
requirements cannot be determined
• Applications are shipped with excessive public authority (common problem) which leads to security
exposures
The problem: customers don’t change security leaving data exposed
• Example: Think about your personal device, over 1 million files on a single user system
• What if this device was a multi-user system… how would you lock it down?
• No knowledge of the application or data objects so very difficult to secure the objects
Security and Compliance - the Issue
Locking Down Object Level Authority

Build a utility that captures pertinent data associated with an authority check
(included as part of the base OS)
• The collection covers all native IBM i file systems
• Focus on capturing only unique instances of the authority check
• Run-time performance, while the collection is active, will degrade 2-3%
• Storage consideration for long running authority collection
The collection includes key pieces of information… (including)
“What authority is required for this authority check?”
Solution: Authority Collection

Authority Collection – View
SELECT * FROM qsys2.authority_collection where user_name = ‘FRED1’

Authority Collection – View
Scrolling Right within the Authority Collection Data

IBM i Encryption
Protecting your Data

A data encryption key should be well protected or data
is exposed
• Key is used to encrypt data (SSN’s, credit card numbers, etc.)
It is recommended to encrypt the data key with a key
encrypting key (KEK)
• Used to encrypt data encryption keys
A Master Key can then be used to encrypt all KEKs
• A master key is used to encrypt KEKs or Data Encryption Keys
• Top level key, in the clear! If master key is compromised, data
is compromised.
• How do you securely store this master key?
Cryptographic Key Protection - Terminology
1 2 3KEK2
1 2 3
KEK1
Master
Clear Text
NOTE: Encryption
Algorithms are public
knowledge, encryption keys
must be kept
secret and protected

Crypto Key Management
IBM i has GUI & CL interfaces to manage master keys & keystore files
• Included as part of the base OS
Syncsort provides “off partition” key management via tight integration
with the encryption products plus FIPS certified algorithm support
• FIPS certified encryption support
• Off partition encryption key management

Navigate to Security /
Cryptographic Services
Key Management /
Master Keys
Create Master Key(s) via Navigator – IBM support
NOTE: The SAVRST Master Key is not yet set in the example above. A default key is in place to provide minimal protection until you
set your key. This means that the master keys are not “in the clear” on your SAVSYS tape, but any IBM i system can decrypt them

Key Store Capabilities
Key stores protected by master keys
Cryptographic Services APIs used to manage key stores
A single key store file can be encrypted under one master key
One master key can encrypt multiple key store files
KEKs and data keys are
stored in the key store file
Key store is a database file
• normal file access methods disabled
Key store: MYKEYS
Library: KEYLIB
Public authority: *EXCLUDE
Master Key ID: 1
Public
Key
Key
label
Key
Type
Key
Size
KVV
Master
Encrypted
Key
Key
label
Key
Type
Key
Size
KVV
Master
Encrypted
Private Key
Asymmetric Key
Symmetric Key
Key Store

IBM i Encryption Algorithms
IBM i APIs exist to allow applications to encrypt data
• Included with the OS
• Key management integrated with the API design (master keys
and key store files)
Syncsort provides FIPS certified encryption support
• FIPS certified encryption algorithms
• Key Management solution, including “off partition”

Db2 Column Level (field) exit support
• Exit program (Field Procedure) called on insert/update/read of a column
• Similar to “Triggers” but additional support to enable encryption
• Masking of Data is also supported
IBM i Enables Column Level Encryption
• Support to enable the Encrypt/Decrypt data in a Db2 column
• No need to change column attributes like field length or data type
• No application changes required
• Encryption & Key management must be implemented by the Field Procedure software
Solution from Syncsort for Db2 Field Procedures and Key Management
Db2 Field Procedures

IBM i has no OS support for tokenization
Syncsort provides the tokenization solution
• Tokenization provides the ability to replace sensitive data, such as a credit card
number with a token that represents the sensitive data.
• The sensitive data is stored in a token vault, usually of the partition. The token
cannot be used to directly obtain the credit card number.
• Tokenization is a popular technique for PCI (payment card industry) compliance.
Tokenization

IBM i has no OS support for anonymization
Syncsort provides the anonymization solution
Anonymization replaces sensitive data, such as personal information, with data that
maintains the same format but is unrelated to the original data.
• The name Jeff M Uehling would be replaced, for example, by a John A Smith.
Anonymization is often used to create test data or perform Personal Information cleansing
• Scenario: A Db2 file contains personal information. This file needs to be sent to a 3rd party but the
personal information should not be exposed. Anonymization will cleans the data prior to sending.
Anonymization

Encryption of data on tape & disk
(HW technologies are recommended for optimal performance)
• SW Encrypted backup. Provides encryption support for
tape/virtual tape via BRMS and tape management APIs (OS
option 44)
• HW encrypted backup solutions
• SW Encrypted ASP. Provides disk level encryption support for all
data written to disk (OS option 45)
• HW support for Disk level encryption
Encryption key management is required
(master keys and data encryption keys)
Encryption of Data at “Rest”

Enhanced HW Tape Drive and Disk
Support with Encryption
Provide encryption capability in the Tape and Disk
(external storage)
Encryption capabilities are being designed to work
with the key management software called Secure
Key Lifecycle Manager (SKLM)

Encryption Key Manager Software (SKLM),
Required for Tape and Disk HW Solutions
NOTE: Most IBM i customers run SKLM
on stand-alone Linux or Windows
The example on this
slide is for tape
encryption
User
library
Tape
Drive
TCP/IP
IBM i
Data to
save/restore
TCP/IP
Key store
(duplicate)
SKLM Config
(duplicate)
Duplicate Key Server
System
(secondary)
Key store
(duplicate)
SKLM Config
(duplicate)
Primary Key Server
System
(Primary)
IBM i
Data to
save/restore

Conclusion – Resource Security
 Protecting your objects with resource security is
necessary to protect your data.
 Run at a high security level
 Secure your confidential data with a combination of
authority and encryption
 Add Layers of security via Syncsort products
 Network control
 Monitoring & reporting
 Audit and data protection
 Multi-factor authentication
 Elevated authority management
 And more

Network Security
Considerations

Firewall – Building a Secure Network
I
Install and maintain a firewall configuration
A firewall examines all network traffic and blocks
those transmissions that do not meet the specified
security criteria.
Stay Current on
Firewall Technology!

Firewalls:
Intrusion Monitors:
Location:
• Outside your internal
company network
• Makes sense to let
firewall filter what it can.
Network-Based Intrusion Detection
Stay current on Technology!!!
Internet
WWW Mail
Development
system
H/R System
Firewall
Domino
Corporate NetworkIntrusion
Monitor

Network-Based Intrusion
Detection
What intrusion monitors do –
• Perform "Signature Analysis" or "Pattern Matching"
• Patterns: Looking for known "bad patterns" in IP flow
• Signature Analysis: Watch for "Trend Deviations" in network usage
• i.e. When someone successfully connects to a machine, packet
activity is quite different when somebody randomly searching for
open ports.
• React to suspected malicious behavior
• Send e-mail or message to pager
• Shutdown network or routers

Lock the IBM i doors and windows to keep the intruder out
• Minimal support in the IBM i OS, for authentication, via passwords
or Kerberos
Syncsort provides the network layer of protection
• Product for network security and audit
• Define rules to block access INTO IBM i
• Define rules to block access once the user has authenticated
• Plus, multi-factor authentication
• And monitoring, reporting and SIEM integration
Resource Security – Network

Best Practices for network connections to and from your system:
• TLS1.2 is the current “gold” standard
• PCI requirement in June 2018 (TLS 1.1 or TLS 1.2)
• TLS 1.1 & 1.2 support exists in 7.1 and 7.2
• IBM i 6.1 and earlier will not meet PCI requirements in 2018
• What is TLS?
• SSL follow-on protocol to encrypt network application data flow
• A mixture of TLS enabled and non-TLS enabled applications can be run
from the system (secure/unsecure conversations)
• Cipher Suite (encryption) strength needs to stay current.
Secure Socket Layer (SSL) &
Transport Layer Security (TLS)
NOTE: All versions of SSL
and TLS 1.0 have been
deemed unsecure and
should never be used!

Approved TLS Cipher Suite List
*ECDHE_ECDSA_AES_128_GCM_SHA256
*ECDHE_ECDSA_AES_256_GCM_SHA384
*ECDHE_RSA_AES_128_GCM_SHA256
*ECDHE_RSA_AES_256_GCM_SHA384
*RSA_AES_128_GCM_SHA256
*RSA_AES_256_GCM_SHA384
*ECDHE_ECDSA_AES_128_CBC_SHA256
*ECDHE_ECDSA_AES_256_CBC_SHA384
*ECDHE_RSA_AES_128_CBC_SHA256
*ECDHE_RSA_AES_256_CBC_SHA384
*RSA_AES_128_CBC_SHA256
*RSA_AES_128_CBC_SHA
*RSA_AES_256_CBC_SHA256
*RSA_AES_256_CBC_SHA
Transport Layer Security (TLS) Approved Cipher Suite list
See the QSSL*
sysvals
Recent IBM PTFs have
removed all 3DES and RC4
ciphers because of
vulnerabilities

Certificate Types
• ECDSA (Eliptic Curve Digital Signature Algorithm), newer technology
• Key size of 256 or 384
• RSA (Rivest–Shamir–Adleman)
• Key size of 2048 or 4096 bits (4096 is more secure, but may affect performance)
• Note: 1024 bit keys are not secure and not trusted by browsers
Secure Hash Algorithms
A hash algorithm is used when signing the certificate by the Certificate Authority
• SHA 2: 256 or 384 bits are acceptable
• Note: SHA 1 hash is not secure and not trusted by browsers
Certificate Validity Periods
Certificates should be occasionally replaced and acceptable algorithms used
• Standard certificates are valid for 1 year
• Extended validation certs may be good for 2 years
• Some free certificates expire every 90 days
Digital Certificates:
Best Practices

• Perform a security assessment
• Set the security related System Values and lock them
down
• Use the Security Audit Journal
• Protect your sensitive objects with object security and
encryption
• Add layers of security via Syncsort products
• Network Control, Monitoring & Reporting, Audit
and Data protection, MFA, EAM, etc.
Presentation Summary
Learn more at
www.syncsort.com/en/assure
Syncsort can
help with all your
IBM i Security
needs!

• Network security
• Firewalls, IDS/IPS, network segmentation, etc.
• Deploy a Network Security product
• Syncsort product to “lock down” IBM i doors & windows (ODBC, FTP, DRDA, etc)
• Multi-factor authentication (MFA) via Syncsort product
• Secure sensitive data (*FILE, *STMF, etc)
• Object level authority, public(*exclude) where appropriate
• Use Journal to log changes for *FILE and *STMF objects
• RCAC (Row and Column Access Control)
• Deploy file level protection via Syncsort Products
• Encrypt “confidential” data
• Db2 field procedures, tokenization and encryption & “at rest on media”
• Audit sensitive objects and security configuration
• Audit, monitoring & reporting via Syncsort capabilities
• Monitor security configuration, via Syncsort, to ensure settings are accurately set
Resource Security – A Layered Approach
= Syncsort capability

IBM i Security Best Practices

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à IBM i Security Best Practices

Similaire à IBM i Security Best Practices (20)

Plus de Precisely

Plus de Precisely (20)

Dernier

Dernier (20)

IBM i Security Best Practices