Recently, Visa and MasterCard have been increasingly demanding compliance with the PCI DSS standard from payment gateways, merchants connected to them, as well as from service providers that may affect the security of card data. In this regard, the issue of compliance with the requirements of the PCI DSS standard is becoming important not only for large players in the payment card industry, but also for small merchants. In this article, we will answer the main questions that concern organizations that are faced with the task of certification according to the PCI DSS standard.

PCI DSS FAQ for those interested in certification

# Who is covered by PCI DSS?

First of all, the standard defines the requirements for organizations whose information infrastructure stores, processes or transmits data. payment cards, as well as to organizations that can influence the security of this data. The purpose of the standard is quite obvious - to ensure the security of circulation of payment cards. Since mid-2012, all organizations involved in the process of storing, processing and transferring WPC must comply with PCI DSS requirements, and companies in the territory Russian Federation are no exception.

To understand whether your organization is subject to mandatory PCI DSS compliance, we suggest using a simple flowchart.

Figure 1. Determining if PCI DSS Compliance is Necessary

The first step is to answer two questions:

• Is payment card data stored, processed or transmitted within your organization?
• Can your organization's business processes directly affect the security of payment card data?

If the answers to both of these questions are negative, PCI DSS certification is unnecessary. In the case of at least one positive answer, as seen in Figure 1, compliance with the standard is necessary.

# What are the PCI DSS requirements?

Compliance with the standard requires fulfillment of the requirements, which are summarized in the twelve sections shown in the table below.

Table 1. Top-level PCI DSS requirements

If you go a little deeper, the standard requires passing about 440 verification procedures, which should give a positive result when checking for compliance with the requirements.

# How can I verify PCI DSS compliance?

There are various ways to verify compliance with the requirements of the PCI DSS standard, which consist of conducting external audit (QSA), internal audit (ISA) or self-assessment (SAQ) of the organization. The features of each of them are illustrated in the table.

Table 2. PCI DSS Compliance Verification Methods

External audit QSA (Qualified Security Assessor)	ISA internal audit (Internal Security Assessor)	SAQ self-assessment (Self Assessment Questionnaire)
Performed external audit organization QSA certified by the PCI SCC Council.	Performed internal trained and certified by the PCI SSC Council program auditor.Can be carried out only if the primary compliance was confirmed by the QSA-audit.	Performed on one's own by filling out a self-assessment sheet.
As a result of checking QSA auditors collect performance evidence	As a result of checking ISA auditors, as in an external audit, collect performance evidence requirements of the standard and keep them for three years.	Collection of evidence meeting the requirements of the standard not required.
According to the results of the audit Compliance report is being prepared- ROC(Report on Compliance).	Self-filled SAQ self-assessment sheet.

Despite the apparent simplicity of the presented methods, customers often face misunderstanding and difficulties in choosing the appropriate method. An example of this is the emerging questions below.

# In what situation is it necessary to conduct an external audit, and in what- interior? Or is it enough to confine ourselves to the self-assessment of the organization?

The answers to these questions depend on the type of organization and the number of transactions processed per year. This should not be a random choice, as there are documented rules that govern which way an organization will use to verify compliance with a standard. All these requirements are set by international payment systems, the most popular of them in Russia are Visa and MasterCard. There is even a classification according to which two types of organizations are distinguished: trade and service enterprises (merchants) and service providers.

Depending on the number of transactions processed per year, merchants and service providers can be classified into different levels.

Let's say a trade and service enterprise processes up to 1 million transactions per year using e-commerce. According to the classification of Visa and MasterCard (Fig. 2), the organization will be classified as level 3. Therefore, to confirm compliance with PCI DSS, it is necessary to conduct a quarterly external vulnerability scan of information infrastructure components ASV (Approved Scanning Vendor) and an annual SAQ self-assessment. In this case, the organization does not need to collect evidence of compliance, since this is not necessary for the current level. The completed SAQ self-assessment sheet will be the reporting document.

Or consider the example of a cloud service provider that processes over 300,000 transactions per year. According to the established classification of Visa or MasterCard, the service provider will be classified as level 1. This means, as shown in Figure 2, it is necessary to conduct a quarterly external vulnerability scan of ASV information infrastructure components, as well as an external annual QSA audit.

Figure 2. Classification of levels and requirements for confirming compliance with the PCI DSS standard

# Does a single ASV scan timeout pose a significant risk to PCI DSS compliance?

