subject: New AUSKF Membership Website Security Concerns

1. The new website will be collecting a large amount of Personally Identifiable Information (PII) from a large membership base. It will be necessary to know where, geographically, the population is drawn from as each jurisdiction has different requirements. Should there be a breach, different jurisdictions have differing definitions of what constitutes a breach, what triggers breach notifications and what timelines must be adhered to. It's good to know this ahead of time rather than having to figure it out after a breach occurs. Being a US-based organization, I assume it will only have American users. However, if it has PII from foreign citizens, the countries where they reside may also have differing laws.
   Should a breach occur we have a plan in place to notify the members of the event and a fail safe mechanism that requires a password reset with email verification upon next access to the website.

2. Separate, but similar to the above, is the necessary data handling laws. Within the US, you're pretty safe. However, if data is collected on foreign citizens, the data collection laws for those locations will need to be followed.
   We are currently following industry recognized standards for data security and in many cases exceeding these standards.

3. The type of data that's collected will need to be examined. If it contains any data types that could be considered protected health information, additional data protection requirements may apply. I believe that as AUSKF is not a health provider, school/university, or health clearing house, that these requirements probably don’t apply.
   The law you are referring to is called HIPPA (Health Insurance Portability and Accountability Act of 1996). We do not collect, store analyze or make available storage of any data that falls under the HIPPA category.

