Teamsite and Internal Hacking

hello. Recently, a client asked which were the Teamsite 5.0 security features to prevent an internal hacker from accessing and taking control over the TS server. To this question i had no reply! but my opinion is that TS doesn't provide any means to avoid the problem. Do you agree? Do you know of some way to solve the problem? Thanks a lot in advance...
ps: can anyone briefly explain me how someone can get control of a machine just by connecting to a port in it? excuse me for my ignorance...

Find more posts tagged with

Comments

Migrateduser

Out of curiosity, what kind of company do you work for where you would have to be concerned about internal hackers?

Dave Smith
davidh.smith@nike.com

<font color='red'>Dave Smith</font>
DavidH.Smith@nike.com

kris1

Obviously, anytime you put a system online, you must ask the question, "Is it secure?" Part of this question resides in making sure the system complies with the security policy your company has in place. If your company does not have a security policy, I seriously recommend that your company looks into writing one.

That said, it is entirely possible to have a Teamsite development environment where all users are not trusted. Teamsite does provide many of the same security features that the UNIX file system provides. It restricts users to the files, directories, workareas for which they have access.

All in all, a system is not easily hackable just because it provides access to a port. The vulnerability lies in any applications running on a given port, which are buggy. Obviously, the more applications you have running that listen on ports, the more *possible* vulnerabilities you *could* have.

If you don't have a good security analyst or system administrator in-house to check over the system, the general rule-of-thumb when setting up a system is to only provide the amount of access you really need to any server. Ideally you only want your Teamsite Server to be a dedicated Teamsite server. If you limit the amount of server applications running on your box, and then correctly configure each of them so that only the people who need to use them can access them, you will be running a fairly secure shop.

For more reading on basic security issues, see:
http://www.securityfocus.com

They have a section called “The Basics” that give a general overview of good security practices. If your client has very high security requirements, you may want to email Interwoven directly with any of your client’s security concerns.

I hope I haven’t stated the obvious here.

Regards,
-Kris Weinhold

ProfessorX

Our concern is not that someone will break Teamsite and the server but for someone to push a hack through a WF/OD out to our production servers

The Professor-

Migrateduser

Isn't that what QA is for? I really think that if you're concerned about your own people pushing **** to production you only have your process to blame. It really has nothing to do with TeamSite or OpenDeploy.

Dave Smith
Sr. Software Engineer
Nike, Inc.
(503) 671-4238
DavidH.Smith@nike.com

skip11

Secure the OS first, IMHO. Next, make TS work with certificate
based authenication. Evauate permissions on files, and tweak as
necessary. Firewalls with rule based auth for ftp/telnet to the
TS Server and your OD rcvr's. Eval conf/roles carefully, and tweak
instantly as users go offline and on to other competitors Smiley Wink

For
critical OD .xml, use "don't do", until you are ready to do it,
and then put it back. We have tweaked some of the services
to run on non-standard ports, so that a casual glance at netstat -na may not reveal where the beast is hiding. Also important,
check the logs carefully on a regular basis or hook them up to
an event based analyzer (Patrol, etc) .

This is how it's done a Swiss Bank. Think in terms of access, who, where and what and lock it down.

Skip

Hazzie

You can have all the security you want but it still comes down to a level of trust. You can configure the systems to prevent everyone but one person doing a specific thing, but whos to say that one person may not come in one morning an do something naughty.

But what you seem to be tlaking about there prof x is what smitty says a QA job. We have 2 steps of QA, one to say that the devlopment has been done is correct, and the second to say that the development fits in with the whole site (it may be correct in its own little world but not in a much bigger one).

Hazzie
TS 5.5.2 on NT.