An organization that achieves PCI DSS status must meet a number of requirements on a regular basis, such as quarterly ASV scans. During the initial audit, it is enough to have a documented ASV-scan procedure and the results of at least one successful execution of it in the last three months. All subsequent scans must be quarterly, the length of time should not exceed three months.
Violation of the schedule of external vulnerability scanning entails the imposition of additional requirements for the management system information security In the organisation. First, it will still be necessary to conduct an ASV scan for vulnerabilities, to achieve a "green" report. And secondly, it will be necessary to develop an additional procedure that will not allow such violations of the schedule in the future.

Finally

The main conclusions can be expressed by a quote from Peter Shapovalov, information security engineer at Deuterium LLC:

“Despite the fact that the National Payment Card System (NSPK) has already started functioning on the territory of the Russian Federation, the requirements of international payment systems have not been abolished. On the contrary, recently, letters from Visa and MasterCard to acquiring banks have become more frequent that the latter require compliance with the PCI DSS standard from payment gateways, merchants connected to them, as well as from service providers that may affect the security of card data. . In this regard, the issue of compliance with the requirements of the PCI DSS standard is becoming important not only for large players in the payment card industry, but also for small merchants. Relevant to Russian market is now managed services. It consists in the fact that the service provider provides customers with not only equipment or virtual information infrastructure for rent, but also services for its administration in accordance with the requirements of the PCI DSS standard. This is especially useful for small trade and service enterprises that do not have their own divisions. information technologies and information security. Turning to certified service providers helps significantly simplify the PCI DSS certification process for merchants and ensure the protection of payment card data at the proper level.”

As an example of a company providing PCI DSS managed services (not only renting PCI DSS infrastructure, but also administering it in accordance with the requirements of the standard), we can cite

Friends, we are expanding the range of services provided and will soon add to our website the ability to order services for scanning websites for malicious code (ASV scanning), which is required by PCI DSS certification. In this regard, we are starting a new section of publications related to data security standards and requirements. And first of all, we want to talk about PCI DSS certification. Use of payment by credit and debit cards provides for the possible transfer, storage and processing of payment card data, which increases the risk of cybercrime. In this regard, MasterCard, Visa, American Express and other payment systems put forward certain security requirements for merchants and service providers that work with payment card data. These requirements are described in the PCI DSS standard. Let's understand what is PCI DSS certification and what are the main points you need to know.

What is PCI DSS?

PCI DSS is an abbreviation for Payment Card Industry Data Security Standard, which means the data security standard of the payment card industry. PCI DSS was developed by the PCI SSC (Payment Card Industry Security Standards Council). PCI SSC Board Founding Members - International payment systems Visa, MasterCard, American Express, JCB International and Discover Financial Services have agreed to adopt a common security standard as part of the specification for each of their data security compliance programs. In addition, each founding member recognizes PCI SSC qualified security auditors(Qualified Security Assessors, QSA) and approved scanning providers(Approved Scanning Vendors, ASV). The latter includes our partner Comodo, whose licensed scanning service HackerGuardian PCI Scanning Service will soon be available for order on our website.

Who needs PCI DSS certification?

Everyone who works with payment cards or in any way influences their security should take care of the security of payment card data, and these can be:

• Trade and service companies of any size
• Financial institutions
• Point of Sale Terminal Suppliers
• Manufacturers of hardware and software, in a word, all those who create and use the international infrastructure for processing payments.

Therefore, the requirements of the PCI DSS standards apply to all organizations, regardless of their size or the number of transactions that receive, transfer, process or store any information of credit card holders, or if business processes in these organizations can affect the security of payment cards. .

PCI DSS Requirements

PCI DSS certification implies compliance with the standard, which consists of 12 sections of comprehensive requirements for ensuring the security of information about the owners of payment cards that merchants and service providers work with. Compliance with the requirements of the PCI standard implies a comprehensive implementation of measures to ensure security at each step of working with payment cards, from data transfer to its storage in the company's databases.

Control objects	PCI DSS Requirements
Building and Maintaining a Secure Network	1. Installing and maintaining a firewall configuration to protect the data of payment card holders
	2. Opt-out of default settings for password systems and other security settings
Data protection of payment card holders	3. Protection of received data of payment card holders
	4. Encryption of data transmission of payment card holders over open public networks
Vulnerability Management Program Support	5. Use and regularly update anti-virus software on all systems that are commonly affected by malware
	6. Development and support of secure systems and applications
Implement Strong Access Control	7. Restriction of access to the data of payment card holders on a need-to-know basis
	8. Assigning a unique identification number to every person with access to a computer
	9. Restriction of physical access to data of payment card holders
