Author: pkfavantedge (Page 25 of 37)

Get Ready for PCI-DSS version 3.2

PCI Council released in the December 2015 bulletin, extending the deadline for Secure Sockets Layer (SSL)/early Transport Layer Security (TLS) migration. Recently, the PCI Council announced it would publish a new version of the PCI Data Security Standard (PCI DSS) in early 2016 to include the revised migration dates and address changes in the threat and payment acceptance landscape.

PCI Council’s Chief Technology Officer Troy Leach talks on what to expect with the release of PCI DSS 3.2 and how organizations can start planning for it now.

Excerpt taken from the PCI Perspective Blog:

When will PCI DSS version 3.2 be released?

Troy Leach:
  The Council will publish the revision in the first half of 2016 – we are aiming for the March/April timeframe. We will keep stakeholders informed as we move closer to that date.

Based on what you’re saying, there is no expectation of a PCI DSS release in November 2016?

Troy Leach:
That’s correct. We are not planning any additional releases of PCI DSS during 2016. The version 3.2 release in the first half of 2016 replaces the expected fourth quarter 2016 release.

What changes are expected?

Troy Leach:
When making changes to the standard, in addition to market feedback, we look closely at the threat landscape, and specifically what we are seeing in breach forensics reports as the trending attacks causing compromises. With this in mind, for 3.2 we are evaluating additional multi-factor authentication for administrators within a Cardholder Data Environment (CDE); incorporating some of the Designated Entities Supplemental Validation (DESV) criteria for service providers; clarifying masking criteria for primary account numbers (PAN) when displayed; and including the updated migration dates for SSL/early TLS that were published in December 2015.

How long will organizations have to move over to PCI DSS 3.2?

Troy Leach:
As usual, there will be a transition period, and we will keep everyone informed as we approach publication. Version 3.2 will become effective as soon as it’s published, and version 3.1 will be retired three months later to allow organizations to complete PCI DSS v3.1 assessments already under way. Keep in mind, though, that new requirements always have a sunrise date prior to them being effective. This allows organizations to plan accordingly prior to validating to new PCI DSS requirements. The new requirements will be considered best practices for a sunrise period to be determined based on the release date.

As a reminder, the SSL/early TLS updates in PCI DSS v3.2 are those made public in December. Organizations can and should already be addressing this issue, starting with reviewing the Bulletin on Migrating from SSL and Early TLS  now for more information on where to begin with migration and taking advantage of the guidance and resources outlined.

Enter The Monkey

To all our readers,

PKF Avant Edge wishes all of you a very prosperous Chinese New Year!

Every year, every business everywhere in this region grinds to a halt, this year being even worse than normal. Most times, we have the first four days of the new year cutting across the weekends. This year is the perfect storm. The Chinese New Year starts on a Monday.

This means for the first four days at least until Thursday, businesses won’t open. The fifth day, Friday is considered the wealth day, so some traditional businesses may open, but I don’t expect anyone to be closing huge sales. It would probably be more like a 3 hour lunch time kind of thing. Then it would be weekend, and after that, people will start dragging into the offices the following Monday.

For businesses like ours, we all know and concede that February is almost like a flat month. Not much sales, not much activities, and A LOT of holidays. But after this, the new year begins, and we are looking forward to the year of the Monkey. Yes, we expect enormous challenges especially in terms of ongoing projects and getting new ones, but everyone is in the same boat. With the continuing currency crisis and ongoing impasse in our government dealing with accusations of corruption, we are certainly at the crossroads in 2016 not just politically, but socioeconomically as well.

But enough of the harangue, let’s for the next few days put work and worries aside and look forward to a time with the young ones, family and the giving and receiving of Ang Pows!

Gong Xi Fa Chai!

 

ASV scans – who needs it?

One of the often asked questions we face after dealing with PCI-DSS (Payment Card Industry Data Security Standards) for the past 5 years is also often the simplest. Who needs to do ASV scan?

