As part of our application development team, you are the first line of defense

against cyber criminals trying to hack into and access cardholder data. While it is
unlikely you will directly interact with cardholder data, you are tasked with
ensuring it can only be accessed by those with a business need-to-know and that
your systems are configured in a secure manner.

Let’s look again at the core objectives of PCI DSS and how you can help protect
our customers’ cardholder data. Please note that in some cases our policies may be
more stringent than the PCI DSS, and if so, those policies should be followed as
well.

The first objective is to Build and Maintain a Secure Network and Systems, which
includes the following requirements: Install and Maintain Network Security
Controls and Apply Secure Configurations to All System Components. To do this:

Maintain up-to-date network and architecture diagrams of your application. This is

easy to overlook but is very important in your audit.

If you deploy a vendor-supplied application with default passwords or usernames,

change them before deployment. These are often well-known and can result in an
easily found back door into your network.

The second objective is to Protect Account Data, which includes the following
requirements: Protect Stored Account Data and Protect Cardholder Data with
Strong Cryptography During Transmission Over Open, Public Networks. To do
this:

Encrypt stored cardholder data at rest and in transit. Protect encryption keys used
for this purpose.
The encryption used should be industry-standard and the strongest possible. Never
use custom, outdated, or insecure encryption protocols (such as WEP).

‘Mag Stripe’ data, CVV2 data, or PIN data should not be maintained after
authorization anywhere, even if encrypted. Additionally, this type of sensitive
authentication data must be encrypted from the time it is captured until it is
removed from the system once authorization is complete.

Ensure your system masks credit card numbers when displayed on screens or
printouts.

Ensure technologies like chat or email can protect credit card data, or do not allow
it to be transmitted via these mediums.

Follow the data retention policies for cardholder data, and ensure data is deleted
according to those policies.

Validate every quarter that these controls are still in place.

The third objective is to Maintain a Vulnerability Management Program, which

includes the following requirements: Protect All Systems and Networks from
Malicious Software and Develop and Maintain Secure Systems and Software.

Have a process to identify and categorize new vulnerabilities in software packages.

Fix these issues according to severity.

If developing applications that handle cardholder data, ensure they use secure
coding best practices, such as the ones provided by the Open Web Application
Security Project, or OWASP. Security requirements should be defined and
followed in all stages of the System Development Life Cycle.

Perform code reviews of custom code as well as tests of public-facing applications

before release and at least annually.

Use documented change management techniques and get approvals before

deploying code to production.

Inventory all bespoke and custom software, as well as all third-party software
components used in your code.

If your applications contain code that runs in a user’s browser, inventory all scripts
that run on payment pages and ensure the integrity of these scripts.

Understand and document the roles and responsibilities of your team regarding
secure software development.

The fourth objective is to Implement Strong Access Control Measures, which

includes the following requirements: Restrict Access to System Components and
Cardholder Data by Business Need to Know, Identify Users and Authenticate
Access to System Components, and Restrict Physical Access to Cardholder Data.

Create roles to manage users and assign users to these roles when access is
requested and approved.

Make sure approvals are documented and appropriate. While it can be tempting to
allow an emergency access request without approval, the safety of our customers’
data may depend on that approval.

Authenticate users to systems with at least a user ID and password. Rotate and lock
out credentials as needed.

Do not allow the use of shared accounts to access systems.

Review the users that have internal access to systems at least every 6 months. If
someone has left the company or the team, their access should be removed if it is
no longer needed.

Secure all remote access to cardholder data environments via two-factor

authentication.

Log access to cardholder data at all tiers of an application.

Protect point-of-sale devices from tampering and inspect them periodically for
damage.

The final objective we will review is to Regularly Monitor and Test Networks,
which includes the following requirements: Log and Monitor All Access to System
Components and Cardholder Data and Test Security of Systems and Networks
Regularly.

Log access to cardholder data. The level of logging should be able to tell you the
user’s identity, what actions they performed or what data they viewed, and when
they did it.

Have penetration tests performed annually.

If your team has specific responsibilities related to PCI requirements, ensure that
you maintain documentation on these roles and responsibilities and that the team
understands them.

While you may not be directly responsible for all of these requirements in your job,
you will be involved with many of them depending on your role. Additionally, as a
developer, you may be heavily involved with PCI DSS audits. To facilitate these
audits, maintain good records of changes and hardening as well as documentation
of the cardholder data environment, and be able to provide them upon request.
Your role, and your diligence, is crucial to a successful audit and your team’s
success.