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

Monday, December 24, 2018

Secure Language Translations - Part 1 of Many

"The language Industry is Big Business". It is an Industry that undeniably will continue to grow as the Fourth Industrial Revolution continues to unfold. And the bigger this Industry gets, the more vulnerable it will be.

Are current Language Service Providers (LSP) really secure? Are your translation vendors (linguists) offering secure translations? Is your company sensitive, private, confidential and proprietary information being translated by secure processes, partners, employees and vendors?

Even if you have a strong background check and do business only with security diligent vendors your risk exposure might be way bigger than what you can imagine. The investment to provide secure translations is not little.

Let us see some security challenges with a non comprehensive list:
  1. No company can completely control a personal device used by a vendor unless a significant cost is incurred in Mobile Device Management (MDM) software. Add to it the transaction costs related to vendor agreements to deploy the MDM in their own machines. Add the local regulations under which those vendors operate, and the MDM related liability in terms of privacy (MDM controls the remote device from head to toes). Add the IT support you must put in place for vendors under MDM. This cost will go beyond the usual profit behind today's translation services prices. Can a company provide secure translations without incurring in the high cost associated to MDM?
  2. Data kept in an end user computer, even if encrypted under current best standards, can be stolen when such device is for whatever reason in the hands of a criminal. Will an LSP be able to provide secure translations if linguists are using their own devices?
  3. Devices break and need to be repaired so unmanaged technician devices will end up with copies of your data at their disposal.
  4. Encrypting data is not as easy as some might think. Without proper key management the best encryption in the world is as good as plain text. You cannot trust end users to manage encryption of your data and therefore you can't trust them to deliver secure translations from their own devices.
  5. Everybody backs up data without looking at retention needs. Retention must apply to daily work related data and backups as well, but most backup software is not prepared to cherry pick what to delete. As a consequence even when your data is deleted from operational systems, copies of it are still accessible from backups. Without a sound retention policy, secure translations can't exist.
  6. Is deletion even enough? We know for sure it is not because of data remanence so who will take care of real data purging? If there is a chance of data remanence any offered secure translation is just a wishful thinking.
The last mile of translation (the linguist device) is the most vulnerable and yet the most overlooked security issue in millions of insecure translations that are today performed across LSPs and linguists owned servers and devices.

Companies' hosted translation services are also at serious risks. Last year we witnessed contracts and passwords publicly available because of miss handling of confidential information.

Some might claim the usage of Secure Socket Layer (SSL) as proof of security due diligence and due care when the protocol implementation is actually insecure. Furthermore, data must be protected not only in transit but at rest and in use. SSL which in reality should not be used because it has been superseded by Transport Layer Security (TLS) just protects your data when in transit. Some believe that just using SSL and having the green lock in the browser is enough. You need to look under the hood. Finding common vulnerabilities on SSL/TLS for any website is actually quite simple: Just hit SSL Labs Server Test to start right now if you wish. You will be surprised to see how many LSP portals and online translation management systems (TMS) out there do not have an "A+" rating. Of course the question is, why some fail to protect the most basic entry point to your data? Security of data in transit therefore should not be taken for granted.

It requires a big deal of key management procedures to make sure the encryption keys do not fall in the hands of unintended recipients to guarantee that such encrypted storage is actually secure. It requires serious backup and restore considerations before you can be completely sure that your data is not actually exposed. We must not forget big leaks related to poor encryption and bad media destruction practices. Security of data at rest should not be taken for granted.

Not less effort is required from applications and users that are authorized to read in plain text any confidential data that is encrypted in transit or at rest. Application logs containing sensitive data are way more common than what you would like, and applications that show intrinsic logs containing sensitive data are not unheard of. Data in use protection demands strong security-first architecture rarely practiced even in the most regulated environments. Most LSP own or lease technology that exposes functionality via Application Programming Interfaces (API) through which intimate details could be exposed as we have all seen in the news recently. Security of data in process should not be taken for granted.

You cannot expect your translator to be a security expert but you can create secure environments. Unfortunately to do that you will need to have at least one security expert on board because it is not enough to just check for the existence of reports and certifications. The devil is in the details. Here is a start:
  1. Have comprehensive internal information security policies (ISP) that align with your business objectives
  2. Ask your LSP for their ISP and make sure they comply
  3. Ask your LSP for their internal organizational service controls (SOC) and confirm the ISP is covered by such controls
  4. Ask your LSP for internal audits on their SOC including results showing material evidence of such audit being conducted. Confirm the controls comply with your expectations about security
  5. Ask your LSP for an external audit on their SOC by Certified Public Accountants (CPA) in the form of a SOC 2 type II report. Confirm that the report complies with your expectation about security. For example you might be concerned not just about the security principle but also confidentiality, integrity, availability and privacy principles. You want to assert your LSP third parties like cloud providers do have a SOC 2 type II report and that it is periodically reviewed. You want to make sure there are SOC 2 Type II reports in the whole chain of providers. Do not go for less like SOC 1, SOC 2 Type I or SOC 3 reports. It is your right to know who handles your data and how it is handled
  6. Ask your LSP for an ISO 27001 certification. Since this certification does not come with a report then ask them for the following documents: Information security risk assessment process, Information security risk treatment process, Results of the information security risk assessment, Results of the information security risk treatment, Evidence of the monitoring and measurement of results, The documented internal audit process, Evidence of the audit programs and the audit results, Evidence of the nature of the non-conformities and any subsequent actions taken, Evidence of the results of any corrective actions taken
  7. Ask your LSP for the names of individuals in charge of handling security and check their credentials
What about real practical examples of what a secure translation process should be like? What features should a secure TMS have across its whole infrastructure and architecture design, its software development lice cycle (SDLC), its end user interface (UI) and its API. In Part 2 I start analyzing risk management frameworks and threat modeling through a real life attack example. In further parts I will continue with top measures you cannot live without as a start when it comes to protecting highly sensitive information.

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.

Wednesday, December 19, 2018

Android Bluetooth Setup

  1. Turn on Bluetooth device and make sure it is not connected to any other device
  2. Go to Settings in your Android
  3. Search Settings for (or select the option if found): Connected Devices
  4. If the device was previously connected, then select "Previously Connected devices" and select the Bluetooth device from the list
  5. If the device was not previously selected, then select "Pair new device" and connect to it
  6. If the above does not work restart your Android, turn off the Bluetooth device and start all over following this guide

Friday, December 14, 2018

kubernetes pod in terminating state forever

kubectl delete pod  --force --grace-period=0

Sunday, October 14, 2018

NodeJS cleanup: clean cache or delete node_modules

From time to time node_modules accumulate changes that either delay execution or even make the program miss behave. It is a good idea from time to time to clean cache:
npm cache clean --force
Or perhaps better
rm -fr node_modules && npm i
Here is one of those cases I found that this procedure helped with. Note that this is not to say the below issue will 100% of the time be related to uncleaned node_modules:
(node:25899) UnhandledPromiseRejectionWarning: Unhandled promise rejection (rejection id: 1) (node:25899) [DEP0018] DeprecationWarning: Unhandled promise rejections are deprecated. In the future, promise rejections that are not handled will terminate the Node.js process with a non-zero exit code.

Followers