ASV stands for Approved Scanning Vendors. These are the guys that has been approved to do public scans for PCI clients, by the PCI-SSC (that’s like the Jedi council made up of Master Card and his minions.) Anyway, the ASV scans apply only on external facing IP addresses IN SCOPE.

This is very confusing, because often, our clients will give us a small set of IP, or either a gargantuan set of IPs like 10.x.x.x (yes, that’s an internal zone, so that’s where the education begins), or some give us their entire C class of their ISP.

Technically, the scope is defined by the merchants or service provider (NOT the ASV or QSA). However, if you are undergoing a full PCI program, we will obviously have more knowledge on your network and we can help you define your scope appropriately. Else, if you are a cold call ASV client, we will generally rely on your scan scope provided to us and scan those IP or IP ranges. We prefer you to provide us a set of IP host address, although we can technically do a network range, but the pricing might vary more.

So who needs to do it?

Anyone undergoing PCI.

Who has a public IP address. This includes not just servers, but routers, VPNs, network devices and even POS devices. If you are an ecommerce company, then you will likely have public IP address. If you are a retailer and using IP based POS, then these need to be included. If you have DNS, mail servers that belong to you, then those need to be included.

Whether you are a level 1 merchant or a level 4 merchant, whether you are a level 1 or 2 service provider – you need the ASV scan. The only companies that don’t require it are companies who have no internet capability. This is rare, but lets say a mom and pop grocery store who uses dial up POS provided by the acquirer or a knuckle buster.

Else, if you are undergoing PCI, you best get ready for the ASV scan.

So to summarise the process:

a) Define which addresses are in scope and are PUBLICLY assessible. His includes any IPs that are filtered by firewall.

b) Provide these IPs to the ASV vendor and the ASV will provide a range of source IPs to whitelist. We get some questions: why do we need to whitelist? Why can’t you guys just do the testing without whitelisting? Because ASV scans are not expensive, and we need to get it done fast, so we generally don’t have time to 100% simulate a slow burn attack that most actual attacks might face, who can afford to do that because they are not charging you and they are actually trying to get in.

c) Allow the ASV to do their job. We often get clients giving us like 20 IP addresses, ask us to scan and n half a day demand for a report. Here is the difference between those peddling free unlimited ASV scans vs actual ASV scans = the free unlimited scans do not come with manual verification of findings. So you get say 40 vulnerabilities listed in a colorful chart – you generally need to go through these 40 and address them one by one (whether its an actual vulnerability of not!). For us, we take a few days to plow through the vulnerabilities and remove the false positives by doing a manual verification process, which might include manually checking if, say the system is actually providing an actual information, or it could just be a fingerprinting of OS that got screwed up. That way, we can hash that 40 down to say 10 or less, and makes it less of a chore for you. So beware of ‘Free’ ASV. Nothing in life is Free. Except sunlight and air. And that too is being charged in some countries.

d) Once its done, we release a preliminary report and go through with you what needs to be done. Generally all medium – high issues need to be addressed. In most cases we see are SSL related issues. If it is, good news is that you can move your mitigation plan to June 2018 and buy some grace period. All we require is a formal mitigation plan and we will pass the ASV.

e) ASV needs to be done every quarter.So technically, your ASV report has an expiry (of 3 months from the scanned date). But in some instances, ASV providers such as Control Case allows you to define the quarter in a more precise term. The moment the PO arrives to us, we start counting the quarter. For instance, if it starts today (say date X), then the first quarter will end 3 months from today (say, date Y). You can scan at ANY time in this quarter and it will be good up to the date of Y. So technically, you can scan right at the end of the first quarter (pass Q1) and immediately when you go into Q2, start scanning for Q2. Depending on your ASV provider, your mileage may vary but we’ve worked with a few before and it seems to be a pretty consistent interpretation of quarters.

The ASV scan is by far, one of the least complicated things in PCI. However, don’t underestimate the effort. We had clients who thought one week was plenty enough to do ASV and they missed their quarter scan because we need CLEAN results. If we cannot get clean results (all medium-high issues solved), we cannot pass the ASV. If we cannot pass within the deadline, you miss your Quarter and there is no turning back. It will cause you to have  problem when you re-certify for the coming year for PCI-DSS.

