PKF AvantEdge

Page 24 of 40

Alienvault Certified Security Engineer (ACSE)

March 26, 2016 / / 5 Comments

acse

After a slight delay, our company now have an Alienvault Certified Security Engineer (ACSE)

To be honest, a lot of customers still go “What?” when we talk about AlienVault, but we hope to get more and more people acquainted with the product. Especially in PCI-DSS, it simply works. Having an ACSE goes a long way to ensure our commitment to provide the best services we can to our clients.

The exam itself is around 70 – 75 multiple choice questions over 90 minutes. You will likely not use the full 90 minutes, but it basically will give you enough time to think it over. Frankly for me, it’s simply either I know it or I don’t. And for those that I don’t know (and for sure, there will be a number of them), well, take a shot.

It had a good mixture of linux questions, user interface questions, overall architecture and how AV works, so you need to know not just the theory but you will need to get your hands dirty with the system. Luckily, Alienvault provides a free 30 day trial to install in VMWare ESXi – which itself has a trial period of 60 days, so I recommend that you get this up and running and do some testing. Without hands on experience, you will find it difficult to answer a lot of the questions – unless you are a good (and lucky) chooser.

If you don’t have the resources to set up VMWare and the 30 day trial of Alienvault, you could get OSSIM (the free version) up and running on any virtualbox system (including your laptop). Be warned though, it might tax your resource a little, so make sure you have sufficient RAM and Hard drive to do it. I won’t recommend it on any system under i5. I run on Core i7 with 16GB of Memory and I am still struggling with OSSIM running in virtualbox (of course, having multiple Linux systems and a CISCO emulator installed doesn’t help as well).

Overall, the ACSE covers a good balance of technical and theory, and worth taking. It will certainly help as we prepare for numerous Proof Of Concepts ahead of us!

Alienvault with NXLog

March 23, 2016 / / 0 Comments

For various reasons unknown to mankind, Windows has a very retarded relationship with logs. Because it was designed without any inkling of networking or internet in mind, Windows logs are very local and very stupid. I don’t know why, maybe because whoever created windows never really thought that their OS will be in a networked environment.

Anyway, to get Windows to work with a sort of syslog capability, NXLog can be used. In the next few articles, we will explore how to get it working, because like everything else in Windows, it needs some work. 10 years from now, our children will probably do the same thing by clicking an icon and everything magically works. For now, its back to CLI.

First – NxLog runs on TCP 514. Alienvault by default listens on UDP only.

Go ahead to /etc/rsyslog.conf 

# provides UDP syslog reception
$ModLoad imudp
$UDPServerRun 514

# provides TCP syslog reception
$ModLoad imtcp
$InputTCPServerRun 514

The ones in bold were commented, so just go ahead uncomment it and service rsyslog restart.

Do a netstat -tulpen | grep rsyslog and you should see it listening. For good measure, do nc – vt 127.0.0.1 514 and it will say its open.

Done!

Not really. Alienvault has additional issues. For some reason, even if you turn off Alienvault Firewall from the setup menu, you still cannot telnet to 514 from another system. Something is obviously blocking it.

I will assume you have installed nxlog in your windows. In nxlog.conf under C:\Program Files (x86)\nxlog\conf, you should see

<Output out-5141>
#Send to central nxlog listener on tcp port 5141, change host address
Module om_tcp
Host xxx.xxx.xxx.xxx
Port 514
OutputType LineBased
</Output>

Just replace the xxx with the IP of your Alienvault

Go ahead to

C:\Program Files (x86)\nxlog\data\nxlog.log

You might encounter

2016-03-23 10:31:47 ERROR couldn’t connect to tcp socket on <IP ADDRESS>:514; A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.  

Obviously, the IP is your Alienvault IP. This generally means there is some issue. Try telneting to port 514 from your Windows and you will get a timeout.

On your Alienvault

