PKF AvantEdge

Month: October 2017

Alienvault: File Integrity Monitoring on Linux Part 1

October 31, 2017 / / 0 Comments

If you have been deploying or troubleshooting Alienvault long enough, you would know a few things: Alienvault is one of the most flexible SIEMs in the market. It has the most varied security features, and covers almost the entire spectrum of our PCI-DSS needs – from IDS, to SIEM, to File Integrity Monitoring, to vulnerability scaring to a partridge in a pear tree.

One of the products working under the Alienvault hood is OSSEC, which is a opensorce host based IDS. Sometimes, its interchangeable to HIDS, which is Host IDS, but really, the latter is simply the type; while the former is the actual name itself. For the sake of this article, we will interchange both terms.

OSSEC runs well with Windows, where Alienvault can do an auto deployment given the correct setup and credentials. However, it’s on Linux boxes that sometimes we get a bit concerned. Not because the product doesn’t work, but simply because the setting up of the installation. There is no auto deployment, so we need to set it up manually, and this might mean downloading the correct packages in the first place.

After this, we are going to look at a specific function of HIDS – File Integrity Monitoring or FIM for short.

Firstly, let’s get started. We have set up a simple CentOS 7 box in our lab in the same network as Alienvault, and we are going to install HIDS on this box as an AGENT. This will then talk to the Alienvault USM which is the server.

So let’s assume you have your agent system network setup (please ensure your DNS is set properly, you should be able to work this out in CentOS 7 either through the network tools or editing resolv.conf).

 yum groupinstall "Development Tools" -y

The CentOS development tools are very useful tools which is a bundle, used primarily for building and compiling software from source code. “Yum” here while making you think of going for a teh tarik is a command found in almost all red-hat based distros to run installations. It’s used for update, installations etc. In the old days before YUM, we would use RPM (which is really what YUM is using), but we would have to manually track down dependencies and it really sucks because to install an RPM package might mean to install a whole bunch of stupid libraries or updating stuff and you are basically running around the internet looking for RPMs like Where’s Wally. It looks awful now, but back in the days, RPM was heavensent. We didn’t need to do “tar”, configure, make, “make install” anymore!

Anyway, the -y argument behind simply automates the command by answering yes to the prompts. So once you run that, fingers crossed, everything runs ok and you get

Complete!

Which means everything is ok.

The next is to get the kernel-devel package.

yum install kernel-devel -y

This is a package that allows us to install a kernel driver later. It’s not the full kernel source, so it shouldn’t take too long before you see the “complete!”.

At this point you are ready to install OSSEC. If there are any issues, then troubleshooting is obviously required.

First, we need to locate the version of HIDS that can work with Alienvault. You might think heading to the latest HIDS in https://ossec.github.io/downloads.html might be the answer, but for Alienvault, we would recommend to get the 2.8.3 version. You can find it here:

https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

So, go to a installation directory (optional) like /usr/src and run

curl -OL https://bintray.com/ossec/ossec-hids/download_file?file_path=ossec-hids-2.8.3.tar.gz

We used curl here because for some reason wget wasn’t installed. the -OL is supposed to handle the redirected links for that particular site and supposedly to rename it to a proper remote file name. It doesn’t do the rename though (don’t know?) and we wind up with a file called “download_file?file_path=ossec-hids-2.8.3.tar.gz”. Just rename it if you are into aesthetics to ossec-hids-2.8.3.tar.gz.

So now lets do an extraction

tar –xzvf ossec-hids-2.8.3.tar.gz

We now have a folder called ossec-hids-2.8.3. Go into this folder and then run

./install.sh

Once you run, you will be given a series of questions. Default should be fine for most, and you should just select ‘agent’ and also key in the server (Alienvault) IP address. Now if you are running a separate Alienvault setup (non-AIO), then this IP address is actually the address of your SENSOR. Not Alienvault Server. So don’t get mixed up. The Sensor is the Server. Hm.

So everything ready, fingers crossed, just go ahead and install. There will be a lot of text filling your screen but the important thing is that there is no ERROR or WARNING (well warning ain’t bad), but at the end you should have a welcome note stating

 Thanks for using the OSSEC HIDS.
 If you have any question, suggestion or if you find any bug, contact us 
