Secure Translations - Old Browser Support - Part 7 of Many

Is your service provider stopping old or unpatched browsers from using their application? Is your Language Service Provider delivering secure translations? Let us start with a browser support test. Open Google Chrome, go to your service provider web application and press Ctrl + Shift + J if you are on Windows/Linux or Cmd + Opt + J if you are on MAC OSX. When the Inspector screen shows up click on the three dots menu button on the right and click on More Tools, then on Network Conditions. Scroll to User Agent section, deselect "Select automatically" and pick for instance "Internet Explorer 7" as shown below:

Did you get a page stating that your browser must be updated? No? Then your service provider is not rendering secure services because it is supporting an old unsupported browser. Repeat this process for all user agents to verify that your service provider is delivering secure services. If you are using a Language Service Provider (LSP) that fails this test then they are not delivering secure translations to you.

Up until now (2019-01-30) there are over 100 reported vulnerabilities affecting Internet Explorer. Previously, in 2018 there were over 2000 Internet Explorer reported vulnerabilities. Six years ago I started supporting only the latest version of any browser including Internet Explorer and in that post you can see several issues related to security and cost associated with delivering software that supports insecure browsers.

There is a fundamental issue with Internet Explorer. Microsoft decided to embed it in the Windows Operating System, and that was a bad decision for two reasons: Exploits are closer to make a bigger impact in the affected system and upgrading the browser usually means that the user must also upgrade the Operating System. Therefore I would say that if Microsoft really wants to promote the use of Internet Explorer as a secure browser, then they should separate it from the Operating System and upgrade it automatically as soon as a critical flow is detected. Until then I would say use one of the alternative browsers in the market. I personally recommend Chrome just because of the tremendous investment in security that Google has put behind that browser.

The ENISA Threat Landscape Report 2018 reveals how serious IE issues are:

The trend of web browser based (drive-by) exploit-kits is continuing. According to Malwarebytes spring and summer report, the majority of exploit kits were observed in Asia. This might be related to the continued use of Internet Explorer (Japan, South Korea) in this part of the world. Apart from known browser type exploit-kits, researchers observed an increase in drive-by downloads labelled as “pseudo exploit-kits”. These type of exploit-kits typically miss a solid infrastructure and often result from a single malicious software developer/actor copy and pasting from leaked or POC-type exploits

In the topic of browser type exploits, Internet Explorer (CVE-2018-8174) and Flash (CVE-2018-4878) have been the most weaponised vulnerabilities for this type of web-based attacks

Even Edge is problematic, and Microsoft has announced its intent to use the Chromium project for their browser. Hopefully they will completely remove the browser from the OS. Until then I personally suggest to avoid using any Microsoft Windows supplied by default Browser. This will also make it cheaper to build web applications as the IE and Edge render issues do not need to be addressed.

This is the 7th post on my Secure Translation series, and this time I am discussing Old Browser Support related threat.

As usual, let us use our simple yet effective quantitative risk management framework to analyze this threat.

• Threat: Companies love to cast a wider net for which they tend to support any browser, even well known compromised versions.
• Asset: Web applications and all assets they handle.
• Vulnerability: Users behind old browsers will be compromised. These users are accessing company resources. Computers controlled by criminals can pentest these applications without being noticed, escalate privileges, access other users data and beyond.
• Risk: The impact of supporting an old compromised browser is high, only limited by the number of vulnerabilities that a logged in user can find. The likelihood of this happening is also high because usually exploited machines will be plenty of malware that hackers can control remotely. Therefore the risk is high.
• Safeguard: Do not grant access to any browser with vulnerable versions in your application. Force users to download non embedded browsers like Chrome which is without a doubt the safest browser in the planet at the time of this writing. Check browser support for absolutely all service providers like your LSP's online Translation Management System (TMS). Reach out to them to make sure they update their applications. An LSP that allows access to any of their services from an insecure browser cannot provide secure translations. While it is OK to cast a wider net in your corporate website be aware that marketing related forms could be a target for criminals. What will be a serious mistake is to allow old browsers to interact with the service. As explained in this post, change your user agent and try your current LSP with it and if they support an old version of a given browser be aware that they cannot provide secure translations.

