How can I calculate exposure factor?

You cannot calculate a Single Loss Expectancy (SLE) without an actual, historical, estimated, or guess-estimated Exposure Factor (EF). I think what is lacking in most INFOSEC Risk Management training materials that cover quantitative analysis, is that they don't give much guidance on how to translate the generic risk definition [risk = f(asset, threat, vulnerability)] into an EF and into the SLE and ALE formulas. I looked online just now, and I didn't see anyone that covered it well.

For a risk to exist there must be a vulnerability to exploit, and threats against that vulnerability. Those threats also have a probability of occurrence (which may be based upon observed attacks). The Threat Probability translates into the Annualised Rate of Occurrence in the quantitative analysis. So your EF mostly is based upon the vulnerability and its consequences to the asset when the threat occurs.

Many per-risk (meaning per-threat/vulnerability pair) EFs result in a 0 EF or a 1 EF which reduces some of the risk analysis workload. It also helps sometimes in doing EF estimation to also consider any mitigators what are put in-place to help reduce or eliminate the vulnerability.

• Some simplistic examples of trivial 0 and 1 EFs:
  
• Asset: an online-accessible bank account's balance
  
• Threat: Hacker employs fishing emails to get bank account logins to drain accounts
  
• Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
  

Mitigators: none

• Resultant EF to bank account balance: 1.0
  
• Threat: Hacker employs fishing emails to get bank account logins to drain accounts
  
• Vulnerabilities: HUMINT: account holder is tricked to revealing their userid & password
  
• Mitigators: bank does not allow external balance transfers to be initiated online; bank does not show account numbers or routing numbers online
  
• Resultant EF to bank account balance: 0.0
  
• Threat: Hacker uses recent lists of stolen userid/password from a social media site
  
• Vulnerabilities: HUMINT: many account holders use same passwords on all sites and AUTHEN: many sites (including this bank) use one's email address as a userid
  
• Mitigators: bank has in-place two-factor authentication
  
• Resultant EF to bank account balance: 0.0
  

For most other risks, one has to assess the vulnerability, the threat, and any vulnerability mitigators to decide upon an estimated EF. If one does not have a lot of real observed data to base the EF depending upon the risk, then these individual SLEs can be wildly out-of-line. When rolled up into aggregate Annualised Loss Expectancies, it could have a very large margin of error due to all the poorly estimated individual EFs. However, using the banking industry as an example, for a bank that has been in-operation for many years, they have detailed historical loss data (including cyber-related losses). A bank can actually calculate these values (EF, SLE, ARO, ALE) quite accurately for their history-to-date, and then use them for predictions of future losses. Also, given that detailed loss history, banks can do relatively accurate what-if cost-vs-benefit analysis of implementing new mitigators (such as two-factor authentication).

• Determine the total-cost estimate to implement and deploy that mitigator.
  
• Calculate the aggregate ALE given current EFs over a time period (say 10 years).
  
• Tweak any EFs that the mitigator affects.
  
• Calculate the new aggregate ALE over that same time period
  

Calculate the difference between the new aggregate ALE and the current aggregate ALE (which is the hoped for benefit in that the new ALE ideally be smaller than the current ALE) If the benefit (loss reduction) is greater than the total-cost to implement, then do so; if the benefit (loss reduction) is significantly less than the total-cost to implement, then cost-vs-benefit analysis would recommend not implementing the mitigator.