Fine Grained Password Policies

Purpose of Fine Grained Password Policy (FGPP)

The primary purpose of fine-grained policies is that they can help the administrator apply stricter policies to privileged accounts that deal assets critical to the organizations compared to non-privileged accounts that may not deal with assets critical to the organization.
Since Windows Server 2008, Fine Grained Password Policies (FGPP) have been made it possible that allow u different users in the domain to have different policies.

What are FGPP ?

Fine-grained policies apply only to user objects and global security groups.
Normally the password policy is set for all user at the domain level. This domain level password policy can be viewed by:
1. firing up 'gpedit.msc'
2. select Default Domain Policy [Domain name] -> Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Password Policy
Once you select the above path the Password Policy (applicable to the domain) will appear in the right hand panel of the GPO Window.

Requirements for FGPP

FGPP was introduced in Windows Server 2008 so in order to use this feature the Domain Controller should be upgraded to Windows Server 2008. i.e. the functional level that supports fine grained policies is the Windows Server 2008. The domain function level to the following:
 1 - Start - >Administrative tools -> Active Directory Users and Computers
 2 - Right clik on the domain server in the left hand panel.
 3 - Select prorperties
You will be presented with the properties of the domain including Function level of the domain controller, make sure the Domain Functional Level is Windows Server 2008.

How to create FGPP's

The Fine-grained policies are stored in the Password Settings Container (PSC) under the System container of the domain.
1 - You will need to fire up Active Directory Services Interface (ADSI) on the domain controller of your domain and connect to your domain.
2 - Once in the domain navigate down to CN=System. Once CN=System has expanded look for CN=Password Setting Container (the PSC). We need to create a new Object in the PSC. Right click CN=PSC and select New.
3 - From the list of objects select 'msDS-Password Settings' object (most probably the only option in the menu), then click 'Next'.
4- The next window mainly asks for a value, this is where you provide a name for the policy. For the sake of this tutorial we will name is 'Grained policy', but it can be anything that makes it disctinct and easy to locate.
5 - Select the precedence you want to apply for this particular object. The precedence will be needed if two policies or more apply to the same object. The lower precedence value wins. The value 10 is acceptable.
6 - The object creation process is wizard based and you can fill in the values according to information given below (source blogs.technet.com), The Recommended Values and Format for each of the attributes are provided by the author:

• msDS-PasswordReversibleEncryptionEnabled (self explanatory)
  Recommended Value = False

• msDS-PasswordHistoryLength (Also self explanatory... you can keep up to 1024)
  Recommended Value = 5
  (domain default: 24)

• msDS-PasswordComplexityEnabled (Upper, lower, number, blah blah blah)
  Recommended Value = True

• msDS-MinimumPasswordLength (If only everyone were using pass-phrases instead of passwords)
  Recommended Value = 12
  (domain default(chars): 7)

Now we get into crazy land. MinimumPasswordAge, MaximumPasswordAge, LockoutObservationWindow, and LockoutDuration must all be entered in I8 format.
To quote from TechNet:
    When you use ADSI Edit to create Password Settings objects (PSOs), enter the values of the four time-related PSO attributes (msDS-MaximumPasswordAge, msDS-MinimumPasswordAge, msDS-LockoutObservationWindow, and msDS-LockoutDuration) in d:hh:mm:ss format.
We will use the d:hh:mm:ss format

• msDS-MinimumPasswordAge
  (domain default: 1 day = -864000000000)
  Recommened Value: 01:00:00:00 ( 1 day)
• msDS-MaximumPasswordAge
  (domain default: 42 days = -36288000000000)
  Recommended Value: 45:00:00:00 (45 Days)

 Fill in the following attributes for account lockout settings:

• msDS-LockoutThreshold
  Value = 0
  (domain default: 0 = don‘t lockout accounts after invalid passwords)
  Recommended Value= 15

• msDS-LockoutObservationWindow
  Value = -18000000000 (Nine zeroes)
  (domain default: 6 min = -18000000000)
  Recommended Value=00:00:30:00 (Thirty minutes)

• msDS-LockoutDuration
  Value = -18000000000 (Nine zeroes)
  (domain default: 6 min = -18000000000)
  Recommended Value: 00:02:00:00