Good luck, and start early!

Alienvault Update: Setting Up Logging

I know we sort of touched on this a few weeks back, but due to the new updates, we will need to revisit this again.

First of all, AlienVault can collect logs in a variety of ways:

a) Device sends logs = this is a classic syslog server set up. Previously we had to go through the rustic rsyslog set up etc in order to get the systems to talk to us. Not anymore. With the new updates, AV sets up easier, faster and less typing needed.

b) AV collects logs = there are several ways AV does that. One is through database plugins, where AV talks direct to the database and gets information from tables. Another way is through Windows Management Istrumentation (WMI), Security device event exchange (SDEE for CISCO).

c) AV collects through HIDS (where you install host intrusion agent for windows and LINUX)

We are going to explore the normal ways which is through a) and c). The B) method is a little advanced and we’ll look at it separately.

For basic logging, get your device to first send logs over to AV.

You will find it hard to believe, but this can be fantastically difficult, especially if your client is not up to par in terms of technicality. One example is that they are not even knowledgeable of their own network. Usually we do just a packet inspection on our interface and if I don’t see stuff coming in from your device, I handoff to you.

Except we don’t.

In PKF Avant Edge, we take responsibility even when it’s clearly NOT our responsibility. It’s silly but unfortunately it’s in our DNA to solve problems even if its not ours.

We have some experience where we troubleshoot for our clients up to firewall policies to be enabled, routing to be enabled etc. if I get 1RM everytime I hear a client say, “No firewall, no ACL! There is no filtering, problem is on your side”, I will be a millionaire. No kidding. It helps that our background is in NOC (network operations centre), so we don’t get bullied too often by network admins.

Once AV receives the logs, all we need to do is to go to ASSET -> Detail and in the tab ‘Plugins’, click on it and select the plugin to enable. Once done, your system is being monitored automatically. There should be a ‘receiving’ under the plugin. To be sure, you can go to command line and type avdevicelog (assuming you’ve put in the alias as suggested in previous post) and you should see a folder with the IP addresses of the systems you are receiving logs in. Go to the folder and just tail -f the file there.

If you see ‘No’ under the receiving data, don’t worry. AV sometimes gets confused as well. Just check the actual logs if it’s in there. Furthermore, go to avagentlog and cat agent.log | grep <pluginid>. You should see quite a fair bit of things here. For instance:

Oct 14 08:48:52 VirtualUSMAllInOne ossim-agent: Alienvault-Agent[INFO]: Plugin[1686] Total lines [14457] TotalEvents:[14457] EPS: [0.00] elapsed [10.01] seconds

This shows that Alienvault is seeing a total lines 14,457 and processing these as events. It means its working.

For an idea where its mapping, go to /etc/ossim/agent and more config.yml. You should see the device-log file mapping for example

– /etc/ossim/agent/plugins/vmware-esxi.cfg:
DEFAULT: {device: 192.168.0.38, device_id: 29b1cd29-70ac-11e5-a5e9-000c93c2e358}
config: {location: /var/log/alienvault/devices/192.168.0.38/192.168.0.38.log}

If you see logs coming in but no events, remember – Logs become events become alarms.

That probably would mean your plugin isn’t interpreting the logs properly, and it’s time to dive into creating a plugin or modifying a plugin.

We recommend to copy the plugin and create a new plugin altogether.

For instance, when our Juniper logs had additional dates in there due to an intermediate logger, we created a new plugin, but used the old Juniper plugin and just changed the regex to handle the new fields and it worked terrifically.

Remember a new plugin also requires a new corresponding SQL file, which are found in avsql (if you use the alias we suggested).

Writing plugins is another article. For now, you have successfully set AV up to receive logs, create events and create alarms. No need to set up rsyslog command line anymore and no need to enable those plugins through the alienvault-setup menu. Just go asset->Details->Plugins and you are good to go!

« Older posts Newer posts »

© 2025 PKF AvantEdge

Up ↑