Is it common practice for companies to MITM HTTPS traffic?
Is this common practice in big companies?
Yes. The feature is available in most enterprise firewalls and also several firewalls for smaller companies. It is even available in the free web proxy Squid. And several personal firewalls have implemented it too.
As more and more sites, (both harmless and harmful), move to https://, expect that the usage of SSL interception will increase too, because nobody likes to have a firewall which fails to protect a system because it is blind regarding encrypted traffic.
Can someone point me to an ISO standard?
SSL interception just makes use of the existing SSL and PKI standards. There is no need to have a new standard which defines how SSL interception works.
As for the Cyber Security Standards: I'm not aware of any which explicitly require SSL interception, but I don't have much knowledge of these kind of standards. But even if it is not explicitly required it might be implicitly expected that you either block access to a SSL site or do SSL interception when the standard demands traffic monitoring.
will give me a certificate error.
SSL interception needs you to trust the intercepting CA. In most companies these CA certificates are centrally managed and installed on all computers, but if you use a browser like Firefox it might not help because Firefox has its own CA store and does not use the systems CA store.
To me this is hurting security in one area to help it in another.
Yes, it is breaking end-to-end encryption to detect malware and data leakage which use encrypted connections. But since the breakage of end-to-end encryption is done in full control of the company and you still have encryption to the outside world this is a trade off most companies are willing to take.
But note that in the past bugs were detected in several SSL interception products (like same CA between different companies, no revocation checks...) which additionally weakened the security.
This practice is becoming more common as organizations try to control things more, and as manufacturers market features to be able to spy on user activity.
To me this is hurting security in one area to help it in another.
Yes, but this MITM may be hurting security in an area that the organization doesn't care about (like being decent to employees/customers/etc.) in order to focus on an area that they do care about (like being able to be controlling).
Presumably, you can stop getting those web browser errors by installing a certificate published by your company. This can expose you to problems, as I note in chat room about college requiring SSL certification. In that case, the certificate was from Cyberoam, which had this vulnerability: "It is therefore possible to intercept traffic from any victim of a Cyberoam device with any other Cyberoam device - or to extract the key from the device and import it into other DPI devices". (DPI="Deep Packet Inspection") Therefore, installing that certificate is not recommended.
A better option is to simply not browse the web when connected to the VPN. Not browsing the web may be inconvenient: the workaround is to minimize time connected to the VPN. Briefly use the VPN for only the sensitive communications that need to be encrypted, and then stop using it. If that gets to be too inconvenient, then report the troubles. If there are sufficient complaints, perhaps the VPN will be perceived as being too troublesome with the current policy, which can lead to people considering a change in the policy.
Per some other comments (like one by Arlix), ISO might not provide any standards about this. However, a standards organization that has responded is the IETF, which noted this "Best Current Practice" document: IETF BCP 188 (currently RFC 7258: "Pervasive Monitoring Is an Attack"). This might be your best bet if you're looking for an official resource describing why this should not be done. Companies performing this MITM attack are not being standards-compliant.
Please bear in mind that the two greatest roadblocks to the adoption of SSL Intercept features are the following:
Corporate or Public privacy requirements (Policies) - you will want to ensure that whatever SSL intercept solution you go with allows for policy based (URL categorization and whitelist features) to ensure that you can excempt sites that you will not want to be monitoring. Banking is a great example, do you want obe liable if your network or device is hacked and employee/friends banking credentials are compromised? Consider archive and compliance requirements as part of that discussion.
Future SSL changes - aka certificate validation. Example - Many website are going to be moving to certificate verification in code. This is where the website checks to ensure that the certificate that the client is using actually matches the certificate that it send. This completely breaks almost all SSL Intercept implementations that perform MITM as a core functions. Future standards changes or industry best practice like this may impact you spend or even viability of SSL Intercept.