Encryption requirements over carrier/WAN circuits

The only way you can really enforce this is if you have control over both ends of a circuit.

If you do, then you might choose a hardware of software implementation.

Normally TLS encryption is sufficient + there may be requirements for a certain level of cipher to use.

Refer to any HIPAA or MIL specs or any other specs required by both producers + consumers using the line.

The main point about HIPAA is it's easy to secure a line + becomes very difficult to control outside the line.

For example, let's say someone sends an email over a HIPAA encrypted line, from one end to the other. If the email must leave the HIPAA encrypted connection to reach it's final destination, then you'll configuring your outgoing MTA to only connect to other MX records which enforce Opportunistic TLS connections... In other words, you must ensure your email only moves between MTAs as encrypted.

If there's ever a chance of additional delivery past the MX endpoint, then you'll use S/MIME to actually encrypt the message.

Figuring out every detail of any encryption compliance is complex.

There is no... one size fits all solution... Each enterprise + related workflow is best analyzed, then infrastructure built to support all compliance guidelines.

Tip: None of this requires point to point networks. For example, if you use HTTPS + IMAP4S + S/MIME with strong ciphers, you'll accomplish compliance easily... in a few hours, rather than weeks or months of tooling.

@David Favor

Thank you for the great/quick response. I do have some follow-up questions, of course.

I understand that you can attack it at an application level, and also that encrypting a path requires every hop of that path. What they're currently looking at is encryption at the infrastructure level (at least currently for the MPLS network) by having firewalls at each end with IPsec tunnels between the locations. Thus, everything would be encrypted while traversing the L3 VPN WAN.  (Again, I understand that once the traffic extends beyond the tunnel, you'd have to deal with it separately.)

That said, two questions:

- Is the above a bad approach for some reason (vs. dealing with it at the application level)?  One challenge is sizing around the traffic requirements, of course.
- If the above is a "normal" solution for satisfying this requirement, have you found that it seems to be less of a concern regarding "dedicated" links (such as the P2P DWDM) vs. inherently multi-tenant (MPLS)?

I'm just curious what's been seen in the field more often, as I'm fairly new in dealing with these types of requirements.

Thanks again

Coming from a shop where this was a normal conversation (and it was always repeated with each new project/customer), I can say that the two methodologies that we attempted to stay within (regarding securing the path) were either IPSEC tunneling or (more recently) SD-WAN.  On private circuits we normally used IPSEC and on public infrastructure we pushed for SD-WAN.

Tunneling presents the advantage of being vendor agnostic (though cross vendor inter-operation can be challenging).

SD-WAN presents the opportunity to control both anchors of the path (source agnostic) and pass traffic directly to the customers security domain, over IP.  The down side is customers can be more resistant to the idea and may need more coaching to get over the hump.

@atlas_shuddered

Thanks for your input as well. I understand the tunneling vs. SD-WAN stuff, but let's focus on the following:

• It's assumed the customer is requiring encryption for their MPLS circuits.
• They also have dedicated optical DWDM circuits between their sites.
• They also have DCI (through us, their DC/carrier) between data centers via optical.

I'm looking for input regarding potential compliance requirements (and maybe more specifically how other customers are dealing with this) for the 2nd/3rd bullets.

Thanks again for your patience and input.