Page 20 of 40

Alienvault Troubleshooting: The Missing Sensor

avlogo

USM Sensor not displayed properly at “AlienVault Center” of the USM Server

We have recently been involved in a few deployments of Alienvault. Aside from the All In Ones, we have had a few projects where separate sensor, loggers and servers were deployed, as well as even deploying USM Anywhere, Alienvault’s new flagship cloud centric product that literally makes Alienvault USM works – well – anywhere.

While the USM Anywhere deserves its own piece of article, in this short article we will explore the often seen problem we call: The Case of the Missing Sensor.

So, you have setup the standard server and sensor properly and as per the deployment guide that you find here. The configuration was well configured and the sensor peacefully connects to the USM Server. So you break open the celebratory glasses and start relaxing. You let your customer go through the whole features, absolutely confident that they will be impressed with everything you have done so far and they will be signing off the implementation sheet, and you will be paid and you will ….

“Hold on. Where is the sensor?”

Startled, you look at the screen and even though you have configured the server IP address in the sensor, you do not see any sensor under the Server’s Alienvault Center section. This makes it look like the sensor wasn’t  deployed but in fact all has been configured and accepted. If it didn’t show under AlienVault Center, you won’t be able to manage and update the sensor properly. Plus, it makes it look like you sold them a sensor but then ran away without actually installing one. Which makes you a charlatan. Which isn’t good.

So, you try the well tested “alienvault-reconfig” and cross your fingers. Do it on both server and sensor. No luck.

If you hit a brick wall on this, one method around it is to add the sensor manually into the server.  The below is the command used to fix it:

To add sensor into Server

#alienvault-api add_system --system-ip=[sensor's ip] --password=[sensor's root password]

Once you run the command, that doggone sensor should show up properly under the AlienVault Center and you look like a king in front of your customer. However, like all CLI commands, you need to make sure that if this is done on production, proper backup and proper due diligence has been done.

There is not much detail found but there is similar issue found at the Alienvault forum and the thread is a couple years old.

AlienVault Forum: https://www.alienvault.com/forums/discussion/1322/adding-sensors-to-the-alienvault-centre-display

We ratted on Amazon Web Services (and made them change!)

Just a funny post to include and which I was reminded of by a few of my clients asking this question:

“Can I put a logo on my website or in my marketing material to state I am PCI-DSS Certifed?”

Something similar to this, which we see all the time. It’s nice, it’s beautiful, it’s stately – it basically tells everyone that I have gone through hell and back.

PCI-DSS

Except. You can’t do that.

That is correct – you cannot put a logo like that on your website. Doing so will get you in trouble with the PCI-SSC, it’s basically infringing their copyright of their logo and they disallow it. Here is an article we wrote a while back that talks about this.

So what happened was, one of our clients insisted they can use it because they have seen it in AWS website. We took a snapshot of it and here it is

PCIAWS

You can see they have proudly displayed the Level 1 Service Provider logo of PCI-DSS ‘Compliant’ along with the nice and thoroughly aggrandizing ‘tick’ and an altogether unnecessary picture of a lock at the bottom. The only problem is that this logo is not endorsed by PCI-SSC and was probably created by their summer intern.

So we asked politely to PCI-SSC, why are you allowing AWS to use it and not our client? Is it because a certain Jeff Bezos is the most powerful man in the internet?

Their response was classic:

They are not allowed to use that logo. Unfortunately, we cannot police the entire internet, so we contact these firms as we learn of the logo use.

You are correct in your understanding of the article. We encourage you to refer your clients to this article when they question you.  And let them know we will be contacting this firm to have this logo removed.

We appreciate you bringing this to our attention.

Wow. That’s nice. The largest cloud provider in the entire known universe uses that logo and you cannot police it. This generally means, they don’t do any policing. At All.

I like the fact that they refer Amazon as ‘this firm’ as if AWS is some useless junk company in the outer fringes of Elbonia. I like that. It’s powerful.

So what happened? PCI-SSC like a chihuahua took on a T-rex and guess what? The T-Rex changed.

PCIAWS2