4. The data being collected may be for members that are under the age of 13. I know that data regarding minors must be handled carefully, and believe (though I'm not positive) that people under the age of 13 have additional requirements.
   The law you are referring to is called the Children's Online Privacy Protection Act enacted in 1998. This law applies to the operators of commercial websites and online services (including mobile apps) directed to children under 13 that collect, use, or disclose personal information from children. It also applies to operators of general audience (we fall under this identifier) websites or online services with actual knowledge that they are collecting, using, or disclosing personal information from children under 13. The Rule also applies to websites or online services that have actual knowledge that they are collecting personal information directly from users of another website or online service directed to children.

   We have included the appropriate provisions to ensure that persons under the age of 13 are not allowed to register or login to the site to interact with the site. Given this, we do need to be able to register children under the age of 13 so that their memberships can be paid, dues or fees updated etc. This requires that a legal guardian (either a member or non-participating member) register on behalf of the child and acknowledge the data collection we require and accept the privacy policy we have set forth. This is in compliance with the FTC. We do not share our PII data with any third party. Even during the collection of fees/dues all members are required to enter their information directly with our financial vendor.

   What does this mean for the usage model where a dojo representative registers some or all of their dojo members?
   This is a special case. If the dojo representative wishes to register all members we will need explicit consent from the legal guardian. This can be achieved at the dojo level via parental consent or unfortunately we will need the guardian to actually register their children. This is because the law does not allow us to knowingly store even temporary data for children under 13.

   If the dojo rep that is doing the registration has a contact email for the parents then during registration we can offer to notify the guardian/parent in an email and provide a link for them to follow to complete the registration process. This is not current functionality, however I can make this happen in short order.

5. Special care must be taken to harden the website against attack. Here are some recommendations.
   1. Enable HTTPS for the website and redirect all traffic to use HTTPS. The HTTP port should only be used to redirect traffic to the secure site.
   2. Use an SSL certificate to secure the website. Using a certificate from a known Certificate Authority will cause the "lock" on the browser to show that the connection is secure without displaying a warning dialog about an "unauthenticated or self-signed certificate". There are low-cost and free SSL certs available (e.g. https://letsencrypt.org).
      All traffic to the site is being done over SSL. We have a 2048 bit SHA-2 cert purchased specifically for this site, serial number: c5:57:01:8c:23:f2:1f:db issued by godaddy.com whom is in the global trust.

   3. Use encryption on the data at rest. If the site is breached, you don't want the hackers having full access to all members' data.
      We are currently not encrypting all data as this is not only not necessary, it is not considered a breach of confidence or requirement by the FTC and has been determined to fall under the category of onerous requirements with dubious value.

   4. Be aware of common vulnerabilities when coding. I use the OWASP Top 10 as a good starting point (https://www.owasp.org/images/f/f8/OWASP_Top_10_-_2013.pdf). This is an Open Source project which attempts to identify the most common vulnerabilities and is updated (about) every 3 years. 2013 is the latest update. Of particular concern are cross-site scripting and SQL injection vulnerabilities. These can both be mitigated with adequate user input filtering and validation.
      Thank you for the recommendation, we are quite familiar with this work and have actually contributed in the past to this project. Regarding cross-site scripting aka XSS, we do not allow the posting of any potentially hazardous information that could then be displayed to another user. This is accomplished through a layered system of security starting with the generation of anti-forgery tokens during form submission that must match on the server, and also disallowing the posting and processing of any text that could be interpreted at runtime by any browser as script. ASP.Net and IIS by default do not allow dangerous text to be posted, this is the default behavior as of version 6 (we are using version 8). In addition to the anti-forgery and built in protections, we also http-encode form data with strips out any characters that could be used for an XSS attack. And finally, we do not display any user generated content other than user information to the logged in user .

   5. Don't handle financial data unless absolutely necessary. The requires compliance with additional Payment Card Industry - Data Security Standards (PCI-DSS). Instead, it would be better to have a link that allows people to pay via Paypal or similar processor.
      We are completely PCI (Payment Card Industry) compliant. https://www.pcicomplianceguide.org/pci-faqs-2/ Not only do we not collect and store any financial information, we never have any financial information even transmitted to our servers. We use a third party financial service that through an encrypted connection communicates directly to the end user to gather any needed information. This service then processes this information and provides us (the membership site) with a one use, short lived (1 minute) token which we can submit back to the service to request a charge that has been previously (either one time or recurring at the user's discretion) authorized by the end user to the third party financial institution. As such no sensitive information is stored either in persistent, durable or volatile storage on our site or accessed by our code base.

   6. If financial data is kept, encrypt everything and keep it separate from the PII of the members.

6. Have a penetration test or vulnerability assessment performed. Using the same methods a malicious hacker uses, the pen tester will attempt to break into the application and exfiltrate data. The "White-Hat" hacker can then explain what the vulnerabilities were and how to fix them.
   We currently are actively doing this.

7. Get cyber-insurance. It's becoming common for insurers to exclude cyber as part of their liability coverage. Check the AUSKF policy. Even a "small" breach can be very expensive.

8. Get AUSKF lawyers involved. Stories of data breaches continue to show up in the news. Knowing, ahead of time, what to do in the event of a breach can greatly speed the recovery and reduce costs. Getting the lawyers to help identify the data protection laws involved and create incidence response plans can help minimize future potential costs.

I hope I did not unnecessarily frighten the federation away from implementing a website. I think using the old spreadsheets were cumbersome and look forward to using a more modern tool. I just wanted provide some feedback that could help the federation avoid future embarrassment and/or expenses.

Thank you for your time.
Daniel Ouellette, CISSP

Thank you for such a prompt and thorough response. This greatly eases my mind concerning the website development and I'm glad to see that these issues are already being actively discussed and addressed by the developers. Given that the appear to be well versed in PCI compliance, COPA, and other relevant regulations, I don't see any reason to be overly concerned with the implementation. My only remaining recommendation would be to enlist the help of some penetration testers or the use of a vulnerability scanner during the QA to validate the implementation. Otherwise, I think this looks great. Again, thanks for addressing our concerns.

Daniel Ouellette, CISSP

• 1/14/17: Jan SCKF BoD meeting, continue discussion from Dec 12/3/16 meeting re AUSKF new fees and membership system
• 1/16-18/17: above email thread
• 2/4/17: Feb SCKF BoD meeting, continue discussion from Jan meeting, including the above thread
• 2/5/17: send request letter to AUSKF including unanswered concerns from the above thread
• 2/24/17: send 2nd letter to AUSKF including jurisdiction (state law) concerns from the above thread