SimpleTix: PCI Compliant Solution
SimpleTix is in compliance with the Payment Card Industry (PCI) Data Security Standards (DSS).
Visa, MasterCard, and the other major credit cards have jointly developed these strict security regulations to make sure that your credit card information is safe when you use your credit card in a store and on-line.
In order to become PCI Compliant, organizations must undergo extensive reviews to make sure their technology and security meet the rigorous requirements. This is a time consuming and expensive process.
Does my organization have to be PCI Compliant?
Instead of going through the rigors of PCI compliance, you can use a vendor who offers a PCI-compliant solution.
Because SimpleTix is PCI Compliant, we take care of all the details, worry and liability… so you don’t have to. By choosing SimpleTix, you have peace of mind because your members’ data is protected at the highest level.
PCI DSS New Self-Assessment Questionnaire (SAQ) Notes
Cross-side scripting (XSS)? (SAQ #6.5.1)
Website users are never given access to post/save any type of HTML. All data that comes from user input is sanitized before saving to the database. This includes stripping out any scripting and HTML.
Information leakage and improper error handling?
The default setting in the web.config redirects all errors to user-friendly error pages. This prevents any type of information leakage from being leaked to the end-user.
Is access to system components and cardholder data limited to only those individuals whose jobs require such access? (SAQ #7.1) & (SAQ #7.1.1)
SimpleTix uses role based security. Only users with the role of Box Office can view cardholder data.
Are all users assigned a unique ID before allowing them to access system components or cardholder data? (SAQ #8.1)
Every user in the system has a unique user name.
Are all passwords rendered unreadable during transmission and storage on all system components using strong cryptography (see help for definition)? (SAQ #8.4)
SimpleTix uses the Microsoft .Net Membership Framework. All passwords are stored in the database in an one-way encrypted fashion. They can never be retrieved to revealed. They can only be reset and validated.
Is user identity verified before performing password resets? (SAQ #8.5.2)
Yes, they must enter a CAPTCHA phrase. This prevents robots. Then they must have access to the correct email account.
Is access for any terminated users immediately revoked? (SAQ #8.5.4)
When a staff member leaves, is terminated, or is on vacation the webmaster can simply remove the role of Box Office. Later if they return it’s easy to re-apply the role again.
Are password procedures and policies communicated to all users who have access to cardholder data?(SAQ #8.5.7)
All users system-wide are required to use strong passwords. Users with access to cardholder data are given security warnings when the log in.
Is a minimum password length of at least seven characters required?(SAQ #8.5.10)
Yes, you cannot event create a user account with less than 7 characters.
Must passwords contain both numeric and alphabetic characters?(SAQ #8.5.11)
All users is Admin, Manager, and Box Office are required to use a strong password with numbers, letters, and symbols.
If a session has been idle for more than 15 minutes, must the user re-enter the password to re-activate the terminal?(SAQ #8.5.15)
Yes, and this can be set in the ~/web.config file.
Injection flaws, particularly SQL injection? (SAQ #18.104.22.168)
All SQL statements use stored procedures or parameterized SQL. This prevents any type of SQL Injection as all of the variables are sanitized before being used.
Disable inactive accounts after 90 days
All users with Box Office, Manager, Admin roles with have their account flagged as inactive if there is no activity for 90 days.