VirtualUSMAllInOne:/var/log# tcpdump -i eth0 “tcp port 514”

Restart your nxlog on your windows and you will see some packets coming in. It’s just not connecting. This shows you that the packets are reaching your AV, but for some nefarious reason your AV is not willing to talk.

Firewall?

As I mentioned, disabling firewall on the Alienvault menu doesn’t help because…I don’t know. It just doesn’t.

Luckily, we know a secret.

/etc/ossim/firewall_include

This little file is where you configure your policies for firewall. Just add

-A INPUT -p tcp -m state –state NEW -m tcp –dport 514 -j ACCEPT

At the bottom. This opens up the port 514 to chat.

Now, you need to reload the ossim config. No, service ossim-server restart or service ossim-agent restart won’t work. You need to do the full ossim-reconfig.

Once that is done, do a telnet again, or a tcpdump or check the nxlog log (after restarting).

2016-03-23 11:12:08 INFO nxlog-ce-2.8.1248 started
2016-03-23 11:12:08 INFO connecting to <IP ADDRESS>:514

Your port 514 is open now.

We will configure NXlog in the next article to send logs over to Alienvault.

DROWN Vulnerability: Cross-protocol attack on TLS using SSLv2

March 1, 2016 / / 0 Comments

This is a security advisory on the DROWN Attack (CVE-2016-0800).

What is DROWN Attack (CVE-2016-0800)

DROWN, stands for “Decrypting RSA with Obsolete and Weakened eNcryption”, is a serious vulnerability that affects HTTPS and other services that rely on SSL and TLS, some of the essential cryptographic protocols for Internet security. These protocols allow everyone on the Internet to browse the web, use email, shop online, and send instant messages without third-parties being able to read the communication.

Any communication between users and the server, typically includes, but is not limited to, usernames and passwords, credit card numbers, emails, instant messages, and other sensitive information. Under some common scenarios, an attacker can also impersonate a secure website and intercept or change the content the user sees.

