CIST 1601 Information Security Fundamentals

1. CIST 1601 Information Security Fundamentals Chapter 14 Security-Related Policies and Procedures Collected and Compiled By JD Willard MCSE, MCSA, Network+, Microsoft IT Academy Administrator Computer Information Systems Technology Albany Technical College

2. Policies You Must Have Data Loss/Theft Policies outline the responsibilities associated with data. A common policy typically begins with wording to the effect “ATC is not responsible for any data loss and/or damages…” and contains phrases stating that data loss can be caused by users, human error, security breaches, and so on. These statements are there to protect the company in the event a user loses data and tries to place blame. Least PrivilegeThe phrase “less is more” is a convenient reminder of the security practice known as the principle of least privilege, where an account is granted no more access rights than the bare minimum needed to perform assigned tasks. When assigning permissions, give users only the permissions they need to do their work and no more. A least privilege policy should exist and be enforced throughout the enterprise. Separation of Duties As a security administrator, you need to make certain that you have as many different levels of permissions and privileges as possible. At a minimum, you should do the following: Separate the System Administrator (SA) account from the regular accounts. Never log in as the SA and use the system to perform routine functions. Use the SA account only to do those operations that require those privileges. Limit the SA account to as small a group as possible. Separate the audit and logging responsibilities from the SA. Segregation of duties and separation of environments is a way to reduce the likelihood of misuse of systems or information (either intentionally or accidentally).

3. Policies You Must Have Time of Day Restrictions Almost every operating system, whether Server or Workstation, allows you to configure when an account can have access to the system. Restrictions can be applied as policies for groups or users in Active Directory (Windows), set locally, or set through a number of add-on packages. You can assign time-of-day restrictions as a means to ensure that employees are using computers only during specified hours. This setting is useful for organizations where users require supervision, security certification requires it, or employees are mainly temporary or shift workers. Mandatory Vacations and Job Rotation A policy of mandatory vacations should be implemented in order to assist in the prevention of fraud. It provides an opportunity to see what they truly do and look for any improper (including illegal) acts, which can be a deterrent in and of itself. Job rotation policies are much more extreme than mandatory vacations. Job rotation is an extension of the separation of duties. Rotating administrative users between roles both improves awareness of the mandates of each role and, while also ensuring that fraudulent activity cannot be sustained.

4. Policies You Should Have –Human Resource Policies Human Resource Policies Human resource policies deal with specifying standards and enforcing behaviors. Hiring policies specify the process of how new personnel are hired, and detail processes for screening employees for new positions including: Background searches Drug-testing requirements Investigating references, college degrees, and certifications Termination policies involve more than simply firing a person. Have a clear process for informing affected departments about voluntary and involuntary terminations. When an employee leaves a company, their computer access should be discontinued immediately. An ethics policy is the written policy governing accepted organizational ethics. Ethics are the personnel or organizational rules about how interactions, relationships, and dealings occur.

5. Policies You Should Have –Human Resource Policies Need to Know policies define that information should be limited to only those individuals who require it, so as to minimize unauthorized access of information. Background investigations should include credit history and criminal-record checks as well as information about work experience and education. A background check should weed out individuals who have misrepresented their background and experiences. These checks must be done with the permission of the prospective employee.

6. Policies You Should Have – Certificate Policies • In the CA environment, the three primary parties are: • The subscriber is the individual attempting to present the certificate that proves authenticity. • The relying party is the person receiving the certificate and is dependent on the certificate as the primary authentication mechanism. • The third partyis responsible for providing assurance to the relying party that the subscriber is genuine. Certificate Policies dictate how an organization uses, manages, and validates certificates. A certificate policy needs to identify: Which certificate authorities (CAs) are acceptable How certificates are used How certificates are issued An organization must also determine whether to use third-party CAs, such as VeriSign, or create its own CA systems.

