Day: October 27, 2021

October 2021 Newsletter

This newsletter includes:

October for me is always the start of the second conference season of the year, with a multitude of conferences happening in October.  Unfortunately, two of my favorite the COMMON Fall Conference and IBM Technical University both are virtual events due to COVID. I am so sick of the pandemic, I want to see all my IBM i friends who I see at conferences.  Sometimes, it’s not necessarily the sessions you learn the most at, it is at the informal discussions and networking where you learn the most.…

Groundhog Day for Malware

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 …

Advanced Security Testing: Processes Part 1

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 …