|
6.1 Ensure
that all system components and software have the latest
vendor-supplied security patches installed. Install critical security
patches within one month of release.
Update your system at least once a month with any new patches.
6.2 Establish
a process to identify newly discovered security vulnerabilities
Subscribe to the mailing list for packages you run, and to mailings
lists such as BugTraq at http://www.securityfocus.com/
6.3.1 Testing
of all security patches, and system and software configuration
changes before deployment, including but not limited to the
following:
Any patches, updates, etc, should be tested, in a dev or QA environment
before being installed in the production environment.
Among the things to test for in 6.3.1 are:
6.3.1.1 Validation
of all input (to prevent cross-site scripting, injection flaws,
malicious file execution, etc.)
6.3.1.2 Validation
of proper error handling
6.3.1.3 Validation
of secure cryptographic storage
6.3.1.4 Validation
of secure communications
6.3.1.5 Validation
of proper role-based access control (RBAC)
6.3.2 Separate
development/test and production environments
Your test environment should be on seperate servers, on a
seperate network than you production environment.
6.3.3 Separation
of duties between development/test and production environments
Seperate employees should do the development, and seperate employees do
the testing/release to production.
6.3.4 Production
data (live PANs) are not used for testing or development
Have a set of test data, such as fake credit card numbers to use for
testing
6.3.5 Removal
of test data and accounts before production systems become active
Remove the data form 6.3.4 and any logins used for testing before
releasing to production
6.3.6 Removal
of custom application
accounts, user IDs, and passwords
before applications become active or are released to customers
Similar to 6.3.5
6.3.7 Review
of custom code prior to release to production or customers in order
to identify any potential coding vulnerability
Have someone other than the code author test the code for
vulnerabilities, such as testing for the thigns in 6.3.1
6.4 Follow
change control procedures for all changes to system components. The
procedures must include the following:
Create a policy for this, store with your other documents and policies.
Your policy in 6.4 should include:
6.4.1 Documentation
of impact
6.4.2 Management
sign-off by appropriate parties
6.4.3 Testing
of operational functionality
6.4.4 Back-out
procedures
6.5 Develop
all web applications (internal and external, and including web
administrative access to application) based on secure coding
guidelines such as the Open
Web Application Security Project Guide
Create a policy for coding web
applications, be familiar with
the OWASP
guide
(http://www.owasp.org).
Your policy for 6.5 should include protection against:
6.5.1 Cross-site
scripting (XSS)
6.5.2 Injection
flaws, particularly SQL injection. Also consider LDAP and Xpath
injection flaws as well as other injection flaws.
6.5.3 Malicious
file execution
6.5.4 Insecure
direct object references
6.5.5 Cross-site
request forgery (CSRF)
6.5.6 Information
leakage and improper error handling
6.5.7 Broken
authentication and session management
6.5.8 Insecure
cryptographic storage
6.5.9 Insecure
communications
6.5.10 Failure
to restrict URL access
-
6.6 For
public-facing web applications, address new threats and
vulnerabilities on an ongoing basis and ensure these applications are
protected against known attacks by either
of the following methods:
-
Reviewing public-facing web applications
via manual or automated application vulnerability security assessment
tools or methods, at least annually and after any changes
-
Installing a web-application firewall in
front of public-facing web applications
Pen test your web applications at least annually. Use a layer 7,
web application firewall such as http://www.modsecurity.org/
|
