JUSTFAB JUSTFAB NETWORK SECURITY POLICY
←
→
Page content transcription
If your browser does not render page correctly, please read the page content below
JustFAB
JustFAB Network Security
Policy
Version Control
Version Date Author Modifications
1.0 11/25/2014 Jason Loomis, VP IT Initial release
Security/Operations
1.1 2/1/2015 Jason Loomis, VP IT Additions
Security/Operations
1.2 4/25/2015 Jason Loomis, VP IT Edits – grammatical only
Security/Operations
CONFIDENTIAL Page 1 of 28 25/04/20151. Overview
The JustFab Network Security Policy covers the general (non-IT specific)
requirements of all employees and others noted in the scope statement for the
protection of JustFab information and assets. This document outlines the network
security policy for JustFAB. All current information security policies and standards
are available at https://sharepoint.justfab.net or by request from the IT Security
Department.
2. Purpose
The purpose of this policy is to establish the technical guidelines for IT security,
and communicate the controls necessary for a secure network infrastructure.
The JustFab Network Security Policy will provide the practical mechanisms to
support JustFAB’s comprehensive set of security policies.
3. Scope
This policy applies to employees, contractors, consultants, interns, vendors and
other workers at JustFab, including all personnel affiliated with third parties.
This policy applies to all computer and network systems owned, leased, licensed
or administered by JustFAB and specifically those that store, process or transmit
cardholder data. This includes, but is not limited to all operating systems,
computer systems, and application systems. The policy covers only information
handled by computers and networks. Although this document includes mention
of other manifestations of information such as voice and paper, it does not
directly address the security of information in these forms. For information
about the protection of information in paper form, see the employee handbook.
A network device is defined as any device that provides network services,
including, but not limited to: routers, switches, wireless access points, multi-
homed computers, firewalls.
This policy is a required policy for all networks and network devices determined
to be in-scope for PCI compliance, and is the recommended policy for all other
JustFAB networks.
4. Policies
4.1. Network Device Authentication
A compromised password on a network device could have devastating, network-
wide consequences. Passwords that are used to secure these devices, such as
CONFIDENTIAL Page 2 of 28 25/04/2015routers, switches, and servers, must be held to higher standards than user-level
or desktop system passwords.
4.1.1. Network Device Password Construction
Passwords can be a weak link in a security infrastructure. Because of this,
the organization specifies that two-factor authentication be used for
network devices. This may be in the form of a smart card, hardware or
software token, biometrics, or another method that greatly enhances
security.
The organization recognizes, however, that not every system (internal and
external) is compatible with two-factor authentication, or that two-factor
authentication isn’t practical. In these situations the IT Security
Department (can we name someone specific or that IT has to be contacted)
must be notified and a strong password selected. Where a password must
be used, the organization mandates that users adhere to the Information
Security Policy section 4.4 for password requirements.
4.1.2. Failed Logins to Network Devices
Repeated login failures can indicate an attempt to 'crack' a password and
surreptitiously access a network account. In order to guard against
password-guessing and brute-force attempts, JustFAB must lock a user's
account after 3 unsuccessful logins. This can be implemented as a time-
based lockout or require a manual reset, at the discretion of the
Information Security Department.
In order to protect against account guessing, when login failures occur the
error message transmitted to the user must not indicate specifically
whether the account name or password were incorrect. The error can be
as simple as "the login credentials you supplied were incorrect."
4.1.3. Network Device Default Value Change Requirements
Passwords must be changed according to JustFAB’s Password Policy.
Additionally, the following requirements apply to changing network device
defaults:
Vendor defaults are easy for an attacker to guess and can lead to a major
security incident. For this reason JustFAB requires that all vendor default
values be changed prior to a new device being installed on the network.
This includes but is not limited to those used by:
o Software that provides security services
o Application accounts
o System accounts
CONFIDENTIAL Page 3 of 28 25/04/2015o Pont of sale terminals
o Encryption keys
o SNMP community strings
o Etc.
Additionally, these values must be changed when someone who has
knowledge of the existing values leaves JustFAB, changes position, or any
time there is a suspected security incident relating to these devices, even
peripherally. This statement also applies to any consultant or contractor
who has access to administrative passwords. (Can we add a requirement
that anyone with administrative passwords must be approved by the IT
department?)
If any network device password is suspected to have been compromised,
all network device passwords must be changed immediately. (Would IT
be responsible for giving notice of a compromise and would individual
users have to change passwords or would they be reset by IT?) Not
applicable. See definition of Network Device under scope.
4.1.4. Password Policy Enforcement
Where passwords are used, technology must be implemented that enforces
JustFAB's password policies on construction, changes, re-use, lockout, etc.
4.1.5. Administrative Password Guidelines
As a general rule, administrative (also known as "root") access to systems
must be limited to only those who have a legitimate business need for this
type of access. This is particularly important for network devices, since
administrative changes can have a major effect on the network, and, as
such, network security. Additionally, administrative access to network
devices must be logged. (Logged how and who monitors?) Not part of the
policy (I know this is getting confusing even for me – the difference
between policy and procedure) but part of our process.
4.2. Logging
The logging of certain events is an important component of good network
management practices. Logs contained on application servers, network devices,
and critical systems may all contain different data, but all contain valuable
information that JustFAB must record. Thus, JustFAB requires that logging on
network-level devices must be enabled to the fullest degree possible. No
passwords must be contained in logs.
CONFIDENTIAL Page 4 of 28 25/04/20154.2.1. Log Management
While logging is important to JustFAB's network security, log management
can become burdensome if not implemented appropriately. As logs grow, so
does the time required to review and manage the logs. For this reason,
JustFAB uses a third party log aggregation and monitoring service for all PCI
compliant required logging. (Recommends this to who, either we have this
or not, unclear why this is recommended)
4.2.2. Log Review
Device logs do little good if they are not reviewed on a regular basis.
JustFAB must review logs for all system components to identify anomalies
or suspicious activity. Log harvesting, parsing, and management
applications can assist in highlighting important events, however, a
member of the JustFAB IT Security team must review logs on critical and
high-security devices at least daily. This review can utilize a log
management tool as long as it is properly configured to highlight relevant
data for human analysis. (Is someone assigned to do this? Don’t want to
have a policy that we are not following)
JustFAB requires the following to be included in the daily review:
o All security events.
o Logs of all system components that store, process, or transmit
cardholder data or sensitive authentication data, or those that
could impact the security of the cardholder data environment
(CDE) or Sensitive Authentication Data (SAD).
o Logs of all critical system components.
o Logs of all servers and system components that perform security
functions, such as firewalls, intrusion detection systems, intrusion
prevention systems, authentication servers, etc.
Other system logs should be reviewed periodically based on JustFAB’s
overall risk management strategy, as determined by the annual risk
assessment, and at the discretion of the Information Security
Department. The frequency of these reviews should be based on the
JustFAB’s perceived level of risk. (Who decides the level of risk? Who
conducts the annual assessment?) Right now, there is none, IT Security
will be developing on in Q2 of 2015.
CONFIDENTIAL Page 5 of 28 25/04/2015Any exceptions or anomalies discovered during the review process must
be fully investigated, and the results documented.
4.2.3. Log Retention
Logs must be retained in accordance with JustFAB's Retention Policy.
Unless known to contain non-proprietary or public data, JustFAB must
classify network device logs as confidential data.
4.3. Audit Trails
Audit trails are similar to logging, and typically are created from logs, but differ in
that audit trails are typically chronological and designed to allow for the
reconstruction and examination of the activities surrounding network and
system events.
4.3.1. Audit Trail Process
JustFAB has established a process for linking all access to system
components, particularly access done with administrative privileges, back
to individual users. Audit trails must be implemented that allow the
reconstruction of the following events:
o Individual access to cardholder data.
o All actions taken with administrative/root privileges.
o Access to audit trails.
o Invalid logical access attempts.
o Use of, and changes to, authentication mechanisms, including
creation of new accounts, elevation of privileges, etc.
o Initialization, pausing, or stopping audit logs.
o Creation and deletion of system-level objects.
Audit trails must be retained for at least one year, with a minimum of three
months available for immediate analysis.
4.3.2. What to Record
JustFAB records the following entries for all system components for each
event, so that a potential compromise can be quickly identified with
sufficient detail to investigate the situation:
User identification.
Type of event.
Date and time of event.
Success or failure indication.
Origination of event.
CONFIDENTIAL Page 6 of 28 25/04/2015 Identity or name of affected data, system component, or
resources.
4.3.3. Security of Audit Trails
An attacker will often try to erase records of what he or she changed on a
system. For that reason JustFAB must secure audit trails such that they
cannot be altered. The following requirements apply specifically to the
protection of audit trails:
o Only those with a job-related need may be able to view or access
audit trails.
o Audit trail files must be protected from unauthorized modifications.
o Audit trails must be promptly backed up to a centralized server or
other media that is difficult to alter.
o Logs for external-facing systems (such as web, firewall, DNS, etc.)
must be written to a secure, centralized, internal log server or media
device.
o Log files must be monitored for unusual behavior through the use of
file-integrity monitoring or change detection software. Logs that
don’t often change should be monitored for any changes. Logs that
do often change should be monitored for changes outside normal
parameters, such as the deletion of the log, major log file size
changes, or any other indications that the log has been tampered
with.
4.4. Firewalls
Firewalls are arguably the most important component of a sound security
strategy. Internet connections and other unsecured networks must be separated
from the JustFAB network through the use of a firewall.
4.4.1. Configuration
The following statements apply to JustFAB's implementation of
firewall technology:
A firewall or firewalls must be configured by default to block
inbound access to the network from external sources.
CONFIDENTIAL Page 7 of 28 25/04/2015 Firewall rules must be as restrictive as possible while still
providing the necessary access required for business operations.
Firewalls must provide secure administrative access (through the
use of strong encryption) with management access limited to only
networks where management connections would be expected to
originate.
No unnecessary services or applications can be enabled on
firewalls. JustFAB must use 'hardened' systems for firewall
platforms, or use pre-hardened appliances.
Clocks on firewalls must be synchronized with JustFAB's other
networking hardware using NTP or other means. This should be
done by either synchronizing directly to an external time server or
by synchronizing to an internal time server which itself is
synchronized to an external time server. Regardless of the
architecture, JustFAB must ensure that its systems are
synchronized to UTC (Coordinated Universal Time), which is
received from reliable, industry-accepted time sources. Among
other benefits, this will aid in problem resolution and security
incident investigation. Time data must be protected from
unauthorized access, since a malicious user will often attempt to
change system time in order to prevent detection of his or her
activity.
Firewalls must be configured by default to block access to high
security zones or confidential information, such as the cardholder
data environment. Any firewall rules that allow access to these
zones, regardless of the type of access, must be approved by
management and documented accordingly. Documentation must
include port, level and type of access, business reason for access,
and proof of management approval for access.
All firewall adds/additions or changes to ECOM/PCI environments
must be made using the JustFAB Firewall Access Request form,
must be signed by the Department Head, a Security Officer, an IT
Operations representative or a Security Analyst and submitted to
servicedeskticket@justfab.com.
Firewall rulesets must be documented and audited every six
months. Documentation must include details of each rule,
CONFIDENTIAL Page 8 of 28 25/04/2015including business justification for all services and protocols
allowed. Documentation of any protocols considered to be
insecure must include a description of security features
implemented to mitigate risk to acceptable levels. Audits must
cover each rule, what it is for, if it is still necessary, and if it can be
implemented more securely. All documentation must be
approved and maintained by the Information Security Manager.
For its own protection, the firewall ruleset must include a "stealth
rule," which forbids connections to the firewall itself.
The firewall must log dropped or rejected packets.
Systems must be configured to restrict the disclosure of internal
IP addresses and routing information.
No internal network IP address must be allowed to pass from the
Internet into the DMZ. This will prevent attacks that spoof IP
addresses so that they look like legitimate internal traffic, and
thus bypass rules designed to prohibit external connections.
Any publicly accessible services, protocols, or ports must be
located in a DMZ, segregated by a firewall from JustFAB’s internal
network. All inbound public traffic must be routed to IP addresses
located in the DMZ.
A process must be developed so that any changes to the firewall
configuration must be approved by the Information Security Manager
before being implemented.
4.4.2. Load Balancing
Services often require load balancing integration. Load balancing requests
for all ECOM and PCI environments must
4.4.3. Outbound Traffic Filtering
Firewalls are often configured to block only inbound connections
from external sources; however, by filtering outbound
connections from the network, security can be greatly improved.
This practice is also referred to as "Egress Traffic Filtering."
Blocking outbound traffic prevents users from accessing
unnecessary, and many times, dangerous services. By specifying
CONFIDENTIAL Page 9 of 28 25/04/2015exactly what outbound traffic to allow, all other outbound traffic
is blocked. This type of filtering would block root kits, viruses, and
other malicious tools if a host were to become compromised.
JustFAB requires that permitted outbound traffic be limited to
only known ``good'' services, which are the following ports: 22,
25, 53, 80, 143, 443, 465, 585, 993 and 995. All other outbound
traffic must be blocked at the firewall unless an exception is
granted from the Information Security Manager.
4.5. Networking Hardware
Networking hardware, such as routers, switches, bridges, and access points,
must be implemented in a consistent manner. The following statements
apply to JustFAB's implementation of networking hardware:
o Networking hardware must provide secure administrative access
(through the use of strong encryption) with management access limited
to only networks where management connections would be expected
to originate.
o Clocks on networking hardware must be synchronized with JustFAB's
other networking hardware using NTP or other means. This should be
done by either synchronizing directly to an external time server or by
synchronizing to an internal time server which itself is synchronized to
an external time server. Regardless of the architecture, JustFAB must
ensure that its systems are synchronized to UTC (Coordinated Universal
Time), which is received from reliable, industry-accepted time sources.
Among other benefits, this will aid in problem resolution and security
incident investigation. Time data must be protected from unauthorized
access, since a malicious user will often attempt to change system time
in order to prevent detection of his or her activity.
o Switches must be used instead of hubs. Hubs are not to be used
without the specific permission of the Information Security Manager.
When using switches JustFAB must use VLANs to separate networks if it
is reasonable and possible to do so.
o Access control lists must be implemented on network devices that
prohibit direct connections to the devices. Connections to routers must
be limited to the greatest extent possible. Exceptions to this are
management connections that can be limited to known sources.
CONFIDENTIAL Page 10 of 28 25/04/2015o Where possible, router configurations should use anti-spoofing
measures to detect and block forged source IP addresses.
o Router configuration files must be secured from unauthorized access
and synchronized, such that the running (or active) configuration
matches the start-up configuration.
o Only services, daemons, and protocols necessary for the system to
perform the intended business functions are to be enabled on any
system. All other services, daemons, protocols must be disabled. If any
required services, daemons, or protocols are considered to be insecure,
additional security measures must be implemented. For example SSH,
S-FTP, or IPsec VPN must be used to secure insecure technologies such
as NetBIOS, file sharing, telnet, FTP, etc.
o Access to administrative ports on networking hardware must be
restricted to known management hosts and otherwise blocked with a
firewall or access control list.
o Systems must be configured to restrict the disclosure of internal IP
addresses and routing information.
o Router configurations must be built to restrict connections from
untrusted networks to the cardholder data environment.
o Router rulesets (if applicable) must be reviewed every six months. This
review must cover each rule, what it is for, if it is still necessary, and if it
can be implemented more securely. (Who creates the rulesets, where
are they located? Who is supposed to know them?) IT Security and
Operations do. Don’t think I need to state that here? As that would be
part of the process? Not necessarily the policy?
o A process must be developed so that any changes to the router
configuration must be approved by the Information Security Manager
before being implemented.
4.6. Network Servers
Servers typically accept connections from a number of sources, both internal and
external. As a general rule, the more sources that connect to a system, the more
risk that is associated with that system, so it is particularly important to secure
network servers. The following statements apply to JustFAB's use of network
servers:
CONFIDENTIAL Page 11 of 28 25/04/2015 Only services, daemons, protocols, scripts, drivers, and features necessary for
the system to perform the intended business functions are to be enabled on
any system. All other services, daemons, protocols, scripts, drivers and
features must be disabled. If any required services, daemons, or protocols are
considered to be insecure, additional security measures must be
implemented. For example SSH, S-FTP, or IPsec VPN must be used to secure
insecure technologies such as NetBIOS, file sharing, telnet, FTP, etc. If
possible, also follow a server-hardening guide consistent with industry best
practices.
Network servers, even those meant to accept public connections, must be
protected by a firewall or access control list.
Implement only one primary function per server. This will ensure that
applications with different security levels do not exist on the same server.
A standard installation and hardening process must be developed for JustFAB's
network servers. This will provide consistency across servers no matter what
employee or contractor handles the installation.
Systems must be configured to restrict the disclosure of internal IP addresses
and routing information.
Configure system security parameters to prevent misuse.
Clocks on network servers must be synchronized with JustFAB's other
networking hardware using NTP or other means. This should be done by either
synchronizing directly to an external time server or by synchronizing to an
internal time server which itself is synchronized to an external time server.
Regardless of the architecture, JustFAB must ensure that its systems are
synchronized to UTC (Coordinated Universal Time), which is received from
reliable, industry-accepted time sources. Among other benefits, this will aid
in problem resolution and security incident investigation. Time data must be
CONFIDENTIAL Page 12 of 28 25/04/2015protected from unauthorized access, since a malicious user will often attempt
to change system time in order to prevent detection of his or her activity.
4.7. Intrusion Detection/Intrusion Prevention
Intrusion Detection System (IDS) and Intrusion Prevention System (IPS)
technology can be useful in network monitoring and security. The tools
differ in that an IDS alerts to suspicious activity whereas an IPS blocks the
activity. When tuned correctly, IDSs are useful but can generate a large
amount of data that must be evaluated for the system to be of any use.
IPSs automatically take action when they see suspicious events, which
can be both good and bad, since legitimate network traffic can be
blocked along with malicious traffic.
JustFAB requires the use of either an IDS or IPS on critical or high-risk or
high-security network segments. If an IDS is used, procedures must be
implemented to review and act on the alerts expediently. If an IPS is
used, procedures must be implemented that provide a mechanism for
emergency unblocking if the IPS obstructs legitimate traffic. Also, if an
IPS is used, it must be audited and documented according to the
standards detailed in the "Firewalls" section of this document.
4.8. File Integrity Monitoring
File Integrity Monitoring (FIM) will alert to changes to critical system files.
This can be useful in notifying the IT staff to malicious activity or other
significant network events that may otherwise go unnoticed. JustFAB
requires the use of an effective change detection mechanism, such as FIM
technology, that will alert to changes to system files, configuration files, or
content files. The software must be configured to perform critical file
comparisons at least weekly. JustFAB must implement a process to
respond to any alerts generated by the change-detection software.
4.9. Security Testing
Security testing is an important part of maintaining JustFAB's network
security. Security testing can sometimes be provided by IT Staff members,
but is often more effective when performed by a third party with no
connection to JustFAB's day-to-day Information Technology activities,
which is why JustFAB requires a mix of both strategies be used (specific
guidance below). The following sections detail JustFAB's requirements for
security testing.
CONFIDENTIAL Page 13 of 28 25/04/20154.9.1. Wireless Scans
JustFAB must create and document a process to evaluate the
network for the presence of all authorized and unauthorized
wireless access devices (802.11) connected to the network, such as
wireless access points, wireless cards, and portable wireless
devices (such as USB-connectable devices). This process must be
performed at least quarterly.
This analysis can be done via a wireless analyzer or physical
inspection (if the scope of the inspection is limited). If the network
is larger or includes multiple nodes, a combination of physical
inspection and wireless spectrum analysis is required. Additionally,
automated monitoring can be employed. If automated wireless
monitoring is utilized, the employed solution must be configured
to generate alerts to company personnel when an unauthorized
device is discovered.
Refer to JustFAB’s Incident Response Plan for specific actions to
take if an unauthorized wireless device is discovered (refer
specifically to the section 4.6, Hybrid Incidents), either during a
manual scan or discovered via automated analysis, if this
technology is used by JustFAB.
4.9.2. Internal Vulnerability Scans
Internal Vulnerability Scans, that is, vulnerability scans that test
systems from a point internal to the network perimeter, must be
performed quarterly. At a minimum, all systems in the cardholder
data environment or high security zones must be included in the
scope of the internal scans. The purpose of these scans is to locate
any vulnerabilities that exist on the local network, that are either
exploitable by local access or that may be hidden by firewalls or
other access controls.
Internal scans can be performed by qualified company personnel
who are reasonably independent of the systems being tested.
Alternatively, JustFAB may engage a third party to conduct the
internal scans. Any third party company selected must be
recognized as an Approved Scanning Vendor (ASV) by the PCI SSC.
CONFIDENTIAL Page 14 of 28 25/04/2015JustFAB must put a process in place to quickly remediate any
vulnerabilities discovered that are rated “high-risk” vulnerabilities.
After remediation activities, JustFAB must rescan the network until
no high-risk vulnerabilities are found.
In addition to the regularly scheduled quarterly scans, JustFAB
must scan the network after any significant change to the network
(with re-scans as needed), such as: new component installations,
changes in network topology, firewall rule changes, product
upgrades, etc. These scans can be performed by internal company
personnel as qualified above.
4.9.3. External Vulnerability Scans
External Vulnerability Scans, that is, vulnerability scans that test
systems from a point external to the network perimeter, must be
performed quarterly. External scans must test JustFAB’s security
posture from a public perspective (the internet). The purpose of
these scans is to locate any vulnerabilities that exist and can be
accessed from external sources.
External scans must be performed by an Approved Scanning
Vendor (ASV) with organizational independence of JustFAB’s
systems and security configuration. JustFAB must put a process in
place to quickly remediate any vulnerabilities discovered that are
rated “high-risk” vulnerabilities. After remediation activities,
JustFAB must re-scan the network until no high-risk vulnerabilities
are found, such as those rated higher than 4.0 by the Common
Vulnerability Scoring System (CVSS), and a passing score is
achieved.
In addition to the regularly scheduled quarterly scans, JustFAB
must scan the network after any significant change to the network
(with re-scans as needed), such as: new component installations,
changes in network topology, firewall rule changes, product
upgrades, etc. These scans can be performed by qualified internal
company personnel who are reasonably independent of the
systems being tested. (Who performs scans, this and much of the
document seems very IT specific though this is suppose to be a
policy for all employees.) Our external ASV vendor now for in scope
PCI networks.
CONFIDENTIAL Page 15 of 28 25/04/20154.9.4. Penetration Testing
A penetration test differs from a vulnerability assessment in that
penetration testing is a manual process that includes the
identification of vulnerabilities present on a network or system, but
also the active exploit of those vulnerabilities. The first step in a
penetration test is often a vulnerability scan, but a penetration test
will then go much deeper, with the intent of simulating a real-world
attack and identifying methods an attacker may use to successfully
penetrate the network. JustFAB requires that a penetration testing
methodology must be implemented, and the methodology must
meet the following criteria:
Be based on an industry-accepted penetration testing approach
(for example, NIST SP800-115)
Include coverage for the entire cardholder data environment
perimeter and all critical systems.
Include testing from both inside and outside the network.
Include testing to validate any segmentation and scope-
reduction controls.
Defines application-layer penetration tests to include, at a
minimum, the requirements stated in Section 4.15 Software
and Application Development Policy.
Defines network-layer penetration tests to include components
that support network functions and operating systems.
Includes a review and consideration of threats and
vulnerabilities experienced in the previous twelve months.
Specifies retention of penetration testing and remediation
results.
External and internal penetration tests must be performed at least
annually, as well as after any significant infrastructure or
application upgrade or modification, such as an operating system
upgrade, a sub-network added to the environment, or a web server
added to the environment. Any exploitable vulnerabilities found
CONFIDENTIAL Page 16 of 28 25/04/2015during the penetration tests must be corrected and testing
repeated to verify successful remediation.
If network compartmentalization/segmentation is used to isolate
the cardholder data environment from other networks,
penetration testing must be performed at least annually on the
segmentation controls, as well as after any changes to the
segmentation controls, in order to verify that the methods in use
are still operational/effective and capable of isolating the
cardholder data environment from out-of-scope devices.
4.10. Disposal of Information Technology Assets
IT assets, such as network servers and routers, often contain sensitive data
about JustFAB's network communications. When such assets are
decommissioned, the following guidelines must be followed:
Any asset tags or stickers that identify JustFAB must be removed before
disposal.
Any configuration information must be removed by deletion or, if
applicable, resetting the device to factory defaults.
At a minimum, data wiping must be used. Simply reformatting a drive
or deleting data does not make the data unrecoverable. If wiping is
used, JustFAB must use the most secure commercially-available
methods for data wiping. Alternatively, JustFAB has the option of
physically destroying the data storage mechanism from the device
(such as its hard drive or solid state memory).
4.11. Network Compartmentalization
Good network design is integral to network security. By implementing
network compartmentalization, which is separating the network into
different segments based on their security classification, JustFAB will
reduce its network-wide risk from an attack, virus outbreak, or
unauthorized disclosure of confidential information. Firewalls and routers
must be configured to seriously restrict or block connections between
trusted and untrusted networks. Further, security can be increased if
CONFIDENTIAL Page 17 of 28 25/04/2015traffic must traverse additional enforcement/inspection points. JustFAB
requires the following with regard to network compartmentalization:
4.11.1. High Risk Networks and High Security Zones
Examples:
Wireless network, cardholder data environment, systems storing
confidential data.
Requirements:
Access must be restricted to only those services and ports that are
absolutely necessary for business operations and separate the
network with a firewall. Direct access to or from these networks
is prohibited. This includes both inbound and outbound traffic.
Initially an implicit “deny all” rule must be implemented and then
specific, limited access opened as necessary. The firewall must
support stateful inspection, also known as dynamic packet
filtering, such that only established connections are allowed
through. Management approval must be obtained for any rule or
configuration change that provides access at any level to high
security zones. Any ports opened to high security zones must be
documented (inbound or outbound). Documentation must
include: the port, the level and type of access, the necessary
business reason for the access, and management approval for
such access. Access must only be granted when there is no other
viable way to meet the business need.
4.11.2. Externally-Accessible Networks
Examples:
Guest network, Demilitarized Zone (DMZ), email servers, web
servers
Requirements:
Segmentation of externally-accessible systems from JustFAB's
internal network is required, and must be enforced with a firewall
or router that provides granular access controls (source,
destination, service, port, etc.).
CONFIDENTIAL Page 18 of 28 25/04/20154.11.3. Internal Networks
Examples:
Sales, Finance, Human Resources
Requirements:
Segmentation of internal networks from one another can improve
security as well as reduce chances that a user will access data that
he or she has no right to access. JustFAB requires that networks
be segmented to the fullest reasonable extent. If the internal
network is also considered a high risk or high security zone, then
the more restrictive policy will apply.
4.12. Network Documentation
Network documentation, specifically as it relates to security, is important
for efficient and successful network management. Further, the process of
regularly documenting the network ensures that JustFAB's IT Staff has a
firm understanding of the network architecture at any given time. The
intangible benefits of this are immeasurable.
JustFAB requires a formal network documentation process. At a minimum,
network documentation must include:
Network diagram(s), including any wireless networks
System configurations
Firewall ruleset
IP Addresses, both in-use and unallocated
Access Control Lists
Details of rule changes as specified in section 4.9.1
A current diagram that shows all cardholder data flows across systems
and networks
An inventory of all system components that are in the scope of the PCI
Data Security Standard. This should include a list of hardware and
software components, and a description of functions for each.
JustFAB must ensure that the following are documented, in use, and known to
all affected parties:
CONFIDENTIAL Page 19 of 28 25/04/2015 Security policies
Operational procedures for managing firewalls
Operational procedures for vendor defaults and other security
parameters
Operational procedures for protecting stored cardholder data, and
restricting access to cardholder data
Operational procedures for encrypting transmissions of cardholder
data
Operational procedures for protecting systems against malware
Operational procedures for developing and maintaining secure
systems and applications
Operational procedures for identification and authentication
Operational procedures for restricting physical access to cardholder
data
Operational procedures for monitoring all access to network resources
and cardholder data
Operational procedures for security monitoring and testing
4.13. Anti-Malware
Computer viruses and malware are pressing concerns in today's threat
landscape. If a system or network is not properly protected, a virus
outbreak can have devastating effects on the system, the network, and the
entire company. In addition to the policies regarding malicious software
outlined in the JustFAB Information Security Policy, JustFAB provides the
following guidelines on the use of antivirus/anti-malware software:
All company-provided user workstations and servers must have
antivirus/anti-malware software installed.
Workstation software must maintain a current "subscription" to
receive patches and virus signature/definition file updates.
For systems that are considered to not be commonly affected by
malicious software, such as mainframes or similar systems, JustFAB
CONFIDENTIAL Page 20 of 28 25/04/2015must perform periodic evaluations to identify and evaluate evolving
malware threats in order to determine if such systems are becoming
at-risk, and thus should require antivirus/anti-malware software. This
can be done by monitoring vendor security notices and antivirus/anti-
malware newsgroups to determine if the systems in question are
coming under threat from malicious software.
Patches, updates, and antivirus signature file updates must be installed
in a timely manner, either automatically or manually. Software must
be set to automatically install updates whenever practical.
Antivirus solution must be capable of detecting and removing all
known threats. In addition to viruses, the software must eradicate
threats from all known malware, adware, spyware, Trojans, rootkits,
worms, or any other known malicious virus-like software.
Antivirus software must automatically run periodic scans with no user
intervention required to initiate the scan.
Antivirus software must be able and configured to generate audit logs
that are retained for at least one year. A minimum of three months’
logs are required to be available for immediate restoration and/or
analysis.
JustFAB must ensure that antivirus software is running and cannot be
disabled or altered by users.
If there is a legitimate technical need to temporarily disable the
antivirus software, this is permitted only with management approval
and for a limited time period. JustFAB should consider implementing
additional security measures for the time period that the antivirus
software is disabled.
4.14. Software Use Policy
Software applications can create risk in a number of ways, and thus certain
aspects of software use must be covered by this policy. JustFAB provides
the following requirements for the use of software applications:
Only legally licensed software may be used. Licenses for JustFAB's
software must be stored in a secure location.
CONFIDENTIAL Page 21 of 28 25/04/2015 Open source and/or public domain software can only be used with the
permission of the Information Security Manager.
Software must be kept reasonably up-to-date by installing new patches
and releases from the manufacturer.
Vulnerability alerts must be monitored for all software products that
JustFAB uses. Sources of this information should be trustworthy, and
can include vendor websites or mailing lists, industry news groups, RSS
feeds, or other reliable sources. JustFAB must assign a risk ranking
based on industry best practices to each vulnerability discovered, such
as “high,” “medium,” or “low.” Any patches deemed critical, in that
they fix high-risk vulnerabilities or security holes that are found to
currently exist, must be installed as soon as possible, but no more than
one month after the patch release date. Note that the risk ranking and
vulnerability management process must be appropriate based on
JustFAB’s risk assessment strategy.
4.15. Software / Application Development Policy
This section applies if JustFAB develops custom software applications for
internal or external use. It is JustFAB’s intent to develop software in a
secure manner and in accordance with industry best practices for secure
application coding. JustFAB requires that security be included in all phases
of application development, including the following:
JustFAB must train developers in secure coding techniques, including
how to avoid common coding vulnerabilities and understanding how
sensitive data is handled in memory.
Custom application code must be reviewed for security weaknesses
prior to being put into production. This review can be performed by
qualified company personnel or a third party knowledgeable about
code-review techniques and secure coding practices. Regardless, the
reviewer must be independent of the software developer. Automated
review tools can be employed, but should not be a substitute for a
qualified individual or team, as automated tools cannot catch every
CONFIDENTIAL Page 22 of 28 25/04/2015vulnerability. In addition, reviews of custom code must meet the
following criteria:
The reviewer must be independent of the code author.
The reviewer must ensure that code is developed according to
secure coding guidelines.
The reviewer must verify that appropriate corrections are
implemented prior to release.
The code review results, and corrections, must be approved by
management prior to release.
Custom application accounts, development accounts, authentication
data, test accounts, and test data must be removed prior to the
application going into production.
Software development systems must be separated from the
production environment, so that vulnerabilities introduced, perhaps
temporarily, during development do not affect the production
environment. The two environments should be independent, with
privileges managed independently of one another, and enforced with
access controls. For example, a developer may have administrative
privileges to the testing environment but user-level access to the
production environment.
Production data, including live credit card data, must never be used for
testing and/or development. Account numbers suitable for testing can
be obtained from payment card vendors.
JustFAB must implement change control procedures into its
application development process that allow for the implementation of
security patches and software modifications. These must include:
documentation of impact of the change, documentation of approval of
the change by authorized parties, functionality testing that verify
security controls remain effective, and back-out procedures.
Software must be developed using secure coding guidelines, in
accordance with PCI DSS standards, and/or based on industry best
practices, with the development approach adapted as these best
practices change over time. At minimum, the coding methodology
should include protection against:
Code injection flaws (such as SQL injection)
Buffer overflow attacks
Insecure cryptographic storage
Insecure communications
CONFIDENTIAL Page 23 of 28 25/04/2015 Improper error handling
Cross-site scripting (XSS)
Cross-site forgery (CSRF)
Improper access control (such as directory transversal)
Failure to restrict user access functions
Broken authentication and session management
Any vulnerabilities deemed high-risk during the vulnerability
ranking process.
Public facing web applications must be protected by installing an
automated technical solution that detects and prevents web-based
attacks, such as a securely configured web-application firewall, or by
performing automated vulnerability scans targeted at the web
application on an annual basis (or after changes to the application).
Note: the requirements listed in this section were consistent with industry
best practices at the time this policy was written. Sources for information
on industry best practices should be periodically reviewed, and this policy
updated as necessary, to stay consistent with secure application
development practices.
4.16. Maintenance Windows and Scheduled Downtime
Certain tasks require that network devices be taken offline, either for a
simple reboot, an upgrade, or other maintenance. When this occurs, the
IT Staff must perform the tasks during a scheduled weekly or monthly
maintenance window. Tasks that are deemed "emergency support," or
tasks required to close discovered vulnerabilities, as determined by the
Information Security Manager, must be done with one hour's notice to
users or immediately if the situation dictates.
4.17. Change Management
Documenting changes to network devices is a good management practice
and can help speed resolution in the event of an incident. The IT Staff must
document hardware and/or configuration changes to network devices in a
"change log." Network devices must employ a method to readily
determine device owner and purpose, such a sticker or tag indicating
essential information, such as the person responsible for the device,
contact information for that person, and the purpose of the device.
Additional information should be added as necessary, such as the device
name, IP address, asset information, and any additional data that may be
helpful, such as information about cabling.
CONFIDENTIAL Page 24 of 28 25/04/2015As stated in 4.11.1, any ports opened to high security zones must be
documented (inbound or outbound). Documentation must include: the
port, the level and type of access, the necessary business reason for the
access, and management approval for such access. Granular
documentation for all firewall rule changes, not just those that fall under
the requirement above, is recommended.
Any changes to the configuration of firewalls or networking hardware must
be documented, with the documentation including the approval of the
Information Security Manager, VP of IT Security, the CTO or the CIO.
For further details regarding change management procedure, please refer
to the JustFAB IT Operations, IT Security and IT Servicedesk Change
Management Process and Procedures Guide.
4.18. Suspected Security Incidents
When a security incident is suspected that may impact a network device,
the IT Staff must refer to JustFAB's Incident Response policy for guidance.
4.19. Redundancy
Redundancy can be implemented on many levels, from redundancy of
individual components to full site-redundancy. As a general rule, the more
redundancy implemented, the higher the availability of the device or
network, and the higher the associated cost. JustFAB wishes to provide
the IT Manager and/or Information Security Manager, as appropriate, with
latitude to determine the appropriate level of redundancy for critical
systems and network devices. Redundancy should be implemented where
it is needed, and should include some or all of the following:
Hard drive redundancy, such as mirroring or RAID
Server level redundancy, such as clustering or high availability
Component level redundancy, such as redundant power supplies or
redundant NICs
Keeping hot or cold spares onsite
4.20. Manufacturer Support Contracts
Outdated products can result in a serious security breach. When
purchasing critical hardware or software, JustFAB must purchase a
maintenance plan, support agreement, or software subscription that will
allow JustFAB to receive updates to the software and/or firmware for a
CONFIDENTIAL Page 25 of 28 25/04/2015specified period of time. The plan must meet the following minimum
requirements:
Hardware: The arrangement must allow for repair/replacement of the
device within an acceptable time period, as determined by the Information
Security Manager, as well as firmware or embedded software updates.
Software: The arrangement must allow for access to updates, upgrades,
and hotfixes for a specified period of time.
4.21. Security Policy Management
It is JustFAB's intention to comply with this policy not just on paper but in
its everyday processes as well. With that goal in mind JustFAB requires
the following:
4.21.1. Information Security Manager
An employee must be designated as the manager of JustFAB's
security program. He or she will be responsible for JustFAB's
compliance with this security policy and any applicable security
regulations. This employee must be responsible for A) the initial
implementation of the security policies, B) publishing, maintaining,
and disseminating JustFAB’s security policies to all users, C) training
and retraining of employees on JustFAB's information security
program (as detailed below), D) any ongoing testing or analysis of
JustFAB's security in compliance with this policy, E) updating the
policy as needed to adhere with applicable regulations and the
changing information security landscape.
The Information Security Manager must develop usage policies for
all critical technologies and define the proper use of those
technologies. Further, the Information Security Manager must
maintain a list or database of all critical technologies (such as
remote access technologies, wireless technologies, laptops,
tablets, email, and the Internet) and the users that have access to
these technologies. The list must include all devices and personnel
with access to the technologies, the approval of the relevant
authorized parities to use the technologies, the authentication
methods for the use of the technologies, and acceptable network
locations for the devices.
The Information Security Manager will ultimately be responsible
for the security of JustFAB’s data, and must monitor and control all
CONFIDENTIAL Page 26 of 28 25/04/2015access to JustFAB’s information resources. In addition to the
above, the Information Security Manager will be specifically
responsible for:
Implementing JustFAB’s risk management program. Refer to
section 4.8 of the Incident Response policy for additional
information.
Developing daily operational security procedures that are
consistent with the requirements of this policy, and clearly
communicating those procedures to the appropriate
personnel.
Monitoring and analyzing security alerts, and distributing that
information to the appropriate personnel.
The administration of user accounts, including additions,
deletions, and modifications.
Additional employees can be included in JustFAB’s security
program as deemed necessary. All security roles and
responsibilities must be clearly defined, with appropriate
escalation paths. Further, an employee (which can be the
Information Security Manager) or team must be specifically
designated as the contact in the event of a suspected security
incident.
4.21.2. Security Awareness Training
A security awareness program must be implemented that will detail
JustFAB's information security program to all users and/or employees
covered by the policy, as well as the importance of data security. The
training program must cover, among other topics, the appropriate
handling of confidential data, including cardholder data. Employees
must sign off on the receipt of, and in agreement to, the user-
oriented policies upon hire and at least annually. Likewise, security
awareness training must be performed upon hire and at least
annually.
CONFIDENTIAL Page 27 of 28 25/04/20154.21.3. Security Policy Review
JustFAB's security policies must be reviewed at least annually.
Additionally, the policies must be reviewed when there is an
information security incident or a material change to JustFAB's
security policies or network. As part of this evaluation JustFAB must
review:
Any applicable regulations for changes that would affect JustFAB's
compliance or the effectiveness of any deployed security controls.
If JustFAB's deployed security controls are still capable of
performing their intended functions.
If technology or other changes may have an effect on JustFAB's
security strategy.
If any changes need to be made to accommodate future IT security
needs.
4.21.4. Applicability of Other Policies
This document is part of JustFAB's cohesive set of security policies.
Other policies may apply to the topics covered in this document
and, as such, the applicable policies should be reviewed as
necessary.
CONFIDENTIAL Page 28 of 28 25/04/2015You can also read
