NIST Requirements
NIST Requirements
NIST Requirements
IDENTIFY (ID)
Governance (ID.GV): The policies, procedures, and processes to
manage and monitor the organization’s regulatory, legal, risk,
environmental, and operational requirements are understood and inform
the management of cybersecurity risk.
PROTECT (PR)
RESPOND (RS)
Analysis (RS.AN): Analysis is conducted to ensure adequate response
and support recovery activities.
Governance and
Compliance
Baseline
Atos PPS
Subcategory
ID.AM-1: Physical devices and systems within the organization are inventoried
ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-
party stakeholders (e.g., suppliers, customers, partners) are established
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.BE-2: The organization’s place in critical infrastructure and its industry sector is
identified and communicated
ID.BE-4: Dependencies and critical functions for delivery of critical services are
established
ID.BE-5: Resilience requirements to support delivery of critical services are
established
ID.GV-1: Organizational information security policy is established
ID.GV-2: Information security roles & responsibilities are coordinated and aligned
with internal roles and external partners
ID.RA-5: Threats, vulnerabilities, likelihoods, and impacts are used to determine risk
PR.AC-1: Identities and credentials are managed for authorized devices and users
PR.DS-6: Integrity checking mechanisms are used to verify software, firmware, and
information integrity
PR.DS-7: The development and testing environment(s) are separate from the ,
production environment
PR.IP-1: A baseline configuration of information technology/industrial control
systems is created and maintained
PR.IP-2: A System Development Life Cycle to manage systems is implemented
PR.IP-5: Policy and regulations regarding the physical operating environment for
organizational assets are met
PR.IP-6: Data is destroyed according to policy
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-10: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
DE.AE-1: A baseline of network operations and expected data flows for users and
systems is established and managed
DE.AE-2: Detected events are analyzed to understand attack targets and methods
DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors
CP-8, PE-9, PE-11, PM-8, SA-14 A.11.2.2, A.11.2.3, A.12.1.3 CP-8, PE-9, PE-11, PM-8, SA-
14
CP-2, CP-11, SA-14 A.11.1.4, A.17.1.1, A.17.1.2, A.17.2.1 CP-2, CP-11, SA-14
CA-2, CA-7, CA-8, RA-3, RA-5, SA-5, A.12.6.1, A.18.2.3 CA-2, CA-7, CA-8, RA-3, RA-
SA-11, SI-2, SI-4, SI-5 5, SA-5, SA-11, SI-2, SI-4, SI-
5
AC-4, AC-5, AC-6, PE-19, PS-3, PS-6, A.6.1.2, A.7.1.1, A.7.1.2, A.7.3.1, AC-4, AC-5, AC-6, PE-19, PS-
3, PS-6, SC-7, SC-8, SC-13,
SC-7, SC-8, SC-13, SC-31, SI-4 A.8.2.2, A.8.2.3, A.9.1.1, SC-31, SI-4
SI-7 A.12.2.1, A.12.5.1, SI-7
CM-2, CM-3, CM-4, CM-5, CM-6, CM- A.12.1.2, A.12.5.1, CM-2, CM-3, CM-4, CM-5,
7, CM-9, SA-10 CM-6, CM-7, CM-9, SA-10
SA-3, SA-4, SA-8, SA-10, SA-11, SA-12, A.6.1.5, A.14.1.1, A.14.2.1, A.14.2.5 SA-3, SA-4, SA-8, SA-10, SA-
SA-15, SA-17, PL-8 11, SA-12, SA-15, SA-17, PL-
8
CM-3, CM-4, SA-10 A.12.1.2, A.12.5.1, A.12.6.2, A.14.2.2, CM-3, CM-4, SA-10
A.14.2.3, A.14.2.4
CP-4, CP-6, CP-9 A.12.3.1, A.17.1.2A.17.1.3, A.18.1.3 CP-4, CP-6, CP-9
PE-10, PE-12, PE-13, PE-14, PE-15, A.11.1.4, A.11.2.1, A.11.2.2, A.11.2.3 PE-10, PE-12, PE-13, PE-14,
PE-18 PE-15, PE-18
MP-6 A.8.2.3, A.8.3.1, A.8.3.2, A.11.2.7 MP-6
A-2, CA-7, CP-2, IR-8, PL-2, PM-6 Gap A-2, CA-7, CP-2, IR-8, PL-2,
PM-6
MP-2, MP-4, PM-5, PM-7 A.8.2.2, A.8.2.3, A.8.3.1, A.8.3.3, MP-2, MP-4, PM-5, PM-7
A.11.2.9
AC-3, CM-7 A.9.1.2 AC-3, CM-7
AC-4, AC-17, AC-18, CP-8, SC-7 A.13.1.1, A.13.2.1 AC-4, AC-17, AC-18, CP-8,
SC-7
AU-6, CA-7, IR-4, SI-4 A.16.1.1, A.16.1.4 AU-6, CA-7, IR-4, SI-4
AU-6, CA-7, IR-4, IR-5, IR-8, SI-4 Gap AU-6, CA-7, IR-4, IR-5, IR-8,
SI-4
AC-2, AU-12, AU-13, CA-7, CM-10, A.12.4.1 AC-2, AU-12, AU-13, CA-7,
CM-11 CM-10, CM-11
SI-3 A.12.2.1 SI-3
SC-18, SI-4. SC-44 A.12.5.1 SC-18, SI-4. SC-44
CA-7, PS-7, SA-4, SA-9, SI-4 A.14.2.7, A.15.2.1 CA-7, PS-7, SA-4, SA-9, SI-4
AU-12, CA-7, CM-3, CM-8, PE-3, PE-6, Gap AU-12, CA-7, CM-3, CM-8,
PE-20, SI-4 PE-3, PE-6, PE-20, SI-4
AU-6, CA-2, CA-7, RA-5, SI-4 A.16.1.2 AU-6, CA-2, CA-7, RA-5, SI-4
CA-2, CA-7, PL-2, RA-5, SI-4, PM-14 A.16.1.6 CA-2, CA-7, PL-2, RA-5, SI-4,
PM-14
AU-6, CA-7, IR-4, IR-5, PE-6, SI-4 A.12.4.1, A.12.4.3, A.16.1.5 AU-6, CA-7, IR-4, IR-5, PE-6,
SI-4
IDENTIFY (ID)
PROTECT (PR)
RESPOND (RS)
Communications (RS.CO): Response activities are coordinated with
internal and external stakeholders, as appropriate, to include external
support from law enforcement agencies.
RESPOND (RS)
Analysis (RS.AN): Analysis is conducted to ensure adequate response
and support recovery activities.
ID.AM-1: Physical devices and systems within the organization are inventoried
ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-
party stakeholders (e.g., suppliers, customers, partners) are established
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.BE-2: The organization’s place in critical infrastructure and its industry sector is
identified and communicated
ID.BE-4: Dependencies and critical functions for delivery of critical services are
established
ID.BE-5: Resilience requirements to support delivery of critical services are
established
ID.GV-1: Organizational information security policy is established
ID.GV-2: Information security roles & responsibilities are coordinated and aligned
with internal roles and external partners
PR.AC-1: Identities and credentials are managed for authorized devices and users
PR.AC-2: Physical access to assets is managed and protected
PR.AC-3: Remote access is managed
PR.AC-4: Access permissions are managed, incorporating the principles of least
privilege and separation of duties
PR.IP-5: Policy and regulations regarding the physical operating environment for
organizational assets are met
PR.IP-6: Data is destroyed according to policy
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-10: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
DE.AE-2: Detected events are analyzed to understand attack targets and methods
DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors
Firewalls are devices that control computer traffic allowed between an entity’s networks (internal) and untrusted networks (exter
traffic into and out of more sensitive areas within an entity’s internal trusted networks. The cardholder data environment is an ex
sensitive area within an entity’s trusted network.
4
1.1.4 Requirements for a firewall at each Internet connection and
between any demilitarized zone (DMZ) and the internal network
zone
8
1.2 Build firewall and router configurations that restrict
connections between untrusted networks and any system
components in the cardholder data environment.
Note: An “untrusted network” is any network that is external to
9 the networks belonging to the entity under review, and/or which
is out of the entity's ability to control or manage.
10
11
1.3 Prohibit direct public access between the Internet and any
system component in the cardholder data environment.
13
1.3.1 Implement a DMZ to limit inbound traffic to only system
components that provide authorized publicly accessible services,
protocols, and ports.
14
15
Protection methods such as encryption, truncation, masking, and hashing are critical components of cardholder data protection
opportunities. For example, methods for minimizing risk include not storing cardholder data unless absolutely necessary, trunca
Please refer to the PCI DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms for definitions of “strong cryptograph
3.1 Keep cardholder data storage to a minimum by implementing
35 data retention and disposal policies, procedures and processes
that include at least the following for all cardholder data (CHD)
3.2
storage: Do not store sensitive authentication data after authorization
36 (even if encrypted). If sensitive
• Limiting data storage amountauthentication
and retention data time is to received,
that which
render
is required all data
for unrecoverable
legal, regulatory, upon
and completion
business of the
requirements
3.2.1 Do not store
authorization process.the full It iscontents
permissible of anyfor track
issuers (from
andthe
37 •magnetic Specificstripe retention
located requirements
on the back forofcardholder
a card, data
equivalent data
companies
•contained Processes that support
forchip,
secure issuing services
deletion of after to store
data authorization.
when no longer sensitive needed
authentication on a datathe or
if: card elsewhere) This data
•is alternatively
3.2.2 A quarterly
Do not store process
called fullfortrack,
identifying
verification
track, and code
track securely
1,ortrack
value deleting
2, stored
(three-digit
and
38 •or There
cardholderfour-digitis adata
business
number justification
that printed
exceeds theand
ondefined frontretention.
or back of a payment
magnetic-stripe
•card Theused data to is verifydata.
stored securely.
card-not-present transactions) after
Sensitive
3.2.3
authorization.Do not authentication
store the personal data includes the data
identification as cited
number in the
(PIN) or the
39 Note:
following
encrypted In the normal
blockcourse
Requirements
PIN after 3.2.1of through
business,
authorization. the following data
3.2.3:
elements from the magnetic stripe may need to be retained:
The
3.3 Mask cardholder’s
PAN whenname displayed (the first six and last four digits
40 Primary
are the maximum accountnumber numberof(PAN) digits to be displayed), such that
only Expiration
personnel date
with a legitimate business need can see more
3.4
Service
than Render
the first PAN
code Tounreadable
six/last minimize
four digits anywhere
risk,
of store
the PAN. it is stored
only these data (including on
elements
41 portable digital media, backup media, and in logs) by using any
as needed
Note: This for business.does not supersede stricter requirements
requirement
of
in the following
place for approaches:
displays of cardholder data—for example, legal or
3.4.1
• One-wayIf diskhashes
encryption based is used (rather
on strong than file-
cryptography, or (hash
column-level
must be
42 payment
database card brand
encryption), requirements for point-of-sale
logical access must be managed (POS)
of the
receipts. entire PAN)
•separately
3.5 Truncation
Document
and independently
(hashing
and cannot be
implement
of used
nativetooperating
procedures replace
to protect
system
the truncated
keys usedbyto
43 authentication
segment of PAN) and access control mechanisms (for example,
secure
not using stored cardholder
local anduserpads account data against
databases disclosure
or and
generalstored) misuse:
network login
•Note:Index tokens
This requirement (pads
applies must
to keysbe used
securely to encrypt stored
credentials).
•cardholder
Strong
3.5.1 Decryption
cryptography
Additional keys
withapplies
requirement must
associated
forto not be associated
key-management
service providers with
only:user
44 accounts. data, and also key-encrypting
Note: This keys
requirement used to
processes
Maintain
protect a and procedures.
documented
data-encrypting description
keys— ofkey-encrypting
suchDSS the cryptiongrfaphic keyskey-
must
applies
Note: It to
is additioin
aasrelatively to all other
trivial PCI
effort encryption
for a malicious and
architecture
be at
management least that
strongincludes:
requirements.as the data-encrypting key. individual to
•reconstruct
Details of all original PAN data
algorithms, if they and
protocols, havekeys access used to for
both
thethe
truncated and
protection hashed version
of cardholder of a PAN.key
data, including Where strengthhashed andandexpiry
truncated versions of the same PAN are present in an entity’s
date
•environment,
Description of additional
the key usage controls formust
eachbe keyin place to ensure that
the hashed of
• Inventory andany truncated
HSMs and versions cannotused
other SCDs be correlated
for key to
reconstruct the original PAN.
management
3.5.2 Restrict access to cryptographic keys to the fewest number
45 of custodians necessary.
3.5.3 Store secret and private keys used to encrypt/decrypt
46 cardholder data in one (or more) of the following forms at all
times:
3.5.4 Store cryptographic
• Encrypted keys in the
with a key-encrypting keyfewest
that is possible locations.
at least as strong as
47
the data-encrypting key, and that is stored separately from the
data-encrypting
3.6 Fully document keyand implement all key-management processes and procedures for cryptographic keys used for
48 • Within a secure cryptographic device (such as a hardware
(host) security module (HSM) or PTS-approved point-of-
interaction device)of strong cryptographic keys
3.6.1 Generation
49 • As at least two full-length key components or key shares, in
accordance with an industry-accepted method
3.6.2
Note:Secure
It is notcryptographic key distribution
required that public keys be stored in one of these
50
forms.
3.6.3 Secure cryptographic key storage
51
3.6.4 Cryptographic key changes for keys that have reached the
52 end of their cryptoperiod (for example, after a defined period of
time has passed and/or after a certain amount of cipher- text has
3.6.5 Retirementbyorareplacement
been produced given key), as (for example,
defined archiving,
by the associated
53 destruction, and/or or
revocation) ofand
keysbased
as deemed necessary
application vendor key owner, on industry best
when the
practices integrity
and of the
guidelines key
(for has been
example, weakened
NIST (for
Special example,
Publication
3.6.6 If manual
departure of an clear-text
employeecryptographic
with knowledge key-management
of a clear-text key
54 800-57).
operations
component), or keys are suspected of being be
are used, these operations must managed using
compromised.
split
Note: knowledge and dual
If retired orofreplaced control.
cryptographic keysofneed to be
3.6.7 Prevention
Note: Examples unauthorized
of manual key- substitution
management cryptographic
55 retained,
keys. these keys must be securely archivedoperations include,
(for example, by
but are not limited to: key generation, transmission,
using a key-encryption key). Archived cryptographic keys should loading,
storage
only be
3.6.8 and destruction.
used
Requirement for decryption/verification
for cryptographic keypurposes.
custodians to formally
56 acknowledge that they understand and accept their key-
custodian responsibilities.
3.7 Ensure that security policies and operational procedures for
57 protecting stored cardholder data are documented, in use, and
known to all affected parties.
Requirement 4: Encrypt transmission of cardholder data across open, public networks
Sensitive information must be encrypted during transmission over networks that are easily accessed by malicious individuals. M
Assigning a unique identification (ID) to each person with access ensures that each individual is uniquely accountable for their a
—particularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwo
The effectiveness of a password is largely determined by the design and implementation of the authentication system—particul
Note: These requirements are applicable for all accounts, including point-of-sale accounts, with administrative capabilities and
However, Requirements 8.1.1, 8.2, 8.5, 8.2.3 through 8.2.5, and 8.1.6 through 8.1.8 are not intended to apply to user accounts
8.1 Define and implement policies and procedures to ensure
108 proper user identification management for non- consumer users
and administrators on all system components as follows:
8.1.1 Assign all users a unique ID before allowing them to
109 access system components or cardholder data.
8.1.2 Control addition, deletion, and modification of user IDs,
110 credentials, and other identifier objects.
8.1.3 Immediately revoke access for any terminated users.
111
Requirement 10: Track and monitor all access to network resources and cardholder data
Logging mechanisms and the ability to track user activities are critical in preventing, detecting, or minimizing the impact of a dat
10.3 Record at least the following audit trail entries for all system
169 components for each event:
10.3.1 User identification
170
cal in preventing, detecting, or minimizing the impact of a data compromise. The presence of logs in all environments allows thorough track
es.
duals and researchers, and being introduced by new software. System components, processes, and custom software should be tested frequ
security for all personnel.
nd informs personnel what is expected of them. All personnel should be aware of the sensitivity of data and their responsibilities for protecti
sting Providers
with access to cardholder data (including shared hosting providers) must adhere to the PCI DSS. In addition, Requirement 2.6 states that s
Guidance
ernal), as well as
example of a more
Firewalls and routers are key components of the architecture that controls
entry to and exit from the network. These devices are software or
hardware devices that block unwanted access and manage authorized
access into and out of the network.
Configuration standards and procedures will help to ensure that the
organization’s first line of defense in the protection of its data remains
strong.
Network diagrams describe how networks are configured, and identify the
location of all network devices.
Without current network diagrams, devices could be overlooked and be
unknowingly left out of the security controls implemented for PCI DSS and
thus be vulnerable to compromise.
This review gives the organization an opportunity at least every six months
to clean up any unneeded, outdated, or incorrect rules, and ensure that all
rule sets allow only authorized services and ports that match the
documented business justifications.
Organizations with a high volume of changes to firewall and router rule
sets may wish to consider performing reviews more frequently, to ensure
that the rule sets continue to meet the needs of the business.
It is essential to install network protection between the internal, trusted
network and any untrusted network that is external and/or out of the
entity’s ability to control or manage. Failure to implement this measure
correctly results in the entity being vulnerable to unauthorized access by
malicious individuals or software.
For firewall functionality to be effective, it must be properly configured to
control and/or limit traffic into and out of the entity’s network.
While the running (or active) router configuration files include the current,
secure settings, the start-up files (which are used when routers are re-
started or booted) must be updated with the same secure settings to
ensure these settings are applied when the start-up configuration is run.
Because they only run occasionally, start-up configuration files are often
forgotten and are not updated. When a router re-starts and loads a start-up
configuration that has not been updated with the same secure settings as
those in the running configuration, it may result in weaker rules that allow
malicious individuals into the network.
The DMZ is that part of the network that manages connections between
the Internet (or other untrusted networks), and services that an
organization needs to have available to the public (like a web server).
This functionality is intended to prevent malicious individuals from
accessing the organization's internal network from the Internet, or from
using services, protocols, or ports in an unauthorized manner.
Misconfigured wireless networks and vulnerabilities in legacy encryption and authentication protocols continue to be targets of malicious in
r actions. When such accountability is in place, actions taken on critical data and systems are performed by, and can be traced to, known a
words at the point of entry, during transmission, and while in storage.
ularly, how frequently password attempts can be made by an attacker, and the security methods to protect user passwords at the point of e
d all accounts used to view or access cardholder data or to access systems with cardholder data. This includes accounts used by vendors a
ts within a point-of- sale payment application that only have access to one card number at a time in order to facilitate a single transaction (s
By ensuring each user is uniquely identified—instead of using one ID for
several employees—an organization can maintain individual responsibility
for actions and an effective audit trail per employee. This will help speed
issue resolution and containment when misuse or malicious intent occurs.
To ensure that user accounts granted access to systems are all valid and
recognized users, strong processes must manage all changes to user IDs
and other authentication credentials, including adding new ones and
If an employee
modifying has left
or deleting the company
existing ones. and still has access to the network via
their user account, unnecessary or malicious access to cardholder data
could occur—either by the former employee or by a malicious user who
Accounts
exploits the thatoldare not used
and/or unusedregularly areTo
account. often targets
prevent of attack since
unauthorized it is
access,
less likely that any changes (such as a changed password)
user credentials and other authentication methods therefore need to be will be noticed.
As such,promptly
revoked these accounts may be more easily exploited and used to access
in case they
cardholder need (as
data.
soon
to support asyour
possible)
systems upon the employee’s
increases the chancesdeparture.
of
unauthorized access, either from a user in the vendor’s environment or
from a malicious individual who finds and uses this always-available
Without
external account-lockout
entry point into your mechanisms
network. in place, an
Enabling attacker
access onlycan
for continually
the time
attempt to guess a password through manual or
periods needed, and disabling it as soon as it is no longer needed,automated tools (for
helps
example,
prevent password
misuse of cracking),
these until
connections. they achieve success and gain access
If
to an account
a user’s is locked
account. out Testing
Note: due to someone
Procedure continually
8.1.6.b trying to guess a
Monitoring
password, of vendor
controls toaccess
delay provides
reactivationassurance
of these thatisvendors
locked
an additional
are stops the
accounts
procedure
accessing that only applies ifnecessary
the entity and
being assessed is a service
malicious individual from continually guessing the password (theytime
provider.
only the systems only during approved will have
frames.
When
to stopusers walk awayoffrom
for a minimum an openuntil
30 minutes machine with access
the account to critical
is reactivated).
system components
Additionally, or cardholder
if reactivation must bedata, that machine
requested, the admin mayorbe used
help deskby can
others
validate in the user’s absence,
that it is the actual resulting
account in unauthorized account access
These
and/or authentication
misuse. methods, whenowner
used requesting
in addition reactivation.
to unique IDs, help
protect users’ IDs from being compromised, since
The re-authentication can be applied either at the system level the one attempting the
to protect
compromise needs toonknow
all sessions running both the unique
that machine, or at theID application
and the password
level. (or other
authentication used). Note that a digital certificate is a valid option for
“something you have” as long as it is unique for a particular user.
Since one of the first steps a malicious individual will take to compromise a
system is to exploit weak or nonexistent passwords, it is important to
implement good processes for authentication management.
Many network devices and applications transmit unencrypted, readable
passwords across the network and/or store passwords without encryption.
A malicious individual can easily intercept unencrypted passwords during
Many malicious
transmission usingindividuals
a “sniffer,” useor"socialdirectlyengineering”—for
access unencrypted example,passwords callingina
help desk and acting as a legitimate user—to
files where they are stored, and use this data to gain unauthorized access. have a password changed
so
Note:they can utilize
Testing Proceduresa user ID. 8.2.1.dConsider and use of are
8.2.1.e a “secret question” that only
Strong
the passwords/passphrases
proper userifcan answer to help are the first line ofadditional
administrators defensethe
identify
procedures
into usera network
prior to
that
since only apply
a malicious the entity
individual being assessed
will often first is a service provider.
try to find accounts with weak or
re-setting or modifying authentication credentials.
non-existent passwords. If passwords are short or simple to guess, it is
Passwords/passphrases
relatively easy for a malicious that are valid for
individual toafindlong time weak
these without a change
accounts and
provide malicious individuals
compromise a network under the guise of a valid user ID.with more time to work on breaking the
password/phrase.
This requirement Note: Testing
specifies that aProcedureminimum 8.2.4.b
of sevenischaracters
an additional and both
If password
procedure history
that only isn’tapplies maintained,
if the entity thebeingeffectiveness
assessed ofischanging
a service
numeric
passwords and is alphabetic
reduced, ascharacters
previous should
passwords be used
can for
be passwords/
reused over and
provider.
passphrases.
over. RequiringFor that cases
passwordswhere this cannot minimum
be reused cannot for be met due
a period to
of time
technical
If the same
reduces limitations,
the likelihoodentities
password is used
that canfor use
passwords every “equivalent
newhave
that user,been strength”
an internal
guessed to user,
evaluate former
or brute- their
alternative.
employee, orFor information
malicious on
individual variability
may
forced will be used in the future. Note: Testing Procedure 8.2.5.b is an knowand equivalency
or easily of
discover password
this
strength
password,
additional (also andreferred
procedure use it that totogainas
only entropy)
access
applies toforaccounts.
passwords/passphrases of
Multi-factor
different formats,authentication
refer to industry requires an ifindividual
standards
the entitytobeing
(e.g., the present assessed
current a minimum is a
version ofof
service
two provider
NIST SP 800-63.) Note: Testing Procedure 8.2.3.b is an additional 8.2),
separate forms of authentication (as described in Requirement
before
procedure access that isonly granted.
applies if to theapply entitytobeing assessed is aadministrative
service
This requirement
Multi-factor is intended
authentication provides all personnel
additional assurance with that the individual
provider.
access to the CDE.access This requirement
attempting to gain is who theyapplies claim toonly be. to Withpersonnel
multi-factor with
administrative
authentication, access
anisattacker and only
would for non-console
needtotoallcompromise access to the
at least two CDE; it does
different
Thisapply
not requirement
to application intendedor system to apply accounts personnel—including
performing automated general
authentication
users, mechanisms, increasing
administrators, and vendors (for support or maintenance) with the difficulty of compromise and
functions.
thus reducing the risk.network—where that remote access could lead to
remote
If access
the entity does tonot the use segmentation topolicies
separate the CDE from the
Multi-factor
Communicating
access authentication
to the CDE. If remote is not
password/authentication access requiredis to at both the
anmulti-factor
entity’s and system-level
procedures
network that has and
to allrest
of their
users network,
application-level
helps segmentation, an
thoseforusers administrator
a particular
understand could
system and use
component.
abide authentication
by theMulti-factor
policies.
appropriate
either when logging onto thesuch CDE that remote
network orusers
whencannot logging access
onto aorsystem.
impact
authentication
For
the example,
cardholder can
guidance
data be performed
on
environment, selecting eitherstrongupon
multi-factor authentication
passwords
authentication to
may includefor theremote
If the CDE
multiple network
particular is
users segmented
share tothe from
thesame
orpersonnel system the rest of
authentication the entity’s network,
credentials an
(for example,
suggestions
access
user to that
administrator
account
tonetwork
help
would
and need
password), wouldto use not
itthat becomponent.
select hard-to-guess
required.
multi-factor
becomes However,
authentication
impossible
passwords
tonot multi-factor
trace when
that don’t
system
Examples
contain of
dictionary
authentication multi-factor
words, technologies
and don’t include
contain but are
information limited
about toaccess
remote
the user
connecting
access and
authentication
(such as the to ais
activities
and
user
required
CDE ID, system
to
dial-in
names
for
anservice any remote
from
individual.
of a non-CDE
(RADIUS)
family This access
members, inwith
turn to
network. networks
prevents
tokens;
date of anwith
Multi-factor
terminal
birth, entity
etc.). from
access
to the This
Note: cardholder
authentication requirement data
cancontrol environment,
applies
be implemented only at and
when isthe
network recommended
entity being for all
assessed remote is a
assigning
controller
Guidance
access
service to
accountability
access
for protecting
the
provider. entity’s
for,
system or having
authentication
networks. (TACACS) effective withlevel
credentials logging
tokens;
mayor atof,and another
include individual’s
not writing
system/application
actions,
technologies
down sincethat
passwords a given level;
facilitate
or saving it multi-factor
action does
themcould not have
in have
insecure to be
been
authentication. both.
performed
files, and Ifbeing
thebyadministrator
anyone
alert for in the
To
uses
groupprevent
MFA
that the compromise
when
has logging
knowledge into ofofthe
the multiple
CDE customers
network,
authentication they through
do
credentials. not the
also use need of ato
malicious
If user set
single individuals
authentication
oflogcredentials, who may
mechanisms
vendors attemptsuch
with to exploit
as tokens,
remote accesstheir
smartpasswords
cards,toand
accounts (for
customer
use MFA to
example,
certificates bycan into
calling
be used a particular
anuse employee
bya multiple system
and or application
asking
accounts, for their
it may within
password
be the so
impossible CDE. the
to
environments should different authentication credential for each
caller
identify
customer.can
the “troubleshoot
individual usinga problem”).
the authentication mechanism. Having physical
Without
Instructing
and/or user
logical usersauthentication
to change
controls for access
passwords to databases
if there is that and
a chance applications,
theaapassword theis
Technologies,
potential for such
unauthorized as (for or
example,
multi-factor
malicious
a PIN,
mechanisms,
access
biometric
increases,
data,
provide and
or password)
unique
such access
no
to longer secure
uniquely
credential for eachcan
identify theprevent
user ofmalicious
connection the
(for account
example, users will
viafrom
prevent using
a single-use a legitimate
unauthorizedpassword) users
cannot
password
from be to
gaining logged
gain
access since
unauthorized the user
through use has
access.
of a not
sharedbeen authenticated
authentication and
mechanism. is
could
thereforealso
Personnelnot meet
need known the intent
to betoaware of
the system. this requirement.
of andAlso, following database security policies
access shouldand be
operational
granted through procedures
programmatic for managing methods identification
only (for example, and authorization
through stored on a
continuous basis
procedures), rather than via direct access to the database by end users
(except for DBAs, who may need direct access to the database for their
administrative duties).
or data and to remove systems or hardcopies, and should be appropriately restricted. For the purposes of Requirement 9, “onsite personne
der data.
Without physical access controls, such as badge systems and door
controls, unauthorized persons could potentially gain access to the facility
to steal, disable, disrupt, or destroy critical systems and cardholder data.
When
Locking investigating
console login physical
screensbreaches,
preventsthese controls can
unauthorized help from
persons identify the
gaining
individuals that physically accessed the sensitive areas,
access to sensitive information, altering system configurations, introducing as well as when
they entered and
vulnerabilities intoexited.
the network,jacks
or destroying records.
Restricting access
Criminals attempting to to
network
gain physical(oraccessnetwork ports) willareas
to sensitive prevent will often
malicious individuals from plugging into readily available
attempt to disable or bypass the monitoring controls. To protect these network jacks and
gain access
controls from into internal network
tampering, video resources.
cameras could be positioned so they are
Without
Whether security
logical over
or access
physical to wireless
controls, or acomponents
combination and devices,
of both, are used,
out of reach
malicious and/or
users be monitored
could usetoan to detect
organization’s tampering.
unattended Similarly,
wireless access
they should
control be sufficient
mechanisms could be prevent an individual
monitored or have or device
physical that is devices
protectionsnot
to access
explicitly network
authorized resources,
from being or even
able toconnect
connect their
to own
the devices
network. to the
installed
Identifying to authorized
prevent
wireless network to them
gain beingsodamaged
visitors they are
unauthorized or disabled
easily
access. by malicious
distinguished
Additionally, from onsite
securing
individuals.
personnel prevents unauthorized visitors from being
networking and communications hardware prevents malicious users from granted access to
Examples
areas ofnetwork
containing
intercepting sensitive areas
cardholder
traffic include
ordata.
physicallycorporate database
connecting server
their own rooms,to
devices
back-office
wired network rooms at retail locations that store cardholder data, and storage
resources.
areas for large quantities of cardholder data. Sensitive areas should be
identified by each organization to ensure the appropriate physical
monitoring controls are implemented.
Controlling physical access to sensitive areas helps ensure that only
authorized personnel with a legitimate business need are granted access.
When personnel leave the organization, all physical access mechanisms
Visitor
should controls are important
be returned topromptly
or disabled reduce the(asability
soon of
asunauthorized
possible) upon and
their
malicious persons to gain access to facilities (and potentially, to
departure, to ensure personnel cannot gain physical access to sensitive cardholder
data).
areas once their employment has ended.
Visitor controls ensure visitors are identifiable as visitors so personnel can
monitor their activities, and that their access is restricted to just the
duration of their legitimate visit.
Ensuring that visitor badges are returned upon expiry or completion of the
visit prevents malicious persons from using a previously authorized pass to
gain physical access into the building after the visit has ended.
A visitor log documenting minimum information on the visitor is easy and
inexpensive to maintain and will assist in identifying physical access to a
building or room, and potential access to cardholder data.
The firewall and router configuration standard (can be in the Documentation (firewall and router configuration)
network standard) must include: provides for the "life cycle" cradle-to-grave, of
• The formal process for testing and approval (lifecycle) of firewall rules and router connections. And, there
each network connection and firewall and router configuration. is in place, via document or automation,
documentation and formal approval of each
There exists the formal "tracking" of the introduction and/or network connection and the firewall and router
changes to network connections and changes to the firewall configuration.
and router configuration. This can exist through automation
(Service Now) or tracked in microsoft suite.
Provide the network diagram(s) that illustrate the location of all The configuration document matches with the
network hardware. Can be cross referenced against the network diagram.
firewall and network configuration.
Note, this is a separate document from the network diagram. it Data flow diagram is coherent: diagram is
must clearly illustrate the movement of credit card data within supported with appropriate verbiage to accurately
the cardholder data environment (app, os, network, database explain the data flow.
tiers). Nothing can be taken for granted. These must be in
great detail complete, with ports, protocols, encryptions, etc.
The firewall and router configuration standard (can be in the The provided documentation must provide the
network standard) must include: assurance of the firewall requirement AND that
• The requirement for a firewall at each internet connection, the firewall is in place. The network diagram must
includes the DMZ and internal network zones. clearly illustrate this requirement.
• Testing of all firewall configuration changes
• Approval of all firewall configuration changes
The firewall and router configuration standard (can be in the Network security team and the network security
network standard) must include: manager understand their roles regarding the
• A description of groups, roles, and responsibilities for logical ongoing management and approval of the router,
management of network components. This formal assignment port and protocol inventory.
ensures that the network administrator(s) and the network
security manager understand their roles and that they have an
understanding of the network inventory.
The firewall and router configuration standard (can be in the The firewall and router configuration standard
network standard) must include: provides for the "life cycle" cradle-to-grave, of
• Minimum guidance for the network lifecycle on tracking, secure and "approved" insecure network
cradle-to-grave, each of the network services, protocols and services, protocols and ports.
ports.
• The identification of "approved: insecure services, protocols
and ports. List compensation controls to overcome their
insecurities.
The firewall and router configuration standard (can be in the The firewall and router configuration standard
network standard) must include: provides for the review of the firewall and router
• The requirement to review the firewall and router rule sets, as rules set to occur every six months as a
a minimum, every six months. minimum.
The firewall and router configuration standard (can be in the The firewall and router configuration standard
network standard) must include: provides for the "life cycle" cradle-to-grave, of
• All inbound and outbound traffic necessary for the cardholder ensuring all inbound and outbound traffic is
data environment. understood and has a justification.
• Note-limit traffic to minimum necessary-every concession
must have a legitimate requirement.
• Default rule must be an implicit "deny."
The firewall and router configuration standard (can be in the Requirement is effectively communicated in the
network standard) must include: firewall and router configuration standard, the
• Minimum guidance for ensuring router configuration files are current file is stored with only authoraiced access,
secure from unauthorized access. synchronized and can be tested at any time.
• And that the latest file is synchronized (running). The latest
file must be the start-up file.
The firewall and router configuration standard (can be in the The firewall and router configuration standard
network standard) must include: provides for the "life cycle" cradle-to-grave, of
• Minimum guidance for the network lifecycle on tracking, secure and "approved" insecure network
cradle-to-grave, each of the network services, protocols and services, protocols and ports.
ports.
• The identification of "approved: insecure services, protocols
and ports. List compensation controls to overcome their
insecurities.
nternet, mobile computers, and storage devices, resulting in the exploitation of system vulnerabilities. Anti-virus software must be used on a
virus software to be in place.
ties that manage the systems. All systems must have all appropriate software patches to protect against the exploitation and compromise o
a and systems are performed by, and can be traced to, known and authorized users and processes. The effectiveness of a password is larg
he security methods to protect user passwords at the point of entry, during transmission, and while in storage.
with cardholder data. This includes accounts used by vendors and other third parties (for example, for support or maintenance).
ard number at a time in order to facilitate a single transaction (such as cashier accounts).
restricted. For the purposes of Requirement 9, “onsite personnel” refers to full-time and part-time employees, temporary employees, contra
racking, alerting, and analysis when something does go wrong. Determining the cause of a compromise is very difficult, if not impossible, w
frequently to ensure security controls continue to reflect a changing environment.
otecting it. For the purposes of Requirement 12, “personnel” refers to full-time and part-time employees, temporary employees, contractors a
hat shared hosting providers must protect each entity’s hosted environment and data. Therefore, shared hosting providers must additionally
Evidence of Controls
Control Process Control Output:
Artifact
Assuming all firewall rules start with deny/deny, An excel spreadsheet or a word document
fire wall rules are not arbitrary. Each rule beyond or a dashboard (automated) that reflects
deny must have a definition (why it's there) and each and every rule, port and protocol,
an approval. Each network connection (port and their definition, inception date and
protocol) has a role and must contain a reason. approval.
The lifecycle must identify and show why rule,
ports and protocols are in place.
Merchant (or service provider) reponsible for the A drawing in some form:
data flow must possess a current, up-to-date, • Visio drawing
diagram of the cardholder data flow with • Output from a network application
appropriate support verbiage. The document Must also contain full explanations.
must run in parallel to the network diagram.
The firewall configuration standard must require • The firewall configuratin standard.
the requirement for a firewall at each internet • The network topology drawing.
connection, includes the DMZ and internal • Interview with the network security SME.
network zones.
• The configuration standard provides for the • Current router (network) configuration
roles and responsibilities of the aligned network standard with the requirement.
team and its manager. • Interview with any of the router (network)
• The team and manager clearly represent the team to demonstrate the understanding is
standard's requirement. in place and supported.
The network lifecycle must be formally tracked, An excel spreadsheet or a word document
via microsoft suite or in automation (ServiceNow) or a dashboard (automated) that reflects
for the inception, changes and approvals to each and every rule, port and protocol,
secure and "appproved" insecure services, their definition, inception date and
protocols and ports. approval.
In following the firewal and router configuration An excel spreadsheet or a word document
standard, the activity of a complete firewall and or a dashboard (automated) that reflects
router rule review. Each review must be formally the review. Availabilty of a resource that
tracked, via microsoft suite or in automation attended/conducted the review.
(ServiceNow) to demonstrate the review
occurred. .
See Below See Below
The network lifecycle must be formally tracked, An excel spreadsheet or a word document
via microsoft suite or in automation (ServiceNow) or a dashboard (automated) that reflects
for the inception, changes and approvals to any the requirement for the assurance that
inbound and outbound traffic ensuring justification inbound and outbound traffic is limited
for each instance. minimum necessary and each instance is
justified.
The network lifecycle must be formally tracked, An excel spreadsheet or a word document
via microsoft suite or in automation (ServiceNow) or a dashboard (automated) that reflects
for the inception, changes and approvals to each and every rule, port and protocol,
secure and "appproved" insecure services, their definition, inception date and
protocols and ports. approval.
ftware must be used on all systems commonly affected by malware to protect systems from current and
tation and compromise of cardholder data by malicious individuals and malicious software.
ess of a password is largely determined by the design and implementation of the authentication system
maintenance).
orary employees, contractors and consultants who are physically present on the entity’s premises. A “visitor” refers to a vendor, guest of an
ficult, if not impossible, without system activity logs.
employees, contractors and consultants who are “resident” on the entity’s site or otherwise have access to the cardholder data environmen
oviders must additionally comply with the requirements in this Appendix.
Comment
See Below
ises. A “visitor” refers to a vendor, guest of any onsite personnel, service workers, or anyone who needs to enter the
ve access to the cardholder data environment
#
4
1.1.4 Requirements for a firewall at each Internet connection and
between any demilitarized zone (DMZ) and the internal network
zone
6
1.1.6 Documentation and business justification for use of all
services, protocols, and ports allowed, including documentation
of security features implemented for those protocols considered
to be insecure.
Examples of insecure services, protocols, or ports include but
are not limited to FTP, Telnet, POP3, IMAP, and SNMP v1 and
v2.
10
11
12
1.3 Prohibit direct public access between the Internet and any
system component in the cardholder data environment.
13
14
15
1.3.3 Implement anti-spoofing measures to detect and block
forged source IP addresses from entering the network.
(For example, block traffic originating from the Internet with an
internal source address.)
16
17
18
19
1.3.7 Do not disclose private IP addresses and routing
information to unauthorized parties.
21
1.5 Ensure that security policies and operational procedures for
managing firewalls are documented, in use, and known to all
affected parties.
22
Requirement 2: Do not use vendor-supplied defaults for system passwords and other security parameters
2.1 Always change vendor-supplied defaults and remove or
disable unnecessary default accounts before installing a system
on the network.
This applies to ALL default passwords, including but not limited
to those used by operating systems, software that provides
security services, application and system accounts, point-of-sale
(POS) terminals, Simple Network Management Protocol (SNMP)
community strings, etc.).
23
2.1.1 For wireless environments connected to the cardholder
data environment or transmitting cardholder data, change ALL
wireless vendor defaults at installation, including but not limited
to default wireless encryption keys, passwords, and SNMP
community strings.
24
2.2 Develop configuration standards for all system components.
Assure that these standards address all known security
vulnerabilities and are consistent with industry-accepted system
hardening standards.
Sources of industry-accepted system hardening standards may
include, but are not limited to:
25
27
2.2.3 Implement additional security features for any
required services,
protocols, or daemons that are considered to be insecure.
Note: Where SSL/early TLS is used, the requirements in
Appendix A2 must be completed.
28
29
30
2.3 Encrypt all non-console administrative access using
strong cryptography. Note: Where SSL/early TLS is used,
the requirements in Appendix A2 must be completed.
31
32
33
34
35
38
39
3.3 Mask PAN when displayed (the first six and last four digits
are the maximum number of digits to be displayed), such that
only personnel with a legitimate business need can see more
than the first six/last four digits of the PAN.
40
42
45
46
47
3.6 Fully document and implement all key-management processes and procedures for cryptographic keys used for
48
49
50
51
3.6.4 Cryptographic key changes for keys that have reached the
end of their cryptoperiod (for example, after a defined period of
time has passed and/or after a certain amount of cipher- text has
been produced by a given key), as defined by the associated
application vendor or key owner, and based on industry best
practices and guidelines (for example, NIST Special Publication
800-57).
52
53
54
3.6.7 Prevention of unauthorized substitution of cryptographic
keys.
55
56
57
• The internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile
communications (GSM), Code division multiple access (CDMA)
58 • General Packet Radio Service (GPRS)
• Satelite communications
59
4.2 Never send unprotected PANs by end-user messaging
technologies (for example, e-mail, instant messaging, SMS, chat,
etc.).
60
61
62
5.1.1 Ensure that anti-virus programs are capable of detecting,
removing, and protecting against all known types of malicious
software.
63
64
65
5.3 Ensure that anti-virus mechanisms are actively running and
cannot be disabled or altered by users, unless specifically
authorized by management on a case-by-case basis for a limited
time period.
67
69
71
6.3.2 Review custom code prior to release to production or
customers in order to identify any potential coding vulnerability
(using either manual or automated processes) to include at least
the following:
73
6.4.1 Separate development/test environments from production
environments, and enforce the separation with access controls.
74
75
6.4.3 Production data (live PANs) are not used for testing or
development
76
77
6.4.5 Change control procedures must include the following:
78
79
80
6.4.5.3 Functionality testing to verify that the change does not
adversely impact the security of the system.
81
82
83
6.5 Address common coding vulnerabilities in software-
development processes as follows:
84
Note: Requirements 6.5.1 through 6.5.6, below, apply to all applications (internal or external).
85
6.5.1 Injection flaws, particularly SQL injection. Also consider OS
Command Injection, LDAP and XPath injection flaws as well as
other injection flaws.
86
6.5.2 Buffer overflows
87
6.5.3 Insecure cryptographic storage
88
6.5.4 Insecure communications
89
6.5.5 Improper error handling
90
6.5.6 All “high risk” vulnerabilities identified in the vulnerability
identification process (as defined in PCI DSS Requirement 6.1).
Note: Requirements 6.5.7 through 6.5.10, below, apply to web
applications and application interfaces (internal or external):
91
Note: Requirements 6.5.7 through 6.5.10, below, apply to web applications and application interfaces (inter
6.5.7 Cross-site scripting (XSS)
92
6.5.8 Improper access control (such as insecure direct object
references, failure to restrict URL access, directory traversal, and
failure to restrict user access to functions).
93
6.5.9 Cross-site request forgery (CSRF)
94
6.5.10 Broken authentication and session management
95
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:
96
97
98
7.1.1 Define access needs for each role, including:
100
101
102
104
105
106
107
109
8.1.2 Control addition, deletion, and modification of user IDs,
credentials, and other identifier objects.
110
111
112
▪ Enabled only during the time period needed and disabled when
not in use.
▪ Monitored when in use.
113
8.1.6 Limit repeated access attempts by locking out the user ID
after not more than six attempts.
114
115
116
8.2 In addition to assigning a unique ID, ensure proper user-
authentication management for non-consumer users and
administrators on all system components by employing at least
one of the following methods to authenticate all users:
117
118
120
121
122
8.2.6 Set passwords/phrases for first- time use and upon reset to
a unique value for each user, and change immediately after the
first use.
123
124
8.3.1 Incorporate multi-factor authentication for all non-console
access into the CDE for personnel with administrative access
Note: This requirement is a best practice until January 31, 2018,
after which it becomes a requirement.
125
126
8.4 Document and communicate authentication procedures and
policies to all users including:
128
▪ All user access to, user queries of, and user actions on
databases are through programmatic methods.
▪ Only database administrators have the ability to directly access
or query databases.
▪ Application IDs for database applications can only be used by
the applications (and not by individual users or other non-
application processes).
131
8.8 Ensure that security policies and operational procedures for
identification and authentication are documented, in use, and
known to all affected parties.
132
133
136
137
9.3 Control physical access for onsite personnel to the sensitive
areas as follows:
140
142
9.4.4 A visitor log is used to maintain a physical audit trail of
visitor activity to the facility as well as computer rooms and data
centers where cardholder data is stored or transmitted.
Document the visitor’s name, the firm represented, and the
onsite personnel authorizing physical access on the log.
Retain this log for a minimum of three months, unless otherwise
143 restricted by law.
144
147
148
9.6.3 Ensure management approves any and all media that is
moved from a secured area (including when media is distributed
to individuals).
149
150
151
152
153
9.8.2 Render cardholder data on electronic media unrecoverable
so that cardholder data cannot be reconstructed.
154
9.9 Protect devices that capture payment card data via direct
physical interaction with the card from tampering and
substitution.
155
157
158
9.10 Ensure that security policies and operational procedures for
restricting physical access to cardholder data are documented, in
use, and known to all affected parties.
159
160
161
10.2.1 All individual user accesses to cardholder data
162
163
164
165
10.2 5 Use of and changes to identification and authentication
mechanisms—including but not limited to creation of new
accounts and elevation of privileges—and all changes, additions,
or deletions to accounts with root or administrative privileges
166
167
168
10.3 Record at least the following audit trail entries for all system
components for each event:
169
10.3.1 User identification
170
171
172
173
10.3.5 Origination of event
174
175
177
178
179
10.5 Secure audit trails so they cannot be altered.
180
181
182
183
10.5.4 Write logs for external-facing technologies onto a secure,
centralized, internal log server or media device.
184
10.6 Review logs and security events for all system components
to identify anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to
meet this Requirement.
186
10.6.1 Review the following at least daily:
187
188
189
10.7 Retain audit trail history for at least one year, with a
minimum of three months immediately available for analysis (for
example, online, archived, or restorable from backup).
190
•Firewalls
•IDS/IPS
•FIM
•Anti-virus
191 •Physical access controls
•Logical access controls
•Audit logging mechanisms
•Segmentation controls (if used)
193
Note: Methods that may be used in the process include but are
not limited to wireless network scans, physical/logical inspections
of system components and infrastructure, network access control
(NAC), or wireless IDS/IPS. Whichever methods are used, they
must be sufficient to detect and identify both authorized and
unauthorized devices..
194
11.1.1 Maintain an inventory of authorized wireless access points
including a documented business justification.
195
196
11.2 Run internal and external network vulnerability scans at
least quarterly and after any significant change in the network
(such as new system component installations, changes in
network topology, firewall rule modifications, product upgrades).
198
11.2.2 Perform quarterly external vulnerability scans, via an
Approved Scanning Vendor (ASV) approved by the Payment
Card Industry Security Standards Council (PCI SSC). Perform
rescans as needed, until passing scans are achieved.
Note: Quarterly external vulnerability scans must be performed
by an Approved Scanning Vendor (ASV), approved by the
Payment Card Industry Security Standards Council (PCI SSC).
Refer to the ASV Program Guide published on the PCI SSC
website for scan customer responsibilities, scan preparation, etc.
199
200
11.3 Implement a methodology for penetration testing that
includes the following:
202
203
11.3.3 Exploitable vulnerabilities found during penetration testing
are corrected and testing is repeated to verify the corrections.
204
205
11.3.4.1 Additional requirement for service providers only: If
segmentation is used, confirm PCI DSS scope by performing
penetration testing on segmentation controls at least every six
months and after any changes to segmentation
controls/methods.
206
207
11.5 Deploy a change-detection mechanism (for example, file-
integrity monitoring tools) to alert personnel to unauthorized
modification (including changes, additions, and deletions) of
critical system files, configuration files, or content files; and
configure the software to perform critical file comparisons at least
weekly.
209
210
12.10.2 Review and test the plan, including all elements listed in
246 Requirement 12.10.1, at least annually.
12.10.3 Designate specific personnel to be available on a 24/7
247 basis to respond to alerts.
12.10.4 Provide appropriate training to staff with security breach
248 response responsibilities.
12.10.5 Include alerts from security monitoring systems,
249 including but not limited to intrusion-detection, intrusion-
prevention, firewalls, and file-integrity monitoring systems.
12.10.6 Develop a process to modify and evolve the incident
250 response plan according to lessons learned and to incorporate
industry developments.
12.11 Additional requirement for service providers only.
Perform reviews at least quarterly to confirm personnel are
following security policies and operational procedures. Reviews
must cover the following processes:
A.1.1 Ensure that each entity only runs processes that have
access to that entity’s cardholder data environment.
A.1.2 Restrict each entity’s access and privileges to its own
cardholder data environment only.
A.1.3 Ensure logging and audit trails are enabled and unique to
each entity’s cardholder data environment and consistent with
PCI DSS Requirement 10.
A.1.4 Enable processes to provide for timely forensic
investigation in the event of a compromise to any hosted
merchant or service provider.
Testing
Procedures
1.1.3 Examine data-flow diagram and interview personnel to verify the diagram:
• Shows all cardholder data flows across systems and networks.
• Is kept current and updated as needed upon changes to the environment.
1.1.4.a Examine the firewall configuration standards and verify that they include
requirements for a firewall at each Internet connection and between any DMZ
and the internal network zone.
1.1.4.b Verify that the current network diagram is consistent with the firewall
configuration standards.
1.1.4.c Observe network configurations to verify that a firewall is in place at
each Internet connection and between any demilitarized zone (DMZ) and the
internal network zone, per the documented configuration standards and network
diagrams.
1.1.6.b Identify insecure services, protocols, and ports allowed; and verify that
security features are documented for each service.
1.1.6.c Examine firewall and router configurations to verify that the documented
security features are implemented for each insecure service, protocol, and port.
1.1.7.a Verify that firewall and router configuration standards require review of
firewall and router rule sets at least every six months.
1.2 Examine firewall and router configurations and perform the following to
verify that connections are restricted between untrusted networks and system
components in the cardholder data environment
1.2.1.a Examine firewall and router configuration standards to verify that they
identify inbound and outbound traffic necessary for the cardholder data
environment.
1.2.1.b Examine firewall and router configurations to verify that inbound and
outbound traffic is limited to that which is necessary for the cardholder data
environment.
1.2.1.c Examine firewall and router configurations to verify that all other inbound
and outbound traffic is specifically denied, for example by using an explicit “deny
all” or an implicit deny after allow statement.
1.2.2.a Examine router configuration files to verify they are secured from
unauthorized access.
1.2.3.a Examine firewall and router configurations to verify that there are
perimeter firewalls installed between all wireless networks and the cardholder
data environment.
1.2.3.b Verify that the firewalls deny or, if traffic is necessary for business
purposes, permit only authorized traffic between the wireless environment and
the cardholder data environment
1.3 Examine firewall and router configurations—including but not limited to the
choke router at the Internet, the DMZ router and firewall, the DMZ cardholder
segment, the perimeter router, and the internal cardholder network segment—
and perform the following to determine that there is no direct access between
the Internet and system components in the internal cardholder network
segment:
1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ.
1.3.2 Examine firewall and router configurations to verify that inbound Internet
traffic is limited to IP addresses within the DMZ
1.3.3 Examine firewall and router configurations to verify that anti-spoofing
measures are implemented, for example internal addresses cannot pass from
the Internet into the DMZ.
1.3.4 Examine firewall and router configurations to verify that outbound traffic
from the cardholder data environment to the Internet is explicitly authorized.
1.3.5 Examine firewall and router configurations to verify that the firewall permits
only established connections into the internal network and denies any inbound
connections not associated with a previously established session.
▪ Personal firewall (or equivalent functionality) is installed and configured per the
organization’s specific configuration settings.
▪ Personal firewall (or equivalent functionality) is actively running.
▪ Personal firewall (or equivalent functionality) is not alterable by users of the
portable computing devices.
1.5 Examine documentation and interview personnel to verify that security
policies and operational procedures for managing firewalls are:
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
2.1.b For the sample of system components, verify that all unnecessary default
accounts (including accounts used by operating systems, security software,
applications, systems, POS terminals, SNMP, etc.) are removed or disabled.
2.2.5.c. Examine the documentation and security parameters to verify that only
documented functionality is present on the sampled system components.
2.3 Select a sample of system components and verify that non-console
administrative access is encrypted by performing the following:
2.3.b Review services and parameter files on systems to determine that Telnet
and other insecure remote-login commands are not available for non-console
access.
2.4.a Examine system inventory to verify that a list of hardware and software
components is maintained and includes a description of function/use for each
.
2.4.b Interview personnel to verify the documented inventory is kept current.
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
2.6 Perform testing procedures A1.1 through A1.4 detailed in Appendix A1:
Additional PCI DSS Requirements for Shared Hosting Providers for PCI DSS
assessments of shared hosting providers, to verify that shared hosting providers
protect their entities’ (merchants and service providers) hosted environment and
data.
3.1.a Examine the data retention and disposal policies, procedures and
processes to verify they include the following for all cardholder data (CHD)
storage:
▪ Limiting data storage amount and retention time to that which is required for
legal, regulatory, and/or business requirements.
▪ Specific requirements for retention of cardholder data (for example, cardholder
data needs to be held for X period for Y business reasons).
▪ Processes for secure deletion of cardholder data when no longer needed for
legal, regulatory, or business reasons.
▪ A quarterly process for identifying and securely deleting stored cardholder data
that exceeds defined retention requirements.
▪ All locations of stored cardholder data are included in the data retention and
disposal processes.
▪ Either a quarterly automatic or manual process is in place to identify and
securely delete stored cardholder data.
▪ The quarterly automatic or manual process is performed for all locations of
cardholder data.
▪ Examine files and system records to verify that the data s tored does not
exceed the requirements defined in the data retention policy
▪ Observe the deletion mechanism to verify data is deleted securely.
3.2.a For issuers and/or companies that support issuing services and store
sensitive authentication data, review policies and interview personnel to verify
there is a documented business justification for the storage of sensitive
authentication data.
3.2.b For issuers and/or companies that support issuing services and store
sensitive authentication data, examine data stores and system configurations to
verify that the sensitive authentication data is secured.
3.2.c For all other entities, if sensitive authentication data is received, review
policies and procedures, and examine system configurations to verify the data is
not retained after authorization.
3.2.d For all other entities, if sensitive authentication data is received, review
procedures and examine the processes for securely deleting the data to verify
that the data is unrecoverable.
3.2.1 For a sample of system components, examine data sources including but
not limited to the following, and verify that the full contents of any track from the
magnetic stripe on the back of card or equivalent data on a chip are not stored
after authorization:
3.2.2 For a sample of system components, examine data sources, including but
not limited to the following, and verify that the three-digit or four-digit card
verification code or value printed on the front of the card or the signature panel
(CVV2, CVC2, CID, CAV2 data) is not stored after authorization:
3.2.3 For a sample of system components, examine data sources, including but
not limited to the following and verify that PINs and encrypted PIN blocks are
not stored after authorization:
▪ A list of roles that need access to displays of more than the first six/last four
(includes full PAN) is documented, together with a legitimate business need for
each role to have such access.
▪ PAN must be masked when displayed such that only personnel with a
legitimate business need can see more than the first six/last four digits of the
PAN.
▪ All roles not specifically authorized to see the full PAN must only see masked
PANs.
3.3.b Examine system configurations to verify that full PAN is only displayed for
users/roles with a documented business need, and that PAN is masked for all
other requests.
3.4.a Examine documentation about the system used to protect the PAN,
including the vendor, type of system/process, and the encryption algorithms (if
applicable) to verify that the PAN is rendered unreadable using any of the
following methods:
3.4.b Examine several tables or files from a sample of data repositories to verify
the PAN is rendered unreadable (that is, not stored in plain-text).
3.4.e If hashed and truncated versions of the same PAN are present in the
environment, examine implemented controls to verify that the hashed and
truncated versions cannot be correlated to reconstruct the original PAN.
3.4.1.a If disk encryption is used, inspect the configuration and observe the
authentication process to verify that logical access to encrypted file systems is
implemented via a mechanism that is separate from the native operating
system’s authentication mechanism (for example, not using local user account
databases or general network login credentials).
3.4.1.c Examine the configurations and observe the processes to verify that
cardholder data on removable media is encrypted wherever stored. Note: If disk
encryption is not used to encrypt removable media, the data stored on this
media will need to be rendered unreadable through some other method.
▪ Details of all algorithms, protocols, and keys used for the protection of
cardholder data, including key strength and expiry date
▪ Description of the key usage for each key
▪ Inventory of any HSMs and other SCDs used for key management
3.5.2 Examine user access lists to verify that access to keys is restricted to the
fewest number of custodians necessary
3.5.3.b Examine system configurations and key storage locations to verify that
cryptographic keys used to encrypt/decrypt cardholder data exist in one (or
more) of the following form at all times.
3.5.4 Examine key storage locations and observe processes to verify that keys
are stored in the fewest possible locations.
3.6.a Additional testing procedure for service provider assessments only: If the
service provider shares keys with their customers for transmission or storage of
cardholder data, examine the documentation that the service provider provides
to their customers to verify that it includes guidance on how to securely transmit,
store, and update customers’ keys, in accordance with Requirements 3.6.1
through 3.6.8 below.
3.6.b Examine the key-management procedures and processes for keys used
for encryption of cardholder data and perform the following:
3.6.1.b Observe the procedures for generating keys to verify that strong keys
are generated.
3.6.2.b Observe the method for distributing keys to verify that keys are
distributed securely.
3.6.3.b Observe the method for storing keys to verify that keys are stored
securely.
3.6.4.a Verify that key-management procedures include a defined cryptoperiod
for each key type in use and define a process for key changes at the end of the
defined cryptoperiod(s).
3.6.4.b Interview personnel to verify that keys are changed at the end of the
defined cryptoperiod(s).
▪ The retirement or replacement of keys when the integrity of the key has been
weakened
▪ The replacement of known or suspected compromised keys.
▪ Any keys retained after retiring or replacing are not used for encryption
operations
▪ Keys are retired or replaced as necessary when the integrity of the key has
been weakened, including when someone with knowledge of the key leaves the
company.
▪ Keys are replaced if known or suspected to be compromised.
▪ Any keys retained after retiring or replacing are not used for encryption
operations.
▪ Split knowledge of keys, such that key components are under the control of at
least two people who only have knowledge of their own key components; AND
▪ Dual control of keys, such that at least two people are required to perform any
key-management operations and no one person has access to the
authentication materials (for example, passwords or keys) of another.
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
4.1.d Examine keys and certificates to verify that only trusted keys and/or
certificates are accepted.
4.1.f Examine system configurations to verify that the proper encryption strength
is implemented for the encryption methodology in use. (Check vendor
recommendations/best practices.)
4.2.b Review written policies to verify the existence of a policy stating that
unprotected PANs are not to be sent via end-user messaging technologies.
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
m
5.1 For a sample of system components including all operating system types
commonly affected by malicious software, verify that anti-virus software is
deployed if applicable anti-virus technology exists.
5.1.1 Review vendor documentation and examine anti-virus configurations to
verify that anti-virus programs:
5.1.2 Interview personnel to verify that evolving malware threats are monitored
and evaluated for systems not currently considered to be commonly affected by
malicious software, in order to confirm whether such systems continue to not
require anti-virus software.
5.2.a Examine policies and procedures to verify that anti-virus software and
definitions are required to be kept up to date.
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
pplications
6.1.a Examine policies and procedures to verify that processes are defined for
the following:
6.2.b For a sample of system components and related software, compare the
list of security patches installed on each system to the most recent vendor
security-patch list, to verify the following:
That applicable critical vendor-supplied security patches are installed within
one month of release.
All applicable vendor-supplied security patches are installed within an
appropriate time frame (for example, within three months).
▪ Code changes are reviewed by individuals other than the originating code
author, and by individuals who are knowledgeable in code-review techniques
and secure coding practices.
▪ Code reviews ensure code is developed according to secure coding guidelines
(see PCI DSS Requirement 6.5).
▪ Appropriate corrections are implemented prior to release.
▪ Code-review results are reviewed and approved by management prior to
release.
6.4 Examine policies and procedures to verify the following are defined:
Development/test environments are separate from production environments
with access control in place to enforce separation.
A separation of duties between personnel assigned to the development/test
environments and those assigned to the production environment.
Production data (live PANs) are not used for testing or development.
Test data and accounts are removed before a production system becomes
active.
Change control procedures related to implementing security patches and
software modifications are documented.
6.4.1.a Examine network documentation and network device configurations to
verify that the development/test environments are separate from the production
environment(s).
6.4.1.b Examine access controls settings to verify that access controls are in
place to enforce separation between the development/test environments and
the production environment(s).
6.4.3.b Examine a sample of test data to verify production data (live PANs) is
not used for testing or development.
6.4.4.a Observe testing processes and interview personnel to verify test data
and accounts are removed before a production system becomes active.
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not adversely impact the
security of the system
▪ Back-out procedures
6.4.5.3.b For custom code changes, verify that all updates are tested for
compliance with PCI DSS Requirement 6.5 before being deployed into
production.
6.4.5.4 Verify that back-out procedures are prepared for each sampled change.
6.5.b Examine records of training to verify that software developers receive up-
to-date training on secure coding techniques at least annually, including how to
avoid common coding vulnerabilities.
▪ Validating input to verify user data cannot modify meaning of commands and
queries.
▪ Utilizing parameterized queries.
6.5.2 Examine software-development policies and procedures and interview
responsible personnel to verify that buffer overflows are addressed by coding
techniques that include:
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
7.1 Examine written policy for access control, and verify that the policy
incorporates 7.1.1 through 7.1.4 as follows:
▪ System components and data resources that each role needs to access for
their job function
▪ Identification of privilege necessary for each role to perform their job function.
7.1.4 Select a sample of user IDs and compare with documented approvals to
verify that:
7.2 Examine system settings and vendor documentation to verify that an access
control system(s) is implemented as follows:
7.2.1 Confirm that access control systems are in place on all system
components.
7.2.2 Confirm that access control systems are configured to enforce privileges
assigned to individuals based on job classification and function.
7.2.3 Confirm that the access control systems have a default “deny-all” setting.
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
omponents
8.1.a Review procedures and confirm they define processes for each of the
items below at 8.1.1 through 8.1.8
8.1.1 Interview administrative personnel to confirm that all users are assigned a
unique ID for access to system components or cardholder data.
8.1.2 For a sample of privileged user IDs and general user IDs, examine
associated authorizations and observe system settings to verify each user ID
and privileged user ID has been implemented with only the privileges specified
on the documented approval.
8.1.3.a Select a sample of users terminated in the past six months, and review
current user access lists—for both local and remote access—to verify that their
IDs have been deactivated or removed from the access lists.
8.1.4 Observe user accounts to verify that any inactive accounts over 90 days
old are either removed or disabled.
8.1.5.a Interview personnel and observe processes for managing accounts used
by third parties to access, support, or maintain system components to verify that
accounts used for remote access are:
8.3.1.b Observe a sample of administrator personnel login to the CDE and verify
that at least two of the three authentication methods are used.
8.3.2.a Examine system configurations for remote access servers and systems
to verify multi-factor authentication is required for:
8.4.c Interview a sample of users to verify that they are familiar with
authentication policies and procedures.
8.5.a For a sample of system components, examine user ID lists to verify the
following:
8.5.b Examine authentication policies and procedures to verify that use of group
and shared IDs and/or passwords or other authentication methods are explicitly
prohibited.
8.5.c Interview system administrators to verify that group and shared IDs and/or
passwords or other authentication methods are not distributed, even if
requested.
8.7.a Review database and application configuration settings and verify that all
users are authenticated prior to access.
Without user authentication for access to databases and applications, the
potential for unauthorized or malicious access increases, and such access
cannot be logged since the user has not been authenticated and is therefore not
known to the system. Also, database access should be granted through
programmatic methods only (for example, through stored procedures), rather
than via direct access to the database by end users (except for DBAs, who may
need direct access to the database for their administrative duties).
8.7.b Examine database and application configuration settings to verify that all
user access to, user queries of, and user actions on (for example, move, copy,
delete), the database are through programmatic methods only (for example,
through stored procedures).
9.1 Verify the existence of physical security controls for each computer room,
data center, and other physical areas with systems in the cardholder data
environment.
▪ Verify that access is controlled with badge readers or other devices including
authorized badges and lock and key.
▪ Observe a system administrator’s attempt to log into consoles for randomly
selected systems in the cardholder data environment and verify that they are
“locked” to prevent unauthorized use.
9.1.1.a Verify that either video cameras or access control mechanisms (or both)
are in place to monitor the entry/exit points to sensitive areas.
9.1.1.b Verify that either video cameras or access control mechanisms (or both)
are protected from tampering or disabling.
9.1.1.c Verify that data from video cameras and/or access control mechanisms
is reviewed, and that data is stored for at least three months.
9.1.2 Interview responsible personnel and observe locations of publicly
accessible network jacks to verify that physical and/or logical controls are in
place to restrict access to publicly accessible network jacks.
Restricting access to network jacks (or network ports) will prevent malicious
individuals from plugging into readily available network jacks and gain access
into internal network resources.
Whether logical or physical controls, or a combination of both, are used, they
should be sufficient to prevent an individual or device that is not explicitly
authorized from being able to connect to the network.
9.1.3 Verify that physical access to wireless access points, gateways, handheld
devices, networking/communications hardware, and telecommunication lines is
appropriately restricted.
9.2.a Review documented processes to verify that procedures are defined for
identifying and distinguishing between onsite personnel and visitors.
9.2.c Verify that access to the identification process (such as a badge system) is
limited to authorized personnel.
9.3.a For a sample of onsite personnel with physical access to sensitive areas,
interview responsible personnel and observe access control lists to verify that:
9.3.b Observe personnel accessing sensitive areas to verify that all personnel
are authorized before being granted access.
9.4 Verify that visitor authorization and access controls are in place as follows:
9.4.1.a Observe procedures and interview personnel to verify that visitors must
be authorized before they are granted access to, and escorted at all times
within, areas where cardholder data is processed or maintained.
9.4.1.b Observe the use of visitor badges or other identification to verify that a
physical token badge does not permit unescorted access to physical areas
where cardholder data is processed or maintained.
9.4.2.a Observe people within the facility to verify the use of visitor badges or
other identification, and that visitors are easily distinguishable from onsite
personnel.
9.4.3 Observe visitors leaving the facility to verify visitors are asked to surrender
their badge or other identification upon departure or expiration.
9.4.4.a Verify that a visitor log is in use to record physical access to the facility
as well as computer rooms and data centers where cardholder data is stored or
transmitted.
9.4.4.c Verify that the log is retained for at least three months.
9.5 Verify that procedures for protecting cardholder data include controls for
physically securing all media (including but not limited to computers, removable
electronic media, paper receipts, paper reports, and faxes).
9.5.1 Verify that the storage location security is reviewed at least annually to
confirm that backup media storage is secure.
9.6 Verify that a policy exists to control distribution of media, and that the policy
covers all distributed media including that distributed to individuals.
9.6.1 Verify that all media is classified so the sensitivity of the data can be
determined.
9.6.2.a Interview personnel and examine records to verify that all media sent
outside the facility is logged and sent via secured courier or other delivery
method that can be tracked.
9.6.2.b Select a recent sample of several days of offsite tracking logs for all
media, and verify tracking details are documented.
9.6.3 Select a recent sample of several days of offsite tracking logs for all
media. From examination of the logs and interviews with responsible personnel,
verify proper management authorization is obtained whenever media is moved
from a secured area (including when media is distributed to individuals).
9.7 Obtain and examine the policy for controlling storage and maintenance of all
media and verify that the policy requires periodic media inventories.
9.7.1 Review media inventory logs to verify that logs are maintained and media
inventories are performed at least annually.
9.8 Examine the periodic media destruction policy and verify that it covers all
media and defines requirements for the following:
9.8.1.b Examine storage containers used for materials that contain information
to be destroyed to verify that the containers are secured.
9.8.2 Verify that cardholder data on electronic media is rendered unrecoverable
(e.g., via a secure wipe program in accordance with industry-accepted
standards for secure deletion, or by physically destroying the media).
9.9.1.b Select a sample of devices from the list and observe devices and device
locations to verify that the list is accurate and up to date.
9.9.1.c Interview personnel to verify the list of devices is updated when devices
are added, relocated, decommissioned, etc.
9.9.2.a Examine documented procedures to verify processes are defined to
include the following:
▪ Documented,
▪ In use, and
▪ Known to all affected parties.
Through interviews and observation of audit logs, for each auditable event (from
10.2), perform the following tests outlined below for requirements 10.3.1 through
10.3.6:
Verify user identification is included in log entries.
▪ Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International
Atomic Time or UTC.
▪ Where there is more than one designated time server, the time servers peer
with one another to keep accurate time,
▪ Systems receive time information only from designated central time server(s).
▪ Only the designated central time server(s) receives time signals from external
sources, and time signals from external sources are based on International
Atomic Time or UTC.
▪ Where there is more than one designated time server, the designated central
time server(s) peer with one another to keep accurate time.
▪ Systems receive time only from designated central time server(s).
Examine systems configurations to verify that the time server(s) accept time
updates from specific, industry-accepted external sources (to prevent a
malicious individual from changing the clock). Optionally, those updates can be
encrypted with a symmetric key, and access control lists can be created that
specify the IP addresses of client machines that will be provided with the time
updates (to prevent unauthorized use of internal time servers).
Interview system administrators and examine system configurations and
permissions to verify that audit trails are secured so that they cannot be altered
as follows:
Only individuals who have a job-related need can view audit trail files.
Current audit trail files are protected from unauthorized modifications via access
control mechanisms, physical segregation, and/or network segregation.
Current audit trail files are promptly backed up to a centralized log server or
media that is difficult to alter.
Logs for external-facing technologies (for example, wireless, firewalls, DNS,
mail) are written onto a secure, centralized, internal log server or media.
Examine system settings, monitored files, and results from monitoring activities
to verify the use of file-integrity monitoring or change-detection software on logs.
Observe processes and interview personnel to verify that the following are
reviewed at least daily:
Examine security policies and procedures to verify that procedures are defined
for reviewing logs of all other system components periodically—either manually
or via log tools—based on the organization’s policies and risk management
strategy.
Examine security policies and procedures to verify that procedures are defined
for following up on exceptions and anomalies identified during the review
process.
Interview personnel and examine audit logs to verify that audit logs are retained
for at least one year.
Interview personnel and observe processes to verify that at least the last three
months’ logs are immediately available for analysis.
Examine detection and alerting processes and interview personnel to verify that
processes are implemented for all critical security controls, and that failure of a
critical security control results in the generation of an alert.
Examine documented policies and procedures and interview personnel to verify
processes are defined and implemented to respond to a security control failure,
and include: Restoring security functions. Identifying and documenting the
duration (date and time start to end) of the security failure. Identifying and
documenting cause(s) of failure, including root cause, and documenting
remediation required to address root cause. Identifying and addressing any
security issues that arose during the failure. Performing a risk assessment to
determine whether further actions are required as a result of the security failure.
Implementing controls to prevent cause of failure from reoccurring. Resuming
monitoring of security controls
es.
11.1.a Examine policies and procedures to verify processes are defined for
detection and identification of both authorized and unauthorized wireless access
points on a quarterly basis.
11.1.b Verify that the methodology is adequate to detect and identify any
unauthorized wireless access points, including at least the following:
WLAN cards inserted into system components
Portable or mobile devices attached to system components to create a
wireless access point (for example, by USB, etc.)
Wireless devices attached to a network port or network device.
11.1.c If wireless scanning is utilized, examine output from recent wireless
scans to verify that:
Authorized and unauthorized wireless access points are identified, and
The scan is performed at least quarterly for all system components and
facilities.
11.1.d If automated monitoring is utilized (for example, wireless IDS/IPS, NAC,
etc.), verify the configuration will generate alerts to notify personnel.
11.1.1 Examine documented records to verify that an inventory of authorized
wireless access points is maintained and a business justification is documented
for all authorized wireless access points.
11.2.1.a Review the scan reports and verify that four quarterly internal scans
occurred in the most recent 12-month period.
11.2.1.b Review the scan reports and verify that all “high risk” vulnerabilities are
addressed and the scan process includes rescans to verify that the “high risk”
vulnerabilities (as defined in PCI DSS Requirement 6.1) are resolved.
11.2.1.c Interview personnel to verify that the scan was performed by a qualified
internal resource(s) or qualified external third party and, if applicable,
organizational independence of the tester exists (not required to be a QSA or
ASV).
11.2.2.a Review output from the four most recent quarters of external
vulnerability scans and verify that four quarterly external vulnerability scans
occurred in the most recent 12-month period.
11.2.2.b Review the results of each quarterly scan and rescan to verify that the
ASV Program Guide requirements for a passing scan have been met (for
example, no vulnerabilities rated 4.0 or higher by the CVSS, and no automatic
failures).
11.2.2.c Review the scan reports to verify that the scans were completed by a
PCI SSC Approved Scanning Vendor (ASV).
11.2.3.a Inspect and correlate change control documentation and scan reports
to verify that system components subject to any significant change were
scanned.
11.2.3.b Review scan reports and verify that the scan process includes rescans
until:
For external scans, no vulnerabilities exist that are scored 4.0 or higher by the
CVSS.
For internal scans, all “high risk” vulnerabilities as defined in PCI DSS
Requirement 6.1 are resolved.
11.2.3.c Validate that the scan was performed by a qualified internal resource(s)
or qualified external third party and, if applicable, organizational independence
of the tester exists (not required to be a QSA or ASV).
11.3 Examine penetration-testing methodology and interview responsible
personnel to verify a methodology is implemented that includes the following:
* Is based on industry-accepted penetration testing approaches (for example,
NIST SP800-115)
* Includes coverage for the entire CDE perimeter and critical systems
* Testing from both inside and outside the network
* Includes testing to validate any segmentation and scope-reduction controls
* Defines application-layer penetration tests to include, at a minimum, the
vulnerabilities listed in Requirement 6.5
* Defines network-layer penetration tests to include components that support
network functions as well as operating systems
* Includes review and consideration of threats and vulnerabilities experienced in
the last 12 months
* Specifies retention of penetration testing results and remediation activities
results.
11.3.1.a Examine the scope of work and results from the most recent external
penetration test to verify that penetration testing is performed as follows:
Per the defined methodology
At least annually
After any significant changes to the environment.
11.3.1.b Verify that the test was performed by a qualified internal resource or
qualified external third party and, if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.3.2.a Examine the scope of work and results from the most recent internal
penetration test to verify that penetration testing is performed as follows.
Per the defined methodology
At least annually
After any significant changes to the environment.
11.3.2.b Verify that the test was performed by a qualified internal resource or
qualified external third party and, if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.3.3 Examine penetration testing results to verify that noted exploitable
vulnerabilities were corrected and that repeated testing confirmed the
vulnerability was corrected.
11.3.4.b Examine the results from the most recent penetration test to verify that:
Penetration testing to verify segmentation controls is performed at least
annually and after any changes to segmentation controls/methods.
The penetration testing covers all segmentation controls/methods in use.
The penetration testing verifies that segmentation controls/methods are
operational and effective, and isolate all out-of-scope systems from systems in
the CDE.
11.3.4.c Verify that the test was performed by a qualified internal resource or
qualified external third party and, if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.3.4.1.a Examine the results from the most recent penetration test to verify
that:
Penetration testing is performed to verify segmentation controls at least every
six months and after any changes to segmentation controls/methods.
The penetration testing covers all segmentation controls/methods in use.
The penetration testing verifies that segmentation controls/methods are
operational and effective, and isolate all out-of-scope systems from systems in
the CDE.
11.3.4.1.b Verify that the test was performed by a qualified internal resource or
qualified external third party and, if applicable, organizational independence of
the tester exists (not required to be a QSA or ASV).
11.5.1 Interview personnel to verify that all alerts are investigated and resolved.
Firewalls and routers are key components of the architecture that controls
entry to and exit from the network. These devices are software or
hardware devices that block unwanted access and manage authorized
access into and out of the network.
Configuration standards and procedures will help to ensure that the
organization’s first line of defense in the protection of its data remains
strong.
Network diagrams describe how networks are configured, and identify the
location of all network devices.
Without current network diagrams, devices could be overlooked and be
unknowingly left out of the security controls implemented for PCI DSS and
thus be vulnerable to compromise.
This review gives the organization an opportunity at least every six months
to clean up any unneeded, outdated, or incorrect rules, and ensure that all
rule sets allow only authorized services and ports that match the
documented business justifications.
Organizations with a high volume of changes to firewall and router rule
sets may wish to consider performing reviews more frequently, to ensure
that the rule sets continue to meet the needs of the business.
While the running (or active) router configuration files include the current,
secure settings, the start-up files (which are used when routers are re-
started or booted) must be updated with the same secure settings to
ensure these settings are applied when the start-up configuration is run.
Because they only run occasionally, start-up configuration files are often
forgotten and are not updated. When a router re-starts and loads a start-up
configuration that has not been updated with the same secure settings as
those in the running configuration, it may result in weaker rules that allow
malicious individuals into the network.
The DMZ is that part of the network that manages connections between
the Internet (or other untrusted networks), and services that an
organization needs to have available to the public (like a web server).
This functionality is intended to prevent malicious individuals from
accessing the organization's internal network from the Internet, or from
using services, protocols, or ports in an unauthorized manner.
The DMZ is that part of the network that manages connections between
the Internet (or other untrusted networks), and services that an
organization needs to have available to the public (like a web server).
This functionality is intended to prevent malicious individuals from
accessing the organization's internal network from the Internet, or from
using services, protocols, or ports in an unauthorized manner.
Normally a packet contains the IP address of the computer that originally
sent it so other computers in the network know where the packet came
from. Malicious individuals will often try to spoof (or imitate) the sending IP
address so that the target system believes the packet is from a trusted
source. Filtering packets coming into the network helps to, among other
things, ensure packets are not “spoofed” to look like they are coming from
an organization’s own internal network.
A firewall that maintains the "state" (or the status) for each connection
through the firewall knows whether an apparent response to a previous
connection is actually a valid, authorized response (since it retains each
connection’s status) or is malicious traffic trying to trick the firewall into
allowing the connection.
If server functions that need different security levels are located on the
same server, the security level of the functions with higher security needs
would be reduced due to the presence of the lower-security functions.
Additionally, the server functions with a lower security level may introduce
security weaknesses to other functions on the same server. By considering
the security needs of different server functions as part of the system
configuration standards and related processes, organizations can ensure
that functions requiring different security levels don’t co-exist on the same
server.
These values should be known only to the card owner or bank that issued
the card. If this data is stolen, malicious individuals can execute fraudulent
PIN-based debit transactions (for example, ATM withdrawals).
The display of full PAN on items such as computer screens, payment card
receipts, faxes, or paper reports can result in this data being obtained by
unauthorized individuals and used fraudulently. Ensuring that full PAN is
only displayed for those with a legitimate business need to see the full PAN
minimizes the risk of unauthorized persons gaining access to PAN data.
The masking approach should always ensure that only the minimum
number of digits is displayed as necessary to perform a specific business
function. For example, if only the last four digits are needed to perform a
business function, mask the PAN so that individuals performing that
function can view only the last four digits. As another example, if a function
needs access to the bank identification number (BIN) for routing purposes,
unmask only the BIN digits (traditionally the first six digits) during that
function.
This requirement relates to protection of PAN displayed on screens, paper
receipts, printouts, etc., and is not to be confused with Requirement 3.4 for
protection of PAN when stored in files, databases, etc.
PANs stored in primary storage (databases, or flat files such as text files
spreadsheets) as well as non-primary storage (backup, audit logs,
exception or troubleshooting logs) must all be protected.
One-way hash functions based on strong cryptography can be used to
render cardholder data unreadable. Hash functions are appropriate when
there is no need to retrieve the original number (one-way hashes are
irreversible). It is recommended, but not currently a requirement, that an
additional, random input value be added to the cardholder data prior to
hashing to reduce the feasibility of an attacker comparing the data against
(and deriving the PAN from) tables of pre-computed hash values.
The intent of truncation is to permanently remove a segment of PAN data
so that only a portion (generally not to exceed the first six and last four
digits) of the PAN is stored.
An index token is a cryptographic token that replaces the PAN based on a
given index for an unpredictable value. A one-time pad is a system in
which a randomly generated private key is used only once to encrypt a
message that is then decrypted using a matching one-time pad and key.
The intent of strong cryptography (as defined in the PCI DSS and PA-DSS
Glossary of Terms, Abbreviations, and Acronyms) is that the encryption be
based on an industry-tested and accepted algorithm (not a proprietary or
"home-grown" algorithm) with strong cryptographic keys.
By correlating hashed and truncated versions of a given PAN, a malicious
individual may easily derive the original PAN value. Controls that prevent
the correlation of this data will help ensure that the original PAN remains
unreadable.
The intent of this requirement is to address the acceptability of disk-level
encryption for rendering cardholder data unreadable. Disk-level encryption
encrypts the entire disk/partition on a computer and automatically decrypts
the information when an authorized user requests it. Many disk-encryption
solutions intercept operating system read/write operations and carry out
the appropriate cryptographic transformations without any special action by
the user other than supplying a password or pass phrase upon system
startup or at the beginning of a session. Based on these characteristics of
disk-level encryption, to be compliant with this requirement, the method
cannot:
1) Use the same user account authenticator as the operating system, or
2) Use a decryption key that is associated with or derived from the
system’s local user account database or general network login credentials.
Full disk encryption helps to protect data in the event of physical loss of a
disk and therefore may be appropriate for portable devices that store
cardholder data.
The encryption solution must generate strong keys, as defined in the PCI
DSS and PA-DSS Glossary of Terms, Abbreviations, and Acronyms under
"Cryptographic Key Generation." Use of strong cryptographic keys
significantly increases the level of security of encrypted cardholder data.
The encryption solution must distribute keys securely, meaning the keys
are distributed only to custodians identified in 3.5.1, and are never
distributed in the clear.
Keys that are no longer used or needed, or keys that are known or
suspected to be compromised, should be revoked and/or destroyed to
ensure that the keys can no longer be used. If such keys need to be kept
(for example, to support archived, encrypted data) they should be strongly
protected.
The encryption solution should provide for and facilitate a process to
replace keys that are due for replacement or that are known to be, or
suspected of being, compromised.
Split knowledge and dual control of keys are used to eliminate the
possibility of one person having access to the whole key. This control is
applicable for manual key-management operations, or where key
management is not implemented by the encryption product.
Split knowledge is a method in which two or more people separately have
key components, where each person knows only their own key
component, and the individual key components convey no knowledge of
the original cryptographic key.
Dual control requires two or more people to perform a function, and no
single person can access or use the authentication materials of another.
The encryption solution should not allow for or accept substitution of keys
coming from unauthorized sources or unexpected processes.
This process will help ensure individuals that act as key custodians commit
to the key-custodian role and understand and accept the responsibilities.
Even the best anti-virus solutions are limited in effectiveness if they are not
maintained and kept current with the latest security updates, signature
files, or malware protections.
Audit logs provide the ability to monitor virus and malware activity and anti-
malware reactions. Thus, it is imperative that anti-malware solutions be
configured to generate audit logs and that these logs be managed in
accordance with Requirement 10.
Anti-virus that continually runs and is unable to be altered will provide
persistent security against malware.
Use of policy-based controls on all systems to ensure anti-malware
protections cannot be altered or disabled will help prevent system
weaknesses from being exploited by malicious software.
Additional security measures may also need to be implemented for the
period of time during which anti-virus protection is not active—for example,
disconnecting the unprotected system from the Internet while the anti-virus
protection is disabled, and running a full scan after it is re-enabled.
Test data and accounts should be removed before the system component
becomes active (in production), since these items may give away
information about the functioning of the application or system. Possession
of such information could facilitate compromise of the system and related
cardholder data.
If not properly managed, the impact of system changes—such as
hardware or software updates and installation of security patches—might
not be fully realized and could have unintended consequences.
The more people who have access to cardholder data, the more risk there
is that a user’s account will be used maliciously. Limiting access to those
with a legitimate business reason for the access helps an organization
prevent mishandling of cardholder data through inexperience or malice.
In order to limit access to cardholder data to only those individuals who
need such access, first it is necessary to define access needs for each role
(for example, system administrator, call center personnel, store clerk), the
systems/devices/data each role needs access to, and the level of privilege
each role needs to effectively perform assigned tasks. Once roles and
corresponding access needs are defined, individuals can be granted
access accordingly.
Once needs are defined for user roles (per PCI DSS requirement 7.1.1), it
is easy to grant individuals access according to their job classification and
function by using the already-created roles.
If an employee has left the company and still has access to the network via
their user account, unnecessary or malicious access to cardholder data
could occur—either by the former employee or by a malicious user who
exploits the old and/or unused account. To prevent unauthorized access,
user credentials and other authentication methods therefore need to be
revoked promptly (as soon as possible) upon the employee’s departure.
Accounts that are not used regularly are often targets of attack since it is
less likely that any changes (such as a changed password) will be noticed.
As such, these accounts may be more easily exploited and used to access
cardholder data.
When users walk away from an open machine with access to critical
system components or cardholder data, that machine may be used by
others in the user’s absence, resulting in unauthorized account access
and/or misuse.
The re-authentication can be applied either at the system level to protect
all sessions running on that machine, or at the application level.
These authentication methods, when used in addition to unique IDs, help
protect users’ IDs from being compromised, since the one attempting the
compromise needs to know both the unique ID and the password (or other
authentication used). Note that a digital certificate is a valid option for
“something you have” as long as it is unique for a particular user.
Since one of the first steps a malicious individual will take to compromise a
system is to exploit weak or nonexistent passwords, it is important to
implement good processes for authentication management.
Note: This requirement applies only when the entity being assessed is a
service provider.
To prevent the compromise of multiple customers through the use of a
single set of credentials, vendors with remote access accounts to customer
environments should use a different authentication credential for each
customer.
Technologies, such as multi-factor mechanisms, that provide a unique
credential for each connection (for example, via a single-use password)
could also meet the intent of this requirement.
If user authentication mechanisms such as tokens, smart cards, and
certificates can be used by multiple accounts, it may be impossible to
identify the individual using the authentication mechanism. Having physical
and/or logical controls (for example, a PIN, biometric data, or a password)
to uniquely identify the user of the account will prevent unauthorized users
from gaining access through use of a shared authentication mechanism.
When investigating physical breaches, these controls can help identify the
individuals that physically accessed the sensitive areas, as well as when
they entered and exited.
Criminals attempting to gain physical access to sensitive areas will often
attempt to disable or bypass the monitoring controls. To protect these
controls from tampering, video cameras could be positioned so they are
out of reach and/or be monitored to detect tampering. Similarly, access
control mechanisms could be monitored or have physical protections
installed to prevent them being damaged or disabled by malicious
individuals.
Examples of sensitive areas include corporate database server rooms,
back-office rooms at retail locations that store cardholder data, and storage
areas for large quantities of cardholder data. Sensitive areas should be
identified by each organization to ensure the appropriate physical
monitoring controls are implemented.
Restricting access to network jacks (or network ports) will prevent
malicious individuals from plugging into readily available network jacks and
gain access into internal network resources.
Whether logical or physical controls, or a combination of both, are used,
they should be sufficient to prevent an individual or device that is not
explicitly authorized from being able to connect to the network.
It is important that media be identified such that its classification status can
be easily discernible. Media not identified as confidential may not be
adequately protected or may be lost or stolen. Note: This does not mean
the media needs to have a “Confidential” label attached; the intent is that
the organization has identified media that contains sensitive data so it can
protect it.
Malicious users often attempt to alter audit logs to hide their actions, and a
record of access allows an organization to trace any inconsistencies or
potential tampering of the logs to an individual account. Having access to
logs identifying changes, additions, and deletions can help retrace steps
made by unauthorized personnel.
Turning the audit logs off (or pausing them) prior to performing illicit
activities is a common practice for malicious users wishing to avoid
detection. Initialization of audit logs could indicate that the log function was
disabled by a user to hide their actions.
Adequate protection of the audit logs includes strong access control (limit
access to logs based on “need to know” only), and use of physical or
network segregation to make the logs harder to find and modify.
Promptly backing up the logs to a centralized log server or media that is
difficult to alter keeps the logs protected even if the system generating the
logs becomes compromised.
Many breaches occur over days or months before being detected. Regular
log reviews by personnel or automated means can identify and proactively
address unauthorized access to the cardholder data environment.
The log review process does not have to be manual. The use of log
harvesting, parsing, and alerting tools can help facilitate the process by
identifying log events that need to be reviewed.
Checking logs daily minimizes the amount of time and exposure of a
potential breach.
Daily review of security events—for example, notifications or alerts that
identify suspicious or anomalous activities—as well as logs from critical
system components, and logs from systems that perform security
functions, such as firewalls, IDS/IPS, file-integrity monitoring (FIM)
systems, etc. is necessary to identify potential issues. Note that the
determination of “security event” will vary for each organization and may
include consideration for the type of technology, location, and function of
the device. Organizations may also wish to maintain a baseline of “normal”
traffic to help identify anomalous behavior.
Logs for all other system components should also be periodically reviewed
to identify indications of potential issues or attempts to gain access to
sensitive systems via less-sensitive systems. The frequency of the reviews
should be determined by an entity’s annual risk assessment.
Without formal processes to detect and alert when critical security controls
fail, failures may go undetected for extended periods and provide attackers
ample time to compromise systems and steal sensitive data from the
cardholder data environment.
The specific types of failures may vary depending on the function of the
device and technology in use. Typical failures include a system ceasing to
perform its security function or not functioning in its intended manner; for
example, a firewall erasing all its rules or going offline.
Note: This requirement applies only when the entity being assessed is a
service provider
If critical security control failures alerts are not quickly and effectively
responded to, attackers may use this time to insert malicious software,
gain control of a system, or steal data from the entity’s environment.
Note: This requirement applies only when the entity being assessed is a
service provider.
Once these weaknesses are identified, the entity corrects them and
repeats the scan until all vulnerabilities have been corrected.
Identifying and addressing vulnerabilities in a timely manner reduces the
likelihood of a vulnerability being exploited and potential compromise of a
system component or cardholder data.
See below
Hardware Configuration Firewall and router configuration are set to permit only
established connections into the internal network and denies
any inbound connections not associated with a previously
established session. Firewall and router configuration standard
must provide the inventory of those established connections.
Hardware Configuration Firewall and router configuration are set to permit only
established connections into the internal network and denies
any inbound connections not associated with a previously
established session. Firewall and router configuration standard
must provide the inventory of those established connections.
Hardware Configuration The firewall and router configuration (includes the standard)
should contain, spanning any varying technologies, methods
used to meet the intent of this requirement: i.e., the controls
used to meet this requirement may be different for IPv4
networks than for IPv6 networks.
Hardware Configuration Atos Policy and the Technical System Security guide have this
listed as a requirement. Any portable computing device that
connects to the network (CDE) have the firewall configuration
in place. This will be a system check before being allowed to
connect to the CDE:
Hardware Configuration The firewall and router configuration standard (can be in the
network standard) must include all inbound and outbound
traffic necessary for the cardholder data environment.
Hardware Configuration The firewall and router configuration standard (can be in the
network standard) must include:
Hardware Configuration The firewall and router configuration standard (can be in the
network standard) must include:
Hardware Configuration The firewall and router configuration standard (can be in the
network standard) must include:
▪ Ensure firewall filters block traffic from the internet that has a
source address from inside the network-Set up rules on the
firewall, router and other network gateways that examine
incoming packets i.e., drop conflicting source IPs.
▪ Filter outgoing packets that have a source address different
from the internal network to prevent an attack originating from
the local site.
Hardware Configuration Firewall and router configuration restrict traffic to only
authorized communications (for example: restricting
source/destination addresses/ports and blocking content).
Hardware Configuration Firewall and router configuration are set to permit only
established connections into the internal network and denies
any inbound connections not associated with a previously
established session. Firewall and router configuration standard
must provide the inventory of those established connections.
Hardware Configuration Firewall and router configuration are set to permit only
established connections into the internal network and denies
any inbound connections not associated with a previously
established session. Firewall and router configuration standard
must provide the inventory of those established connections.
Hardware Configuration The firewall and router configuration (includes the standard)
should contain, spanning any varying technologies, methods
used to meet the intent of this requirement: i.e., the controls
used to meet this requirement may be different for IPv4
networks than for IPv6 networks.
Hardware Configuration Atos Policy and the Technical System Security guide have this
listed as a requirement. Any portable computing device that
connects to the network (CDE) have the firewall configuration
in place. This will be a system check before being allowed to
connect to the CDE:
Policy / Process / Procedure Atos security policy, the firewall and router configuration
standard and any applicable Technical System Security guides
illustrate the procedures for managing firewalls, that they're in
use and easily accessible known to all affected parties.
Policy / Process / Procedure There needs to be a unified policy regarding firewall
maintenance including how maintenance procedures are
performed, who has access to the firewall and when
maintenance is scheduled.
Audit / Interview / Sample Review Ideally, you'd want to select an access point vendor that does
not ship with default keys that need to be changed. The
vendors product should also support the latest strong security
standards and make it easy to ensure they are setup correctly.
Please reference requirement 2.1 which speaks to SMTP
community strings and default password change requirements.
Audit / Interview / Sample Review It is imperative that the organization adopts secure benchmark
hardening and vulnerability checklists for each asset in the
environment before it hits production. Proper configuration
standards must be developed (written down and documented)
for all system components. It’s a good idea, and considered a
best practice, to standardize your configurations as much as
possible. You are required to document your configuration
standards and if a system component is checked, it must meet
the specifications you documented.
Audit / Interview / Sample Review Each physical bare-metal server deployed in the organization
should have one primary function per server to prevent
functions that require different security levels from co-existing
on the same server. (For example, web servers, database
servers, and DNS should be implemented on separate
servers.) If virtualization is used, their can be multiple virtual
servers on one physical server, however, that physical server
should have only one primary function (i.e. Web)
Audit / Interview / Sample Review Each physical bare-metal server deployed in the organization
should have one primary function per server to prevent
functions that require different security levels from co-existing
on the same server. (For example, web servers, database
servers, and DNS should be implemented on separate
servers.) If virtualization is used, their can be multiple virtual
servers on one physical server, however, that physical server
should have only one primary function (i.e. Web)
Audit / Interview / Sample Review It is imperative that organization's utilize a defense in depth
strategy and only permit essential ports and services to run on
their network
Audit / Interview / Sample Review Organizations must ensure that security is baked into every
level of the overall application/service deployment. If an
insecure protocol must be leveraged for compatibility
purposes, it should be adequately tested. A safeguard should
also be in place due to the use of the insecure service/protocol
Audit / Interview / Sample Review System administrators and engineers must have knowledge of
common security parameter settings available specifically to
the application/service they are implementing.
Audit / Interview / Sample Review In an effort to prevent misuse, organizations should develop of
policy during the server build process to disable any
unnecessary inherent functionality
Audit / Interview / Sample Review Admin-level system access other than console should be
strongly encrypted
Policy / Process / Procedure Organizations should ensure that the established SLA with
vendors defines the scope of work adequately
Audit / Interview / Sample Review Organizations are not to store the card verification code or
value (three-digit or four-digit number printed on the front or
back of a payment card used to verify card-not-present
transactions) after authorization.
Audit / Interview / Sample Review Organizations should not store the personal identification
number (PIN) or the encrypted PIN block after authorization.
Audit / Interview / Sample Review PAN, if fully displayed on computer screens, receipts, fax or
print out can be used for fraudulent purposes. Hence, it is a
must to verify that PAN should be masked when it appears to
any of the unauthorized individuals.
Audit / Interview / Sample Review The organization must take measures to render PAN
unreadable anywhere it is stored (including on portable digital
media, backup media, and in logs). It is a relatively trivial effort
for a malicious individual to reconstruct original PAN data if
they have access to both the truncated and hashed version of
a PAN.
Audit / Interview / Sample Review If disk encryption is used (rather than file- or column-level
database encryption), logical access must be managed
separately and independently of native operating system
authentication and access control mechanisms
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
Audit / Interview / Sample Review It is extremely important to protect cryptographic keys as any
access to key by a fraudulent individual means that the
information can be decrypted by them and used for all the
wrong purposes.
Policy / Process / Procedure Management of cryptographic keys is as important as the
implementation of the encryption process itself. For
compliance purposes it is important to develop and examine
the documentation that is provided to customers as a guidance
to protect the cryptographic keys.
Audit / Interview / Sample Review Personnel need to be aware of and following security policies
and documented operational procedures for managing the
secure storage of cardholder data on a continuous basis.
Audit / Interview / Sample Review For safe transmission of cardholder data from the sender to
receiver over a public network, it is important to use reliable
certificates or keys, strong encryption, and secure
authentication protocol to transport data over the network. Any
requests to join by systems that could result in an unsafe or
unsecured connection to the network should be rejected.
Audit / Interview / Sample Review For safe transmission of cardholder data from the sender to
receiver over a wireless network, it is important to use reliable
certificates or keys, strong encryption, and secure
authentication protocol to transport data over the network.
Audit / Interview / Sample Review This requirement maintains that Personal Account Numbers
should never be sent unencrypted or in plain text format over a
messaging platform such as emails, instant messengers or
chat, etc. These platforms are vulnerable to exposure through
packet sniffers that can be used by malicious individuals to
extract valuable confidential information such as PAN
Audit / Interview / Sample Review The organization is responsible for documenting and
communicating the security policies and operational
procedures to all affected parties
Audit / Interview / Sample Review Commercial grade anti-virus solutions provide signature-based
malware detection capabilities. New signatures are created
and made available by the vendor to address and protect the
organization from zero day exploits
Audit / Interview / Sample Review Commercial grade anti-virus solutions provide signature-based
malware detection capabilities. New signatures are created
and made available by the vendor to address and protect the
organization from zero day exploits.
Audit / Interview / Sample Review Advanced, extensible, and scalable centralized security
management software allows the organization to ensure in
near real time that all systems are up to date with the latest
signature files, and provide an auditing mechanism to prove
this
Audit / Interview / Sample Review Most commercially available anti virus vendors package their
software in such a way that the mechanisms utilized to ensure
that an endpoint is up to date is persistent. In the event of a
rootkit or some other malicious program designed to detect
and kill this process, a host base intrusion detection system
should be utilized.
Audit / Interview / Sample Review Anti-virus should be set up in such a manner that its settings
cannot be disabled or changed by any user, except the
authorized personnel. When an anti-virus program runs
continuously in the background, it can detect a virus in real
time and will constantly check for malware threats
Audit / Interview / Sample Review The organization is responsible for documenting and
communicating the security policies and operational
procedures to all affected parties
Policy / Process / Procedure Document a software asset list of all tools and libraries that are
used within the development process.
Policy / Process / Procedure Identify the policy/process/work instructions that directs the
organization to periodically review process documentation for
accuracy, updates, evolution to ensure alignment with current
best practice for code development and security
Policy / Process / Procedure Identify the policy/process/work instructions that directs the
organization to periodically review process documentation for
accuracy, updates, evolution to ensure alignment with current
best practice for Change and Configuration Management
Policy / Process / Procedure Identify the policy/process/work instructions that directs the
organization to perform periodic reviews of the network
architecture to ensure that development/test and production
systems are separate and distinct.
User roles are defined and assigned to allow the lowest level
of access required to complete the required activities.
whenever possible, different people should have different
responsibilities in each environment. However, it may be
necessary for a coder to have broad access to the dev/test
environment but only user rights in production for limited
troubleshooting purposes
Policy / Process / Procedure Conduct a periodic review of the Change Management and/or
Configuration Management procedures to ensure the inclusion
of the following:
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not
adversely impact the security of the system
▪ Back-out procedures
Policy / Process / Procedure Conduct a periodic review of the Change Management and/or
Configuration Management procedures to ensure the inclusion
of the following:
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not
adversely impact the security of the system
▪ Back-out procedures
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not
adversely impact the security of the system
▪ Back-out procedures
Policy / Process / Procedure Conduct a periodic review of the Change Management and/or
Configuration Management procedures to ensure the inclusion
of the following:
▪ Documentation of impact
▪ Documented change approval by authorized parties
▪ Functionality testing to verify that the change does not
adversely impact the security of the system
▪ Back-out procedures
Policy / Process / Procedure Conduct a periodic review of the Change Management and/or
Configuration Management procedures to ensure the inclusion
of the following for more significant system changes or
updates:
Policy / Process / Procedure Policies and procedures related to PCI-DSS will be reviewed
and maintained regularly.
Policy / Process / Procedure With role-based access control (RBAC), a subject is given one
or more roles depending on the subject’s job. Access is
determined by the subject’s role. This control calls for these
specific job roles to be defined, so that principles of least
privilege may be incorporated.
Audit / Interview / Sample Review Least principle access dictates that user's are assigned to
roles based on their job function, and that those roles be
assigned the minimum privileges required to fulfill that job
function
Audit / Interview / Sample Review Job classification and function access based on defined roles
ties once again into RBAC
Audit / Interview / Sample Review It is imperative to the organization that it knows of all
individuals with elevated privileges and access. The electronic
storage of this data should be keep confidential, and encrypted
Audit / Interview / Sample Review Access controls systems for each application used by the
organization (especially SaaS-related) should be configured to
implicitly deny access. Access to these systems should be
permitted only once explicitly granted, and level of access
needs to map to a defined role for the user
Audit / Interview / Sample Review Access controls systems for each application used by the
organization (especially SaaS-related) should be configured to
implicitly deny access. Access to these systems should be
permitted only once explicitly granted, and level of access
needs to map to a defined role for the user
Audit / Interview / Sample Review Access controls systems for each application used by the
organization (especially SaaS-related) should be configured to
implicitly deny access. Access to these systems should be
permitted only once explicitly granted, and level of access
needs to map to a defined role for the user
Audit / Interview / Sample Review Access controls systems for each application used by the
organization (especially SaaS-related) should be configured to
implicitly deny access. Access to these systems should be
permitted only once explicitly granted, and level of access
needs to map to a defined role for the user
Audit / Interview / Sample Review The organizational SOP should clearly state what the security
policies and operational procedures are. This SOP should be
kept in a secure space, but available to all employees for easy
review
Audit / Interview / Sample Review Security policies and operational procedures regarding the
restricted access to cardholder data must be documented, and
known by everyone
Policy / Process / Procedure Identify the Policy and Process documents that document the
organization's rules for setting up and maintaining user access,
password requirements and user login protocols.
Policy / Process / Procedure Policy to require each user to have a unique ID.
Include a system check to verify that each ID is unique and
has not been user previously
Design reporting capability to identify "generic" or multi user
accounts
Policy / Process / Procedure A System Access Request process is implemented that
manages requests and authorizations for additions, deletions
and modifications of User IDs and access rights
Policy / Process / Procedure Accounts that have not been accessed within 90 days will be
disabled. Accounts that have not been accessed for longer
periods (length TBD by agreement with the Client) may be
deleted. Reviews of user accounts will be conducted
periodically (weekly / monthly) by assigned administrative
personnel.
Policy / Process / Procedure Vendors requiring access to the system for support or
maintenance will be required to submit a Vendor SAR that
includes information specific to the request, including but not
limited to
Policy / Process / Procedure User Access Management settings will be implemented to lock
account access and require the user contact IT Support or
initiate a password reset that verifies the user identity before
completing the reset and unlocking the account. Recommend
lock out after 3 failed attempts but no more than 6 failed
attempts. Additional measures, including wait times between
failed logins and 2 step authentication may be considered
based on the Client's requirements.
Policy / Process / Procedure All privileged passwords are protected with strong encryption
both at rest and in transit.
The solution includes flexible and centralized password policy
management for all privileged accounts across the
organization including password aging, complexity,
versioning, and archiving. The organizations can set policy for
privileged password format, including the requirements for a
minimum length, and numeric and
alphabetic characters; and can ensure passwords are unique.
Password changes are automated based on an
organizationally-defined time-frame, enabling
organizations to schedule password changes including after
every use, and enforce time limitations on passwords for all
privileged users.
Policy / Process / Procedure The User Access Management process for unlocking disabled
account, resetting passwords, or any other user account
services provided by a support function will require user
authentication via security questions that are stored securely
as part of the users profile.
Policy / Process / Procedure User profile policy will require a minimum length of at least
seven characters. Passwords will contain both numeric and
alphabetic characters.
Policy / Process / Procedure User profile policy and procedures will require:
a passwords/pass phrases to change every 90 days.
Policy / Process / Procedure User profile policy and procedures will require:
The password system will have the ability to keep the last 4
passwords / pass phrases used and prevent users from using
any of the last 4 passwords.
Policy / Process / Procedure Initial password setup and resets are known to the user and to
the personnel who created them and must be changed in a
timely fashion. These passwords are temporary and should
expire within a limited period of time.
Policy / Process / Procedure System configurations for remote access servers and systems
are configured to verify multi-factor authentication for:
All remote access by personnel, both user and administrator,
and
All third-party/vendor remote access (including access to
applications and system components for support or
maintenance purposes).
Policy / Process / Procedure Conduct periodic reviews and audits to ensure that policy and
procedures are published, communicated, trained and followed
regarding strong authentication and password security.
Policy / Process / Procedure Organizational policy and process will implement solutions that
ensure use group, shared, or generic IDs, passwords, or other
authentication methods are managed as follows:
Policy / Process / Procedure As service providers Atos' Organizational policy and process
will implement solutions that ensure use group, shared, or
generic IDs, passwords, or other authentication methods apply
to each customer. Passwords and Pass Phrases will be
unique and will not be used for multiple customers or sites
Policy / Process / Procedure User Access Management and any cooperating resources
responsible for the issuance of additional authentication
mechanisms will have policy, process and tools available to
track and manage the assignment and issuance of physical or
logical security tokens, smart cards, certificates, etc. so that:
Policy / Process / Procedure Policy and procedures will be published and maintained so
that database and application configuration settings ensure
that every user is authenticated before being granted access
to any database containing sensitive data. What is more
threatening is that the user cannot even be traced since that
user is an unknown individual
Audit / Interview / Sample Review Security policies and operational procedures will be published
to the organization's documentation library.
Changes will be communicated via the organizations Change
Management or Communication Management process.
New hires will receive training on the security policies and
procedures as appropriate to their role and responsibilities.
Periodic reviews, audits and refresher training will be
conducted to ensure continued awareness and compliance.
Physical Security Publish and periodically review policy and procedures to:
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and strong procedures will be in place to recognize the
identity of visitors to check whether they are authorized to
enter the sensitive areas of the facility or not.
Physical Security Policy and Process related to physically securing all media will
be published, communicated and trained.
Physical Security Policy and process related to CDE data storage will include an
annual review of documented security protocols and its
implementation
Physical Security Policy and process will require that all media (Meaning any
physical item separate or separable from a computer that
stores or contains payment card information, whether the info
exists on paper, in electronic form on a disc or drive, or in
some other kind of medium) will be identified and classified
according to it's sensitivity. The intent is that the organization
has identified media that contains sensitive data so it can
protect it
Physical Security Policy and process will require that all media sent to outside
facilities is transported via a secured courier and that all
transport activities are tracked, managed and traceable
Physical Security Policy and process that requires all media sent to outside
facilities is transported via a secured courier and that all
transport activities are tracked, managed and traceable will
also include management approval for any and all media that
is moved from a secured area
Physical Security The organization shall publish and maintain policy and process
to perform inventory control and destruction to manage unused
important forms to prevent unauthorized use.
Physical Security The organization will utilize and review media inventory logs to
verify that periodic media inventories are performed at least
annually.
Physical Security The organization will conduct periodic reviews of the policy
and processes related to the storage, transfer, transmission
and destruction of sensitive media. Rules related to sensitive
media may be contained within a more comprehensive policy
related to the storage, transfer, transmission and destruction of
all media.
Physical Security The organization will conduct periodic refresher training and/or
process audits to ensure that the policy and processes related
to the storage, transfer, transmission and destruction of
sensitive media are trained and followed.
Policy / Process / Procedure Asset Management policy and procedures will provide the
guidance and mechanisms to maintain an up-to-date list of
devices. At a minimum, the list will include the following:
Audit / Interview / Sample Review Policy and process will require that training materials are
reviewed periodically to ensure that they are up to date and to
identify opportunities for improvement.
Audit / Interview / Sample Review Auditing and account association to individual named users
must be enabled in order to ensure traceability of data access
- to a specific user. Logging data must be captured to include
user, data and time and level of access (amoung other data
elements). In addition, Implement audit trails for all systems,
alerts on suspicious activity, and a response plan for those
anomalies
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Properly implemented controls should allow the examiner to
assemble all necessary post-event data to properly depict: the
change or level-of-access made, date and time the change(s)
were made, user making the change, etc. The gathering of this
information should extend to all users including system
administrators. Track all admin actions, login attempts, account
changes, and pauses in the audit trail.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Audit / Interview / Sample Review Log data will provide the forensic trail from which to assmble
the "story" of the access, change or removal of restricted data.
Ensuring the necessary data elements to assemble the "story"
will depend on the level of logging and audit data that is
captured. A balance must be struck however between the level
of log data caputred, compared to the requirements to store
and archive the data. Excessive logging can also impact
system performance. This too is a consideration to be made.
Policy / Process / Procedure System administrators or, accounts with root access, (by
default) can modify audit or log data. Actions undertaken using
these accounts should be logged and audited frequently. In
addition, automated notifications should be considered when
elevated accounts access, or modify log data. Enable a
"separation of duties" approach users who have system
administrator access, to those who have access to log or audit
data.
Policy / Process / Procedure System administrators or, accounts with root access, (by
default) can modify audit or log data. Actions undertaken using
these accounts should be logged and audited frequently. In
addition, automated notifications should be considered when
elevated accounts access, or modify log data. Enable a
"separation of duties" approach users who have system
administrator access, to those who have access to log or audit
data.
Policy / Process / Procedure Log files should be backed-up and archived per the
organizational data retention policy to ensure historical access
to log data if needed. Access to log archives should be
restricted to users or accounts with a need-to-know.
Policy / Process / Procedure Log data should be written to non-destructive media (SAN,
NAS, tape, etc.) residing on aspects of the network considered
"trusted" or core. Care should be taken to not store logs on
same systems or external-facing technologies as these
systems may be accessible via the same means of
compromise as the original security event.
Policy / Process / Procedure File Integrity Monitoring (FIM) establishes alerts or notifications
in the event key system files are modified or altered. FIM
should be considered as part of a comprehensive data
protection or log retention program.
Policy / Process / Procedure Device monitoring via internal tool sets or external managed or
monitored security service provider is highly recommended.
Tools or service providers alert on the status, activity
(malicious or other) and health of critical infrastructure
components.
Policy / Process / Procedure Review security policies frequently to ensure accuracy and
relevancy based on business need. Personnel should be
interviewed to verify that all security policies and procedures
are communicated to them. Efforts can include; security
awaareness training and certification procedures for staff or
associates charged with information-handling, account or
infrastructure administration.
Policy / Process / Procedure Solutions to address this control range from policy
development to technology solutions and software aimed at
detection and reporting.
Policy / Process / Procedure The current incident response plan should be modified to
include procedures for the detection, location, mitigation, and
remediation of unauthorized wireless technologies.
Audit / Interview / Sample Review Internal and External vulnerability scanning is an inspection of
the potential points of exploit on a computer or network to
identify security holes.
Audit / Interview / Sample Review Internal and External vulnerability scanning is an inspection of
the potential points of exploit on a computer or network to
identify security holes.
Audit / Interview / Sample Review A viable penetration testing plan seeks to leverage ethical
hacking techniques to determine how far a mallicous actor
could get in a trusted, secure environment.
Policy / Process / Procedure Remediation reports represent the findings discovered as part
of the Penetration Test. Remediation plans are specific tasks
and timings associated with addressing vulnerabilities
discovered during the test,
Audit / Interview / Sample Review A viable penetration testing plan seeks to leverage ethical
hacking techniques to determine how far a mallicous actor
could get in a trusted, secure environment.
Policy / Process / Procedure Intrusion Detection / Intrusion Prevention systems (IDS / IPS)
monitor for suspect activity and generate alerts and automated
responses based on pre-determined response profiles.
Policy / Process / Procedure Considerations for this control should be included as part of
the Incident Response Plan.
Policy / Process / Procedure Review security policies frequently to ensure accuracy and
relevancy based on business need. Personnel should be
interviewed to verify that all security policies and procedures
are communicated to them. Efforts can include; security
awaareness training and certification procedures for staff or
associates charged with information-handling, account or
infrastructure administration.
ATOS PCI Control Framework Guidance
Control Implementation Effectiveness of Control
Ensure firewall and router configuration is set to Firewall and router configuration restrict traffic to only
restrict only authorized traffic. authorized communications (for example: restricting
source/destination addresses/ports and blocking content).
Provide a firewall and router configuration that Firewall and router configuration illustrate an inventory of
permits only established connections into the only established connections into the internal network and
internal network and denies any inbound denies any inbound connections not associated with a
connections not associated with a previously previously established session. Firewall and router
established session. Firewall and router configuration standard must provide the inventory of those
configuration standard must provide the inventory established connections.
of those established connections.
Provide a firewall and router configuration that Firewall and router configuration illustrate an inventory of
permits only established connections into the only established connections into the internal network and
internal network and denies any inbound denies any inbound connections not associated with a
connections not associated with a previously previously established session. Firewall and router
established session. Firewall and router configuration standard must provide the inventory of those
configuration standard must provide the inventory established connections.
of those established connections.
Ensure the firewall and router configuration Prevent the disclosure of private IP addresses and routing
standard reflect this requirement. Ensure the information from internal networks to the Internet.
configuration change management tracking Interviewed personnel and support documentation provide
clearly demonstrates this as a priority (from that any disclosure of private IP addresses and routing
inception and through the course of varying information to external entities is authorized.
changes). Approach and delivery must be
interoperable, repeatable and acted upon by
administrators.
Provide the guidance necessary to ensure this Atos Policy and the Technical System Security guide have
requirement is in place--Any portable computing this listed as a requirement--Any portable computing
device that connects to the network (CDE) have device that connects to the network (CDE) have the
the firewall configuration in place. There is an firewall configuration in place. There is an automated
automated system check before a system is system check before a system is allowed to connect to the
allowed to connect to the CDE. Atos CDE:
installs/configures/supports a security baseline (in • Personal firewall software or equivalent functionality is in
the Atos Technical System Security guide) that is place for all portable computing devices (including
the image for every new build and is enforced on company and/or employee-owned) that connect to the
any devices attempting to connect. Internet when outside the network (for example, laptops
used by employees), and which are also used to access
the CDE.
• Specific configuration settings are defined for personal
firewall (or equivalent functionality).
• Personal firewall (or equivalent functionality) is
configured to actively run.
• Personal firewall (or equivalent functionality) is
configured to not be alterable by users of the portable
computing devices.
Atos security policy, the firewall and router Atos security policy, the firewall and router configuration
configuration standard and any applicable standard and any applicable Technical System Security
Technical System Security guides clearly illustrate guides clearly illustrate the procedures for managing
the procedures for managing firewalls, that firewalls, that they're in use and easily accessible known
they're in use and easily accessible known to all to all affected parties.
affected parties.
Firewall maintenance requirements should be Realization of this control takes a collaborative effort
spelled out in the organizations SOP. Who has between the sys admins, firewall admins, network admins,
access to the firewall can be determined via role- and management
based access and/or GPO. Firewall maintenance
should almost always be scheduled after core
hours, unless an emergency patch is required
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of ensuring all inbound and
for the inception, changes and approvals to any outbound traffic is understood and has a justification.
inbound and outbound traffic ensuring justification
for each instance.
The firewall and router configuration standard Requirement is effectively communicated in the firewall
(can be in the network standard) provides the and router configuration standard. The current file is
latest configuration file secure from unauthorized stored with only authorized access, synchronized and can
access and that the most current file is be tested at any time.
synchronized.
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of secure and approved
for the inception, changes and approvals to insecure network services, protocols and ports.
secure and approved insecure services,
protocols and ports.
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of secure and approved
for the inception, changes and approvals to insecure network services, protocols and ports.
secure and "approved" insecure services,
protocols and ports.
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of secure and approved
for the inception, changes and approvals to insecure network services, protocols and ports.
secure and "approved" insecure services,
protocols and ports.
The network lifecycle must be formally tracked, The firewall and router configuration standard provides for
via Microsoft suite or in automation (ServiceNow) the life cycle cradle-to-grave, of secure and approved
for the inception, changes and approvals to insecure network services, protocols and ports.
secure and "approved" insecure services,
protocols and ports.
Based upon the firewall capabilities and Firewall and router configuration:
compatibilities, firewall and router configuration:
1. Set firewall filters to block traffic from the 1. Ensure firewall filters block traffic from the internet that
internet that has a source address from inside the has a source address from inside the network-Set up rules
network-Set up rules on the firewall, router and on the firewall, router and other network gateways that
other network gateways that examine incoming examine incoming packets i.e., drop conflicting source IPs.
packets i.e., drop conflicting source IPs. 2. Filter outgoing packets that have a source address
2. Set firewall rules to filter outgoing packets that different from the internal network to prevent an attack
have a source address different from the internal originating from the local site.
network to prevent an attack originating from the
local site.
Ensure firewall and router configuration is set to Firewall and router configuration restrict traffic to only
restrict only authorized traffic. authorized communications (for example: restricting
source/destination addresses/ports and blocking content).
Provide a firewall and router configuration that Firewall and router configuration illustrate an inventory of
permits only established connections into the only established connections into the internal network and
internal network and denies any inbound denies any inbound connections not associated with a
connections not associated with a previously previously established session. Firewall and router
established session. Firewall and router configuration standard must provide the inventory of those
configuration standard must provide the inventory established connections.
of those established connections.
Provide a firewall and router configuration that Firewall and router configuration illustrate an inventory of
permits only established connections into the only established connections into the internal network and
internal network and denies any inbound denies any inbound connections not associated with a
connections not associated with a previously previously established session. Firewall and router
established session. Firewall and router configuration standard must provide the inventory of those
configuration standard must provide the inventory established connections.
of those established connections.
Ensure the firewall and router configuration Prevent the disclosure of private IP addresses and routing
standard reflect this requirement. Ensure the information from internal networks to the Internet.
configuration change management tracking Interviewed personnel and support documentation provide
clearly demonstrates this as a priority (from that any disclosure of private IP addresses and routing
inception and through the course of varying information to external entities is authorized.
changes). Approach and delivery must be
interoperable, repeatable and acted upon by
administrators.
Provide the guidance necessary to ensure this Atos Policy and the Technical System Security guide have
requirement is in place--Any portable computing this listed as a requirement--Any portable computing
device that connects to the network (CDE) have device that connects to the network (CDE) have the
the firewall configuration in place. There is an firewall configuration in place. There is an automated
automated system check before a system is system check before a system is allowed to connect to the
allowed to connect to the CDE. Atos CDE:
installs/configures/supports a security baseline (in • Personal firewall software or equivalent functionality is in
the Atos Technical System Security guide) that is place for all portable computing devices (including
the image for every new build and is enforced on company and/or employee-owned) that connect to the
any devices attempting to connect. Internet when outside the network (for example, laptops
used by employees), and which are also used to access
the CDE.
• Specific configuration settings are defined for personal
firewall (or equivalent functionality).
• Personal firewall (or equivalent functionality) is
configured to actively run.
• Personal firewall (or equivalent functionality) is
configured to not be alterable by users of the portable
computing devices.
Atos security policy, the firewall and router Atos security policy, the firewall and router configuration
configuration standard and any applicable standard and any applicable Technical System Security
Technical System Security guides clearly illustrate guides clearly illustrate the procedures for managing
the procedures for managing firewalls, that firewalls, that they're in use and easily accessible known
they're in use and easily accessible known to all to all affected parties.
affected parties.
Firewall maintenance requirements should be Realization of this control takes a collaborative effort
spelled out in the organizations SOP. Who has between the sys admins, firewall admins, network admins,
access to the firewall can be determined via role- and management
based access and/or GPO. Firewall maintenance
should almost always be scheduled after core
hours, unless an emergency patch is required
This configuration change would be made my the Most wireless access points on the market today do not
admin or engineer responsible for setting up the ship with default encryption keys that need to be changed
WAP. upon arrival. An encryption algorithm such as WPA2/AES
or TKIP should be an option for its configuration. It's usage
is strongly encouraged
The adoption of CIS benchmarks in the These configuration standards must meet some hardening
organization is ultimately a management decision standards such as those from SANS or NIST. The Center
and requires their commitment. The benefits of for Internet Security is the primary recognized industry-
leveraging this standard should be considered by standard for secure configuration guidance, developing
all respective teams, and incorporated by the comprehensive, consensus-derived checklists to help
administrator/engineer prior to the installation of identify and mitigate known security vulnerabilities across
any software. a wide range of platforms. CIS benchmarks provide
prescriptive guidance for establishing a secure
configuration posture for your IT Infrastructure, including a
detailed description and rationale of potential
vulnerabilities together with clear auditing and remediation
steps. As such, the CIS benchmarks are the overwhelming
option of choice for auditors worldwide.
By leveraging tools such as SCCM, Chef, By leveraging tools such as SCCM, Chef, Puppet, or
Puppet, or Alienvault's USM appliance, Alienvault's USM appliance, organizations will be able to
organizations will be able to create an run a create an run a custom scan of their environment ensuring
custom scan of their environment ensuring that that each server has only one primary function
each server has only one primary function
By leveraging tools such as SCCM, Chef, By leveraging tools such as SCCM, Chef, Puppet, or
Puppet, or Alienvault's USM appliance, Alienvault's USM appliance, organizations will be able to
organizations will be able to create an run a create an run a custom scan of their environment ensuring
custom scan of their environment ensuring that that each server has only one primary function
each server has only one primary function
By leveraging tools such as SCCM, Chef, By leveraging tools such as SCCM, Chef, Puppet, or
Puppet, or Alienvault's USM appliance, Alienvault's USM appliance, organizations will be able to
organizations will be able to create and run a create and run a custom scan of their environment
custom scan of their environment ensuring that ensuring that only required services, ports, and protocols
only required services, ports, and protocols are are permitted
permitted
All integrated security features should be well- All integrated security features should be well-
documented and follow an established baseline. documented and follow an established baseline. For
For situations where an insecure protocol must situations where an insecure protocol must be used, this
be used, this documentation should spell out how documentation should spell out how a safeguard is being
a safeguard is being leveraged to protect the leveraged to protect the asset
asset
Organizations can ensure that this knowledge set Organizations can ensure that this knowledge set exists
exists by querying their admins. Most CM tools by querying their admins. Most CM tools will allow you to
will allow you to create an run a custom scan of create an run a custom scan of you environment where
you environment where you can ensure than you can ensure than hardening standards are integrated
hardening standards are integrated per policy per policy
The sys admin or integrator should be able to The sys admin or integrator should be able to confirm this
confirm this requirement. A custom scan of the requirement. A custom scan of the environment using
environment using some CM tool can also ensure some CM tool can also ensure that scripts, etc. are not
that scripts, etc. are not able to be ran able to be ran
The sys admin or integrator would be responsible The system administrator or integrator would be
for ensuring admin access is privileged access responsible for ensuring admin access is privileged access
requiring MFA, and utilizes strong encryption requiring MFA, and utilizes strong encryption algorithms.
algorithms. On Windows systems, a reviews of On Windows systems, a reviews of Services will inform us
Services will inform us if insecure remote-login if insecure remote-login services such as Telnet or
services such as Telnet or prohibited prohibited
Software of this type would need to be installed Assets (hardware, software, etc.) are specified and listed
and maintained by an engineer or admin. If into the management software for easy tracking. From
leveraging a SaaS offering, sufficient support here, criticality levels can be set, as well as a list of
from the vendor should be written into the SLA approved software
A quick review of the SOP or SLA should depict As vendors are engaged and their services leveraged, the
verbiage meant to ensure that applicable established SLA should clearly define a SOW, and who is
personnel are aware of the role they play in responsible for various aspects. Applicable admins and
ensuring that vendor defaults are managed and engineers are to be informed that they have a crucial role
reviewed periodically. The criticality of the service to play in ensuring that the vendor implements their
provided such dictate this interval solution properly and that it is kept current
If leveraging a service provider like AWS to When selecting your hosting provider, ensure that they're
maintain cardholder data, the organization must able to logically segment components on the same server,
have intimate knowledge of how this data is to be as isolate assets into their select security zones. These
stored-particularly if the server being used is zones create their own enclave where specific controls
shared by other tenants. The SLA between the can be applied (usually at an additional cost) based on
organization and the provider will define these the nature of the data
aspects.
The PCI DSS defines the Primary Account The PCI DSS defines the Primary Account Number (PAN),
Number (PAN), cardholder name, expiration date cardholder name, expiration date and service code to be
and service code to be sensitive pieces of sensitive pieces of information that need to be protected
information that need to be protected after being after being stored. Either a manual or an automatic
stored. Either a manual or an automatic process process should be set up which identifies which data
should be set up which identifies which data needs to be stored and which needs to be destroyed and
needs to be stored and which needs to be immediate action should be taken on data that needs to be
destroyed and immediate action should be taken deleted. SDelete is a tool for secure removal on Windows
on data that needs to be deleted. SDelete is a platforms. Use the -D parameter for PCI compliant
tool for secure removal on Windows platforms. removal. SRM is a tool for secure removal on Unix
Use the -D parameter for PCI compliant removal. platforms. Use the -p 7 parameter to specify 7 removal
SRM is a tool for secure removal on Unix passes.
platforms. Use the -p 7 parameter to specify 7
removal passes.
For complying to PCI DSS, data that is termed as For complying to PCI DSS, data that is termed as
authentication data should not be stored beyond authentication data should not be stored beyond the
the retention period. This data includes magnetic retention period. This data includes magnetic strip
strip contents, verification code and PIN. The contents, verification code and PIN. The deletion of such
deletion of such data is important as this data is data is important as this data is extremely valuable for
extremely valuable for scammers as they can scammers as they can make fake duplicate payment cards
make fake duplicate payment cards based upon based upon this information. If sensitive authentication
this information. If sensitive authentication data is data is received, follow the company procedure for safely
received, follow the company procedure for safely deleting the data and verify that no recovery of the data is
deleting the data and verify that no recovery of possible.
the data is possible.
The DB admin will be able to show proof that full The DB admin will be able to show proof that full track
track card data is not captured and maintained on card data is not captured and maintained on the database
the database
The DB admin would be able to ensure that this Set neverPersist to true in the
requirement is met via a simple configuration PaymentSystemPluginMapping.xml file. This option
change captures the CVV data and sends it for payment
authorization in a single transaction. This eliminates the
step to temporarily store the CVV data in the database.
The DB admin will be able to ensure that this The DB admin will be able to ensure that this parameter is
parameter is not maintained in the DB not maintained in the DB
Compliance to this requirement entails written Compliance to this requirement entails written policies and
policies and procedures for masking the display procedures for masking the display of Personal Account
of Personal Account Number (PAN). These Number (PAN). These should enlist which roles are
should enlist which roles are authorized to view authorized to view full PAN and the legitimate reason of
full PAN and the legitimate reason of why they why they need to do so. Only the individuals with the roles
need to do so. Only the individuals with the roles enlisted should be able to see full PAN and any
enlisted should be able to see full PAN and any unauthorized individual should see PAN in masked form.
unauthorized individual should see PAN in By default, the last 5 digits of the account number are
masked form. shown in plain text typically. To be PCI compliant, you
must reduce this to the last 4 digits of the account number.
To change this value, open the
PaymentSystemPluginMapping XML file and change the
value of the plain attribute on the <Keyword
name="account" element from -5 to -4.
Per PCI DSS, the Primary Account Number (PAN) Per PCI DSS, the Primary Account Number (PAN) can be
can be stored after a transaction but it must be stored after a transaction but it must be made illegible by
made illegible by using techniques such as using techniques such as encryption, truncation or
encryption, truncation or hashing. If the PAN hashing. If the PAN stores the cardholder name, expiration
stores the cardholder name, expiration date and date and service code, additional efforts to protect the
service code, additional efforts to protect the data data should be adopted. But if they are stored separately
should be adopted. But if they are stored from the PAN then no additional efforts are required.
separately from the PAN then no additional efforts Hence, the storage plan of these pieces of information
are required. Hence, the storage plan of these must be carefully planned to minimize the complexity.
pieces of information must be carefully planned to
minimize the complexity. Key management is also important when encryption is
being used for compliance purposes. To make encryption
Key management is also important when more effective, limit the access to keys used for decrypting
encryption is being used for compliance the cipher text. By limiting the key backup location, not
purposes. To make encryption more effective, only can you restore the key easily in time of need, you
limit the access to keys used for decrypting the can also put a limit to number of individuals who can
cipher text. By limiting the key backup location, acquire and restore the keys.
not only can you restore the key easily in time of
need, you can also put a limit to number of
individuals who can acquire and restore the keys.
A disk encryption solution such as Intel Security A disk encryption solution such as Intel Security (McAfee)
(McAfee) Complete Endpoint Protection, or Complete Endpoint Protection, or Sophos SafeGuard
Sophos SafeGuard Enterprise should be installed Enterprise should be installed and configured by the
and configured by the organization. These organization. These applications typically come standard
applications typically come standard with the with the security features required to be compliant with this
security features required to be compliant with requirement per PCI DSS
this requirement per PCI DSS
Keys should remain in a protected key vault at all Strict policies and procedures should be implemented and
times. In particular, ensure that there is a gap should ensure the following:
between the threat vectors that have direct
access to the data and the threat vectors that Keys are only access by the fewest possible individuals
have direct access to the keys. This implies that Key-encrypting keys are as strong as the data encrypting
keys should not be stored on the application or keys
web server (assuming that application attackers Key-encrypting keys and data encrypting keys are stored
are part of the relevant threat model) in separate locations
Keys are stored in fewest possible locations
If keys are compromised or an external authority The effectiveness of this control can be measured by
expires them, key changes will be needed. maintaining current documentation of the cryptographic
Application polices or emergency needs will force architecture in a protected space within the organization
application administrators to rotate keys and
potentially rekey data at some point. It's best to
be prepared to rapidly handle this need when
necessary. Including a key version and encryption
algorithm version with the encrypted data is a
useful, proactive feature. For instance, including
a simple prefix string, such as "{1,1}...", prior to
the encrypted data could indicate algorithm
version 1, key version 1. This allows for an
"online" change to the encryption algorithm and
key without re-encrypting all existing data all at
once.
Access to the keys must be restricted to the The effectiveness of this control can be measured by
smallest amount of users possible. This group of reviewing policy around how encryption keys are
users will ideally be users who are highly trusted maintained as well as the key vault itself
and trained to perform Key Custodian duties.
There will obviously be a requirement for
system/service accounts to access the key data
to perform encryption/decryption of data.
Store secret and private keys used to The effectiveness of this control can be measured by
encrypt/decrypt cardholder data in one (or more) reviewing policy around how encryption keys are
of the following forms at all times: maintained as well as the key vault itself
- Encrypted with a key-encrypting key that is at
least as strong as the data-encrypting key, and
that is stored separately from the data-encrypting
key
- Within a secure cryptographic device (such as a
host security module (HSM) or approved point-of-
interaction device)
- As at least two full-length key components or
key shares, in accordance with an industry-
accepted method.
Cryptographic key storage areas are to be limited The effectiveness of this control can be measured by
to environments designed to maintain them, and reviewing policy stating where encryption keys are
where they are deemed absolutely critical maintained and why
The organization should have a complete The effectiveness of this control can be measured by
understanding of how to securely store, transmit reviewing policy addressing all eight (8) applicable sub-
and update the keys without disclosing them to requirements to this control
an unauthorized entity.
The organization must generate strong keys so The effectiveness of this control can be measured by
that the security of the data isn't undermined by reviewing conducting internal pen testing to determine if
weak cryptographic keys. A strong key is the key is weak. A review of the algorithm being used will
generated by using a key length which is also be beneficial
sufficient for your data security requirements and
compliant with the PCI DSS. The key size alone
isn't a measure of the strength of a key. The data
used to generate the key must be sufficiently
random ("sufficient" often being determined by
your data security requirements) and the entropy
of the key data itself must be high.
The method used to distribute keys must be The effectiveness of this control can be measured by
secure to prevent the theft of keys in transit. The reviewing the key vault distribution setting to conclude that
use of a protocol such as Diffie Hellman can help a secure protocol is being used
secure the distribution of keys, the use of secure
transport such as TLS and SSHv2 can also
secure the keys in transit. Older protocols like
SSLv3 should not be used.
Configure key management software to store the The effectiveness of this control can be measured by
merchant key (in encrypted format) in an external reviewing the key management system settings and
file. Specify a key encryption key in a separate configuration
file, which is used to encrypt the merchant key.
Each file should be protected with file system
protection.
The PCI DSS standard mandates that keys used The effectiveness of this control can be measured by
for encryption must be rotated at least annually. reviewing the key management system settings and
The key rotation process must remove an old key configuration
from the encryption/decryption process and
replace it with a new key. All new data entering
the system must encrypted with the new key.
While it is recommended that existing data be
rekeyed with the new key, as per the rekey data
at least every one to three years rule above, it is
not clear that the PCI DSS requires this.
The key management processes must cater for The effectiveness of this control can be measured by
archived, retired or compromised keys. If retired reviewing the key management system settings and
or replaced cryptographic keys need to be configuration
retained, these keys must be securely archived
(for example, by using a key-encryption key).
Archived cryptographic keys should only be used
for decryption/verification purposes.
The requirement for split knowledge and/or dual The effectiveness of this control can be measured by
control for key management prevents an reviewing the key management system settings and
individual user performing key management tasks configuration
such as key rotation or deletion. The system
should require two individual users to perform an
action (i.e. entering a value from their own OTP)
which creates to separate values which are
concatenated two create the final key data.
The system put in place to comply with The effectiveness of this control can be measured by
requirement 3.6.6 can go a long way to reviewing the key management system settings and
preventing unauthorized substitution of key data. configuration
In addition to the dual control process you should
implement strong access control, auditing and
logging for key data so that unauthorized access
attempts are prevented and logged.
To perform the strong key management functions The effectiveness of this control can be measured by
we have seen in requirement 3.6 we must have reviewing the forms signed by the custodians
highly trusted and trained key custodians who
understand how to perform key management
duties. The key custodians must also sign a form
stating they understand the responsibilities that
come with this role.
In order to comply with this requirement, it is The effectiveness of this control can be measured by
necessary that personnel are well aware of assessing the results from personnel interviews
security policies and procedures to manage the
safe storage of cardholder data on a regular
basis. Personnel should be interviewed from time
to time to verify that they understand and
implement those policies and operational
procedures in their routine work involving
cardholder data handling.
It is important to keep in mind that some of the To meet the requirements of the PCI-DSS, you must
authentication protocols such as TLS 1.0, SSL disable weak keys and protocol implementations (such as
v2.0 and SSH v1.0 have vulnerabilities known to SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0) that have
hackers and can easily be exploited by them for known vulnerabilities. These encryption types are
getting information access or even diverting the considered too weak for PCI-DSS compliance. Instead,
information flowing across a network. Hence, to you should use stronger implementations like TLS 1.1 or
prevent this exploitation, protocols should be higher
configured with their secure versions only.
The organization can gauge the effectiveness of The use of WEP and any other algorithm proven to be
this control by reviewing the wireless access point ineffective as a security control must be prohibited within
configuration with an administrator and confirming wireless networks
that weak encryption schemes are not in use
The organization can gauge the effectiveness of Messaging tools such as packet sniffers (which can be
this control by ensuring that messaging tools used for legitimate purposes by a network admin) should
responsible for sending data be configured to only be used for sending information if they have been
encrypt the data being sent or received configured to encrypt the data being sent or received
The organization can gauge the effectiveness of To comply with this PCI DSS requirement, it is important to
this control by establishing periodic reviews of the draft strong policies and procedures regarding the
security policy and interviewing sample sets of protection of cardholder data over a network. There should
users be policies for strong encryption, authenticated protocols
and the use of reliable keys and certificates. Moreover,
these policies and procedures should be communicated to
every individual member of the staff and it should be
ensured that every individual understands them
The anti-virus solution is an application to be In order to be assured that anti-virus is installed and
installed onto the client it is meant to protect. This protecting the endpoint or host, a screenshot will suffice as
can be done manually, as part of an image, or an artifact. This artifact should depict that the endpoint has
remotely executed the most up to date DAT file.
The anti-virus solution is an application to be In order to be assured that anti-virus is installed and
installed onto the client it is meant to protect. This protecting the endpoint or host, a screenshot will suffice as
can be done manually, as part of an image, or an artifact. This artifact should depict that the endpoint has
remotely executed the most up to date DAT file.
A vulnerability scan or pentest on the client is a For systems with distinct operating systems, a formal
definite act that should be carried out by an testing plan should exist to ensure these systems exude
experienced professional no signs of compromise (vulnerability scans, internal
pentest, etc.)
On a periodic basis, members of the OPSEC This capability will either reside on-premise within an
team can run a report, or view via the dashboard enclave or in the cloud. It is testable and configurable per
the current status of all systems within the the organization's requirement.
organization with an anti-virus client. The
capability to monitor threats, signatures fired, and
processes terminated will exist with this platform
This capability can either be reviewed in the This capability can either be reviewed in the vendors
vendors documentation regarding their product, documentation regarding their product, or selectively.
or selectively. enabled. The organization can enabled. The organization can confirm the existence of a
confirm the existence of a HIDS solution by HIDS solution by looking within installed programs on the
looking within installed programs on the endpoint, endpoint, or reviewing the logs feeding into a SIEM
or reviewing the logs feeding into a SIEM
The organization can gauge the effectiveness of A strict policy prohibiting the alteration or disablement of
this control by ensuring that all systems have an the anti-virus should be communicated to the staff to stop
AV client installed and running in real-time. A any weaknesses from potential exploitation. If the anti-
report sample should be generated regularly from virus is disabled for some amount of time due to any
the manager to ensure this is being met reason, extra security measures should be taken such as,
disabling internet connection before disabling anti-virus,
and then performing a system scan after enabling it again.
If an anti-virus program needs to be disabled because of
any technical reasons, permission must be taken by the
authority
The organization can gauge the effectiveness of To make sure that every individual is aware of security
this control by establishing periodic reviews of the policies and operational procedures of an organization,
security policy and interviewing sample sets of and to ensure maximum protection of the network from
users malware, personnel should be communicated the
organizational policies and procedures regarding malware
protection
IA and Cyber Security resources have access to IA and Cyber Security resources have access to a variety
a variety of industry related sources for of industry related sources for vulnerability and risk related
vulnerability and risk related news and news and information
information
Policy and process documentation as well as the
Policy and process documentation as well as the associated mechanism exists related to patches, risks and
associated mechanism exists related to patches, vulnerabilities
risks and vulnerabilities
System components and software have the latest System components and software have the latest vendor-
vendor-supplied security supplied security
patches installed. Critical patches are consistently patches installed. Critical patches are consistently applied
applied within a month of release. within a month of release.
Remove development, test and/or custom Processes, mechanisms and records of code review / peer
application accounts, user IDs, and review / manual or automated testing / verification and
passwords before applications become active or validation should occur and be evident throughout the
are released to customers. lifecycle
Periodic training and audits are conducted to Periodic training and audits are conducted to ensure that
ensure that responsible personnel know how to responsible personnel know how to incorporate security
incorporate security best practices in their coding best practices in their coding and that they implement that
and that they implement that knowledge into their knowledge into their coding practices
coding practices
Remove development, test and/or custom Processes, mechanisms and records of code review / peer
application accounts, user IDs, and review / manual or automated testing / verification and
passwords before applications become active or validation should occur and be evident throughout the
are released to customers. lifecycle
Periodic Reviews are conducted and Periodic Reviews are conducted and documented in the
documented in the Policy or Procedure change Policy or Procedure change history. Resulting changes or
history. Resulting changes or updates would be updates would be recorded as a separate line item
recorded as a separate line item
Development/test functions are separated from Periodic audits and training are scheduled and the results,
production functions. in the form of audits reports and training records are
available for review and action as indicated
In environments where one individual performs
multiple roles (for example application
development and implementing updates to
production systems), duties are assigned such
that no one individual has end-to-end control of a
process without an independent checkpoint.
Assign roles based access that aligns with the Periodic audits and training are scheduled and the results,
roles and responsibility of the resource within in the form of audits reports and training records are
each system or application available for review and action as indicated
Conduct periodic review of process Periodic audits and training are scheduled and the results,
documentation, periodic process audits and/or in the form of audits reports and training records are
training to ensure and verify that mock data, available for review and action as indicated
rather than live data is used for testing and
development
Conduct periodic review of process Periodic audits and training are scheduled and the results,
documentation, periodic process audits and/or in the form of audits reports and training records are
training to ensure and verify that test data and available for review and action as indicated
account information is removed before transition
to the live system
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
A Change Review Board or equivalent function A Change Review Board or equivalent function will have
will have scheduled meetings and an agenda to scheduled meetings and an agenda to review and approve
review and approve upcoming updates and upcoming updates and implementations.
implementations.
CRB Meeting Minutes and artifacts should be available for
CRB Meeting Minutes and artifacts should be review and reference
available for review and reference
Identify the policy/process/work instructions that The organization's recurring training function includes
directs the organization to ensure developers are training for Developer's Secure Coding Techniques that is
trained and current in secure coding techniques administered at least annually.
that are relevant to the application coding
languages used. The organization's onboarding process includes roles
based training requirements for new hires, including
The secure coding techniques must be based on Secure Coding Techniques for Developer roles
industry best practices or standards.
All development personnel, and any other staff A process for conducting this review will also be
and third parties that are subject to the documented.
development policies and procedures will be
made fully aware of the requirements.
As the identity management system is By using an identity management system, the organization
onboarded, roles are created for specific job would know with assured certainty that RBAC is
functions, and a subject has to be assigned to a implemented. Even with legacy systems and software, the
role to execute actions that are authorized for the components of an identity management system - the
role. The system assigns permissions to job provisioning and credentials servers - can be used to
functions based on operations rather than to translate the roles information for the legacy software.
resource objects
Within an identity management system, as roles An identity management system would assist the
are assigned and mapped to job functions, it organization in ensuring that principles of least privileges
must be ensured that each role created has the is adhered to. In order to prevent privilege creep, it
absolute minimum amount of privileges assigned becomes necessary for each role, function, and user
to perform their job tasks. This becomes account mapped to be reviewed periodically
increasingly important with the creation of admin
role function
As the identity management system is By using an identity management system, the organization
onboarded, roles are created for specific job would know with assured certainty that RBAC is
functions, and a subject has to be assigned to a implemented. Even with legacy systems and software, the
role to execute actions that are authorized for the components of an identity management system - the
role. The system assigns permissions to job provisioning and credentials servers - can be used to
functions based on operations rather than to translate the roles information for the legacy software.
resource objects
Within the IAM system, these are built-in By utilizing an IAM system, maintaining a record of admin
capabilities and feature sets that simply must be accounts, and requesting approval becomes seamless.
enabled and configured. Most system will keep track of all your admin users for
you, and send an inquiry to management periodically to
ensure that an individual still require this level of access.
Most IAM systems can now be configured to have admin
access requests be routed to two or three system owners
for their blessing before access can be granted
To ensure that this capability exists and is in To ensure that this capability exists and is in place, once
place, once each new application or system is each new application or system is stood up an admin
stood up an admin needs only to attempt to login needs only to attempt to login via a credential set that has
via a credential set that has not been explicitly not been explicitly permitted access. As long as the
permitted access. As long as the authentication authentication attempt is unsuccessful, the test can be
attempt is unsuccessful, the test can be deemed deemed a success.
a success.
To ensure that this capability exists and is in To ensure that this capability exists and is in place, once
place, once each new application or system is each new application or system is stood up an admin
stood up an admin needs only to attempt to login needs only to attempt to login via a credential set that has
via a credential set that has not been explicitly not been explicitly permitted access. As long as the
permitted access. As long as the authentication authentication attempt is unsuccessful, the test can be
attempt is unsuccessful, the test can be deemed deemed a success.
a success.
To ensure that this capability exists and is in To ensure that this capability exists and is in place, once
place, once each new application or system is each new application or system is stood up an admin
stood up an admin needs only to attempt to login needs only to attempt to login via a credential set that has
via a credential set that has not been explicitly not been explicitly permitted access. As long as the
permitted access. As long as the authentication authentication attempt is unsuccessful, the test can be
attempt is unsuccessful, the test can be deemed deemed a success.
a success.
To ensure that this capability exists and is in To ensure that this capability exists and is in place, once
place, once each new application or system is each new application or system is stood up an admin
stood up an admin needs only to attempt to login needs only to attempt to login via a credential set that has
via a credential set that has not been explicitly not been explicitly permitted access. As long as the
permitted access. As long as the authentication authentication attempt is unsuccessful, the test can be
attempt is unsuccessful, the test can be deemed deemed a success.
a success.
The SOP can easily be reviewed to detect any The SOP can easily be reviewed to detect any
shortcomings in organizational policies, as well as shortcomings in organizational policies, as well as confirm
confirm principles such as least privilege exist. principles such as least privilege exist. This artifact should
This artifact should be revised in accordance with be revised in accordance with industry standards
industry standards guidelines guidelines
Organizational policies and procedures should be All security policies and operational procedures regarding
readily available an visible to all employees for the restricted access to cardholder data should be put in a
review within a secure area documented format, implemented and communicated to all
the parties involved
HR Process documentation for terminated Terminated employees have their assigned physical
employees includes initiating a SAR request with authentication methods retrieved and access rights are
the required information. terminated within the required time limits
responsible HR resources are trained and use
the process as published and instructed
System Access Administrators will have No Windows systems have unused or disabled accounts
documented processes for conducting an inactive
user review. The process may include automated
reporting and/or manual user activity reviews.
Assigned personnel will be trained and will use
the published process to conduct the review and
complete any required actions
System Access Administrators and Vendors will Vendors will not have access to the systems without
have a documented and published process for submitting a request and receiving authorization. All
requesting and conducting vendor related Windows guest accounts are disabled
maintenance and support. This process will
include steps for activating and deactivating
vendor access as well as guidance to monitor the
support or maintenance activities
User Access Management policy will set the No Windows systems have accounts that have never
standards for failed access lock-out. These logged in or never changed their password
standards will be implemented at the network,
system / application and user levels as
appropriate
User Access Management policy will set the No account lockout configuration checks failed
standards for failed access lock-out. These
standards will be implemented at the network,
system / application and user levels as
appropriate
User Access Management policy will set the No session lock/termination configuration checks failed
standards for application/system timeout.
User Access Management policy and processes No password configuration checks failed
will set the standards for user passwords and/or
other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
Identify files that contain PAS information and Passwords files are unreadable both at rest and in transit.
implement a technical solution that masks, at a
minimum, the number of digits required by the
PCI-DSS standards and increase the number of
digits masked to maximize protection while still
allowing resources the ability to use the PAS info
as required for their role and responsibility.
The user creation process will include having the Users requesting account support will be asked to verify
user set up a number of security questions and their identity using the security questions and answers
answers. provided in their user profiles. Disabled accounts will not
be unlocked and no changes or updates will be made
unless the security questions are answered correctly.
The user creation process will include having the Applied password prevent unauthorized users from
user set up a password that is validated against guessing user ID login information thus reducing the risk of
the established requirements unauthorized access to organizational systems and
applications.
Network / System / Application settings would be Account passwords that are not change within the 90-day
set to force passwords to change every 90 days, requirement would be disabled and require an authorized
at a minimum. Users receive reminders started user to request a password reset to unlock their profile to
15 days before the password expiration and are access the system / application.
prompted to change their passwords via a self
service portal or via their technical support team.
Network / System / Application settings would Preventing the repeated use of passwords or passphrases
securely save the last 4 passwords used and provides additional security and reduces the risk of
prevent users from applying any of those unauthorized access via the use of an old password that
passwords / pass phrases as a new passwords / may have been found, discovered or recovered.
pass phrase.
Network / System / Application Policy and Forcing initial passwords and reset passwords to either
process would require initial passwords and change or expire within 24 hours minimizes the risk of
resets to follow the same requirements as the unauthorized access via the usage of common set up or
published password policy. reset passwords.
This requirement is intended to apply to all Only remote users with 2 factor authentication will be
remote personnel with user and administrative allowed to have access to the CDE. This reduces the risk
access to the CDE. of unauthorized access via the discovery or recovery of a
If the entity does not use segmentation to user password alone.
separate the CDE from the rest of their network,
an administrator could use multi-factor
authentication either when logging onto the CDE
network or when logging onto a system.
If the CDE is segmented from the rest of the
entity’s network, an administrator would need to
use multi-factor authentication when connecting
to a CDE system from a non-CDE network. Multi-
factor authentication can be implemented at
network level or at system/application level; it
does not have to be both. If the administrator
uses MFA when logging into the CDE network,
they do not also need to use MFA to log into a
particular system or application within the CDE.
Policy and Process documentation is published Users are familiar with and trained on policy and process
and periodically reviewed and updated. related to password security. Users can locate the
Policy and Process documentation is appropriate published references.
communicated to the appropriate user community
Policy and Process training is provided during on
boarding and periodically
Policy and Process documentation is published to ▪ Generic user IDs are disabled or removed.
periodically review the active user list to ensure: ▪ Shared user IDs do not exist for system administration
and other critical functions.
Generic user IDs are disabled or removed. ▪ Shared and generic user IDs are not used to administer
Shared user IDs do not exist for system any system components.
administration and other critical functions.
Shared and generic user IDs are not used to
administer any system components.
Utilize a random password or pass phrase Atos resource working at multiple client engagements will
generators or another industry accepted method have unique passwords and pass phrases for each site
for ensuring unique passwords and pass with no re-use or duplication.
phrases, even across multiple customers
Policy and Process documentation is published to Physical authentication mechanisms are assigned to 1
periodically review the active user list to ensure: specific user.
▪ Generic user IDs are disabled or removed. Only the account holder assigned to the mechanism can
▪ Shared user IDs do not exist for system use it to gain access.
administration and other critical functions.
▪ Shared and generic user IDs are not used to Policy and process is published and communicated that
administer any system components. guides the use and control of physical authentication
mechanisms.
Automated reporting or manual reviews will be
conducted to complete the review per the client
site's capabilities and environment.
Non-DBA users will not have direct access to Only authorized and authenticated users have direct
query the data. Instead, access should be access to database containing cardholder data. This
provided through programmatic methods only, minimizes the chances of unauthorized and malicious
e.g. through stored procedures. individual gaining access to the system.
Select and install physical controls and implement Only authorized personnel and visitors are granted access
policy and procedures for their effective use and to the CDE. Controls are able to track, monitor and log
management. user access. Systems are locked at all times when not in
use.
Ensure coordination between IT and Security to
ensure system operation and enforcement of
both eh physical security and data security within
the CDE
Video surveillance and access logging should be All physical user access to the CDE is monitored,
considered in the design of a data center, recorded, logged, saved and retrievable for no less than 3
computer room, or other physical area with months.
systems in the CDE.
Ensure that wireless access points, gateways, Only authorized users are able to wireless access points,
handheld devices, networking/communications gateways, handheld devices, networking/communications
hardware, and telecommunication lines are hardware, and telecommunication lines are adequately
adequately secured in order to minimize the risk secured in order to minimize the risk of unauthorized
of unauthorized access or tampering access or tampering
Physically identify employees / contractors / Documented policies and procedures for visitors verify
vendors and visitors by implementing a badging that:
system that clearly and visibly differentiates to
various categories of personnel and include New onsite individuals are distinguished from the regular
processes that direct access level and duration employees .e.g. by assigning a badge.
based on an Access Request Process. Access to the distinguishing mechanism such as assigning
badges, is limited to only authorized staff.
Visitor and Vendor access will expire at a Visitor identification mechanism, e.g. badge, is cancelled
designated time. Employees and Contractors as soon as the visitor leaves. For example, the authorized
may have to renew periodically per Client staff has the responsibility to take back the badge before
requirements and guidance. the visitor leaves.
Access must be controlled in such a manner that When a visit of an authorized individual to a sensitive area
only those employees should be allowed to visit ends, it should be ensured that all access permissions are
the sensitive areas, who have a work-related taken back from him/her and they cannot get access to the
need and are properly authorized. The following CDE again without authorized approval. It should also be
elements must be considered before granting verified that none of the recently terminated employees of
access to cardholder data environment: the organization are trying to gain access to these areas.
To achieve compliance in this area, requirements Only authorized and escorted visitors are authorized into
9.4.1 through 9.4.4 must be met and verified by the CDE thus, reducing unauthorized access of malicious
the authority. individuals to the cardholder data environment.
All visitors should be verified before granting Only authorized and escorted visitors are authorized into
access and must be escorted throughout their the CDE thus, reducing unauthorized access of malicious
visit to areas holding cardholder data. individuals to the cardholder data environment.
Visitor identification such as visitor badges must Only authorized and escorted visitors are authorized into
be identifiable from the inside personnel and the CDE thus, reducing unauthorized access of malicious
should be expired after a certain condition is met. individuals to the cardholder data environment.
Visitors must be asked to return their badges Only authorized and escorted visitors are authorized into
before leaving the facility. the CDE thus, reducing unauthorized access of malicious
individuals to the cardholder data environment.
Maintain a visitor log to keep a record of all Only authorized and escorted visitors are authorized into
individuals visiting the areas holding sensitive the CDE thus, reducing unauthorized access of malicious
information. These logs must mention the name individuals to the cardholder data environment.
of the visitor, the company on whose behalf they
are visiting and the inside personnel who granted
them access.
Keep the log records for a minimum of three
months.
Authorized users follow the published processes Policy and Process related to physically securing all media
for securing all media, including but not limited to: will be published, communicated and trained.
Assign resources and schedule review with Annual reviews should ensure that security protocols are
review criteria in place. sufficient and effective or make recommendations to
improve protocols or identify opportunities for improvement
in performance.
Policy and process will be published, All media is has a classification and responsible resources
communicated and implemented to responsible are knowledgeable in the proper handling of said media
personnel that clearly defines the various types of
media that the organization may create, receive
or otherwise manage. Process documentation
will provide guidance on the storage, transfer,
transmission and destruction of all media,
depending on is classification.
The organization will engage the services of a All media transfers are secure, logged, tracked and
secure courier and implement processes to verifiable
ensure that media transfers are secure, logged,
tracked and verifiable
Processes will ensure that media transport from a Processes will ensure that media transport from a secure
secure area does not take place without area does not take place without management approval
management approval
Policy and process will be published, The organization has minimized the risk of stolen or
communicated and implemented to responsible missing media going unnoticed by having current and
personnel that clearly defines the various types of accurate inventories of sensitive media.
media that the organization may create, receive
or otherwise manage. Process documentation
will provide guidance on the storage, transfer,
transmission and destruction of all media,
depending on is classification.
Policy and process will be published, The organization has minimized the risk of stolen or
communicated and implemented to responsible missing media going unnoticed by periodically reviewing
personnel that clearly defines the various types of the inventory logs for of sensitive media.
media that the organization may create, receive
or otherwise manage. Process documentation
will provide guidance on the storage, transfer,
transmission and destruction of all media,
depending on is classification.
Periodic Reviews are conducted and Policy and processes documentation related to the
documented in the Policy or Procedure change storage, transfer, transmission and destruction of sensitive
history. Resulting changes or updates would be media is current, relevant and aligned with the appropriate
recorded as a separate line item best practices, rules and regulations.
The organization shall establish policy and Sensitive media, in both electronic and hard copy formats
processes to provide training and periodic are destroyed or made unreadable when no longer
process audit to ensure that policy and needed and thereby reducing the risk that sensitive data
processes related to the storage, transfer, could be compromised by unauthorized personnel
transmission and destruction of sensitive media
are trained and followed.
The organization publish and maintain policy and No electronic media is disposed of without first ensuring
procedures to employ verifiable methods for that any sensitive data is destroyed and unrecoverable by
securely destroying electronic media include means of the approved and required electronic media
secure wiping, degaussing, or physical destruction process
destruction (such as grinding or shredding hard
disks).
Asset Management policy and procedures will All assets are accounted for as part of the organizations
provide the guidance and mechanisms to asset management system.
maintain an up-to-date list of devices. At a
minimum, the list will include the following: All devices can be identified at the assigned location
• Make, model of device No devices are found to be not on the asset list
• Location of device (for example, the address of
the site or facility where the device is located)
• Device serial number or other method of unique
identification.
Policy and procedures will be published, trained Employees are trained, knowledgeable and use the
and implemented to provide guidance for periodic appropriate processes to protect devices from being
inspection of devices to detect and report tampered with or replaced by unauthorized personnel
evidence of tempering or replacement.
HR and internal training programs will offer point- Employees are trained, knowledgeable and use the
of-sale security training to new hires and as appropriate processes to protect devices from being
periodic refresher training to employees based on tampered with or replaced by unauthorized personnel
assigned roles and responsibilities.
Policies and procedures are configurable items All affected parties (employees, contractors, vendors, etc.)
and should be included in the organizations CM are aware of, familiar with, and adhere to the policies and
Database process. process for security in and around the CDE
Onboarding and refresher training will be
addressed via the organizations HR/Training
departments or at the group level as appropriate
to the organization.
Reviews and Audits will be addressed by the
organizations QA function to ensure continues
compliance.
Permitted actions without proper authentication or The effectiveness of this control can be measured by
identification should be strictly limited. In addition, frequent audits of the user directory compared to a similar
the use of generic user accounts or, access to review of system access. System activity that does not
system accounts with root access should specifically relate to an individual named-user should be
discouraged. User accounts should be directly discouraged and eliminated where possible.
related to named users through the use of
account creation or modification policy.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
All user account creation, modification of removal The effectiveness of this control can be demonstrated by
should be logged to include, the date and time of test modification of non-production accounts and a
the change, the user account effecting the subsequent review of audit activities.
change and the type of change executed.
Simply stated: If it is not known which users were
logged in at the time of an incident, it is not
possible to identify users that may have been
involved.
All audit log clearing actions should be recorded Sample or Test data should be deleted and testing of
and any individual found guilty of log clearing automated notification and/or logging processes
should be questioned. To limit the possibility of demostrated.
such an event, it is important to restrict the rights
of log clearing to a few authorized individuals only
Every access to the system level objects needs Control effectivness can be demontrated by establishing a
to be closely monitored, but what is more test or control environment by which to make changes that
important is the monitoring of any creation and will not affect production acitivity. Modification of system
deletion of these objects. To achieve this, it is level objects should enabled automated notifications or, at
important to log every user activity on system minimum, generated sufficient log data as to depict the
level objects, such as the name of the user, his user making the change, the type of change made and the
access rights, and the time of access. This data date and time of the change.
can further help finding out whether there was
any creation and/or deletion at that particular time
when the user accessed the particular area. To
achieve full compliance to this requirement, it is
recommended to isolate all system level objects
and get the record of all activities on those
objects.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
The process to track and monitor user access to The effectiveness of this control can be demonstrated by a
cardholder data should be automated to avoid review of system activity contrasted against a review of
any human error. Besides this, every user activity audit events generated programatically. Gaps in the
during log-in time should also be recorded. The logging process should be addressed from a development
data should further be sorted out in such a perspective and sufficiently enabled as to both, cover all
manner that the users who made access to system activity while avoiding increases to system
important and private information over the performance or resource utilization.
network should be separated from the rest.
Automation should include notification processes
to alert in the event of data move, copy
modification of removal.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated a by
synchronization technology is in use and review of time synchronization capabilities between
functional from a common and reliable source. systems and, attempted change of system time against
the system master time controlled. Changes beyond that
of the pre-determined time synchronization controlled
should be denied.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated a by
synchronization technology is in use and review of time synchronization capabilities between
functional from a common and reliable source. systems and, attempted change of system time against
the system master time controlled. Changes beyond that
of the pre-determined time synchronization controlled
should be denied.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated a by
synchronization technology is in use and review of time synchronization capabilities between
functional from a common and reliable source. systems and, attempted change of system time against
the system master time controlled. Changes beyond that
of the pre-determined time synchronization controlled
should be denied.
All systems should be verified to ensure that time The effectivness of this control can be demonstrated by a
synchronization technology is in use and review of time synchronization capabilities between
functional from a common and reliable source. systems and, attempted change of system time against
the system master time controlled. Changes beyond that
of the pre-determined time synchronization controlled
should be denied.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
This requirement maintains that assessment trails The effectiness of this contrl can be demonstrated by
should be secured so that they cannot be altered. establishing test accounts with standard and elevated
As such, strict access control based on need-to- privlidges. Both account types should attempt to access
know classification should be enabled. The use of restricted audit or log data including attempts to modify
system accounts with an ability to delete or this data.
modify audit data should me heavily controlled
(as these can be used anonymously for malicious Account types that are successfully validated could be
purposes). User accounts should be tied to used as account templates from which to base future
specific individuals and the actions of these account creation.
accounts audited frequently.
Implementation of File Integrity Monitoring tools The effectivness of this control can be demonstrated by
(Tripwire, Verisys, CimTrack, etc.) to alert to enababling File Integrity Monitoring tools and
changes of mission-critical, or information- corresponding notification protocols. Test changes made
sensitive log files. to sample data should generate corresponding alerts and
notifications based on the action taken.
Alerting should be set to notify of Change and to
alert administrators directly based on unplanned
deletion to removal.
It is recommended to daily review logs of all the An effective log review or audit program outlines first; a
system components which store, process or process to identify and prioritize logs to be reviewed then
transmit cardholder data or that have indirectly an a schedule and task assignments for the review.
impact on the cardholder data. Review and check
a sample of all system components and servers Automation can be applied to search for anomalous
that carry out security functions. behavior however, this type of review (read: automated) is
not recommended if discreet changes to data are
suspected.
It is recommended to daily review logs of all the An effective log review or audit program outlines first; a
system components which store, process or process to identify and prioritize logs to be reviewed then
transmit cardholder data or that have indirectly an a schedule and task assignments for the review.
impact on the cardholder data. Review and check
a sample of all system components and servers Automation can be applied to search for anomalous
that carry out security functions. behavior however, this type of review (read: automated) is
not recommended if discreet changes to data are
suspected.
It is recommended to daily review logs of all the An effective log review or audit program outlines first; a
system components which store, process or process to identify and prioritize logs to be reviewed then
transmit cardholder data or that have indirectly an a schedule and task assignments for the review.
impact on the cardholder data. Review and check
a sample of all system components and servers Automation can be applied to search for anomalous
that carry out security functions. behavior however, this type of review (read: automated) is
not recommended if discreet changes to data are
suspected.
It is recommended to daily review logs of all the An effective log review or audit program outlines first; a
system components which store, process or process to identify and prioritize logs to be reviewed then
transmit cardholder data or that have indirectly an a schedule and task assignments for the review.
impact on the cardholder data. Review and check
a sample of all system components and servers Automation can be applied to search for anomalous
that carry out security functions. behavior however, this type of review (read: automated) is
not recommended if discreet changes to data are
suspected.
Audit logs must be saved for a minimum time Control effectivness can be demonstrated by a review of
period of one year to cater for the fact that many log retention and log recall procedures to include:
times a security compromise is discovered quite
after some time of its actual occurrence. These Logs greater than three-months old.
logs should be stored online as offline storing of Logs less than three-months old.
logs would result in delayed availability.
Logs greater than three-months old may require more than
At least 3 months old logs should be kept one business-day to access. However, logs less than
somewhere where they are readily available at all three-months old should be available near real-time. This
times. Audit policies and procedures should be is necessary in the event a security episode is identified
examined and personnel should be interviewed to and immediate access to relevant log data is neccessary
verify that proper audit log retention policies exist, to determine how the system was accessed, the exten of
and that official procedures exist to maintain audit the changes made and, the user account responsible for
logs for one year along with immediately available the change.
3 months old logs
A comprhensive device health and activity The effectivness of this control can be demonstrated by
monitoring program includes automated establishing a test environment from which to work and,
notifications in the event of intended or systematically disabling key portions of the environment to
unintended outage. Escalation procedures should demonstrate the corresponding alert. Alerts that are
be developed and enabled to cascade intentionally not acknowledged should casdace to the next
notifications that are not addressed or responded level of management per the defined escalation
to within a period of time determined to match the procedures.
criticality of the infrastructure item. (i.e. "Firewall
Outage Notifications will be responded to within
15 minutes. Notifications within 15 minutes that
are not acknowledged will be escalated to a
supervisor or manager...").
A comprhensive device health and activity The effectivness of this control can be demonstrated by
monitoring program includes automated establishing a test environment from which to work and,
notifications in the event of intended or systematically disabling key portions of the environment to
unintended outage. Escalation procedures should demonstrate the corresponding alert. Alerts that are
be developed and enabled to cascade intentionally not acknowledged should casdace to the next
notifications that are not addressed or responded level of management per the defined escalation
to within a period of time determined to match the procedures.
criticality of the infrastructure item. (i.e. "Firewall
Outage Notifications will be responded to within
15 minutes. Notifications within 15 minutes that
are not acknowledged will be escalated to a
supervisor or manager...").
A comprehensive security program should include The effectivness of this contrl can be demonstrated by
provision for the development and ongoing review of the information security program specific to data
administration of security policies and retention, account and infrastructure administation and, by
procedures. The program should be considered a review of security awareness training and operational
living process that changes as the business and standards.
threat landscape change. Quarterly reviews of
the program schould be includes as part of
program maintenance activities.
To achieve compliance, the following measures Effectiveness of this control can be demonstrated by a
must be taken: number of means, including:
•Verification of policies and procedures to detect * A comparison of current, filed network topology diagrams
and identify authorized and unauthorized wireless to current (actual) state design.
devices. * Penetration testing or, testing of unamortized (or loosely
•Verification of the methodology used for controlled) wireless network segments.,
detection. This should be adequate enough to * Enabling Test configurations of Wireless Detection
identify basic wireless devices such as WLAN technology by enabling an unplanned wireless access
cards, portable devices, and wireless devices point or segment to the network.
connected to network ports.
•Ensuring that network scans are performed on a
quarterly basis
•Verification of automatic notifications in case
automatic monitoring mechanism such as
wireless IPS/IDS is being used.
•Examine the incident response plan to verify that
a mechanism to properly respond to incident
reporting is implemented.
To achieve compliance, the following measures Effectiveness of this control can be demonstrated by a
must be taken: number of means, including:
•Verification of policies and procedures to detect * A comparison of current, filed network topology diagrams
and identify authorized and unauthorized wireless to current (actual) state design.
devices. * Penetration testing or, testing of unamortized (or loosely
•Verification of the methodology used for controlled) wireless network segments.,
detection. This should be adequate enough to * Enabling Test configurations of Wireless Detection
identify basic wireless devices such as WLAN technology by enabling an unplanned wireless access
cards, portable devices, and wireless devices point or segment to the network.
connected to network ports.
•Ensuring that network scans are performed on a
quarterly basis
•Verification of automatic notifications in case
automatic monitoring mechanism such as
wireless IPS/IDS is being used.
•Examine the incident response plan to verify that
a mechanism to properly respond to incident
reporting is implemented.
To achieve compliance, the following steps must Effectiveness of this control can be demonstrated as
be ensured: follows:
•It should be verified that at least four quarterly * At least four quarterly scans were conducted in last 12
scans were conducted in last 12 months. months.
•Scan reports should be reviewed to verify that all • Scan reports should be reviewed to verify that all results
results are rescanned until all high risk are rescanned until all high risk vulnerabilities are
vulnerabilities are removed. removed.
•Verify that the internal scan was conducted by • Verify that the internal scan was conducted by qualified
qualified personnel and that the external scan personnel and that the external scan was conducted by an
was conducted by an Approved Scanning Vendor Approved Scanning Vendor (ASV).
(ASV). • Examine the change control documentation and verify
•Examine the change control documentation and that any change in system components was also made a
verify that any change in system components part of the scanning process.
was also made a part of the scanning process.
To achieve compliance, the following steps must Effectiveness of this control can be demonstrated as
be ensured: follows:
•It should be verified that at least four quarterly * At least four quarterly scans were conducted in last 12
scans were conducted in last 12 months. months.
•Scan reports should be reviewed to verify that all • Scan reports should be reviewed to verify that all results
results are rescanned until all high risk are rescanned until all high risk vulnerabilities are
vulnerabilities are removed. removed.
•Verify that the internal scan was conducted by • Verify that the internal scan was conducted by qualified
qualified personnel and that the external scan personnel and that the external scan was conducted by an
was conducted by an Approved Scanning Vendor Approved Scanning Vendor (ASV).
(ASV). • Examine the change control documentation and verify
•Examine the change control documentation and that any change in system components was also made a
verify that any change in system components part of the scanning process.
was also made a part of the scanning process.
To achieve compliance, the following steps must Effectiveness of this control can be demonstrated as
be ensured: follows:
•It should be verified that at least four quarterly * At least four quarterly scans were conducted in last 12
scans were conducted in last 12 months. months.
•Scan reports should be reviewed to verify that all • Scan reports should be reviewed to verify that all results
results are rescanned until all high risk are rescanned until all high risk vulnerabilities are
vulnerabilities are removed. removed.
•Verify that the internal scan was conducted by • Verify that the internal scan was conducted by qualified
qualified personnel and that the external scan personnel and that the external scan was conducted by an
was conducted by an Approved Scanning Vendor Approved Scanning Vendor (ASV).
(ASV). • Examine the change control documentation and verify
•Examine the change control documentation and that any change in system components was also made a
verify that any change in system components part of the scanning process.
was also made a part of the scanning process.
A penetration test serves to evaluate a system in terms of
Penetration testing in the context of compliance how far a malicious hacker will be able to penetrate into
should involve the following: the network, by simulating an attack. It is a proactive
approach and serves as a counter mechanism by the
* An inventory of application and systems in- organization to develop protective strategies against a
scope. potential attack. A penetration test is one step ahead of a
* A priority rating assigned to each application or vulnerability scan as a penetration tester attempts to
system based on business-criticality and potential exploit the vulnerabilities detected in a vulnerability scan.
risk.
* Based on priority, a plan to test the application. It is important that in order to comply with this requirement,
* Execution of the Pen Test(s) in-scope. the penetration testing mechanism must be examined and
* Resulitng Pen Test report indicating the penetration testers should be interviewed to verify the
following: above mentioned fulfillments. Results should be verified to
- Systems Tested validate that penetration tests are performed at least once
- Level of Access Achieved a year and also after every change within the network.
- Exploits Used to Achieve Access Network and application penetration tests must be verified
- Vulnerabilities Identified. at all levels of the organization. The results of penetration
- Recommendations for Remediation based on tests must also be examined to verify that the discovered
risk and level of exposure. vulnerabilities were removed and a retest confirmed the
removal of those vulnerabilities.
A penetration test serves to evaluate a system in terms of
Penetration testing in the context of compliance how far a malicious hacker will be able to penetrate into
should involve the following: the network, by simulating an attack. It is a proactive
approach and serves as a counter mechanism by the
* An inventory of application and systems in- organization to develop protective strategies against a
scope. potential attack. A penetration test is one step ahead of a
* A priority rating assigned to each application or vulnerability scan as a penetration tester attempts to
system based on business-criticality and potential exploit the vulnerabilities detected in a vulnerability scan.
risk.
* Based on priority, a plan to test the application. It is important that in order to comply with this requirement,
* Execution of the Pen Test(s) in-scope. the penetration testing mechanism must be examined and
* Resulitng Pen Test report indicating the penetration testers should be interviewed to verify the
following: above mentioned fulfillments. Results should be verified to
- Systems Tested validate that penetration tests are performed at least once
- Level of Access Achieved a year and also after every change within the network.
- Exploits Used to Achieve Access Network and application penetration tests must be verified
- Vulnerabilities Identified. at all levels of the organization. The results of penetration
- Recommendations for Remediation based on tests must also be examined to verify that the discovered
risk and level of exposure. vulnerabilities were removed and a retest confirmed the
removal of those vulnerabilities.
IDS / IPS solutions should be placed The effectiness of IDS / IPS implementation can be
implemented based on throrough design reviews demonstrated as part of a comprehensive Penetration
of the network and, proximal to known points of Testing program such that; effective IDS / IPS capabilities
ingress / egress. should significantly limit or, at a minimum, alert to the
existence of penetration attempts.
Where possible, IDS / IPS technology should be
centrally monitored and administered to reduce During a penetration test, an effective IDS / IPS
the need for individual updates and, to ensure implementation will alert to attempted access methods to
events across devices are available for include, type of attempt, location of attempt, time, date,
comprehensive viewing. etc.
Implementation of File Integrity Monitoring tools The effectivness of this control can be demonstrated by
(Tripwire, Verisys, CimTrack, etc.) to alert to enababling File Integrity Monitoring tools and
changes of mission-critical, or information- corresponding notification protocols. Test changes made
sensitive log files. to sample data should generate corresponding alerts and
notifications based on the action taken.
Alerting should be set to notify of Change and to
alert administrators directly based on unplanned
deletion to removal.
Response plans should include an inventory of The effectivness of this contrl can be demonstrated by
systems covered by CMDS, their priority and rehersal of the Incident Response Plan specific to
criticality in the organization and, the priority-level unplanned or unauthorized change management
of response that is expected based on the detection.
change or alert generated.
A comprehensive security program should include The effectivness of this contrl can be demonstrated by
provision for the development and ongoing review of the information security program specific to data
administration of security policies and retention, account and infrastructure administation and, by
procedures. The program should be considered a review of security awareness training and operational
living process that changes as the business and standards.
threat landscape change. Quarterly reviews of
the program schould be includes as part of
program maintenance activities.
Control Output:
Artifact
See Below
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Personnel Interviews
Key Vault Review
Policy Audit
To carry out a compliance check, all
locations of cardholder data transmittal
over public networks should be identified.
The actual applied system configuration
setting should then be checked against
the documented procedures to ensure
that they are actually being put into
practice. The processes should be verified
for recognition of trusted certificates
and/or keys, use of secure version of
protocol and a strong encryption
methodology. Verification should be done
by selecting a sample of data transmission
and identifying whether strong
cryptography is applied on the data during
transit or not, protocol with secured
version is being used and only trusted
keys are accepted. For strong
cryptography, verify that the wireless
networks transmitting the cardholder data
use industry best practices for encryption,
such as IEEE 802.11
Admin Interview
WAP Configuration Review
Policy Audit
Compliance to this requirement entails
that a sample of outbound messages
should be taken and examined. This
would help to verify that Personal Account
Numbers are encrypted via strong
cryptography if end-user messaging
technology is being used to send
cardholder data. Moreover, there should
be a written policy for this and it must be
reviewed to check that it clearly forbids the
transmittal of unprotected or unencrypted
PAN’s across end-user messaging
platforms
Audit records
Training records
Improved metrics reports with acceptable
occurrences of error per SLOC
Meeting notes for peer review
Results of automated testing
Feedback and markups for manual code
reviews.
Change Requests and the resulting
changes management records.
See Below
User profile report that indicates that
personnel with Admin rights in the CDE
require 2 factor authentication.
See Below
Transport Logs
Transport Logs will include proper
management approvals.
training records
Audit Logs / Audit Reports
Action items and follow up records
resulting from Audit Logs and Reports
Destruction logs
Destroyed media transport logs from a 3rd
part vendor.
See Below
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Outputs of test-account modification
aligned with the corresponding audit
records demonstrating the following: Time
and date of change, The change as
executed, The account effecting the
change.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
Artifact(s) include:
* System Context Diagrams depicting end-
to-end system transactions and the points
at which audit data is generated and
captured.
* Audit reports generated by the system
contracted against a manual review of the
same transaction and a review of the data
captured.
AU-10 Non-repudiation
SA-13 Trustworthiness
SC-26 Honeypots
SC-29 Heterogeneity
The information system enforces approved authorizations for controlling the flow of
information within the system and between interconnected systems in accordance with
applicable policy.
The information system notifies the user, upon successful logon (access), of the date
and time of the last logon (access).
The information system limits the number of concurrent sessions for each system
account to [ Assignment: organization-defined number ].
The information system: Prevents further access to the system by initiating a session
lock after [ Assignment: organization-defined time period ] of inactivity or upon
receiving a request from a user; and Retains the session lock until the user reestablishes
access using established identification and authentication procedures.
The organization: Identifies specific user actions that can be performed on the
information system without identification or authentication; and Documents and
provides supporting rationale in the security plan for the information system, user
actions not requiring identification and authentication.
The organization provides basic security awareness training to all information system
users (including managers, senior executives, and contractors) as part of initial training
for new users, when required by system changes, and [ Assignment: organization-
defined frequency ] thereafter.
The information system produces audit records that contain sufficient information to, at
a minimum, establish what type of event occurred, when (date and time) the event
occurred, where the event occurred, the source of the event, the outcome (success or
failure) of the event, and the identity of any user/subject associated with the event.
The organization allocates audit record storage capacity and configures auditing to
reduce the likelihood of such capacity being exceeded.
The information system: Alerts designated organizational officials in the event of an
audit processing failure; and Takes the following additional actions: [ Assignment:
organization-defined actions to be taken (e.g., shut down information system, overwrite
oldest audit records, stop generating audit records) ].
The organization: Reviews and analyzes information system audit records [ Assignment:
organization-defined frequency ] for indications of inappropriate or unusual activity, and
reports findings to designated organizational officials; and Adjusts the level of audit
review, analysis, and reporting within the information system when there is a change in
risk to organizational operations, organizational assets, individuals, other organizations,
or the Nation based on law enforcement information, intelligence information, or other
credible sources of information.
The information system provides an audit reduction and report generation capability.
The information system uses internal system clocks to generate time stamps for audit
records.
The information system protects audit information and audit tools from unauthorized
access, modification, and deletion.
The information system protects against an individual falsely denying having performed
a particular action.
The information system provides the capability to: Capture/record and log all content
related to a user session; and Remotely view/hear all content related to an established
user session in real time.
The organization: Develops a plan of action and milestones for the information system
to document the organizations planned remedial actions to correct weaknesses or
deficiencies noted during the assessment of the security controls and to reduce or
eliminate known vulnerabilities in the system; and Updates existing plan of action and
milestones [ Assignment: organization-defined frequency ] based on the findings from
security controls assessments, security impact analyses, and continuous monitoring
activities.
The organization: Assigns a senior-level executive or manager to the role of authorizing
official for the information system; Ensures that the authorizing official authorizes the
information system for processing before commencing operations; and Updates the
security authorization [ Assignment: organization-defined frequency ].
The organization: Determines the types of changes to the information system that are
configuration controlled; Approves configuration-controlled changes to the system with
explicit consideration for security impact analyses; Documents approved configuration-
controlled changes to the system; Retains and reviews records of configuration-
controlled changes to the system; Audits activities associated with configuration-
controlled changes to the system; and Coordinates and provides oversight for
configuration change control activities through [ Assignment: organization-defined
configuration change control element (e.g., committee, board ] that convenes
[ Selection: (one or more): [ Assignment: organization-defined frequency ] ;
[ Assignment: organization-defined configuration change conditions ]].
The organization analyzes changes to the information system to determine potential
security impacts prior to change implementation.
The organization defines, documents, approves, and enforces physical and logical access
restrictions associated with changes to the information system.
The organization: Establishes and documents mandatory configuration settings for
information technology products employed within the information system using
[ Assignment: organization-defined security configuration checklists ] that reflect the
most restrictive mode consistent with operational requirements; Implements the
configuration settings; Identifies, documents, and approves exceptions from the
mandatory configuration settings for individual components within the information
system based on explicit operational requirements; and Monitors and controls changes
to the configuration settings in accordance with organizational policies and procedures.
The organization configures the information system to provide only essential capabilities
and specifically prohibits or restricts the use of the following functions, ports, protocols,
and/or services: [ Assignment: organization-defined list of prohibited or restricted
functions, ports, protocols, and/or services ].
The organization develops, documents, and maintains an inventory of information
system components that: Accurately reflects the current information system; Is
consistent with the authorization boundary of the information system; Is at the level of
granularity deemed necessary for tracking and reporting; Includes [ Assignment:
organization-defined information deemed necessary to achieve efective property
accountability ]; and Is available for review and audit by designated organizational
officials.
The organization trains personnel in their contingency roles and responsibilities with
respect to the information system and provides refresher training [ Assignment:
organization-defined frequency ].
The organization: Tests and/or exercises the contingency plan for the information
system [ Assignment: organization-defined frequency ] using [ Assignment: organization-
defined tests and/or exercises ] to determine the plans efectiveness and the
organizations readiness to execute the plan; and Reviews the contingency plan
test/exercise results and initiates corrective actions.
The organization provides for the recovery and reconstitution of the information system
to a known state after a disruption, compromise, or failure.
The organization manages information system identifiers for users and devices by:
Receiving authorization from a designated organizational official to assign a user or
device identifier; Selecting an identifier that uniquely identifies an individual or device;
Assigning the user identifier to the intended party or the device identifier to the
intended device; Preventing reuse of user or device identifiers for [ Assignment:
organization-defined time period ]; and Disabling the user identifier after [ Assignment:
organization-defined time period of inactivity ].
The organization manages information system authenticators for users and devices by:
Verifying, as part of the initial authenticator distribution, the identity of the individual
and/or device receiving the authenticator; Establishing initial authenticator content for
authenticators defined by the organization; Ensuring that authenticators have sufficient
strength of mechanism for their intended use; Establishing and implementing
administrative procedures for initial authenticator distribution, for lost/compromised or
damaged authenticators, and for revoking authenticators; Changing default content of
authenticators upon information system installation; Establishing minimum and
maximum lifetime restrictions and reuse conditions for authenticators (if appropriate);
Changing/refreshing authenticators [ Assignment: organization-defined time period by
authenticator type ]; Protecting authenticator content from unauthorized disclosure and
modification; and Requiring users to take, and having devices implement, specific
measures to safeguard authenticators.
The organization: Trains personnel in their incident response roles and responsibilities
with respect to the information system; and Provides refresher training [ Assignment:
organization-defined frequency ].
The organization tests and/or exercises the incident response capability for the
information system [ Assignment: organization-defined frequency ] using [ Assignment:
organization-defined tests and/or exercises ] to determine the incident response
efectiveness and documents the results.
The organization: Implements an incident handling capability for security incidents that
includes preparation, detection and analysis, containment, eradication, and recovery;
Coordinates incident handling activities with contingency planning activities; and
Incorporates lessons learned from ongoing incident handling activities into incident
response procedures, training, and testing/exercises, and implements the resulting
changes accordingly.
The organization approves, controls, monitors the use of, and maintains on an ongoing
basis, information system maintenance tools.
The organization: Sanitizes information system media, both digital and non-digital, prior
to disposal, release out of organizational control, or release for reuse; and Employs
sanitization mechanisms with strength and integrity commensurate with the
classification or sensitivity of the information.
The organization develops, disseminates, and reviews/updates [ Assignment:
organization-defined frequency ]: A formal, documented physical and environmental
protection policy that addresses purpose, scope, roles, responsibilities, management
commitment, coordination among organizational entities, and compliance; and Formal,
documented procedures to facilitate the implementation of the physical and
environmental protection policy and associated physical and environmental protection
controls.
The organization: Develops and keeps current a list of personnel with authorized access
to the facility where the information system resides (except for those areas within the
facility officially designated as publicly accessible); Issues authorization credentials;
Reviews and approves the access list and authorization credentials [ Assignment:
organization-defined frequency ], removing from the access list personnel no longer
requiring access.
The organization: Enforces physical access authorizations for all physical access points
(including designated entry/exit points) to the facility where the information system
resides (excluding those areas within the facility officially designated as publicly
accessible); Verifies individual access authorizations before granting access to the
facility; Controls entry to the facility containing the information system using physical
access devices and/or guards; Controls access to areas officially designated as publicly
accessible in accordance with the organizations assessment of risk; Secures keys,
combinations, and other physical access devices; Inventories physical access devices
[ Assignment: organization-defined frequency ]; and Changes combinations and keys
[ Assignment: organization-defined frequency ] and when keys are lost, combinations
are compromised, or individuals are transferred or terminated.
The organization: Maintains visitor access records to the facility where the information
system resides (except for those areas within the facility officially designated as publicly
accessible); and Reviews visitor access records [ Assignment: organization-defined
frequency ].
The organization protects power equipment and power cabling for the information
system from damage and destruction.
The organization employs and maintains automatic emergency lighting for the
information system that activates in the event of a power outage or disruption and that
covers emergency exits and evacuation routes within the facility.
The organization employs and maintains fire suppression and detection devices/systems
for the information system that are supported by an independent energy source.
The organization: Maintains temperature and humidity levels within the facility where
the information system resides at [ Assignment: organization-defined acceptable
levels ]; and Monitors temperature and humidity levels [ Assignment: organization-
defined frequency ].
The organization protects the information system from damage resulting from water
leakage by providing master shutof valves that are accessible, working properly, and
known to key personnel.
The organization protects the information system from information leakage due to
electromagnetic signals emanations.
The organization appoints a senior information security officer with the mission and
resources to coordinate, develop, implement, and maintain an organization-wide
information security program.
The organization: Ensures that all capital planning and investment requests include the
resources needed to implement the information security program and documents all
exceptions to this requirement; Employs a business case/Exhibit 300/Exhibit 53 to
record the resources required; and Ensures that information security resources are
available for expenditure as planned.
The organization implements a process for ensuring that plans of action and milestones
for the security program and the associated organizational information systems are
maintained and document the remedial information security actions to mitigate risk to
organizational operations and assets, individuals, other organizations, and the Nation.
The organization develops, monitors, and reports on the results of information security
measures of performance.
The organization develops an enterprise architecture with consideration for information
security and the resulting risk to organizational operations, organizational assets,
individuals, other organizations, and the Nation.
The organization: Manages (i.e., documents, tracks, and reports) the security state of
organizational information systems through security authorization processes;
Designates individuals to fulfill specific roles and responsibilities within the
organizational risk management process; and Fully integrates the security authorization
processes into an organization-wide risk management program.
The organization: Defines mission/business processes with consideration for
information security and the resulting risk to organizational operations, organizational
assets, individuals, other organizations, and the Nation; and Determines information
protection needs arising from the defined mission/business processes and revises the
processes as necessary, until an achievable set of protection needs is obtained.
The organization employs a formal sanctions process for personnel failing to comply
with established information security policies and procedures.
The organization: Manages the information system using a system development life
cycle methodology that includes information security considerations; Defines and
documents information system security roles and responsibilities throughout the
system development life cycle; and Identifies individuals having information system
security roles and responsibilities.
The organization includes the following requirements and/or specifications, explicitly or
by reference, in information system acquisition contracts based on an assessment of risk
and in accordance with applicable federal laws, Executive Orders, directives, policies,
regulations, and standards: Security functional requirements/specifications; Security-
related documentation requirements; and Developmental and evaluation-related
assurance requirements.
The organization enforces explicit rules governing the installation of software by users.
The organization applies information system security engineering principles in the
specification, design, development, implementation, and modification of the
information system.
The information system separates user functionality (including user interface services)
from information system management functionality.
The information system prevents unauthorized and unintended information transfer via
shared system resources.
The information system protects against or limits the efects of the following types of
denial of service attacks: [ Assignment: organization-defined list of types of denial of
service attacks or reference to source for current list ].
The information system limits the use of resources by priority.
The organization establishes and manages cryptographic keys for required cryptography
employed within the information system.
The information system protects the integrity and availability of publicly available
information and applications.
The organization: Defines acceptable and unacceptable mobile code and mobile code
technologies; Establishes usage restrictions and implementation guidance for
acceptable mobile code and mobile code technologies; and Authorizes, monitors, and
controls the use of mobile code within the information system.
The organization: Establishes usage restrictions and implementation guidance for Voice
over Internet Protocol (VoIP) technologies based on the potential to cause damage to
the information system if used maliciously; and Authorizes, monitors, and controls the
use of VoIP within the information system.
The information system provides additional data origin and integrity artifacts along with
the authoritative data the system returns in response to name/address resolution
queries.
The information system performs data origin authentication and data integrity
verification on the name/address resolution responses the system receives from
authoritative sources when requested by client systems.
The information systems that collectively provide name/address resolution service for
an organization are fault-tolerant and implement internal/external role separation.
The information system protects the confidentiality and integrity of information at rest.
The organization partitions the information system into components residing in separate
physical domains (or environments) as deemed necessary.
The information system protects the integrity of information during the processes of
data aggregation, packaging, and transformation in preparation for transmission.
The organization: Identifies, reports, and corrects information system flaws; Tests
software updates related to flaw remediation for efectiveness and potential side efects
on organizational information systems before installation; and Incorporates flaw
remediation into the organizational configuration management process.
The organization: Employs malicious code protection mechanisms at information system
entry and exit points and at workstations, servers, or mobile computing devices on the
network to detect and eradicate malicious code: - Transported by electronic mail,
electronic mail attachments, web accesses, removable media, or other common means;
or - Inserted through the exploitation of information system vulnerabilities; Updates
malicious code protection mechanisms (including signature definitions) whenever new
releases are available in accordance with organizational configuration management
policy and procedures; Configures malicious code protection mechanisms to: - Perform
periodic scans of the information system [ Assignment: organization-defined frequency ]
and real-time scans of files from external sources as the files are downloaded, opened,
or executed in accordance with organizational security policy; and - [ Selection (one or
more): block malicious code; quarantine malicious code; send alert to administrator;
[ Assignment: organization-defined action ]] in response to malicious code detection;
and Addresses the receipt of false positives during malicious code detection and
eradication and the resulting potential impact on the availability of the information
system.
The information system verifies the correct operation of security functions [ Selection
(one or more): [ Assignment: organization-defined system transitional states ] ; upon
command by user with appropriate privilege; periodically every [ Assignment:
organization-defined time-period ]] and [ Selection (one or more): notifies system
administrator; shuts the system down; restarts the system; [ Assignment: organization-
defined alternative action(s) ]] when anomalies are discovered.
The organization restricts the capability to input information to the information system
to authorized personnel.
The organization: Protects the information system from harm by considering mean time
to failure for [ Assignment: organization-defined list of information system components ]
in specific environments of operation; and Provides substitute information system
components, when needed, and a mechanism to exchange active and standby roles of
the components.
Control Guidance
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the access control family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The access control policy can be included as part of
the general information security policy for the organization. Access control procedures can be developed for
the security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the access control policy. Related control: PM-9.
The identification of authorized users of the information system and the specification of access privileges is
consistent with the requirements in other security controls in the security plan. Users requiring administrative
privileges on information system accounts receive additional scrutiny by organizational officials responsible for
approving such accounts and privileged access. Related controls: AC-3, AC-4, AC-5, AC-6, AC-10, AC-17, AC-19,
AC-20, AU-9, IA-4, IA-5, CM-5, CM-6, MA-3, MA-4, MA-5, SA-7, SC-13, SI-9.
Access control policies (e.g., identity-based policies, role-based policies, attribute-based policies) and access
enforcement mechanisms (e.g., access control lists, access control matrices, cryptography) are employed by
organizations to control access between users (or processes acting on behalf of users) and objects (e.g.,
devices, files, records, processes, programs, domains) in the information system. In addition to enforcing
authorized access at the information-system level, access enforcement mechanisms are employed at the
application level, when necessary, to provide increased information security for the organization.
Consideration is given to the implementation of an audited, explicit override of automated mechanisms in the
event of emergencies or other serious events. If encryption of stored information is employed as an access
enforcement mechanism, the cryptography used is FIPS 140-2 (as amended) compliant. For classified
information, the cryptography used is largely dependent on the classification level of the information and the
clearances of the individuals having access to the information. Mechanisms implemented by AC-3 are
configured to enforce authorizations determined by other security controls. Related controls: AC-2, AC-4, AC-5,
AC-6, AC-16, AC-17, AC-18, AC-19, AC-20, AC-21, AC-22, AU-9, CM-5, CM-6, MA-3, MA-4, MA-5, SA-7, SC-13, SI-
9.
Information flow control regulates where information is allowed to travel within an information system and
between information systems (as opposed to who is allowed to access the information) and without explicit
regard to subsequent accesses to that information. A few examples of flow control restrictions include:
keeping export controlled information from being transmitted in the clear to the Internet, blocking outside
traffic that claims to be from within the organization, and not passing any web requests to the Internet that are
not from the internal web proxy. Information flow control policies and enforcement mechanisms are
commonly employed by organizations to control the flow of information between designated sources and
destinations (e.g., networks, individuals, devices) within information systems and between interconnected
systems. Flow control is based on the characteristics of the information and/or the information path. Specific
examples of flow control enforcement can be found in boundary protection devices (e.g., proxies, gateways,
guards, encrypted tunnels, firewalls, and routers) that employ rule sets or establish configuration settings that
restrict information system services, provide a packet-filtering capability based on header information, or
message-filtering capability based on content (e.g., using key word searches or document characteristics).
Mechanisms implemented by AC-4 are configured to enforce authorizations determined by other security
controls. Related controls: AC-17, AC-19, AC-21, CM-7, SA-8, SC-2, SC-5, SC-7, SC-18.
Examples of separation of duties include: (i) mission functions and distinct information system support
functions are divided among diferent individuals/roles; (ii) diferent individuals perform information system
support functions (e.g., system management, systems programming, configuration management, quality
assurance and testing, network security); (iii) security personnel who administer access control functions do
not administer audit functions; and (iv) diferent administrator accounts for diferent roles. Access
authorizations defined in this control are implemented by control AC-3. Related controls: AC-3.
The access authorizations defined in this control are largely implemented by control AC-3. The organization
employs the concept of least privilege for specific duties and information systems (including specific ports,
protocols, and services) in accordance with risk assessments as necessary to adequately mitigate risk to
organizational operations and assets, individuals, other organizations, and the Nation. Related controls: AC-2,
AC-3, CM-7.
Due to the potential for denial of service, automatic lockouts initiated by the information system are usually
temporary and automatically release after a predetermined time period established by the organization. If a
delay algorithm is selected, the organization may chose to employ diferent algorithms for diferent
information system components based on the capabilities of those components. Response to unsuccessful
login attempts may be implemented at both the operating system and the application levels. This control
applies to all accesses other than those accesses explicitly identified and documented by the organization in
AC-14.
System use notification messages can be implemented in the form of warning banners displayed when
individuals log in to the information system. System use notification is intended only for information system
access that includes an interactive login interface with a human user and is not intended to require notification
when an interactive interface does not exist.
This control is intended to cover both traditional logons to information systems and general accesses to
information systems that occur in other types of architectural configurations (e.g., service oriented
architectures).
The organization may define the maximum number of concurrent sessions for an information system account
globally, by account type, by account, or a combination. This control addresses concurrent sessions for a given
information system account and does not address concurrent sessions by a single user via multiple system
accounts.
A session lock is a temporary action taken when a user stops work and moves away from the immediate
physical vicinity of the information system but does not want to log out because of the temporary nature of
the absence. The session lock is implemented at the point where session activity can be determined. This is
typically at the operating system-level, but may be at the application-level. A session lock is not a substitute for
logging out of the information system, for example, if the organization requires users to log out at the end of
the workday.
This control is intended for those specific instances where an organization determines that no identification
and authentication is required; it is not, however, mandating that such instances exist in given information
system. The organization may allow a limited number of user actions without identification and authentication
(e.g., when individuals access public websites or other publicly accessible federal information systems such as
http://www.usa.gov). Organizations also identify any actions that normally require identification or
authentication but may under certain circumstances (e.g., emergencies), allow identification or authentication
mechanisms to be bypassed. Such bypass may be, for example, via a software-readable physical switch that
commands bypass of the login functionality and is protected from accidental or unmonitored use. This control
does not apply to situations where identification and authentication have already occurred and are not being
repeated, but rather to situations where identification and/or authentication have not yet occurred. Related
control: CP-2, IA-2.
Security attributes are abstractions representing the basic properties or characteristics of an entity (e.g.,
subjects and objects) with respect to safeguarding information. These attributes are typically associated with
internal data structures (e.g., records, bufers, files) within the information system and are used to enable the
implementation of access control and flow control policies, reflect special dissemination, handling or
distribution instructions, or support other aspects of the information security policy. The term security label is
often used to associate a set of security attributes with a specific information object as part of the data
structure for that object (e.g., user access privileges, nationality, affiliation as contractor). Related controls: AC-
3, AC-4, SC-16, MP-3.
This control requires explicit authorization prior to allowing remote access to an information system without
specifying a specific format for that authorization. For example, while the organization may deem it
appropriate to use a system interconnection agreement to authorize a given remote access, such agreements
are not required by this control. Remote access is any access to an organizational information system by a user
(or process acting on behalf of a user) communicating through an external network (e.g., the Internet).
Examples of remote access methods include dial-up, broadband, and wireless (see AC-18 for wireless access).
A virtual private network when adequately provisioned with appropriate security controls, is considered an
internal network (i.e., the organization establishes a network connection between organization-controlled
endpoints in a manner that does not require the organization to depend on external networks to protect the
confidentiality or integrity of information transmitted across the network). Remote access controls are
applicable to information systems other than public web servers or systems specifically designed for public
access. Enforcing access restrictions associated with remote connections is accomplished by control AC-3.
Related controls: AC-3, AC-18, AC-20, IA-2, IA-3, IA-8, MA-4.
Wireless technologies include, but are not limited to, microwave, satellite, packet radio (UHF/VHF), 802.11x,
and Bluetooth. Wireless networks use authentication protocols (e.g., EAP/TLS, PEAP), which provide credential
protection and mutual authentication. In certain situations, wireless signals may radiate beyond the confines
and control of organization-controlled facilities. Related controls: AC-3, IA-2, IA-3, IA-8.
Mobile devices include portable storage media (e.g., USB memory sticks, external hard disk drives) and
portable computing and communications devices with information storage capability (e.g., notebook/laptop
computers, personal digital assistants, cellular telephones, digital cameras, and audio recording devices).
Organization-controlled mobile devices include those devices for which the organization has the authority to
specify and the ability to enforce specific security requirements. Usage restrictions and implementation
guidance related to mobile devices include, for example, configuration management, device identification and
authentication, implementation of mandatory protective software (e.g., malicious code detection, firewall),
scanning devices for malicious code, updating virus protection software, scanning for critical software updates
and patches, conducting primary operating system (and possibly other resident software) integrity checks, and
disabling unnecessary hardware (e.g., wireless, infrared). Examples of information system functionality that
provide the capability for automatic execution of code are AutoRun and AutoPlay. Organizational policies and
procedures for mobile devices used by individuals departing on and returning from travel include, for example,
determining which locations are of concern, defining required configurations for the devices, ensuring that the
devices are configured as intended before travel is initiated, and applying specific measures to the device after
travel is completed. Specially configured mobile devices include, for example, computers with sanitized hard
drives, limited applications, and additional hardening (e.g., more stringent configuration settings). Specified
measures applied to mobile devices upon return from travel include, for example, examining the device for
signs of physical tampering and purging/reimaging the hard disk drive. Protecting information residing on
mobile devices is covered in the media protection family. Related controls: MP-4, MP-5.
External information systems are information systems or components of information systems that are outside
of the authorization boundary established by the organization and for which the organization typically has no
direct supervision and authority over the application of required security controls or the assessment of
security control efectiveness. External information systems include, but are not limited to: (i) personally
owned information systems (e.g., computers, cellular telephones, or personal digital assistants); (ii) privately
owned computing and communications devices resident in commercial or public facilities (e.g., hotels,
convention centers, or airports); (iii) information systems owned or controlled by nonfederal governmental
organizations; and (iv) federal information systems that are not owned by, operated by, or under the direct
supervision and authority of the organization. For some external systems, in particular those systems operated
by other federal agencies, including organizations subordinate to those agencies, the trust relationships that
have been established between those organizations and the originating organization may be such, that no
explicit terms and conditions are required. In efect, the information systems of these organizations would not
be considered external. These situations typically occur when, for example, there is some pre-existing sharing
or trust agreement (either implicit or explicit) established between federal agencies and/or organizations
subordinate to those agencies, or such trust agreements are specified by applicable laws, Executive Orders,
directives, or policies. Authorized individuals include organizational personnel, contractors, or any other
individuals with authorized access to the organizational information system and over which the organization
has the authority to impose rules of behavior with regard to system access. The restrictions that an
organization imposes on authorized individuals need not be uniform, as those restrictions are likely to vary
depending upon the trust relationships between organizations. Thus, an organization might impose more
stringent security restrictions on a contractor than on a state, local, or tribal government. This control does not
apply to the use of external information systems to access public interfaces to organizational information
systems and information (e.g., individuals accessing federal information through www.usa.gov). The
organization establishes terms and conditions for the use of external information systems in accordance with
organizational security policies and procedures. The terms and conditions address as a minimum; (i) the types
of applications that can be accessed on the organizational information system from the external information
system; and (ii) the maximum security categorization of information that can be processed, stored, and
transmitted on the external information system. This control defines access authorizations enforced by AC-3,
rules of behavior requirements enforced by PL-4, and session establishment rules enforced by AC-17. Related
controls: AC-3, AC-17, PL-4.
The control applies to information that may be restricted in some manner (e.g., privileged medical, contract-
sensitive, proprietary, personally identifiable information, special access programs/compartments) based on
some formal or administrative determination. Depending on the information-sharing circumstance, the
sharing partner may be defined at the individual, group, or organization level and information may be defined
by specific content, type, or security categorization. Related control: AC-3.
Nonpublic information is any information for which the general public is not authorized access in accordance
with federal laws, Executive Orders, directives, policies, regulations, standards, or guidance. Information
protected under the Privacy Act and vendor proprietary information are examples of nonpublic information.
This control addresses posting information on an organizational information system that is accessible to the
general public, typically without identification or authentication. The posting of information on non-
organization information systems is covered by appropriate organizational policy. Related controls: AC-3, AU-
13.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the security awareness and training
family. The policy and procedures are consistent with applicable federal laws, Executive Orders, directives,
policies, regulations, standards, and guidance. Existing organizational policies and procedures may make the
need for additional specific policies and procedures unnecessary. The security awareness and training policy
can be included as part of the general information security policy for the organization. Security awareness and
training procedures can be developed for the security program in general and for a particular information
system, when required. The organizational risk management strategy is a key factor in the development of the
security awareness and training policy. Related control: PM-9.
The organization determines the appropriate content of security awareness training and security awareness
techniques based on the specific requirements of the organization and the information systems to which
personnel have authorized access. The content includes a basic understanding of the need for information
security and user actions to maintain security and to respond to suspected security incidents. The content also
addresses awareness of the need for operations security as it relates to the organizations information security
program. Security awareness techniques can include, for example, displaying posters, ofering supplies
inscribed with security reminders, generating email advisories/notices from senior organizational officials,
displaying logon screen messages, and conducting information security awareness events.
The organization determines the appropriate content of security training based on assigned roles and
responsibilities and the specific requirements of the organization and the information systems to which
personnel have authorized access. In addition, the organization provides information system managers, system
and network administrators, personnel performing independent verification and validation activities, security
control assessors, and other personnel having access to system-level software, adequate security-related
technical training to perform their assigned duties. Organizational security training addresses management,
operational, and technical roles and responsibilities covering physical, personnel, and technical safeguards and
countermeasures. The organization also provides the training necessary for these individuals to carry out their
responsibilities related to operations security within the context of the organizations information security
program. Related controls: AT-2, SA-3.
While an organization may deem that organizationally mandated individual training programs and the
development of individual training plans are necessary, this control does not mandate either. Documentation
for specialized training may be maintained by individual supervisors at the option of the organization.
Ongoing contact with security groups and associations is of paramount importance in an environment of rapid
technology changes and dynamic threats. Security groups and associations can include, for example, special
interest groups, specialized forums, professional associations, news groups, and/or peer groups of security
professionals in similar organizations. The groups and associations selected are consistent with the
organizations mission/business requirements. Information-sharing activities regarding threats, vulnerabilities,
and incidents related to information systems are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the audit and accountability family.
The policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The audit and accountability policy can be included as
part of the general information security policy for the organization. Audit and accountability procedures can be
developed for the security program in general and for a particular information system, when required. The
organizational risk management strategy is a key factor in the development of the audit and accountability
policy. Related control: PM-9.
The purpose of this control is for the organization to identify events which need to be auditable as significant
and relevant to the security of the information system; giving an overall system requirement in order to meet
ongoing and specific audit needs. To balance auditing requirements with other information system needs, this
control also requires identifying that subset of auditable events that are to be audited at a given point in time.
For example, the organization may determine that the information system must have the capability to log
every file access both successful and unsuccessful, but not activate that capability except for specific
circumstances due to the extreme burden on system performance. In addition, audit records can be generated
at various levels of abstraction, including at the packet level as information traverses the network. Selecting
the right level of abstraction for audit record generation is a critical aspect of an audit capability and can
facilitate the identification of root causes to problems. Related control: AU-3.
Audit record content that may be necessary to satisfy the requirement of this control, includes, for example,
time stamps, source and destination addresses, user/process identifiers, event descriptions, success/fail
indications, filenames involved, and access control or flow control rules invoked. Related controls: AU-2, AU-8.
The organization considers the types of auditing to be performed and the audit processing requirements when
allocating audit storage capacity. Related controls: AU-2, AU-5, AU-6, AU-7, SI-4.
Audit processing failures include, for example, software/hardware errors, failures in the audit capturing
mechanisms, and audit storage capacity being reached or exceeded. Related control: AU-4.
An audit reduction and report generation capability provides support for near real-time audit review, analysis,
and reporting requirements described in AU-6 and after-the-fact investigations of security incidents. Audit
reduction and reporting tools do not alter original audit records. Related control: AU-6.
Time stamps generated by the information system include both date and time. The time may be expressed in
Coordinated Universal Time (UTC), a modern continuation of Greenwich Mean Time (GMT), or local time with
an ofset from UTC. Related control: AU-3.
Audit information includes all information (e.g., audit records, audit settings, and audit reports) needed to
successfully audit information system activity. Related controls: AC-3, AC-6.
Examples of particular actions taken by individuals include creating information, sending a message, approving
information (e.g., indicating concurrence or signing a contract), and receiving a message. Non-repudiation
protects individuals against later claims by an author of not having authored a particular document, a sender
of not having transmitted a message, a receiver of not having received a message, or a signatory of not having
signed a document. Non-repudiation services can be used to determine if information originated from an
individual, or if an individual took specific actions (e.g., sending an email, signing a contract, approving a
procurement request) or received specific information. Non-repudiation services are obtained by employing
various techniques or mechanisms (e.g., digital signatures, digital message receipts).
The organization retains audit records until it is determined that they are no longer needed for administrative,
legal, audit, or other operational purposes. This includes, for example, retention and availability of audit
records relative to Freedom of Information Act (FOIA) requests, subpoena, and law enforcement actions.
Standard categorizations of audit records relative to such types of actions and standard response processes for
each type of action are developed and disseminated. The National Archives and Records Administration
(NARA) General Records Schedules (GRS) provide federal policy on record retention.
Audits records can be generated from various components within the information system. The list of audited
events is the set of events for which audits are to be generated. This set of events is typically a subset of the
list of all events for which the system is capable of generating audit records (i.e., auditable events). Related
controls: AU-2, AU-3.
None.
Session auditing activities are developed, integrated, and used in consultation with legal counsel in accordance
with applicable federal laws, Executive Orders, directives, policies, or regulations.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the security assessment and
authorization family. The policies and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The security
assessment/authorization policies can be included as part of the general information security policy for the
organization. Security assessment/authorization procedures can be developed for the security program in
general and for a particular information system, when required. The organizational risk management strategy
is a key factor in the development of the security assessment and authorization policy. Related control: PM-9.
The organization assesses the security controls in an information system as part of: (i) security authorization or
reauthorization; (ii) meeting the FISMA requirement for annual assessments; (iii) continuous monitoring; and
(iv) testing/evaluation of the information system as part of the system development life cycle process. The
assessment report documents the assessment results in sufficient detail as deemed necessary by the
organization, to determine the accuracy and completeness of the report and whether the security controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements of the information system. The FISMA requirement for (at least) annual security
control assessments should not be interpreted by organizations as adding additional assessment requirements
to those requirements already in place in the security authorization process. To satisfy the FISMA annual
assessment requirement, organizations can draw upon the security control assessment results from any of the
following sources, including but not limited to: (i) assessments conducted as part of an information system
authorization or reauthorization process; (ii) continuous monitoring (see CA-7); or (iii) testing and evaluation of
an information system as part of the ongoing system development life cycle (provided that the testing and
evaluation results are current and relevant to the determination of security control efectiveness). Existing
security control assessment results are reused to the extent that they are still valid and are supplemented with
additional assessments as needed. Subsequent to the initial authorization of the information system and in
accordance with OMB policy, the organization assesses a subset of the security controls annually during
continuous monitoring. The organization establishes the security control selection criteria and subsequently
selects a subset of the security controls within the information system and its environment of operation for
assessment. Those security controls that are the most volatile (i.e., controls most afected by ongoing changes
to the information system or its environment of operation) or deemed critical by the organization to protecting
organizational operations and assets, individuals, other organizations, and the Nation are assessed more
frequently in accordance with an organizational assessment of risk. All other controls are assessed at least
once during the information systems three-year authorization cycle. The organization can use the current years
assessment results from any of the above sources to meet the FISMA annual assessment requirement
provided that the results are current, valid, and relevant to determining security control efectiveness. External
audits (e.g., audits conducted by external entities such as regulatory agencies) are outside the scope of this
control. Related controls: CA-6, CA-7, PM-9, SA-11.
This control applies to dedicated connections between information systems and does not apply to transitory,
user-controlled connections such as email and website browsing. The organization carefully considers the risks
that may be introduced when information systems are connected to other systems with diferent security
requirements and security controls, both within the organization and external to the organization. Authorizing
officials determine the risk associated with each connection and the appropriate controls employed. If the
interconnecting systems have the same authorizing official, an Interconnection Security Agreement is not
required. Rather, the interface characteristics between the interconnecting information systems are described
in the security plans for the respective systems. If the interconnecting systems have diferent authorizing
officials but the authorizing officials are in the same organization, the organization determines whether an
Interconnection Security Agreement is required, or alternatively, the interface characteristics between systems
are described in the security plans of the respective systems. Instead of developing an Interconnection
Security Agreement, organizations may choose to incorporate this information into a formal contract,
especially if the interconnection is to be established between a federal agency and a nonfederal (private
sector) organization. In every case, documenting the interface characteristics is required, yet the formality and
approval process vary considerably even though all accomplish the same fundamental objective of managing
the risk being incurred by the interconnection of the information systems. Risk considerations also include
information systems sharing the same networks. Information systems may be identified and authenticated as
devices in accordance with IA-3. Related controls: AC-4, IA-3, SC-7, SA-9.
The plan of action and milestones is a key document in the security authorization package and is subject to
federal reporting requirements established by OMB. Related control: PM-4.
Security authorization is the official management decision, conveyed through the authorization decision
document, given by a senior organizational official or executive (i.e., authorizing official) to authorize operation
of an information system and to explicitly accept the risk to organizational operations and assets, individuals,
other organizations, and the Nation based on the implementation of an agreed-upon set of security controls.
Authorizing officials typically have budgetary oversight for information systems or are responsible for the
mission or business operations supported by the systems. Security authorization is an inherently federal
responsibility and therefore, authorizing officials must be federal employees. Through the security
authorization process, authorizing officials are accountable for the security risks associated with information
system operations. Accordingly, authorizing officials are in management positions with a level of authority
commensurate with understanding and accepting such information system-related security risks. Through the
employment of a comprehensive continuous monitoring process, the critical information contained in the
authorization package (i.e., the security plan (including risk assessment), the security assessment report, and
the plan of action and milestones) is updated on an ongoing basis, providing the authorizing official and the
information system owner with an up-to-date status of the security state of the information system. To reduce
the administrative cost of security reauthorization, the authorizing official uses the results of the continuous
monitoring process to the maximum extent possible as the basis for rendering a reauthorization decision.
OMB policy requires that federal information systems are reauthorized at least every three years or when
there is a significant change to the system. The organization defines what constitutes a significant change to
the information system. Related controls: CA-2, CA-7, PM-9, PM-10.
This control establishes a baseline configuration for the information system and its constituent components
including communications and connectivity-related aspects of the system. The baseline configuration provides
information about the components of an information system (e.g., the standard software load for a
workstation, server, network component, or mobile device including operating system/installed applications
with current version numbers and patch information), network topology, and the logical placement of the
component within the system architecture. The baseline configuration is a documented, up-to-date
specification to which the information system is built. Maintaining the baseline configuration involves creating
new baselines as the information system changes over time. The baseline configuration of the information
system is consistent with the organizations enterprise architecture. Related controls: CM-3, CM-6, CM-8, CM-9.
The organization determines the types of changes to the information system that are configuration controlled.
Configuration change control for the information system involves the systematic proposal, justification,
implementation, test/evaluation, review, and disposition of changes to the system, including upgrades and
modifications. Configuration change control includes changes to components of the information system,
changes to the configuration settings for information technology products (e.g., operating systems,
applications, firewalls, routers), emergency changes, and changes to remediate flaws. A typical organizational
process for managing configuration changes to the information system includes, for example, a chartered
Configuration Control Board that approves proposed changes to the system. Auditing of changes refers to
changes in activity before and after a change is made to the information system and the auditing activities
required to implement the change. Related controls: CM-4, CM-5, CM-6, SI-2.
Security impact analyses are conducted by organizational personnel with information security responsibilities,
including for example, Information System Administrators, Information System Security Officers, Information
System Security Managers, and Information System Security Engineers. Individuals conducting security impact
analyses have the appropriate skills and technical expertise to analyze the changes to information systems and
the associated security ramifications. Security impact analysis may include, for example, reviewing information
system documentation such as the security plan to understand how specific security controls are implemented
within the system and how the changes might afect the controls. Security impact analysis may also include an
assessment of risk to understand the impact of the changes and to determine if additional security controls
are required. Security impact analysis is scaled in accordance with the security categorization of the
information system. Related controls: CA-2, CA-7, CM-3, CM-9, SI-2.
Any changes to the hardware, software, and/or firmware components of the information system can
potentially have significant efects on the overall security of the system. Accordingly, only qualified and
authorized individuals are allowed to obtain access to information system components for purposes of
initiating changes, including upgrades and modifications. Additionally, maintaining records of access is
essential for ensuring that configuration change control is being implemented as intended and for supporting
after-the-fact actions should the organization become aware of an unauthorized change to the information
system. Access restrictions for change also include software libraries. Examples of access restrictions include,
for example, physical and logical access controls (see AC-3 and PE-3), workflow automation, media libraries,
abstract layers (e.g., changes are implemented into a third-party interface rather than directly into the
information system component), and change windows (e.g., changes occur only during specified times, making
unauthorized changes outside the window easy to discover). Some or all of the enforcement mechanisms and
processes necessary to implement this security control are included in other controls. For measures
implemented in other controls, this control provides information to be used in the implementation of the
other controls to cover specific needs related to enforcing authorizations to make changes to the information
system, auditing changes, and retaining and review records of changes. Related controls: AC-3, AC-6, PE-3.
Configuration settings are the configurable security-related parameters of information technology products
that are part of the information system. Security-related parameters are those parameters impacting the
security state of the system including parameters related to meeting other security control requirements.
Security-related parameters include, for example, registry settings; account, file, and directory settings (i.e.,
permissions); and settings for services, ports, protocols, and remote connections. Organizations establish
organization-wide mandatory configuration settings from which the settings for a given information system are
derived. A security configuration checklist (sometimes referred to as a lockdown guide, hardening guide,
security guide, security technical implementation guide [STIG], or benchmark) is a series of instructions or
procedures for configuring an information system component to meet operational requirements. Checklists
can be developed by information technology developers and vendors, consortia, academia, industry, federal
agencies (and other government organizations), and others in the public and private sectors. An example of a
security configuration checklist is the Federal Desktop Core Configuration (FDCC) which potentially afects the
implementation of CM-6 and other controls such as AC-19 and CM-7. The Security Content Automation
Protocol (SCAP) and defined standards within the protocol (e.g., Common Configuration Enumeration) provide
an efective method to uniquely identify, track, and control configuration settings. OMB establishes federal
policy on configuration requirements for federal information systems. Related controls: CM-2, CM-3, SI-4.
Information systems are capable of providing a wide variety of functions and services. Some of the functions
and services, provided by default, may not be necessary to support essential organizational operations (e.g.,
key missions, functions). Additionally, it is sometimes convenient to provide multiple services from a single
component of an information system, but doing so increases risk over limiting the services provided by any
one component. Where feasible, organizations limit component functionality to a single function per device
(e.g., email server or web server, not both). The functions and services provided by organizational information
systems, or individual components of information systems, are carefully reviewed to determine which
functions and services are candidates for elimination (e.g., Voice Over Internet Protocol, Instant Messaging,
auto-execute, file sharing). Organizations consider disabling unused or unnecessary physical and logical ports
and protocols (e.g., Universal Serial Bus [USB], File Transfer Protocol [FTP], Internet Protocol Version 6 [IPv6],
Hyper Text Transfer Protocol [HTTP]) on information system components to prevent unauthorized connection
of devices, unauthorized transfer of information, or unauthorized tunneling. Organizations can utilize network
scanning tools, intrusion detection and prevention systems, and end-point protections such as firewalls and
host-based intrusion detection systems to identify and prevent the use of prohibited functions, ports,
protocols, and services. Related control: RA-5.
Information deemed to be necessary by the organization to achieve efective property accountability can
include, for example, hardware inventory specifications (manufacturer, type, model, serial number, physical
location), software license information, information system/component owner, and for a networked
component/device, the machine name and network address. Related controls: CM-2, CM-6.
Configuration items are the information system items (hardware, software, firmware, and documentation) to
be configuration managed. The configuration management plan satisfies the requirements in the organizations
configuration management policy while being tailored to the individual information system. The configuration
management plan defines detailed processes and procedures for how configuration management is used to
support system development life cycle activities at the information system level. The plan describes how to
move a change through the change management process, how configuration settings and configuration
baselines are updated, how the information system component inventory is maintained, how development,
test, and operational environments are controlled, and finally, how documents are developed, released, and
updated. The configuration management approval process includes designation of key management
stakeholders that are responsible for reviewing and approving proposed changes to the information system,
and security personnel that would conduct an impact analysis prior to the implementation of any changes to
the system. Related control: SA-10.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the contingency planning family.
The policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The contingency planning policy can be included as
part of the general information security policy for the organization. Contingency planning procedures can be
developed for the security program in general and for a particular information system, when required. The
organizational risk management strategy is a key factor in the development of the contingency planning policy.
Related control: PM-9.
Contingency planning for information systems is part of an overall organizational program for achieving
continuity of operations for mission/business operations. Contingency planning addresses both information
system restoration and implementation of alternative mission/business processes when systems are
compromised. Information system recovery objectives are consistent with applicable laws, Executive Orders,
directives, policies, standards, or regulations. In addition to information system availability, contingency plans
also address other security-related events resulting in a reduction in mission/business efectiveness, such as
malicious attacks compromising the confidentiality or integrity of the information system. Examples of actions
to call out in contingency plans include, for example, graceful degradation, information system shutdown, fall
back to a manual mode, alternate information flows, or operating in a mode that is reserved solely for when
the system is under attack. Related controls: AC-14, CP-6, CP-7, CP-8, IR-4, PM-8, PM-11.
None.
There are several methods for testing and/or exercising contingency plans to identify potential weaknesses
(e.g., checklist, walk-through/tabletop, simulation: parallel, full interrupt). Contingency plan testing and/or
exercises include a determination of the efects on organizational operations and assets (e.g., reduction in
mission capability) and individuals arising due to contingency operations in accordance with the plan.
System-level information includes, for example, system-state information, operating system and application
software, and licenses. Digital signatures and cryptographic hashes are examples of mechanisms that can be
employed by organizations to protect the integrity of information system backups. An organizational
assessment of risk guides the use of encryption for protecting backup information. The protection of system
backup information while in transit is beyond the scope of this control. Related controls: CP-6, MP-4.
Recovery is executing information system contingency plan activities to restore essential missions and business
functions. Reconstitution takes place following recovery and includes activities for returning the information
system to its original functional state before contingency plan activation. Recovery and reconstitution
procedures are based on organizational priorities, established recovery point/time and reconstitution
objectives, and appropriate metrics. Reconstitution includes the deactivation of any interim information
system capability that may have been needed during recovery operations. Reconstitution also includes an
assessment of the fully restored information system capability, a potential system reauthorization and the
necessary activities to prepare the system against another disruption, compromise, or failure. Recovery and
reconstitution capabilities employed by the organization can be a combination of automated mechanisms and
manual procedures. Related controls: CA-2, CA-6, CA-7, SC-24.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the identification and
authentication family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The identification and
authentication policy can be included as part of the general information security policy for the organization.
Identification and authentication procedures can be developed for the security program in general and for a
particular information system, when required. The organizational risk management strategy is a key factor in
the development of the identification and authentication policy. Related control: PM-9.
Organizational users include organizational employees or individuals the organization deems to have
equivalent status of employees (e.g., contractors, guest researchers, individuals from allied nations). Users are
uniquely identified and authenticated for all accesses other than those accesses explicitly identified and
documented by the organization in AC-14. Unique identification of individuals in group accounts (e.g., shared
privilege accounts) may need to be considered for detailed accountability of activity. Authentication of user
identities is accomplished through the use of passwords, tokens, biometrics, or in the case of multifactor
authentication, some combination thereof. Access to organizational information systems is defined as either
local or network. Local access is any access to an organizational information system by a user (or process acting
on behalf of a user) where such access is obtained by direct connection without the use of a network. Network
access is any access to an organizational information system by a user (or process acting on behalf of a user)
where such access is obtained through a network connection. Remote access is a type of network access
which involves communication through an external network (e.g., the Internet). Internal networks include local
area networks, wide area networks, and virtual private networks that are under the control of the
organization. For a virtual private network (VPN), the VPN is considered an internal network if the organization
establishes the VPN connection between organization-controlled endpoints in a manner that does not require
the organization to depend on any external networks across which the VPN transits to protect the
confidentiality and integrity of information transmitted. Identification and authentication requirements for
information system access by other than organizational users are described in IA-8. The identification and
authentication requirements in this control are satisfied by complying with Homeland Security Presidential
Directive 12 consistent with organization-specific implementation plans provided to OMB. In addition to
identifying and authenticating users at the information-system level (i.e., at logon), identification and
authentication mechanisms are employed at the application level, when necessary, to provide increased
information security for the organization. Related controls: AC-14, AC-17, AC-18, IA-4, IA-5.
The devices requiring unique identification and authentication may be defined by type, by specific device, or
by a combination of type and device as deemed appropriate by the organization. The information system
typically uses either shared known information (e.g., Media Access Control [MAC] or Transmission Control
Protocol/Internet Protocol [TCP/IP] addresses) for identification or an organizational authentication solution
(e.g., IEEE 802.1x and Extensible Authentication Protocol [EAP], Radius server with EAP-Transport Layer
Security [TLS] authentication, Kerberos) to identify and authenticate devices on local and/or wide area
networks. The required strength of the device authentication mechanism is determined by the security
categorization of the information system.
Common device identifiers include media access control (MAC) or Internet protocol (IP) addresses, or device-
unique token identifiers. Management of user identifiers is not applicable to shared information system
accounts (e.g., guest and anonymous accounts). It is commonly the case that a user identifier is the name of
an information system account associated with an individual. In such instances, identifier management is
largely addressed by the account management activities of AC-2. IA-4 also covers user identifiers not
necessarily associated with an information system account (e.g., the identifier used in a physical security
control database accessed by a badge reader system for access to the information system). Related control:
AC-2, IA-2.
User authenticators include, for example, passwords, tokens, biometrics, PKI certificates, and key cards. Initial
authenticator content is the actual content (e.g., the initial password) as opposed to requirements about
authenticator content (e.g., minimum password length). Many information system components are shipped
with factory default authentication credentials to allow for initial installation and configuration. Default
authentication credentials are often well known, easily discoverable, present a significant security risk, and
therefore, are changed upon installation. The requirement to protect user authenticators may be implemented
via control PL-4 or PS-6 for authenticators in the possession of users and by controls AC-3, AC-6, and SC-28 for
authenticators stored within the information system (e.g., passwords stored in a hashed or encrypted format,
files containing encrypted or hashed passwords accessible only with super user privileges). The information
system supports user authenticator management by organization-defined settings and restrictions for various
authenticator characteristics including, for example, minimum password length, password composition,
validation time window for time synchronous one time tokens, and number of allowed rejections during
verification stage of biometric authentication. Measures to safeguard user authenticators include, for example,
maintaining possession of individual authenticators, not loaning or sharing authenticators with others, and
reporting lost or compromised authenticators immediately. Authenticator management includes issuing and
revoking, when no longer needed, authenticators for temporary access such as that required for remote
maintenance. Device authenticators include, for example, certificates and passwords. Related controls: AC-2,
IA-2, PL-4, PS-6.
The feedback from the information system does not provide information that would allow an unauthorized
user to compromise the authentication mechanism. Displaying asterisks when a user types in a password, is an
example of obscuring feedback of authentication information.
None.
Non-organizational users include all information system users other than organizational users explicitly
covered by IA-2. Users are uniquely identified and authenticated for all accesses other than those accesses
explicitly identified and documented by the organization in accordance with AC-14. In accordance with the E-
Authentication E-Government initiative, authentication of non-organizational users accessing federal
information systems may be required to protect federal, proprietary, or privacy-related information (with
exceptions noted for national security systems). Accordingly, a risk assessment is used in determining the
authentication needs of the organization. Scalability, practicality, and security are simultaneously considered in
balancing the need to ensure ease of use for access to federal information and information systems with the
need to protect and adequately mitigate risk to organizational operations, organizational assets, individuals,
other organizations, and the Nation. Identification and authentication requirements for information system
access by organizational users are described in IA-2. Related controls: AC-14, AC-17, AC-18, MA-4.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the incident response family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The incident response policy can be included as part
of the general information security policy for the organization. Incident response procedures can be developed
for the security program in general and for a particular information system, when required. The organizational
risk management strategy is a key factor in the development of the incident response policy. Related control:
PM-9.
Incident response training includes user training in the identification and reporting of suspicious activities,
both from external and internal sources. Related control: AT-3.
None.
Incident-related information can be obtained from a variety of sources including, but not limited to, audit
monitoring, network monitoring, physical access monitoring, and user/administrator reports. Related controls:
AU-6, CP-2, IR-2, IR-3, PE-6, SC-5, SC-7, SI-3, SI-4, SI-7.
Documenting information system security incidents includes, for example, maintaining records about each
incident, the status of the incident, and other pertinent information necessary for forensics, evaluating
incident details, trends, and handling. Incident information can be obtained from a variety of sources
including, for example, incident reports, incident response teams, audit monitoring, network monitoring,
physical access monitoring, and user/administrator reports.
The intent of this control is to address both specific incident reporting requirements within an organization
and the formal incident reporting requirements for federal agencies and their subordinate organizations. The
types of security incidents reported, the content and timeliness of the reports, and the list of designated
reporting authorities are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Current federal policy requires that all federal agencies (unless
specifically exempted from such requirements) report security incidents to the United States Computer
Emergency Readiness Team (US-CERT) within specified time frames designated in the US-CERT Concept of
Operations for Federal Cyber Security Incident Handling. Related controls: IR-4, IR-5.
Possible implementations of incident response support resources in an organization include a help desk or an
assistance group and access to forensics services, when required. Related controls: IR-4, IR-6.
It is important that organizations have a formal, focused, and coordinated approach to responding to incidents.
The organizations mission, strategies, and goals for incident response help determine the structure of its
incident response capability.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the system maintenance family.
The policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The information system maintenance policy can be
included as part of the general information security policy for the organization. System maintenance
procedures can be developed for the security program in general and for a particular information system,
when required. The organizational risk management strategy is a key factor in the development of the system
maintenance policy. Related control: PM-9.
The control is intended to address the information security aspects of the organizations information system
maintenance program. Related controls: MP-6, SI-2.
The intent of this control is to address the security-related issues arising from the hardware and software
brought into the information system specifically for diagnostic and repair actions (e.g., a hardware or software
packet snifer that is introduced for the purpose of a particular maintenance activity). Hardware and/or
software components that may support information system maintenance, yet are a part of the system (e.g.,
the software implementing ping, ls, ipconfig, or the hardware and software implementing the monitoring port
of an Ethernet switch) are not covered by this control. Related control: MP-6.
Non-local maintenance and diagnostic activities are those activities conducted by individuals communicating
through a network; either an external network (e.g., the Internet) or an internal network. Local maintenance
and diagnostic activities are those activities carried out by individuals physically present at the information
system or information system component and not communicating across a network connection. Identification
and authentication techniques used in the establishment of non-local maintenance and diagnostic sessions are
consistent with the network access requirements in IA-2. Strong authenticators include, for example, PKI
where certificates are stored on a token protected by a password, passphrase, or biometric. Enforcing
requirements in MA-4 is accomplished in part, by other controls. Related controls: AC-2, AC-3, AC-6, AC-17,
AU-2, AU-3, IA-2, IA-8, MA-5, MP-6, SC-7.
Individuals not previously identified in the information system, such as vendor personnel and consultants, may
legitimately require privileged access to the system, for example, when required to conduct maintenance or
diagnostic activities with little or no notice. Based on a prior assessment of risk, the organization may issue
temporary credentials to these individuals. Temporary credentials may be for one-time use or for a very
limited time period. Related controls: IA-8, MA-5.
The organization specifies those information system components that, when not operational, result in
increased risk to organizations, individuals, or the Nation because the security functionality intended by that
component is not being provided. Security-critical components include, for example, firewalls, guards,
gateways, intrusion detection systems, audit repositories, authentication servers, and intrusion prevention
systems. Related control: CP-2.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the media protection family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The media protection policy can be included as part
of the general information security policy for the organization. Media protection procedures can be developed
for the security program in general and for a particular information system, when required. The organizational
risk management strategy is a key factor in the development of the media protection policy. Related control:
PM-9.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, external/removable
hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper,
microfilm). This control also applies to mobile computing and communications devices with information
storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital
cameras, and audio recording devices). An organizational assessment of risk guides the selection of media and
associated information contained on that media requiring restricted access. Organizations document in policy
and procedures, the media requiring restricted access, individuals authorized to access the media, and the
specific measures taken to restrict access. Fewer protection measures are needed for media containing
information determined by the organization to be in the public domain, to be publicly releasable, or to have
limited or no adverse impact if accessed by other than authorized personnel. In these situations, it is assumed
that the physical access controls where the media resides provide adequate protection. Related controls: MP-
4, PE-3.
The term marking is used when referring to the application or use of human-readable security attributes. The
term labeling is used when referring to the application or use of security attributes with regard to internal data
structures within the information system (see AC-16, Security Attributes). Removable information system
media includes both digital media (e.g., diskettes, magnetic tapes, external/removable hard drives,
flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). An
organizational assessment of risk guides the selection of media requiring marking. Marking is generally not
required for media containing information determined by the organization to be in the public domain or to be
publicly releasable. Some organizations, however, may require markings for public information indicating that
the information is publicly releasable. Organizations may extend the scope of this control to include
information system output devices containing organizational information, including, for example, monitors and
printers. Marking of removable media and information system output is consistent with applicable federal
laws, Executive Orders, directives, policies, regulations, standards, and guidance.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, external/removable
hard drives, flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper,
microfilm). This control also applies to mobile computing and communications devices with information
storage capability (e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital
cameras, and audio recording devices). Telephone systems are also considered information systems and may
have the capability to store information on internal media (e.g., on voicemail systems). Since telephone
systems do not have, in most cases, the identification, authentication, and access control mechanisms typically
employed in other information systems, organizational personnel use extreme caution in the types of
information stored on telephone voicemail systems. A controlled area is any area or space for which the
organization has confidence that the physical and procedural protections are sufficient to meet the
requirements established for protecting the information and/or information system. An organizational
assessment of risk guides the selection of media and associated information contained on that media
requiring physical protection. Fewer protection measures are needed for media containing information
determined by the organization to be in the public domain, to be publicly releasable, or to have limited or no
adverse impact on the organization or individuals if accessed by other than authorized personnel. In these
situations, it is assumed that the physical access controls to the facility where the media resides provide
adequate protection. As part of a defense-in-depth strategy, the organization considers routinely encrypting
information at rest on selected secondary storage devices. The employment of cryptography is at the
discretion of the information owner/steward. The selection of the cryptographic mechanisms used is based
upon maintaining the confidentiality and integrity of the information. The strength of mechanisms is
commensurate with the classification and sensitivity of the information. Related controls: AC-3, AC-19, CP-6,
CP-9, MP-2, PE-3.
Information system media includes both digital media (e.g., diskettes, magnetic tapes, removable hard drives,
flash/thumb drives, compact disks, digital video disks) and non-digital media (e.g., paper, microfilm). This
control also applies to mobile computing and communications devices with information storage capability
(e.g., notebook/laptop computers, personal digital assistants, cellular telephones, digital cameras, and audio
recording devices) that are transported outside of controlled areas. Telephone systems are also considered
information systems and may have the capability to store information on internal media (e.g., on voicemail
systems). Since telephone systems do not have, in most cases, the identification, authentication, and access
control mechanisms typically employed in other information systems, organizational personnel use caution in
the types of information stored on telephone voicemail systems that are transported outside of controlled
areas. A controlled area is any area or space for which the organization has confidence that the physical and
procedural protections provided are sufficient to meet the requirements established for protecting the
information and/or information system. Physical and technical security measures for the protection of digital
and non-digital media are commensurate with the classification or sensitivity of the information residing on
the media, and consistent with applicable federal laws, Executive Orders, directives, policies, regulations,
standards, and guidance. Locked containers and cryptography are examples of security measures available to
protect digital and non-digital media during transport. Cryptographic mechanisms can provide confidentiality
and/or integrity protections depending upon the mechanisms used. An organizational assessment of risk
guides: (i) the selection of media and associated information contained on that media requiring protection
during transport; and (ii) the selection and use of storage containers for transporting non-digital media.
Authorized transport and courier personnel may include individuals from outside the organization (e.g., U.S.
Postal Service or a commercial transport or delivery service). Related controls: AC-19, CP-9.
This control applies to all media subject to disposal or reuse, whether or not considered removable.
Sanitization is the process used to remove information from information system media such that there is
reasonable assurance that the information cannot be retrieved or reconstructed. Sanitization techniques,
including clearing, purging, and destroying media information, prevent the disclosure of organizational
information to unauthorized individuals when such media is reused or released for disposal. The organization
uses its discretion on the employment of sanitization techniques and procedures for media containing
information deemed to be in the public domain or publicly releasable, or deemed to have no adverse impact
on the organization or individuals if released for reuse or disposal.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the physical and environmental
protection family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The physical and environmental
protection policy can be included as part of the general information security policy for the organization.
Physical and environmental protection procedures can be developed for the security program in general and
for a particular information system, when required. The organizational risk management strategy is a key factor
in the development of the physical and environmental protection policy. Related control: PM-9.
Authorization credentials include, for example, badges, identification cards, and smart cards. Related control:
PE-3, PE-4.
The organization determines the types of guards needed, for example, professional physical security staf or
other personnel such as administrative staf or information system users, as deemed appropriate. Physical
access devices include, for example, keys, locks, combinations, and card readers. Workstations and associated
peripherals connected to (and part of) an organizational information system may be located in areas
designated as publicly accessible with access to such devices being safeguarded. Related controls: MP-2, MP-4,
PE-2
Physical protections applied to information system distribution and transmission lines help prevent accidental
damage, disruption, and physical tampering. Additionally, physical protections are necessary to help prevent
eavesdropping or in transit modification of unencrypted transmissions. Protective measures to control physical
access to information system distribution and transmission lines include: (i) locked wiring closets; (ii)
disconnected or locked spare jacks; and/or (iii) protection of cabling by conduit or cable trays. Related control:
PE-2.
Monitors, printers, and audio devices are examples of information system output devices.
Investigation of and response to detected physical security incidents, including apparent security violations or
suspicious physical access activities, are part of the organizations incident response capability.
Individuals (to include organizational employees, contract personnel, and others) with permanent
authorization credentials for the facility are not considered visitors.
Visitor access records include, for example, name/organization of the person visiting, signature of the visitor,
form(s) of identification, date of access, time of entry and departure, purpose of visit, and name/organization
of person visited.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
This control applies to facilities containing concentrations of information system resources, for example, data
centers, server rooms, and mainframe computer rooms.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
Fire suppression and detection devices/systems include, for example, sprinkler systems, handheld fire
extinguishers, fixed fire hoses, and smoke detectors. This control, to include any enhancements specified, may
be satisfied by similar requirements fulfilled by another organizational entity other than the information
security program. Organizations avoid duplicating actions already covered.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
This control, to include any enhancements specified, may be satisfied by similar requirements fulfilled by
another organizational entity other than the information security program. Organizations avoid duplicating
actions already covered.
Efectively enforcing authorizations for entry and exit of information system components may require
restricting access to delivery areas and possibly isolating the areas from the information system and media
libraries.
Alternate work sites may include, for example, government facilities or private residences of employees. The
organization may define diferent sets of security controls for specific alternate work sites or types of sites.
Physical and environmental hazards include, for example, flooding, fire, tornados, earthquakes, hurricanes,
acts of terrorism, vandalism, electromagnetic pulse, electrical interference, and electromagnetic radiation.
Whenever possible, the organization also considers the location or site of the facility with regard to physical
and environmental hazards. In addition, the organization considers the location of physical entry points where
unauthorized individuals, while not being granted access, might nonetheless be in close proximity to the
information system and therefore, increase the potential for unauthorized access to organizational
communications (e.g., through the use of wireless snifers or microphones). This control, to include any
enhancements specified, may be satisfied by similar requirements fulfilled by another organizational entity
other than the information security program. Organizations avoid duplicating actions already covered.
The security categorization of the information system (with respect to confidentiality) and organizational
security policy guides the application of safeguards and countermeasures employed to protect the information
system against information leakage due to electromagnetic signals emanations.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the security planning family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The security planning policy addresses the overall
policy requirements for confidentiality, integrity, and availability and can be included as part of the general
information security policy for the organization. Security planning procedures can be developed for the
security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the security planning policy. Related control: PM-9.
The security plan contains sufficient information (including specification of parameters for assignment and
selection statements in security controls either explicitly or by reference) to enable an implementation that is
unambiguously compliant with the intent of the plan and a subsequent determination of risk to organizational
operations and assets, individuals, other organizations, and the Nation if the plan is implemented as intended.
Related controls: PM-1, PM-7, PM-8, PM-9, PM-11.
The organization considers diferent sets of rules based on user roles and responsibilities, for example,
diferentiating between the rules that apply to privileged users and rules that apply to general users. Electronic
signatures are acceptable for use in acknowledging rules of behavior. Related control: PS-6.
None.
Security-related activities include, for example, security assessments, audits, system hardware and software
maintenance, and contingency plan testing/exercises. Organizational advance planning and coordination
includes both emergency and nonemergency (i.e., planned or nonurgent unplanned) situations.
The information security program plan can be represented in a single document or compilation of documents
at the discretion of the organization. The plan documents the organization-wide program management
controls and organization-defined common controls. The security plans for individual information systems and
the organization-wide information security program plan together, provide complete coverage for all security
controls employed within the organization. Common controls are documented in an appendix to the
organizations information security program plan unless the controls are included in a separate security plan for
an information system (e.g., security controls employed as part of an intrusion detection system providing
organization-wide boundary protection inherited by one or more organizational information systems). The
organization-wide information security program plan will indicate which separate security plans contain
descriptions of common controls. Organizations have the flexibility to describe common controls in a single
document or in multiple documents. In the case of multiple documents, the documents describing common
controls are included as attachments to the information security program plan. If the information security
program plan contains multiple documents, the organization specifies in each document the organizational
official or officials responsible for the development, implementation, assessment, authorization, and
monitoring of the respective common controls. For example, the organization may require that the Facilities
Management Office develop, implement, assess, authorize, and continuously monitor common physical and
environmental protection controls from the PE family when such controls are not associated with a particular
information system but instead, support multiple information systems. Related control: PM-8.
The security officer described in this control is an organizational official. For a federal agency (as defined in
applicable federal laws, Executive Orders, directives, policies, or regulations) this official is the Senior Agency
Information Security Officer. Organizations may also refer to this organizational official as the Senior
Information Security Officer or Chief Information Security Officer.
Organizations may designate and empower an Investment Review Board (or similar group) to manage and
provide oversight for the information security-related aspects of the capital planning and investment control
process. Related controls: PM-4, SA-2.
The plan of action and milestones is a key document in the information security program and is subject to
federal reporting requirements established by OMB. The plan of action and milestones updates are based on
the findings from security control assessments, security impact analyses, and continuous monitoring activities.
OMB FISMA reporting guidance contains instructions regarding organizational plans of action and milestones.
Related control: CA-5.
This control addresses the inventory requirements in FISMA. OMB provides guidance on developing
information systems inventories and associated reporting requirements.
Measures of performance are outcome-based metrics used by an organization to measure the efectiveness or
efficiency of the information security program and the security controls employed in support of the program.
The enterprise architecture developed by the organization is aligned with the Federal Enterprise Architecture.
The integration of information security requirements and associated security controls into the organizations
enterprise architecture helps to ensure that security considerations are addressed by organizations early in the
system development life cycle and are directly and explicitly related to the organizations mission/business
processes. This also embeds into the enterprise architecture, an integral security architecture consistent with
organizational risk management and information security strategies. Security requirements and control
integration are most efectively accomplished through the application of the Risk Management Framework and
supporting security standards and guidelines. The Federal Segment Architecture Methodology provides
guidance on integrating information security requirements and security controls into enterprise architectures.
Related controls: PL-2, PM-11, RA-2.
The requirement and guidance for defining critical infrastructure and key resources and for preparing an
associated critical infrastructure protection plan are found in applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Related controls: PM-1, PM-9, PM-11, RA-3.
An organization-wide risk management strategy includes, for example, an unambiguous expression of the risk
tolerance for the organization, acceptable risk assessment methodologies, risk mitigation strategies, a process
for consistently evaluating risk across the organization with respect to the organizations risk tolerance, and
approaches for monitoring risk over time. The use of a risk executive function can facilitate consistent,
organization-wide application of the risk management strategy. The organization-wide risk management
strategy can be informed by risk-related inputs from other sources both internal and external to the
organization to ensure the strategy is both broad-based and comprehensive. Related control: RA-3.
The security authorization process for information systems requires the implementation of the Risk
Management Framework and the employment of associated security standards and guidelines. Specific roles
within the risk management process include a designated authorizing official for each organizational
information system. Related control: CA-6.
Information protection needs are technology-independent, required capabilities to counter threats to
organizations, individuals, or the Nation through the compromise of information (i.e., loss of confidentiality,
integrity, or availability). Information protection needs are derived from the mission/business needs defined
by the organization, the mission/business processes selected to meet the stated needs, and the organizational
risk management strategy. Information protection needs determine the required security controls for the
organization and the associated information systems supporting the mission/business processes. Inherent in
defining an organizations information protection needs is an understanding of the level of adverse impact that
could result if a compromise of information occurs. The security categorization process is used to make such
potential impact determinations. Mission/business process definitions and associated information protection
requirements are documented by the organization in accordance with organizational policy and procedure.
Related controls: PM-7, PM-8, RA-2.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the personnel security family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The personnel security policy can be included as part
of the general information security policy for the organization. Personnel security procedures can be
developed for the security program in general and for a particular information system, when required. The
organizational risk management strategy is a key factor in the development of the personnel security policy.
Related control: PM-9.
Position risk designations are consistent with Office of Personnel Management policy and guidance. The
screening criteria include explicit information security role appointment requirements (e.g., training, security
clearance).
Screening and rescreening are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, guidance, and the criteria established for the risk designation of the assigned position.
The organization may define diferent rescreening conditions and frequencies for personnel accessing the
information system based on the type of information processed, stored, or transmitted by the system.
Information system-related property includes, for example, hardware authentication tokens, system
administration technical manuals, keys, identification cards, and building passes. Exit interviews ensure that
individuals understand any security constraints imposed by being former employees and that proper
accountability is achieved for all information system-related property. Exit interviews may not be possible for
some employees (e.g., in the case of job abandonment, some illnesses, and nonavailability of supervisors). Exit
interviews are important for individuals with security clearances. Timely execution of this control is particularly
essential for employees or contractors terminated for cause.
This control applies when the reassignment or transfer of an employee is permanent or of such an extended
duration as to make the actions warranted. In addition the organization defines the actions appropriate for the
type of reassignment or transfer; whether permanent or temporary. Actions that may be required when
personnel are transferred or reassigned to other positions within the organization include, for example: (i)
returning old and issuing new keys, identification cards, and building passes; (ii) closing previous information
system accounts and establishing new accounts; (iii) changing information system access authorizations; and
(iv) providing for access to official records to which the employee had access at the previous work location and
in the previous information system accounts.
Access agreements include, for example, nondisclosure agreements, acceptable use agreements, rules of
behavior, and conflict-of-interest agreements. Signed access agreements include an acknowledgement that
individuals have read, understand, and agree to abide by the constraints associated with the information
system to which access is authorized. Electronic signatures are acceptable for use in acknowledging access
agreements unless specifically prohibited by organizational policy. Related control: PL-4.
Third-party providers include, for example, service bureaus, contractors, and other organizations providing
information system development, information technology services, outsourced applications, and network and
security management. The organization explicitly includes personnel security requirements in acquisition-
related documents.
The sanctions process is consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. The process is described in access agreements and can be included as
part of the general personnel policies and procedures for the organization. Related controls: PL-4, PS-6.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the risk assessment family. The
policy and procedures are consistent with applicable federal laws, Executive Orders, directives, policies,
regulations, standards, and guidance. Existing organizational policies and procedures may make the need for
additional specific policies and procedures unnecessary. The risk assessment policy can be included as part of
the general information security policy for the organization. Risk assessment procedures can be developed for
the security program in general and for a particular information system, when required. The organizational risk
management strategy is a key factor in the development of the risk assessment policy. Related control: PM-9.
A clearly defined authorization boundary is a prerequisite for an efective security categorization. Security
categorization describes the potential adverse impacts to organizational operations, organizational assets, and
individuals should the information and information system be comprised through a loss of confidentiality,
integrity, or availability. The organization conducts the security categorization process as an organization-wide
activity with the involvement of the chief information officer, senior information security officer, information
system owner, mission owners, and information owners/stewards. The organization also considers potential
adverse impacts to other organizations and, in accordance with the USA PATRIOT Act of 2001 and Homeland
Security Presidential Directives, potential national-level adverse impacts in categorizing the information
system. The security categorization process facilitates the creation of an inventory of information assets, and in
conjunction with CM-8, a mapping to the information system components where the information is processed,
stored, and transmitted. Related controls: CM-8, MP-4, SC-7.
A clearly defined authorization boundary is a prerequisite for an efective risk assessment. Risk assessments
take into account vulnerabilities, threat sources, and security controls planned or in place to determine the
level of residual risk posed to organizational operations and assets, individuals, other organizations, and the
Nation based on the operation of the information system. Risk assessments also take into account risk posed
to organizational operations, organizational assets, or individuals from external parties (e.g., service providers,
contractors operating information systems on behalf of the organization, individuals accessing organizational
information systems, outsourcing entities). In accordance with OMB policy and related E-authentication
initiatives, authentication of public users accessing federal information systems may also be required to
protect nonpublic or privacy-related information. As such, organizational assessments of risk also address
public access to federal information systems. The General Services Administration provides tools supporting
that portion of the risk assessment dealing with public access to federal information systems. Risk assessments
(either formal or informal) can be conducted by organizations at various steps in the Risk Management
Framework including: information system categorization; security control selection; security control
implementation; security control assessment; information system authorization; and security control
monitoring. RA-3 is a noteworthy security control in that the control must be partially implemented prior to
the implementation of other controls in order to complete the first two steps in the Risk Management
Framework. Risk assessments can play an important role in the security control selection process during the
application of tailoring guidance for security control baselines and when considering supplementing the
tailored baselines with additional security controls or control enhancements.
The security categorization of the information system guides the frequency and comprehensiveness of the
vulnerability scans. Vulnerability analysis for custom software and applications may require additional, more
specialized techniques and approaches (e.g., web-based application scanners, source code reviews, source
code analyzers). Vulnerability scanning includes scanning for specific functions, ports, protocols, and services
that should not be accessible to users or devices and for improperly configured or incorrectly operating
information flow mechanisms. The organization considers using tools that express vulnerabilities in the
Common Vulnerabilities and Exposures (CVE) naming convention and that use the Open Vulnerability
Assessment Language (OVAL) to test for the presence of vulnerabilities. The Common Weakness Enumeration
(CWE) and the National Vulnerability Database (NVD) are also excellent sources for vulnerability information.
In addition, security control assessments such as red team exercises are another source of potential
vulnerabilities for which to scan. Related controls: CA-2, CM-6, RA-3, SI-2.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the system and services acquisition
family. The policy and procedures are consistent with applicable federal laws, Executive Orders, directives,
policies, regulations, standards, and guidance. Existing organizational policies and procedures may make the
need for additional specific policies and procedures unnecessary. The system and services acquisition policy
can be included as part of the general information security policy for the organization. System and services
acquisition procedures can be developed for the security program in general and for a particular information
system, when required. The organizational risk management strategy is a key factor in the development of the
system and services acquisition policy. Related control: PM-9.
The inability of the organization to obtain necessary information system documentation may occur, for
example, due to the age of the system and/or lack of support from the vendor/contractor. In those situations,
organizations may need to recreate selected information system documentation if such documentation is
essential to the efective implementation and/or operation of security controls.
Tracking systems can include, for example, simple spreadsheets or fully automated, specialized applications
depending on the needs of the organization.
If provided the necessary privileges, users have the ability to install software. The organization identifies what
types of software installations are permitted (e.g., updates and security patches to existing software) and what
types of installations are prohibited (e.g., software whose pedigree with regard to being potentially malicious
is unknown or suspect). Related control: CM-2.
The application of security engineering principles is primarily targeted at new development information
systems or systems undergoing major upgrades and is integrated into the system development life cycle. For
legacy information systems, the organization applies security engineering principles to system upgrades and
modifications to the extent feasible, given the current state of the hardware, software, and firmware within
the system. Examples of security engineering principles include, for example: (i) developing layered
protections; (ii) establishing sound security policy, architecture, and controls as the foundation for design; (iii)
incorporating security into the system development life cycle; (iv) delineating physical and logical security
boundaries; (v) ensuring system developers and integrators are trained on how to develop secure software; (vi)
tailoring security controls to meet organizational and operational needs; and (vii) reducing risk to acceptable
levels, thus enabling informed risk management decisions.
An external information system service is a service that is implemented outside of the authorization boundary
of the organizational information system (i.e., a service that is used by, but not a part of, the organizational
information system). Relationships with external service providers are established in a variety of ways, for
example, through joint ventures, business partnerships, outsourcing arrangements (i.e., contracts, interagency
agreements, lines of business arrangements), licensing agreements, and/or supply chain exchanges. The
responsibility for adequately mitigating risks arising from the use of external information system services
remains with the authorizing official. Authorizing officials require that an appropriate chain of trust be
established with external service providers when dealing with the many issues associated with information
security. For services external to the organization, a chain of trust requires that the organization establish and
retain a level of confidence that each participating provider in the potentially complex consumer-provider
relationship provides adequate protection for the services rendered to the organization. The extent and nature
of this chain of trust varies based on the relationship between the organization and the external provider.
Where a sufficient level of trust cannot be established in the external services and/or service providers, the
organization employs compensating security controls or accepts the greater degree of risk. The external
information system services documentation includes government, service provider, and end user security roles
and responsibilities, and any service-level agreements. Service-level agreements define the expectations of
performance for each required security control, describe measurable outcomes, and identify remedies and
response requirements for any identified instance of noncompliance.
A defense-in-breadth approach helps to protect information systems (including the information technology
products that compose those systems) throughout the system development life cycle (i.e., during design and
development, manufacturing, packaging, assembly, distribution, system integration, operations, maintenance,
and retirement). This is accomplished by the identification, management, and elimination of vulnerabilities at
each phase of the life cycle and the use of complementary, mutually reinforcing strategies to mitigate risk.
The intent of this control is to ensure that organizations recognize the importance of trustworthiness and
making explicit trustworthiness decisions when designing, developing, and implementing organizational
information systems. Trustworthiness is a characteristic or property of an information system that expresses
the degree to which the system can be expected to preserve the confidentiality, integrity, and availability of
the information being processed, stored, or transmitted by the system. Trustworthy information systems are
systems that are capable of being trusted to operate within defined levels of risk despite the environmental
disruptions, human errors, and purposeful attacks that are expected to occur in the specified environments of
operation. Two factors afecting the trustworthiness of an information system include: (i) security functionality
(i.e., the security features or functions employed within the system); and (ii) security assurance (i.e., the
grounds for confidence that the security functionality is efective in its application). Appropriate security
functionality for the information system can be obtained by using the Risk Management Framework (Steps 1,
2, and 3) to select and implement the necessary management, operational, and technical security controls
necessary to mitigate risk to organizational operations and assets, individuals, other organizations, and the
Nation. Appropriate security assurance can be obtained by: (i) the actions taken by developers and
implementers of security controls with regard to the design, development, implementation, and operation of
those controls; and (ii) the actions taken by assessors to determine the extent to which the controls are
implemented correctly, operating as intended, and producing the desired outcome with respect to meeting
the security requirements for the information system. Developers and implementers can increase the
assurance in security controls by employing well-defined security policy models, structured, disciplined, and
rigorous hardware and software development techniques, and sound system/security engineering principles.
Assurance is also based on the assessment of evidence produced during the initiation,
acquisition/development, implementation, and operations/maintenance phases of the system development
life cycle. For example, developmental evidence may include the techniques and methods used to design and
develop security functionality. Operational evidence may include flaw reporting and remediation, the results
of security incident reporting, and the results of the ongoing monitoring of security controls. Independent
assessments by qualified assessors may include analyses of the evidence as well as testing, inspections, and
audits. Minimum assurance requirements are described in Appendix E. Explicit trustworthiness decisions
highlight situations where achieving the information system resilience and security capability necessary to
withstand cyber attacks from adversaries with certain threat capabilities may require adjusting the risk
management strategy, the design of mission/business processes with regard to automation, the selection and
implementation rigor of management and operational protections, or the selection of information technology
components with higher levels of trustworthiness. Trustworthiness may be defined on a component-by-
component, subsystem-by-subsystem, or function-by-function basis. It is noted, however, that typically
functions, subsystems, and components are highly interrelated, making separation by trustworthiness perhaps
The underlying assumption is that the list of information technology products defined by the organization
cannot be trusted due to threats from the supply chain that the organization finds unacceptable. The
organization re-implements or custom develops such components to satisfy requirements for high assurance.
Related controls: SA-12, SA-13.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the system and communications
protection family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The system and communications
protection policy can be included as part of the general information security policy for the organization.
System and communications protection procedures can be developed for the security program in general and
for a particular information system, when required. The organizational risk management strategy is a key factor
in the development of the system and communications protection policy. Related control: PM-9.
Information system management functionality includes, for example, functions necessary to administer
databases, network components, workstations, or servers, and typically requires privileged user access. The
separation of user functionality from information system management functionality is either physical or logical
and is accomplished by using diferent computers, diferent central processing units, diferent instances of the
operating system, diferent network addresses, combinations of these methods, or other methods as
appropriate. An example of this type of separation is observed in web administrative interfaces that use
separate authentication methods for users of any other information system resources. This may include
isolating the administrative interface on a diferent domain and with additional access controls.
The information system isolates security functions from nonsecurity functions by means of an isolation
boundary (implemented via partitions and domains) that controls access to and protects the integrity of, the
hardware, software, and firmware that perform those security functions. The information system maintains a
separate execution domain (e.g., address space) for each executing process. Related control: SA-13.
The purpose of this control is to prevent information, including encrypted representations of information,
produced by the actions of a prior user/role (or the actions of a process acting on behalf of a prior user/role)
from being available to any current user/role (or current process) that obtains access to a shared system
resource (e.g., registers, main memory, secondary storage) after that resource has been released back to the
information system. Control of information in shared resources is also referred to as object reuse. This control
does not address: (i) information remanence which refers to residual representation of data that has been in
some way nominally erased or removed; (ii) covert channels where shared resources are manipulated to
achieve a violation of information flow restrictions; or (iii) components in the information system for which
there is only a single user/role.
A variety of technologies exist to limit, or in some cases, eliminate the efects of denial of service attacks. For
example, boundary protection devices can filter certain types of packets to protect devices on an organizations
internal network from being directly afected by denial of service attacks. Employing increased capacity and
bandwidth combined with service redundancy may reduce the susceptibility to some denial of service attacks.
Related control: SC-7.
Priority protection helps prevent a lower-priority process from delaying or interfering with the information
system servicing any higher-priority process. This control does not apply to components in the information
system for which there is only a single user/role.
Restricting external web traffic only to organizational web servers within managed interfaces and prohibiting
external traffic that appears to be spoofing an internal address as the source are examples of restricting and
prohibiting communications. Managed interfaces employing boundary protection devices include, for
example, proxies, gateways, routers, firewalls, guards, or encrypted tunnels arranged in an efective security
architecture (e.g., routers protecting firewalls and application gateways residing on a protected subnetwork
commonly referred to as a demilitarized zone or DMZ). The organization considers the intrinsically shared
nature of commercial telecommunications services in the implementation of security controls associated with
the use of such services. Commercial telecommunications services are commonly based on network
components and consolidated management systems shared by all attached commercial customers, and may
include third-party provided access lines and other service elements. Consequently, such interconnecting
transmission services may represent sources of increased risk despite contract security provisions. Therefore,
when this situation occurs, the organization either implements appropriate compensating security controls or
explicitly accepts the additional risk. Related controls: AC-4, IR-4, SC-5.
This control applies to communications across internal and external networks. If the organization is relying on
a commercial service provider for transmission services as a commodity item rather than a fully dedicated
service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed
security controls for transmission integrity. When it is infeasible or impractical to obtain the necessary security
controls and assurances of control efectiveness through appropriate contracting vehicles, the organization
either implements appropriate compensating security controls or explicitly accepts the additional risk. Related
controls: AC-17, PE-4.
This control applies to communications across internal and external networks. If the organization is relying on
a commercial service provider for transmission services as a commodity item rather than a fully dedicated
service, it may be more difficult to obtain the necessary assurances regarding the implementation of needed
security controls for transmission confidentiality. When it is infeasible or impractical to obtain the necessary
security controls and assurances of control efectiveness through appropriate contracting vehicles, the
organization either implements appropriate compensating security controls or explicitly accepts the additional
risk. Related controls: AC-17, PE-4.
This control applies to both internal and external networks. Terminating network connections associated with
communications sessions include, for example, de-allocating associated TCP/IP address/port pairs at the
operating-system level, or de-allocating networking assignments at the application level if multiple application
sessions are using a single, operating system-level network connection. The time period of inactivity may, as
the organization deems necessary, be a set of time periods by type of network access or for specific accesses.
A trusted path is employed for high-confidence connections between the security functions of the information
system and the user (e.g., for login).
Cryptographic key management and establishment can be performed using manual procedures or automated
mechanisms with supporting manual procedures. In addition to being required for the efective operation of a
cryptographic mechanism, efective cryptographic key management provides protections to maintain the
availability of the information in the event of the loss of cryptographic keys by users.
None.
The purpose of this control is to ensure that organizations explicitly address the protection needs for public
information and applications with such protection likely being implemented as part of other security controls.
Collaborative computing devices include, for example, networked white boards, cameras, and microphones.
Explicit indication of use includes, for example, signals to users when collaborative computing devices are
activated
Security attributes may be explicitly or implicitly associated with the information contained within the
information system. Related control: AC-16.
For user certificates, each organization attains certificates from an approved, shared service provider, as
required by OMB policy. For federal agencies operating a legacy public key infrastructure cross-certified with
the Federal Bridge Certification Authority at medium assurance or higher, this Certification Authority will
suffice. This control focuses on certificates with a visibility external to the information system and does not
include certificates related to internal system operations, for example, application-specific time services.
Decisions regarding the employment of mobile code within organizational information systems are based on
the potential for the code to cause damage to the system if used maliciously. Mobile code technologies
include, for example, Java, JavaScript, ActiveX, PDF, Postscript, Shockwave movies, Flash animations, and
VBScript. Usage restrictions and implementation guidance apply to both the selection and use of mobile code
installed on organizational servers and mobile code downloaded and executed on individual workstations.
Policy and procedures related to mobile code, address preventing the development, acquisition, or
introduction of unacceptable mobile code within the information system.
None.
This control enables remote clients to obtain origin authentication and integrity verification assurances for the
host/service name to network address resolution information obtained through the service. A domain name
system (DNS) server is an example of an information system that provides name/address resolution service.
Digital signatures and cryptographic keys are examples of additional artifacts. DNS resource records are
examples of authoritative data. Information systems that use technologies other than the DNS to map
between host/service names and network addresses provide other means to assure the authenticity and
integrity of response data. The DNS security controls are consistent with, and referenced from, OMB
Memorandum 08-23.
A recursive resolving or caching domain name system (DNS) server is an example of an information system that
provides name/address resolution service for local clients. Authoritative DNS servers are examples of
authoritative sources. Information systems that use technologies other than the DNS to map between
host/service names and network addresses provide other means to enable clients to verify the authenticity
and integrity of response data.
A domain name system (DNS) server is an example of an information system that provides name/address
resolution service. To eliminate single points of failure and to enhance redundancy, there are typically at least
two authoritative domain name system (DNS) servers, one configured as primary and the other as secondary.
Additionally, the two servers are commonly located in two diferent network subnets and geographically
separated (i.e., not located in the same physical facility). With regard to role separation, DNS servers with an
internal role, only process name/address resolution requests from within the organization (i.e., internal
clients). DNS servers with an external role only process name/address resolution information requests from
clients external to the organization (i.e., on the external networks including the Internet). The set of clients
that can access an authoritative DNS server in a particular role is specified by the organization (e.g., by address
ranges, explicit lists).
This control focuses on communications protection at the session, versus packet, level. The intent of this
control is to establish grounds for confidence at each end of a communications session in the ongoing identity
of the other party and in the validity of the information being transmitted. For example, this control addresses
man-in-the-middle attacks including session hijacking or insertion of false information into a session. This
control is only implemented where deemed necessary by the organization (e.g., sessions in service-oriented
architectures providing web-based services).
Failure in a known state can address safety or security in accordance with the mission/business needs of the
organization. Failure in a known secure state helps prevent a loss of confidentiality, integrity, or availability in
the event of a failure of the information system or a component of the system. Failure in a known safe state
helps prevent systems from failing to a state that may cause injury to individuals or destruction to property.
Preserving information system state information facilitates system restart and return to the operational mode
of the organization with less disruption of mission/business processes.
The deployment of information system components with minimal functionality (e.g., diskless nodes and thin
client technologies) reduces the need to secure every user endpoint, and may reduce the exposure of
information, information systems, and services to a successful attack. Related control: SC-30.
None.
Operating system-independent applications are applications that can run on multiple operating systems. Such
applications promote portability and reconstitution on diferent platform architectures, increasing the
availability for critical functionality within an organization while information systems with a given operating
system are under attack.
This control is intended to address the confidentiality and integrity of information at rest in nonmobile devices
and covers user information and system information. Information at rest refers to the state of information
when it is located on a secondary storage device (e.g., disk drive, tape drive) within an organizational
information system. Configurations and/or rule sets for firewalls, gateways, intrusion detection/prevention
systems, and filtering routers and authenticator content are examples of system information likely requiring
protection. Organizations may choose to employ diferent mechanisms to achieve confidentiality and integrity
protections, as appropriate.
Increasing the diversity of information technologies within the information system reduces the impact of the
exploitation of a specific technology. Organizations that select this control should consider that an increase in
diversity may add complexity and management overhead, both of which have the potential to lead to mistakes
and misconfigurations which could increase overall risk.
Virtualization techniques provide organizations with the ability to disguise information systems, potentially
reducing the likelihood of successful attacks without the cost of having multiple platforms.
Information system developers/integrators are in the best position to identify potential avenues within the
system that might lead to covert channels. Covert channel analysis is a meaningful activity when there is the
potential for unauthorized information flows across security domains, for example, in the case of information
systems containing export-controlled information and having connections to external networks (i.e., networks
not controlled by the organization). Covert channel analysis is also meaningful in the case of multilevel secure
(MLS) systems, multiple security level (MSL) systems, and cross domain systems.
In this control, the term operating environment is defined as the code upon which applications are hosted, for
example, a monitor, executive, operating system, or application running directly on the hardware platform.
Hardware-enforced, read-only media include, for example, CD-R/DVD-R disk drives. Use of non-modifiable
storage ensures the integrity of the software program from the point of creation of the read-only image.
This control is intended to produce the policy and procedures that are required for the efective
implementation of selected security controls and control enhancements in the system and information
integrity family. The policy and procedures are consistent with applicable federal laws, Executive Orders,
directives, policies, regulations, standards, and guidance. Existing organizational policies and procedures may
make the need for additional specific policies and procedures unnecessary. The system and information
integrity policy can be included as part of the general information security policy for the organization. System
and information integrity procedures can be developed for the security program in general and for a particular
information system, when required. The organizational risk management strategy is a key factor in the
development of the system and information integrity policy. Related control: PM-9.
The organization identifies information systems containing software afected by recently announced software
flaws (and potential vulnerabilities resulting from those flaws) and reports this information to designated
organizational officials with information security responsibilities (e.g., senior information security officers,
information system security managers, information systems security officers). The organization (including any
contractor to the organization) promptly installs security-relevant software updates (e.g., patches, service
packs, and hot fixes). Flaws discovered during security assessments, continuous monitoring, incident response
activities, or information system error handling, are also addressed expeditiously. Organizations are
encouraged to use resources such as the Common Weakness Enumeration (CWE) or Common Vulnerabilities
and Exposures (CVE) databases in remediating flaws discovered in organizational information systems. By
requiring that flaw remediation be incorporated into the organizational configuration management process, it
is the intent of this control that required/anticipated remediation actions are tracked and verified. An example
of expected flaw remediation that would be so verified is whether the procedures contained in US-CERT
guidance and Information Assurance Vulnerability Alerts have been accomplished. Related controls: CA-2, CA-
7, CM-3, MA-2, IR-4, RA-5, SA-11, SI-11.
Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers,
proxy servers, and remote-access servers. Malicious code includes, for example, viruses, worms, Trojan horses,
and spyware. Malicious code can also be encoded in various formats (e.g., UUENCODE, Unicode) or contained
within a compressed file. Removable media includes, for example, USB devices, diskettes, or compact disks. A
variety of technologies and methods exist to limit or eliminate the efects of malicious code attacks. Pervasive
configuration management and strong software integrity controls may be efective in preventing execution of
unauthorized code. In addition to commercial of-the-shelf software, malicious code may also be present in
custom-built software. This could include, for example, logic bombs, back doors, and other types of cyber
attacks that could afect organizational missions and business functions. Traditional malicious code protection
mechanisms are not built to detect such code. In these situations, organizations must rely instead on other risk
mitigation measures to include, for example, secure coding practices, trusted procurement processes,
configuration management and control, and monitoring practices to help ensure that software does not
perform functions other than those intended. Related controls: SA-4, SA-8, SA-12, SA-13, SI-4, SI-7.
Information system monitoring includes external and internal monitoring. External monitoring includes the
observation of events occurring at the system boundary (i.e., part of perimeter defense and boundary
protection). Internal monitoring includes the observation of events occurring within the system (e.g., within
internal organizational networks and system components). Information system monitoring capability is
achieved through a variety of tools and techniques (e.g., intrusion detection systems, intrusion prevention
systems, malicious code protection software, audit record monitoring software, network monitoring software).
Strategic locations for monitoring devices include, for example, at selected perimeter locations and near server
farms supporting critical applications, with such devices typically being employed at the managed interfaces
associated with controls SC-7 and AC-17. The Einstein network monitoring device from the Department of
Homeland Security is an example of a system monitoring device. The granularity of the information collected is
determined by the organization based on its monitoring objectives and the capability of the information
system to support such activities. An example of a specific type of transaction of interest to the organization
with regard to monitoring is Hyper Text Transfer Protocol (HTTP) traffic that bypasses organizational HTTP
proxies, when use of such proxies is required. Related controls: AC-4, AC-8, AC-17, AU-2, AU-6, SI-3, SI-7.
Security alerts and advisories are generated by the United States Computer Emergency Readiness Team (US-
CERT) to maintain situational awareness across the federal government. Security directives are issued by OMB
or other designated organizations with the responsibility and authority to issue such directives. Compliance to
security directives is essential due to the critical nature of many of these directives and the potential
immediate adverse afects on organizational operations and assets, individuals, other organizations, and the
Nation should the directives not be implemented in a timely manner.
The need to verify security functionality applies to all security functions. For those security functions that are
not able to execute automated self-tests, the organization either implements compensating security controls
or explicitly accepts the risk of not performing the verification as required. Information system transitional
states include, for example, startup, restart, shutdown, and abort.
The organization employs integrity verification applications on the information system to look for evidence of
information tampering, errors, and omissions. The organization employs good software engineering practices
with regard to commercial of-the-shelf integrity mechanisms (e.g., parity checks, cyclical redundancy checks,
cryptographic hashes) and uses tools to automatically monitor the integrity of the information system and the
applications it hosts.
Information system entry and exit points include, for example, firewalls, electronic mail servers, web servers,
proxy servers, and remote-access servers. Related controls: SC-5, SI-3.
Restrictions on organizational personnel authorized to input information to the information system may extend
beyond the typical access controls employed by the system and include limitations based on specific
operational/project responsibilities. Related controls: AC-5, AC-6.
Rules for checking the valid syntax and semantics of information system inputs (e.g., character set, length,
numerical range, acceptable values) are in place to verify that inputs match specified definitions for format
and content. Inputs passed to interpreters are prescreened to prevent the content from being unintentionally
interpreted as commands.
The structure and content of error messages are carefully considered by the organization. The extent to which
the information system is able to identify and handle error conditions is guided by organizational policy and
operational requirements. Sensitive information includes, for example, account numbers, social security
numbers, and credit card numbers.
The output handling and retention requirements cover the full life cycle of the information, in some cases
extending beyond the disposal of the information system. The National Archives and Records Administration
provides guidance on records retention. Related controls: MP-2, MP-4.
While mean time to failure is primarily a reliability issue, this control focuses on the potential failure of specific
components of the information system that provide security capability. Mean time to failure rates are
defendable and based on considerations that are installation-specific, not industry-average. The transfer of
responsibilities between active and standby information system components does not compromise safety,
operational readiness, or security (e.g., state variables are preserved). The standby component is available at
all times except where a failure recovery is in progress or for maintenance reasons. Related control: CP-2.
Testing
Procedures
Control Exists
Yes or No
Evidence of Control
Control is Executed Correctly Control Output
Comments Artifact
Function Category
IDENTIFY (ID)
PROTECT (PR)
RESPOND (RS)
Communications (RS.CO): Response activities are coordinated with
internal and external stakeholders, as appropriate, to include external
support from law enforcement agencies.
RESPOND (RS)
Analysis (RS.AN): Analysis is conducted to ensure adequate response
and support recovery activities.
ID.AM-1: Physical devices and systems within the organization are inventoried
ID.AM-6: Cybersecurity roles and responsibilities for the entire workforce and third-
party stakeholders (e.g., suppliers, customers, partners) are established
ID.BE-1: The organization’s role in the supply chain is identified and communicated
ID.BE-2: The organization’s place in critical infrastructure and its industry sector is
identified and communicated
ID.BE-4: Dependencies and critical functions for delivery of critical services are
established
ID.BE-5: Resilience requirements to support delivery of critical services are
established
ID.GV-1: Organizational information security policy is established
ID.GV-2: Information security roles & responsibilities are coordinated and aligned
with internal roles and external partners
PR.AC-1: Identities and credentials are managed for authorized devices and users
PR.AC-2: Physical access to assets is managed and protected
PR.AC-3: Remote access is managed
PR.AC-4: Access permissions are managed, incorporating the principles of least
privilege and separation of duties
PR.IP-5: Policy and regulations regarding the physical operating environment for
organizational assets are met
PR.IP-6: Data is destroyed according to policy
PR.IP-9: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
PR.IP-10: Response plans (Incident Response and Business Continuity) and recovery
plans (Incident Recovery and Disaster Recovery) are in place and managed
DE.AE-2: Detected events are analyzed to understand attack targets and methods
DE.AE-3: Event data are aggregated and correlated from multiple sources and sensors
(B) Risk management (Required). Implement security measures sufficient to reduce risks and
vulnerabilities to a reasonable and appropriate level to comply with § 164.306(a).
(C) Sanction policy (Required). Apply appropriate sanctions against workforce members who fail to
comply with the security policies and procedures of the covered entity.
(D) Information system activity review. Implement procedures to regularly review records of
information system activity, such as audit logs, access reports, and security incident tracking
reports.
164.308 (a)(2) Standard: Assigned Security Responsibility
Identify the security official who is responsible for the development and implementation of the
policies and procedures required by this subpart for the entity.
(D) Testing and revision procedures (Addressable). Implement procedures for periodic testing and
revision of contingency plans.
(E) Applications and data criticality analysis (Addressable). Assess the relative criticality of specific
applications and data in support of other contingency plan components.
164.308 (a)(8) Standard: Evaluation
Perform a periodic technical and nontechnical evaluation, based initially upon the standards
implemented under this rule and subsequently, in response to environmental or operational
changes afecting the security of electronic protected health information that establishes the
extent to which an entity’s security policies and procedures meet the requirements of this subpart.
164.308 (b)(2) This standard does not apply with respect to—
(i) The transmission by a covered entity of electronic protected health information to a health care
provider concerning the treatment of an individual.
(ii) The transmission of electronic protected health information by a group health plan or an HMO
or health insurance issuer on behalf of a group health plan to a plan sponsor, to the extent that the
requirements of § 164.314(b) and § 164.504(f) apply and are met; or
(iii) The transmission of electronic protected health information from or to other agencies
providing the services at § 164.502(e)(1)(ii)(C), when the covered entity is a health plan that is
public benefits, if the requirements of § 164.502(e)(1)(ii)(C) are met.
164.310 (a)(2)(ii)
Facility security plan (Addressable). Implement policies and procedures to safeguard the facility
and the equipment therein from unauthorized physical access, tampering, and theft.
164.310 (a)(2)(iii)
Access control and validation procedures (Addressable). Implement procedures to control and
validate a person’s access to facilities based on their role or function, including visitor control, and
control of access to software programs for testing and revision.
164.310 (a)(2)(iv)
Maintenance records (Addressable). Implement policies and procedures to document repairs and
modifications to the physical components of a facility which are related to security (for example,
hardware, walls, doors, and locks).
164.310 (d)2)(ii)
Media re-use (Required). Implement procedures for removal of electronic protected health
information from electronic media before the media are made available for re-use.
164.310 (d)(2)(iii)
Accountability (Addressable). Maintain a record of the movements of hardware and electronic
media and any person responsible therefore.
164.310 (d)(2)(iv)
Data backup and storage (Addressable). Create a retrievable, exact copy of electronic protected
health information, when needed, before movement of equipment.
45 CFR 164.312 Technical safeguards.
164.312 (a)(1) Standard: Access Control
Implement technical policies and procedures for electronic information systems that maintain
electronic protected health information to allow access only to those persons or software
programs that have been granted access rights as specified in § 164.308(a)(4).
164.312 (a)(2)(iii)
Automatic logof (Addressable). Implement electronic procedures that terminate an electronic
session after a predetermined time of inactivity.
164.312 (a)(2)(iv)
Encryption and decryption (Addressable). Implement a mechanism to encrypt and decrypt
electronic protected health information.
164-312 (b) Standard: Audit Controls
Implement hardware, software, and/or procedural mechanisms that record and examine activity in
information systems that contain or use electronic protected health information.
164.312 (c)(1) Standard: Integrity
Implement policies and procedures to protect electronic protected health information from
improper alteration or destruction.
164.312 (c)(2) Implementation Specification
Mechanism to authenticate electronic protected health information (Addressable). Implement
electronic mechanisms to corroborate that electronic protected health information has not been
altered or destroyed in an unauthorized manner.
Well documented policies and procedures provide a baseline for governance, risk, and compliance
processes that ultimately ensure that data and the systems that house it are secure. Policies are
adhered to in accordance to established mandates and controls.
Once documented, unless modified by contractual agreements, policies and procedures are
reviewed annually at a minimum. Typically, these documents are updated due to changes such as
environment updates/upgrades, government mandates etc.
As a service provider, we acknowledge to internal and external customers that we are responsible
for security of electronic access to health data and to remain in compliance with privacy
regulations set by HHS.
Detection of security violations is a key requirement to be implemented and observed in a cyber
security environment. Not only detection systems must be in place to monitor anomalies or
suspicious activity, but tracking and identification of abnormal activities should be reported with
the end goal of remediation and eventually preventing future compromising activities.
Documented procedures should include information that is relevant to monitoring and reporting
incidents. Systems should alert personnel of suspicious activity while logging/tracking those
activities for further review by security personnel. Audit trails must have a minimum set of
identifiable data for each event such as user, event type, date and time of occurrance, success or
failure indicator, event origination, name of of afected data, system component, or resource.
Documented policies and procedures must address the implementation of additional security
features for any system component deemed insecure. In addition, these policies and procedures
must address the governance of personnel and locations where protected health information is
accessible.
Personnel access to protected health information must be approved and authorized to access
system components based on a user's need to know. This leads to assignment of privileges to
individuals based on job classification and function resulting in user-authentication management
that validates access to protected health information.
PCI DSS 3.2 Control
PCI REFERENCE
12.6 12.6 Implement a formal security awareness program to make all personnel
aware of the importance of cardholder data security policy and procedures.
12.9 12.9 Additional requirement for service providers only: Service providers
acknowledge in writing to customers that they are responsible for the security
of cardholder data the service provider possesses or otherwise stores,
processes, or transmits on behalf of the customer, or to the extent that they
could impact the security of the customer’s cardholder data environment.
Note: This requirement is a best practice until June 30, 2015, after which it
becomes a requirement.
12.9.1 #N/A
12.9.2 #N/A
12.9.3 #N/A
12.9.4 #N/A
#N/A
10.6 10.6 Review logs and security events for all system components to identify
anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this
Requirement.
11.5 11.5 Deploy a change-detection mechanism (for example, file-integrity
monitoring tools) to alert personnel to unauthorized modification (including
changes, additions, and deletions) of critical system files, configuration files, or
content files; and configure the software to perform critical file comparisons
at least weekly.
Note: For change-detection purposes, critical files are usually those that do
not regularly change, but the modification of which could indicate a system
compromise or risk of compromise. Change-detection mechanisms such as
file-integrity monitoring products usually come pre-configured with critical
files for the related operating system. Other critical files, such as those for
custom applications, must be evaluated and defined by the entity (that is, the
merchant or service provider).
#N/A
2.2.3 2.2.3 Implement additional security features for any required services,
protocols, or daemons that are considered to be insecure.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
8.5.1 8.5.1 Additional requirement for service providers only: Service providers with
remote access to customer premises (for example, for support of POS systems
or servers) must use a unique authentication credential (such as a
password/phrase) for each customer.
8.5.16 #N/A
10.2.7 10.2.7 Creation and deletion of system- level objects
10.3 10.3 Record at least the following audit trail entries for all system components
for each event:
10.3.1 10.3.1 User identification
10.3.2 10.3.2 Type of event
10.3.3 10.3.3 Date and time
10.3.4 10.3.4 Success or failure indication
10.3.5 10.3.5 Origination of event
10.3.6 10.3.6 Identity or name of afected data, system component, or resource.
10.6 10.6 Review logs and security events for all system components to identify
anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this
Requirement.
Note: For change-detection purposes, critical files are usually those that do
not regularly change, but the modification of which could indicate a system
compromise or risk of compromise. Change-detection mechanisms such as
file-integrity monitoring products usually come pre-configured with critical
files for the related operating system. Other critical files, such as those for
custom applications, must be evaluated and defined by the entity (that is, the
merchant or service provider).
#N/A
8.5.16 #N/A
#N/A
2.2.3 2.2.3 Implement additional security features for any required services,
protocols, or daemons that are considered to be insecure.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
6.6 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:
2.2.3 2.2.3 Implement additional security features for any required services,
protocols, or daemons that are considered to be insecure.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
8.5.1 8.5.1 Additional requirement for service providers only: Service providers with
remote access to customer premises (for example, for support of POS systems
or servers) must use a unique authentication credential (such as a
password/phrase) for each customer.
8.5.16 #N/A
8.2 8.2 In addition to assigning a unique ID, ensure proper user-authentication
management for non-consumer users and administrators on all system
components by employing at least one of the following methods to
authenticate all users:
8.5.1 8.5.1 Additional requirement for service providers only: Service providers with
remote access to customer premises (for example, for support of POS systems
or servers) must use a unique authentication credential (such as a
password/phrase) for each customer.
8.5.16 #N/A
#N/A
#N/A
5.1 5.1 Deploy anti-virus software on all systems commonly afected by malicious
software (particularly personal computers and servers).
5.1.1 5.1.1 Ensure that anti-virus programs are capable of detecting, removing, and
protecting against all known types of malicious software.
5.2 5.2 Ensure that all anti-virus mechanisms are maintained as follows:
10.1 10.1 Implement audit trails to link all access to system components to each
individual user.
10.2 10.2 Implement automated audit trails for all system components to
reconstruct the following events:
10.2.1 10.2.1 All individual user accesses to cardholder data
10.2.5 #N/A
10.2.7 10.2.7 Creation and deletion of system- level objects
10.3 10.3 Record at least the following audit trail entries for all system components
for each event:
10.3.1 10.3.1 User identification
10.3.2 10.3.2 Type of event
10.3.3 10.3.3 Date and time
10.3.4 10.3.4 Success or failure indication
10.3.5 10.3.5 Origination of event
10.3.6 10.3.6 Identity or name of afected data, system component, or resource.
10.5.4 10.5.4 Write logs for external-facing technologies onto a secure, centralized,
internal log server or media device.
10.6 10.6 Review logs and security events for all system components to identify
anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this
Requirement.
Note: For change-detection purposes, critical files are usually those that do
not regularly change, but the modification of which could indicate a system
compromise or risk of compromise. Change-detection mechanisms such as
file-integrity monitoring products usually come pre-configured with critical
files for the related operating system. Other critical files, such as those for
custom applications, must be evaluated and defined by the entity (that is, the
merchant or service provider).
8.5 8.5 Do not use group, shared, or generic IDs, passwords, or other
authentication methods as follows:
8.5.10 #N/A
8.5.11 #N/A
8.5.12 #N/A
8.5.13 #N/A
8.5.14 #N/A
8.5.2 #N/A
8.5.3 #N/A
8.5.7 #N/A
8.5.8 #N/A
8.5.9 #N/A
#N/A
12.6 12.6 Implement a formal security awareness program to make all personnel
aware of the importance of cardholder data security policy and procedures.
12.9 12.9 Additional requirement for service providers only: Service providers
acknowledge in writing to customers that they are responsible for the security
of cardholder data the service provider possesses or otherwise stores,
processes, or transmits on behalf of the customer, or to the extent that they
could impact the security of the customer’s cardholder data environment.
Note: This requirement is a best practice until June 30, 2015, after which it
becomes a requirement.
12.9.1 #N/A
12.9.2 #N/A
12.9.3 #N/A
12.9.4 #N/A
12.9.6 #N/A
9.1.1 9.1.1 Use video cameras and/or access control mechanisms to monitor
individual physical access to sensitive areas. Review collected data and
correlate with other entries. Store for at least three months, unless otherwise
restricted by law.
Note: “Sensitive areas” refers to any data center, server room or any area that
houses systems that store, process, or transmit cardholder data. This excludes
public-facing areas where only point-of- sale terminals are present, such as
the cashier areas in a retail store.
#N/A
#N/A
#N/A
#N/A
#N/A
11.3 11.3 Implement a methodology for penetration testing that includes the
following:
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
3.2 3.2 Do not store sensitive authentication data after authorization (even if
encrypted). If sensitive authentication data is received, render all data
unrecoverable upon completion of the authorization process. It is permissible
for issuers and companies that support issuing services to store sensitive
authentication data if:
8.5.1 8.5.1 Additional requirement for service providers only: Service providers with
remote access to customer premises (for example, for support of POS systems
or servers) must use a unique authentication credential (such as a
password/phrase) for each customer.
8.5.16 #N/A
8.5.8 #N/A
12.3.2 12.3.2 Authentication for use of the technology
8.5.15 #N/A
• Details of all algorithms, protocols, and keys used for the protection of
cardholder data, including key strength and expiry date
• Description of the key usage for each key
• Inventory of any HSMs and other SCDs used for key management
Note: This requirement is a best practice until January 31, 2018, after which it
becomes a requirement.
3.5.2 3.5.2 Restrict access to cryptographic keys to the fewest number of custodians
necessary.
3.6 3.6 Fully document and implement all key-management processes and
procedures for cryptographic keys used for encryption of cardholder data,
including the following:
Note: Numerous industry standards for key management are available from
various resources including NIST, which can be found at http://csrc.nist.gov.
3.6.4 3.6.4 Cryptographic key changes for keys that have reached the end of their
cryptoperiod (for example, after a defined period of time has passed and/or
after a certain amount of cipher- text has been produced by a given key), as
defined by the associated application vendor or key owner, and based on
industry best practices and guidelines (for example, NIST Special Publication
800-57).
10.1 10.1 Implement audit trails to link all access to system components to each
individual user.
10.2 10.2 Implement automated audit trails for all system components to
reconstruct the following events:
10.2.1 10.2.1 All individual user accesses to cardholder data
10.2.5 #N/A
10.2.7 10.2.7 Creation and deletion of system- level objects
10.3 10.3 Record at least the following audit trail entries for all system components
for each event:
10.3.1 10.3.1 User identification
10.3.2 10.3.2 Type of event
10.3.3 10.3.3 Date and time
10.3.4 10.3.4 Success or failure indication
10.3.5 10.3.5 Origination of event
10.3.6 10.3.6 Identity or name of afected data, system component, or resource.
10.5.4 10.5.4 Write logs for external-facing technologies onto a secure, centralized,
internal log server or media device.
10.6 10.6 Review logs and security events for all system components to identify
anomalies or suspicious activity.
Note: Log harvesting, parsing, and alerting tools may be used to meet this
Requirement.
11.5 11.5 Deploy a change-detection mechanism (for example, file-integrity
monitoring tools) to alert personnel to unauthorized modification (including
changes, additions, and deletions) of critical system files, configuration files, or
content files; and configure the software to perform critical file comparisons
at least weekly.
Note: For change-detection purposes, critical files are usually those that do
not regularly change, but the modification of which could indicate a system
compromise or risk of compromise. Change-detection mechanisms such as
file-integrity monitoring products usually come pre-configured with critical
files for the related operating system. Other critical files, such as those for
custom applications, must be evaluated and defined by the entity (that is, the
merchant or service provider).
2.3 2.3 Encrypt all non-console administrative access using strong cryptography.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
4.1 4.1 Use strong cryptography and security protocols to safeguard sensitive
cardholder data during transmission over open, public networks, including the
following:
• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations.
• The encryption strength is appropriate for the encryption methodology in
use.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
Examples of open, public networks include but are not limited to:
• The internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile
communications (GSM), Code division multiple access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications
4.1.1 4.1.1 Ensure wireless networks transmitting cardholder data or connected to
the cardholder data environment, use industry best practices to implement
strong encryption for authentication and transmission.
#N/A
#N/A
3.2 3.2 Do not store sensitive authentication data after authorization (even if
encrypted). If sensitive authentication data is received, render all data
unrecoverable upon completion of the authorization process. It is permissible
for issuers and companies that support issuing services to store sensitive
authentication data if:
8.1 8.1 Define and implement policies and procedures to ensure proper user
identification management for non- consumer users and administrators on all
system components as follows:
8.5.16 #N/A
8.5.8 #N/A
12.3.2 12.3.2 Authentication for use of the technology
#N/A
2.1.1 #N/A
4.1 4.1 Use strong cryptography and security protocols to safeguard sensitive
cardholder data during transmission over open, public networks, including the
following:
• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations.
• The encryption strength is appropriate for the encryption methodology in
use.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
Examples of open, public networks include but are not limited to:
• The internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile
communications (GSM), Code division multiple access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications
4.1 4.1 Use strong cryptography and security protocols to safeguard sensitive
cardholder data during transmission over open, public networks, including the
following:
• Only trusted keys and certificates are accepted.
• The protocol in use only supports secure versions or configurations.
• The encryption strength is appropriate for the encryption methodology in
use.
Note: Where SSL/early TLS is used, the requirements in Appendix A2 must be
completed.
Examples of open, public networks include but are not limited to:
• The internet
• Wireless technologies, including 802.11 and Bluetooth
• Cellular technologies, for example, Global System for Mobile
communications (GSM), Code division multiple access (CDMA)
• General Packet Radio Service (GPRS)
• Satellite communications
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
#N/A
Policy / Process / Procedure
#N/A
#N/A
#N/A
Audit / Interview / Sample Review
Audit / Interview / Sample Review
0
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Physical Security
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
#N/A
0
Audit / Interview / Sample Review
0
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
#N/A
0
#N/A
#N/A
Audit / Interview / Sample Review
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
0
0
0
0
0
0
0
0
#N/A
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
#N/A
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
#N/A
#N/A
The anti-virus solution is an application to be installed onto the client it is
meant to protect. This can be done manually, as part of an image, or remotely
executed
The anti-virus solution is an application to be installed onto the client it is
meant to protect. This can be done manually, as part of an image, or remotely
executed
0
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Where these controls are not already in place, facilities upgrades should be
planned and implemented to ensure compliance with Requirement 9 of the
DSS
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
For complying to PCI DSS, data that is termed as authentication data should
not be stored beyond the retention period. This data includes magnetic strip
contents, verification code and PIN. The deletion of such data is important as
this data is extremely valuable for scammers as they can make fake duplicate
payment cards based upon this information. If sensitive authentication data is
received, follow the company procedure for safely deleting the data and verify
that no recovery of the data is possible.
User access controls are in place and used by the appropriate user
administrators so that each user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted by policy
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
#N/A
0
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
#N/A
0
Keys should remain in a protected key vault at all times. In particular, ensure
that there is a gap between the threat vectors that have direct access to the
data and the threat vectors that have direct access to the keys. This implies
that keys should not be stored on the application or web server (assuming
that application attackers are part of the relevant threat model)
The organization must generate strong keys so that the security of the data
isn't undermined by weak cryptographic keys. A strong key is generated by
using a key length which is sufficient for your data security requirements and
compliant with the PCI DSS. The key size alone isn't a measure of the strength
of a key. The data used to generate the key must be sufficiently random
("sufficient" often being determined by your data security requirements) and
the entropy of the key data itself must be high.
The method used to distribute keys must be secure to prevent the theft of
keys in transit. The use of a protocol such as Diffie Hellman can help secure
the distribution of keys, the use of secure transport such as TLS and SSHv2 can
also secure the keys in transit. Older protocols like SSLv3 should not be used.
Configure key management software to store the merchant key (in encrypted
format) in an external file. Specify a key encryption key in a separate file,
which is used to encrypt the merchant key. Each file should be protected with
file system protection.
The PCI DSS standard mandates that keys used for encryption must be rotated
at least annually. The key rotation process must remove an old key from the
encryption/decryption process and replace it with a new key. All new data
entering the system must encrypted with the new key. While it is
recommended that existing data be rekeyed with the new key, as per the
rekey data at least every one to three years rule above, it is not clear that the
PCI DSS requires this.
The requirement for split knowledge and/or dual control for key management
prevents an individual user performing key management tasks such as key
rotation or deletion. The system should require two individual users to
perform an action (i.e. entering a value from their own OTP) which creates to
separate values which are concatenated two create the final key data.
The system put in place to comply with requirement 3.6.6 can go a long way to
preventing unauthorized substitution of key data. In addition to the dual
control process you should implement strong access control, auditing and
logging for key data so that unauthorized access attempts are prevented and
logged.
To perform the strong key management functions we have seen in
requirement 3.6 we must have highly trusted and trained key custodians who
understand how to perform key management duties. The key custodians must
also sign a form stating they understand the responsibilities that come with
this role.
0
#N/A
0
0
0
0
0
0
0
0
0
0
The sys admin or integrator would be responsible for ensuring admin access is
privileged access requiring MFA, and utilizes strong encryption algorithms. On
Windows systems, a reviews of Services will inform us if insecure remote-login
services such as Telnet or prohibited
#N/A
#N/A
For complying to PCI DSS, data that is termed as authentication data should
not be stored beyond the retention period. This data includes magnetic strip
contents, verification code and PIN. The deletion of such data is important as
this data is extremely valuable for scammers as they can make fake duplicate
payment cards based upon this information. If sensitive authentication data is
received, follow the company procedure for safely deleting the data and verify
that no recovery of the data is possible.
User access controls are in place and used by the appropriate user
administrators so that each user ID is uniquely assigned to an individual user.
No "generic" user IDs are created or permitted by policy
User Access Management policy and processes will set the standards for user
passwords and/or other authentication methods.
▪ Length
▪ Numbers/Letter/Special
▪ Not reused
▪ Not matching ID
▪ Non-repeating
#N/A
#N/A
0
#N/A
#N/A
It is important to keep in mind that some of the authentication protocols such
as TLS 1.0, SSL v2.0 and SSH v1.0 have vulnerabilities known to hackers and
can easily be exploited by them for getting information access or even
diverting the information flowing across a network. Hence, to prevent this
exploitation, protocols should be configured with their secure versions only.
The organization can gauge the efectiveness of this control by reviewing the
wireless access point configuration with an administrator and confirming that
weak encryption schemes are not in use
The adoption of CIS benchmarks in the organization is ultimately a
management decision and requires their commitment. The benefits of
leveraging this standard should be considered by all respective teams, and
incorporated by the administrator/engineer prior to the installation of any
software.
The organization can gauge the efectiveness of this control by reviewing the
wireless access point configuration with an administrator and confirming that
weak encryption schemes are not in use
Control Implementation
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
#N/A
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
#N/A
No password configuration checks failed
#N/A
#N/A
#N/A
In order to be assured that anti-virus is installed and protecting the endpoint
or host, a screenshot will suffice as an artifact. This artifact should depict that
the endpoint has the most up to date DAT file.
In order to be assured that anti-virus is installed and protecting the endpoint
or host, a screenshot will suffice as an artifact. This artifact should depict that
the endpoint has the most up to date DAT file.
For systems with distinct operating systems, a formal testing plan should exist
to ensure these systems exude no signs of compromise (vulnerability scans,
internal pentest, etc.)
0
#N/A
0
0
0
0
0
0
0
0
0
0
Most wireless access points on the market today do not ship with default
encryption keys that need to be changed upon arrival. An encryption
algorithm such as WPA2/AES or TKIP should be an option for its configuration.
It's usage is strongly encouraged
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
All physical user access to the CDE is monitored, recorded, logged, saved and
retrievable for no less than 3 months.
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
For complying to PCI DSS, data that is termed as authentication data should
not be stored beyond the retention period. This data includes magnetic strip
contents, verification code and PIN. The deletion of such data is important as
this data is extremely valuable for scammers as they can make fake duplicate
payment cards based upon this information. If sensitive authentication data is
received, follow the company procedure for safely deleting the data and verify
that no recovery of the data is possible.
1 user = 1 User ID
#N/A
#N/A
0
To ensure that this capability exists and is in place, once each new application
or system is stood up an admin needs only to attempt to login via a credential
set that has not been explicitly permitted access. As long as the authentication
attempt is unsuccessful, the test can be deemed a success.
#N/A
0
Strict policies and procedures should be implemented and should ensure the
following:
0
#N/A
0
0
0
0
0
0
0
0
0
0
To meet the requirements of the PCI-DSS, you must disable weak keys and
protocol implementations (such as SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0)
that have known vulnerabilities. These encryption types are considered too
weak for PCI-DSS compliance. Instead, you should use stronger
implementations like TLS 1.1 or higher
The use of WEP and any other algorithm proven to be inefective as a security
control must be prohibited within wireless networks
#N/A
#N/A
For complying to PCI DSS, data that is termed as authentication data should
not be stored beyond the retention period. This data includes magnetic strip
contents, verification code and PIN. The deletion of such data is important as
this data is extremely valuable for scammers as they can make fake duplicate
payment cards based upon this information. If sensitive authentication data is
received, follow the company procedure for safely deleting the data and verify
that no recovery of the data is possible.
1 user = 1 User ID
#N/A
#N/A
0
#N/A
#N/A
To meet the requirements of the PCI-DSS, you must disable weak keys and
protocol implementations (such as SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0)
that have known vulnerabilities. These encryption types are considered too
weak for PCI-DSS compliance. Instead, you should use stronger
implementations like TLS 1.1 or higher
The use of WEP and any other algorithm proven to be inefective as a security
control must be prohibited within wireless networks
These configuration standards must meet some hardening standards such as
those from SANS or NIST. The Center for Internet Security is the primary
recognized industry-standard for secure configuration guidance, developing
comprehensive, consensus-derived checklists to help identify and mitigate
known security vulnerabilities across a wide range of platforms. CIS
benchmarks provide prescriptive guidance for establishing a secure
configuration posture for your IT Infrastructure, including a detailed
description and rationale of potential vulnerabilities together with clear
auditing and remediation steps. As such, the CIS benchmarks are the
overwhelming option of choice for auditors worldwide.
To meet the requirements of the PCI-DSS, you must disable weak keys and
protocol implementations (such as SSL v2.0, SSL v3.0, SSH v1.0 and TLS 1.0)
that have known vulnerabilities. These encryption types are considered too
weak for PCI-DSS compliance. Instead, you should use stronger
implementations like TLS 1.1 or higher
The use of WEP and any other algorithm proven to be inefective as a security
control must be prohibited within wireless networks
Effectiveness of Control
0
0
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
#N/A
Running a report from any of these CM tools will produce an artifact that
should satisfy this requirement. A review of the organization's SOP or asset
baseline manual should also exude compliance
The SOP can be either electronic or physical. Fir compliance purposes, the
section speaking to role-based access, least privileges, and need to know can
simply be provided to the auditor for review
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
0
0
0
0
0
0
0
0
#N/A
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
#N/A
Running a report from any of these CM tools will produce an artifact that
should satisfy this requirement. A review of the organization's SOP or asset
baseline manual should also exude compliance
Audit results, actions items and follow up activities are documented and
stored for later reference and review.
Running a report from any of these CM tools will produce an artifact that
should satisfy this requirement. A review of the organization's SOP or asset
baseline manual should also exude compliance
The SOP can be either electronic or physical. Fir compliance purposes, the
section speaking to role-based access, least privileges, and need to know can
simply be provided to the auditor for review
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
#N/A
#N/A
Compliance to this requirement should be achieved by taking a sample of
system components and verifying that an updated version of antivirus is
deployed and fully functional. The Network Access Control (NAC) mechanism
can also help to verify that all individual systems have latest patches applied to
them
To achieve compliance, the following measures need to be taken:
▪ Check up the policies and procedures of the organization to make sure that
they mention the need of updated antivirus software and confirm that it is
applied according to the policies and procedures.
▪ Inspect the anti-virus configuration to verify that anti-virus scans are set to
start H70automatically after certain time periods and are on auto-update
mode.
▪ Verify by checking the anti-virus configuration, that H69log generation of
anti-virus is enabled and are in compliance with requirement 10.7
▪ Check up the policies and procedures of the organization to make sure that
they mention the need of updated antivirus software and confirm that it is
applied according to the policies and procedures.
▪ Inspect the anti-virus configuration to verify that anti-virus scans are set to
start automatically after certain time periods and are on auto-update mode.
▪ Verify by checking the anti-virus configuration, that log generation of anti-
virus is enabled and are in compliance with requirement 10.7
0
#N/A
0
0
0
0
0
0
0
0
0
0
A running config pulled from the WAP should suffice as an artifact during an
audit
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
#N/A
#N/A
#N/A
Video and access logs including date time stamps are retrievable for the
specified timeframe.
#N/A
#N/A
#N/A
#N/A
#N/A
0
0
#N/A
#N/A
0
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
#N/A
To verify that no data from magnetic stripe, verification code and Personal
Identification Number is stored even after authorization, examine all data
sources such as incoming and outgoing transaction details, logs, history files,
trace files, database contents, etc.
System User Reports listing the appropriate data to show any instances of
User IDs that are generic in nature or are accessed by more than 1 user
simultaneously.
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
#N/A
0
#N/A
0
Key Vault Review
Admin Interview
Policy Audit
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
Admin Interview
Key Vault Review
Policy Audit
0
#N/A
0
0
0
0
0
0
0
0
0
0
#N/A
#N/A
To verify that no data from magnetic stripe, verification code and Personal
Identification Number is stored even after authorization, examine all data
sources such as incoming and outgoing transaction details, logs, history files,
trace files, database contents, etc.
System User Reports listing the appropriate data to show any instances of
User IDs that are generic in nature or are accessed by more than 1 user
simultaneously.
User profile report that indicates that the password complies with the policy
Smart Card / Token issuance logs indicating issue date / return date / user /
manager / etc.
#N/A
#N/A
0
#N/A
#N/A
To carry out a compliance check, all locations of cardholder data transmittal
over public networks should be identified. The actual applied system
configuration setting should then be checked against the documented
procedures to ensure that they are actually being put into practice. The
processes should be verified for recognition of trusted certificates and/or
keys, use of secure version of protocol and a strong encryption methodology.
Verification should be done by selecting a sample of data transmission and
identifying whether strong cryptography is applied on the data during transit
or not, protocol with secured version is being used and only trusted keys are
accepted. For strong cryptography, verify that the wireless networks
transmitting the cardholder data use industry best practices for encryption,
such as IEEE 802.11
Admin Interview
WAP Configuration Review
Policy Audit
A CIS report template can serve as an artifact for compliance, as well as a
recent vulnerability scan report showing that the system is hardened per the
specification of the benchmark
Admin Interview
WAP Configuration Review
Policy Audit
Hardware Configuration
Policy / Process / Procedure
Audit / Interview / Sample Review
Physical Security
Other Documentation