Engagement Insider Threat

2021-11-15

Warning: Contains spoilers for the season 6, episode 5 “Tethics” of the show Silicon Valley which aired in 2019.

In “Tethics”, two managers of Pied Piper, Gilfoyle and Monica, are threatened by HR due to their low employee engagement scores — there’s a consensus among the employees that the two managers are jerks. They both promise to raise their scores, but stupidly promise to raise the scores from “hate” to “love” within a week. Faced with this impossible task, they hatch a plan to use social engineering to steal employee’s passwords and then, using the compromised employee’s accounts, modify the engagement scores to show that employees now love them. How realistic is this plan? How can we mitigate these kinds of attacks? Let’s use a threat modeling approach to answer both.

More formally, the attacker’s objective is to modify the engagement data to benefit themselves. As managers within the company, they will know:

1. what system is being used to collect and analyze the data (we will assume this is commercial, non-self hosted SaaS software),
2. who (in their company) would be administering the project,
3. who would be providing engagement scores (the respondents), and
4. the high-level project plan and process.

The data needs to be modified surreptitiously; if the engagement data is deleted or is exposed as doctored, the attackers may have gained a short reprieve but haven’t accomplished their goal of appearing as better managers. In addition, we will assume the attackers do not have advanced technical skills to attack the SaaS software directly¹ and the time budget is closer to days than months.

The proposed attack is two-stage:

1. Obtain employee passwords by using social engineering/knowledge of the employee’s backgrounds to guess passwords
2. Leveraging those accounts, change the employee’s ratings for the managers in the engagement monitoring system

In the STRIDE threat model², this is a Spoofing threat (obtaining account access) that can then allow a Tampering threat (modifying engagement score data). The asset to be protected in the first stage are passwords and, in the second stage, the employee ratings. Spoofing threats are mitigated via authentication and tampering threats are mitigated via ensuring data integrity.

(If you find this kind of analysis interesting, I strongly recommend Adam Shostack Threat Modeling³ book. Also, Ross Anderson’s Security Engineering⁴ covers a broader systems-approach to security; the two books are complementary.)

Spoofing mitigations

While the employee engagement responses may be anonymized or otherwise have some sort of privacy protections, the actual act of providing feedback is not anonymous. Instead, the collection system requires some ability to know who the respondent is in order to tie the responses to the respondent’s place in the organization. (Engagement studies often include questions specific to certain roles or organizations and results need to be aggregated under the appropriate manager.) Thus, the collection process requires respondent authentication. Within the episode, the authentication is handled via passwords, so that is where we’ll focus our model.

Password policy/recovery policy

Using personal information to aid in guessing a user’s password is not a novel attack; it’s a standard trope in fiction but one that still works in the real world. As a straight-forward attack, it relies on users choosing poor passwords and on the systems being vulnerable to guessing attacks. Better passwords can be encouraged via the use of password managers (which reduces the pain of a unique password per site), single sign-on (which increases the value of a strong password), or policies that encourage higher entropy passwords (although onerous policies can encourage users to use their creativity to perversely choose worse passwords).

Additionally, if the system locks out (even temporarily) an account after a number of bad logins, this will slow the rate an attacker can guess passwords. Within this scenario, the managers do not have a large amount of time to guess passwords and there is no indication they can guess passwords “off-line”, so a good authentication system can throttle their attack.

An alternative interpretation of their attack is they are not attacking passwords directly, but rather using personal details to attack the password recovery mechanism. Password recovery mechanisms typically require the user to answer a handful of personal questions and, if they answer correctly, the system will initiate a password change. Recovery questions often suffer from a low number of possible answers and answers can often be sourced with some public background checks. Good password recovery systems will notify the user (ideally through multiple channels) about the password change, so this can cause the attack to become known if the users see the notifications and decide to flag them as improper. However, not all recovery systems include these features, so the attackers could maintain their cover.

Two-factor authentication

The three-factors are something you know, something you have, and something you are. Two-factor authentication requires two of these factors, normally a password and a key (often via a multi-factor authentication app on a phone or a physical device). If providing an engagement score requires two-factor authentication, then the cost of spoofing dramatically increases because a password, by itself, is not useful. However, this also increases the cost to the respondent (and the complexity of the collection) since the respondent will need to go through a longer and more error-prone authentication process. If this creates too much hassle, there will be a decrease in the response rate which may invalidate the utility of the engagement project.