Regular monitoring and verification of networks	10. Tracking and monitoring of access to network resources and data of payment card holders
	11. Regular review of security systems and processes
Information security policy support	12. Support for policies aimed at ensuring data security

You can read the most current and complete PCI DSS standards on the official website of the Security Standards Council at the link: https://en.pcisecuritystandards.org

PCI DSS Certification Levels

PCI DSS certification defines four levels of trade and service enterprises And two levels of service providers depending on the number of transactions with payment Visa cards(including credit, debit and prepaid cards) within 12 months.

Visa defines the following levels of merchants:

Level	Description	PCI DSS certification includes:
4	Merchants that process less than 20,000 e-commerce transactions per year, and All other merchants not listed in the other tiers that process up to 1 million transactions per year, regardless of the receiving channel.	Annually: Completion of the Safety Self-Assessment Questionnaire (SAQ) is recommended; Quarterly: ASV scan recommended; The acquiring bank determines the compliance requirements.
3	Merchants processing 20,000 to 1 million e-commerce transactions per year.
2	Merchants processing 1-6 million transactions per year, regardless of the channel of their receipt.	Annually: Completion of the Safety Self-Assessment Questionnaire (SAQ); Quarterly: ASV scan recommended.
1	Merchants that process more than 6 million transactions per year, regardless of the channel for receiving them.	Annually: an audit by an approved security auditor (QSA); Quarterly: ASV vulnerability scan.

In several early publications, we have already considered some international standards in the field of information security. However, they were predominantly in house , i.e. company's internal infrastructure. The most clear understanding of information security comes when security is directly related to finances, when it shows its significant impact on business in numbers. Therefore, today we will talk about security in financial institutions such as banks, credit organizations, payment agents, etc. All of them are doing money transfers, which means they fall under the industry standardPCI DSS(Payment Card Industry Data Security Standard)

Standard PCI DSS is designed to ensure the security of processing, storage and transmission of data on payment card holders in the information systems of companies working with international payment systems Visa , master card and others. The standard is developed by the community PCI Security Standards Council, which includes world leaders in the payment card market, such as American Express, Discover Financial Services, JCB, MasterCard Worldwide And Visa International. Standard requirements PCI DSS spread for all companies that process, store or transmit data on payment card holders (banks, processing centers, service providers, e-commerce systems, etc.). In Russia, compliance with the standard PCI DSS became mandatory for use in relevant organizations since 2007.

According to the results of the study Analysys Mason, approximately 42% of cloud service providers comply with payment card industry data security standards (PCI DSS, Payment Card Industry Data Security Standard). They are valid worldwide and apply to all organizations that process credit cards, and also store or transmit information about their holders. This standard was introduced to give the payment card industry more control over sensitive data and prevent it from being leaked. It also aims to ensure that consumers are protected from fraud or identity theft when they use credit cards.

Under both Visa and MasterCard classifications, systems that process, store, or transmit more than 6 million transactions per year are classified as first level (Level 1) and are required annually be audited .

HISTORY OF THE DEVELOPMENT OF THE STANDARD

1.0 is the original version of the standard.

1.1 - adopted in September 2006.

1.2 - adopted in October 2008.

2.0 - adopted in October 2010.

3.0 - adopted in November 2013.

3.1 - adopted in April 2015.

PCI DSS Version 3.0