7- After entering the value for the last attribute msDS-LockoutDuration we can close the wizard by clicking on 'Finish' and then manually assigning the 'Grained Policy' to a user group by right clicking on the new object and click 'Properties'. Scroll down the 'Attribute Editor' to look for 'msDS-PSOAppliesTo' attribute and click 'Edit'.

8- Click on 'Add Windows Account' and you will be presented with a window similar to the one used to assigned permissions on folders, to select a user or group. Enter the name of the user or group to whom you wish to assign the granual password policy. Once selected the SID of the user or group will appear in the 'value' section of 'msDS-PSOAppliesTo' attribute.
The Fine Grained Password Policy is now in place.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.

Database (SQL Server) Security Best Practices and recommendations

Introduction

This article is an effort to list best practices to secure Database servers. The first half of this article is list of best practices to secure Database servers in general, later we look at specific recommendations for Microsoft SQL Server and Oracle’s MySQL Server. The article does not claim to contain an exhaustive list of methods and best practices to secure a Data base server.

Recommendations:

1-      (Web) Application Servers: If the data base server is being used in conjunction with an application server (which they almost always are.):

a.       Separate the Database and the application (possibly web) servers, setup the database server and (web) application server on two, physically, separate machines.

b.      In case of Web servers use a web application firewall to filter out any SQL injection attacks. Source code of the web application should be reviewed to ensure it does not allow any control character to be sent to the underlying database.

2-      Encrypt the archived files: Some databases provide this functionality to encrypt the data files of the tables that are being used. In general it is highly recommended to encrypt backups and SQL files that may contain instructions to insert data in the tables.

3-      Information Security Policies/Password Policies: Develop, Implement and Maintain information security policies, the policies should include a password control policy requiring a very (very very) strong password.

4-       Backup and Recovery: Have a backup plan and disaster recovery plan.

a.       Take backups regularly on daily, weekly and monthly basis.

b.      In case of Database security the above (point a) is extremely important. A backup can be a life saver if the impact of a malware or hardware corruption was devastating. There are instances where investigating and cleaning up a malware will take more time compared to cleaning the machine and restoring a backup to a point in time before the malware infection.

c.       Create an organization specific Backup and recovery plan. This plan should be tested regularly. If not tested for dependency, regularly, then it is of little practicality.

d.      Encrypt the backups. This re-enforces point 2 above.

e.       The backup of the database server and the recovery procedure to restore any lost database are the core of any Disaster Recovery Plan, at timed and planned intervals recovery drills should be carried out, so that the workforce is versed in recovery procedure and does not panic when a recovery is needed.

5-      Minimal Installations: Make sure the installation is minimal and only required components are installed.

6-      Try to hack yourself before the hackers do. Always make sure you do scans from leading industry tools, Nessus (by tenable.com) is highly recommended. Carry out a credentialed scan if your Database server is running any of the following:

a.       Oracle

b.      SQL Server

c.       Informix

d.      MySQL

e.       PostgreSQL

f.       DB2

7-      Normalization: Architect the database carefully, normalize the data, to make sure the sensitive information is not copied at multiple locations. Sensitive tables should be few in number and clearly known. Such architecture make certifications like PCI-DSS very smooth.

8-      Seperation of Duties: This is something even security savvy dba's role their eyes at. In majority of organizations the dba and network/system administrator are the same person.

9-       Auditing Mechanisms:There should be auditing mechanisms. All logins and their purposes should be known. More than knowing their purposes the privileges granted to them should be known. There should be a minimum number of Administrators/Super users. Also if possible ensure that all DML statements are also logged.

1-  Host Base Firewall: Using a host based firewall make sure that only designated (web) application servers can access the servers. That too only for the relevant port on which a data connection can be set up.

1-  Remove/Rename Defaults: Remove built-in administrator accounts. There should be no sample databases or sample scripts

For MS SQL Server:

 -      Run the Server Configuration Tool after the installation and disable the unnecessary features. This includes disabling the SQL Browser; this approach will reduce the attack surface of the SQL server.

2-      Patched: Make sure the server is patched regularly. A regular Nessus ‘credentialed scan’ always helps.

3-       Antivirus: Ensure the antivirus is always up to date.

4-      Windows Authentication Mode: Where possible use Windows Authentication mode. Windows Authentication mode is more secure compared to SQL server mode (SQL Authentication).

