 |
|
| iSeries 400 Tips: |
|
|
|
ISERIES SECURITY TIPS
Keeping consultants honest
Rich Loeber
03.06.2006
Rating: -3.38- (out of 5)
[TABLE]I am always surprised by the number of programming shops that, in addition to their own resources, use external consultants for programming and systems tasks. The reasons are varied, but consultants present some serious security exposures. In this article, we'll discuss those security issues, and I'll make a few suggestions of things you should consider.
[TABLE] |
|
[IMAGE] |
Companies use consultants for a lot of reasons. Some companies can't afford a full-time technical staff, so they bring in high priced -- but part time -- people to fill their needs. Other companies need consultants who are specialists on the software package that they have implemented. Hiring one of these package experts full time is rarely done and consultants fit the bill. Others like to augment their in-house staff for special development projects.
First of all, most consultants do programming work and the tips I recently published, "Keeping programmers honest " -- part 1 and part 2 -- should apply to them, as well. However, consultants bring a new set of security issues that you need to consider. While the issue of password rotation is covered in the above referenced articles, it is of paramount importance when applied to consultants. Most consultants have their favorite passwords that they use at every shop where they work. Those passwords can become widely known, and you should insist on unique passwords and on password rotation for your installation. The consultant is getting paid very well, and they should agree to this as a term of employment.
First, you should have non-disclosure agreements in place with every consultant that you work with. That agreement must be signed before the consultant starts any work for you. While this is just a piece of paper and won't secure y
To continue reading for free, register below or login
To read more you must become a member of Search400.com
our system for you, it will give you recourse down the road if security issues come up.
Second, you should also come to an agreement with the consultant, in writing, defining who owns the code that is developed while the consultant is working for you. That agreement can get confusing, and you should take some time to negotiate with the consultant. What you are trying to avoid is having the consultant develop new programs and features that they can then turn around and sell to their other clients while you have paid for the development expense. Complications can arise with code that the consultant brings in with him and installs on your system. That code clearly belongs to the consultant and it is being used for your benefit. Provision in the agreement must be made for give and take in this area. If the consultant develops some code that they then wish to use elsewhere, you should be able to work out some remuneration for your company for making the code available to the consultant.
While there are many special requirements for consultants, perhaps the most important one is remote access to your system. In the old days when consultants "dialed in" to connect to your system from a terminal emulator, security was tight. But, with today's networked world, that situation is quite different. Consultants these days connect to your system via the Internet and that brings new concerns. First, your system must be sitting behind a firewall. Then, the easiest solution, which works for a lot of installations, is to implement a Virtual Private Network (VPN). That will allow a secure connection into your house network. Once that connection is made, the consultant can connect to your iSeries to get their work done. I have such arrangements with a number of customers where I do consulting. With some, we use MS VPN while others have implemented Citrix. I'm sure there are other arrangements, as well. Take the time to investigate the best solution for you. Granting direct Internet access to your system is generally not a good idea -- unless you have strict controls implemented at the server exit point level and even then I have my reservations.
This article raises only a few issues involved. If you have more ideas in this area, let me know so I can share them in a future tip. If you have specific questions about this topic, e-mail me at rich@kisco.com. All e-mail messages will be answered.
---------------------------
About the author: Rich Loeber is president of Kisco Information Systems Inc. in Saranac Lake, N.Y. The company is a provider of various security products for the iSeries market.
|
Digg This!
StumbleUpon
Del.icio.us