`The new version of PCI-DSS 3.0 will make the standard an integral part of normal business operations,' Bob Russo, CEO of the Payment Card Industry Security Standards Council (PCI SSC), told eWeek. — We want to try to wean people from believing that PCI-DSS can be dealt with once a year, and then not to think about it. In a real situation, gaps often occur.

PCI-DSS was often seen as nothing more than a basis for checking a company for compliance, where you can tick off that everything is in order at the moment and calmly move on to other matters. Bob Russo emphasized that in the new standard PCI-DSS 3.0 there is an emphasis on education and policy, making payment security a daily task and an element of a constantly maintained order. The bottom line is that the standard will help lead to more consistent process-oriented control, which is especially important for large organizations. And it also strengthens the focus on ongoing accountability, not just occasional PCI-DSS audits.

One of the criticisms of the PCI-DSS standard is the lack of clarity in its provisions. For example, a standard may require an organization to deploy a Web Application Firewall (WAF) without detailing the required firewall configuration or even explaining why it is needed. These criticisms were expressed in a clear and sharp form by members of the PCI SCC, and this required the development of a new and improved standard.

In previous versions of the standard, there were always two columns explaining a particular security control requirement. The first column stated the requirement, and the second gave details of the testing procedure. PCI-DSS 3.0 should have a third column, which Leach says will contain real-life examples of the risks that this security control is designed to mitigate.

So, in the case of WAF, the new standard will explain what this technology can do and what types of risks it can help mitigate.

One of the important changes in the PCI-DSS 3.0 standard is related to the use of passwords. In the past three years, the PCI SCC has conducted a series of password strength studies that have helped formulate new requirements.

One of the PCI-DSS 3.0 requirements that retailers will need to meet is the timely detection of malicious code. Regulation 5.1.2 has been added to ensure that any person processing payment card data has a sound risk management process in this area.

PCI-DSS 3.0 has consistently emphasized the need for flexibility in security management, which must be achieved in a variety of ways that are constantly being improved.

PCI DSS Version 2.0

October 28, 2010 saw the release of a new version of the standard PCI DSS , namely version 2.0. It is difficult to call the changes introduced into the document regulating the industry radical, they are mainly in the nature of clarifications and clarifications. In addition, some verification procedures have been grouped in a new way in order to simplify their perception and implementation during the audit.

Although the version 2.0 standard came into effect on January 1, 2011, payment card industry participants can use the previous version until the end of 2011. This PCI SSC Council initiative allows for a gradual transition to new version. The next version will be prepared by the PCI SSC over a three-year life cycle.

PCI DSS Requirements

The PCI DSS defines the following six areas of control and 12 basic security requirements.

Building and maintaining a secure network

• Requirement 1: Install and maintain firewalls to protect cardholder data.
• Requirement 2: Non-use of manufacturer-default system passwords and other security settings.

Protecting cardholder data

• Requirement 3: Ensuring that cardholder data is protected during storage.
• Requirement 4: Encryption of cardholder data in transit over public networks.

Vulnerability Management Program support

• Requirement 5: Use and regularly update antivirus software.
• Requirement 6: Develop and maintain secure systems and applications.
• Implementing Strict Access Control Measures
• Requirement 7: Restrict access to cardholder data on a need-to-know basis.
• Requirement 8: Assign a unique identifier to each person who has access to the information infrastructure.
• Requirement 9: Restrict physical access to cardholder data.

Regular network monitoring and testing

• Requirement 10: Control and track all access to network resources and cardholder data.
• Requirement 11: Regular testing of security systems and processes.

Information security policy support

• Requirement 12: Develop, maintain, and enforce an information security policy.

Despite the openness of the standards, many questions accumulate. We will try to answer some of them below.

1. Who is covered by PCI DSS?

First of all, the standard defines the requirements for organizations whose information infrastructure stores, processes or transmits payment card data, as well as for organizations that can affect the security of this data. The purpose of the standard is quite obvious - to ensure the security of circulation of payment cards. From mid-2012, all organizations involved in the process of storing, processing and transferring WPC must comply with the requirements PCI DSS , and companies in the Russian Federation are no exception. To understand if your organization is subject to mandatory compliance with the requirements of the standard PCI DSS , we suggest using a simple block diagram.

The first step is to answer two questions:

• Is payment card data stored, processed or transmitted within your organization?
• Can your organization's business processes directly affect the security of payment card data?

If the answers to both of these questions are negative, get certified according to PCI DSS no need. In the case of at least one positive answer, as seen in Figure 1, compliance with the standard is necessary.

2. What are the PCI DSS requirements?

Compliance with the standard requires fulfillment of the requirements, which are summarized in the twelve sections shown in the table below:

If you go a little deeper, the standard requires passing about 440 verification procedures, which should give a positive result when checking for compliance with the requirements.

3. How can I verify PCI DSS compliance?

There are various ways to confirm compliance with the requirements of the standard PCI DSS which consists in carrying out external audit (QSA) , internal audit (ISA) or self-assessment (SAQ) organizations.

The features of each of them are illustrated in the table.

Despite the apparent simplicity of the presented methods, customers often face misunderstanding and difficulties in choosing the appropriate method. An example of this is the emerging questions below.

4. In what situation is it necessary to conduct an external audit, and in which - internal? Or is it enough to confine ourselves to the self-assessment of the organization?

The answers to these questions depend on the type of organization and the number of transactions processed per year. This should not be a random choice, as there are documented rules that govern which way an organization will use to verify compliance with a standard. All these requirements are set by international payment systems, the most popular of which in Russia are Visa And master card. There is even a classification according to which two types of organizations are distinguished: trade service companies (merchants) and service providers.

Trade and service enterprise is an organization that accepts payment cards for payment for goods and services (shops, restaurants, online stores, gas stations, etc.). A trade and service enterprise is an organization that accepts payment cards for payment for goods and services (shops, restaurants, online stores, gas stations, etc.).

Depending on the number of transactions processed per year, merchants and service providers can be classified into different levels.

Let's say a trade and service enterprise processes up to 1 million transactions per year using e-commerce. By classification Visa And master card(Fig. 2) the organization will be classified as level 3. Therefore, to confirm compliance PCI DSS it is necessary to conduct a quarterly external vulnerability scan of ASV (Approved Scanning Vendor) information infrastructure components and an annual SAQ self-assessment. In this case, the organization does not need to collect evidence of compliance, since this is not necessary for the current level. The completed SAQ self-assessment sheet will be the reporting document.

ASV scanning (Approved Scanning Vendor)— automated checking of all points of connection of the information infrastructure to the Internet in order to identify vulnerabilities. PCI DSS requires that this procedure be performed on a quarterly basis.

Or consider the example of a cloud service provider that processes over 300,000 transactions per year. According to the established classification Visa or master card, the service provider will be classified as level 1. This means that, as indicated in Figure 2, it is necessary to conduct a quarterly external vulnerability scan of ASV information infrastructure components, as well as an external annual QSA audit.

It should be noted that the bank participating in the process of accepting payment cards for payment for goods or services, the so-called acquiring bank, as well as international payment systems (IPS ) can override the level of the merchant connected to them or the service provider used according to their own assessment risks. The assigned level will take precedence over the classification of the international payment system indicated in Figure 2.

Any objective and meaningful penetration testing must
be carried out in accordance with the recommendations and rules. At least to be
a competent specialist and not to miss anything. So if you want to tie your
professional activity with pentest - be sure to familiarize yourself with
standards. And first of all - with my article.

The rules and framework of information penetration testing are presented in the methodologies
OSSTMM And OWASP. Subsequently, the obtained data can be easily
adapted for conformity assessment with any industrial
standards and "best world practices" such as, Cobit,
series standards ISO/IEC 2700x, recommendations CIS/SANS/NIST/etc
and - in our case - the standard PCI DSS.

Of course, the accumulated data obtained during testing on
penetration, to conduct a full assessment according to industry standards
won't be enough. But that's why it's a pentest, not an audit. In addition, for
implementation of such an assessment in full, only technological data on
anyone will not be enough. For a full assessment, interviews of employees are required.
various divisions of the company being valued, analysis of the administrative
documentation, various IT/IS processes and much more.

Regarding penetration testing as required
standard for information security in the payment card industry - it is not much
differs from conventional testing conducted using methods
OSSTMM And OWASP. Moreover, the standard PCI DSS recommended
To follow the rules OWASP when conducting both pentest (AsV) and
audit (QSA).

The main differences between testing PCI DSS from testing to
penetration in the broad sense of the word are as follows:

1. The standard does not regulate (and therefore is not required) to carry out attacks with
   using social engineering.
2. All checks carried out should minimize the threat of "Refusal
   Service (DoS). Therefore, the testing should be
   carried out by the "grey box" method with a mandatory warning
   respective system administrators.
3. The main purpose of such testing is an attempt to implement
   unauthorized access to payment card data (PAN, Cardholder Name and
   etc.).

The "gray box" method refers to the implementation of various
kind of checks with preliminary receipt of additional information about
the system under study at different stages of testing. This reduces the risk
denial of service when carrying out such work in relation to information
resources operating 24/7.

In general, PCI penetration testing should
meet the following criteria:

• Clause 11.1(b) – Wireless network security analysis
• Clause 11.2 - Scanning the information network for vulnerabilities (AsV)
• 11.3.1 - Carrying out checks at the network layer (Network-layer
  penetration tests)
• Clause 11.3.2 - Carrying out checks at the application level (Application-layer
  penetration tests)

This ends the theory and we move on to practice.

Determining the boundaries of the ongoing research

First of all, you need to understand the boundaries of penetration testing,
determine and agree on the sequence of actions to be performed. At its best
In this case, the IS department may obtain a network map on which
schematically shows how the processing center interacts with the general
infrastructure. At worst, you will have to communicate with the system administrator,
who is aware of his own jambs and obtaining comprehensive data on
information system will be hampered by his unwillingness to share his
unique (or not so - approx. Forb) knowledge. One way or another, in order to
PCI DSS Pentest requires at least the following information:

• network segmentation (user, technological, DMZ, processing and
  etc.);
• firewall at subnet boundaries (ACL/ITU);
• used Web applications and DBMS (both test and productive);
• used wireless networks;
• any security details that need to be taken into account in
  during the course of the survey (for example, blocking accounts at N
  incorrect authentication attempts), infrastructure specifics, and general
  wishes for testing.

With all the necessary information listed above, you can
organize your temporary shelter in the most optimal network segment and
start examining information system.

Network-layer penetration tests

To begin with, it is worth analyzing the network traffic passing by using
any network analyzer in the "promiscuous" mode of the network card
(promiscuous mode). As a network analyzer for similar purposes
great fit or CommView. This step will take 1-2 hours to complete.
sniffer. After this time, enough data will be accumulated to carry out
analysis of intercepted traffic. And first of all, when analyzing it, one should
pay attention to the following protocols:

• switching protocols (STP, DTP, etc.);
• routing protocols (RIP, EIGRP, etc.);
• dynamic host configuration protocols (DHCP, BOOTP);
• open protocols (telnet, rlogin, etc.).

As for open protocols, the likelihood that they will fall into
the sniffing time of passing traffic in a switched network is quite small.
However, if there is a lot of such traffic, then in the network under study there are clearly observed
problems in the settings of network equipment.

In all other cases, there is the possibility of carrying out beautiful attacks:

• classic MITM (Man in the middle) attack in the case when
  DHCP, RIP
• obtaining the role of the STP root node (Root Bridge), which allows
  intercept traffic of neighboring segments
• switching the port to trunk mode using DTP (enable trunking);
  allows you to intercept all traffic of your segment
• and etc.

A wonderful tool is available to implement attacks on switching protocols
Yersinia. Suppose that in the process of traffic analysis, flying
past DTP packets (see screenshot). Then sending a DTP ACCESS/DESIRABLE packet
may allow the switch port to be set to trunk mode. Further
the development of this attack allows you to listen to your segment.

After testing the link layer, it is worth switching attention to the third
OSI layer. The turn has come to the ARP-poisoning attack. Everything is simple here.
Choose a tool, for example,

and discuss with the IS employees the details of this attack (including
the need for an attack aimed at intercepting one-way SSL).
The thing is that in the case of a successful implementation of the ARP-poisoning attack against
of its entire segment, a situation may arise when the attacker's computer does not
cope with the flow of incoming data and, ultimately, it can become
cause a denial of service for an entire network segment. Therefore, the most correct
will select single targets, such as admin workstations and/or
developers, any specific servers (possibly a domain controller,
DBMS, terminal server, etc).

A successful ARP-poisoning attack allows you to get in the clear
passwords to various information resources - DBMS, domain catalog (with
NTLM authentication downgrade), SNMP-community string, etc. Less than
luckily, hash values ​​can be obtained from passwords to various systems,
which will need to be restored during the pentest by
rainbow tables (rainbow tables), by dictionary or by attack "on the forehead". intercepted
passwords can be used somewhere else, and subsequently this is also needed
confirm or deny.

In addition, it is worth analyzing all intercepted traffic for the presence
CAV2/CVC2/CVV2/CID/PIN transmitted in the clear. For this you can skip
saved cap file via NetResident and/or
.
The second, by the way, is great for analyzing the accumulated traffic in general.

Application-layer penetration tests

Let's move on to the fourth OSI layer. Here, first of all, it all comes down to
instrumental scanning of the surveyed network. How to carry it out? The choice is wrong
too big. The initial scan can be done using Nmap in
"Fast scan" mode (switches -F -T Aggressive|Insane), and in the following steps
testing to scan on specific ports (switch -p), for example,
in cases of detection of the most probable penetration vectors associated with
vulnerabilities in certain network services. In parallel, it is worth running the scanner
security - Nessus or XSpider (the latter will have shabby results) in
the mode of performing only safe checks. When scanning for
vulnerabilities, it is also necessary to pay attention to the presence of outdated systems
(for example, Windows NT 4.0), because the PCI standard prohibits them
use in the processing of cardholder data.

It is not worth it, when a critical vulnerability is found in any service, immediately
rush to exploit it. Correct approach when testing over PCI -
this, firstly, to get a more complete picture of the state of security of the subject
system (is this vulnerability random or is it ubiquitous),
and secondly, to coordinate their actions to exploit the identified vulnerabilities in
certain systems.

The results of the instrumental examination should be the overall picture
implemented IS processes and a superficial understanding of the state of security
infrastructure. During the development of scans, you can ask to familiarize yourself with
the information security policy used by the Company. For general self-development :).

The next stage is the choice of targets for penetration. At this stage, you should
analyze all the collected information obtained during listening
traffic and vulnerability scanning. Probably by this time there will be
trace vulnerable or potentially vulnerable systems. Therefore, it came
time to take advantage of these shortcomings.

As practice shows, the work takes place in the following three areas.

1. Exploitation of vulnerabilities in network services

In the distant past, there is a time when exploitation was the lot of the elite,
able to at least assemble someone else's code and (oh my God!) prepare their own shellcode.
Now the exploitation of vulnerabilities in network services, such as overflow
buffers and others like them, available to everyone. Moreover, the process is more and more like
quest game. Take at least Core Impact, in which the entire pentest is reduced
to clicking on various drop-down menus in a nice GUI wrapper.
Such a toolkit saves a lot of time, which during internal pentesting
not so much. Because jokes are jokes, and the feature set implemented in Core Impact,
allows, without particularly bothering, to consistently perform operation, lifting
privileges, collecting information and removing traces of your stay in the system. IN
Therefore, Core Impact is especially popular with Western auditors and
pentesters.

Of the public tools of this kind, the following can be mentioned.
assemblies: Core Impact, CANVAS, SAINTexploit and everyone's favorite Metasploit Framework.
As for the first three, these are all commercial products. True, some
old versions of commercial assemblies leaked to the Internet at one time. If desired
you can find them on the global network (naturally, solely for the purpose of
self-education). Well, all the free fresh sploit is available in Metasploit
framework. Of course, there are zero-day builds, but this is completely different money.
In addition, there is a controversial opinion that when conducting a pentest, their use
is not entirely fair.

Based on the network scan data, you can play a little hacker :).
Having previously agreed on the list of targets, carry out the operation of the detected
vulnerabilities, and then perform a superficial local audit of captured systems.
Information collected on vulnerable systems can improve
privileges on other network resources. That is, if during the attack
you corrupted Windows, then it would not be superfluous to remove the SAM database from it (fgdump) for
subsequent password recovery, as well as LSA secrets (Cain & Abel), in which
can often be kept open for a long time useful information. By the way,
after all the work has been done, the collected information about passwords can be regarded as
context of compliance or non-compliance with the requirements of the PCI DSS standard (clause 2.1,
2.1.1, 6.3.5, 6.3.6, 8.4, 8.5.x).

2. Analysis of access control

Analysis of access control must be performed on all information
resources on which it was possible to implement NSD. And on file shares
Windows (SMB), on which anonymous access is open - too. This often allows
obtain additional information about resources that were not discovered in
network scanning time, or stumble upon other information, various
the degree of confidentiality stored in the clear. As I already said, at
conducting PCI testing, first of all, the search is aimed at detecting
cardholder data. Therefore, it is important to understand what this data might look like and
look for them in all information resources for which there is an appropriate
access.

3. Brute force attack

It is necessary, at a minimum, to check defaults and simple login-password combinations.
Such checks need to be carried out, first of all, in relation to the network
equipment (including for SNMP) and remote administration interfaces.
When performing an AsV scan over PCI DSS, it is not allowed to carry out "heavy"
brute force, which can lead to a DoS condition. But in our case it is
about the internal PCI pentest, and therefore, in a reasonable form and without fanaticism, it costs
to carry out an attack on the selection of simple combinations of passwords to various
information resources (DBMS, WEB, OS, etc.).

The next step is to analyze the security of Web applications. During PCI pentest
about the deep analysis of Web speech does not go. Let's leave that to the QSAs. Here
it is enough to carry out a blackbox scan with selective verification
exploitable server/client-side vulnerabilities. In addition to those already mentioned
security scanners, you can use scanners tailored for analysis
Web. The ideal solution is definitely HP WebInspect or
(which, by the way, is excellent at detecting bugs in AJAX). But all this is
expensive and unaffordable luxury, and if so, then w3af will suit us, which in
recently gaining momentum in terms of detection of various kinds
vulnerabilities in web applications.

Regarding manual verification of vulnerabilities in the Web! It is necessary at least
check the mechanisms of authentication and authorization, the use of simple
login-password combinations, defaults, and everyone's favorite SQL injections,
including files and executing commands on the server. As for the client-side
vulnerabilities, then, in addition to verifying the possibility of exploiting a vulnerability, here
nothing more is required. But with the server-side, you need to tinker a bit,
because it's still a pentest, albeit according to PCI DSS. As I noted earlier, we are looking for PAN,
Cardholder Name and CVC2/CVV2 optional. Most likely, such data
are contained in the DBMS, and therefore, if an SQL injection is found, it is worth evaluating the names
tables, columns; it is desirable to make several test samples in order to
confirm or deny the presence of such data in the database in
in unencrypted form. If you encounter Blind SQL injection, it is better to incite
to the web server (with
--dump-all key), which currently works with MySQL, Oracle,
PostgreSQL and Microsoft SQL Server. This data will be sufficient to demonstrate
exploiting the vulnerability.

The next step is to analyze the security of the DBMS. Again, there is a great
tool - AppDetective from "Application Security Inc.", but it's expensive
pleasure. Unfortunately, a similar security scanner that would issue
as much information as AppDetective can, and supported the same
DBMS does not currently exist. And that's why you have to take on board
many separate, unrelated products that are sharpened under
work with certain vendors. So, for the oracle, the minimum set
pentester will be as follows:

• Oracle Database Client - an environment for working with DBMS
• Toad for Oracle - client for working with PL/SQL
• Oracle Assessment Kit - brute force users and database SIDs
• various PL/SQL scripts (for example, a configuration audit or
  the ability to go down to the level of execution of OS commands)

The final stage of PCI penetration testing is the analysis
the security of wireless networks, or rather, not even analysis, but the search for access points,
using vulnerable configurations such as Open AP, WEP, and WPA/PSK. With another
On the other hand, the PCI standard does not prohibit more in-depth analysis, including
with recovery keys for connecting to a wireless network. Because it makes sense
carry out this kind of work. The main tool at this stage,
of course there will be aircrack-ng. Additionally, you can carry out an attack aimed at
wireless clients, known as "Caffe Latte", using the same
tool. When conducting a survey of wireless networks, you can safely
be guided by data from the site
wirelessdefence.org.

Instead of a conclusion

Based on the test results, an analysis of all the collected information is carried out in
context of compliance technical requirements PCI DSS standard. And as I already
noted at the very beginning, in the same way, the data obtained during the pentest can be
interpreted in the context of any other high-level document,
containing technical criteria and recommendations for the management system
information security. Regarding the template used for reporting
PCI documents, you can use MasterCard's requirements for the PCI
AsV scanning. They provide for the division of the report into two documents -
top-level document for the manager, which contains beautiful graphs
and the percentage of compliance of the current state of the system with the requirements of PCI DSS is indicated,
and a technical document containing a protocol of testing performed on
penetration, identified and exploited vulnerabilities, as well as recommendations for
bringing the information system in line with the requirements of MasterCard.
I can therefore say goodbye and wish you good luck in your research!

www

pcisecuritystandards.org - PCI Security Standards Council.
pcisecurity.ru - portal,
dedicated to PCI DSS from Informzaschita.
pcidss.ru is a portal dedicated to
PCI DSS from Digital Security.
isecom.org/osstmm - Open
Source Security Testing Methodology Manual.
owasp.org - Open Web Application
security project.

Payment Card Industry Data Security Standard (PCI DSS) is a payment card industry data security standard developed by the Payment Card Industry Security Standards Council (PCI SSC), established by the international payment systems Visa, MasterCard, American Express, JCB and Discover.

PCI DSS requirements are mandatory for any company working with the largest payment systems. They guarantee protection against theft of client information and other fraudulent transactions. Infrastructure analysis carried out as part of certification reflects the degree of protection of the system processes where information about cardholders is stored, processed and transmitted.

PCI DSS VERSION 3.2, 2018

Maxim Sapronov, CTO of Avito: “Avito is one of the largest IT companies, our activities involve the storage and processing of large amounts of data. We strive to provide our customers with uninterrupted service high level, which requires a high-quality IT infrastructure. Avito has been placing its equipment in the DataSpace data center for several years now, we are confident in its reliability, excellent technical equipment and, most importantly, safety. Successful certification for compliance with the data security standard once again underlines the high qualification of the center and confirms our right choice of DataSpace as a reliable partner.”

PCI DSS VERSION 3.1

Arsen Kondakhchan, Head of IT Department at BPC Banking Technologies, noted: "For us, as a processing center, this certification is very important, as it simplifies our own certification, and also confirms that DataSpace is a serious and responsible partner who thinks about the needs of customers."