Security for Small and Medium Enterprises, Part 1
Those trained and experienced in the Information Security area know all about IDS systems, biometric security, Disaster Recovery systems, and all the other expensive technologies available to large enterprises with their large budgets.
Quite often overlooked in this area however, are the vast number of small and medium enterprises. Statistics vary per region, but some countries rely on these so-called SME’s for more than half of their national GDP. This makes SME’s an essential part of any economy. The classification for a business to qualify to be listed as an SME also varies per region. In the United States a maximum of 500 employees is stated, while in New Zealand this is set at only 19 employees. The importance of IT security within organisations of all sizes, including these SME’s, is clear. A study in 2012 by Hiscox, a small business insurer, found that 1 in 10 SME’s have suffered from a data hack, showing that security in this area needs some serious attention.
Some problems small businesses face are the low IT budgets available, and partially because of this, the lack of IT Security expertise. IT Security is a specialized field and an all-round Systems Administrator or staff at a general IT service provider cannot keep up with all security developments on top of everything else.
In this series of articles, we delve into some relatively simple security solutions that achieve the greatest security impact to a business for the lowest financial cost. I will focus mostly on Microsoft Windows Server 2008, because this OS has a market share of about 80 to 90% within the SME market. The general principles behind the security items that will be covered are mostly applicable to any other OS as well.
In this first part of the series we will discuss the key security asset of any network and the horror of many security professionals: Passwords.
A combination of the incredible confidence of users in the strength of their passwords and the ease with which attackers could acquire these passwords, would nearly make them a security threat instead of a security control. With the right policies enforced however, a lot of problems can be avoided.
How strong does a password need to be? If a password is too complex or if a user is forced to change a password too often, users will start to write down their passwords on the famous yellow post-its which they stick on desks, screens or under their keyboard. This outcome is almost as bad as allowing users to use old and simple passwords.
Finding the balance between security and usability is never easy. Many organisations such as the NSA and NIST have written security guidelines in which they included recommendations for strong passwords. These recommendations vary a lot and do not take into account the risks to a particular business type. A bank for instance can be expected to use stronger passwords than a local bowling club, just because the risks to their network are higher. This increased risk will justify the increased time (and therefore money) spent on password policies by IT staff and users.
Microsoft has implemented password policies by default on a newly installed domain controller. This is done by Group Policy Objects (GPO) that applies to the entire domain. Explaining how to use a GPO within a Windows Server is out of the scope of this article, but let’s look at the available settings and their values.
Maximum password age
This setting enforces the password expiry policy. If this is set too short, users will write down their passwords to remember them, as mentioned before. Another side-effect of frequent password changes is the additional support cost of password resets for users who forget their new password.
If this value is set too long, an attacker will have a longer time to attempt to crack or intercept a password before it expires. If the password has been compromised or a co-worker has acquired a colleagues’ password, they can also use the account for a longer period without being easily noticed.
Suppose a user has local administrative privileges on their PC which was installed 6 months earlier by IT Support with administrative access to the network. An attack can easily be run against the password hashes collected on the PC. This way the administrative account can be cracked and until the password expires, the user will have access to the entire company network. When the password expires, this will stop unless the user has made some permanent changes to the network. These potential changes, such as an added administrator account, will hopefully be detected.
Much debate exists about password expiry policies and the required time periods. Microsoft advises a period of 42 days and the NSA advises 30 to 90 days. Within a SME, it probably will depend on the type of business and users. A period of 90 days will be a safe bet in any network that does not require high security levels.
Enforce password history
This setting relates to a user’s previous passwords. With this setting disabled (set to 0), a user is allowed to change a password back to the same value when prompted to change the password. This would make a password expiry useless. A history of more than 12 passwords is recommended to prevent users from working with predictable month-values or simple, incrementing numbers.
Minimum password age
This essential setting helps to enforce the Password History and Maximum Password Age settings. Without this set to at least a few days, a user could quickly run through a list of temporary passwords to bypass the password history list when their current password expires. This would allow the user to reuse the old, expired password again within minutes.
Minimum password length
This probably is the most used and understood password setting. The length of the password determines the amount of effort it takes to guess or crack it. As with any password setting, if the minimum password length is too long, users will start to write it down or ring IT Support when they forget it. If it is too short, passwords will be easy to guess or crack. Microsoft and many other organisations recommend this value to be set to 8 characters.
Passwords must meet complexity requirements
This setting enforces password complexity rules. If it is enabled, user passwords must meet the following requirements:
- The password is at least six characters long (or longer if set at Minimum Password Length).
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.
Some users can find these rules quite difficult to understand, but they are very important. Without these rules, user “andrewk” can use password “andrewk” for instance, which is obviously a security risk. After a few password changes, users will get used to the requirements.
Multiple Security levels
Individual GPO’s can be applied to different security groups as well. This allows for example for strong password policies on accounts with higher privileges, while still providing an acceptable, lower strength policy for normal network users. It is very important however that no exceptions are made for any user requesting a lower level of password strength. The chain of security is only as strong as its weakest link, and a manager who cannot remember their password should not be allowed to be a security risk.
Account Lockout Policy
A well-tried and tested way to reduce the risks of a brute force attack or simple hands-on password guessing is the implementation of an account lockout policy. Forward port 3389 for remote desktop users or port 110 for POP3 users to the Internet via NAT and within minutes, these services will be under dictionary attacks originating from many different servers at the same time. I will elaborate more about this in another article, but when it comes to passwords, an account lockout policy is the best measure to take.
Any values set in this policy need to be carefully thought out, because when they are too strict, users can lock themselves out. This will result in downtime for users and increased support time for the IT department responsible for unlocking accounts.
Another problem with lockout policies is the possibility of a DOS attack. An account can be locked after reaching a limit of failed login attempts for instance. These attempts can be made manually by the user, automated by a dictionary attack, but also by an external or internal party trying to prevent users from logging in.
The Account Lockout Policy is made up of the following three settings.
Account lockout duration
This setting simply determines the lockout duration after reaching the limit of invalid logon attempts. A low value of 30 minutes would deter an external attacker, because it would take too long to run through the password lists. If the attack is fully automated and the attacking system keeps trying despite the account being locked, all login attempts during the 30 minutes would be useless.
A much longer lockout time can be used as well, but considering most attacks occur during the night, a long lockout time could mean users find their accounts locked when they come in the next morning.
Account lockout threshold
This value is the limit of invalid login attempts before the system locks an account. A user should be able to get a password right within 5 guesses, even on a Monday morning. The lower this value is set, the higher the amount of calls to IT support to unlock accounts. The higher this value is set, the greater the opportunity for an attacker to guess the password.
Reset account lockout after
This setting will prevent an attacker from trying to crack a password by utilizing breaks after nearly reaching the account lockout threshold value. With this value set equal to the value for Account lockout duration, it will not be possible to wait a few minutes to reset the logon threshold counter, after which an attack can be launched again. The equal values mean the attacker would need to wait for as long as the lockout would last anyway.
Password protect screensaver
Finally we will look at the password protected screensaver. This is an important security policy which is quite often neglected. A lot of effort can be put into the implementation of strong password policies, but a staff member can leave a workstation switched on overnight. This can be done by a user intentionally to save time booting up the next morning or simply because he or she simply forgot to log off. Anyone, such as for instance overnight cleaning staff, can access that workstation while the user is away. This can mean during lunch breaks as well.
There are two settings that can be used to create a network-enforced password protected screensaver within Windows Server2008.
Password protect the screensaver
This setting should be enabled to enforce the password requirement when disabling the screensaver.
Screen saver timeout
This setting determines the time before the screensaver is enabled. Because of the password requirement to disable the screensaver, this value should not be too low. It can be very frustrating having to login after every phone call. A value of 20 minutes should create a balance between security and user acceptance, of course depending on the companies’ individual security risks.
As I have mentioned before in this article, security is a chain which is only as strong as its weakest link. Especially in SME environments where protocols and procedures can be a little more “unofficial”, exceptions to security rules can be easily made.
Some users such as senior management might find a greater impact upon their work by security controls than others and they might get very frustrated by the discussed password policies. For these users however, a policy such as a password protected screensaver is even more important than for the other users, simply because the risks to the business upon a data breach are usually higher.
This quick guide shows that password policies are easy to implement. They can be automatically enforced and are often free from any associated costs. They should therefore be a standard within any network environment, including SME’s.