5-      Change all defaults: Besides default passwords it is best to disable default usernames like 'SA'. Also change the default port to some other port. In case a hacker is looking for a specific open port this measure will throw him off, .

6-      Best Practice Analyzer: Microsoft provides Best Practice Analyser for MS SQL Server. The best practice analyzer checks a SQL server installation against a list of best practices and reports which best practices are missing. A DBA should definitely consider using such a tool in conjunction with a vulnerability scanning tool to determine the shortcomings in implementing an SQL Server according to industry best practices.

For MySQL Server:

 MySQL is considered over here because of its popularity with database powered websites and due to the author's own affiliation and experience with the product.

1-      Install using RPM as that goes most of the recommended security settings at its first install.

2-      Keep the latest stable version of the database engine.

3-      Grant access to specific users from specific hosts only. This is in addition to the host based firewall which will permit only the legal user to access the server.

4-      The default user is 'root', in order avoid login attempts to this default user we can change the username of this root/administrator by using the 'RENAME USER' command and changing all instances of the 'root' user with any preferred name in the 'user' table of the mysql database.

5-      As the audit mechanism enable the 'Error Log' and the 'MySQL Log'.

6-      Run MySQL in a ‘chroot’ed environment.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.

Security Identifiers in Microsoft Windows

A Security Identifier is an alphanumeric (mostly numeric) string that is used to represent a security principal. A security principal may be a user, group, computer, or a service.

   Subject(Security Principal)-------Accesses-------->Objects

Each object (File is an example of an object) in Microsoft windows has an associated Access Control List (ACL). When we assign permissions to a security principal over an object, the operating system writes the permissions in the ACL against the security principal's security identifier.

Security Identifiers are part of the ticket granting server in a domain. Inside a domain the SID is always unique (it may not be unique universally)

Composition of an SID

Below are 3 examples of SIDs:

S-1-5-80-2639291829-767035215-3510963033-3734144485-3832470211
S-1-5-80-167798707-2992289499-228648626-2823606389-3827609590
S-1-5-80-1591580229-2093530990-3506924748-295743206-3912932562

SIDs may seem complex and very difficult to understand the composition of the SID you will be able to tell what this SID means. As a Microsoft Windows professional you should have at least a basic understanding of the SID and its composition. The following points explain the position from left to right.


1 - All SID's begin with the letter 'S', so whenever you come across an SID it will begin with an 'S'.

2 - SID's always end with Relative Identifiers (RIDs). RID's are identifiers for security principals. Some popular RIDs are given below:

The last component of the SID is the Relative Identifier. A relative identifier is a number used to uniquely identify a security principal in a scope. The scope maybe a standalone system or a domain. In a stand alone machine the RID is created by the Local Security Authority (LSA) in a domain the RID is created by the Active Directory. The RIDs can be best explained by the following list of popular RIDs in Windows:

User: Administrator, RID:500
User:Guest, RID: 501
User:Domain Admins, RID: 512
User: Built-in Administrators, RID:544

From the above example you will see that the RIDs are not just for users, but for groups as well, in fact they services have RIDs as well the SID: S-1-5-6 tells that the SID holder is a SERVICE. Here 6 is the RID for the SERVICE identifier.

3 - The second component of the SID is the revision level. Currently (as of Windows Server 2008 R2) the revision is 1, so for all the SIDs you come across, the SID will begin with S-1

4 - The next component is the SID issuing authority. This tells you what sort of scope the SID belongs to. If this value is set to 5 then a domain controller is the one who issued this SID. SIDs of all Security Principals which are a part of a domain will begin with S-1-5.

5 - The next component is the sub-authority if it is 32 then it refers to something that is built in to the domain. Like if it is the SID for the built-in administrator of a Domain then the SID will be S-1-5-32-544, where 544 is the RID for the Built-in domain administrator. The Built-in administrator means the administrator user of a domain which is created automatically when a domain is created. The number of sub-authorities is not fixed there can be many sub-authorities in an SID. The sub-authority chain can be explained with the help of the folling diagram of the SID structure.

  

                                           Figure1: Components of a Security Identifier
   
The chain of sub-authorities uniquely identifies the domain/sub-domain in a Enterprise.

Majority of the SIDs that are associated with users begin with S-1-5-21 as the IDs of users within a domain/tree (scope) are not guaranteed to be universally unique.


