RE: Client Access Security

> Where is a good place to start looking at Client-level

> security?

> Specifically in the area of ODBC/OLE access.

> 

> We are starting to roll out several client based access

> apps where the

> user's are going to be using ODBC and the like to access

> our production

> data, and I want to try and head off any security issues.

 

 

Ron,

 

On a typical iSeries system, end users are going to have pretty broad
authority to your database.  Our company did an iSeries security study
and found that (on average) *PUBLIC had *CHANGE rights to over 80% of
the data on a typical system.  While most people might think this is
excessive, this particular data point did not even address the number of
users that have *ALL rights to the data because they belong to the group
profile that owns the data.  
(You can download the study and read it for yourself at
http://www.powertech.com/promotions/whitepaper.html).  

You can also see how you stack up against the survey data by running a
PowerLock FlashAudit for your self - you can find this free download at
http://www.powertech.com/SOA.html.

 

The most prominent security issue with traditional iSeries applications
(and even some newer ones) is that users have direct Read, Add, Update,
and Delete rights to the data.  If you can somehow manage to keep your
users completely locked into your own application interfaces, your data
might be safe from their experimentations.  But if your users have the
ability to run FTP and ODBC drivers from their PC's (and most do), then
you're going to have the added challenge of trying to discern when a
trusted application is trying to access data, and when an errant,
malicious, or un-authorized application is trying to get at your data.
This can be more than just a little bit tricky.  

 

We use (and sell) ODBC exit programs to do this sort of low level
transaction inspection.  The exit program can intercept the inbound ODBC
statement and scrutinize it for legitimacy. Known Good transactions are
accepted, and suspect transactions are either suspended, or outright
rejected.  If you want to write your own ODBC exit programs (and few
people who have gone this route would recommend the write-your-own route
to others), you can learn more about them in the Client Access Host
Servers manuals.  The Call Level Interfaces are described there, and
there may even be some sample code.  If you go this route, you should
also look at the TCP/IP manuals for information on how to protect
against FTP and REXEC, as well as the Distributed Database Guide for the
DDM interfaces (I think that's all of the sources, but it's been a while
since I looked them all up).

If you are interested in putting a commercial application in place and
letting somebody else (the vendor) worry about keeping it current with
OS releases, then visit our main page (www.powertech.com
<http://www.powertech.com/> ) and learn more about our exit program
solution called PowerLock NetworkSecurity 

 

 

In any case, you are right to be concerned about your end users
accidentally (or on purpose) hammering your data with direct ODBC
access.  And as with any other application project, the earlier you can
architect a security solution in to the application, the more effective
an less disruptive your solution will be.  

 

If you need more specific information about some of the ODBC exposures,
just ask.

 

jte

 

 

--

John Earl | Chief Technology Officer

The PowerTech Group

19426 68th Ave. S

Seattle, WA 98032

(253) 872-7788 ext. 302

john.earl@xxxxxxxxxxxxx

www.powertech.com 

 

 

 

This email message and any attachments are intended only for the use of
the intended recipients and may contain information that is privileged
and confidential. If you are not the intended recipient, any
dissemination, distribution, or copying is strictly prohibited. If you
received this email message in error, please immediately notify the
sender by replying to this email message, or by telephone, and delete
the message from your email system.

--

 

> -----Original Message-----

> From: midrange-l-

> bounces+john.earl=powertech.com@xxxxxxxxxxxx

> [mailto:midrange-l-

> bounces+john.earl=powertech.com@xxxxxxxxxxxx] On Behalf Of

> ron_adams@xxxxxxxxxxxxxx

> Sent: Thursday, September 30, 2004 12:57 PM

> To: Midrange Systems Technical Discussion

> Subject: Client Access Security

> 

> Where is a good place to start looking at Client-level

> security?

> Specifically in the area of ODBC/OLE access.

> 

> We are starting to roll out several client based access

> apps where the

> user's are going to be using ODBC and the like to access

> our production

> data, and I want to try and head off any security issues.

> 

> Ron Adams

> Information Technology Group

> Crane Valves

> 9200 New Trails Dr. Suite 200

> The Woodlands, TX 77385

> Office: 281-298-5463 x104

> Direct: 281-465-3054

> Cell: 281-216-7721

> 

> --

> This is the Midrange Systems Technical Discussion

> (MIDRANGE-L) mailing list

> To post a message email: MIDRANGE-L@xxxxxxxxxxxx

> To subscribe, unsubscribe, or change list options,

> visit:

> http://lists.midrange.com/mailman/listinfo/midrange-l

> or email: MIDRANGE-L-request@xxxxxxxxxxxx

> Before posting, please take a moment to review the

> archives

> at http://archive.midrange.com/midrange-l.