Spoiler alert: Don’t hard-code your credentials
From September 8–11, 2022, Datavant will host our first annual Future of Healthcare Hackathon. Hackers can submit projects to one of three tracks, Privacy, Public Health, and Improving Patient Care. Regardless of the track you choose, security within your project is always a critical consideration. Below, Datavant’s Head of Security Ben Waugh and Product Security Engineer David Gold offer some considerations around hackathon project security.
Hackathons are an integral part of the ongoing growth of any technology company, as they create an opportunity for teams to self-organize for a fixed period of time and tackle a challenging business problem. A hackathon embodies the ideals of experimentation, speed over perfection, and of course, getting things done. From Twilio’s Tweak Week to Atlassian Ship It Days, we (Ben and David!) have had the opportunity to take part in many such events over the years, and as security practitioners, we would be lying if we said we had never seen things come up in these events that were…a little concerning. Issues often arise from teams prioritizing development speed over considerations of security (read on for examples!). Yet, we’ve noticed there is little guidance out there as to how hackathon teams can keep security and privacy at top of mind as they compete without slowing down their project.
Hence, in the lead up to Datavant’s Future of Healthcare Hackathon, we’re sharing some advice and tips for teams to best manage security and privacy risks in their projects. And since we’re talking about security, these tips apply just as much to day-to-day work as they do to a hackathon project.
Why care about security in a hackathon project?
Risk profiles of different projects will always be different. Rather than disregard security entirely, though, it is better to consider the specific risk profile of a project, and avoid the potential issues lying therein. Not only will this help you improve the actual security of your project, you might also impress the more security-minded judges. And if the project is to have any kind of subsequent longevity, these security issues are issues you would have to deal with down the line anyway.
Here are four key considerations (and one bonus suggestion!) to keep in mind while building your project:
Research software frameworks.
There’s a good chance you will want to experiment with a new framework while developing your hackathon project. Experimentation is great! That’s what a hackathon is for! But, it’s always a good idea to do some background research on a new tool to see if the developers produced any security best practices documentation. This is especially true if your project is going to be hosted publicly or will interact with any non-public data or systems. Where are you going to show your project? What kind of third-party tools do you need to bring in to make it happen? These decisions can potentially create an unforeseen sensitivity.
If your frameworks are touching things you don’t ordinarily work with (databases, infrastructure, etc.), it is even more imperative to seek security guidance for these tools. For example, Flask explains a couple common web app vulnerabilities such as cross-site scripting and man-in-the-middle attacks, and describes how to address them within the framework. Often, simple configuration settings or helper methods can be used to mitigate major security risks with little effort.
You might also consider whether your aim is to build something usable, or simply to show that something is possible. If you’re building a product feature or enhancement that relies on an open source library or software package, does it by extension require your entire project to be built in an open-source framework? If your goal is to create something actually usable, this strategy, while perhaps easier to get rolling, may limit the future use cases it could have. Of course, if the project doesn’t depend on the library, but just makes use of it as a proof of concept, then this is less problematic, and a future rebuild could be made without that library in it.
As a hackathon strategy, the more research you can do on a framework you intend to experiment with before the hackathon kicks off, the better. This allows you to go in prepared, and not spend valuable time doing this background research during the hackathon.
Pre-plan your infrastructure and environment.
You want to move quickly. You don’t want to slow yourself down building overhead or setting up unsexy plumbing that may or may not be a featured element of the final presentation. Creating wide open access policies (be they Security Group rules, IAM Policies, etc.) is likely the fastest route to deploying infrastructure. However, this approach means exposing your project (and any interconnected components) to the entire world. Be mindful of this exposure and ensure your systems, accounts, and infrastructure components (such as databases) are protected with strong authentication. Enable Multi Factor Authentication for your IAM Accounts and SSH Key Pairs for Authentication instead of using passwords.
Integrating SaaS products like Slack, Google, or JIRA may be especially valuable if you’re working on a project to build a productivity tool for your company, but keep in mind that some of these tools ask for OAuth. Be thoughtful about what permissions you give those products. Does your hackathon project actually need admin access to these accounts? Are you inadvertently turning over your company contact list to Slack (and/or the world)?
Just as you can undertake some background research on best security practices for new tools ahead of the hackathon, you can strategize about your built environment ahead of time. Making important decisions about security protocols in the heat of the moment can lead you to make mistakes or forget about basic security practices. In short, leaving open access policies in the name of speedy building is a strategy that could easily backfire. Also, any security-minded judges on the panel will decidedly frown upon an approach that ignores risk management altogether. Figure out how to address it in a manner appropriate to the demands of the project.
Map Out Your Use of Data.
In the spirit of rapidly producing proofs of concepts, it may be tempting to build your project directly on top of an existing production system using existing production data. In some ways, this is the most realistic “test” data to prove the validity of your idea. However, from a security standpoint, this is generally not a good idea, especially if you are working with sensitive data (as Datavant engineers regularly do). Given the points we made above about balancing speed and security, building on existing production data with ill-conceived security could quickly become highly problematic.
Ideally, you would be able to use a robust development or staging environment (without real data), but if not, it’s best to mock out API calls that otherwise operate on production data. If you can, aim to redact sensitive attributes, or use public or synthetic data. In the case of the upcoming Datavant Hackathon, we are making available diverse datasets: price transparency data by Turquoise, synthetic datasets by Syntegra, and a variety of datasets related to provider/payer information sharing provided by Datavant. There are tons of open-source tools available to help with mocking and test data generation across many languages, frameworks, and domains. For example, here is some open-source synthetic patient data. Finally, when attempting to identify what data may be sensitive, consider not only the data that is being operated upon (e.g. patient medical records in the case of a health app), but also its metadata, including, for example, location, hospital names, and IP addresses.
Be Mindful of Credentials and Third Party Services.
We see this way too often.
Perhaps the greatest cardinal sin of software development we see committed all the time in hackathon projects is credentials hard-coded into source code. These credentials could be for other systems, cloud environments (your AWS account), or third party APIs.
We get it. This is the fastest approach. But hard-coding credentials is never a good idea out in the real world, and continues to be a bad idea in a hackathon environment too. If your project code ends up on Github, it’s not a leap to imagine your credentials being lifted for nefarious purposes…like…let’s say…mining tens of thousands of dollars of crypto currency. Your hackathon project may be hypothetical, but the consequences of that strategy are quite real. While it would be ideal to use a secrets management system, such as Hashicorp Vault, AWS Secrets Manager or AWS Parameter Store, even employing environment variables is a huge step up from hardcoding.
Don’t put credentials in your code.
Bonus for committing to your hackathon project security and reading to the end!
Leverage your security team and your security-minded contacts. Explain your project concept and ask for insight on the particular risks involved in the project, and invite their input. Finally, if you’re a security or privacy practitioner reading this, get involved in Datavant’s Future of Health Hackathon! We’ve learned a lot both as participants in hackathons and by watching other teams develop projects. Join a team and contribute directly to make sure interesting projects get built safely.
We look forward to seeing some imaginative and innovative projects! See below for more information about the Future of Healthcare Hackathon.
About the Future of Healthcare Hackathon
Datavant has hosted several hackathons over the past few years. One major highlight of these was the 2020 Pandemic Response Hackathon, which drew over 1600 participants, 230 submissions, and involved 30+ co-partners. Have a look at the 2020 project showcase to see some especially impressive submissions.
The Future of Healthcare Hackathon is a virtual event taking place from Sept. 8 — Sept. 11. Submissions will be reviewed by our judging panel including David Shulkin, prior U.S. Secretary to the VA, Niall Brennan, Chief Analytics and Privacy Officer at Clarify (formerly at the Healthcare Cost Institute), Clare Bernard, Ph.D., Senior Director, Data Sciences Platform at Broad Institute, and more.
Winners can bring their projects to life by leveraging our prize pool, which includes cash prizes and the opportunity to travel to Washington D.C. to present at the annual Future of Health Data Summit (on 9/15). Presenters at this conference will include Former and Current Heads of the FDA, Former U.S. Secretary of the VA, Chief Data Officer of Broad institute, and Federal CIO. ~250 high profile leaders in healthcare, tech, and policy, will be in attendance, as well as press.
Authored by Ben Waugh, David Gold, and Nicholas DeMaison.
Ben Waugh has a background in secure software engineering and security architecture and is currently the Head of Security at Datavant. Connect with Ben via Linkedin.
David Gold has a background in chemistry, biology, and software engineering and is currently on the product security team at Datavant. Connect with David via Linkedin.
Nicholas DeMaison enjoys telling simple stories about complex things. Connect with Nick via Linkedin.
Looking to solve security and privacy challenges of healthcare tech at scale? We’re hiring!
.svg)