Uniquness of an SID

This domain identifier may not be globally/universally unique as an indentifier for a domain/sub-domain with the exact same values may be present in another enterprise.
The SIDs do not claim to be unique universally. The S-1-32-544 will be the same for all domains. There will not be a clash as the space in which an SID for built-in administrator is disjoint from the space in which another domain might use the same SID for assigning permissions.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.

Microsoft Windows Security Principals

In windows actions are taken by subjects on objects. The subjects are the ones that need the access and the objects are accessed in different ways (read, write etc.).

There are three types of security principals.
1 - The 'User' and by extension its more complicated extension, the 'group'.
2 - The 'computer'
3 - The 'process', Service to be precise.
Every Security Principal is represented by an SID in a particular scope, where the SID is unique within that particular scope.  The above mentioned Security Principals are explained below:
1- The User
The user is the most basic type of security principal, the most basic entity which can be assigned permissions.
The default user in Windows machine is the Administrator and the Guest. The users in a stand alone machine are managed by the SAM : The local SAM contains all the users on that system.  By default in a Windows domain there are the Domain Administrator the guest account is there but in Windows 2003 and later it is disabled by default.
 The other type of user is the domain user which is created on the domain, it is created and maintained by the Active Directory instead of the local SAM. Once a computer becomes and Active Directory Server the SAM does not cease to exist or cease to function, in fact it remains and maintains the local system users which may be used for recovery operations.
The concept of users is pretty straight forward,  so in this article we will be talking about Groups in MS Windows 2008 and later.
Groups (Security Groups)
According to Microsoft itself a 'user group' is a collection of user accounts that all have the same security rights. User groups are also sometimes referred to as security groups.
There are 6 different types of Security Groups
a- The Local Group
b - Global Group
c - Universal Group
These are explained below according to the permissions they can be assigned and the members they can contains.
a- Local Group
Permissions Scope:  They can be assigned permissions to resources in the same domain they are defined in
Possible Members:  Users, Universal and Global groups from any trusting domain or other domain local groups.
b- Global Group
Permissions Scope: resources in any domain in the forest the domain is part of or any trusting forest.
Possible Members: Users and Global groups from the domain the group was defined in
c- Universal Group
Permissions Scope: Resources in any trusting domain.
Possible Members: Users and Universal and Global Groups from any domain.
A fresh Active Directory installation will contain default groups of all above three types three types. As we mentioned above there are 6 different types of security groups. The remaining three types are user defined versions of the above three i.e.
d - User Defined Local Groups
e - User Defined Global Groups
f - User Defined Universal Groups
In a freshly installed default installation of Active Directory there are no less than 63 groups. A large number of these groups abstract concepts called Special Identities

Special Identities
These groups represent dynamic aspects of a security principal, for example the following dynamic groups (special identities)
 INTERACTIVE:    Contains users that have logged on to a terminal or via Terminal Services
NETWORK:     Contains users that have logged in from over the network. According to the purposes of the INTERACTIVE and NETWORK group a user can be a member of only one group and not the other.

AUTHENTICATED USERS:              This group contains all users that have been authenticated and given remote or terminal sessions on the machine. This is the same as saying all users.
EVERYONE:                                         As the name implies, this group includes all users.
The difference between the Authenticated Users group and the Everyone group is that the Everyone user can contain a user which does not need authentication, viz the Guest user. Do note that since Windows 2003 onwards the Guest user has been disabled, so for all practical purposes the groups Authenticated User and Everyonehave the same component users.
2- Computers
The second security principal type is 'Computers'. Computers are, for all practical purposes, just another user in Active Directory.
3-Services
The last type of security principal is a service. Since Microsoft Windows 2008 services are security principals to the extent that they have their own security identifiers. The security identifier of the service can be used to assign permissions on resources.

About the Author: Saquib Farooq Malik, is a senior Information Security Consultant at ITButler e-Services(www.itbutler.com.au) . Saquib Specializes in Vulnerability Assessment and Penetration Testing, implementations of ISO 27001 in different corporate environments in the Middle East.

He is a CISSP, an ITILv3 Foundation certified professional, ISO 27001 Lead Auditor, Tenable Certified Nessus Auditor and a Lumension Certified Engineer.