Cyber Security for REDCap Extended Features Protecting REDCap extended features (Twilio, Mobile App, API, and more). – Staying ahead of the bad guys – An open discussion on cyber security as it pertains to REDCap. Discussion Leaders Brian Man and Kevan Essmyer

Why mess with a good thing? “This (REDCap) is great, but would it be possible to….?” “This is exactly what we want….do you think you could maybe….?” “We’ve got a guy who’ll write our API programs for us...don’t worry about it...” “Mobile app, cool!, all of our team members have phones….” “We need access to the database so we can generate the reports we need…” “It’s HTTPS, so we’re protected...”

Twilio Twilio supports the TLS cryptographic protocol. Clustered architecture reliable high availability service. "Fallback" URLs on incoming phone numbers SMS Low risk -- Secure URL links to REDCap surveys High Risk -- direct text question/response (Non-PHI only)

API Limit Token access Project Isolation Request overhead to limit number of tokens created Responsibility (IRB) Project Isolation API limited to individual project Token use tied to single user account SSL transport layer independent of API security Only effective if the client checks for certificate validation API limited functionality Controlled number of system access points Limited functions

Mobile App Mobile Top 10 2016 Improper Platform Usage Insecure Data Storage Insecure Communication Insecure Authentication Insufficient Cryptography Insecure Authorization Poor Code Quality Code Tampering Reverse Engineering Extraneous Functionality -- https://www.owasp.org (Low-ish Risk) Official Release -- REDCap Mobile App Source code tightly controlled Primarily API Developer and user tested Specialized token user rights (Moderate to High Risk) Locally Developed App API clients Monitor Server API Traffic Try to work as a partner if possible Allow access to test server for app testing Information Security Office ← Friends!!!

File Sharing features Risk Mitigate Risk Multiple users on system Unintended transfers of Protected Information (leak) Malware propagation Content is not scanned for malware before upload Host system vulnerability Mitigate Risk Disable Feature (Determined to be high risk, Redundant--site license for Box exists) Virus Scan storage directory Resilient host environment Limit file types

More? (Extra Features, plugins, and stuff) Plugins,hooks, “Special Reporting Scripts or Programs” Secure programming best practices Limit input options Filter free-text input prior to processing Security scans Detect vulnerabilities Standardize/revise best practice components Protected space Plugin access granted only after authentication Make use of “built in” system security container Isolate Abusive Access lockout access until user can explain cause and prove it has been addressed.

Discussion Break Who’s worried about security? (Am I doing enough?) Who’s had security issues? Who’s put off using a feature due concerns?

Risk Management “100% secure system --Chernobyl Method-- unplug the box and bury it under 100 tons of cement” Alternative Scheme: Sound workflow policy for using technology Best practices Monitoring Isolation - minimum amount of access necessary Routine security testing Regulatory review boards Data Breach Insurance personal note: Most data issues have been caused by users using regular features -KE