On the recent Twitter hack

First, caveats:

1. I’m unaffiliated with Twitter, and while I had an account previously, I deleted it a couple years ago.
2. I have no sources inside the company, I can’t definitively speak to their practices.
3. I’m not an expert on security: I have a couple years of experience in this space at Booking.com.

That being said, I worked on two topics at Booking.com. First, I was the lead of Identity and Access Management (Corporate). Subsequently I was assigned the topic of Account Security. The former scope looked at preventing internal fraud, with a heavy emphasis on regulatory compliance, and the latter scope looked at preventing external fraud, again with a heavy emphasis on regulatory compliance.

So to me, this is an interesting circumstance because it intersects both of these topic areas.

On preventing internal fraud: Sarbanes-Oxley Act

In the United States, the Sarbanes-Oxley Act is an incredibly large piece of legislation passed in the wake of the Enron accounting crisis that requires publicly held companies to go through annual audits of not only financial information, but the controls around financial information. In short, the question we ask is “is it possible for someone to commit financial fraud without detection?” The 2002 legislation itself doesn’t say exactly what the audit looks like — it delegated the details to the U.S. Securities and Exchange Commission, but an interesting phrase in Section 404 is this:

(b) contain an assessment, as of the end of the most recent
fiscal year of the issuer, of the effectiveness of the internal
control structure and procedures of the issuer for financial
reporting.

So, anything that could influence financial data would have to be audited and reported. What’s relevant to our discussions, then, is that the controls that would allow for permissions for financial data was often the same controls that would allow for permissions for other systems. So in the end, the ability for any random developer to get access to a random database would, by necessity, need to be restricted because of its “material financial impact” for the leaking of said data.

In working with auditors, evidence we’d have to bring to them were often proof that a particular control was working. So we had to prove we understood exactly how the system would grant permissions for different systems. We had to prove there was regular review of the permissions granted, and that for all permissions we could point to what system the individuals had. We had to prove that when a person no longer needed the permissions that it would be revoked.

As developers, we chafed at having controls and limits on our ability to touch production data.

• “How will I debug issues?”
• “What if the system is down and I need to do something restricted?”
• “How can I be autonomous if the action requires someone else to be there?”

These were often questions developers would have in protest of these restrictions. Additionally, we introduced a system of Segregation of Duties: someone who’s created a purchase order cannot be the person approving the purchase order (for instance). Though this was mostly for financial information, all development processes had to go through this analysis as well, since the financial databases were also populated via code.

And developers hated it. More often than not the “why hire us if you don’t trust us?” statement would be an objection to new controls.

Thing is, we might trust the person behind the account to not partake in fraud, but as a professional working in the security field it’s imperative not to trust people to always be paranoid about their credentials.

And so the guard rails need to exist, and the monitoring needs to exist.

Speculation on Twitter, on internal fraud

So let’s bring the above to Twitter’s case. How is it an audit of the control systems did not find this deficiency? Or if it did, how was this not publicised?How is it possible that an individual person or their credentials being compromised could have such a huge impact? Twitter is a publicly traded company in the United States, and given the importance to the contents of tweets, I would have expected this to be something that would have been a top priority.

On remediating social engineering: Account Security

One issue that happens with social engineering is that it’s not entirely detectable: if a hotelier is socially engineered to give away their credentials, including their MFA, then we cannot rely on the accuracy of their password entry or MFA to be certain the person logging in is indeed the person we expected it to be. Scammers can be particularly persistent, especially when there is a positive return on investment from the amount of money stolen from unsuspecting people compared to the amount of effort involved. At Booking we had this issue constantly: scammers would pretend to be hotels. So what did we do about it?

Like any other bank or secure system, we built machine learning models around behaviors, using indicators of compromise to trace the graph from one compromise to another. When I left Booking we were working on decreasing the time to detect, and finding ways to target suspicious behavior. Every single request of sensitive data was instrumented.

The legislation that was applicable here is the GDPR. The data access that the GDPR requires for breach notifications also coincides with the data access a scammer would need in order to run spear phishing campaigns.

And this was a constant battle! When we detected a new fraud campaign, we would create an attack path map of the scammers, identify the weak spots where the social engineering was occurring, and do the following:

1. Create ways to detect that type of social engineering
2. Create mechanisms to separate normal behavior from anomalous behavior
3. Hypothesise on the goals of the fraudsters
4. Hypothesise on what the fraudsters would try if the specific path was blocked off

When I left Booking.com, we were working on figuring out how to more quickly identify anomalous behavior. An example would be the “impossible travel” issue. If someone logs in from, say, Paris, and then immediately makes a request from Tokyo, then one of those actions are not legitimate.

Speculation on Twitter, on external fraud

Given the amount of impact Twitter as a service has, I’m surprised there were no immediate alarm bells that were tripped when a number of identical tweets were sent out. Or, even better, circuit breakers associated with the former. I’m surprised that amongst product features Twitter doesn’t seem to support the concept of sub-accounts (for corporate tweets).

Tying it all together

I am incredibly sympathetic to their security team: this type of issue was the type of publicity that I dreaded my entire time at Booking.com, whether it was an external audit finding a deficiency in our system, or a major scamming operation being big enough to warrant public scrutiny. Often we’d be fighting an uphill battle to invest more in security. When bad things happened, it’d be our problem to fix, but when nothing happened, it would be more difficult to justify the investment.

Public trust is a difficult thing to get back, though unless a competitor is able to offer the same services I doubt there’ll be any long-term consequences.

In the end, this particular incident will be corporate motivation for organisations to “do the right thing” and evaluate where they stand in terms of the risk of fraud, whether internal or external.

Trust is not a valid strategy!

Call to action

What can we do in our organisations to prevent this type of thing from happening to us? I think understanding the state of affairs and planning for remediation of the following questions is a good start:

• What are risks associated with access?
• What are the motivations of the people who would want to gain access?
• If an individual within the organisation is compromised, is there a way to detect it and prevent malicious activity?
• Is it possible for privileged access to be shared from an internal account to an external one?

Some resources

I’ve been using the OWASP framework to understand and work on the security posture. The CIS top 20 is also a good place to start if you’re looking at doing this as well.