Many organizations are faced with the decision to implement or to forgo corporate WiFi. There are a number of considers to think about when contemplating this and many are business and security related and not merely technical in nature. Here are some things to consider:
1. Is it necessary?
The first question to ask yourself is whether or not WiFi is necessary, and you must also realize that there are different levels of what is “actually” necessary. If the CEO says that it is necessary to implement WiFi, you must consider the business reason for why it is needed. Would it be used for guest access, internal access, only in conference rooms, or so that tablets can easily access documents? If its the latter, then there are other far reaching things to consider regarding compliance (see our first post in this series). Think long and hard about whether WiFi is really necessary, and whether or not the infrastructure, policies and procedures, and executive buy-in are in place to support a well secured corporate WiFi infrastructure.
At this point we assume that WiFi is, indeed, necessary. Now, when deciding on what hardware to use, you should use nothing less than enterprise class hardware, end of story. A home network class access point, such as Linksys or D-Link should not be relied upon to protect your corporate network. If you can’t do it right, don’t do it at all.
3. Strong Encryption/Authentication
The encryption should be nothing less than WPA2-Enterprise with 802.1x (LDAP/RADIUS authentication). Another option is certificate based authentication so that only devices with corporately issued certificates can connect. If guest access is available, it should have nothing less than WPA2 and one time passwords issued at a splash screen. These passwords should be directly issues by corporate resources, and not in the form of handouts or posted fliers around the office, and available to your next door tenants.
4. Guest WiFi
If guest WiFi is required, it should not be public as stated above, it should be protected by WPA2 and require one time passwords for access. Under no circumstance should guest WiFi provide any access to internal network resources. Ideally, there would be a physical separation from internal resources, but a strong logical separation can work as well.
Configure the power output on the access point antennas so that the signal does not extend far outside of your physical location. There is no reason to broadcast any more than is necessary to provide useful coverage, and you should definitely not be broadcasting your WiFi to anyone outside of your corporation.
6. SSID (Network Name) broadcast
There are differing opinions on this, even among my colleagues. I will cover both lines of thought. If SSID is not broadcast, it helps keep random, non-technical people from attempting to connect to the network, but a well trained individual can easily get around this. If an SSID is not broadcast, the devices connecting to it are set to automatically connect so that they do not have to be configured every time. This opens those devices up to a rather simple man in the middle attack. So not broadcasting an SSID can offer some obfuscation, but it does not offer any real additional security benefit for the organization. On the other side, if the SSID is broadcast, it’s there for the world to see, and it does not mean the devices won’t automatically connect (though this can be managed through policy). This is a discussion that should be thoroughly investigated for a particular company. My opinion on this is that the SSID should be broadcast because there should be other security measures already in place.
Personal devices should not be allowed to connect to the internal network. The only exception that I would consider are devices managed through a mobile device management (MDM) system. Even then, I am hesitant to recommend this because of the lack of malware and monitoring on personal devices.
8. Corporate Policy
On the flip side of the previous item, corporate devices should not be allowed to connect to the guest WiFi at all, but especially when connected to the physical internal network. This it the equivalent of leaving a window open.
In conclusion, WiFi adds additional attack vectors to a network, it requires additional management from the existing physical LAN, and there a number of factors that are difficult to manage regarding access, authentication and enforcement. If the business does not require it, and it is only a nice to have for convenience; I would consider long and hard whether or not the benefits outweigh the detriments to network security.
The Hitlist is a new series where we will attempt to provide a quick list of security considerations for a particular technology or initiative within an organization. Our first post will be on compliance. What we mean is if your organization is attempting to become compliant to an industry standard or regulation, these are things that will have to be considered and more than likely implemented across the board for things such as PCI-DSS, HIPAA, ISO27k, FISMA and more. Here is the hitlist for things to consider when planning to meet a compliance standard:
1. Patch Your Stuff
Everyone hates having to patch their servers and network devices every month or so. This might be one of the most basic security requirement maintaining network security. You must patch not only operating systems, but also software applications such Adobe and Java. We often see anywhere from 20-60% of the vulnerabilities on a network as critical or high and usually 50-80% of those are either Microsoft, Java and Adobe. If you don’t do this on a regular basis, it’s time to start.
2. Risk Assessment
How do you know what to protect if you don’t know where your risks are? A risk assessment will evaluate your biggest gaps and your biggest liabilities. This will allow your organization to focus its efforts where the most impact can be made quickly.
3. Data Classification
You need to know what your data is and where your data is. If only a small portion of your data contains sensitive information, then all of your data doesn’t need to be under the same scrutiny. You need to identify what the sensitive data is so that you can identify where that data is. Once you know where it resides, then you can put controls and processes in place to protect it. Additionally, it is essential to have policies and procedures in place so that all this information is documented.
4. Network Monitoring/Testing
Many compliance standards require annual penetration testing and vulnerability assessments. Additionally tools should be in place to monitor the network in real time: antivirus, intrusion detection/prevention (IDS/IPS), enterprise class firewalls, Data Loss Prevention (DLP). The extent of the required real-time monitoring will vary on the budget of the organization, the requirements of the compliance standard and the type of data being protected.
5. Data Encryption
Do you have sensitive data? It needs to be encrypted now. Whenever it moves (email, ftp, file shares) that communication needs to be encrypted. Whenever it’s at rest (USB drives, file shares, desktops, mobile devices) it needs to be encrypted, no exception. Industry standard, strong encryption is the only sure way to make sure that if portable media is lost or stolen, prying eyes can’t read the data.
6. User Training
Most standards require annual security training. It is also just a good practice for any organization. How many of your users can recognize a phishing email? How many users have their guard up for a phone call asking them to give up sensitive information? Users need to good reminders on basic security tenants.
Why lock your doors if the key is hanging on the wall? Not only to strong and unique passwords need to be enforced (this includes the C-suite), but 2 factor authentication needs to be strongly considered, especially for access to sensitive data. If 2 factor authentication is available, then the complexity requirements on passwords can drop a notch (that doesn’t mean 6 characters, no special characters). An ideal corporate authentication strategy for standard users would be 8-12 characters, numbers, letters, special characters, and a password history of at least 10 in addition to 2 factor authentication. For users with direct access to sensitive data or with technical administration roles the requirements should be stricter.
8. Separation of Duties
Have you ever seen the movie where they are about to launch the nuclear missiles and it requires a code and 2 keys? They do that so that no single person can launch a nuclear missile. The same is true for network administrative. Your network admins should be using their standard user accounts for performing administrative functions. They should have separate accounts used for remote access, email access, and workstation access from the accounts they use to manage the network. There are exceptions based on the magnitude of the operations (adding users, joining a computer to the domain, etc). I have seen too many organizations where a system administrator has a standard account that is a member of the most privileged groups in the domain and also uses that account for remote access.
9. Centralized Logging
This one isn’t a requirement for all standards, but it is for some and it is essential to know what is happening in your network. Centralized logging can allow you to find information about a security incident without having to go look through 15 different sources. Additionally, there are tools that allow an organization to add analytic and correlation to those logs that provides intelligence on top of the logs. What if you could know if a user account was attempting to log into your network from multiple cities or countries? This is how you can reduce the mean time of 87 days until discovery of a breach to just a few days.
10. Physical Security
If you have everything else buttoned up, but leave the back door open, it doesn’t matter. You need to be able to know when people come and go, you need to be able to see when people come and go, and you need to know where your assets are. Electronic key cards, video surveillance, and asset management are essential to a robust network security program.
You can theorize about how good you are, you can make educated guesses, and you can read a bunch of studies, but until you have a third party measure your compliance against your policies and your standards you won’t know. Most standards require for ‘periodic review,’ but put it this way, how will you ever know if you are compliant without having someone look?