You can see now that the ugly ticked lock, illegal, summer intern designed logo is gone, replaced by another PCI logo. This time, this is a logo they can actually use because they are registered as a ‘participating organisation’. But nowhere in the logo does it state they are Level 1 certified Service provider.

We like to think, in our small and narrow mind, that we, an unknown security firm in the fringes of Malaysia AKA Elbonia to most of the world – made the mighty AWS change something on their website.

Such feeling of worthiness.

PCI-DSS Evidences: Your Type of Compliance

pci-compliance

Since our last post, we have received some queries on how do we get PCI-DSS started. A majority of our clients are doing Level 1 Certification – this is where we come in and do a gap assessment, determine scope and then remediate and certify. However, lately we have been seeing more and more clients looking to do PCI-DSS on their own.

The question is: Can they?

Well – as with many questions for PCI-DSS, the answer is: it depends.

You see, the journey to PCI-DSS is different for different companies. Some need to go through the whole road. Some goes through just a little. Some need a third party to audit, some can do their own assessment…so while the standard is ONE, the ways to achieve it is MANY.

Now, enough of the philosophical babbling. Simply put: if you are doing PCI-DSS, you simply have 3 available options:

a) Third Party Certification

b) Validated Self Assessment Questionnaire (SAQ)

c) Self Signed Self Assessment Questionnaire (SAQ)

That’s it. You will fall into one of these buckets. If you fall under b) or c), you will then further have to wade through the types of SAQs: A, A-EP, B, B-IP, C, C-VT, D-SP, D-Mer, P2PE. Yes. They have a lot. But in general, your consultant or QSA should be able to tell you which one is right for your business.

Now back to the buckets. What’s a third party? No, it’s not literally a third party that you go to after your graduation and you are getting smashed. In audit terms, there are 3 kinds of audit – first party which is where internal auditors of the company audit themselves. Second Party which is where an external company with ties to the auditee company audits the auditee company – for whatever reason. It could be a supplier audit, it could be a due diligence audit before takeover, it could be a regulator auditing its regulatee etc. Finally a third party is a completely independent organisation auditing the company.

So the first bucket is a third party certification. This is where an external company called a Qualified Security Assessor (QSA) assesses your company and provide a Report on Compliance. This is where they will ask you to do a gap assessment, assist you through the ‘remediation’ period, and do the certification. What a lot of people don’t know is that actually, Merchant Level 1 also has an option to do a first party audit. This means they need an ISA (Internal Security Assessor) in their organisation who is able to sign off on the ROC. Of course, getting an ISA certified is another story, and in most cases, many just take the QSA route.

The second bucket is a Validated SAQ. This will not apply to Level 1 Merchants or Level 1 Service providers, and this is available for Service Providers Level 2 or Merchants Level 2 and below. Basically this means that theoretically, you can complete the SAQ that is applicable to your company and sign off and you are ‘compliant’. This also means any Tom, Dick and Harry who thinks that a firewall constitute setting an actual office wall on fire, can sign off on 1.1.4 (a) which asks if a firewall is implemented in your company. Seriously though. That’s why Mastercard has this caveat:

“Effective 30 June 2012, Level 2 merchants that choose to complete an annual self-assessment questionnaire must ensure that staff engaged in the self-assessment attend PCI SSC ISA Training and pass the associated accreditation program annually in order to continue the option of self-assessment for compliance validation. Alternatively, Level 2 merchants may, at their own discretion, complete an annual onsite assessment conducted by a PCI SSC approved Qualified Security Assessor (QSA) rather than complete an annual self-assessment questionnaire.”

Many, including myself, find this caveat extremely frustrating. To cut the long story short, Mastercard is simply saying for all Level 2 merchants you have 2 routes:

a) Do the Level 1 route. Get a QSA

b) Do your SAQ, but get the staff ‘engaged in the self assessment’ to be ISA certified. Now the first confusion is staff engaged in self assessment does not mean everyone involved in the audit. It basically means the one doing the assessment in behalf of the organisation and signing off at the AoC (Attestation of Compliance) of the SAQ. Whew! But still, now you need to get an ISA. It’s not cheap! And it’s also, to me, a really silly certification, but one that makes total Sen$e to the PCI-SSC.