at contact@ossec.net or using our public maillist at ossec-list@ossec.net 
(http://www.ossec.net/main/support/ ).

Press enter and you should be out of the installation. Congratulations!

You are not done yet. You still need to get Alienvault to talk to your box. The steps are as follows:

a) Generate an Agent Key from Alienvault

Go to your Alienvault AIO or your Server (since a standard sensor has no GUI, remember?).

Environment->Detection->Agents

Click “Add Agent”

Select the host from the list (It should be there automatically, but if it’s not just add it there through the asset list).

So now the agent has been created but you should see it as “Disconnected” from the list. Click the little Key sign that says “Extract Key”.

You should see something like

Agent key information for '2' is:

MiBIb3N0LTE5Mi0xNjgtMC01MCAxOTIuMTY4LjAuNTAgMDBmYzI0MzUyNzg4N.....etc
The garbled message is the key. So go ahead and highlight and copy it.

b) Import the key into the agent system

Go back to your agent system and head over to /var/ossec/bin and run

./manage-agents

Type in ‘I’ to import

Paste the whole key into the screen and confirm adding it.

Quit and then restart by going

/var/ossec/bin

And

./ossec-control restart

c) Restarting HIDS on the server

On the server head over to

Environment->Detection->HIDS Control

On the right side, click “Restart” the HIDS and you should be fine.

d) Check the Agent Logs

Head back to the agent system and check the logs

cd /var/ossec/logs
more ossec.log

You should (hopefully!) see

INFO: Connected to the server (192.168.0.xxx:1514).

where xxx is your server IP address.

Back in the USM server you will be able to see that now the agent is “Active”.

In the next article we will see if we can get the FIM to work.

PDPA and the Tale of the Telemarketer

October 29, 2017 / / 0 Comments

We were working very late on Saturday to roll out a PCI manual for some of our merchant clients, so I only slept at around 4.30 am. I am usually up on Sunday around 9.30 am at the latest due to my kids utilising my body as a trampoline which I can probably ignore for about 15 minutes before being entirely awoken, but 5 hours of sleep is pretty good so I will take that regardless.

At around 9 am unfortunately, my phone rang and I saw a number I didn’t recognise. Thinking this could be an emergency, I picked up the call and on the other line, this unrecognised voice chirpily said, “Hi, I am calling from <name of telco> and I would like to do a marketing survey with you!”

“Do you know it’s a Sunday?”

“Yes, it is a Sunday, I know!”

“Don’t you realise that you shouldn’t be telemarketing me on a Sunday morning?”

“We believe that you would be too busy on a weekday, sir, that’s why I am calling you on a Sunday!”

“Well, I am too busy now on a Sunday. Goodbye.”

And I hung up.

Now, I was fuming, because I just felt it was completely distasteful and disrespectful for them to be calling me up on a Sunday morning because they think I would reject them on a weekday. They think they will get me on a better mood on a Sunday morning?!

For the record, I don’t usually do this, as in, be rude or just hang up even on telemarketers. I am always reminded, that telemarketers are people. The person on the other line has a family too, and she probably wish that she was with them on a Sunday morning, taking her kids out for breakfast or hanging out with her friends or something. I mean, I doubt she is jumping up and down with excitement at the prospect of going into the office and dialing up people on Sunday so she could make her survey quota. I never experienced being a telemarketer, but in our first year, I did experience the emptiness of having zero clients and doing cold calling if anyone wanted my audit services. So, yes, I do commiserate with them. On normal calls I am usually civil to them. I usually politely tell them that they have already called me many times (Astro calls me like every week asking me to upgrade), and even thank them before hanging up, before I put their number in my ignore list. Some, I admit, when they do call, and I am in a the middle of something, I tell them that I am currently busy and then I put their number on my ignore list. It’s hard for me to ignore phone calls on any number because there could be a potential sales opportunity and not a telemarketer. But if it is a telemarketer, I don’t shut them down rudely. At least not in my memory.

But Sunday morning is a different thing. I did kind of feel bad, and was contemplating to call her back again to take that survey, but then Sunday life started (me being a trampoline) and I lost track of it.