7. Privilege Decision Making In the case of a highly centralized environment, a single department or person is responsible for making decisions about access that affect the entire organization. In a decentralized environment, decision making is spread throughout the organization. It’s important that personnel receive access only to the information they really need. Establishing a standardized policy or set of policies is important; these policies, and their effects, must be well documented and enforced. Sometimes individuals may need special access to information that they wouldn’t normally be given. Specialized access should be granted only for the period of time during which they need the access. A separate account with these special privileges is usually the best way to manage these types of situations. When finished, the account can be disabled or deleted. If an organization has multiple servers, it may not want administrators to have access to all the servers for administrative purposes. As a rule, you should grant administrative access only to specific systems and possibly grant it only at specific times.

8. Security Controls for Account Management The primary objective of privilege management is to define the entitlement rights of users to access the organization’s information. Privilege management: Determines the security requirements of users Provides access authorization Monitors the resources accessed by users Ensures that the privileges assigned to users in the form of permissions and access rights to information resources corroborate with their job requirements The standard practices for an effective privilege management are use of the “need to know” and “least privilege” principals. The need to know principal is based on the premise that users should be provided access to information that they absolutely require to fulfill their job responsibilities. Access to any additional information is denied to users who work under the least privilege principle.

9. User and Group Role Management A user account holds information about the specific user. It can contain basic information such as name, password, and the level of permission the user has. Internal users have the greatest access to data and the opportunity to either deliberately sabotage it or accidentally delete it. External users have the opportunity to damage data, but they do not have enough permission to accidentally delete data nor do they have access to data as readily as internal users. Roles, groups, location, time of day, and transaction type can all be used to restrict access to resources. Regardless of the criteria used, access administration can be simplified by grouping objects and subjects. Roles are based upon a subject’s job within the company. The roles are only granted those rights and privileges needed to complete job assignments. The Administratoraccount should be used only for the purpose of administering the server. You should create another account to do daily tasks. Although permissions can apply to individual user accounts, they are best administered by using group accounts. Groups are created to incorporate users that need the same access permissions into one common entity. When these users need access to a resource, the permission is granted to the entire group. Using groups simplifies access control administration.

10. Security grouping User and Group Role Management Active Directory Services provides flexibility by allowing two types of groups: security groups and distribution groups. A security group can have predefined access capabilities associated with it. It is used to manage user access to a network or system. In this way, you can develop a comprehensive security model that addresses the accessibility needs of everyone in an organization. Departmental groups access information based on established needs and predefined access. Each department may have different access capabilities. In some cases, different roles within a department have different needs. It comes down to an issue of trust, experience, and need. Distribution groups are assigned to a user list for applications or non-security-related functions. For example, a distribution group can be used by Microsoft Exchange to distribute email. This figure illustrates the group process. In this example, most individuals are placed into one of two departmental groups. The top user in the picture only has access to accounting applications on the ACCTG server, the middle user has access to both, and the bottom user only has access to the APPS server.

11. User and Group Role Management Group Scope Domain Local Groups Groups of the domain local scope are typically used for resource access. When creating a group of this scope, you think of the resource that we're granting access to, rather than the users who might use the resource. You also name the group object after the resource. The members of the group can be user accounts, global groups, and universal groups from any domain trusted by this domain. Global Groups A global group is used to collect user accounts, typically according to the function the members perform in their work. Therefore, their names reference the accounts that are on the group member list. Only accounts in the same domain as the group object can be members of the global group. The reason the group is called "global" is that the group can be assigned access to any resource or made a member of any domain local group in the entire forest. Universal Groups A universal group, as its name implies, has no limitations as to where its members are located, or in what domains it can be granted resource access. Its members can come from any trusted domain, and it can be a member of any group or be granted access to resources in any trusted domain. These qualities make the group type seem ideal: no worrying about whether the source of members is all right or whether the group can be assigned access in another domain. Groups also exist on a local machine level, even if ADS is not in use. You can create local groupson the local computer using the Local Users and Group MMC snap-in and the can be used for assigning permissions on that computer only.

12. Permissions Windows Server 2008 standard NTFS folder permissions

