PCI Compliance can be cumbersome and confusing upon its first read. There are lots of different levels of PCI compliance, along with different types of compliance depending on how you use the credit card data. For example, if you accept credit cards, you are considered a merchant. You would need to follow the merchant rules for determining which level you would need to be certified for. If you are a service provider, and other merchants just transmit credit card data over your infrastructure, you need to be certified as a service provider. Service providers have different levels compared to merchants. We will first talk about the various merchant levels, since this is more common.
In the Merchant level, each credit card has their own rules in terms of exact transactions per year. So it can get complicated. You will need to check with each vendor for the exact amounts. I will use Visa’s PCI Compliance rules, since they are probably the most common.
Keep Reading »
Today’s threats are more advanced and thorough than ever before. Hackers will spends hours probing various systems to see what will and will not work to get them the information they need. Because of this high level of sophistication, more advanced security is needed on the perimeter of your web applications. Traditional firewalls can only go so far in your environment today. They were designed to perform a purpose, which they do very well, but unfortunately, more intelligence is needed in today’s security threat environment. Traditional firewalls typically look to see if the packet is allowed or not based on various items like Source/Destination IP address, or possible by service, or by both. But, for a service that is allowed through, it doesn’t typically check to see if that request is legitimate or not. Now I know some firewalls can perform basic checks on Layer 7, but in my opinion, they don’t do it as well as purpose built device, or piece of software.
Defense in Depth
Defense-in-depth specifies having as many levels of different security types and devices to make it as hard as possible for a hacker to get your data. Having a device in place which can understand your Layer 7 protocols will allow it to pick up when things may be ok on the Network layer, but not on the Application layer.
Keep Reading »
Check your Logs
One of the basic and first rules when troubleshooting any hosting issue is to check the logs. Logs can tell you exactly what is going on the hosting environment, whether it is good or bad. But, they also tend to be the last place people look, or not even look at all, even though they know better. Logs can also foreshadow future events. They can sometimes let you know when disks are failing, or that something fishy is happening security wise. This is why most compliance requirements have a strong logging infrastructure and review process requirement. You can’t secure an environment if you don’t know what is going on. And the best way to see what is going on is to look at the logs.
What is SIEM?
SIEM , or Security Information and Event Management, is a tool that can help you get control over your hosting environment, and know what is going on within it. SIEM allows for a centralized system where all the logs from your hosting environment go, so that they can be reviewed together. No more logging into multiple places to see what happened when, they are all within one place for easy viewing. This allows for no only easier viewing, but also for quicker event correlation. Event correlation is the term used to describe the process of taking logs entries from multiple sources, and matching them to a particular event. For example, in your webserver logs you notice someone trying to brute force a login to a secure area. You then notice in your web application firewall logs, that same IP Address is trying SQL injection attacks against your web application ( But of course successfully being blocked by your web application firewall ). Finally, you notice that same IP has been scanning your complete network based on logs from your firewall and IPS unit. All these logs can be correlated to an event, and that event being that IP address is attacking/scanning your hosting environment looking for a way in. Without that event correlation, you would only see parts, and not get the whole picture.
Keep Reading »
Dual Factor Authentication is an important layer in your defense in depth strategy and provides redundancy in the event a security control fails or a vulnerability is exploited. It is often used to add an additional verification layer in Virtual Private Network (VPN) authentication. Not only is Dual Factor Authentication a great addition to the security-minded client, but it is often required by various compliances, like PCI. In case you are not familiar with exactly what multi-factor authentication is, let me describe it here for you.
The Three Factors
The principle around Multifactor authentication is that you are authentication yourself to some system via different factors. The factors available are as follows:
• Something you know
• Something you are
• Something you have
Something You know
Most people are aware of the “something you know”. This is typically something that the true user would know, like a user and password to their account. Seems secure, and would only be known by the “true” user, right? Well, not exactly. How many people out there have given their password to someone else for some sort of use, or for that matter, have it saved somewhere for future reference? You may have a password stored somewhere on your computer, which would seem secure. But, if that gets compromised, then that “true” identity is no longer guaranteed to be you. I bet most people have, and that is what compliance certifications like PCI and such are looking to correct. By incorporating an additional factor, they can better guarantee you are who you say you are. Of course, it gets very hard to guarantee 100%, but as you add factors, it gets pretty darn close.
Keep Reading »
Intrusion Protection System and Intrustion Detection System (IPS/IDS) devices are an important layer in the overall network security profile of any business. They provide a basic sanity check on traffic to and from your network that your firewall has deemed acceptable to pass. It’s part of the defense in depth initiative that any security conscious company should employ. Each layer is responsible for a particular security check. IPS/IDS units check traffic that has passed the basic access control list on the firewall for any potentially known bad payload. How they do this? Well, here is a basic understanding of IPS/IDS.
First, we will start with getting traffic to the device. In most cases, you can put the sensor inline (IPS mode), or out of line (IDS). In IPS mode, you are performing inspections and pattern matching as the live traffic passes through the sensor. In IDS mode, you are performing those security inspections and pattern matching on copied traffic, so it does not affect the flow of live traffic. Typically, the implementation style is a business decision that differs between companies and depends on a device manufacturer being implemented.
Once you have the topology decided upon, you can then determine which traffic gets inspected. Typically, you would want all server traffic to be checked against the signature database. But, there may be exceptions to this, so this would need to be determined based on your business drivers. Once this is all set, the traffic you want to check will start flowing through the sensor.
The signature database is the crux of the IPS/IDS unit. The effectiveness of the device is only as good as the signatures you are checking the traffic against. You want to make sure your device is getting the latest signatures for the most effective use. Most of the larger vendors maintain a very tight and up to date signature line which is pushed to their sensors on a frequent basis.
As traffic passes through the device, it is compared against various signatures within a device. Signatures are grouped into engines based on their function. Signature engines are very powerful, and we could write a blog article just on them, but for this article, I will just glance over the main ideas. These signatures engines can be of different types. For example, they may look for a particular string within the payload, which is also known as a string signature. They may also look for a particular action on a specific port. These are known as atomic or service types of signatures. Next, there are those that can look for large amounts of requests by that same person over a particular time period, which are known as the flood type. Meta type signatures can watch for a known bad pattern over a sliding window of time. For example, someone telnets to port 25 with a given string, and then within 1 minute, sends a particular ICMP type.
Keep Reading »