As experts in Cisco Professional Services, the 4CornerNetworks blog covers a wide range of Cisco Network related topics. Our blog features topics from Cisco Support Services, Cisco Engineers and our specialist blogs based on Cisco Security.
Head of Security Deyan Panchev writes about Cisco Security providing advice, tips and insights into topics such as Cisco Firepower services, Cisco ASA Firewall Support, Installations and Deployments. Topical issues about network security are also discussed on our blog ranging from the NGFW (Next Generation Firewalls) to the recent Wannacry outbreak.
Subscribe to the 4CornerNetworks blog and follow us on LinkedIn and Twitter for the latest updates.
Virtual Private Networks constitute a hot topic in networking because they provide low cost and secure communications between sites (site-to-site VPNs) whilst improving productivity by extending corporate networks to remote users (remote access VPNs). Naturally the VPN technology is widely deployed on all internet edge devices and most ASAs.
Cisco is very proud of its VPN solutions. It’s one of the few vendors that support such a wide range of VPN technologies with so many features and flexibility. Cisco Routers and Cisco ASA Firewalls are the two types of devices that are used most often to build Cisco Virtual Private Networks. Cisco has been very strict about the way its routers and firewalls should be used and what technologies are available to them – routers will do the full range of Site-To-Site of VPNs: Traditional (Policy-based) IPsec VPNs, but also GRE IPsec VPNs, DMVPNs, GET VPNs, and have limited capabilities for the remote access VPNs: IPsec and SSL based. However, the ASA is very different so far it could do just traditional policy based L2L IPsec VPN but will have the full functionality for remote based VPNs. The message was very clear, for large organization and ISP use Routers for remote access VPN and static traditional Site-to-Site use the ASAs.
Things changed, Cisco very recently introduced a new feature with its 9.7.x code in the VPN module of the ASA – the VTI (Virtual Tunnel Interface). VTI were long available in Cisco Routers but never in Cisco Firewalls but similar technologies (Route-Based VPNs) were available in most competitors and the demand for that features finally took effect on Cisco and they introduced it.
Now before understanding why VTI are so important we will do a quick comparison between the traditional Site-to-Site IPsec VPN (Policy Based VPNs) and the VTI (Route-Based VPNs)
Policy Based VPNs
They rely on static (policy based) configuration of the encryption domain (usually by ACLs) and do not pass multicasts, not great for dynamic routing and voice/video and other multicast applications and requires re-configuration on both sides if the networks that traverse the VPN should change. The configuration is quite complex involving many steps that need to be same or mirrored (encryption domains/ACL config) and that is prone to mistakes.
However, the benefits are that this is a well matured configuration process and the IPsec VPN is a IETF standard which means all vendors must implement it according to the specifications of the standard, hence in theory it should always work between in multivendor scenarios. This is important because the two main uses of L2L (Site-to-Site) VPNs is connecting same company sites over internet thus replacing more expensive intranets or connecting one company to another company/partner/provider of services over Internet in a secure manner. In that second case, there is a big chance that both companies will use different vendors for VPN devices.
A route-based VPN configuration uses Layer3 routed tunnel interfaces (either GRE based or VTI based) as the endpoints of the VPN. Instead of selecting a static subset of traffic to pass through the VPN tunnel using an Access List, all traffic passing through the special Layer3 tunnel interface is placed into the VPN. Therefore, you need to configure routing accordingly. Either a dynamic routing protocol (such as EIGRP or OSPF) or static routing must be configured to divert VPN traffic through the special Layer3 tunnel interface. That makes the selection of interesting traffic dynamic and you have the flexibility to perform changes and introduce new traffic to the VPN without redoing the VPN configuration (only by changing the routing so new traffic gets routed to the interface). Another benefit is that this type of VPN can pass multicast traffic thus allowing dynamic routing protocols and enabling multicast applications to work.
There are some limitation and considerations that need to be taken in mind. First VTI is a proprietary to Cisco technology, despite other vendors having similar route-based VPN technology, there is no guarantee these will work between each other. Also, the tunnel interface itself does not provide inherited security, IPsec protection is an add-on and needs to be configured on top for encryption/security of traffic.
Summary and conclusions:
Introducing VTIs in ASAs is a big step forward in making the firewall an even more versatile network edge device. The VTI capability to provide security and encryption on multicast traffic and its flexibility for tunneling the traffic via dynamic routing with zero reconfiguration on the VPN, means that any small or middle-sized organization with ASA on network edge can now benefit very strongly from that functionality and would not need to purchase additional hardware thus maximizing its return on investment value.
Cisco has finally decided to merge its two major network security products – the ASA and FirePOWER. These two have been living on the same hardware (5500X) model for years now but they required separate management which increased the deployment and operational costs for a Cisco FirePOWER implementation. Now Cisco has decided to merge these two platforms by removing the logical separation in hardware and the full separation in software by creating a merged OS that combines the features of both worlds, hence lowering the time/costs for deployment and running.
A bit of History
Cisco is a major player in the Firewall Market since the PIX. With the introduction of the first gen ASA, the PIX was given a polish, new features (such as dynamic routing, QoS, new RFC based protocol inspections/fixup and a few more), but ASA’s were and still are a traditional stateful packet firewall positioned at the Internet Edge. The demands to introduce firewalls also in the DC drove the change from IP based object to Name based object and totally different way of doing NAT (including the introduction of the Any as interface) in versions 8.3+. Still the ASA was purely a stateful firewall and the IDS/IPS module that Cisco was offering was quite outdated in technology and had a less than excellent catch-rate. Cisco knew that and purchased the best IPS/IDS vendor out there – SourceFire.
Now Cisco had two flagmen in the network security and naturally decided to offer them as one box – hence the NX 5500X Firewalls were created, no modules needed, all you need to run both ASA and FirePOWER was an upgrade to SSD drives. However, the management, logging, operation of the ASA and FirePOWER was still independent – ASA was managed and monitored by either ASDM or CSM, where FirePOWER was using – FireSight (pre-version 6) and now FMC (Firepower Management Center). Most competitors (Palo Alto and Check Point) did not need nor have separate management platforms to configure their advanced Next-Gen capabilities and frankly speaking users/admins were not happy with having to do double amount of work to enable a Cisco Next Gen Firewall – interfaces, licensing, configuration, policies, monitoring etc.
In 2015 Cisco hinted about the concept of having one unified management OS that would combine the features of both FirePOWER and ASA. The FirePOWER was chosen as a base for that new image, so from day one the FTD image had almost a 100% of the FirePOWER functionality but a very small percentage of the ASA functionality. The first release (6.0) for testing and Cisco partners was in 2016 and then the FTP had about 20% of the features of the ASA – basic features of course were migrated first, but shockingly there was lack of some major features such as – HA, VPNs (both site-to-site and Anyconnect), dynamic routing protocols, virtualization/contexts, QoS. A quick introduction of 6.0.1 and 6.1 introduced HA failover so the FTD was now ready to go public.
The Situation today
Latest version release early 2017 is 6.2.0
Cisco continued its work to close the gap between the current ASA and FTD functionality. New major functionality added: Clustering for ASA, Site-To-Site IPSec VPN with certificates (6.1 supported Site-to-Site VPN but only with Pre-Shared-Key), PKI support, SGT without Realm, Migration tool (from traditional ASA to FTD), REST API, Packet Tracer and Capture functionality.
On top of the migrated in 6.1 functionalities such as integrations with Cisco ISE, Threat Grip, on-box management for some model, the 6.2 is looking more and more enterprise ready (not only SOHO as the 6.0 and 6.1). Also, adding the tools for automated migration, the FTD becomes more easily available when doing migration. The user base is also enlarging quite quickly (good for discovering of bugs and security/stability issues). Version 6.2.1 is just around the corner and will close the gap even further introducing the Anyconnect Remote Access functionality and many improvements/new features in NAT, Dynamic Routing, Multicast and QoS, HA, Site-To-Site VPN and interestingly an option for conversion back to ASA image.
This all points that soon there will be a major swift in the Cisco Security community and more and more clients will start using FTD. Naturally after break-point Cisco will start the phase out of the traditional ASA image (functionality gap will be in favor of the FTD) and clients will be forced to switch. Of course, that process will take time but why not be ahead of the curve?
SHA-1 is dead, from a security point of view, but has been a long time coming. A combined research collaboration between CWI and Google, published a paper on 23th of February 2017 that proved deliberate collisions can be created for SHA-1 (Secure Hash Algorithm -1). The researchers managed to forge a PDF doc so I have the same SHA-1 value as completely different document (aka collision).
OK, why is that such a big deal?
Background information and the risk
Hash functions are widely used in the cryptography and hence in the VPN world. They are used to verify the presence of a piece of information on the other peer (for example a pre-shared-key) that matches perfectly with yours (that is authentication) and to confirm that data has not been tampered with during transit (integrity), hash functions are used in the Public Key Infrastructure to verify integrity and sign the certificates (aka to verify that certain a person with a certain name has a certain public key).
The ability for someone to create a forged data string so that it matches the computed hash of another data string nullifies the security and the idea of using hash functions in cryptography.
SHA-1 is still widely used for integrity/signing in IPsec IKEv1 (and sometimes IKEv2) and some PKI still support it so there are a multitude of certificates using it.
Furthermore, why is that important for Cisco VPN users?
IPsec IKEv1 does not support newer SHA algorithms (SHA-2) and the predominance of IPsec VPN is still built on IKEv1.
Even if you are using IKEv2 there could also be hardware restrictions preventing you from using modern hash functions (SHA-2) – legacy Cisco ASA devices (5505, 5510, 5520, 5540, 5550) cannot support newer hash functions in hardware and Cisco has not implemented the functionality into their software.
If your company is using a VPN and you need to audit them then ensure they are not using SHA-1 anymore. For expert VPN Security advice, contact 4CornerNetworks today.
Sources of Information:
We are experiencing a new phase in our vision of network security. There is currently no quick fix solution, no 100% proof network security protection/prevention tool or product. There is always zero-day or purposely built (very focused, low spread) APT malware that current vendors are unable to detect at the time of the breach.
Hence total prevention is a myth.
Most of the current network security solutions offer only Point-In-Time detection/prevention. Namely they inspect the traffic when the traffic goes via the firewall and if they deem the traffic is clean or unknown, at that exact time, they will allow it and forget about it. That could lead to malware passing through and being undetected for long periods of time. All vendors rely on intercepting the C&C communication to the botnet servers but not all malware uses such a centralized operation method so that cannot be considered a proven method of detection. That is why most of the vendors will apply their own sandboxing solution, namely send all files of unknown malware type to the cloud where they will be detonated in a controlled environment and the result of their execution will be deemed malicious or not by machines or sometimes humans. Upon discovery of malicious actions, the file is marked as malware and an update is shot out to all vendor appliances out there so they can intercept and drop such files. That process however takes time (typically more than 8 hours) and usually stops more than 96% of the malware spread (it depends on how quickly the different vendors discover that the file is malicious and how quickly the update is sent out) and that percentage was deemed high-enough for most companies.
What about that 4% though? I am sure any business owner would not like to be in this position and would like greater protection and value for their money. When a mere 4% can cause 100% of your security problems, you’re not protected.
Cisco is the only vendor in the NGFW market that currently has its vision also set on the retrospective side of the network security, the so-called After-The-Attack phase. Cisco uses the combination between Firepower and AMP for both network and endpoint to be able to provide threat context and to pinpoint the progress and spread of the malware in historical time so you will know exactly when and how the malware moved in your network, which hosts were infected so that you can immediately deploy mitigation techniques. First restrict the malware, block the effect of the malware and finally remove the malware that has already breached your network. Without this continuous analysis, the attack can run rampant on the network and it will be extremely difficult to determine the scope of the outbreak and the root cause or provide on-time/adequate response. Here is an example of such an event and how Firepower and AMP deal with it.
The following 4 simple steps represent how Firepower and Amp works with zero-day malware files:
- Unknown file gets downloaded to a client ip (220.127.116.11 for example) via http application with Firefox, the file is then allowed to reach the endpoint. The unknown file is sent to the cloud to be detonated and given a verdict.
- The Firepower tracks the movement/copying of the file within the network so it sees the file being propagated via any protocol at any time. For example, the file gets copied to another host 18.104.22.168 via SMB at 12:41 AM on the 1st of Dec 2016.
- Within 30min the same file gets replicated to 5 more devices within the internal range, all via SMB. The Firepower has a map of the file trajectory with hosts and timing of the movements.
- Two hours since the file was first seen, Cisco Security Intelligence Cloud had reached a verdict that the file in question is in fact malicious. From now on all Cisco AMP and Firepower enabled devices will drop that file upon encounter and alarm/log, but here comes the difference between Cisco and other vendors, namely the retrospective part. In our example, all future transfer of the files will be blocked and the file itself will be quarantined on all endpoints that have this file (requires AMP for endpoint), even more the administrators can leverage the trajectory map and verify the malicious file has been quarantined/removed and hosts have been remediated.
APT – Advanced Persistent Threats
C&C – Command and Control
NGFW – Next-Generation Firewall
There is not a single industry anywhere in the world who are immune from the threat of some form of cyber-attack. Any attacks on your organization’s IT Network will be unpredictable in terms of the exact method of attack, but you can at least be poised to deflect and protect your company from such cyber-attacks with these 8 easy to follow steps.
1. Implement your CyberSecurity strategy from the top-down
Devise a security strategy, make sure Directors and Management understand the importance of your organization’s IT Network Security. The fundamental thing about security is knowing the risks involved and understanding what needs to be secured, namely what are your valuables/assets.
Only after a thorough risk assessment has been carried out can a proper security strategy then be formed and implemented. The importance of cyber-security should be something that senior management understands and supports, resulting in a top-down approach to implementation.
2. Create polices for the allocation of internal IT Resources
Once the importance of security issues is fully understood by management, organizations can then begin to create and implement polices on how to use, manage and allocate company resources to tackle cyber security.
It is vital to then develop and enforce policies and procedures for employees to follow, this will impact:
- The allocation of company IT resources – allowed and prohibited expenditure
- Change management procedures to be implemented across all IT systems and related policies
- Reevaluate risk and security posture at regular intervals
3. Network Security
Have a network design with a strong focus on cyber-security. Segment your network on logical system based zones so you can isolate/segregate critical business systems and be able to apply network security controls to them – firewall/inspect traffic between those zones. Protect your Internet Edge but also internal traffic (east-west), cover the most used vectors of attack (email, web)
Pay special attention to wireless connectivity – use strong authentication based on individual credentials or personal certificates, strong encryption (AES) and proper guest/BYOD access. Plan carefully, home and remote users access – they should have equal security controls as users on corporate networks.
Have a central point for system monitoring (SIEM) that is integrated within your environment and provides a single point that holds all relative logs/events for your systems. Monitor your network/user activity with qualified staff. Fine tune your IPS systems to use relative to your network environment security rules/signatures and to produce relevant alarms. Act on the alarms promptly.
Secure both user/management and physical access to your network assets. Apply only secure configuration using the vendor/standard recommended best practices. Have a lifecycle policy in place – aka review/renew security controls/equipment at regular intervals. Finally, ensure you have an up to date network diagram with HLD/LLD documents.
4. Protect your endpoints/servers
Always use legitimately supported software and hardware. Create and maintain a policy for patching and updates – keep up to date with patches and security updates.
Devise and maintain a hardware and software repository – know what you have in your network. Centrally manage your endpoint from OS and software point of view. Limit user rights to make changes to endpoint security:
- Never give normal users full access (admin)
- Limit execution controls/change configuration
- Create safe-lists of allowed software
- Disable unnecessary services
- Disable unnecessary peripheral devices and removable media access
- Disable auto-run capability if removable media access is deemed necessary
Accessing sensitive information should be done in a secure manner – proper access controls should be in place – secure and robust authentication mechanisms, use two-factor authentication for sensitive access, encryption for data in transit and rest. Monitoring of how sensitive data is handled and transferred should also be in place.
Use endpoint protection mechanism (Anti-Virus, Anti-Spyware, Software, Firewalls) which support centralised management and can be integrated with your network security controls and monitoring tools. Regularly backup all important data in a safe manner (encrypt and secure data in rest in motion) – this mitigates the effects of ransomware attacks. In case of a breach, have a plan to restore normal network operations for different scenarios but also remember to include steps for gathering data for forensic investigations to take place in the aftermath.
5. Train your personnel
Users should be aware of the ideas behind the implementation of security
measures, what threats are out there and what should raise their suspicion – simple things like:
- Non-solicited mails with strange hidden links – aka “Think before you click campaign”
- File attachment with general but well-sounding names
- Plugging/connecting unapproved media or personal devices into the network
Users should undergo training on:
- How to handle sensitive information
- Social Engineering training and be aware of the techniques used
- Report any strange activities or security incidents
The training and development of personnel should be a continuous process not a one-off occurrence to ensure topics are relevant, minimise any potential threats and so staff training can be scaled.
6. Remote/Home Users controls
Access risks for remote corporate users and create a policy on how to mitigate their usage. Use strong/two-factor authentication. Educate remote users on the importance of security and how to work with all security control mechanisms without sacrificing productivity.
Create and regularly update manuals on how to use and configure different security controls (aka VPN Clients etc.) Have a support and escalation procedure in place – this is done so users can work with all security controls in place and do not try to circumvent them. Protect data in transit and rest. Use a common security build for all remote workers – more secure, easier to operate and troubleshoot.
We cannot stress enough on the importance of constant monitoring. No environment is bullet proof and buying best of breed products does not guarantee top level of security. There is a lot of factors in play in every complex environment that has many cogs and bolts. The only predictable aspect about security is the unpredictability of the threats they pose (for example the human factor or administrator laziness). A link as strong as its weakest chain. A company should concentrate on having all protection/prevention mechanisms in place but should never forget to have visibility and monitoring tools in place.
Detect attacks and abnormal behaviour – both from outside and inside attacks. React to attacks – in a timely response to stop the spread of damage, can ensure that the attack is blocked in the future and could assist with a forensic investigation. Account for activity – you should have a complete understanding of how systems run, and how data and information is being used by users. Only then will you be able to detect deviations from the norm and act on them.
8. Test, test and test!
The only way to really know your security level is protecting your organization, is to regularly test it!
Security tests should cover all parts of your environment and should be performed on procedures/processes, network equipment, endpoint systems and personnel.
- Formal security audits that look at procedures and if they are being followed/enforced
- Automated vulnerability assessments – usually performed every 2-3 months and done internally
- Penetration tests – external annual security tests that usually give the most accurate information for the company’s security posture and effectiveness of all security measures deployed
- Social engineering tests on personnel – attempts to get employees to discard sensitive information to none-authorised people either via phone or in person or to get physical access to company restricted areas.
- HLD – High Level Design
- LLD – Low Level Design
- IT – Information Technology
- IPS – Intrusion Prevention System
- SIEM – combination of the SIM (Security Information Management) and SEM (Security Event Management) abbreviations
- OS – Operating System
- AES – Advanced Encryption Standard
- BYOD – Bring Your Own Device
- Social Engineering – a method in Penetration Testing when the security experts are trying to exploit the human personality into giving out sensitive information that could lead to a breach in security
The traditional legacy ASA Firewalls (5505, 5510, 5520, 5540, 5580) are End of Life (EOL) and soon will be End of Support (EOS). There are still a vast number of ASA’s in the public realm used as a security device/internet edge firewalls where many companies think they are providing the necessary security, the reality cannot be further from the truth.
These older model ASA’s have the following problems
- Hardware Problems
Cisco ASA Firewalls have a Meantime-Between-Failure (MTBF) which is simply the predicted elapsed time between inherent failures of such devices. When legacy ASA’s are out of support it is not possible to renew support contracts as Firmware updates are no longer available, effectively making the devices EOL. Meaning they are a ticking bomb and without support any network can suffer significant downtime when the device gives up.
- Code Vulnerabilities
ASA updates are uncommon, occurring every 6 months or so, meaning security holes can appear with such a time gap between security patch updates. Effectively your device is vulnerable and unsecured whilst it awaits the next patch update. Currently legacy ASA Firewalls only run to version 9.1 updates. These vulnerability problems wouldn’t be a threat if default and most deployed scenario is an Internet Edge Firewall.
- Lack of new features
Cisco is not deploying any new features to the legacy ASA’s and the major version will probably not move away from 9.1 (when the newest is 9.6 for next generation Firewalls)
- Lack of real security
Any working firewall cannot only rely on the Stateful Firewall technology for protecting the assets of an organization. Legacy ASA’s can only run the legacy Cisco IPS with a separate module which cannot measure to the modern IPS technology. The new generation of firewalls have the Firepower functionality which is the industry leading IPS technology.
Challenges for migrating Legacy ASA to ASA X?
- Configuration migration
- Manual migration – Configuration between Legacy ASA’s and the new ASA X usually differs and cannot be simply copied and pasted into the new device. Different naming for interfaces and different features and functionalities means different syntax for the CLI.
Very often the legacy ASA’s run a pre-8.3 code due to RAM restrictions (RAM needs to be upgraded for post 8.3+ code). The pre-8.3 code is very different from today’s code in terms of syntax. It does mandate the obligatory use of objects, the NATs are the old PIX like fashion and any policies use the global ip addresses (the so called real ip addresses seen on the interface) than the original one (the ip addresses on the hosts). That means that large portions of the config need to be redone (in most cases manually) when you do the switch over.
The sections that needs manual work are: Objects, NATs, Policies and ACLs. That is the recommended approach and usually an experienced Cisco Security Consultant is needed to perform the job.
- Automatic migration is possible if the legacy ASA has its RAM upgraded (512MB for 5505 and more than 1GB for the other models is mandatory). Depending on the starting OS Image version several upgrades are done to ensure the device runs the latest 8.2.x code and then jump to 8.4.1. During that jump the device will automatically redo the configuration to its best (will shout out errors on console while booting if it cannot migrate certain areas of the config), it will create objects (with automatic names) and will deploy them.
During automatic migrations, there is always a chance that something will not work so the migration again needs to be performed by someone who understands the migration process, can track down and manually intervene to correct errors or add configuration after the migration. Also, the configuration after an automatic migration is not easily readable due to the creation of objects with automatic naming convention.
- Raising the security level – if you migrated from a legacy ASA to a new generation ASA X that supports other security technologies and Firepower then it makes sense to leverage new technologies and enable/configure/tune them. A blind one-to-one migration might give you more in the world of availability (new hardware, newer code, less code vulnerabilities and frequent code updates), but will not give you ultimately better protection for your assets. A deep packet inspection with content analysis is a must in the modern threat landscape. Implementing the Firepower technology is necessary but a complex step that needs to be done by people with the right skillset and experience.
- EOS / EOL announcement
Assessing the needs of MSPs, integrators and other organisations and the challenges they face when sourcing quality third-party professional project and technical services for Cisco technologies.
The United Kingdom voted to leave the European Union on June 23rd and we’ve heard all about the impact on International stock markets, multi-conglomerates, worldwide economies and not very much about the little guys – small businesses.
Much doom and gloom has surrounded the Brexit vote, primarily due to the multitude of legal and financial uncertainties. There is no doubt that the UK leaving the EU carries risks, but counteracting those risks are an equal amount of opportunities.
This blog will explore the influence of the Brexit vote on an SME in the IT sector offering Cisco Professional Services. We will objectively explore any negative and positive impact the Brexit vote has had on our company, our finances and business operations.
As a Cisco Professional Services organisation, 4CornerNetworks specialise in the provision of Cisco Engineers making our business model dependent on market prices in the recruitment of Cisco Engineers. We operate Internationally, often employing Engineers from the EU and USA where the performance of the Pound Sterling causes both negative and positive currency fluctuations.
Post Brexit vote in the UK caused major currency fluctuations on the Pound Sterling against the US Dollar and Euro. Let’s look at the currency fluctuations of the Pound Sterling vs the US Dollar and the Euro from June 23rd, the day of the Brexit vote.
£ Pound Sterling to the $ US Dollar
$1.48 to £1 23/06/2016
$1.33 to £1 03/08/2016
$1.29 to £1 08/07/2016 = 28.12% fluctuation from 23/06/2016
The pound reached its lowest point on 8th July trading at $1.29 to £1 and its highest point of $1.48 to £1 on the 23rd June resulting in a 28.12% fluctuation. Today the price is $1.33 to £1 where the fluctuation from 23rd June is 22.2%.
£ Pound Sterling to the € Euro
€1.30 to £1 23/06/2016
€1.19 to £1 03/08/2016
€1.16 to £1 06/07/2016 = 18.2% fluctuation from 23/06/2016
On June 23rd the Pound fluctuated by 14.3% against the Euro against today’s price of €1.19, and reached a low of €1.16 to £1 on July 6th resulting in a 18.2% fluctuation.
Price of Doing Business
The average salary of a CCNA in USA is $72,039. At the current exchange rate of $1.33 to £1 is £54,165. On 23rd June the exchange rate was $1.48 to £1 meaning the same CCNA Engineer would cost £48,675 which is a cost of £5,490 for the salary of a single Engineer. (source: http://www.payscale.com/research/US/Certification=Cisco_Certified_Network_Associate_(CCNA)/Salary )
A CCNA in Europe (Take Germany as an example) earns an average salary of €45,562. At the current rate of exchange €1.19 to £1 is £38,287. On 23rd June the exchange rate was €1.30 to £1 meaning the same CCNA Engineer would cost £35,047 which is a cost of £3,240 for the salary of a single Engineer (source: http://www.payscale.com/research/DE/Certification=Cisco_Certified_Network_Associate_(CCNA)/Salary )
However, fortunes are reversed when we receive payment from organisations in Europe or USA. If an invoice for $10,000 was received on 23rd June, this would have been worth £6,757 but the same $10,000 invoice today would be worth £7,519, a surplus of £762.
A €10,000 invoice on 23rd June would have been worth £7,692 but the same €10,000 invoice today would be worth £8,403, a surplus of £711.
The currency fluctuations can be equally negative as they are positive which results in the solidification of uncertainty and therefore a cautious approach must be taken when dealing with international clients, currencies and projects. Operating in volatile market conditions is a business challenge we must accept face on, but remain equally cautious.
Any International growth ambitions small businesses have must now be placed on hold, but for how long? Planning to set up new offices, employ new staff and trade internationally with multiple currencies fluctuating by up to 30% in a matter of weeks presents too many unknowns and a period of stability must be reached before the UK’s small businesses can shake off the shackles and grow. It all depends if you see the glass Half Full or Half Empty?
*Please note the rate of exchange is at 03/08/2016 and will vary