Level 3: Medium to Large Enterprise Wireless LAN Security
Level 3 Wireless LAN security builds on the same principles of Level 2, but you're not allowed to use the "cheats" such as bolting on the RADIUS server on to an existing server or using Self Signed Digital Certificates. PEAP-EAP-MSCHAPv2 is also disallowed because of its sole dependency on passwords which would be classified as "single factor" authentication. EAP-TLS or PEAP-EAP-TLS using "soft" Digital Certificates (certificates that are stored on the user's hard drive) would be the recommended authentication method for this security level. PEAP-EAP-TLS is an improved version of the original EAP-TLS protocol that goes further to encrypt client digital certificate information. Both PEAP-EAP-TLS and EAP-TLS have the same server and client side digital certificate requirements, but PEAP-EAP-TLS may not be compatible with some older Supplicants (Client Software) or some non-Microsoft client side implementations.
Level 3 Wireless LAN security builds on the same principles of Level 2, but you're not allowed to use the "cheats" such as bolting on the RADIUS server on to an existing server or using Self Signed Digital Certificates. PEAP-EAP-MSCHAPv2 is also disallowed because of its sole dependency on passwords which would be classified as "single factor" authentication. EAP-TLS or PEAP-EAP-TLS using "soft" Digital Certificates (certificates that are stored on the user's hard drive) would be the recommended authentication method for this security level. PEAP-EAP-TLS is an improved version of the original EAP-TLS protocol that goes further to encrypt client digital certificate information. Both PEAP-EAP-TLS and EAP-TLS have the same server and client side digital certificate requirements, but PEAP-EAP-TLS may not be compatible with some older Supplicants (Client Software) or some non-Microsoft client side implementations.
To implement EAP-TLS or PEAP-EAP-TLS, not only does the server require a Digital Certificate but the users as well. This means you will need a full blown Certificate Authority to issue a proper Server Digital Certificate on a pair of dedicated RADIUS servers and not just a Self Signed Certificate on a makeshift RADIUS Server. For this security level, the proper PKI best practices should be followed. There should be at least a single dedicated PKI Root Certificate Authority, but preferably it should at least be a 2 or 3 tier PKI design.
A two tier chain for a medium Enterprise organization would have an offline Root Certificate Authority and an online Issuing Certificate Authority. A large Enterprise should implement the three tier design with offline Root Certificate Authority, offline subordinate Certificate Authority, and online Issuing Certificate Authority. The reason for this is that if a Certificate Authority is ever compromised, you can revoke it and create a new one from the higher offline Certificate Authorities without having to start your PKI deployment from scratch. Building a PKI from scratch because of a compromised Certificate Authority would be completely unacceptable in a large scale environment.
To deploy Digital Certificates to the user community, a PKI management infrastructure must be deployed and permanent human resources must be allocated to manage end user certificates if your user base numbers in the thousands or more. Medium size Enterprises can add PKI management to their current hire/termination procedure. Microsoft Active Directory with an Enterprise Root Certificate Authority (a PKI that is completely integrated in to an Active Directory) can issue digital certificates automatically, but be warned that this is not a substitute for proper management. Lost or stolen laptops or terminated employees must have their digital certificates revoked and this is not an automatic process even if a user account is disabled or deleted.
After the certificates are revoked, they must be published in a CRL (Certificate Revocation List) and be applied to all Authentication servers or else the revoked certificates are still usable. If Active Directory auto-enrollment is used, it is highly recommended that you do not just apply the policy to the entire domain by default so that everyone will automatically get a user digital certificate. The policy should be set on just a particular OU (Organizational Unit) so that users who need user certificates and Wireless LAN access must be manually moved to that Certificate enabled OU. Automatic enrollment should be used as a way to simplify management, not substitute management.
As for encryption, the same requirements and recommendations from the previous 2 levels applyl. TKIP at a minimum but AES is recommended as soon as possible. Level 3 organizations should probably be the first to jump to the next level of encryption. The size of these organizations that would select Level 3 wireless LAN security can make upgrading difficult, but it's too important to ignore. The good news is that once AES is achieved, it is expected to hold for some time.
From a vulnerability standpoint, Level 3 is reasonably secure. The only way to compromise this security level is if the hacker can not only steal a user's password, but also steal that user's Digital Certificate which is much more difficult than just stealing a user's password. To steal a "soft" Digital Certificate, either the laptop needs to be stolen in which case it would be obvious and the certificate could be revoked, or a malicious program like a backdoor, virus or worm would have to be installed on the laptop to "harvest" the private key of the digital certificate.
The latter option is much more sinister because a theft could occur totally undetected and the certificate would not be revoked. The same malicious code could also "log" the user's keystrokes and the user's password would be compromised as well. At this point, Level 3 security would be totally defeated hence the need for an even stronger solution in Level 4. Discriminating Enterprises should seriously consider the next security level.
A two tier chain for a medium Enterprise organization would have an offline Root Certificate Authority and an online Issuing Certificate Authority. A large Enterprise should implement the three tier design with offline Root Certificate Authority, offline subordinate Certificate Authority, and online Issuing Certificate Authority. The reason for this is that if a Certificate Authority is ever compromised, you can revoke it and create a new one from the higher offline Certificate Authorities without having to start your PKI deployment from scratch. Building a PKI from scratch because of a compromised Certificate Authority would be completely unacceptable in a large scale environment.
To deploy Digital Certificates to the user community, a PKI management infrastructure must be deployed and permanent human resources must be allocated to manage end user certificates if your user base numbers in the thousands or more. Medium size Enterprises can add PKI management to their current hire/termination procedure. Microsoft Active Directory with an Enterprise Root Certificate Authority (a PKI that is completely integrated in to an Active Directory) can issue digital certificates automatically, but be warned that this is not a substitute for proper management. Lost or stolen laptops or terminated employees must have their digital certificates revoked and this is not an automatic process even if a user account is disabled or deleted.
After the certificates are revoked, they must be published in a CRL (Certificate Revocation List) and be applied to all Authentication servers or else the revoked certificates are still usable. If Active Directory auto-enrollment is used, it is highly recommended that you do not just apply the policy to the entire domain by default so that everyone will automatically get a user digital certificate. The policy should be set on just a particular OU (Organizational Unit) so that users who need user certificates and Wireless LAN access must be manually moved to that Certificate enabled OU. Automatic enrollment should be used as a way to simplify management, not substitute management.
As for encryption, the same requirements and recommendations from the previous 2 levels applyl. TKIP at a minimum but AES is recommended as soon as possible. Level 3 organizations should probably be the first to jump to the next level of encryption. The size of these organizations that would select Level 3 wireless LAN security can make upgrading difficult, but it's too important to ignore. The good news is that once AES is achieved, it is expected to hold for some time.
From a vulnerability standpoint, Level 3 is reasonably secure. The only way to compromise this security level is if the hacker can not only steal a user's password, but also steal that user's Digital Certificate which is much more difficult than just stealing a user's password. To steal a "soft" Digital Certificate, either the laptop needs to be stolen in which case it would be obvious and the certificate could be revoked, or a malicious program like a backdoor, virus or worm would have to be installed on the laptop to "harvest" the private key of the digital certificate.
The latter option is much more sinister because a theft could occur totally undetected and the certificate would not be revoked. The same malicious code could also "log" the user's keystrokes and the user's password would be compromised as well. At this point, Level 3 security would be totally defeated hence the need for an even stronger solution in Level 4. Discriminating Enterprises should seriously consider the next security level.
0 comments:
Post a Comment