B. Responsible Disclosure
When you perform information security tests, you are looking to find ways that systems break. The tests outlined in this guide highlight common issues in software and mobile applications. These issues have persisted for years and, unfortunately, will almost certainly persist for many more years to come.
This is all a long way of saying that when you perform information security testing and reviews, you will -- at some point -- discover problems. In many cases, these problems will reveal issues that compromise user data. Because of this, testing requires discretion and ethics. You are looking for issues, which can lead to accessing sensitive information. If you uncover a security issue, you have an ethical (and, in some cases, a legal) obligation not to make things worse.
If you are not comfortable with behaving responsibly and working to get issues fixed before they are discussed publicly, then security testing might not be for you.
The initial purpose of information security reviews is to discover where problems exist and report them. Probing to uncover the full scope and impact of these issues is a separate domain, and unauthorized access to privileged information -- even when done with the best of intentions -- can lead to serious complications.
In this primer, we are careful to focus our tests in ways that limit the types of data that can be exposed. When you are testing and you find an issue that results in data being leaked, your job is done. If you want to see if user data can be compromised in a system, create one or more dummy accounts in the system and target those. If you expand the scope of your testing and gain access to the personal information of people you do not know and who have not given you permission to test using their data, STOP TESTING and document how to replicate the issue.
Responsibilities and processes around disclosing any vulnerabilities uncovered via testing will vary based on why you are testing. If you are working for a school district, you should coordinate your disclosure with your technology department -- and, ideally, district-level technology departments can establish a process for communicating any issues with vendors. If you are working for a vendor, you will need to escalate any issues to your engineering team -- and, ideally, when these issues are fixed, the updates will be communicated to end users. If you are testing as an individual (i.e., not as part of a district team and not as part of a vendor's team), you should document the issue clearly and communicate with the vendor directly.
When you uncover a security issue, following a responsible disclosure process helps protect you and the people whose data could be at risk of being compromised. If you discover a potential security issue, these steps can provide a rough road map to help get the issue addressed in a timely way.
- Document the steps to replicate the issue. This can be done via screenshots or, in some cases, a screencast. Whenever possible, note the URLs where the problem can be seen.
- Contact the vendor. Most vendors will have a privacy or security contact identified in their privacy policies. Use the contact information there to let the vendor know you have identified an issue.
- If the vendor doesn't respond within 24 hours, contact them again. If the vendor hasn't responded to an email, make a phone call. If the phone message goes unanswered, look for other numbers to try. Additionally, if an email to the security contact does not get a response, send another email to sales, customer support, or other contacts.
- If a vendor remains unresponsive, seek outside help. Most vendors will be responsible and responsive immediately, but if the vendor remains unresponsive after two or three attempts at contact over a two- to three-day period, it is appropriate to escalate the issue. An issue can be escalated in a variety of ways, but any escalation must ensure that user data is not compromised. Escalation of an issue can include reaching out to security experts, reaching out to journalists with a track record of responsible reporting on data issues, or contacting a company that brokers between companies and researchers. If the issue is with an application you have purchased, contacting their sales team or working through your district's contracting team can also be effective.
The reality is that many companies will work quickly to resolve issues, but a small percentage will not respond. If a company is not responsive, it can be frustrating, but in all situations the ethos of responsible disclosure needs to drive how any security issues are shared and addressed.
- Proceed to the next chapter: C. Setting Up the Testing Toolkit