|
CXL ©2008 CXL - VScan
|
| Report for | Demo |
| Company | |
| Business Unit | |
| Location | |
| System | . |
| Report name | c:\tbxnew-works\reports\myrepv.html |
| Report date | 24-Feb-2008 |
| RISKS | RESULTS |
| 1 | SUMMARY | Summary |
|
| Risk |
| The following sections summarise the key areas of this review. |
| 1.1 | PRIVS | Privileges |
|
|
|
| Privileges determine what a user can and cannot do on a system. They determine what processes will work for a user. The most important privileges are the ones which permit the user to run the AUTHORIZE program which then enables them to create accounts with whatever privileges they wish. Such an account will have full access to all the data, software and even the logs recording the activity of the users. |
| Actions |
| With these privileges a user can do anything to your system and cover their tracks. Privileges at or above level 4 fall into this category. |
Number of users with the following privileges: |
| 1.2 | LEVELS | Levels |
|
|
|
| Each of the privileges shown previously has been categorised into 7 levels (0-6). These are in order of the 'damage' they are capable of doing to a system. |
| Actions |
| Users at levels 4 to 6 are considered to be dangerous and the number of such accounts should be strictly limited. We would not expect to see more than about 7 accounts at these levels. |
Number of users at each level: |
| 1.3 | FLAGS | Flags |
|
|
|
| A section of the SYSUAF record details the flags set for each user. Flags, like privileges, limit the facilities available to a user. In general, they tend to prevent users doing certain actions or receiving certain information. |
| Actions |
| Examine the flags set for users and ensure that they are appropriate. |
Number of users with the following flags set: |
| 1.4 | NETLI | Network Logins |
|
|
|
| A NETWORK login is usually made to your system by a user doing a remote file access to it using DECNET. Many DCL commands specify a file or operation which can be performed across DECNET. They are non-interactive. A BATCH login occurs when a user runs a batch job on the system using SUBMIT. A LOCAL login is one that occurs from a terminal that is connected directly to the computer, or is on a Local Area Network and has CONNECT access to it. LOCAL logins are always interactive. A DIALUP login is one that occurs from a terminal connected to a telephone line via a modem. If LOGINOUT sees that the line has the permanent characteristic /DIALUP, it automatically classifies the login as DIALUP. The most secure systems do not have ANY dial-up lines. If your system MUST have some form of dial-up, then VMS provides you with some security tools which counter someone trying to guess a password on your system over a dial-up line, and make dialling-in easier for authorised users. A REMOTE login is made to your system by a remote user typing the command: o $ SET HOST This causes DECNET, to make a connection between them. If the node is reachable, the login sequence will be interactive. |
| Actions |
| Examine the numbers of users in each category and ensure that it is appropriate. Dialup access is frequently given without good reason. |
Number of users with different methods of access: |
| 2 | PWDS | Passwords |
|
| Risk |
| To list the users without passwords you need to issue this DCL instruction: uaf/sel=password=''/display=(user) This will list all users without passwords. |
| 2.1 | PWDLIFE | Password life |
|
|
|
| The default length of time that a password is usable before it has to be changed. EVERY account should have a password life set. A password which is not changed frequently can become widely known. |
| Actions |
| We consider 90 days to be too long for most commercial systems and we would recommend 30 days. Thus any passwords with a life of longer than 60 days should be changed immediately. |
Distribution of password lifetimes. |
| 2.2 | PWDLIFESTD | Password life vs. standards |
|
|
|
| Company standards are not being applied to these users. We recommend that passwords for 'system' users should be set to 30 days or less and for 'ordinary' users, it should be set to 60 days or less. |
| Actions |
| Set password life times to your company standards. |
The following 'system' users have password lifetimes below your company standards. |
| 2.3 | PWDCHANGES | Distribution of password changes |
|
|
|
| Detailed below are the times when the users' passwords were last changed. A password may be set to PRE-EXPIRED and when a user first logs on they will be forced to change it. The system behaves as if the password had reached its expiration date. A password which is not changed frequently can become widely known. |
| Actions |
| Any passwords which have not been changed for a long time either belong to accounts which have a long password expiry set (reduce it) or the account has not been used for a long time (delete it). |
Distribution of password changes. |
| 2.4 | PWDLEN | Password length |
|
|
|
| This is the minimum length required for a user's password. Short passwords are easy to guess. |
| Actions |
| We recommend that passwords are at least 6 characters in length. Any shorter and they become too easy to guess. Much past 8 characters and users will tend to write them down. You may consider it beneficial for 'system' accounts to have passwords of at least 8 characters. |
|
| 2.5 | PWDLENSTD | Password length vs. standards |
|
|
|
| Shown here are users with passwords below your company standards. |
| Actions |
| We recommend that passwords are at least 6 characters in length. Any shorter and they become too easy to guess. Longer than 8 characters and 'ordinary'users will tend to write them down. You may consider it beneficial for 'system' accounts to have passwords of at least 8 characters. |
The following 'system' users have password lifetimes below your company standards. |
| 3 | A/C | Accounts |
|
| Risk |
| This section reviews the users' accounts for specific problems. Problems may be trivial in themselves but when combined with some of the other problems or facilities available to a user, may become very significant. |
| 3.1 | UNA/C | Unused accounts |
|
|
|
| The following accounts have never been used. Unused accounts represent a security risk, particularly if a default password has been assigned to them, pending a change by the legitimate user. Someone else may gain access before the real user if the initial password assigned to the account is a standard format (e.g. user's surname). |
| Actions |
| Determine whether they are new accounts or the users have just never signed on to them. |
Users with unused accounts: |
| 3.2 | NOOWN | No owners |
|
|
|
| A user has not been defined for these accounts. Any actions performed by these accounts may not be able to be traced back to a particular person. |
| Actions |
| Every account should have an owner, someone who is responsible for the actions of whoever signs on with that user-ID. When a problem arises then hopefully the System Manager will be able to question the user. Often, it is not possible to identify a specific terminal or a user-ID and so a name is vital. Some companies also include in this field the telephone extension of the user or their payroll number. These help in both locating a user quickly and identifying a user explicitly. |
The following accounts do not have owners. |
| 4 | SPAC | Specific accounts |
|
| Risk |
| In this section we review in detail the accounts of certain standard 'system' users which appear on all similar systems. These include SYSTEM, FIELD and DEFAULT. Each has a purpose and can also be copied to make other accounts with different names but similar properties. Every hacker knows that these accounts exist and also that some of them are the most powerful on the system. For that reason we have chosen to pay particular attention to them in this section. Any hacker using a terminal can enter a user name of SYSTEM or FIELD and be almost certain that there is an account on the system with that name. They then only have to determine the password which should be a difficult job. However, if these accounts are DISUSERED then even with the correct password he could not enter the system. Full details are given for each account followed by a list of identified problems. If these accounts are not shown in the following pages, they were not found in your SYSUAF file and this is unusual and needs investigating. |
| 4.1 | AC-SYSTEM | SYSTEM Account |
|
|
|
| This is the main Systems Manager account. His own account can be used to re-establish it when needed. Actions carried out by the SYSMAN account could have been performed by every person who knows the password. |
| Actions |
| The system manager should produce his own NAMED account which is used for day-to-day work and reserve this account for special occasions. Most managers can work perfectly well with an account which has SYSPRV and they should disuser this account. |
System SYSTEM MANAGER |
| 4.2 | AC-FIELD | FIELD Account |
|
|
|
| The FIELD account is used by service engineers when they call to do routine maintenance or in an emergency. Since most systems have this account a hacker will try to guess this password and if they succeed, will have full control of your system. If it is DISUSERED then even guessing the password will not permit access. Try to ensure that the password has not been left as FIELD. |
| Actions |
| This account should be left as DISUSERed until the engineer calls. |
Field FIELD |
| 4.3 | AC-DEFAULT | DEFAULT Account |
|
|
|
| This account is often used as a template to create new users from. Instead of having to define all the settings for a user, this account is used as a basis and then copied and modified slightly to create a new user account. The privileges on this account could be increased thus affecting all users subsequently created. |
| Actions |
| This account should be set up to have the minimum privileges available to a normal user (probably just TMPMBX). |
Default GGM DEFAULT |
| 5 | LOGINS | Logins |
|
| Risk |
| This section details how users connect to the system. |
| 5.1 | LINOI | Non-interactive Logins |
|
|
|
| NON-INTERACTIVE Logins require no input from the user during the login, even though LOGINOUT still runs. These logins can be made by typing the SPAWN command or by using DECNET between network nodes. A SUBPROCESS login occurs when a user types the DCL command RUN with any qualifiers other than /DEBUG, /DETACH or /UIC, the DCL command SPAWN, or runs a program which contains either the system routine LIB$SPAWN or $CREPRC. A SUBPROCESS login is always non-interactive. |
| Actions |
| Most normal application users will not need to login non-interactively. Examines the users shown below and decide if they have appropriate access to the system. |
The following users have logged in non-interactively: |
| 5.2 | LIBOT | Both types of login |
|
|
|
| Users generally login either interactively or non-interactively. It is usually only IT staff who use both methods. |
| Actions |
| We would suggest that you review the users shown below and ensure that they are all legitimate IT users. |
The following users have logged in interactively AND non-interactively: |
| 5.3 | LIINT | Interactive logins |
|
|
|
| With INTERACTIVE Logins there is some communication between the program LOGINOUT.EXE and the user. The user provides LOGINOUT with responses to the 'Username' and 'Password' prompts, and, depending on the answers received, LOGINOUT will either grant or deny access to VMS. |
| Actions |
| This is not a high-risk issue and most users will have interactive logins. It is shown here for completeness. |
Of the 63 users, 45 have logged in interactively (ie from a terminal). |
| 5.4 | LLOGINS | Last logins |
|
|
|
| Shown below are when users last logged in by any means. If the system is actively in use then most should have done so in the last 30 days. Those accounts which have not logged in for several months may no longer be needed and should be deleted by first issuing a written warning to the user. Lots of unused accounts may indicate that when users are leaving or moving jobs, no one is informing the IT department or User Administration department. Users who have left the company could still gain unauthorised access. |
| Actions |
| A 'leavers procedure' should be established and anyone leaving the company should have their account deleted IMMEDIATELY. Review any accounts older than 60 days. |
You consider 'old' accounts to be those which have not been used for more |
| 5.5 | LIFAIL | Login failures |
|
|
|
| A high number of login failure attempts indicates that: o you have a forgetful user o a process is trying to connect unsuccessfully o the account is under attack from someone guessing passwords |
| Actions |
| You may care to discuss a sample of these with the users concerned. A very high number of failures may indicate a failing program or batch job. Remember, an account with NO login failures may mean a hacker has succeeded. |
The following users have had login failures: |
| 5.6 | DEFDIR | Default Directories |
|
|
|
| Default directories are the initial storage areas assigned to users. Where people share directories they will also share data and the idea of accountability is destroyed. |
| Actions |
| Ensure that users do not share default directories. |
The following users do no have a default directory set: |
| 5.7 | CLI | CLI |
|
|
|
| The Command Line Interpreter (CLI) is used to enter commands directly to the system. It is a standard product but others can be specified. This is a standard product which is well known and any other CLI may behave in an unpredictable manner. It may even have malicious purposes. |
| Actions |
| The CLI specified in user records should be the standard one supplied with the system. |
42 accounts use the standard CLI called DCL and 21 accounts do not. |
| 5.8 | LGICMD | LGICMD |
|
|
|
| LGICMD is the name of a special file which is executed whenever a user gains access to the system. A malicious user with access to another user's User File Directory (UFD) could copy another LOGIN.COM which contained a time-bomb or Trojan horse. |
| Actions |
| It is best if these files are not called LOGIN or LOGIN.COM. A user without a LGICMD file is in a similar position. |
The following users have bad LGICMDs: |
| 5.9 | NCAPTIVE | Non-Captive |
|
|
|
| An account which is CAPTIVE cannot gain access to the operating system and so cannot use DCL commands directly. Access to the command line could let a user do serious damage to the system. |
| Actions |
| Most users should be CAPTIVE and you ought to investigate those listed below. They may be system accounts or development staff but you should satisfy yourself that each one HAS to be non-CAPTIVE. A CAPTIVE user will normally run an application program and then will be logged out when they are finished. Even when a user is CAPTIVE them may still modify files using an application such as a WP or spreadsheet so make sure you know which applications CAPTIVE users can run. |
Accounts which are not captive: |
| 6 | UICS | UICs |
|
| Risk |
| User Identification Codes (UICs) determine a users rights on the system. |
| 6.1 | SHUICS | Shared UICs |
|
|
|
| These accounts share User Identification Codes (UICs). Users who have a common UIC will have access to each others data and the file protection scheme may not work as intended. |
| Actions |
| Ensure that all users have unique UICs. |
The same UICs are shared by the following users: |
| 6.2 | LOWUICS | Low value UICs |
|
|
|
| These accounts all have low group numbers in their UIC. The UIC is in the format [group,member]. Usually, group numbers of 10 (octal) and less fall into the category of SYSTEM and effectively are the same as users with SYSPRV. These users thus have the potential to completely control the system. Only operators and system managers should have these UICs. |
| Actions |
| Examine users with low UICs and ensure that these are appropriate. |
The following users have system UICs: |
| 7 | SYSSET | System settings |
|
| Risk |
| This section looks at system settings. |
| 7.1 | UNLCPU | Unlimited cpu |
|
|
|
| These users do not have their CPU time restricted. A user performing an unusual task can 'grab' most of the CPU time and make the performance of the system become unusable for everyone else. |
| Actions |
| Every user should have some form of CPU limit set. This is often felt to be difficult to do by System Managers but with careful monitoring of the systems, a reasonable limit can be established. A good starting point might be 10 hours and work down from there. |
No users have unlimited CPU usage. |