Friday, January 18, 2019

Secure Language Translations - Part 3 of Many - Lack of 2FA

"Ensure that subcontractors have vigorous data protection systems in place" says FINRA. In the meantime Troy Hunt has found 773 million records leaked in the dark web. We are all hurrying to find out if our emails are perfectly owned (pwned) by hackers or find out if our current preferred password is already known by criminals.

This is the third post in my Secure Language Translations. In my previous post we analyzed insecure DNS Resolution related issues. Today we will look into what you should ask your language service provider and the service providers they use in terms of their defense in place for identification (the act of being identified as a valid user by means of an ID) and authentication (the act of providing a secret to be granted access to a system). We will not discuss authorization (the act of giving you permissions in the system) today but you bet we will in the very near future.

  • Threat: Criminals can interact with services posing as authorized users just because they manage to get a hold of the credentials of another genuine user. Your hope to receive secure translations goes away as hackers get access to the otherwise sensitive, confidential or restricted files.
  • Asset: Any service that relies on a password to grant access to the functionality it provides.
  • Vulnerability: Services that validate just something that you know like a password because what you know is probably known by others as well.
  • Risk: Tools exist that can be used to figure out emails and passwords in use by those email addresses. The impact is high and the likelihood for it to happen in beyond medium. As a result this is without question a hight risk.
  • Safeguard: In addition to the usage of a password, enforce the use of multiple factor authentication (MFA) in your services. Just by adding an additional second factor authentication (2FA) is enough. This second factor authentication must not be also something that you know (like your password) but something that you have (like a phone), or you are (like fingerprint or retina scans). Sending a token to your email is not 2FA.
Why secure translations are mission impossible if this threat is not mitigated? Let's look at the STRIDE model:
  1. Spoofing can occur. Authenticity is compromised. The criminal can do whatever it is that you can do.
  2. Tampering can occur. Therefore Integrity is compromised. The bad guy can modify data.
  3. Repudiation can occur. Non-repudiability is compromised. The service sees you, a valid user that has provided valid credentials.
  4. Information disclosure can occur. Confidentiality is compromised. The criminal is not only accessing the service, they are most likely collecting and storing information.
  5. Denial of Service (DoS) can occur. Availability is 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. They might even create new users depending on the original user privileges. 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. The criminal knows now more from the system so other exploits might be on the way.


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.

Saturday, January 12, 2019

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.

  • 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.

Monday, January 07, 2019

Install Google Chrome in Ubuntu or Debian Desktop

Search "Install Google Chrome" and download the deb package locally. Assuming it downloads in the default ~/Downloads directory:
cd ~/Downloads
sudo dpkg -i google-chrome*
sudo apt-get -f install

Followers