The threats and risks which are coming out are on a daily basis, and literally by the hour and the minute. Just consider this: In the United States alone in 2013, there were over twenty million Cyber based attacks on a daily basis (SOURCE: 1). However, this was back in 2013. Now imagine how much it has proliferated today, and on a global basis, not just here in the United States. Every day, you have to be on your constant guard to make sure that your wireless devices or even hard wired devices are not infected with any type or kind of Malware, Spyware, or even Adware. The worst part of this is that you never know when you become a victim. Many of these attacks happen very covertly. You only that you have been victimized after the fact, and when it is too late. In the end, all a corporation or business can do is just to be vigilant for any Cyber-based threats which could be occurring from either outside or inside the Security perimeter. Many people have the assumption that if the organization has invested lots of money into the latest Security technologies, then all be well. However, this is far from the truth. The fact is that the Cyber attacker of today is going after the most recent tools, and exploiting them to the maximum amount possible. It is not just technology per se, but rather a combination of both vigilance and technology is needed to thwart off any Security threats or risks. Put in more technical terms, this can also be referred to as the “Equation of Security,” and can be represented as follows: Security Technology + Human Vigilance = Risk/Threat Mitigation When using Security Technology, it means that the tools and resources which are using are up to date with the latest Security patches and that all of the end users are effectively trained in its effective usage. With regards to Human Vigilance, it means that the management team or the IT staff is proactive in keeping alert as to what is specifically happening in their environments, both internally and externally. Being vigilant also means that one can act quickly as well upon the intelligence and information/data which is given to him or her, and using it as effectively as possible. For instance, if there is a dataset which becomes available which shows the attack profile of a potential Cyber threat, then the IT staff must use and decide ahead of time what can be done so that the business or the corporation does not fall prey. However, being proactive on Security related matters is very much a subjective issue. For example, one cannot be “trained” on how to proactive; rather it is a mindset which must be instilled for a long time. In other words, when it comes to a business or a corporation, instilling and implementing this kind of mindset takes an entire group effort, no one person can entirely shoulder this enormous responsibility. Regarding the technological part of the equation mentioned above, it is not enough just to simply install the requisite software patches and upgrades. There is no doubt that this will further enhance the security layers of your Central Servers and related software applications, but once again, this is another crucial area upon which the Cyber attacker preys on. They do this because, in actuality, the software patches and upgrades very often contain Security vulnerabilities themselves, even which the vendor that issued them does not know about. So, apart from simply downloading and installing the upgrades and the software patches, it is also important to test them in the production environment that they are in. This is where the role of Penetration Testing will become very useful. In fact, every facet of the IT Infrastructure of the business or corporation must be tested in this regard. The frequency of testing, of course, depends on the type or kind of technology in question. This is especially true of a Virtual Private Network Infrastructure, and when it is first deployed. Before it can operate in a production based environment, it must be thoroughly tested before it can be used the purposes of remote access and access to network-based resources. This article will review this, focusing on the following:
Virtual Private Network Infrastructure Testing – Off the Shelf.
Even though the business or the corporation may have purchased an “Off the Shelf” Virtual Private Network Infrastructure, it still needs to Security tested just as much as if you have built your own. In other words, just because the VPN comes from a Vendor, it still needs to be tested in your specific environment, to make sure that it lives up to your Security requirements and expectations. It needs to be thoroughly tested from a number of different angles, with the following aspects in mind:
The general attacks against a Virtual Private Infrastructure and the remedies include the following:
Always destroy the Plaintext after it has been converted over into the Ciphertext. If Virtual Memory is used, make sure that the Plaintext which is stored in that also gets destroyed as well. Always delete the passwords from any type or kind of memory at the end of the business day. Make sure that the encrypted Ciphertext is protected with a very strong Public Key/Private Key combination, and not just a combination of a strong one and a weak one. Do not let the Master Keys be governed or managed by the Session Keys. As much as possible, make sure that every possible method in which a hacker can either guess or learn your Public Key/Private Key combination is mitigated – this is where the role of Penetration Testing is especially critical.
Attacks against the hardware of a Virtual Private Network Infrastructure can be mitigated by using the following techniques:
Measuring the Power Consumption Usage. Having the ability to measure the level of Radiation Emissions from what is known as the “other side channels” in a VPN. Conducting a Fault Tolerance Analysis. Purposely and deliberately introducing various faults to determine the vulnerabilities and weaknesses of the Public Key/Private Key combination.
Attacks against Trust Modules: As much as a business or a corporation has to be aware of the technological threats which are posed to a Virtual Private Network Infrastructure, it too has to be aware of the threats which are posed from the human side of the equation. Examples of this include the following:
Which of the personnel at the organization can be trusted and not trusted? How does the VPN confer levels of “trust” amongst the IT staff? To what levels should this trust be extended? How can you avoid the possibility of collusion with the end users of a VPN? How do you avoid the human temptation to fully trust all of your employees (especially the IT Staff) with a VPN? What systems are currently in place make sure that the Version Control to the software code which is associated with the VPN is firmly locked down and secure? How to train your employees to get away from the notion of convenience versus Security for the VPN? How confident are you that your VPN system is as much as 100% irreversible engineered as possible? How do you eradicate the false sense of security with your employees that a Trust Model is always going to be 100% safe, and thus will never need any future improvements? In this regard, it is a given fact that improvements will always have to be constantly made. Also, the associated Security and Trust Models will also have be to updated as well.
Attacks against Failure Recovery: Failure Recovery describes the Virtual Private Network Infrastructure’s capability to maintain very high levels of Security in the imminence of any component breakdown or failure. In other words, this becomes a Functionality versus Security debate. There has to be a fine line which is drawn and equally balanced as to what is most important for the corporation or the business in the face of major malfunction or breakdown from within the VPN: The customer’s and employees convenience or taking the time to have a proper Backup and Recovery process in place?
Attacks against the Cryptographic components of the Virtual Private Network Infrastructure: Despite deploying and implementing the best Cryptographic tools in place, flaws and errors can and still do occur from time to time. To help prevent this from happening, it is important to implement the following steps for your VPN:
Keep the mathematical values as random as possible, all of the time. Make sure that the Cryptographic Digital Signatures are strictly correct about the parameters they need to be in and under what specific IT Assets that they should be used for. From the standpoint of the IT staff, they should know and understand the appropriate as well as the inappropriate uses of the VPN based protocols.
The establishment of a VPN testbed: It is important to keep in mind that that the VPN must be able to communicate and process the Data Packets with any other VPN not just at the business or corporation from where it originates, but from other organizations as well, as they might even have a totally different VPN setup. To allow for this flow of communications to be as efficient and effective as possible, the following factors must be taken into consideration: àMake sure that there are dedicated PCs for each end user (or in this case, the employee). àIt is imperative to issue test versions of the X.509 Digital Certificate for each end user and each network resource which requires access to the VPN. àUse only Trusted Internet Service Providers to allow for the access from the remote office locations, especially where remote connectivity is an absolute must. àIf possible, try to exchange a few of the Digital Certificates to the test population group at the business or the corporation. àNever use the Corporate Intranet for the testing of VPN between client PC. àConsider the possibilities of deploying and using test machines to test the VPN at different offsite locations. àTry to implement the use of test cases for both the Network Gateways as well as the clients. This will enable the IT staff to compare the test results equally between the various VPN systems which are being used. àMost importantly, document the test results from the initial testing and report any types or kinds of problems, malfunctions, and abnormalities which may be experienced, and report this promptly from the vendor of which you obtained your VPN system. That way, any problems, weaknesses, or vulnerabilities can be quickly rectified and mitigated.
In summary, this article has continued with the theme of the Virtual Private Network Infrastructure. The last article examined in more detail how to construct your own VPN system, and some of the key requirements which should be examined when testing it. àMake sure that there are dedicated PCs for each end user (or in this case, the employee). àIt is imperative to issue test versions of the X.509 Digital Certificate for each end user and each network resource which requires access to the VPN. àUse only Trusted Internet Service Providers to allow for the access from the remote office locations, especially where remote connectivity is an absolute must. àIf possible, try to exchange a few of the Digital Certificates to the test population group at the business or the corporation. àNever use the Corporate Intranet for the testing of VPN between client PC. àConsider the possibilities of deploying and using test machines to test the VPN at different offsite locations. àTry to implement the use of test cases for both the Network Gateways as well as the clients. This will enable the IT staff to compare the test results equally between the various VPN systems which are being used. àMost importantly, document the test results from the initial testing and report any types or kinds of problems, malfunctions, and abnormalities which may be experienced, and report this promptly from the vendor of which you obtained your VPN system. That way, any problems, weaknesses, or vulnerabilities can be quickly rectified and mitigated. This article has taken a different angle, using the assumption that the business or corporation has already procured and deployed a VPN system from a trusted third party, such as that of an established vendor. As it was stated, there is often the mistaken belief that just because all of the components came from this trusted third party, that there is no need for any type or kind of testing. Although an analysis was probably conducted ahead of time indicating that the VPN system will fit into the Information Technology environment of the corporation or the business, the only way to see if it will truly fit is by conducting pilot tests of it in a test environment, before it can be put into the production environment. This process will reveal if there are any kinks, or weaknesses which were not seen in the analysis phase. The variables which need to be taken into consideration in this regard were examined in this article. Our next article examines the use of the VPN system in Public Key Infrastructure (PKI), focusing on the impacts of the Public Key/Private Key combination, and the Access Control Lists.
https://www.fortis.edu/blog/technology/millions-of-cyber-attacks-happening-each-day/id/3333 http://www.ibm.com/support/knowledgecenter/ssw_ibm_i_73/rzaja/rzajapdf.pdf http://www.nerc.com/fileUploads/File/Events%20Analysis/FINAL-Guidance_for_Secure_Interactive_Remote_Access.pdf http://www.keysight.com/upload/cmc_upload/All/whitepaper-mplsipvpn.pdf?&cc=US&lc=eng http://www.networkinv.com/wp-content/uploads/application-bgan/Using-VPNs-over-BGAN.pdf http://csr.bu.edu/icnp2005/papers/23_cameraready_139%5B1%5D.pdf https://opengear.zendesk.com/hc/en-us/articles/216374923-Configuring-an-IPsec-VPN-connection http://www.sersc.org/journals/JSE/vol5_no5_2008/7.pdf https://www.blackhat.com/docs/us-16/materials/us-16-McGrew-Secure-Penetration-Testing-Operations-Demonstrated-Weaknesses-In-Learning-Material-And-Tools-wp.pdf http://www.disa.mil/~/media/Files/DISA/Services/Network-Services/Private-IP/EstablishConnectToVPN-CustOrdGuide.pdf
