Re: how to audit the usage of IND$FILE
What ever your security server may be (RACF, CA-ACF2, CA-TSS) audit the successful use of the program IND$FILE so that all executions are logged. This still does not address the issue. Logging the use of IND$FILE (obsolete) does not manage all methods of moving files from the mainframe to PC's. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Was doing an interview audit one time. Subject was control of system libraries and protecting them. Then I shocked the auditor by asking this question. Why are you so intent on protecting the system from me, whose livelihood is dependent on keeping it healthy? What about that hourly operator or tape librarian on the third shift who gets pissed off and trashes the system physically and then skips out the door? Blank stare in response. Daniel McLaughlin Z-Series Systems Programmer Information Communications Technology Crawford Company 4680 N. Royal Atlanta Tucker GA 30084 phone: 770-621-3256 fax: 770-621-3237 email: [EMAIL PROTECTED] web: www.crawfordandcompany.com Best Overall Third-Party Claims Administrator - 2007 Business Insurance Readers Choice Awards Consider the environment before printing this message. This transmission is intended exclusively for the individual or entity to which it is addressed. This communication may contain information that is confidential, proprietary, privileged or otherwise exempt from disclosure. If you are not the named addressee, you are NOT authorized to read, print, retain, copy or disseminate this communication, its attachments or any part of them. If you have received this communication in error, please notify the sender immediately and delete this communication from all computers. This communication does not form any contractual obligation on behalf of the sender, the sender's employer, or the employer's parent company, affiliates or subsidiaries. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
The SMF 30 contains no TSO COMMAND usage information by command name, but any DDNAMEs allocated during the TSO session are recorded in the SMF 30s, so you can often/sometimes recognize what TSO command was used from recognizable unique DDNAMEs in the SMF 30, but without 100% accuracy. And you could map the JOB/JESNR/READTIME triplet to select the TYPE1415 for non-VSAM or TYPE64 for VSAM and identify the DSNAME of that DDNAME, which often is needed to identify which version. Barry -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
This post: Use of SPFEDIT in my own program Bob Rutledge [EMAIL PROTECTED] is a fine example of how to educate the OP instead of doing their work for them. On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak [EMAIL PROTECTED] wrote: After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyong sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. If the auditors are truly coming up with all of these problems, maybe they need to provide the solution for the fee they are paid, too. Is the LISTSERV to share information or do the job for someone else for free? On Fri, 18 Apr 2008 12:27:00 -0500, Tom Schmidt [EMAIL PROTECTED] wrote: We all read post here to both seek share our knowledge, don't we? Or have I completely misunderstood ibm-main's purpose? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
agree 100%. I was especially insulted by a post a few weeks ago where the subject line contained verbiage similar to what our tech support group sees, Emergency, High Priority Application Failure!Like we drop what we're doing to help them out... We should quit being baby sitters for those who won't exhaust their own channels before dealing with this group. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak Sent: Sunday, April 20, 2008 10:29 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyong sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. If the auditors are truly coming up with all of these problems, maybe they need to provide the solution for the fee they are paid, too. Is the LISTSERV to share information or do the job for someone else for free? On Fri, 18 Apr 2008 12:27:00 -0500, Tom Schmidt [EMAIL PROTECTED] wrote: We all read post here to both seek share our knowledge, don't we? Or have I completely misunderstood ibm-main's purpose? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html No virus found in this incoming message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.2/1387 - Release Date: 4/19/2008 11:31 AM No virus found in this outgoing message. Checked by AVG. Version: 7.5.524 / Virus Database: 269.23.2/1387 - Release Date: 4/19/2008 11:31 AM -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
I believe IND$FILE is implemented as a Command Processor (and not a CLIST that CALLs a program); therefore you can create an SMF type 32 record for each use of the command. The SMF Manual discusses enablement in Chapter 4. Barry Barry Merrill Herbert W. Barry Merrill, PhD President-Programmer Merrill Consultants MXG Software 10717 Cromwell Drive Dallas, TX 75229 [EMAIL PROTECTED] http://www.mxg.com admin questions: [EMAIL PROTECTED] technical questions: [EMAIL PROTECTED] tel: 214 351 1966 fax: 214 350 3694 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
In a message dated 4/20/2008 12:05:33 P.M. Central Daylight Time, [EMAIL PROTECTED] writes: (and not a CLIST that CALLs a program); therefore you can create an SMF type 32 record for each use of the command. But aren't they already cut in type 30? I think I stumbled on this while looking at ANAL30DD(slightly modified) after we went to mostly TN3270 and was trying to looking at FTP statistics or something and discovered high use of IND$FILE. Turns out the emulators didn't trust FTP back then. **Need a new ride? Check out the largest site for U.S. used car listings at AOL Autos. (http://autos.aol.com/used?NCID=aolcmp0030002851) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Are you referring to me? If so it doesn't take much. I feel like a hero every time I come home and my cats recognize me. If I can get an assembler program to make it to the linkedit step, I feel like a demigod. -Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Kenneth E Tomiak Sent: 20. huhtikuuta 2008 18:29 To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE If they ask for a program to use the SMF data and someone directs them to a working assembler sample on cbttape.org but it isn't the exact report they want, fixing the program for them makes the fixer an enabler and unpaid-consultant. That goes beyond sharing knowledge. Showing how to fix a few lines of code is sharing, rewriting the program is doing their job for them. Feeling like a hero for providing the answer does not mean they original poster learned anything. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
-snip-- Are you referring to me? If so it doesn't take much. I feel like a hero every time I come home and my cats recognize me. If I can get an assembler program to make it to the linkedit step, I feel like a demigod. -unsnip- You took the time and effort to make the change yourself. In so doing, I'm sure that you learned something. That, to me, demonstrates that you're willing to take some initiative for yourself. It's called self help and we like to see that. We mostly all came up to where we are by the same route. Dogs have owners; cats have staff (I'm a former cat staffer myself. :-) ) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak [EMAIL PROTECTED] wrote: After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. ... Let me present another interpretation of some of those trends (but not, I think, applicable to the original poster of this thread). I'm not knew to system programming - I chased my first CDE chain in about 1970 (on MVT) - but I've been involved in communication- related software for so long that nobody would mistake me for an experienced MVS system programmer any more. I'm woefully out of date regarding anything but very basic MVS concepts. So I sometimes ask really bonehead questions. And if you search the archives you may find that I've asked the same bonehead questions years earlier. Does that mean I'm lazy and am trying to get IBM-Main to do my work? I hope not. It might mean I didn't incorporate the answers into my working knowledge because the topic was too peripheral to my usual work. Or it might be an indication of a failing memory. (And it definitely means I'm to lazy or forgetful to have searched the archives.) So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? ... If this happens too many times (and twice is too many) my paranoia kicks in. Many of the responses to How do I audit IND$FILE? have been That isn't sufficient because I can just picture someone taking notes: I can avoid the auditing if Far fetched? Sure. I said it was my paranoia. But it's something to consider when answering questions like that. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Thanks all your information and sharing. Actually, there are so many ways to transfer files from HOST system but we still have to cope with the internal/external auditor each year. We can't say nothing we can do. Nothing is prefect, but taking notes/remember the coding and picture some photo we can stop it. We can just try our best to protect the shop resources. To be a system programmer, we have responsibility to deal with it. Frankly, we have many communication path, AFTP (protect by program) , FTP (we are not open yet), Ind$file (I create a dummy program on top of it), HDS (rapidxchange disk/share open host, can trace on SMF log volume). * I think we have to stop the way that they can get the files more easily and we are not aware, such as ind$file path. How many pictures you have to take or remember if there are thousand of program coding? regards On 4/21/08, Patrick O'Keefe [EMAIL PROTECTED] wrote: On Sun, 20 Apr 2008 10:29:28 -0500, Kenneth E Tomiak [EMAIL PROTECTED] wrote: After awhile I start to spot a trend from some people posting here that they are not trying to learn how to do something, they have figured out how to get IBM-MAIN to do their job for them. ... Let me present another interpretation of some of those trends (but not, I think, applicable to the original poster of this thread). I'm not knew to system programming - I chased my first CDE chain in about 1970 (on MVT) - but I've been involved in communication- related software for so long that nobody would mistake me for an experienced MVS system programmer any more. I'm woefully out of date regarding anything but very basic MVS concepts. So I sometimes ask really bonehead questions. And if you search the archives you may find that I've asked the same bonehead questions years earlier. Does that mean I'm lazy and am trying to get IBM-Main to do my work? I hope not. It might mean I didn't incorporate the answers into my working knowledge because the topic was too peripheral to my usual work. Or it might be an indication of a failing memory. (And it definitely means I'm to lazy or forgetful to have searched the archives.) So if someone asks how to audit a program 'A' and then later asks how to audit program 'B', did they learn anything the first time? ... If this happens too many times (and twice is too many) my paranoia kicks in. Many of the responses to How do I audit IND$FILE? have been That isn't sufficient because I can just picture someone taking notes: I can avoid the auditing if Far fetched? Sure. I said it was my paranoia. But it's something to consider when answering questions like that. Pat O'Keefe -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Hum, I just had another idea about this sort of thing to bounce around. Don't let the outsiders connect directly to the company LAN. Instead, force them to use something like Microsoft Terminal Services to logon to a multiuser Windows server. Once there, allow them to use a 3270 emulator. That way, the emulator is running on the server, not on the user's desktop. That stops IND$FILE and ftp transfers directly to the user's desktop. I am fairly sure that it stops doing cut'n'paste as well. What it does not stop is ftp to their share on the server, then email the code to themselves. But this is becoming more of a PITA to the user, which does help to discourage them. It all depends on why they are doing it. (cost vs. benefit to them). This same concept can be applied to other systems such as Linux. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Fri, Apr 18, 2008 at 1:47 AM, Kenneth E Tomiak [EMAIL PROTECTED] wrote: Do you strip search them as they leave the building to ensure paper is not in their posession? Ignoring the possibility of print-screen like functions, I can take a pen and a piece of paper and copy a file byte by byte and get a copy. Let me memorize a few lines of code every day and I can write them down when I get to my car. It isn't always about stopping someone, sometimes it is having data to show you know who did access the data and how. Even when they are allowed to access the data. How about stealing an idea from the movie Paycheck. We could wipe the memory of the programmer as soon as the engagement is over. :-) This thread has started to get sillybut it is Friday. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Don Leahy wrote: [...] How about stealing an idea from the movie Paycheck. We could wipe the memory of the programmer as soon as the engagement is over. :-) This thread has started to get sillybut it is Friday. Not necessarily. There is big difference between memorizing few lines of code and downloading all the code repository (many megabytes). In first case some specific idea can be stolen, in second whole application. From business point of view IT IS big difference. However: - we don't know effective method to prevent it. - it is hard to say where's the border between those two cases. -- Radoslaw Skorupka Lodz, Poland -- BRE Bank SA ul. Senatorska 18 00-950 Warszawa www.brebank.pl Sd Rejonowy dla m. st. Warszawy XII Wydzia Gospodarczy Krajowego Rejestru Sdowego, nr rejestru przedsibiorców KRS 025237 NIP: 526-021-50-88 Wedug stanu na dzie 01.01.2008 r. kapita zakadowy BRE Banku SA wynosi 118.642.672 zote i zosta w caoci wpacony. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Oh, another possibility is to use RACF and PADS, but I don't know if that will work to allow ISPF EDIT but disallow basically everything else, such as IND$FILE. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Fri, 18 Apr 2008 00:47:29 -0500, Kenneth E Tomiak ranted: Tommy Tsui has had posts before, IIRC, that indicate a complete lack of knowledge about how an operating system works. I believe he has been asking how to audit just about everything. Ignorant of what SMF can record, how to process SMF data, and how to report on the data. There are lots of manuals that discuss this stuff. I believe that Tommy's past posts have shown an incomplete knowledge but I do NOT believe that they have indicated a complete lack of knowledge about how an operating system works. I believe that you, Kenneth, have been overly harsh in your judgement of Tommy. I agree that there are lots of manuals that discuss this stuff... so many, in fact, that they become a problem for someone who is new to this particular operating system (and apparently new to computing). Tommy's posts have, IIRC, been on-topic to this particular LISTSERV and ought to be welcome here. Whether you chose to respond to them is, as always, up to you. How you respond might be a wee bit more tempered. On Thu, 17 Apr 2008 17:11:13 -0400, J R [EMAIL PROTECTED] responded to Ted's earlier post: It is better to protect the data, rather than the method of copying. That doesn't help if you want the programmer to work on a program but you don't want him to take it with him. ...and that is the bottom line: If you hire a creative programmer to work on your software then you need to carefully assess and perhaps accept the risk that his creativity might include a method of capturing the work product for himself. There are so many ways to skin that cat that auditing any one is pointless. (Besides, someday you might lose the source and his will become the backup.) Perhaps this is more of a contract issue with the creative programmer and not so much a technical contest? We all read post here to both seek share our knowledge, don't we? Or have I completely misunderstood ibm-main's purpose? -- Tom Schmidt -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
how to audit the usage of IND$FILE
Hum, I just had another idea about this sort of thing to bounce around. Don't let the outsiders connect directly to the company LAN. Instead, force them to use something like Microsoft Terminal Services to logon to a multiuser Windows server. Once there, allow them to use a 3270 emulator. That way, the emulator is running on the server, not on the user's desktop. That stops IND$FILE and ftp transfers directly to the user's desktop. I am fairly sure that it stops doing cut'n'paste as well. What it does not stop is ftp to their share on the server, then email the code to themselves. But this is becoming more of a PITA to the user, which does help to discourage them. It all depends on why they are doing it. (cost vs. benefit to them). This same concept can be applied to other systems such as Linux. -- John McKown -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Fri, 18 Apr 2008 12:44:24 -0500, John McKown wrote: Don't let the outsiders connect directly to the company LAN. Instead, force them to use something like Microsoft Terminal Services to logon to a multiuser Windows server. Once there, allow them to use a 3270 emulator. That way, the emulator is running on the server, not on the user's desktop. That stops IND$FILE and ftp transfers directly to the user's desktop. I am fairly sure that it stops doing cut'n'paste as well. What it does not stop is ftp to their share on the server, then email the code to themselves. But this is becoming more of a PITA to the user, which does help to discourage them. It all depends on why they are doing it. (cost vs. benefit to them). This same concept can be applied to other systems such as Linux. I think that a determined programmer would just take screen shots to a file - or just take snapshots with a camera (or continuous video) to capture the data for post-processing by OCR software. (I do something very similar with my genealogy hobby... not terribly difficult or expensive if you are determined.) -- Tom Schmidt (BTW, I know of a company nearby that has a policy prohibiting cellphones with cameras but they have no prohibition regarding cameras without cellphones. You may bring in a digital camera - as long as it isn't part of a cell phone!) -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Tom Schmidt (BTW, I know of a company nearby that has a policy prohibiting cellphones with cameras but they have no prohibition regarding cameras without cellphones. You may bring in a digital camera - as long as it isn't part of a cell phone!) My comapny won't allow cameras without a camera permit which you have to wear around your neck along with our comany badge. Enven then, you need to fill out paper work to describe what you are taking a pictures of and get approval. I think they gave up on PDA and cell phones but you cannot take pictures with any camera enabled device. Even pics of your friends in the parking lot. George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
how to audit the usage of IND$FILE
Hi all, Is there any way that can keep track the usage of IND$FILE, if the user rename the IND$FILE to ther own location and call it with TN3270, how can we check this case. regards -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 15:00:29 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: :Is there any way that can keep track the usage of IND$FILE, if the user :rename the IND$FILE to ther own location and call it with TN3270, how can we :check this case. WHy do you want to do this? What is your business case? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. On 4/17/08, Binyamin Dissen [EMAIL PROTECTED] wrote: On Thu, 17 Apr 2008 15:00:29 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: :Is there any way that can keep track the usage of IND$FILE, if the user :rename the IND$FILE to ther own location and call it with TN3270, how can we :check this case. WHy do you want to do this? What is your business case? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 22:07:11 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: :because our audit want to check the unauthorized user (outsource :programmer) download the source program from our shop. How will this prevent screen scraping? There are other ways to download upload. :On 4/17/08, Binyamin Dissen [EMAIL PROTECTED] wrote: : On Thu, 17 Apr 2008 15:00:29 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: : :Is there any way that can keep track the usage of IND$FILE, if the user : :rename the IND$FILE to ther own location and call it with TN3270, how : can we : :check this case. : WHy do you want to do this? What is your business case? -- Binyamin Dissen [EMAIL PROTECTED] http://www.dissensoftware.com Director, Dissen Software, Bar Grill - Israel Should you use the mailblocks package and expect a response from me, you should preauthorize the dissensoftware.com domain. I very rarely bother responding to challenge/response systems, especially those from irresponsible companies. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Tommy Tsui Sent: Thursday, April 17, 2008 9:07 AM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. I had a similar requirement, but just for internal use. What I did was write a small program which front ended IND$FILE. I composite link'ed it into the load module, so it would still work if somebody copied it to another library. Of course a smart enough person could simply delink my front end. My code is 156 lines of assembler. Also, the front end made the TSO session non-swappable for the duration of the transfer. This was due to some timing problems due to lack of CPU resources. This required that the program be APF authorized and listed in IKJTSOnn as an authorized program. Well, if you forgot to do that last step, the program was smart enough to detect it and bypass the portion that required APF authorization. But all that I did to 'audit' the use was to put out a WTO with ROUTCDE=11 so that it would go on the SYSLOG. I did not write an SMF record (which also requires APF authorization, in general). If you would like the code, please email me off-line at mailto:[EMAIL PROTECTED] . Same for anybody else. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Tommy, Why don't you put AUDIT on the source file and see who touches it for READ? IIRC, IND$FILE might be possible to track if you had a product like MXG or SOFTAUDT or MICS and the access was to the mainframe. Is there a specific way they are invoking IND$FILE? From a PC or from the mainframe? Lizette because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. :Is there any way that can keep track the usage of IND$FILE, if the user :rename the IND$FILE to ther own location and call it with TN3270, how can we :check this case. WHy do you want to do this? What is your business case? -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
As someone else already pointed out, although cumbersome, you can always cutpaste what you see on your 3270 screen. Don't grant people access to data they don't need. Don't grant people access to the system if you don't trust them. Of what value is an audit record that says the data has been read by xyz? Doesn't tell you if only the first few lines have been browsed or if the comlete data has been copied by whatever means. -- Peter Hunkeler CREDIT SUISSE -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Is there any way that can keep track the usage of IND$FILE, if the user rename the IND$FILE to ther own location and call it with TN3270, how can we check this case. Why do you want to audit it? There are many ways to transfer files around besides that method. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
-Original Message- From: IBM Mainframe Discussion List [mailto:[EMAIL PROTECTED] On Behalf Of Ted MacNEIL Sent: Thursday, April 17, 2008 1:54 PM To: IBM-MAIN@BAMA.UA.EDU Subject: Re: how to audit the usage of IND$FILE Is there any way that can keep track the usage of IND$FILE, if the user rename the IND$FILE to ther own location and call it with TN3270, how can we check this case. Why do you want to audit it? There are many ways to transfer files around besides that method. Why? Because some deaf auditor is yelling his head off, most likely. And it is sometimes easier to placate them than to try to educate them. -- John McKown Senior Systems Programmer HealthMarkets Keeping the Promise of Affordable Coverage Administrative Services Group Information Technology The information contained in this e-mail message may be privileged and/or confidential. It is for intended addressee(s) only. If you are not the intended recipient, you are hereby notified that any disclosure, reproduction, distribution or other use of this communication is strictly prohibited and could, in certain circumstances, be a criminal offense. If you have received this e-mail in error, please notify the sender by reply and delete this message without copying or disclosing it. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, Apr 17, 2008 at 10:19 AM, Binyamin Dissen [EMAIL PROTECTED] wrote: On Thu, 17 Apr 2008 22:07:11 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: :because our audit want to check the unauthorized user (outsource :programmer) download the source program from our shop. How will this prevent screen scraping? There are other ways to download upload. Indeed there are. If your company doesn't trust* the outsourced programmer, then perhaps they shouldn't have hired him/her. *Where trust = bound by strict non-disclosure and intellectual property agreements in a contract signed in blood. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 22:07:11 +0800, Tommy Tsui [EMAIL PROTECTED] wrote: because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. On 4/17/08, Binyamin Dissen [EMAIL PROTECTED] wrote: On Thu, 17 Apr 2008 15:00:29 +0800 Tommy Tsui [EMAIL PROTECTED] wrote: :Is there any way that can keep track the usage of IND$FILE, if the user :rename the IND$FILE to ther own location and call it with TN3270, how can we :check this case. WHy do you want to do this? What is your business case? The problem, Tommy, is that IND$FILE is but one of many ways someone could download to a PC. The user could trivially use FTP to do that, if you have an FTP server active, or scp if you have SSH active. Or he could, as you mentioned, copy and rename IND$FILE to something else. Or he could bring in a program from another system. Or he could write a REXX exec to use TCP/IP functions to talk to a program on the PC. Etc. Auditing use of IND$FILE itself is but one way, though perhaps a simple one. But the exposure exists because you gave the user READ access to the data. Having that, there's little you can do to prevent him from copying it somewhere. -- Walt Farrell, CISSP IBM STSM, z/OS Security Design -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 22:07:11 +0800, Tommy Tsui wrote: because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. First, have you protected it with RACF? -- gil -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. What about ftp? Copy Paste? - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
But the exposure exists because you gave the user READ access to the data. This has been discussed before on the RACF-L forum. It is better to protect the data, rather than the method of copying. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
It is better to protect the data, rather than the method of copying. That doesn't help if you want the programmer to work on a program but you don't want him to take it with him. Date: Thu, 17 Apr 2008 20:41:35 + From: [EMAIL PROTECTED] Subject: Re: how to audit the usage of IND$FILE To: IBM-MAIN@BAMA.UA.EDU But the exposure exists because you gave the user READ access to the data. This has been discussed before on the RACF-L forum. It is better to protect the data, rather than the method of copying. - Too busy driving to stop for gas! _ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
That doesn't help if you want the programmer to work on a program but you
don't want him to take it with him.
If he can read it, he can copy it.
And, how protecting IND$FILE will not be enough.
There are many methods, but the crudest one cannot be protected except by
giving the programmer an old 3270 green screen (actually, take the PC away from
him (8-{}).
The crude method is to copy and paste from a TN3270 session into notepad.
-
Too busy driving to stop for gas!
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Is JK Rowling the auditor? Tommy Tsui wrote: because our audit want to check the unauthorized user (outsource programmer) download the source program from our shop. snip -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, 17 Apr 2008 21:30:43 +, Ted MacNEIL wrote:
That doesn't help if you want the programmer to work on a program but you
don't want him to take it with him.
If he can read it, he can copy it.
And, how protecting IND$FILE will not be enough.
There are many methods, but the crudest one cannot be protected except
by giving the programmer an old 3270 green screen (actually, take the PC
away from him (8-{}).
The crude method is to copy and paste from a TN3270 session into notepad.
...and, lest anyone think that Ted's crude method would be too crude to be
useful, it is trivial to create a VB program that steps through the source,
screen-by-screen, while taking snapshots that it copies to notepad (or
straight to a PC file). Grabbing several thousand lines of source wouldn't
take
any more time than it would to page through several thousand lines of source
on the screen. Many TN3270 packages may even provide sample code with
the distribution.
Either you trust your programmer's ethics or you shouldn't provide access to
the treasured source. There is no in between.
--
Tom Schmidt
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Either you trust your programmer's ethics or you shouldn't provide access to the treasured source. There is no in between. Exactly! Everytime you work with an 'outsider' (contractor, outsourcer, consultant, etc.), you have a risk evaluation to do. You either trust them, or you don't. If you don't, then keep it in-house. BUT! Even that is a risk due to disgruntled employees. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Or modularize the design so that no one part is known by everyone. I think that's why Windows works so well. Ted MacNEIL wrote: Either you trust your programmer's ethics or you shouldn't provide access to the treasured source. There is no in between. Exactly! Everytime you work with an 'outsider' (contractor, outsourcer, consultant, etc.), you have a risk evaluation to do. You either trust them, or you don't. If you don't, then keep it in-house. BUT! Even that is a risk due to disgruntled employees. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Or modularize the design so that no one part is known by everyone. I think that's why Windows works so well. LOL! :-) George Fogg -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, Apr 17, 2008 at 5:30 PM, Ted MacNEIL [EMAIL PROTECTED] wrote:
That doesn't help if you want the programmer to work on a program but you
don't want him to take it with him.
If he can read it, he can copy it.
And, how protecting IND$FILE will not be enough.
There are many methods, but the crudest one cannot be protected except by
giving the programmer an old 3270 green screen (actually, take the PC away
from him (8-{}).
Even a green screen is no guarantee if the programmer smuggles a
camera into the office and takes pictures as he scrolls. Tedious
perhaps, but it would work.
Or, he could just write down on paper everything he sees on the screen.
Or, maybe he could just memorize it.
:-)
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
If you have a cell phone camera, it is not that big of an issue - no one
really thinks there is a camera in the building when it is in a cell phone.
Lizette
That doesn't help if you want the programmer to work on a program but you
don't want him to take it with him.
If he can read it, he can copy it.
And, how protecting IND$FILE will not be enough.
There are many methods, but the crudest one cannot be protected except by
giving the programmer an old 3270 green screen (actually, take the PC away
from him (8-{}).
Even a green screen is no guarantee if the programmer smuggles a
camera into the office and takes pictures as he scrolls. Tedious
perhaps, but it would work.
Or, he could just write down on paper everything he sees on the screen.
Or, maybe he could just memorize it.
--
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO
Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
If you have a cell phone camera, it is not that big of an issue - no one really thinks there is a camera in the building when it is in a cell phone. It depends where you work. Th company I recently got downsized from actually had a policy against cell cameras. - Too busy driving to stop for gas! -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Don Leahy wrote: Even a green screen is no guarantee if the programmer smuggles a camera into the office and takes pictures as he scrolls. Tedious perhaps, but it would work. Camera? I have a VBS macro for IBM's PCOMM that scrolls forward and appends each screen's worth of data to a text file. It does this repeatedly until a pre-determined sequence -- signifying EOF -- is detected. I assume a similar macro can be authored with any of the popular emulators. -- Edward E Jaffe Phoenix Software International, Inc 5200 W Century Blvd, Suite 800 Los Angeles, CA 90045 310-338-0400 x318 [EMAIL PROTECTED] http://www.phoenixsoftware.com/ -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
On Thu, Apr 17, 2008 at 11:00 PM, Edward Jaffe [EMAIL PROTECTED] wrote: Don Leahy wrote: Even a green screen is no guarantee if the programmer smuggles a camera into the office and takes pictures as he scrolls. Tedious perhaps, but it would work. Camera? I have a VBS macro for IBM's PCOMM that scrolls forward and appends each screen's worth of data to a text file. It does this repeatedly until a pre-determined sequence -- signifying EOF -- is detected. I assume a similar macro can be authored with any of the popular emulators. -- I meant a real green screen3278 dumb terminal. -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
Re: how to audit the usage of IND$FILE
Do you strip search them as they leave the building to ensure paper is not in their posession? Ignoring the possibility of print-screen like functions, I can take a pen and a piece of paper and copy a file byte by byte and get a copy. Let me memorize a few lines of code every day and I can write them down when I get to my car. It isn't always about stopping someone, sometimes it is having data to show you know who did access the data and how. Even when they are allowed to access the data. Tommy Tsui has had posts before, IIRC, that indicate a complete lack of knowledge about how an operating system works. I believe he has been asking how to audit just about everything. Ignorant of what SMF can record, how to process SMF data, and how to report on the data. There are lots of manuals that discuss this stuff. On Thu, 17 Apr 2008 17:11:13 -0400, J R [EMAIL PROTECTED] wrote: It is better to protect the data, rather than the method of copying. That doesn't help if you want the programmer to work on a program but you don't want him to take it with him. Date: Thu, 17 Apr 2008 20:41:35 + From: [EMAIL PROTECTED] Subject: Re: how to audit the usage of IND$FILE To: IBM-MAIN@BAMA.UA.EDU But the exposure exists because you gave the user READ access to the data. This has been discussed before on the RACF-L forum. It is better to protect the data, rather than the method of copying. - Too busy driving to stop for gas! _ Get in touch in an instant. Get Windows Live Messenger now. http://www.windowslive.com/messenger/overview.html? ocid=TXT_TAGLM_WL_Refresh_getintouch_042008 -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html -- For IBM-MAIN subscribe / signoff / archive access instructions, send email to [EMAIL PROTECTED] with the message: GET IBM-MAIN INFO Search the archives at http://bama.ua.edu/archives/ibm-main.html
