Secure Translations - Business Email Compromise (BEC)

This subject is sticky for two months for a very good reason. Training is mission critical, mastery is a must and Paranoia is the only effective defense. Trust but verify! Untrained Employees are the biggest security risk for the modern enterprise.

Just Google "business email compromise real case studies" to understand the raise of successful Business Email Compromise (BEC) scams and why proper employee training and auditing for such training pays off big time.

With so many language service providers (LSP) you should look for the ones that have invested smart (and not just hard) into security. Without smart employee training language service providers cannot deliver secure translations. Globalization demands translations but if they are not secure then you better stay local.

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

Secure Translations - Employee Training - Phishing - Part 8 of Many

Security Drills like Ethical Phishing Attacks are a must-do to keep digital assets secure.

This immediately poses the question: Are you and your service providers training users on cybersecurity? We need employees to master security, not just to be aware. The employee awareness programs that most auditors are after are a good start but not enough to make sure that your employees act as a trusted line of defense. Trust but verify! With successful Business Email Compromise (BEC) scams on the raise Paranoia is the only effective defense.

This is the 8th post on my Secure Translation series, and this time I am discussing the lack of strong employee security training.

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

• Threat: Companies are tempted just to check the box when it comes to employee training as part of regulatory compliance. Unfortunately, just caring about compliance is not the same as caring about security.
• Asset: All digital assets are at risk when employees are not highly trained on security issues.
• Vulnerability: Users with access to confidential information do not truly know how to combat security dangers like phishing.
• Risk: The impact of any single employee not knowing how to actively fight threats like phishing is the highest security risk Companies face today. The likelihood of this happening is extremely high with attacks getting so sophisticated that even information technology professionals fall for phishing scams nowadays.
• Safeguard: Actively craft your own internal ethical attacks, collect statistics like percentage of employees that are failing to identify threats over time, share the statistics openly, help personally those employees that are having trouble with recognizing threats. Make sure not a single user is left behind. Work with the staff, vendors and even contacts for mastery and not for punishment. Do not just ask for audit reports and certifications from your service providers, but in addition ask them for the specific employee training program and proof that such continuous training is happening. Furthermore demand proof about ethical hacking drills performed internally. A service provider like a language service provider cannot provide secure services like secure translations, unless they have a highly qualified cybersecurity program in place. If a single employee or vendor falls for phishing attacks for example, such provider cannot provide secure services. If such providers do not have in place an ethical hacking drill program, they cannot keep your information safe.

The reason why my series are about secure translations is that the processes being used today to translate documentation for international Corporations are in hands of users that are most likely not well trained. If your organization has trusted translations to Language Service Providers (LSP) that do not have strong continuous employee mastery-training programs, then your risk of data loss is high, no matter what such providers promise. If your LSP is not training users for security mastery, then such Language Service Provider cannot offer secure translations. They might sell themselves as secure translation providers but the devil is in the details. You are ultimately in charge of requesting proof that your content is handled by employees and vendors that master the art of fighting cybercriminals, of being cautious, of being knowledgable. This requires constant training and testing. This is serious cybersecurity matter.

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.

Cyber Threat Intelligence (CTI) Program

Does your organization and all your service providers have a Cyber Threat Intelligence (CTI) Program?

In other words what is the ability of your organization and your service providers to prevent cyber attacks?

Despite the little typo, the The 2018 ENISA Threat Landscape Report outlined CTI program representation in the picture is a starting point to consider reading the rest of this document that coverages current threats and safeguards that you should consider when going through quantitative risk management.

While we want security first and then compliance, both are as important. To achieve a high security maturity level we need to look at the strategy (compliance), tactics (ways to compile intelligence), operations (tooling), and technology (secure DevOps and SDLC practices).

My series about secure translations is actually applicable to any kind of service providers but naturally, based on my current role, I am concerned about the impact of globalization in security and privacy. I am particularly concerned about the modus operandi practices currently being used by multiple top Language Service Providers (LSP).

It is worrisome to see claims about security in LSP corporate websites that tend to deceive customers. For example the claim that they hold security reports and certifications pointing to the hosting providers they use. Let us make this clear, security is not reached because you ride on a mature hosting provider. Instead, security is a journey that an organization decides to make and that must cover internal strategic, tactical, operational and ultimately technical/logical areas.

If you are an international organization executive you should be aware that the biggest cyber-risk faced by your organization lies on the fact that your LSP of choice cannot deliver secure translation services. All efforts around internationalization, localization, trans-creation and therefore globalization might be actually compromising your bottom line.

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.

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.

Are your web security scanners good enough?

Are your web security scanners good enough? Note that use plural here as there is no silver bullet. There is no such thing as the perfect security tool.

