Sunday, May 20, 2012

Security: PCI Compliance

The Payment Card Industry Data Security Standard (PCI DSS) is a set of requirements designed to ensure that all companies that process, store or transmit credit card information maintain a secure environment.


Merchant levels as defined by Visa:
1: Any merchant processing over 6M Visa transactions per year
2: Any merchant processing 1M to 6M Visa transactions per year.
3: Any merchant processing 20,000 to 1M Visa e-commerce transactions per year.
4: Any merchant processing fewer than 20,000 Visa e-commerce transactions per year and other merchants processing up to 1M Visa transactions per year


Best Practices
·       Process transactions immediately online or hand off the processing to your bank
·       Do not store any CC numbers, ever. If they must be stored, you must follow the PCI guidelines to the letter. 
·       If you are using a shared host for your site, you cannot comply with the PCI guidelines. You must have your own infrastructure to comply with the PCI guidelines.

If you do end up storing CC numbers:
  • Encrypt them.
  • follow merchant agreement.
  • for recurring payments, limit term to 1 year.
Other considerations:
  • PCI only allows presentation of first six ( the BIN) or last four digits.
  • Must nore store CCV etc.
  • Must patch system within 1 month of a patch becoming available.
  • reversals should be signed off by two distinct employees.
12 requirements of PCI-DSS if you are going to handle credit cards:


Build and maintain a secure network

  • Install and maintain a firewall configuration to protect data

  • Do not use vendor-supplied defaults for system passwords and other security parameters
Protect Cardholder Data
  • Protect stored data

  • Encrypt transmission of cardholder data and sensitive information across public networks
Maintain a Vulnerability Management Program
  • Use and regularly update anti-virus software

  • Develop and maintain secure systems and applications
Implement Strong Access Control Measures
  • Restrict access to data by business need-to-know

  • Assign a unique ID to each person with computer access

  • Restrict physical access to cardholder data
Regularly Monitor and Test Networks
  • Track and monitor all access to network resources and cardholder data

  • Regularly test security systems and processes
Maintain an Information Security Policy


  • Maintain a policy that addresses information security

PCI Sections Addressing Application Security



  • 3.1 Protect stored cardholder data 
  • 3.2 Protect authentication data 
  • 3.4 Protect Personal Account Numbers (PAN) data
  • 4.1 Encrypt transmission of cardholder data across public networks
  • 6.3 Develop and maintain secure applications
  • 6.5 Develop web applications using secure coding 
  • 6.6 Protect web applications against known attacks
  • 8.1 Assign a unique ID to each person with computer access
  • 10.1 Track and monitor all access to network resources and cardholder data
  • 10.2 Implement automated audit trails
  • 10.3 Record audit trail events
  • 11.3 Regularly test security systems and processes
  • 11.4 Use intrusion detection/ prevention systems



PA-DSS Summary

  • Do not retain full magnetic stripe, card verification code or value (CAV2, CID, CVC2, CVV2), or PIN block data
  • Protect stored cardholder data 
  • Provide secure authentication features
  • Log payment application activity 
  • Develop secure payment applications  
  • Protect wireless transmissions  
  • Test payment applications to address vulnerabilities  
  • Facilitate secure network implementation  
  • Cardholder data must never be stored on a server connected to the Internet  
  • Facilitate secure remote access to payment application  
  • Encrypt sensitive traffic over public networks  
  • Encrypt all non-console administrative access  
  • Maintain instructional documentation and training programs for customers, resellers, and integrators

Sunday, May 6, 2012

Sarbanes Oxley (SOX)



SOX affects information security and the below are two specific sections of the act:

section 302: Corporate responsibility for financial reports

Section 302 states that the Chief Executive Officer (CEO) and Chief Financial  Officer (CFO) must personally certify that financial reports are accurate and complete. They must also assess and report on the effectiveness of internal controls around financial reporting.


section 404: Management assessment of internal controls


Section 404 states that a corporation must assess the effectiveness of its internal controls and report this assessment annually to the SEC. The assessment must
also be reviewed and judged by an outside auditing firm.


Public Company Accounting Oversight Board (PCAOB)

The role of PCOAB is to oversee and guide auditors as they assess a company’s compliance with SOX.
"Proposed Auditing Standards" provide more detailed guidance for assessing compliance with the intent of SOX. information technology (IT) general controls form the foundation for many other types of financial reporting controls and, therefore, must be assessed for SOX.

COSO & COBIT

For the purpose of internal control guidance, PCAOB has selected a control
framework created by the Committee of Sponsoring Organizations (COSO). The
COSO framework provides a structured and comprehensive set of guidelines for
creating and implementing internal controls.

The Information Technology Governance Institute (ITGI) is a group created to assist corporations with governing their IT and ensuring IT efficiently supports business mission and goals. ITGI has used COSO and COBIT to create a set of specific IT control objectives for SOX.

references

http://pcaobus.org

http://www.coso.org/default.htm
http://www.isaca.org/