PCI Moscow - 2009

Presentation from PCI Moscow.

Sergey Gordeychik, Security Metrics for PCI DSS Compliance

View more documents from qqlan.

Compliance management vs Risk management

If we consider the question of request compliance in terms of risk analysis, i.e. assume that:
threat – violation consequences described by the compliance enforcement agency (CEA :).

vulnerability – incompliant to requirements
attack – checks made by the CEA
counter-measure - compliant to requirements

so there is practically an unexampled situation – we have all necessary basic data for quantitative risk analysis based on the classical technique ARO x SLE = ALE.

http://www.windowsecurity.com/articles/Risk_Assessment_and_Threat_Identification.html

We have:

ARO – probability of CEA checks
SLE - violation consequences described by the law or CEA

This interesting situation not only proves that school rules still sometimes work, but also a great benefit of compliance as an engine of information security.

Lets consider some examples that are now widely known - Russian Federal Law 152 (On Personal Data) and PCI DSS.

PCI DSS

This is quite simple, as Visa and other payment systems decided not to taunt business and allow to shift action plan because of events in the world economy now. This is a delay in attack implementation in several years. Unexampled situation when you exactly know that this particular attack did not take place during a year. Or a couple of years. Just imagine a license from virus attacks or hardware theft for a year… A great thing!

So:

threat - fines (N x K$) or loss of operation prohibition (let it be also N x K$ for ease), SLE;
vulnerability - incompliant to requirements (PCI DSS);
attack – CEA (Visa, Mastercard, etc) response to action plan deviation (the probability that it will take place, ALE - 0 times a year)

Totally, we have:

Risk = (N x K$) x (0) = 0

Tat is that you can do nothing!!!

But! The key condition is that you have action plan. Accordingly, you should create it. By yourself or with QSA – as you wish. Unfortunately I do not have information about regulator response if there is no PCI DSS action plan, but I think in this case SLE is about counter-measure (audit) costs.

Federal Law 152

In this case everything is easy also.

threat - some variants

1. Administrative responsibility - fines
2. Suspension or termination of personal data processing in the company is the period of idle time/degradation of constrained business processes before elimination. I think you can take minimum 1/6 of a year.
3. Company and (or) its head is made responsible for criminal (civil, disciplinary, etc.) offence -– a catastrophe.
4. Licenses suspension or revocation for the company basic activity – closer to catastrophe in the current situation.

attack – check by CEA

With regard to newness and interest for regulator and the possibility of initiation from the outside (an application), the probability that the attack will be conducted in 2010 could be taken equal to 1.
For more detailed calculations by regions and business brunches the following statistics could be used:

http://community.livejournal.com/personal_data/721.html

Totally, we have (worse case scenario):

Risk = (the value of business) x (1) = (the value of business)

That is: there is a problem, and you have to solve it.

PS. There is no need to make far-reaching conclusions. It‘s just a funny story. We didn't sell FL-152 consulting :)

Microsoft has published regular Security Intelligence Report.

Russia is among leaders by infected computers percentage:
The infection metrics is about 21,1 for 1000 runs of "cleaner" , an world average index is 8,6. A very strange index.



It is possible that the index is strongly concerned with a possibility to infect different platforms:



I think nobody is surprised that a lot of home users with XP SP0, SP1 are afraid to update it because they are should that their cracked Windows versions will not further work. But will they have Malicious Software Removal Tool? Will a “master” bring on a floppy disk? Rather, something from Kaspersky or DrWeb.

This is a very strange situation. Can it really be corporate employees ?

PS. Actually this is a wonderful report.
The most common threat in Russia – Taterf which is spread through shared folders, in USA - Win32/Renos and Win32/Zlob. There are a lot data about Conficker in the report, but it is missed in statistics first lines.

Is it a wonder?

Risks, risks, risks