More than two years ago I posted a self starting guide to get into penetration testing which brought some interest for some talks, consultancy hours and good friends. Not much have been changed until last month when in the Google Security Blog we learned that a new tool called Firing Range was been open sourced. I said to myself "finally we have a test bed for web application security scanners" and then the next question immediately popped up "Are the web security scanners I normally use good enough at detecting these well known vulnerabilities?". I would definitely like to get feedback private or public about tool results. For now I have asked 4 different open sourced tools about the plans to enhance their scanners so they can detect vulnerabilities like the ones Firing Range exposes. My tests so far are telling me that I need to look for other scanners as these 4 do not detect the exposed vulnerabilities. I have posted a comment to the Google post but it has not been authorized so far. I was after responding the main question in this post but then I realized that probably if everyone out there run their tests against their tools (free or paid) we could gather some information about those that are doing a better job as we speak in terms of finding Firing Range vulnerabilities. Here is the list of my questions so far:

1. Can anybody share results (bad or good) about web application scanners running against Firing Range?
2. Can anybody share other test bed softwares (similar to Firing Range) they are currently using, perhaps a cool honey pot for other to further test scanners?
3. Skipfish: https://code.google.com/p/skipfish/issues/detail?id=209
4. Nikto: I is a Web Server Scanner and not a Web Application Scanner https://github.com/sullo/nikto/issues/191
5. w3af: https://github.com/andresriancho/w3af/issues/6451
6. ZAP: https://code.google.com/p/zaproxy/issues/detail?id=1422

Web Vulnerability Scanners

UPDATE 20141203: I have posted recent findings about the security scanners mentioned in this post since a new open sourced test bed tool from Google called Firing Range has become available. With this tool we at least have a least of vulnerabilities we can test against to evaluate the vulnerability coverage in terms of Web Application Scanners. Note that nikto is a Web Server scanner which means it does not get into application logic vulnerabilities. When you are performing Penetration Testing usually the first tier you will want to address is that HTTP(S) web URL that you have exposed to the outside. Please do your Business a favor and perform an ssl test as your very first step).

Low budget companies usually opt for relying on software developers to take care of this area and while that can be an apparent cheap path and definitely it is indeed better than nothing be aware that this is like investing in a Fund where no external accounting is performed, where is the Audit really?

A company risks too much if it decides to go without a BCP or DR plan, right? A company without a PenTest plan is risking as much or probably more.

PenTesting is not difficult when you know the Web protocols and languages. Most likely your developers, devops, sysadmins know them. The problem is that it is a time consuming task that demands not just knowing protocols and how to use the tools but also a lot of reading, research and community interaction. As usual certain passion for this job is a must have for the team in charge.

Here are some guidelines for an in house security team. Note that I strongly recommend to reach out professional service in this area however at a minimum there should be pentest done yearly and if you ask me it should be integrated in your delivery pipeline. Every time you are ready to deploy you run automated large (AUAT/E2E) tests don't you? So why not using a proxy like ZAP to inspect for vulnerabilities out of those tests?

I hope this will be useful for others starting on the PenTest arena. The site seclists.org has been my home page for some time now and I can tell you the more you read the more you realize how little you know about protecting your applications.

Here is the list of those tools I have been using so far as Web Vulnerability Scanners. Note that they complement each other. The fact that I use them all is because some of them will report issues the others won't. An extensive list of these are found on OWASP site and even compiled in Linux Security distros like BackTrack distro.

1. SkipFish: After running the below command (custom for $site) several warnings/errors are provided starting at output_${site}/index.html. As usual some of them are false positives but everything must be inspected. Sometimes big vulnerabilities lie on "info" level warnings:

   ./skipfish -S dictionaries/complete.wl -o output_${site} http://${site}
   

2. Nikto: Installed with simple apt-get in ubuntu you use the below to scan the web app. Press "v" once the app starts to get verbose information:

   nikto -h $site -o ~/Downloads/nikto-${site}.html
   

3. w3af: Use just the w3af-gui providing the URL and checking for OWASP TOP 10 configuration for a start. Look at the results tab after even though from command line you get all information you need as well.

   git clone --depth 1 https://github.com/andresriancho/w3af.git
   cd w3af
   ./w3af_gui
   

4. OWASP ZAP: Run an "active scan" just starting the app and pointing to your URL:

   ./zap.sh
   

   Run a "passive scan" out of your automated tests. This is the most powerful test of all and while it can come out of manual interaction with your application the real power of it comes out of your automated users acceptance tests (AUAT) AKA end to end (E2E) tests. This is yet another example of a must have for UI automated testing. With that in place you can assert vulnerabilities related to common user interactions with the system. You need to turn on the proxy in your browser. Chrome uses the system wide proxy capabilities so for example in Ubuntu you will proceed as below to configure all HTTP traffic including local to go through the proxy, that way ZAP will be able to search for vulnerabilities.

PenTest Weekend Conclusions

False positives: These are common for any of the tools you use. In some you will notice errors about PHP (modules.php) and ASP (members.asp) resources which do not exist as you are running a J2EE app. Some false positives are related to redirections to the login form for example.

No Silver Bullet: w3af was the only one detecting clickjacking threats this time. I am happy it found something as my latest usage of the tool was almost telling me I could live without it.

Proxy interceptors: Of those available in the market free like in beer the OWASP ZAP is the one that has given me better results so far.