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.

[Richard W Hunt]

SRR is actually a port of a Windows program for the similar purpose as the OpenVMS SRR.

I found the posted version of SRR had not less than 6 "open" GOTOs and a bunch of other errors. I used it as a springboard, not gospel.

One of the things I discovered when playing with SRR is that it also wants to compare this run to the previous run to see what changed. I do that another way so didn't try to implement it.

The things that look crazy in SRR, however, make sense if you realize just how many places there are to consider in a government office, where they want reports by weight.

Conceptually, scripting a security check doesn't always find "bugs" in code - it finds the OTHER kind of problem, which is that the user directory or system directory doesn't have adequate protection to prevent twiddlers from twiddling.

In that vein, it is less that you have or do not have an ACL on a file - it is that you KNOW you have an ACL on a file. Since SRR is a government program, it sometimes seems like it does trivial things, and I'm the first to say that even after 20 years, I don't always understand what they do. But the idea is that you look for access paths to files, of which an ACL is one such path.

So play on with your SRR copy, but just be aware that its tests are to Dept. of Defense standards, not necessarily to commercial standards. If you are still interested in some alternative tests, keep posting and I'll keep answering.

[Wim Van den Wyngaert]

Richard,

I stopped my trial to improve the script. It is checking some security holes but there are a million ways to get round it. Also : lots of stuff isn't checked at all.

I think Societe General used it ...
to make some auditor happy.

We passed the sox tests ... mainly in WORD and some stuppid tests. Not by securing the VMS nodes.

Wim

[Richard W Hunt]

I wish that I could stop running SRR, but I work at a government site that actually requires it because of uniformity of reporting across all platforms.

The SRR is a sort of "internal" security check to go along with an "external" check looking for open ports on your network, etc. The only way to look for "real" security holes is to keep up with the VMS patches and such.

I could lecture on the subject (and in fact used to do so for my site), but I'll spare you the pain.

SRR's purpose is to look for opportunities for an internal attack by an authorized user who wants to look at something s/he isn't supposed to be able to see.

SRR won't tell you that you are patched to proper level; it won't tell you whether you have a keylogger on a proxy server, firewall, or router; it won't tell you if you have a man-in-the-middle attack. It is actually a piece of junk as written. But if you are on a government site facing issues with FIPS-140-2, it is one way of keeping the wolves off your back by SHOWING them you have controls in place that meet DISA standards.

The only reason I mentioned it is that it is a security evaluation program that is available for free if you wanted such a thing. I'll back out of the discussion unless I see a specific question.