Security check

[Wim Van den Wyngaert]

VMS is one of the most secure OS.

But is there a freeware script available that will report all security holes ? Such as world writeable files & mailboxes, unprotected accounts, unprotected SSH files, etc ?

Wim

[Ian Miller.]

There are commercial products which do security reports
e.g from
http://www.pointsecure.com/
and from
http://www.ljk.com/ljk/ljk_security.html

Where they report all security holes is a matter of opinion.

I'm not aware of any freeware scripts - fee free to write one and release it :-)

[Hoff]

There are various documents to this end including the list in the appendix of the OpenVMS security manual, though I am not aware of a freeware tool that would review security.

The DIGITAL-era (commercial) tool to this end (eons ago) was DECinspect.

From long experience with DECinspect, better security is not without cost. DECinspect could render a system unusable, if you blindly invoked the DECinspect-generated lockdown script. If your environment did not meet the DECinspect profile and expectations, you might find yourself running with heavy privileges enabled to get anything done. Hardly the intended result of a lockdown. (And this "fun" was arising from a local implementation and a local profile definition for DECinspect. I'd be very surprised if a generic profile would work acceptably.)

I do have various tools and DCL procedures I use, and various procedures. The process and the techniques I use do not lend themselves to DCL and to generic DCL or application automation -- some of the more obvious parts do automate, but not the key parts of the process. The key pieces of the security review are inherently site-specific.

I've a blog entry or two on this topic queued for the HL whole-site reboot and reload.

Stephen Hoffman
HoffmanLabs

[Wim Van den Wyngaert]

There was a check_system.com for a famous worm (in the '80).

Wim

[Ian Miller.]

A lot of what is required can be checked by program but also a lot is checking procedures - is there a procedure for dealing with usernames after a user has left - a common hole.

[Martin Hughes]

Inspect still exists, it is owned by Touch Technologies now;

http://www.ttinet.com/products.html

Although this is obviously not freeware.

[Richard W Hunt]

This is by no means an accurate or complete program. It has many bugs in it. But if you had access to DISA.GOV, you might be able to find OPENVMS-SRR-V2R2 as one way to examine system security.

I eventually took its ideas and home-grew something to implement the spirit but not the letter of the DISA checks. The problem was that the guy who wrote the SRR program was clearly not a speaker of VMS as a first language. But I got enough ideas that I can say it was a useful exercise.

You might find a "public" copy if you searched the web for "System Readiness Report" (which is what SRR means) to see what crops up. Unfortunately, I am not allowed to post my version because it contains some government-specific tests. No, it doesn't matter to me - but my government point of contact goes into near apoplexy if I mention "posting code" on any forum. (One of these days that SOB will tick me off enough that it will be worth it to watch him choke...)

[Hoff]

I have the links over to the SRR and related security review materials posted at the web site.

Stephen Hoffman
HoffmanLabs LLC

[Wim Van den Wyngaert]

I found that also. But there were many errors in it : syntax like f$parse with dir instead of directory, functional like unprotected mailboxes.

I'm currently correcting it and will post it over here, if I'm satisfied with the results.

But most stuff reported is very normal over here. E.g. group users have the same access as the owner of a file (thus rwed) and the script reports this as an error.

And what is the use of reporting all files with acl's ?

Wim

[Willem Grooters]

[quote]
E.g. group users have the same access as the owner of a file (thus rwed) and the script reports this as an error.
[/quote]

This might be very valid - it depends on what security base the check-tool is based on. If that disallows G:RWED, it's obvious you get a "Not Ok". Same applies to ACL checking. IMHO, that should be covered as well, but again, if the standard on which the tool is based has no clue about ACL, don't expect it to be checked, or partly, and certainly not what fits your organization.

If you require a security audit, I would first determine what standard is used and what exceptions can be tolerated and why (and in what context), and have that agreed by the auditor. Then run tests with multiple tools that are based on that standard.