But how does our Personal Data Protection Act fit into all of this?

Contrary to many people’s beliefs, PDPA actually allows telemarketers to call you. There is nothing in the act that says telemarketers cannot call you. The problem isn’t so much of telemarketers calling. Them calling you is already way downstream of the actual issue. The actual issue is your information being shared, leaked, sold, brokered by service companies to information brokers. Sometimes it’s our fault. We sign up for things and we don’t read the fine print. When we get a direct marketing call we get all up in a tizzy and blame the entire planet for conspiring to wake us up on a Sunday morning. But hey, we agreed to it. Yes, in that terms of services we did not read. In that privacy statement we implicitly agreed to when we gave our information to get a chance to win that free trip to Tokyo.

Privacy statements from banks, telcos, service providers all have to include the section of ‘disclosure’. Google your favourite bank or telco and put in ‘privacy statement’ and click to get their privacy statement. In most cases you will find them defining who they intend to share your personal information with, and in most cases, some broad sweeping statement such as :

Our agents and service providers with whom we have contractual agreements for some of our functions, services and activities; and/or

 

Financial service providers in relation to the products and services that you have with us (e.g. mortgage brokers, insurance companies); and/or

 

Strategic partners with whom we have a relationship with for specific products and services if consented to, by you; and/or

Now, let’s break that down. The first one is very broad. “Agents” and “Service Providers” where they have contractual agreements  – this basically means the entire ecosystem of companies providing services to this bank! The second at least defines it, but generally these are a subset of the first. Finally the ‘strategic partners’ part isn’t so much of an issue but the ‘if consented to, by you’ sounds very good and positive, only for you to realise that the implied consent is usually obtained by you agreeing to the privacy statement in the first place! You see, there is no need for explicit consent if this is not considered ‘sensitive data’, so don’t expect your signature to mean consent. By you taking up their service and agreeing to pass your data – that’s a consent enough for them to share your information. Boom.

So, technically the moment we sign up for a service, we agree that we would allow telemarketers to call us – whether in the middle of the night or on a Sunday morning is irregardless – the fact is that we gave that permission, mostly without knowing it and all just because of that carrot they usually hang in front of us. Dang, I lost that Tokyo competition! Hey, here’s another one – “provide phone number to win a Mazda 3”. OK, here’s my number! Yaay! Let me be lucky!

You get the drift.

Now, back to telemarketers calling us. They have the right. They have a bunch of phone numbers given to them by the bank, and God knows what other information so they can sell us specific services: and so they make the call.

PDPA regulates telemarketing through Section 43 of the Act: Right to prevent processing for purposes of direct marketing. 

So the proper channel to stop this: Technically you are supposed to provide in ‘writing’ to the data user (company calling you), requesting you not to be contacted anymore for telemarketing. This can be a courtesy respond during the call itself, whereby you state to them, please remove your number from their list and not call anymore (it’s not in writing, but you can try this first). If they persist in calling, write to them (their email is found in their company’s privacy notice of who to contact if you have a complaint), and if you still get called up, you can formally complain to PDPA commissioner at aduan@pdp.gov.my and follow that up with a call to 03-89115000 (please check their website to see if this has changed).

So, there you go. Malaysia was supposed to implement a Do-Not-Call (DNC) registry to block these telemarketer phone numbers back in 2014, but it has seemingly died down and implementation is still not done. We are monitoring to see if this is being looked into again, but for now, it looks like we need to fend on our own here.

Remember though – the person calling you may not wish to be calling you at all, and they might just be a phone call away from losing their jobs. While I am not advocating you to entertain them just for the sake of being nice, but on the flip side, there is no reason for some of the foul-mouthed tirade I have seen some people venting on these callers, as if they want to personally reach into their mobile phone and strangle the guy on the other line. Cool down. Ask to be removed, and block the number and move on, knowing you can rely on PDPA if your notice of removal is constantly ignored.

If anyone needs to know more on PDPA, drop us a note at avantedge@pkfmalaysia.com. We have been working with many companies to sort their PDPA concerns out and also implementing controls to address the 7 requirements.

 