A group of security researchers discovered that SSLv2 (Secure Sockets Layer protocol version 2.0) is vulnerable to the Bleichenbacher RSA padding oracle attack, which can be used to decrypt RSA cipher text without the knowledge of the matching private RSA key. This can be done by observing responses from a server that has the private key and performs the decryption of attacker-provided cipher texts using that key. A cross-protocol attack was discovered that could lead to decryption of TLS sessions by using a server supporting SSLv2 and export cipher suites such as Bleichenbacher RSA padding oracle. The cross-protocol attack allows decryption of SSL/TLS sessions using newer protocol versions – SSLv3 or any current TLS (Transport Layer Security) version (1.0 – 1.2) – using this SSLv2 weakness. Note that traffic between clients and non-vulnerable servers can be decrypted provided another server supporting SSLv2 and EXPORT ciphers (even with a different protocol such as SMTP, IMAP or POP) shares the RSA keys of the non-vulnerable server (CVE-2016-0800. This flaw is SSLv2 protocol issue and affects all implementations of the protocol.

Who is Vulnerable?

Websites, mail servers, and other TLS-dependent services are at risk for the DROWN attack.

How to check if server is vulnerable?

A server is vulnerable to DROWN if:

  • It allows SSLv2 connections. This is surprisingly common, due to misconfiguration and inappropriate default settings.
  • Its private key is used on any other server that allows SSLv2 connections, even for another protocol.

How to fix

It is recommend to:

  • Ensure that servers private keys are not used anywhere with server software that allows SSLv2 connections. This includes web servers, SMTP servers, IMAP and POP servers, and any other software that supports SSL/TLS.
  • OpenSSL 1.0.2 users should upgrade to 1.0.2g, OpenSSL 1.0.1 users should upgrade to 1.0.1s
  • Disable the complete support of SSLv2 by following the vendor’s advisory:
    Internet Information Services (IIS)

    Apache

    Postfix

    Nginx

    IBM HTTP Server

Application of PCI-DSS in Retail

February 26, 2016 / / 0 Comments

“Technology…is a queer thing; it brings you great gifts with one hand and it stabs you in the back with the other.” – CHARLES PERCY SNOW”

This was a quote by a man born more than a century ago, that is resonating in its applicability even now, especially in the payment processes for retailers.

On one hand, we are discovering amazing new methods and breakthrough in payment and doing transactions, all driving convenience to the end customer. mPOS has been around for years, and is now migrating to using smartphones to replace bulky handheld terminals; Applepay and other technologies enable mobile phones to make micro transactions through a few clicks; internet transactions increasing to the billions whereby someone a thousand miles away can order something and receive it a few days later. And we are only skimming the possibilities. Cryptocurrencies like Bitcoin might dictate the future of retail where the entire currency is virtual. Transporting of goods through drones might be in the horizon, and in the future not as distant as you would like to think, 3D printing will enable item blueprints to be sent to your printer by the retailer and the item can be created in front of you. It is an exciting time to be involved in technology, for sure.

Yet, on the other hand, as there are people aiming to make a positive impact to the world, there are also those who will twist technology to their selfish ends. Every transaction funneling through the world wide web can be tracked, and tapped, and risk being stolen. Credit card information residing in so-called secure servers can be taken off by just one employee accessing the hard drive through a malware-infected laptop. The very thing that makes life convenient can also make it dangerous: the very same 3D printer that prints out your son’s first airplane toy, can also be used to print out a functioning AK-47 by terrorist cells.

Payment Card Industry Data Security Standard (PCI-DSS) is one of the emerging standards in the attempt to counter this onslaught of security risks. This standard was created by a group consisting of VISA, Mastercard, American Express, Japan Credit Bureau and Discover a decade ago and has now evolved to version 3.1 (with version 3.2 coming this year). The standard applies to any retailers involved in any sort of credit or debit card transactions involving any of these brands.

In PKF Avant Edge, we know there is no magic pill to solve all security issues. But having been actively involved in PCI-DSS since 2010, and with a portfolio of more than 30 PCI-DSS clients, ranging from up and coming payment processors that processes online games to mega sized oil and gas firms, we have experienced companies that are virtually built like a house of cards. Without proper guidance, their IT systems and information security have survived only by sheer luck. Through our methodology of assessing, remediating and certifying, we have helped them strengthen their systems; secure their information and limit needless propagation and storage of critical information assets.

Retailers have a larger challenge, whereby the more locations you have, the more security headaches you will receive. PCI-DSS attempts to do two things for retailers – limit only necessary credit card information to where it should be and to secure this information where it is stored, transmitted and processed. It is not always easy – in fact, the opposite is often true. Most retailer underestimate their security posture and think that PCI-DSS can be passed in a few weeks. In all cases, the rude reality is that they have to undergo changes to their architecture and project thought to be completed in 2 months can stretch to 6 to 8 months. Or even longer.

While some practitioners might say that the remediation effort is the most important aspect of the PCI-DSS program, we are of the opinion that it is in the scoping exercise right at the beginning. Retailers especially, due to distributed location, MUST scope correctly. In PCI, there is such a thing as ‘overscoping’, meaning the coverage of unnecessary items. This places pressure on cost, time and resources. There are alternative ways to make PCI easier, and this is where having an experienced PCI advisor is key. We are not just office consultants looking at a standard document or checklist. We are on the field technology practitioners not just experienced in PCI, but with real world work experience in IT service management, IT security and network operations control, security testing, software development, IT forensics and architecture solutioning. PCI-DSS is a technical standard, and whoever you select to guide you on your journey MUST be technical.

Contact us at pcidss@pkfmalaysia.com for more information about our services .

Get Ready for PCI-DSS version 3.2

February 19, 2016 / / 0 Comments

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.

« Older posts Newer posts »

© 2024 PKF AvantEdge

— Up ↑