A single sign-on (SSO) system, which may require an onerous authentication process but will re-use the authentication across multiple systems, can spread the pain sufficiently to mitigate the friction concerns above. However, SSO is more complex to setup and not all vendors support it.

Alternative authentication approaches

Could we mitigate the attack by not using passwords at all? In The quest to replace passwords⁵, the authors review three dozen approaches against two dozen criteria and find that none of the proposed alternatives to passwords is in-arguably superior across usability, deployability, and security dimensions. There are trade-offs in all approaches and all examined approaches have at least one feature that is “worse” than passwords.

For example, take the “One Time Password over Email” approach⁶. In this approach, users submit their email address to a server which persists one-half of a split token as a cookie and sends the other half to the user’s email. The user supplies the email token and the server combines and verifies the two tokens. Versus passwords, this scheme has the advantages that the user does not need to remember any long-term tokens, is resilient to someone watching the user type, is resilient to both throttled and unthrottled guessing, resilient against release of information from other parties, and resilient to phishing. However, this scheme has the disadvantages of being inefficient for use ⁷, is incompatible with existing password-based systems, is immature versus other schemes, requires trusting a third-party (email system and intermediaries), and allows linking of accounts between disparate systems.

For the employee engagement application, the fact that emails are required is likely a non-issue due to the system likely knowing quite a bit more about the employee; it’s already a PII-sensitive application. Adding friction to the login process is non-ideal as the project needs to maintain response rates, although employee engagement projects tend to have motivated respondents. The immaturity of the scheme may be acceptable for the respondent use case. Respondents don’t need typical user accounts as they are only supplying data to the system. However, using a novel system will require more development effort to implement, may incur a larger user training cost, and will have a higher cost in security audits.

Tampering mitigations

Tampering attacks involved modifying the asset under protection, in this case, the response data. (Tampering could also involve modifying software or hardware within the data flow, but those kinds of attacks would be beyond this kind of attacker.) Maintaining the integrity of the data relies on either preventing improper modification or having a path to restore the proper data after an attack.

Enforce deadline on updates

In a standard employee engagement study, there will be a collection period followed by an analysis period where the project teams assembles and disseminates the reports. If updates to responses are restricted to the collection period, this reduces the window of opportunity for attacks.

Measure trends rather than moments

In the episode, they only need to have good scores on the next review date. This means that actions will be taken on anomalous readings; the attackers only need to adjust scores for one review. If the project instead looked at trends over time, the attackers would need to adjust scores over multiple phases, which would greatly increase the chance that their attack would be noticed.

Report back to the respondents on updates

If changes in data are notified to multiple systems, it can make tampering more apparent. However, notifications and logs are only useful if people look at them as there is a cost to monitoring, particularly if updates are expected in the normal course of business (i.e. false positive rate is significant). One way to counter the economic cost is to notify the respondent, as their volume of notifications will be small. Any additional notifications seen by them will likely be treated as suspicious. Additionally, some respondents will like a copy for their own records, making a security feature a user feature as well. Sending the respondent an email copy of whatever is submitted is an easy mitigation to improve detection of tampering. However, this approach also allows a new vector of information disclosure, since attackers can now access the response data from other data sources. An employee’s company email account is generally more accessible to management and IT staff than an engagement response database.

Use robust aggregate statistics

The attacker’s goal is to increase their engagement score, which is an aggregate of individual scores. Which aggregate is used can greatly influence how the attack must be performed. If individual responses include a score, typically aggregates include mean and median. Alternatively, the program may use a system like Net Promoter Score® (where responses are classified into the three categories of promoter, detractor, and passive and the derived score is the delta of the percentage of promoters versus percentage of detractors) or some linear regression model. The choice of the aggregate determines how robust the calculation is towards outliers and the more robust the statistic, the more expensive the attack. (The use of “outlier” here is informal; the SaaS software presumably restricts value to a valid range, so someone can’t break the calculation by setting an individual’s score to a million.)

