To be or not to be trusted

[Marty Metras]

We are on a HPUX 11.0 system and just went throught an IT audit.
Even though our security is ok the auditor think we might do better.
Our system is not a trusted system.
I know noting about a trusted system except that it exist.
What are the Pros and Cons of converting to a trusted system?
What do you have to do to make it happen?

Marty
DoerOfThings

[Fabio Ettore]

Hi Marty,

from beginners: go in http://docs.hp.com and search for 'trusted system'
Just a link about how to configure it:

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/B2355-90742/B2355-90742_top.html&con=/hpux/onlinedocs/B2355-90742/00/00/66-con.html&toc=/hpux/onlinedocs/B2355-90742/00/00/66-toc.html&searchterms=system%7ctrusted&queryid=20040129-070802

I am sure that other ITRC forum people will post other useful info about Pros and Cons of Trusted System.

Best regards,
Ettore

[RAC_1]

Pros,

1. Better control on users. You can set pass length, time when a user can login.
2. You can set auditing. etc.
Cons

NIS and trusted do go together. this is the one I know.

How yo convert to trusted system.

/etc/tsconvert.
/etc/tsconvert -r -- to revert back.

[Marco Santerre]

Hi Marty,

I think the Pros probably outweighs the cons especially if you've just been audited when it comes to Trusted Mode.

It will give you password aging, it will remove passwords from the /etc/passwd files, password standards, etc.. you can read all about it in the documentations.

To convert a system, all you need to do is go in SAM, select Auditing and Security, and select any options. Before you can go there, it will tell you you have a Non-Trusted System and that you need to convert it. Just select yes to convert it.

The command line is tsconvert.

[Patrick Wallek]

Marty (DoT),

I would definitely go the trusted route. It is very easy to do. You can do it from the command line with the /usr/lbin/tsconvert command or from SAM in the Security area.

If you do convert there are things to be aware of: 1) ALL passwords will be automatically expired and your users will have to change them the next time they log in. 2) ONLY the first 8 characters of the passwords will be converted. If you have longer passwords, only use the first 8 characters after conversion. 3) You have much more control over when passwords expire, when users can change passwords, etc. 4) The encrypted passwords are no longer stored in /etc/passwd file, they are instead moved to /tcb/files/auth/firstletterofusername/username for each user (for example /tcb/files/auth/r/root for root).

I would definitely go the trusted route. One thing to verify though is that your applications support trusted systems. There is one that we are currently looking that says they do not support trusted systems. I would like to see it be a requirement if we purchase it, but that's just me.

[Pete Randall]

Marty,

I guess the first question I would ask is "will the auditor be impressed if I implement this or not?". Does the auditor have any clue what a trusted system does? Do they know what a C-2 security compliance is? Will they care?

The actual process of conversion is quite simple. You can do it through SAM or from the command line with "tsconvert". The most noticeble change is that the passwords in your /etc/passwd file will be replaced with the /tcb directory structure. Refer to this link for more details on trusted systems:

http://www.docs.hp.com/cgi-bin/fsearch/framedisplay?top=/hpux/onlinedocs/5187-2216/5187-2216_top.html&con=/hpux/onlinedocs/5187-2216/00/00/65-con.html&toc=/hpux/onlinedocs/5187-2216/00/00/65-toc.html&searchterms=Systems%7cSecurity%7cHP-UX&queryid=20040129-071446



Pete

[RAC_1]

As tols by gurus, all the password will expire once you convert to trusted system.

You can avoid this by using command
/usr/lbin/modprpw -V immediately after you convert to trusted system.

[Steven Sim Kok Leong]

Hi,

Most mission-critical servers will opt for trusted system. Benefits include shadowed passwords, password policies and auditing controls etc.

Can't remember much downside in my good old HP-UX days, except perhaps that when you migrate your user accounts over from one machine to another, do not forget to migrate the tcb files in /tcb across as well. ;-)

Hope this helps. Regards.

Steven Sim Kok Leong

[Marty Metras]

Thank for all the responces.
Looks like this is the way to go.
I'll verify that our apps will work.
Do a little reading on what it will do for me and keep the auditers happy and then go for it.
Thanks again.
Marty
DoerOfThings

[doug mielke]

I agree that trusted is better, I disagree a bit in that it's not always easy. It can be a real pain if there are applications on your box that communicate with other systems, and have been installed / configured on a non trusted system(s).

[Steven E. Protter]

An alternative to trusted is shadow passwords. It does not give you the flexibility, but it does put the passwords in a seperate, encrypted file.

I do all new systems trusted, because it is more secure and it give me more flexibility. It is tough sometimes though. With three strikes and out on the root password, operations locks it a couple of times a month.

I would make the system trusted and run Bastille on it http://software.hp.com/portal/swdepot/displayProductInfo.do?productNumber=B6849AA

I would consider IDS/9000 depending on your level of paranoia.

The best practice though is good policy. Stop password sharing, lock after three bad attempts and change the root password at least four times a year.

SEP

[Chris Vail · Accepted solution]

I'd go with the trusted system. In fact, the traditional default security level of most unices is abysmally low.
The decision to trust or not to trust is actually needs driven. But I can't imagine a modern commercial computing enterprise that doesn't need more than the default level of security.
Instead of thinking of a reason to start secure computing, instead try to think of a valid business reason to NOT be secure. There really aren't many. The only justifiable one is that security will break unsecure applications. This is an excuse only for a delay in implementing security, not a reason to be unsecure.
I recommend _Practical Unix & Internet Security_ by Garfinkel and Spafford (O'Reilly) as a good place to start learning how to secure your systems. It'll not only give you good reasons to secure your systems, but the methods for doing so.
Yes, your users will complain. Tell 'em to get over it: this is an age where too much is riding on our systems. Anybody who has ever had a computer virus is familiar with the concept.


Chris

[Marty Metras]

Thanks Chris Good point.
Marty

[Sridhar Bhaskarla]

Marty,

My vote goes to trusted whether a system is critical or not.

The biggest issues HP has is that the encrypted passwords are visible to ordinary users on non-trusted systems. If you have an encrypted password, a hacker can leisurely try decoding it at his/her place.
Trusted systems will put the encrypted passwords out of the reach of the users which is the main advantage.

If you don't want you can turn-off all the restrictions so that users would see no difference.

-Sri