Month: October 2021

Say it with me: IBM i is NOT immune to malware.

A couple of years ago I wrote a piece called The Real Effects of Malware on IBM i. I thought it laid out a pretty fun yet frighteningly serious story of having an argument with a gentleman on Facebook regarding what’s IBM i fact vs fiction regarding malware and how myself and iTech Solutions colleague Nathan Williams proved it out with some homemade malware and hosed a test system in the process. It really just says everything it needs to.

So a few weeks ago I’m on Facebook again having the same argument with other people.

I’ll not besmirch the original poster’s name in this newsletter article. I just want to highlight his content of the conversation so I can add a few formal rebuttals after I’ve had some additional time to ponder. I’ve cleaned it up a little for the benefit of the readers.

“The IFS just like a UNIX or Windows file system is susceptible to viruses, the i/OS is NOT.”

Okay, this comment is pretty much false information. First, the IFS is called the Integrated File System because it’s exactly that. It literally contains ALL TEN IBM i file systems! Here they all are for good measure:

Integrated File System

Root File System

QOpenSys

QSYS.LIB

IASP QSYS.LIB

QDLS

QOPT

QFileSvr.400

UDFS

NFS

QNTC

It starts with the Root file system of course.

Every other file system is underneath the root directory. Contained in various places within those file systems is the IBM i operating system. If you expose these file systems through SMB file shares via IBM NetServer, then they are 110% susceptible to malware. See the article above.

“No, the IBM OS is NOT susceptible to Malware and PC Viruses…IFS files are of course because they are just PC files anyway, but the architecture of the IBM i and its objects are not going to be attacked by viruses…in my 38 years of IBM midrange including IBM Rochester support, sorry, you are wrong.

Again, there’s a fundamental misunderstanding of what exactly the IFS actually is and what is or isn’t susceptible to malware. And once someone pulls out the years of experience as a reason to accept their argument as gospel then they’ve lost any leg to stand on. It’s a whopping non sequitur. If someone has 50 years in mathematics and …

The post Groundhog Day for Malware first appeared on iTech Solutions Group.

As in so many other areas of testing in general as we get deeper into the process of security testing, we focus on specific areas. Definition, planning, design, execution, evaluation, and maintenance are the natural next steps as security testing is implemented strategically.

First, we need to define what we need to do in order to determine how to do it.

This is also a lifecycle activity. Implementation of practices and proper validation of them are needed throughout the project. This is an area where alignment between development types and testing objectives is crucial. The organization’s testing risks and needs will be unique to the nature of the company, the software development process, and the business risks. Then we align the testing process to the particular lifecycle model accounting differently for sequential, iterative, commercial off the shelf (aka 3rd party) and open source.

Security test planning needs to focus on 2 aspects; verify the designed security defenses are implemented and function, as designed and verifying no vulnerable, are introduced.

We need to identify who should perform the testing. What is the schedule and is the information being used to determine it realistic. What tasks are involved and how long will they take. What environment will this be testing in and does it mimic production closely enough to be accurate. Lastly what authorizations are needed.

Design phase has different ways to be approached. Risk analysis, threat model, or ad hoc origin categorization of risks are all valid basis and depending on the type of project of these may be needed. Attributes needed are prioritized by risk and threat models, traced to requirements, known intended audience, define known security defect profiles, and automation.

The execution needs to closely analyze the environment more than in other areas of testing.

Isolated from other environments and the malware risk is crucial. Completeness includes systems and applications under test, operating systems, networking, middleware, client/server configuration, mobile concerns, databases, access rights, browsers and plug-ins, co-existing applications, data. Planning and approval is also heightened in this area. Compliance and regulatory laws plus the business risk of an improperly identified intrusion attempt can be devastating.

Evaluation reports need to be as detailed as possible and this is an area reporting cannot be overlooked. All of this feeds into the maintenance of these tests. Given all the work involved they need to be reused and to evolve with the …

The post Advanced Security Testing: Processes Part 1 first appeared on iTech Solutions Group.

Below is a table of the major group PTFs for the last few releases. This is what we are installing for our customers on iTech Solutions Quarterly Maintenance program.

 

7.4
7.3
7.2
7.1
6.1
V5R4
Cumul Pack
21238
21245
21084
17192
15063
12094
Tech. Refresh
5
11
9
11
–
–
Grp Hipers
63
140
200
276
210
204
DB Group
16
27
27
43
33
33
DB2 Mirror
13
–
–
–
–
–
Java Group
12
23
33
47
41
34
Print Group
–
–
3
13
31
49
Backup/Recov.
25
51
71
75
61
57
Blade/IXA/IXS
–
–
1
16
30
15
HTTP
14
33
45
53
46
36
TCP/IP
3
7
9
11
17
22
Security
23
64
97
106
60
 33
High Availability
7
15
18
18
 5

Hardware
2
18
35
44
 17

Open Source
–
6
6
6
–

The easiest way to check your levels is to issue the command WRKPTFGRP. They should all have a status of installed, and you should be up to the latest for all the above, based upon your release. Now there are more groups than the ones listed above, but these are the general ones that most people require. We can help you know which group PTFs you should be installing on your machine based upon your licensed programs. Here is a nice tidbit. The Cumulative PTF package number is broken down as YDDD, where Y is the year and DDD is the day it was released. Therefore, if we look at the cumulative package for 7.3, the ID is 18023. We can determine that it was created on the 23rd day of 2018, which is January 23, 2018. Look at your machine and this will give you a quick indication of just how far out of date in PTFs you may be.

HMCs

Fixes are listed below in the order in which they should be installed for each software version. If you are upgrading to a new release, install the base version from recovery media or network image and then apply updates in the order listed. If you already have fixes applied and your current fix level is not in this list, just start with the next higher-numbered fix pack in the list. Be sure to read the release notes for each HMC version, service pack, and PTF for installation instructions and prerequisites.

 …

The post IBM i, FSP, and HMC release levels and PTFs (October 2021) first appeared on iTech Solutions Group.

If you are still using #PDM, it’s time to #modernize with #RDi on the #IBMi!#RDi how to video – Using #RDi to view Data Tables and using Service Entry Points for CLLE programs.youtu.be/oevcK3HZ08M #RDi, helping YOU be more productive on #IBMi!

Subscribe today!

– Steve Ferrell (@stferrells)05:44 – Oct 27, 2021