In the next post I analyze the risk related to lack of training and in particular lack of internal hacking drills that truly educate employees on cyber-defense practices.

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.

Secure Translations - Privacy reminder on EU Data Protection Day - Part 6 of Many

Today is the European Union Data Protection Day and while there is a lot of GDPR related myth there are definitely good reasons to be alarmed about privacy breaches that apply for now only to European citizens and therefore to any international company dealing with them.

This is the 6th post on my Secure Translation series, and this time I am discussing Privacy breach related threats.

As usual, let us use our simple yet effective quantitative risk management framework to analyze this threat.

• Threat: Privacy breach.
• Asset: Any service where customer contacts, vendor information or staff information is stored.
• Vulnerability: Storing more user information than what is actually needed and/or for purposes not agreed by the user.
• Risk: The impact of keeping personal information for longer than needed or for purposes not agreed by the user is high for a business from a monetary perspective and reputation perspective. The likelihood of such breach happening increases with the miss understanding of what GDPR means for corporations. Therefore the risk can be medium or high depending on how truly ready the company is when it comes to GDPR compliance. Some examples shared by the European Commission are: Outbound marketing like Telemarketing and promotional emails can accidentally disclose personal identifiable information (PII), not reporting to the National Data Protection Authority (DPA) within 72 hours of an accidental disclosure, failing to secure user data (One or more European Data Protection Authorities or the European Protection Board itself will investigate your processes in deep), lack of user consent in processes the users did not agree to participate in.
• Safeguard: Use a security plan that adopts an existing well known framework like NIST or a combination of multiple frameworks. Make sure all your service providers including Language Service Providers (LSP) do have a SOC 2 Type II report (only a type II report matters here, do not go for less). Avoid storing any sensible information in marketing related platforms by using segmentation by IDs rather than actual PII. Use Data Minimization up front.

In the next post I analyze the risk related to supporting old browsers.

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.

Secure Translations - Security first, then Compliance - Part 5 of Many

Let me Google "Compliance is not Security" for you. Wow! That is a lot of hits. Of course the reverse is also true "Security is not Compliance". What is the big deal?

This is the 5th post on my Secure Translation series, and this time I would like to look into two common threats: Lack of Security first approach and lack of Compliance.

People hear me constantly saying "culture comes before tools" or "culture first, then tools" and this expression summarizes the answer to the "Compliance is not Security" debate. You need both, period. However you cannot be compliant without having security, neither you can be secure without compliance. Definitely "Security first, then Compliance" but do not interpret that as you do not need compliance. You need compliance to complement your security as much as you need tools to complement your organization's culture.

Let us go as usual through our effective quantitative risk management framework to analyze these threats.

