We had a security audit and one of the requirement was to raise an alarm whenever any user does a data extract.

1,160 pts.
Tags:
Alert
AS/400
cl 400
DTF
iSeries
Is it possible to raise a alert whenever a user does a data extract using ODBC or DTF.Using CL program or any other way.

Software/Hardware used:
cl400,i750,iseries
ASKED: August 17, 2012  6:15 AM

Answer Wiki

Thanks. We'll let you know when a new response is added.

Hi, I am not sure if it works.

But had you tried Physical Trigger?

Discuss This Question: 5  Replies

 
There was an error processing your information. Please try again later.
Thanks. We'll let you know when a new response is added.
Send me notifications when members answer or reply to this question.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy
  • TomLiotta
    Please define "raise a alert" and "ODBC or DTF". Does ODBC include JDBC? What versions of DTF are possible in your organization?   The requirement sounds irrational. I've worked for many years in that area and I've never heard of such a requirement. The volume of "alerts" could be so high that you'll need to hire multiple people just to respond to them.   I have heard of logging the requests, but not "raise a alert".   You can do it with programming. But if this is a serious external audit requirement, I suggest you obtain a 3rd-party product to do the job. You can start by contacting Help/Systems. They can connect you with PowerTech, Bytware or Safestone, which are all Help/Systems companies. Other 3rd-party providers exist, but you'll get a good introduction through Help/Systems. That might help you know what to look for if you choose some other provider. (IMO, PowerTech would be the choice.)   If this is simply an internal audit, you might want to make sure that your auditor can justify such an extreme request.   Tom   Tom
    125,585 pointsBadges:
    report
  • WoodEngineer
    You may be able to accomplish what you need with an Exit Point program.  IBM has some documentation on exit points in the i5 (there are many).  We found a couple of examples via Google.  IBM also has a good one for FTP.
    6,055 pointsBadges:
    report
  • ToddN2000
    There are other ways of extracting data as well as the ones you mentioned.You could use operations navigator to drag and drop data files to a PC or thumb drive if you have access. (not sure on how that connection works)It's probably best to leave it to the pros like Tom mentioned. Left to resolve this on our own there are always thing we will forget. If security is that much of an issue I'd want to cover all my bases by getting a professionals help. 
    6,360 pointsBadges:
    report
  • TomLiotta
    I've worked with customers that had thousands of audit events per second as a normal state. Database activity from users, from remote servers, from whatever external source, can be extreme.   One obvious requirement for any exit programming can be performance. An exit program that's called concurrently from a thousand or more QZDASOINIT ODBC jobs whenever any transaction comes across the network better not be a performance bottleneck. The methods needed to avoid slowing transactions can be tricky.   Also, a failure of an exit program is tricky. Changes by IBM due to PTFs or upgrades, changes due to local user profile management, changes due to service interruptions from network elements or backup procedures or just about anything imaginable, all of those can cause trouble for exit programs. Sometimes it's just a minor documentation error, though vendors regularly inform IBM that corrections are needed. (At least, I know that PowerTech did.)   For the security aspect, exit programs also must not allow transactions that should be blocked. Most exit programs are able to return an 'Accept/Reject' flag back to the system to tell the system whether or not the transaction should be allowed to continue. There are various circumstances where exit programs can override system security so that a transaction will succeed even if the user normally doesn't have sufficient authority. That means that heavy testing is required under all conceivable connection scenarios from different remote OSes (changes in Windows can change how transactions are presented; and Windows has a lot of changes) using different users. The testing burden can be excessive.   There was a case a few years ago involving an open-source telnet exit program from a highly respected source. I looked it over and saw a logic flaw that involved the interpretation of the parm values passed in from the exit point. The result was that it was fairly easy to make a TN5250E connection to a system with that exit program and pass QSECOFR as the user and not need a password. The exit program would tell the telnet server to accept the connection without worrying about the password. (I privately contacted the author and described the issue. A corrected version was quickly and quietly made available.)   The point is that you really need to understand the implications of how exit programs interact with servers when network security is a concern. Documentation doesn't always teach that aspect. You need to understand fundamental security functions of servers, and the system itself, in order to reason out the implications that aren't obvious. Vendors have accumulated a lot of practical experience from case studies and from detailed discussions with IBM to collect knowledge.   Exit programs also can act differently than programs that run outside of server exit points. Depending on the class of APIs used on a remote system to access your local database, the ODBC server can issue database CLOSE operations that close all open files inside the server process. Your exit program can suddenly find that its files are closed and be unable to open them again. And because the CLOSE was not executed by your exit program, it can't use stuff like the %OPEN() bif to test whether the file is open or not because those only test actions done within the program itself. They don't know when some other program, e.g., the server, issued the CLOSE. The bif will continue to indicate that the file is open.   In addition, all of the usual stuff needs to be attended to. Will you run as OPM in the default activation group? Will you do AG management? Will you use adopted authority? How will you handle errors? Where will messages go?   An OS upgrade or DB2 PTF can change server behavior. You need heavy testing before putting any such changes into production, or you risk shutting server access down until you figure out how to handle the change, maybe until IBM issues a fixing PTF. (Though most IBM PTF issues will be worked through by vendors before you see them.)   In short, you can do it yourself. Be certain about reasons for doing it yourself, particularly if it's a security reason. Expect to spend time and effort beyond the usual for similarly complex functions. ("Expect" means to plan for it, and feel good when the time isn't needed.) Expect to spend extra effort for upgrades/PTFs. Expect that fixes might take months -- PTFs might need creating.   Tom
    125,585 pointsBadges:
    report
  • TomLiotta
    ...had you tried Physical Trigger?   Triggers could be used. But note the original wording:   ...whenever a user does a data extract using ODBC or DTF.   The implication is that a trigger would have to be assigned for every physical file on the system. Every time a new PF was created, a trigger would have to be assigned at the same time. How would you manage that? And would you want to put up with the overhead of invoking a trigger every single time any read access was done against every file on the system? The trigger will always be called whether it's due to remote access or local.   Tom
    125,585 pointsBadges:
    report

Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to:

To follow this tag...

There was an error processing your information. Please try again later.

REGISTER or login:

Forgot Password?
By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

Thanks! We'll email you when relevant content is added and updated.

Following