IATA PCI-DSS: Why your SAQs Matter

October 25, 2017 / / 0 Comments

We have had a few discussions among consultants as we progress further into this compliance for our Travel Agency clients. And very often (if not always), the matter always comes down to, “Can we just do an ASV scan and you certify us?”

We have touched this topic many times. ASV scans cannot certify you as PCI compliant. They are just one of the requirements. In fact for some of the SAQs (self Assessment questionnaire), ASV is not even needed.

SAQ A

We’ve gone through the famous SAQ A in our last post. This is basically where no card data is being entered in merchant environment and they basically forward everything over to the payment provider. There is no requirement for ASV. That doesn’t mean it makes it right though. Imagine this scenario: the developer makes a hopeless job at coding their web application. There are two ways SAQ A can be done: redirect or iframe. Let’s recap.

A redirect occurs when the merchant website sends a redirect instruction to the client browser when payment needs to be made. This instructs the client to connect directly to the payment gateway. This instruction could be a simple

onclick="location.href='https://payme.com';"

Or similarly through some javascript with window.location.

The iframe is similar, whereby a ‘child’ window is called directly from the payment gateway and has a window in the main merchant site. Although everytime this occurs, I have nightmares of those old websites with scrolling words, flashing lights and like 5 – 10 frames running at once. Netscape days.

iFrames are simple as well, with the site you want to call embedded within the <iframe src> tags.

So, anyway, back to ASV scans on these merchant sites. Although its not required, if the web application itself is poorly constructed and is compromised, there could be a high possibility that the redirect process itself gets hacked and redirected to another site that looks like the real payment site. You can imagine what happens next. The solution here is to ensure even on the merchant site, this site is developed with good secure coding practices. If ASV is not required, it does not mean you don’t need to run any scans. We would recommend vulnerability scans to still run against it, whether ASV or not. In fact, any web facing system out there should be tested – because if you are out there, it’s open season – anyone can attack it, and it’s up to you to secure it.

Conclusion: No need for ASV, but recommended – if not ASV, at least some security scans.

SAQ B 

Ah, the good old SAQ B. A lot of people misunderstand this for a good reason. Some of our retail clients, or F&B clients insists this is the correct one as they are using card terminals. However, they forget that most of them have their integrated POS systems – specifically because they need to charge an amount like food etc. So their POS systems sends these details to their EDC (Electronic data capture) terminals and the EDC accepts the DIP cards. What happens is that, these EDCs sends back the transaction data and in many cases, they still swipe our cards on the payment system. SAQ B doesn’t qualify here. SAQ B is specific for dialup EDCs directly to acquirer bank. For those using 3g/4g, then these can be considered as well. If you are using WIFI, or internal broadband link then you are out of luck. No SAQ.

Because of the direct point to point or cellular connectivity, ASV is not required (for a good reason!)

Conclusion: No Need ASV – IF you actually qualify for the SAQ that is.

SAQ C-VT

Another difficult SAQ to be eligible for. It has very specific requirements – whereby a web-based browser connectivity to a virtual payment provider who is PCI compliant. I think it really applies more to hospitality or travel agencies. In this case, the question is often asked – what about my broadband IP accessing the net? Because for sure, when I connect to my virtual terminal provider, I am using the internet right, and not leased line or any point to point? So for sure, my broadband has an IP. Just type “whats my ip” in google and it will show. Most of them have dynamic IP addresses as well. In SAQ C-VT there is no requirement to ASV scan.

However, having a dynamic IP and no ASV scan in SAQ C-VT doesn’t mean you still can’t do it. Many routers/firewalls are poorly implemented or poorly patched. We would recommend to do an internal scan on the firewall interface to ensure vulnerabilities are identified. Again, it’s a matter of securing the internet exposed system.

Conclsuion: No Need ASV, but we recommend an internal security scan on the firewall to ensure the box is properly hardened.

So, there you have it. It’s critical to know your SAQs so you know the extent of what NEEDS to be done and what is BETTER to be done than not.

If you need assistance with your PCI-DSS, drop us an email at pcidss@pkfmalaysia.com

© 2024 PKF AvantEdge

— Up ↑