1. Section 1 (Firewall)
1.1. Network Diagram
1.1.1. 1.1.2.a
1.1.1.1. Document all connections between the cardholder data environment and other networks, including any wireless networks
1.1.2. 1.1.3.a
1.1.2.1. Diagram that shows all cardholder data flows across systems and networks
1.1.3. 1.1.6.a
1.1.3.1. Documented list of services, protocols, and ports, including business justification and approval for firewalls and routers.
2. Section 2 (Vendor Defaults)
2.1. 2.2.5b
2.1.1. Are enabled functions documented and do they support secure configuration?
2.1.1.1. All we care about is the public-facing servers, and that the only functions/programs running on them are ones vital to the purpose they serve, and that they are not vulernable
2.1.1.2. Control Result | Unified Compliance
3. Section 5 (Anti-virus)
3.1. Just public facing servers
3.1.1. Load balancer, Web server, NFS
3.2. Document polices for maintenance, use, and scaling
3.3. Implementing
3.3.1. Clamav (generic and low-quality)
3.3.2. Maldetect (PHP cases)
4. Section 6 (Development)
4.1. 6.4.5
4.1.1. document change-control procedures
4.2. 6.5.9
4.2.1. Do coding techniques address cross-site request forgery (CSRF)?
4.2.1.1. Not needed -- no cc data stored in session; processing handled off-site
4.3. 6.7
4.3.1. Document security policies and operational procedures for developing and maintaining secure systems and applications
5. Section 8 (Unique ID)
5.1. Get software to
5.1.1. 8.1.6.a
5.1.1.1. Lock out the user ID after no more than six attempts
5.1.2. 8.1.7
5.1.2.1. Lockout duration set to a minimum of 30 minutes or until an administrator enables the user ID
5.1.3. 8.1.8
5.1.3.1. If a session has been idle for more than 15 minutes, users required to re-authenticate (for example, re-enter the password) to re-activate the terminal or session
5.1.4. Two hours to execute
5.1.4.1. Only SSH related
5.1.4.1.1. Custom firewall in place -- have to find software that won't interfere
5.2. 8.3.2
5.2.1. Incorporate multi-factor authentication for all remote network access (both user and administrator, and including third party access for support or maintenance) originating from outside the entity’s network
5.2.1.1. Ask SM if multi-factor on VPN is enough
5.2.1.2. the only way to get in our servers is via SSH, after being connected to a VPN that gives access to the private network used by the servers. We can't enable 2FA on the SSH servers, but we can enable 2FA on the VPN accounts that are used to gain access to the network. Will that suffice?
5.2.1.2.1. Yes, that's fine.
5.2.1.3. (and is it even necessary? Can we say N/A given that we passed network pen test?)
5.2.1.3.1. It is necessary.
5.2.1.4. Probably easy
5.2.1.4.1. 1 hour
5.2.1.5. VPN Server lock-down
5.2.1.5.1. 1 hour
5.3. 8.4.a
5.3.1. Document authentication procedures and policies and ensure they are communicated to all users
5.3.1.1. Must include
5.3.1.1.1. Guidance on selecting strong authentication credentials Guidance for how users should protect their authentication credentials Instructions not to reuse previously used passwords Instructions that users should change passwords if there is any suspicion the password could be compromised
5.4. 8.8
5.4.1. Document security policies and operational procedures for identification and authentication
6. Section 10 (Logging)
6.1. Raul
6.1.1. Logs
6.1.1.1. Review section 10 to ensure all tickies can be checked off
6.1.2. Alerts
6.1.2.1. (if not Cosmin/Raul's IP)
6.1.2.2. (if cardholder data environment files be changed
6.1.2.3. Logins
6.1.2.4. User/Group Changes
6.1.2.5. System executables Application executables Configuration and parameter files
6.1.2.6. emails to [email protected]
6.1.2.6.1. and [email protected] alerts
6.1.3. No documentation requirements in this section, but they may be addressed in another section
7. Section 11 (Testing)
7.1. We did not talk about these
7.1.1. 11.4
7.1.1.1. intrusion-detection and/or intrusion-prevention techniques that detect and/or prevent intrusions into the network in place to monitor all traffic
7.1.1.1.1. handled by periodic penetration testingt
7.1.2. 11.5
7.1.2.1. change-detection mechanism (for example, file-integrity monitoring tools) deployed within the cardholder data environment to detect unauthorized modification (including changes, additions, and deletions) of critical system files, configuration files, or content files
7.1.2.1.1. Manually, yes.
7.1.2.1.2. Alerts to follow
7.1.3. Is it enough to rely on periodic pen testing (and if the pen testing comes up clean, assume we can't be changed?
7.1.3.1. That's really up to us. How hard is it to implement these? How confident are we that we'll know if anything changed?
8. Section 12 (Policy)
8.1. Purchase Security Policy boilerplate
8.2. Adapt to Kartra
8.2.1. Documents
8.2.1.1. SAQ Base Security Policies
8.2.1.1.1. Just needs to be signed by Raul
8.2.1.2. Virtual Firewall Configuration Standards
8.2.1.2.1. 1.1. and 1.2 Co-locate diagrams and properly direct
8.2.1.2.2. 1.4 through 1.7 tables to be filled out
8.2.1.3. System Hardening and Configuration Standards
8.2.1.3.1. Table 1.2.a
8.2.1.3.2. Table 1.4.a
8.2.1.3.3. 2.1
8.2.1.3.4. 2.2
8.2.1.4. Kartra Vulnerability Discovery and Risk Ranking Process v.3.2.1.docx
8.2.1.4.1. Appendix 3 and 4
8.2.1.5. Kartra Operating Procedures v.3.2.1.docx
8.2.1.5.1. The procedures are specific to our install, but once documented here, we can tick documentation off our list
8.2.1.6. Kartra Security Awareness Training Process v.3.2.1.docx
8.2.1.6.1. Done
8.2.1.7. Kartra Incident Response Plan v.3.2.1.docx
8.2.1.7.1. Identification and Assessment (11.4 an 11.5 procedures)
8.2.1.8. Kartra Risk Assessment Process v.3.2.1.docx
8.2.1.8.1. Identification of risks
8.2.1.9. (Indices for all)