Is your service secure? Do you think that you will pass an audit? Do you suppose your access management is bulletproof? Perhaps you are right, but if you are honest with yourself, you know that security is always worth double-checking, and that is why I am writing this–to share my opinion and experiences.
Working in environments beyond small and medium businesses, I have realized that security aspects are often overlooked, even in larger enterprises. There might be policies written down somewhere in an unmanaged Microsoft SharePoint, but what are documents good for if they are neither enforced nor considered when installing or changing devices in the infrastructure? Also, I have met device producing companies which seemed to have limited focus on security aspects. Even if the solution of such a company excels in price, features, or both, sometimes one simply cannot make a positive decision for that company if it is clear from the start that the solution will not be compliant to security policies.
In this article, I want to show a few points in security matters that are often overlooked; perhaps you will even learn a few things here before an evil auditor teaches you about it.
Default username / default password
From the moment you take a device out of the box or install software on a server, the developer has usually a “factory” account in place which is often based on a default username and password to log in the very first time (it is also possible that there is no password protection in place at all). At this stage, you have a few options depending on the security level or the policies you have to adhere to. Option 1 is to have a generic admin account with a customized password to prevent attacks from people who are exploiting your device with the help of web pages like “the default password list”. Option 2 involves every administrative user getting their own username and choosing a password that only he or she is aware of. To sum this up, one could say that option 1 will prevent people outside the administrative team from accessing your device and option 2 will prevent attacks from within the team, so long as the password is not shared with anyone.
Social Engineering
Even though Social Engineering is a part of most information sensitivity trainings, many employees are still failing when being tested on a Social Engineering attack. A Social Engineer can be a man or a woman pretending to be part of the team or organization and will virtually or physically engage users to share critical information such as the login credentials. There are no technical configurations that can entirely prevent this from happening as long you are employing humans and not robots, however you can train employees who are handling crucial information and run awareness campaigns.
Guest accounts
For some scenarios, the developer has implemented guest accounts or public space that can be used or viewed without logging in. If you are not using these features, you should be aware of them and disable these guest accounts to prevent users from accessing data which they are not meant to access.
Insecure protocols and services
Often the default configuration is to have all available protocols enabled. However, many of these are not secure (such as HTTP, FTP, Telnet, SNMP) and should be disabled permanently. If possible, you should use the secure alternative of a protocol. If a protocol is only temporarily required–for instance, when doing a backup via FTP– and there is no secure alternative available, you may enable it for the duration of the task and then again disable the service.
Logs
Any change and kind of action should be logged in a proper way; this feature is often called audit log or user log. In some cases, it is possible that a device clears its log when rebooting or that the log can be manually deleted or altered. To prevent this, you can work with a syslog server where these log information is stored away from the appliance itself and can be checked after a possible attack.
Encryption
Cryptography is a set of technologies for hiding information. Whenever possible, an encryption feature should be used so data cannot leak when being transferred. A common solution for encryption is AES (Advanced Encryption Standard).
Password strength and change frequency
In the best case scenario, a save password should contain random special characters, numbers, capital letters as well as normal letters and should be as long as possible. It should not follow a pattern on the keyboard and to prevent brute-force attacks, should not contain words that could be found in a dictionary. The password should not be written down physically and definitely should not end up on a post-it note stuck on the front of your monitor or underneath the keyboard. If there are policies active that enforce a password that is rather hard to memorize, you should ask your information security officer for password management software that is approved within your organization.
The change frequency–or the change of passwords in general–is a subject open for discussion, but if it is policy to change the password every three months, then it just has to be done. It still makes sense to do so, even if changing passwords encourages users to choose weaker passwords in order to memorize them better. The lifetime of a password is approximately less than 100 days and that is because it would take approximately 100 days to crack a password with a normal strength.
Summary
These points are just my hints and, of course, you should always consult the information security personnel of your organization and check for active policies first. If you have feedback or feel that I have overlooked an important subject, please feel free to write a comment below and we can work on further completion together.
Thanks for reading and good luck with the audit.
This post was originally published at a the Radical Logic blog in October 2011 but has now been transferred here since the old platform is no longer maintained.
Photo credit: Nicolas Raymond / Athena Stock
