TweetDeck — Just another hack or a missed opportunity to tighten cloud security?
June 13, 2014 | Leave a Comment
June 12, 2014
By Harold Byun, Senior Director of Product Management, Skyhigh Networks
The recent TweetDeck hack on Twitter presents a common cloud dilemma for information security teams. On the one hand, the BYOX trends that drive cloud service adoption and worker self-enablement are transforming traditional IT into a User-Centric IT model that focuses on empowering and enabling workers. On the other hand, the free-wheeling nature of the cloud and the regular news of breaches creates a gap in security teams’ ability to quickly assess risk and exposure for these types of events. Further, with the cloud-based self-service model, it becomes more difficult to identify affected users and formulate a rational response plan.
This shift not only drives home the importance of gaining in-depth visibility into cloud usage, but also emphasizes that the role of information security is transforming in terms of remediation strategies and user education. As the TweetDeck hack exemplifies, there are two alternate scenarios of response that security teams can take.
In one scenario, security teams can quickly assess that 35.9% of their users have accessed Twitter in the past week, and of these users, 42.2% also accessed TweetDeck. This readily gives InfoSec teams an assessment of their attack surface for this specific cloud-based vulnerability. In fact, Skyhigh ran this exact analysis on its own platform and determined that over the past week, the average enterprise customer had 11,991 users accessing Twitter, with 5,060 of those accessing TweetDeck. Using these findings, a security response team can easily notify the affected TweetDeck users of the breach and provide remediation instructions as well as notify potentially affected Twitter users of the vulnerability. For teams interested in a more proactive approach, sequential transaction analysis can also be used to identify TweetDeck sessions and subsequent site accesses or cross-domain accesses.
For additional monitoring, analysts can also look at concurrent logins and geographically disparate logins to identify compromised accounts and any other anomalous activity from specific users and/or impacted endpoints given that login tokens may very well be a logical target of this type of vulnerability. Further, organizations can formulate a user attack landscape based on breached services accessed by users to identify clusters of higher risk internal targets. Finally, organizations can implement user education redirect pages for users accessing the impacted cloud service to further notify them of the risks associated with using a given service. This type of real-time education can have a profound effect on increasing user awareness to potential risks.
The above response plan is one scenario that provides a comprehensive set of actions which teams could readily implement that would ultimately provide better visibility and monitoring for this vulnerability and future exposures as well.
There is also an alternate scenario. In the latter scenario, security teams will simply note the vulnerability and service breach and rely on existing security solutions to notify them of a potential exploit on their systems. After the noise around this particular breach dies down, they’ll return to their day jobs and focus on other higher priority issues. Unfortunately, this latter scenario is likely the more common path taken.
The irony here is that just as BYOX gives workers a choice on which services to use for work, information security also has a choice on how to educate users and respond to events in a more unconstrained technology environment. The visibility and analytics needed to take a more proactive approach to address your organization’s exposure to breaches exist; it’s up to the security practitioner to leverage the information that’s available to him or her to enact a more proactive and robust security response model.