• Threat: Not implementing a security plan and/or not adhering to compliance standards.
• Asset: Any service used to serve customers including those provided by your service providers like Language Service Providers (LSP).
• Vulnerability: Not implementing a security plan leaves critical resources vulnerable. Not adhering to compliance standards leaves the security plan unchecked.
• Risk: The impact of ignoring security and/or compliance is high for the business and the likelihood for any compromises increases to the roof. These threats are therefore at the top of high risk exposure for any business.
• Safeguard: Use a security plan that adopts an existing well known framework like NIST or a combination of multiple frameworks. Make sure all your service providers including Language Service Providers do have a SOC 2 Type II report (only a type II report matters here, do not go for less) to comply with the highest security compliance standards in USA and an ISO 27001 certification to globally comply with the highest international security standards. If your LSP does not hold these reports and certifications or if they just hold a certification and you are expecting to receive secure translations, you need to ask for their Information security risk assessment process, their Information security risk treatment process, the Results of the information security risk assessment, the Results of the information security risk treatment, the Evidence of the monitoring and measurement of results, their documented internal audit process, the Evidence of the audit programs and the audit results, the Evidence of the nature of the non-conformities and any subsequent actions taken, the Evidence of the results of any corrective actions taken. You need to check the credentials of the CPA firms that performed the audits, if they are authorized to perform these attestations, and whether they are providing attestations to technology leaders. Many LSPs will mention SOC 2 reports but all they are saying is that their services are hosted in data centers that hold such report. This is a major issue because they are per GDPR your processors and they should be the ones holding these reports to claim that they are providing secure translations. Other LSPs mention the existence of a SOC 2 report which is not updated annually. There are some LSPs that do have a SOC 1 or even a SOC 2 type I but those won't fit the bill. They must have a SOC 2 type II report for attestation that they produce secure translations. Do review the report, search for the exceptions found and how they are monitoring their service providers' SOC 2 Type II reports as well. Under GDPR they become controllers of your data when other third parties are in charge of hosting databases, files and system processes. If your current LSP does not proof they hold a SOC 2 Type II report look for one that does. If your LSP is not security compliant, such organization cannot provide secure translations. If your LSP does not have a robust security plan that includes internal and external annual controls, then such company cannot deliver secure translations. If an LSP holds an ISO 27001 certification you should ask for the statement of applicability (SOA) to validate that the Information Security Management System (ISMS) applies controls that address the type of risks that your company expects to see based on your own ISMS.

A note of caution here would be that if you have a strong internal audit department and the budget to incur in your own audits of your LSPs and their providers, then you might be able to make business with a non certified or non report holder however I would question the cost effectiveness of such path. Better to audit attestations than auditing full plans, policies and internal controls for several controllers and processors down the complicated hierarchy of service providers.

In my next post I discuss privacy breach threats.

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.

On Security - Quantitative Risk Analysis

Quantitative risk analysis is laborious but straightforward. The benefits for companies practicing it is huge as just subjective analysis might lead to far from ideal decisions.

Since I am mentioning risk analysis in all my Secure Translation posts I figured that I should have a dedicated post about how to get quantitative risk analysis in place.

Start with a simple spreadsheet that includes each affected asset name, the asset value (AV), the threat, the annualized rate of occurrence (ARO), the exposure factor (EF), the single loss expectancy (SLE=AV*EF), the annualized loss expectancy without a safeguard (ALE1=ARO*SLE), the annual cost of safeguard (ACS), the ALE after safeguard (ALE2), and the Value (Cost or Benefit) of the Safeguard (VS=(ALE1-ALE2)-ACS).

An objective analysis demands that we calculate the annualized loss expectancy of every asset accompanied by a decision about mitigation or acceptance of risk.

For example: If a printer used to send checks would break what is the impact to the business?

To respond this question record the asset value, let us say the printer costs $1000 and therefore that is the asset value (AV).

Let us say that this threat has an annualized rate of occurrence (ARO) of 2, which means that the printer could break twice in a year.

Let us say that the exposure factor (EF) will be 1, which means that there is 100% of complete loss of the asset value if the risk materializes (In USA the usual is to replace rather than to repair ... unfortunately).

The single loss expectancy is (SLE=AV*EF=$1000) and the annualized loss expectancy is (ALE=ARO*2=$2000).

To mitigate this exposure, the risk committee debates possible safeguards like for example going OPEX which allows a printer provider to guarantee a printer within 24 hours. Let's say that this agreement for the printer has an annual cost of safeguard (ACS) of $1000/year and that with it we totally eliminate the risk resulting in a new ALE2 of $0.

We then calculate the value of the Safeguard (VS=(ALE1-ALE2)-ACS=$2000-$0-$1000=$1000).

This is repeated with all possible safeguards and the company picks the one with higher number"