For example, let’s say the score is based on the average (arithmetic mean) of individual employee’s scores. The sample includes 15 employees who have given the scores {1,1,1,2,2,3,3,3,3,3,4,4,5,5,6}. The mean of these scores is 3.1 and the median is 3. The attackers have a good idea of who will be giving the worst scores. By changing the scores to {10,10,10,2,2,10,3,3,3,3,10,4,5,5,6}, they’ve managed to improve the mean to 5.7 and the median to 5. As the mean is less robust, the attackers can improve it (here by 2.6) more easily by modifying one-third of the scores. The median is more robust and has only increased by two.

If clamping is not enforced, then the attackers just need to modify one score to allow them to set the mean score to any arbitrary value. To modify the median to an arbitrary value, they would need to modify one half of all scores.

Retain historical data (and report on it)

There are two vectors for a data change: an updated response from the respondent and an administrative edit. Particularly for this kind of study, respondents may naturally update their responses if they remember some new detail or tempers cool from a rash response. Thus, collection systems often allow updates to a response, even after the respondent has hit ‘submit’. On the administrative side, project administrators may edit the data to correct errors introduced in the project setup, may perform some data clean-up such as re-scaling values, or may edit the data for broader release⁷ or upon request by the respondent. Reports and analytics resulting from the project should reflect the “latest” data and incorporate all edits.

For both vectors the appropriate security feature that the SaaS developers and project administrators should maintain is “non-repudiation”. This feature means that someone can say “I didn’t do that” and the system can prove them wrong (or at least evidence that they did). In bank applications, this means someone can’t withdraw some money and then protest they didn’t do the withdrawal and should get the money back; the bank’s records will identify who performed the withdrawal, where it was done, and likely include photographic evidence of the act.

Non-repudiation requires both data to be logged or persisted appropriately but the details of the changes to be available and evident to the project administrators. On the persistence side, developers will often use an immutable data design or event log to provide that audit trail, with some sort of “latest” snapshot to make analytical processing efficient. On the presentation side, this can be a challenge since there is often a “natural” amount of updates within a project that can obscure nefarious activity. Highlighting altered data within a data grid or showing the number of versions of each row are two straight-forward ways of exposing this data, as long as the volume of changes is small. In the case of a high volume of change, there is an opportunity for a system to provide anomaly or fraud detection to help administrators identify odd patterns.

“Next Best Alternative” Threats

Attackers are rational and will attempt to use the least risky and least expensive attacks available to them. Defenders, faced with their own resource limitations, should invest to raise the costs of attacks beyond the attack’s acceptable threshold, but not over-invest such that the investment exceeds the risk. If the above mitigations are successful against the manager’s attack, what would the managers do instead?

First, instead of attacking respondent’s accounts, they could instead attack a project administrator’s account. Using the admin account, they could then edit the data or delete responses. Administrator accounts are more likely to include additional authentication protections than respondent’s accounts, so this approach is more risky, although once the account is accessed they have greater power to accomplish their goals. Protecting the data against administrative modifications have similar strategies as in “retain historical data”.

Secondly, they could try to discredit the study or process itself. This is not a typical “security” attack, but if sufficient doubt is placed on the accuracy of the study, then the engagement scores will be ignored or treated with little weight. In the context of the episode, though, they are well-known for being anti-social, so they would need to argue that although the results match expectations, they are somehow invalid. Within the episode, the attackers use an alternative form of this attack by making the HR lead’s engagement scores terrible. The HR lead then cancels the study.

Thirdly, an alternative form of discrediting could be accomplished through a denial of service attack. If the software becomes unavailable, the schedule for the study can be disrupted or random failures could shed doubt on the SaaS vendor’s ability to collect all the relevant data or present the complete picture. While a denial of service attack launched directly against the SaaS vendor would be very public and risky, a company’s network can be configured (perhaps through http proxies) to randomly drop packets or requests to the vendor’s sites, thus making it seem like the symptoms of overloaded or unreliable software. Based on our profile of the attackers, this would be outside their ability unless they are part of an IT group or could gain support from someone managing the network.

Conclusion

By incorporating standard security controls and incorporating data integrity controls into their software, the cost and difficulty of the attack can be increased beyond the attacker’s abilities. Since the Pied Piper company is run so shabbily, it is believable that their in-house engagement software could suffer from such an attack, but since these styles of attacks are well-studied and have off-the-shelf mitigations, they should not work against a professional SaaS vendor’s solution.