× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.


  • Subject: Re: Why do software companies always want ALLOBJ
  • From: MacWheel99@xxxxxxx
  • Date: Thu, 14 Sep 2000 05:31:11 EDT

This is challenging at several levels.

How does IT get external auditors aware of this topic?  We seem to only use 
external auditors, who are unfamiliar with our computer system, to check 
reports that are spoon fed to them by accounting users who are rather 
oblivious to security issues.

Ideally, *ALLOBJ should be stopped at package buying time, but we typically 
have to fight it in the middle of developers involvement, or try to fix the 
mess after they are no longer with us.  A company typically is in a 
compromise between stuck with a software package that is brain dead on AS/400 
security & various work arounds to improve security.

IBM education does not really address this topic ... they say DO NOT DO THIS 
& DO NOT DO THAT & it is like it is a totally different universe from how the 
software we have purchased is structured ... there needs to be AS/400 trade 
press articles on how to fix typical packages major security flaws

Is it a reasonable expectation that capitalism as currently structured is 
capable of learning from this topic ... there is a constant turn over of 
decision makers who do not learn from the experiences of the prior decision 
makers.

To a certain extent the Y2K-trained news media is blasting stories about 
computer security disasters into sufficient plain sight that some managers 
are asking questions that should have been asked a lot earlier, and some end 
users are gaining some sensitivity to the subject.

Perhaps a bug could go in the ears of the news media to let them know about 
vendors that have foisted software that has an open door policy on future 
security disasters, for companies in which it did not occur to aquisition 
management to ask that competent security be included in the purchased 
packages - we be careful not to name names in a libelous fashion.  Then 
instead of media just saying that this or that site had denial of service 
attacks, it can be asking why the site had hardware & software that permitted 
such attacks, and how many other sites are wide open to the same, and how few 
companies indulge in computer security audits.

I trust IBM to manage ECS so that we have a level of security there that is 
comparable to that of OS/400 security itself.

But when BPs are heavily populated with folks who seem to be oblivious to 
security concerns, how can we trust that THEY won't be hacked & then hacker 
abuse their *ALLOBJ & *SECADM access to all their clients.

When someone tries to dial into our system, the modem makes distinctive 
noises & I am supposed to know if anyone is currently authorized to dial in.

Unfortunately we also get a fair number of wrong numbers ... we used to have 
the kind of modem in which there was a manual dial feature with a hand set, 
and when I got nervous about security against unauthorized dial in, I could 
leave the handset off the hook, or pick it up when it rang & ask "who needs 
into our computer?" which broke the connection, but now I know if the line is 
varied off they are not supposed to be able to get in.

Several people know how to vary on line so BP this or that can dial in, so I 
need to periodically check that the line is in fact varied off for all but 
IBM.

I would like to have some deal where the process of someone signing on via 
our ECS line does more than send a message to QSYSOPR, like perhaps message 
to all MIS dept staff ... "Someone at _______ company just signed on using 
______ ______ (work station-id & user-id) ... hopefully we know what they 
supposed to be doing."

Our phone system is in the midst of upgrades.  Some day I would like to have 
one that tracks, in real time, where external phone calls are coming from, 
dialing into PCs from which they can connect to our internal networks, then 
compare caller-id of dial in with home phone # of normal user of that PC & 
give the normal user the option of automatically blocking any calls to their 
PC not on some preset list.  I recognize that sales folks on the road with 
lap tops connecting to the home office, are in a different boat than users 
who invariably call from the same number.

We have some menu options (could stant improvement by me I know) to vary on / 
off communication line so that it belongs to:
IBM ECS (normal default ... if we get a hardware problem, I want the CE 
called ASAP)
A Hardware BP; or
A Software BP.

Normally they call in asking for us to vary on the line for a particular BP 
for some specified purpose ... NOT

From their perspective, some co-worker called the BP with a help desk type 
problem, and some staffer at the BP tried to dial into our system but the 
line is varied off unless the MIS department has been told to expect an 
incoming call from a specific BP, and the staffer at the BP has no idea what 
normal procedures are, so they call our receptionist asking to get into our 
system, and we have deliberately not provided our receiptionst with the 
technical ability to respond to calls from people who fail to adequately 
identify why they need to get onto our system (one of my small victories).

It appears to me that it is standard practice for BP & Hacker to use 
identical techinque of calling random person at our site & saying they need 
onto our system, with no explanation why they need on.  I always assume such 
calls are from a hacker until I get satisfactory explanation otherwise, and 
am very polite but still not going to extend access to a person who is 
unknown to me.

What happens is, we get a call from some person at BP or developer who needs 
to "get on our system" & I am not talking to that person directly but to some 
co-worker who took the call & I do not know if this person who needs on our 
system is a person at an outside company or a new employee recently hired, so 
I tell the co-worker to "find out" if the person who needs on the system is a 
new hire in what department & what kind of stuff they will need to be getting 
into, because we set up our workers with right security for "inventory clerk" 
or "shipping department" or something like that & I need to know which 
category the person is in before I set up their security, and also get me the 
name of their supervisor so I can call & confirm that this access to our 
system is in fact authorized, because sometimes there are misconceptions who 
is supposed to be doing what ... 

95% of the calls "someone needs on our system" is that kind ... new hire 
being trained & the trainer has no memory of the procedure for getting the 
new hire assigned access to our system, and it never occurs to anyone to ask 
about this until 2 seconds before the training session for someone that the 
company collectively knew would be hired a week ago, so now it is an 
emergency to get them setup to access our system, and I want to remind the 
supervisor about special very limited access sign-ons we have for training 
purposes & also what the procedure is for getting a new person up & running 
on our system, which they always forget until the next new person.

Al Macintyre  ©¿©

+---
| This is the Midrange System Mailing List!
| To submit a new message, send your mail to MIDRANGE-L@midrange.com.
| To subscribe to this list send email to MIDRANGE-L-SUB@midrange.com.
| To unsubscribe from this list send email to MIDRANGE-L-UNSUB@midrange.com.
| Questions should be directed to the list owner/operator: david@midrange.com
+---

As an Amazon Associate we earn from qualifying purchases.

This thread ...


Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.