In theory, option b) above is correctly still called ‘Self Assessment’ as it is still a first party audit in that sense.

Now the last bucket therefore is the truest first party audit. This usually applies to only Level 3 or Level 4 merchant, but sometimes we still find this existing in Level 2 Service Provider. Where the management say, “Screw it, let me sign it off and I don’t need any other signature on this” and the bank, customer or card scheme accepts it.

So this is the first step of your compliance – find out your type. Because you could be overdoing it (Level 3 Merchant doing a ROC Certification) or you could be underdoing it (Level 1 Service Provider doing an SAQ D). If you overdo it, it’s fine from PCI-SSC perspective, but your boss/stakeholders/board/customers might not be too happy when you have spent half the company’s budget and 8 months on the PCI program doing a full Level 1 RoC on all the 340++ subrequirements – and the vacation trainee points out that you only have to do a self signed SAQ A which takes about 1 day to complete. If you under-do it, likewise, you might be in an awkward position to explain to someone that your SAQ D-SP is not enough to convince your acquirer to start connecting to them, as they need a QSA signed ROC.

So how do we know?

Well – the easiest is to really, ask the ones who are pushing you for PCI? If you get the answer : “Ah, just get compliant!”, then you have more leeway to understand your business, and you might be tempted to just go for the easy way out. Don’t! Assess your business – if you are a merchant, then follow the number of transactions to determine which level you are at. Easy remembering:= 6 million and above for level 1, 1 – 6 million for level 2 and the rest level 3 and 4. I don’t differentiate 3 and 4 because there doesn’t seem to be a squat a difference to what you are supposed to do. It’s the same, they just classify it differently where level 3 is focused on e-commerce and level 4 is more on traditional transactions.

For service provider, it’s simpler. Level 1 is above 300,000 volume of card transactions and level 2 is below. There is no other levels for Service Providers. There is also only SAQ D available for Service Providers so you don’t need to think so much.

The next round, we will explore deeper into how do we get our scoping questions sorted out.

 

Passing PCI-DSS: Evidence Checklist – Brief History

pci-compliance
We have been working on PCI-DSS since 2010. We started out as project managers for an offshore bank in Brunei that approached us asking for PCI-DSS compliance. At that point, we had invested a lot on training and getting our guys ISO27001 lead auditor certified because we saw a stable demand for compliance. We just banked on ISO and ISMS to kick off because of the directive of our government that all Critical National Information Infrastructure (CNII) needs to be ISMS certified. The reality though was slightly different. We pitched for jobs and saw precious few coming to us. Mostly, it went to agencies already incumbent, or agencies that knew how to get projects from government. We didn’t. We were new boys on the block and I remembered we were so desperate for business we drove all the way to Penang for a half hour meeting with a potential company only for them to say, Sorry we have already given the project away. Well, we did market that we had an office in Penang, so they probably thought we came to meet them from down the street. And not down the country.

In any case, in the middle of this desperate look for ISMS business, our customer in Brunei asked us for PCI-DSS. We didn’t really know anything about it, but we said, sure, let’s do it.

We called up some big QSA-Companies – Trustwave, Verizon being some of them. Verizon didn’t even bother responding to emails and calls. Trustwave did respond to my email – 5 months later. The only one that responded was a company called Control Case International. They called around 4 hours after I sent an email, and I was contacted not by their sales, but their founder, Kishor. He called me directly from the US and told me, let’s do this.

PCI is already a tough journey to begin with. We hear some QSA-C touting that it’s as simple as ABC. It’s not. And it’s not fair to say that it is because if it’s easy, everyone will be doing it. That’s not to say it’s impossible. With proper scoping, proper guidance, all companies can get certified with hopefully minimum fuss, stress and cost. Having local support and a responsive QSA is key. Local support doesn’t have to be a QSA. In fact, if possible, it might be even better to have non-QSAs and project specialists handling the local support. In our experience, QSAs are a busy lot and are often flying around on audits and working out other projects. Having a QSA handle your PCI initiative and remediation might not be the most efficient way as most meetings will be conducted either on a call or webex. PCI consultants are more than able to handle the remediation support because they are less caught up with ROC (Report on Compliance) writing and QA processes – which eat a significant amount of time for QSAs.

