In Light Of The Twitter Whistleblower Testimony, Key Questions Every Board Needs To Ask

Following the testimony of Peiter “Mudge” Zatko in front of the Senate Judiciary Committee, I’ve been reviewing his whistleblower complaint as well as the supporting documents. It’s been an opportunity to take a retrospective look at what data security policies should have been established at Twitter and learn from the past. What this testimony has also revealed, however, is implications for how data security is governed, ranging from the board to regulatory bodies. It’s become clear that the future of data security lies in the hands of these groups, and it all begins with an organization’s board members.

Board members must now ask themselves what the implications would be for their business—and them—if they were to find themselves in a similar situation. They’ll need to ask the hard questions and figure out whether they not only have specific capabilities or plans in place to address the issues raised, but also to deal with more esoteric trust issues. Questions like: “Can I believe the current security status reports?” or “Are we being told everything important about security or is some information being purposefully withheld?” These questions are, sadly, questions that aren’t easy to answer with a simple yes or no, even by the people preparing the reports.

Board members must start with a set of questions about the current state of data security that can be answered with evidence-based responses from the CISO. While it is perhaps unfair to expect any CISO new to an organization to be able to answer these questions, they still need to be asked.  With an average tenure of 18 to 24 months, most CISOs could quite fairly be described as “new.” Their focus is more on simultaneously trying to invest strategically in new capabilities while reacting to the latest incident(s), than on unraveling years of technical debt and discovering where data that’s accumulated over the years came from or why they were collecting it in the first place.  This results in a parade of CISO’s failing to make meaningful change—unless, that is, the Board focuses their attention on meaningful change by asking the following simple questions.

Key Questions Every Board Member Should Ask Their CISO

Are development, test, staging, and production environments kept separate from each other?

If the various environments are not separated from each other, organizations are setting the stage for unauthorized users to access data they should not be able to, regardless of the controls put in place.

Least privilege has always been a clear principle underpinning cybersecurity in all its forms and is usually a specific principle adopted within organizational security policies. It’s also been a clear principle in modern privacy laws, with clear direction provided that data should only include that which is required to fulfill a specific purpose. Enterprise leaders must ensure that each environment is properly architected to only allow access to the right users, in order to prevent data leakage from occurring.

Do we know what data is in each environment?

Mudge noted that one of his concerns was that Twitter didn’t know what data it was collecting. But this isn’t the only problem. In fact, it only sets the groundwork for the broader problem, particularly amid concerns over unfettered foreign government activities in and around Twitter; Twitter employees have too much access to too much data and too many systems, because data is everywhere.

Developers and engineers do not need access to personal information in any environment outside of production, but CISOs struggle to enforce this, because they simply do not know what data they have in each environment, trusting that it isn’t sensitive data.

What access do new employees have to this data?

In a continuance of examining user access permissions, boards must also consider what access new employees are given to the organization’s data. This will naturally be dependent on their role, as they will need to learn their responsibilities, however, granting them too much access may lead to excessive permissions that are hard to revert.

Are errors and failed login attempts being monitored?

If organizations are not monitoring and recording errors and failed login attempts, they are losing out on the ability to identify potential risk right away. It is vital that the board maintains visibility into this type of activity, so that the organization can identify problems before they arise, as well as potential attack targets and avenues.

Are there appropriate steps in place to backup data and protect backup data?

Boards also must consider whether the organization’s data security posture management (DSPM) strategy includes adequate steps and procedures to guard against ransomware and other destructive data failures. As we’ve discussed, adopting zero trust and least privilege policies can help prevent unauthorized access to sensitive data, but additional resilience is required.

Creating and testing backups of data also give organizations insurance that data cannot be destroyed or accidentally deleted. If this is not a policy that’s not already in place, leadership should consider implementing this practice to protect enterprise data and safeguard against potential issues.

Are we compliant to our own data security policies?

The telling part of Mudge’s testimony is that without the required visibility, it’s obvious that best intentions and data security practices were impossible to comply with. Systemic failure to adhere to your own security policies and privacy laws are the types of issues that can’t be unseen at the board level and will require a clear commitment to reducing unnecessary data and/or access.

So, will Mudge’s testimony be a catalyst to get specific investment and focus from boards in addressing data flow visibility and reducing unnecessary data and access in other organizations? While data-savvy boards understand that it will take time to rectify years of neglect, this is a problem that will likely generate greater focus from regulators in the short term.