I came across with vulnerabilities in UTM device management web interface during security analysis recently. Rather typical combination of CSRF and XSS is interesting because it allows attackers to get access to device command line and manage the system interactively in administrator’s browser. But this is not the whole point, the vulnerability is typicaly.
The most interesting (as always) was communication with the vendor. We did not agree about the vulnerability risk level that led to desperate correspondence. Here I would like to share with you our ideas in this field.
As a rule, risk level is set by software vendor or by a company that produces protection tools (vulnerability scanners, intrusion detection systems, etc.). In this case typical scheme similar to road regulations is used: low risk level (green), medium risk level (yellow), high risk level (red). Sometimes an additional 4^th level is used – level of critical vulnerabilities.
Many producers use this approach, for example, Microsoft uses 4 vulnerability risk levels in its security bulletins.
But ‘traffic lights’ model is not transparent and greatly depends on expert world view and general state and other factors. That’s why we use CVSSv2 methodology.

English

http://www.first.org/cvss/cvss-guide.html

Russian
http://www.securitylab.ru/analytics/355336.php
http://www.securitylab.ru/analytics/356476.php

Rather simple metrics on which CVSSv2 is based allows assessing risks more or less definitely. In addition, the metrics allows assessing several additional factors as exploitation possibility and environment that is very important.
Quotation (Russian):

Leaving aside advantages and disadvantages of the methods, the following characteristics could affect the assessment reliability:

1. Context dependence;
2. System configuration dependence;
3. Assessment method dependence.

Vulnerabilities of the same type could be of different risk level in different applications. For example, CSRF vulnerability could not be a threat for typical representation server or search engine, but is a critical vulnerability for e-mail or payment system web interface. As a result of information leakage, an attacker could access application logs (low or medium risk level) or download the backup copy of the site (high risk level).

The system configuration could also affect the risk level. Thus, “SQL Injection” vulnerability is usually classified as a high risk level vulnerability. But if web application has restricted rights on DB server, it is a vulnerability of medium or low risk level. In another installation or implementation the same vulnerability could be used to access operating system with superuser rights that makes the vulnerability critical.

Assessment methods greatly affect vulnerability risk level. For the above example, a network scanner could just detect “SQL Injection” as a problem. To determine the available for potential attackers privileges one should try to use the vulnerability or get detailed information about communications between web application and DB server via white box method.

So it is absolutely incorrect to give to different vulnerabilities of the same type equal risk levels without detailed analysis (for example, SQL Injection).

Here is an example.

Let’s assume that SQL Injection allows to get access to DBMS with minimum web server privileges, for example, db_reader. And web application does not store confidential data (for example, passwords) in DBMS.

So CVSSv2 vector and risk level are:

(AV:N/AC:L/Au:N/C:P/I:N/A:P/E:H/RL:W/RC:C) = 6.1

In the other case, if user passwords are stored in DBMS (including administrator password), risk level is higher as the system is more vulnerable to attacks according to data confidentiality.

(AV:N/AC:L/Au:N/C:C/I:N/A:P/E:H/RL:W/RC:C)= 8.1

If web server has unreasonably extended privileges on DB server, for example, sa privileges, the same vulnerability is much more dangerous:

(AV:N/AC:L/Au:N/C:C/I:C/A:C/E:H/RL:W/RC:C) = 9.5

It we reduce it into “traffic lights” model or PCI DSS 5 levels (Urgent, Critical, High, Medium, Low), the result is:

1. Medium (2) and High (3)
2. Medium (2) and Critical (4)
3. High (3) and Urgent (>4).

It means that vulnerability risk level could vary greatly depending on the system and its settings.

CVSSv2 vector for XSS (see description above at the beginning of the note)

(AV:N/AC:H/Au:N/C:C/I:C/A:C/E:F/RL:W/RC:C) = 6.9

So in terms of PCI DSS (it is this model that is the most popular now) the risk level of the issue is High or even Critical, but not Low. But in any case the audit is failed :))

PS. I can understand vendor’s reasons, as if security is not taken into account when the software is designed then (quotation) "hardening the management interface would probably imply a complete redesign of it".

Here it is – the various risk assessment.