Secure Language Translations - Part 2 of Many - Risk Management Framework - DNS Resolution

Our businesses depend not only on the security we deploy but on the security of dozens, hundreds or thousands of third party providers our organizations operate with.

Language Service Providers (LSP) process every day sensitive information belonging to international corporations and citizens. How linguists work on translations matter. As I explained in my first post covering the need for secure translations, there are too many security fragile points when translating information.

If I would be deciding what LSP to choose, I would start by asking a simple question: Please, explain your current risk management framework related to handling my information. As a result, I would expect to see a security in depth deployment across the translation process, data stores, data flows and trust boundaries that apply to my data.

If the LSP aligns with my corporation risk management practices, then I would ask for a list of all service providers such LSP is using to process my data. Note that this is a problem as big as the path that any sensitive information might take at any given time. This is specially important in the European Union where the General Data Protection Regulation (GDPR) makes it clear that there is a chained responsibility through the concepts of controllers and processors. Without strong compliance, secure translations are not possible.

Finally I will ask for proof of due diligence and due care. In other words I would request to see security tagged issues in their ticketing system. A quick review should reveal the kind of issues addressed in a certain period of time, and more importantly if the mitigations protect the information path for my sensitive data. Security related tickets should be correctly tagged not only for quick audit but also for trend and post-mortem analysis. If an LSP provides secure translation services their internal and external audit should be performed at least once a year.

I will take one issue at a time in my Secure Language Translations articles to educate on current threats, vulnerabilities, exposures, risk, and safeguards to assets for companies and organizations.

Today I am presenting the absolute necessary need to use secure domain resolution, through the use of a simple quantitative risk management framework.

• Threat: Man in the Middle (MITM) attacks allow an intruder to be in the middle of a communication between a device, server or desktop that tries to find out where a particular service identified by a Uniform Resource Locator (URL) like https://amazon.com is actually located based on its corresponding Internet Protocol (IP) address. The domain in the URL (amazon.com) is all the device, server or desktop knows. They query domain name resolution (DNS) servers for the mapping from the known URL to the IP. You might think you are talking with amazon.com when you are actually speaking with an intruder. We cannot speak about secure translations for a company that does not enforce DNS over TLS across all services related directly or indirectly to the translation process.
• Asset: Any service that relies on DNS in endangered by this threat. This concerns literally all your digital assets.
• Vulnerability: Usage of any DNS server that does not support encryption.
• Risk: Tools exists that can deploy a MITM attack. The likelihood of it happening is directly proportional to the size of the digital path from any device requesting DNS to the DNS server. For example, a device, server or desktop requests the real IP for amazon.com in clear text and therefore it can be read by anybody that gets access to such communication. A criminal could, therefore, intercept the communication and send the requestor to the evil service which posing as the authentic service can escalate the attack to gain access to the current service and beyond.
• Safeguard: Use DNS over Transport Layer Security (TLS). Change DNS to point to Cloudflare DNS, or Google DNS or any other DNS over TLS provider. Install Stubby in network devices, servers and desktops that manage sensitive information. Make sure all devices, no exception, that can access restricted information are managed and hardened (using DNS over TLS exclusively). Make sure from such devices there is no access to any possible leaking channel.

If you use the STRIDE threat model you will quickly realize that secure translations are impossible mission in your current system should you (or your service provider like your LSP) opt to ignore this threat:

1. Spoofing can occur. Authenticity is compromised. The MITM attack allows the criminal to forward your requests to the right site and at the same time keep track of your actions.
2. Tampering can occur. Therefore Integrity is compromised. At any point your actions can be replayed, enhanced and modified.
3. Repudiation can occur. Non-repudiability is compromised. The service sees you, a valid user that has provided valid credentials. You are just coming from a different (criminal handled) IP. Even your second factor authentication won't help. Only IP protection could help (to certain extent).
4. Information disclosure can occur. Confidentiality is compromised. The criminal is not only sniffing your request and the responses from the genuine service, they are in fact storing that information for further analysis and distribution for money, for pride or even for fun.
5. Denial of Service (DoS) can occur. Availability is compromised. This is perhaps the most complicated one to understand because after all a unique device, server or desktop was compromised. A DoS attack can occur against the service provider because the criminals know more about their system. They have after all valid credentials now. As a result they could come up with other exploits to more internal vulnerabilities through penetration testing tools and manual skills they do not lack of.
6. Elevation of Privilege might occur. Authorization might be compromised. This is definitely lower likelihood but not an unheard of. Again, the criminal knows now more from the system so other exploits might be on the way. Note that password reuse is problematic here. The man in the middle knows your password for a service and there might be other services using the same credentials.

In the United States the National Institute of Standards and Technology (NIST) Management Framework helps to secure your data including your translation related source and target files. Are you and your service providers including LSPs using this or another similar framework? I suggest to inquire your departments to understand who your service providers are, ask them what they do, audit them, and make sure they do the same with their own service providers.

In the next post we will discuss the value of dual factor authentication (2FA).

You can follow the "Secure Language Translations" series in this blog, on linkedIn, Twitter or Google+. My objective is to educate executives and managers but also to help engineers in reducing the organization risk through sound security measures.