We successfully managed the Brunei project to certification and from there on, Control Case wanted to work with PKF for more Malaysian business. We started from zero clients to more than 30 plus clients today. Our goal is to push 50 by the end of this year. While we do work with Control Case, we remain independent as PKF does not have any influence over any report or opinion that Control Case has, and in almost all our projects, we work as project managers and technical advisors for our clients, not for Control Case.  In that way, we are not part of Control Case, or in any way represent or partner with them and even in some cases, we work with other QSAs to achieve the same results.

One of the key areas we work with the QSA and customer on is the evidence collection. Evidence is a key ingredient to your PCI success. We call it audit artefacts – proof that controls are in place. It might be a simple sample of change management tickets, or a more complex sample of 12 month logging of your database – in any case, these are the bedrock of your PCI journey. Without solid evidences that key controls are in place, passing the QSA’s Quality Assurance is going to be very difficult.

In the next few articles on PCI, we will share our evidence collection methodology, our 95 checklist of evidence and sampling on how to get these evidences sorted out for you to succeed in your PCI certification journey.

Personal Data Protection Act for Dong Zong

dongzong

To kickstart the New Year, we spent two full days with The United School Committees Associations of Malaysia for the Personal Data Protection Act training. Which is really a mouthful to say, so we will go by its more well known alias, Dong Zong.

Now, this is a rather unique engagement, for the simple fact that both our lead trainers in PDPA do not speak a lick of Mandarin. The first is proficient in Malay (as he is Malay), the second (which is me) is proficient in English – although he is technically a Chinese. While I am Chinese by birth, my proficiency in language is as follows: English, Malay, Cantonese, German, Minionese, Mandarin. That is to say, I can talk in German and Minionese far better than I can talk in Mandarin. For those who are wondering, Minionese is the official language used by the Minions, the yellow, annoying creatures that so love bananas and my sons so love watching.

Thankfully, we had another colleague who was proficient in Mandarin, but needed a bit of update on the subject, as he was from our technical deployment team for SIEM. So we had a bit of crash course for both. I had to do the introductions, demo and clarifications in broken mando-canto-eng-nese, and he had to crash course the updated PDPA training.

We can usually do the training quite comfortably, including the technical demonstrations (which consist of us actually searching for personal information on the internet during the training itself, demonstrating how easy it is if you know which tools and how/where to look). But this was made infinitely harder because of my lack of command in the language. To put it simply, it was like wrestling with a 300 pound catfish or a giant python. You know what to say in English, but the translation facility in your brain is broken and you just can’t get it out of your mouth and what ends up coming up is meaningless dribble, which my 2 year old son would probably appreciate, but not a roomful of teachers and educationists…who are championing the Mandarin language and the progressive advancement of the Chinese community as a whole. It would be great if I told them I was actually Middle Eastern or Eskimo, then they won’t expect so much from me – but I look like a total Chinese, so there’s no hiding the complete embarrassment of not being able to speak in Mandarin.

To Dong Zong’s credit, they did take it in stride, and our Mandarin-speaking colleague performed admirably (I think, since I did not understand him) and at the end of the two days, we were very well appreciated because somehow between the both of us, we got the job not just done, but done with great feedback and participation from the group. There were some really excellent Q and A time, which I had to answer in English/broken Cantonese and got translated properly. We even had a chance to go through Dong Zong’s implementation of PDPA and did a impromptu, live commentary on the areas to improve in privacy notice and other policies.

For a non-legal, practical way to implement and assess your company on PDPA, please drop us an email at avantedge@pkfmalaysia.com. We have done a lot of practical training on compliance to PDPA, and taken a lot of good info from the PDPA Commission itself. Our content is based on the one we developed with the deputy commissioner of PDPA during the time when we worked together to deliver our training to companies in Cyberjaya. Over the years we have enhanced it with demonstrations, as well as updated with the latest development of Malaysia’s Personal Data Protection Act.

« Older posts Newer posts »

© 2024 PKF AvantEdge

Up ↑