Of course this gets a bit more complicated because an investment usually protects multiple assets but I leave that part as a homework ;-)

Secure Language Translations - Part 4 of Many - Retention

As Google prepares to respond to the Commission Nationale de l'Informatique et des Libertés (CNIL) on the 50 million Euros GDPR related penalty and Bloomberg reports thousands of financial adviser client confidential data exposed by the largest asset manager in the planet , business leaders should ask themselves the question: Is my organization globalization plans backed up by secure translation, localization, internationalization, transcreation procedures? The fact of the matter is that without strong security there is no strong privacy and as a consequence there is no strong compliance. Without strong compliance there is a big business economic risk.

This fine, the biggest related to GDPR so far, should push the Organization Management and The Board of Directors to account for the privacy related risk into their strategy. We should understand the moral of this story through some quotes from the text related to this penalty, namely what can happen when "information about the retention period is not provided for some data", when "The relevant information is accessible after several steps only, implying sometimes up to 5 or 6 actions", when "Users are not able to fully understand the extent of the processing operations", when applications "deprive the users of essential guarantees regarding processing operations that can reveal important parts of their private life". The question for your current language service providers is how they are addressing privacy to deliver secure translations?

As I explained in my first post covering the need for secure translations, there are too many security fragile points when translating information. In my last post we saw the importance of dual factor authentication. Today we will examine why Privacy is so important using our, by now usual, simple quantitative risk management framework:

• Threat: Leaking of personal information. For example your Language Service Provider might use contact information in their marketing automation system, ERP, CRM, cloud storage, company website, and/or TMS which might result in a compromise of your expected secure translations.
• Asset: Any service that captures human related information is endangered by this threat.
• Vulnerability: Private information stored across multiple systems without centralized management. Retention policies applying only to part of the process. Your Language Service Provider can't guarantee secure translations if they are capturing personal information and backing it up without applying retention policies to the whole process. Similarly, not retaining data is as bad because ransomware might delay projects and in some cases make the information disappear. Add to the issues not providing a central location where information is kept like using different tools for TMS, ERP, CRM, company website, cloud storage and marketing automation. Finally not providing access to users so that they know how their information is used and not allowing them to easily be forgotten violates GDPR and therefore becomes a compliance vulnerability.
• Risk: Privacy of users of a system is compromised when related to them data is known beyond the context where it is useful for serving such users. Such information should never be shared beyond the scope the user is aware of and given explicit consent for. The disclosure of such information is a liability for service providers. Tools exist that can compromise internal systems, encrypt valuable information and ask for a ransom in order to decrypt it (ransomware). In addition, tools exist that can collect information and in an automated way come up with a strong profile for a user, provided that the raw information about such user is fed into the tool. This information can become available only if it is stored and later compromised. It can be used in several fraud related attacks. The more systems this information is present the higher the likelihood of a successful attack happening. The impact is severe. Overall this poses a big risk for Companies reputation and financial stability. If your Language Service Provider is delivering secure translations then their translation process should be transparent and audited by an external recognized/authorized CPA firm.
• Safeguard: Use centralized management for information and retention policies that apply to production data and backups. Both. If your current Language Service Provider (AKA LSP) cannot guarantee the applicability of a retention policy in backups and in production data they cannot provide secure translations. If your current LSP does not offer a consolidated file storage for confidential ad restricted information and instead uses their corporate website, out of the box cloud storage or a plethora os systems be aware, they cannot provide secure translations.

I will leave the always helpful STRIDE threat modeling framework to the user. You can look at any of my previous posts for some examples on STRIDE.

In my next post I will look at the threat behind not implementing a security program and/or not getting an external audit to obtain a USA compliance report and/or an international certification.

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.

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. Below is the analysis of the risk related to the lack of 2FA using a simple quantitative risk management framework.

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

In my next post I analyze Privacy and in particular data retention combined with user rights.

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.

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.

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