13. Permissions The following key points should help you to understand how permissions work: File permissions always take precedence over folder permissions. If a user can execute a program in a folder, she can do so even if she doesn't have read and execute permissions on the folder in which that program resides. Permissions are cumulative: they "add up" based on the overall permissions a user gets as a result of her total group memberships. If a user belongs to two groups and one has more liberal access, the user will have the more liberal access. Deny permissions always trump Allow permissions. This applies even if a user is added to a group that is denied access to a file or folder that the user was previously allowed to access through his other memberships. Windows Access Control List

14. Auditing Processes and Files Most systems generate security logs and audit files of activity. These files should be periodically reviewed for unusual events. The amount and volume of information these files contain can be overwhelming. Many web servers provide message auditing, as do logon, system, and application servers. This is done to ensure that the system is running ok and isn't being attacked. Audit files and security logs often contain critical system information, including resource sharing, security status, and so on. An attacker may be able to use this information to gather more detailed data about your network. In an access attack, these files can be deleted, modified, and scrambled to prevent system administrators from knowing what happened in the system. A logic bomb could, for example, delete these files when it completes. You should periodically inspect systems to see what software is installed and whether passwords are posted on sticky notes on monitors or keyboards. You should also consider obtaining a vulnerability scanner and running it across your network. A vulnerability scanner is an application that identifies security issues on a network and offers suggestions on how to prevent the issues. One of the best-known vulnerability scanners is Nessus.

15. Security Audits (3:11) Auditing Auditing is the process of tracking users and their actions on the network, and ensuring that corporate security policies are carried out consistently. An audit is used to inspect and test procedures within an organization to verify that those procedures are working and up-to-date. The result of an audit is a report to management. A periodic security audit of user access and rights review can help determine whether privilege-granting processes are appropriate and whether computer usage and escalation processes are in place and working. Auditing user privileges is generally a two-step process that involves enabling auditing within the operating system and then specifying the resources to be audited. Without proper planning and policies, you probably will quickly fill your log files and hard drives with useless or unused information. The more quickly you fill up your log files, the more frequently you need to check the logs; otherwise, important security events may get deleted unnoticed.

16. Auditing Privilege Auditing A privilege audit is used to determine that all groups, users, and other accounts have the appropriate privileges assigned according to the policies of an organization. Privilege audits assist in ensuring that all user accounts, groups, and roles are correctly defined and assigned. Usage Auditing Usage audits assist with ensuring that all computer systems and software are being used appropriately and consistently with organizational policies. A usage audit may entail physically inspecting systems, verifying software configurations, and conducting other activities intended to prove that resources are being used appropriately. Escalation Auditing Escalation audits verify that the organization has the necessary procedures, policies and tools for dealing with emergencies, catastrophes, and other needs for management intervention. This type of auditing can assist in ensuring that an organization's procedures are operating correctly. Disaster recovery plans, business continuity plans, and other plans are tested and verified for accuracy. Administrative Auditing It is important to document the procedures undertaken during the classification of information, and who is involved in this process. You must also document who is involved in investigations, when it is suspected that something is awry, and the procedures they follow—known as due diligence.

17. Auditing Auditing and Log Files The security log of Event Viewer contains all security events based on your auditing configuration. The Event Viewer logs should be backed up on a daily basis. You should enable the Do not overwrite events option for the Security log. This option configures the log so that events are only configured manually by an administrator. The Maximum event log size option configures the maximum size of the event log. When designing an audit policy for your company, the following steps need to be followed: 1. Develop the company’s security policy. 2. Plan the audit strategy. 3. Conduct the audit. 4. Evaluate the audit results. 5. Communicate the results and needed changes. 6. Conduct follow up. To configure the audit, you should enable auditing, configure auditing on the objects, and then review event logs. Reporting to Management An audit should always conclude with a report to management. This report should outline any organizational strengths and weaknesses as they existed at the time of the audit. The audit should also explain any violations of policy, recommendations for improvement, and recommendations for the organization overall.

