Information security is challenging, and can be breathtakingly expensive in money and staff energy. Smaller organizations may not have the money or staffing expertise to do the job right, even when the need is the greatest. At OSCON 2016, Kelsey Gilmore-Innis of Sexual Health Innovations (SHI) gave a really interesting talk on how her small nonprofit has done some creative thinking about security, and how that influences the deployment and operation of their application.
Callisto is an online reporting system designed to provide a more empowering, transparent, and confidential reporting system for college sexual assault survivors. The application serves as an information escrow; the user can report an assault and then decide whether to release the information to responders and when. It is crucial, given the sensitive information, that the data be absolutely secure. Some of the core principles that Kelsey's organization have adopted for their information security don't require lots of money—merely a different way of thinking about information and the paths it can traverse in and around the application.
Assume a breach will happen
You should plan for what to do when it happens, but work as hard as you can to prevent it.
This has been the failing of a number of high-profile breaches. The example given was the Ashley Madison hack; in this case, the highly sensitive information was not stored safely, was inadequately protected, and too many people had access to the backend of the system. When the hack happened, they were caught completely flat-footed and unable to respond quickly. Their practice of never deleting stale personal information—including that of users who had left the system—compounded the problem. There are low-cost, low-impact measures that could have been taken that would have prevented the data from getting leaked.
Know your strengths
You know your product and its users, even if you're not an expert on server administration, security, or load balancing. It's perfectly OK to pay the experts to take care of things. For instance, don't try to implement your own CDN to mitigate DDOS attacks—there are already services that do that. Find the best ones for your needs and ante up; it'll be money well spent. Don't try to write new encryption schemes; good ones exist already that are well-audited and difficult to crack, so use them.
Know your threats
Threat modeling is at the core of the work that SHI has done for Callisto. It's the process of thinking through what an attacker is looking for, how they'll get it, and what they'll do with it. A good threat model can influence design from the ground up. For Callisto, there were several "threats" that needed to be examined, quite aside from the usual sorts of hacks. Security in this environment requires empathy, primarily to users. Knowing what they do, what their lives are like, and how they would be affected by a data loss requires deep and perhaps painful knowledge of the problem domain.
SHI expects that data may, at some point, be subpoenaed in an active court case. To prevent revealing the data to a litigious adversary, the architecture of the system encrypts the data with a secret key that SHI no longer holds. They generate the key, give it to the user, then discard it. If the user loses the key, that data is permanently lost. Users are warned of this behavior when creating records.
Another attack vector would be someone interested in a specific user's record who may have access to their computers. Still another is misuse of the system by bad actors. They are using the system in legitimate ways, but are doing so in bad faith to harm others.
Your biggest threat is working in the room with you—not just disgruntled employees, though that is a common enough problem—but also leaky information paths: contractors with private email services, email stored on the same servers as production data, weak reporting protocols for data breaches, use of copies of production data on test systems, and inadequate access control policies. All of these present paths where your crucial information can get away from you. Solving most of those problems doesn't take much, just vigilance and sound policies.
The second biggest threat, of course, is the user you are trying to protect. In your UI/UX choices, make sure that the user cannot make insecure choices. The common feature of many sites is the "secret" question (Tell me your cat's name, and I can access your data). If someone is being abused by a live-in partner, they will know that! Consider also the paths that users will take to access your application, including mobile devices and shared computers in public spaces. Make sure that session protection is solid for all users to prevent session hijacks and reuse.
In the case of Callisto, one important threat vector deals with the responders. When a user authorizes the release of the report to their institution, the college or university must use a PGP keypair to decrypt the report that is sent to them. Teaching PGP is challenging, and therefore presents a possibility of leaky information, as does the question of what the institution does with the decrypted report. Not everyone is skilled or knowledgeable about keeping that sort of thing secure.
Think about data transfer security
Where are the boundaries on your system? The boundary between the application and the database must be solid. Serializing and deserializing of data is an attack vector that might not be obvious to some. Is your application using a secure path such as SSL to talk to your database server? Even if both are "inside," it absolutely should!
Does your application keep an activity log? What information is in there? If only the log were leaked, could information contained in it (IP addresses, anyone?) be used to track usage of the system and potentially harm a user?
Test, test, test
You absolutely should test the policies and processes that you've put in place. There are a number of free security checkers, including OWASP, that can help you. If you have the budget for it, paying someone smarter to test it through penetration testing or bug bounties can be extremely useful.
Spending some time and effort with your team, including non-technical users with thorough knowledge of the problem space, can yield substantial insight into your application's security needs at minimal cost. You don't have to spend a fortune on security if you use the best tool in your arsenal: Your brain!
Comments are closed.