18. Account Policy Enforcement (5:13) Account Policy Enforcement Many password-generation systems are based on a one-way hashing approach. You can’t take the hash value and reverse it to guess the password. In theory, this makes it harder to guess or decrypt a password. Passwords should be as long and as complicated as possible. Most security experts believe a password of 10 characters is the minimum to be used. Lowercase letters of the alphabet = 26 characters. Uppercase letters of the alphabet = 26 characters. Numeric values 0 through 9 = 10 characters. You’ll then have a total of 62 characters with which to work to construct a password. A 4-character password would be 62 × 62 × 62 × 62, or approximately 14 million password possibilities. A 5 character password would be 62 to the fifth power, or approximately 920 million password possibilities. A 10-character password would be 62 to the tenth power possibilities. Gazillions of password possibilities A password cracker could probably break the 4-digit password in a fraction of a day. The 10-digit password would take considerably longer and much more processing power. Recommendations for setting a good password policy includes making the password length at least eight characters, and require the use of uppercase and lowercase letters, numbers, and special characters.

19. Account Policy Enforcement Passwords must meet complexity requirements determines whether password complexity is enforced. If this setting is enabled, user passwords meet the following requirements: The password is at least six characters long. The password contains characters from at least three of the following five categories: English uppercase characters (A - Z) English lowercase characters (a - z) Base 10 digits (0 - 9) Non-alphanumeric (For example: !, $, #, or %) Unicode characters The password does not contain three or more characters from the user's account name. Password Expiration is an access control practice to expire passwords on a regular basis, protecting against brute-force password-guessing attacks, and to expire accounts not used after a certain period of time.

20. Account Policy Enforcement A Policy Setting Object has attributes for all the settings that can be defined in the Default Domain Policy Group Policy Object. These settings include attributes for the following password settings: Enforce password history The number of unique new passwords a user must use before an old password can be reused. The value can be between 0 and 24; 0 = enforce password history is disabled. For most organizations, set this value to 24 passwords. Maximum password age How many days a password can be used before the user is required to change it. The value of this between 0 and 999; if it is set to 0, passwords never expire. For most organizations, set this value to 42 days. Minimum password age How many days a user must keep new passwords before they can change them. This setting is designed to work with the Enforce password history setting so that users cannot quickly reset their passwords the required number of times and then change back to their old passwords. The value of this setting can be between 0 and 999; if it is set to 0, users can immediately change new passwords. It is recommended that you set this value to 2 days. Minimum password length How short passwords can be. Windows XP and Windows Server 200X support passwords up to 28 characters. You should not use a value of 0. It is recommended that you set this value to 8 characters. Good password policies include making the password length at least eight character; requiring the use of uppercase and lowercase letter, numbers, and special characters; requiring users to change passwords every 60 to 90 days; and setting the server to not allow users to use the same password over and over again. Best practices for failed logon attempts is to lock out after three to five bad logon attempts.

21. Account Policy Enforcement These settings also include attributes for the following account lockout settings: Account lockout duration The Account lockout duration policy setting determines the number of minutes a locked-out account remains locked out before automatically becoming unlocked. The available range is from 1 through 99,999 minutes. A value of 0 specifies that the account will be locked out until an administrator explicitly unlocks it. If Account lockout threshold is set to a number greater than zero, Account lockout duration must be greater than or equal to the value of Reset account lockout counter after. Account lockout threshold The Account lockout threshold policy setting determines the number of failed logon attempts that will cause a user account to be locked out. A locked-out account cannot be used until it is reset by an administrator or until the number of minutes specified by Account lockout duration expires. You can set a value from 1 through 999 failed logon attempts, or you can specify that the account will never be locked out by setting the value to 0. If Account lockout threshold is set to a number greater than zero, Account lockout duration must be greater than or equal to the value of Reset account lockout counter after. Reset account lockout after The Reset account lockout counter after policy setting determines the number of minutes that must elapse from the time a user fails to log on before the failed logon attempt counter is reset to 0 bad logon attempts. If Account lockout threshold is set to a number greater than zero, this reset time must be less than or equal to the value of Account lockout duration. Account expiration is an access control practice to expire accounts not used after a certain period of time. Unused accounts often retain weak passwords used in initial assignment, and may be more susceptible to password-guessing routines.

22. The End