Four reasons why companies remain vulnerable to cyber attacks.

May 30, 2012 — netequalizer

Over the past year, since  the release of our IPS product, we have spent many hours talking to resellers and  businesses regarding  Internet security. Below are  interesting observations about security investment and more importantly non investment.

1) By far the number one reason why companies are vulnerable is procrastination. Seeing is believing, and  many companies have never been hacked or  compromised .

Some clarification here , most attacks do not end in something being destroyed or any obvious trail of data being lifted. This does not mean they do not happen , it’s just that there was no immediate ramification in many cases, hence business as usual.

Companies are run by people, and most people are reactive, and furthermore some-what single threaded, thus they can only address  a few problems at a time. Without a compelling obvious problem, security gets pushed down the list. The exception to the procrastination rule would be verticals such as financial institutions, where security audits are mandatory (more on audits in a bit).  Most companies, although aware of  risk factors, are reluctant to spend on a problem that has never happened.  In their defense,  a company that reacts to all the security FUD, might find itself hamstrung and out of business.  Some times to be profitable you have to live with a little risk.

2) Existing Security tools are ignored.

Many security suites are just too broad to be relevant, information overload can lead to a false sense of coverage.

The best analogy I can give is the Tornado warning system used by the National Weather Service.  Their warning system, although well intended, has been so diffuse in specificity, after a while people ignore the warnings.  The same holds true with security tools.  In order to impress and and out do one another, security tools have become bloated with quantity, not quality.  This over load of data, can lead to a overwhelming glut of frivolous information. It would be like a stock analyst predicting every possible outcome and expecting you to invest on that advice. Without a specific targeted piece of information your security solution can be a distraction.

3) Security audits are mandated formalities. In some instances  security audit is treated as a bureaucratic mandate.   When security audits  are mandated as a standard , the process of the audit can become the objective. The soldiers carrying out the process will view the completed checklist as the desired result and thus may not actually counter existing  threats. It’s not that the audit does not have value, but the audit itself becomes a minimum objective. And most likely the audit is a broad cookie cutter approach which mostly serves to protect the company or individuals from blame.

4) It may just not be worth the investment.   The cost of getting hacked may  be less than the ongoing fees and consumption of time by  security solutions. On  a mini scale, I followed this advice on  my home laptop running Windows.  It was easier to re-load my system every 6 months when I got a virus rather   mess with all the security virus protection being thrown at me, slowing my system down. The same holds true on a corporate scale. Although nobody would ever come out and admit this publicly or make it deliberately easy,  but it might be more cost effective to recover from a security breach than to proactively invest in preventing it. What if your customer records get stolen so what? Consumers are hearing about the largest banks and government security agencies getting hacked every day. If you are a mid sized business it might be more cost effective to invest in some damage control after the fact rather than jeopardize cash flow today.

So what is the future for security products ? Well they are not going to go away they just need to be smarter cost effective and turn key and then perhaps companies will find the benefit to risk more acceptable.

Reference Security Data overload article

Posted in Commentary and Editorials, Security. Tags: , , , , , , , . Leave a Comment »

Web Security Breaches and Accountability

May 18, 2012 — netequalizer

By Zack Sanders – Security Expert – APconnections

If this recent story about a breach of medical information in Utah is any indication of how organizations will now handle security breaches, technology managers everywhere should be shaking in their boots. After a breach that exposed personal information of 780,000 people, the Utah state technology director was relieved of his position by the governor, and several others are under investigation.

Details of the actual attack are scarce, but it appears as though a medicaid server (possibly hosted in the cloud) was vulnerable to a security misconfiguration at the password authentication level. This could mean a few different things – including SQL injection issues, exposed configuration files, or that content was accessible without actually logging in. Regardless of how it really occurred, it certainly could have been prevented with proper proactive assessments.

The larger issue at hand that the article touches on is accountability in data security. Personally, I think you are going to have a hard time finding organizations that will guarantee their solutions are totally secure. It’s just not realistic. You can never be 100% protected against an attack, and because software solutions often rely on other technologies and people, the amount of ways in are many and proving exactly how someone got in and who is to blame will be difficult considering that vulnerabilities are often leveraged against each other. For example, say you have a server that has a third party web application, a back-end database, and blog software installed. The web application itself is secure, but the blog software is not. It is breached by an attacker, and the database for the web application is stolen. User data in the database was not encrypted, and wide-spread fraud occurs. Who is to blame? The blog maker? The web application developer? The system administrator?

In truth, the answer is everyone – to varying degrees. The system administrator should not have these two software packages running on the same system. The blog developers should have built a better solution. The web application programmer should have encrypted data at rest. Blame can even shift further up the chain. The IT director should have budgeted more money for security. The board members should have demanded proactive actions be taken.

So, it is likely the firings in the Utah Medicaid breach were mostly political in that someone has to fall on the sword, but in truth, the blame should fall on many individuals and companies.

One thing is clear, if you are a technology director or manager, you don’t want this to happen to you – but there are actions you can take. The most important thing is to BE PROACTIVE about security. How many breaches do you have to read about every day before you take charge in your own environment. If you’ve never been hacked, ask someone who has. It is a very painful process and costs reputation, money, and time. Start taking steps today to better your chances against attack. Some options to consider:

- Have quarterly security assessments conducted.

- If major changes to the application or server are made, have those changes reviewed for security.

- Discuss your security controls with an expert.

- Audit your existing infrastructure and start making changes now. Even though this will take time and resources, it does not compare to the time and resources required if a breach occurs.

Posted in Security. Leave a Comment »

Apconnections Backs up Security Device Support with an unusual offer, “We’ll hack your network”

May 9, 2012 — netequalizer

What gets people excited about purchasing an intrusion detection system? Not much. Certainly, fear can be used to sell security devices. But most, mid sized companies are spread thin with their IT staff, they are focused on running their business operations. To spend money to prevent something that has never happened to them would be seen as somewhat foolish. There are a large number of potential threats to a business, security being just one of them.

One expert pointed out recently:

“Sophisticated fraudsters are becoming the norm with data breaches, carder forums, and do it yourself (DIY) crime kits being marketed via the Internet.” Excerpt from fraudwar blog spot.

Thus, getting data stolen happens so often that it can be considered a survivable event, it is the new normal. Your customers are not going to run for the hills, as they have been conditioned to roll with this threat. But there still is a steep cost for such an event. So our staff put our heads together and asked the question… there must be an easy, quantifiable, minimum investment way to objectively evaluate data risk without a giant cluster of data security devices in place, spewing gobs of meaningless drivel.

One of our internal, white knight, hackers pointed out, that in his storied past, he had been able to break into almost any business at will (good thing he is a white knight and does not steal or damage anything). While talking to some of our channel resellers we have also learned that most companies, although aware of outside intrusion, are reluctant to throw money and resources at a potential problem that they can’t easily quantify.

Thus arose an idea for our new offer. For a small refundable retainer fee, we will attempt to break into a customers data systems from the outside. If we can’t get in, then we’ll return the retainer fee. Obviously, if we get in, we can then propose a solution with indisputable evidence of the vulnerability, and if we don’t get in, then the customer can have some level of assurance that their existing infrastructure thwarted a determined break in.

Posted in New Features, Security, Topics. Tags: , , , . Leave a Comment »

Case Study: A Successful BotNet-Based Attack

May 7, 2012 — netequalizer

By Zack Sanders – Security Expert – APconnections

In early 2012, I took on a client who was a referral from someone I had worked with when I first got out of school. When the CTO of the company initially called me, they were actually in the process of being attacked at that very moment. I got to work right away using my background as both a web application hacker and as a forensic analyst to try and solve the key questions that we briefly touched on in a blog post just last week. Questions such as:

- What was the nature of the attack?

- What kind of data was it after?

- What processes and files on the machine were malicious and/or which legitimate files were now infected?

- How could we maintain business continuity while at the same time ensuring that the threat was truly gone?

- What sort of security controls should we put in place to make sure an attack doesn’t happen again?

- What should the public and internal responses be?

Background

For the sake of this case study, we’ll call the company HappyFeet Movies – an organization that specializes in online dance tutorials. HappyFeet has three basic websites, all of which help sell and promote their movies. Most of the company’s business occurs in the United States and Europe, with few other international transactions. All of the websites reside on one physical server that is maintained by a hosting company. They are a small to medium-sized business with about 50 employees locally.

Initial Questions

I always start these investigations with two questions:

1) What evidence do you see of an attack? Defacement? Increased traffic? Interesting log entries?

2) What actions have you taken thus far to stop the attack?

Here was HappyFeet’s response to these questions:

1) We are seeing content changes and defacement on the home page and other pages. We are also seeing strange entries in the Apache logs.

2) We have been working with our hosting company to restore to previous backups. However, after each backup, within hours, we are getting hacked again. This has been going on for the last couple of months. The hosting company has removed some malicious files, but we aren’t sure which ones.

Looking For Clues

The first thing I like to do in cases like this is poke around the web server to see what is really going on under the hood. Hosting companies often have management portals or FTP interfaces where you can interact with the web server, but having root access and a shell is extremely important to me. With this privileged account, I can go and look at all the relevant files for evidence that aligns with the observed behavior. Keep in mind, at this point I have not done anything as far as removing the web server from the production environment or shutting it down. I am looking for valuable information that really can only be discovered while the attack is in progress. The fact that the hosting company has restored to backup and removed files irks me, but there is still plenty of evidence available for me to analyze.

Here were some of my findings during this initial assessment – all of them based around one of the three sites:

1) The web root for one of the three sites has a TON of files in it – many of which have strange names and recent modification dates. Files such as:

db_config-1.php

index_t.php

c99.php

2) Many of the directories (even the secure ones) are world writable, with permissions:

drwxrwxrwx

3) There are SQL dumps/backups in the web root that are zipped so when visited by a web browser the user is prompted for a download – yikes!

4) The site uses a content management system (CMS) that was last updated in 2006 and the database setup interface is still enabled and visible at the web root.

5) Directory listings are enabled, allowing a user to see the contents of the directories – making discovery of file names above trivial task.

6) The Apache logs show incessant SQL injection attempts, which when ran, expose usernames and passwords in plain text.

7) The Apache logs also show many entries accessing a strange file called c99.php. It appeared to be some sort of interface that took shell commands as arguments, as is evident in the logs:

66.249.72.41 – - “GET /c99.php?act=ps_aux&d=%2Fvar%2Faccount%2F&pid=24143&sig=9 HTTP/1.1″ 200 286

Nature of the Attack

There were two basic findings that stood out to me most:

1) The c99.php file.

2) The successful SQL injection log entries.

c99.php

I decided to do some research and quickly found out that this is a popular PHP shell file. It was somehow uploaded to the web server and the rest of the mayhem was conducted through this shell script in the browser. But how did it get there?

The oldest log data on the server was December 19, 2011. At the very top of this log file were commands accessing c99.php, so I couldn’t really be sure how it got on there, but I had a couple guesses:

1) The most likely scenario I thought was that the attacker was able to leverage the file upload feature of the dated CMS – either by accessing it without an account, or by brute forcing an administrative account with a weak password.

2) There was no hardware firewall protecting connections to the server, and there were many legacy FTP and SSH accounts festering that hadn’t been properly removed when they were no longer needed. One of these accounts could have been brute forced – more likely an FTP account with limited access; otherwise a shell script wouldn’t really be necessary to interact with the server.

The log entries associated with c99.php were extremely interesting. There would be 50 or so GET requests, which would run commands like:

cd, ps aux, ls -al

Then there would be a POST request, which would either put a new file in the current directory or modify an existing one.

This went on for tens of thousands of lines. The very manual and linear nature of the entries seemed to me very much like an automated process of some type.

SQL Injection

The SQL injection lines of the logs were also very exploratory in nature. There was a long period of information gathering and testing against a few different PHP pages to see how they responded to database code. Once the attacker realized that the site was vulnerable, the onslaught began and eventually they were able to discover the information schema and table names of pertinent databases. From there, it was just a matter of running through the tables one at a time pulling rows of data.

What Was The Attack After?

The motives were pretty clear at this point. The attacker was a) attempting to control the server to use in other attacks or send SPAM, and b) gather whatever sensitive information they could from databases or configuration files before moving on. Exploited user names and passwords could later be used in identity theft, for example. Both of the above motives are very standard for botnet-based attacks. It should be noted that the attacker was not specifically after HappyFeet – in fact they probably knew nothing about them – they just used automated probing to look for red flags and when they returned positive results,  assimilated the server into their network.

Let the Cleanup Begin

Now that the scope of the attack was more fully understood, it was time to start cleaning up the server. When I am conducting this phase of the project, I NEVER delete anything, no matter how obviously malicious or how benign. Instead, I quarantine it outside of the web root, where I will later archive and remove it for backup storage.

Find all the shell files

The first thing I did was attempt to locate all of the shell files that might have been uploaded by c99.php. Because my primary theory was that the shell file was uploaded through a file upload feature in the web site, I checked those directories first. Right away I saw a file that didn’t match the naming convention of the other files. First of all, the directory was called “pdfs” and this file had an extension of PHP. It was also called broxn.php, whereas the regular files had longer names with camel-case that made sense to HappyFeet. I visited this file in the web browser and saw a GUI-like shell interface. I checked the logs for usage of this file, but there were none. Perhaps this file was just an intermediary to get c99.php to the web root. I used a basic find command to pull a list of all PHP files from the web root forward. Obviously this was a huge list, but it was pretty easy to run through quickly because of the naming differences in the files. I only had to investigate ten or so files manually.

I found three other shell files in addition to broxn.php. I looked for evidence of these in the logs, found none, and quarantined them.

What files were uploaded or which ones changed?

Because of the insane amount of GET requests served by c99.php, I thought it was safe to assume that every file on the server was compromised. It wasn’t worth going through the logs manually on this point. The attacker had access to the server long enough that this assumption is the only safe one. The less frequent occurrences of POST requests were much more more manageable. I did a grep through the Apache logs for POST requests submitted by c99.php and came up with a list of about 200 files. My thought was that these files were all either new or modified and could potentially be malicious. I began the somewhat pain-staking process of manually reviewing these files. Some had been overwritten back to their original state by the hosting company’s backup, but some were still malicious and in place. I noted these files, quarantined them, and retested website functionality.

Handling the SQL injection vulnerabilities

The dated CMS used by this site was riddled with SQL injection vulnerabilities. So much so, that my primary recommendation for handling it was building a brand new site. That process, however, takes time, and we needed a temporary solution. I used the log data that I had to figure out which pages the botnet was primarily targeting with SQL attacks. I manually modified the PHP code to do basic sanitizing on all inputs in these pages. This immediately thwarted SQL attacks going forward, but the damage had already been done. The big question here was how to handle the fact that all usernames and passwords were compromised.

Improving Security

Now that I felt the server was sufficiently cleaned, it was time to beef up the security controls to prevent future attacks. Here are some of the primary tasks I did to accomplish this:

1) Added a hardware firewall for SSH and FTP connections.

I worked with the hosting company to put this appliance in front of the web server. Now, only specific IPs could connect to the web server via SSH and FTP.

2) Audited and recreated all accounts.

I changed the passwords of all administrative accounts on the server and in the CMS, and regenerated database passwords.

3) Put IP restrictions on the administrative console of the CMS.

Now, only certain IP addresses could access the administrative portal.

4) Removed all files related to install and database setup for the CMS.

These files were no long necessary and only presented a security vulnerability.

5) Removed all zip files from the web root forward and disabled directory listings.

These files were readily available for download and exposed all sorts of sensitive information. I also disabled directory listings, which is helpful in preventing successful information gathering.

6) Hashed customer passwords for all three sites.

Now, the passwords for user accounts were not stored in plain text in the database.

7) Added file integrity monitoring to the web server.

Whenever a file changes, I am notified via email. This greatly helps reduce the scope of an attack should it breach all of these controls.

8) Wrote a custom script that blocks IP addresses that put malicious content in the URL.

This helps prevent information gathering or further vulnerability probing. The actions this script takes operate like a miniature NetGladiator.

9) Installed anti-virus software on the web server.

10) Removed world-writable permissions from every directory and adjusted ownership accordingly.

No directory should ever be world writable – doing so is usually just a lazy way of avoiding proper ownership. The world writable aspect of this server allowed the attack to be way more broad than it had to be.

11) Developed an incident response plan.

I worked with the hosting company and HappyFeet to develop an internal incident response policy in case something happens in the future.

Public Response

Due to the fact that all usernames and passwords were compromised, I urged HappyFeet to communicate the breach to their customers. They did so, and later received feedback from users who had experienced identity theft. This can be a tough step to take from a business point of view, but transparency is always the best policy.

Ongoing Monitoring

It is not enough to implement the above controls, set it, and forget it. There must be ongoing tweaking and monitoring to ensure a strong security profile. For HappyFeet, I set up a yearly monitoring package that includes:

- Manual and automated log monitoring.

- Server vulnerability scans once a quarter, and web application scans once every six months.

- Manual user history review.

- Manual anti-virus scans and results review.

Web Application Firewalls

I experimented with two types of web application firewalls for HappyFeet. Both of which took me down the road of broken functionality and over-robustness. One had to be completely uninstalled, and the other is in monitoring mode because protection mode disallowed legitimate requests. It also is alerting to probing attempts about 5,000 times per day – most of which are not real attacks – and the alert volume is unmanageable. Its only value is in generating data for improving my custom script that is blocking IPs based on basic malicious attempts.

This is a great example of how NetGladiator can provide a lot of value to the right environment. They don’t need an intense, enterprise-level intrusion prevention system – they just need to block the basics and not break functionality in their web sites. The custom script, much like NetGladiator, suits their needs to a T and can also be configured to reflect previous attacks and vulnerabilities I found in their site that are too vast to manually patch.

Lessons Learned

Here are some key take-aways from the above project:

- Being PROACTIVE is so much better than being REACTIVE when it comes to web security. If you are not sure where you stack up, have an expert take a look.

- Always keep software and web servers up to date. New security vulnerabilities arrive on the scene daily, and it’s extremely likely that old software is vulnerable. Often, security holes are even published for an attacker to research. It’s just a matter of finding out which version you have and testing the security flaw.

- Layered security is king. The security controls mentioned above prove just how powerful layering can be. They are working together in harmony to protect an extremely vulnerable application effectively.

If you have any questions on NetGladiator, web security, or the above case study, feel free to contact us any time! We are here to help, and don’t want you to ever experience an attack similar to the one above.

Posted in Business Advice, Commentary and Editorials, Security, Topics. Tags: , . 1 Comment »

What to Do If Your Organization Has Been Hacked

April 27, 2012 — netequalizer

By Zack Sanders – Security Expert – APconnections

It’s a scary scenario that every business fears; a successful attack on your web site that results in stolen information or embarrassing defacement.

From huge corporations, to mom-and-pop online shops, data security is (or should be) a keystone consideration. As we’ve written about before, no one is immune to attack – not even local businesses with small online footprints. I, personally, have worked with many clients whom you would not think would be targeted by hackers, and they end up being the victims of reasonably intricate and damaging attacks that cost many thousands of dollars to mitigate.

Because no set of security controls or solutions can make you truly safe from exploitation, it is important to have a plan in place in case you do get hacked. Having a documented plan ready BEFORE an attack occurs allows you to be calm and rational with your response. Below are some basic steps you should consider in an incident response plan and/or follow in case a breach occurs.

1) Stay calm.

An attack, especially one in progress, naturally causes panic. While understandable, these feelings will only cause you to make mistakes in handling the breach. Stay calm and stick to your plan.

2) DO NOT unplug the system.

Unplugging the affected system, deleting malicious files, or restoring to a backup are all panic-driven responses to a security incident. When you take measures such as these, you potentially destroy key evidence in determining what, if anything, was taken, how it was taken, and when. Leave the system in place and call an expert as soon as possible.

3) Call an expert.

There are many companies that specialize in post-breach analysis, and it is important to contact these folks right away. They can help determine how the breach occurred, what was taken, and when. They can also help implement controls and improve security so that the same attack does not happen again. If you’ve been hacked, this is the most important step to take.

4) Keep a record.

For possible eventual legal action and to simply keep track of system changes, always keep a record of what has happened to the infected system – who has touched it, when, etc.

5) Determine the scope of the attack, stop the bleeding, and figure out what was taken.

The expert you phoned in will analyze the affected system and follow the steps above. Once the scope is understood, the system will be taken offline and the security hole that caused the problem will be discovered and closed. After that, the information that was compromised will be reviewed. This step will help determine how to proceed next.

6) Figure out who to tell.

Once you’ve determined what kind of information was compromised, it is very important to communicate that to the right people. If it was internal documents, you probably don’t need to make that public. If it was usernames and passwords, you must let your users know.

7) Have a security assessment performed and improve security controls.

Have your expert analyze the rest of your infrastructure and web applications for security holes that could be a problem in the future. After this occurs, the expert can recommend tools that will vastly improve your security layering.

Of course, many of these tasks can be performed proactively to greatly reduce the likelihood of ever needing this process. Contact an expert now and have them analyze your systems for security vulnerabilities.

Posted in Security. Tags: , . 1 Comment »

Do We Really Need SSL?

April 22, 2012 — netequalizer

By Art Reisman, CTO, www.netequalizer.com, www.netgladiator.net.

Art Reisman CTO www.netequalizer.com

I know that perception is reality, and sometimes it is best to accept it, but when it comes to security, FUD, I get riled up.

For example, last year I wrote about the un-needed investment surrounding the IPV4 demise, and, as predicted, the IPv6 push turned out to be mostly vendor hype motivated by a desire to increase equipment sales. Today, I am here to dispel the misplaced fear around the concept of having your data stolen in transit over the Internet. I am referring to the wire between your residence and the merchant site at the other end. This does  not encompass the security of data once it is stored on disk drive at its final location, just the transit portion.

To get warmed up, let me throw out some analogies.

Do you fear getting carjacked going 75 mph on the interstate?

Most likely not, but I bet you do lock your doors when stopped.

Do you worry about encrypting your cell phone conversations?

Not unless you are on security detail in the military.

As with my examples, somebody stealing your credit card while it is in transit, although possible, is highly impractical; there are just better ways to steal your data.

It’s not that I am against VPN’s and SSL, I do agree there is a risk in transport of data. The problem I have is that the relative risk is so much lower than some other glaring security holes that companies ignore because they are either unaware, or more into perception than protecting data. And yet, customers will hand them financial data as long as their web site portal provides SSL encryption.

To give you some more perspective on the relative risk, let’s examine the task of stealing customer information in transit over the Internet.

Suppose for a moment that I am a hacker. Perhaps I am in it for thrills or for illegal financial gain, either way, I am going to be pragmatic with my approach and maximize my chances of finding a gold nugget.

So how would I go about stealing a credit card number in transit?

Option 1: Let’s suppose I parked in the alley behind your house and had a device sophisticated enough to eaves drop your wireless router and display all the web sites you visited. So now what? I just wait there, and hope perhaps in a few days or weeks you’ll make an online purchase and I’ll grab your cc information, and then I’ll run off and make a few purchases.  This may sound possible, and it is, but the effort and exposure would not be practical.

Option 2: If I landed a job at an ISP, I could hook up a sniffer that eaves drops on every conversation between the ISP customers and the rest of the Internet. I suppose this is a bit more likely than option 1;  but there is just no precedent for it – and ISPs often have internal safeguards to monitor and protect against this. I’d still need very specialized equipment and time to work unnoticed to pull this off. I’d have to limit my thefts to the occasional hit and run so as not to attract suspicion. The chances of economic benefit are slim, and the chances of getting caught are high, and thus the risk to the customer is very low.

For the criminal intent on stealing data, trolling the internet with a bot looking for unsecured servers, or working for a financial company where the data resides, and stealing thousands of credit cards is far more likely. SSL does nothing to prevent the real threats, and that is why you hear about hacking intrusions in the headlines everyday. Many of these break-ins could be prevented, but it takes a layered approach, not just a feel good SSL layer that we could do without.

Posted in IPv6, Security, Topics. Tags: , , . 2 Comments »

Common NetGladiator Questions Explained

April 17, 2012 — netequalizer

Since our last security-related blog post, The Truth About Web Security (And How to Protect Your Data), we’ve received many inquiries related to NetGladiator and best-practice security in general. In the various email and phone conversations thus far, we’ve encountered some recurring questions that many of you might also find useful. The purpose of this post is to provide answers to those questions.

1) Could an attacker circumvent NetGladiator by slowly probing the targets as not to be detected by the time anomaly metrics?

The NetGladiator detects multiple types of anomalies. Some are time-frequency based, and some are pattern based.

For instance, a normal user won’t be hitting 500 pages/minute, and a normal user will never be putting SQL in the URL attempting an injection. If a malicious user was slowly running a probing robot, it would likely still be attempting patterns that the NetGladiator would detect, and the NetGladiator would immediately block that IP. There are directory brute force tools that won’t hit on any patterns, but they will hit on the time frequency settings. If the attacker were to slow it down to a normal user click-rate, it’s possible they could go undetected, but these brute force lists rely on trying millions of common page and directory names quickly. It would not be worth it to run through this list at that pace.

2) Could a hacker change their IP address often enough so that NetGladiator would not think the source of the attack was the same?

The amount of IP addresses you’d need to spoof would make this a tiresome effort for the attacker, and in an automated attack by a botnet, the probe is more likely to just move on to a new target. In a targeted attack, IP spoofing, while possible, would also likely be more of a hassle than it’s worth. But, even if it were worth it for the attacker, the NetGladiator alerts admins to intrusion attempts, so you can proactively deal with the threat. You can also block by IP Range/Country so that if you notice someone spoofing IP addresses from a specific IP range, you can drop all those connections for as long as you like.

Also with regard to IP addresses, the NetGladiator only bans them for a set amount of time. This is because bots probe from new IP addresses all the time. A real user might eventually end up with that IP and you wouldn’t want to block it forever. That being said, if there was a constantly malicious IP, you can permanently block it.

3) Why is there a maximum number of patterns you can input into NetGladiator?

One of NetGladiator’s key differentiating factors is its “robustlessness” and its custom configuration. This may sound like a detriment, but it actually will make you better off. Not only will you be able to exclusively detect threats pertinent to your web application, you also will not break functionality – regardless of poor programming or setup on the back end. Many intrusion prevention systems are so robust in their blocking of requests that there are too many false positives to deal with (usually based on programming “errors” or infrastructure abnormalities). This often ends with the IPS being disabled – which helps no one. NetGladiator has a maximum number of patterns for one main reason:

Speed and efficiency.

We don’t want to hamper your web connections by inspecting packets for too many regular expressions. We’d rather quickly check for key patterns that show malicious intent under the assumption that those patterns will be tried eventually by an attacker. This way, data can seamlessly pass through, and your users won’t incur performance problems.

4) What kind of environments benefit from NetGladiator?

NetGladiator was built to protect web applications from botnets and hackers – it won’t have much use for you at the network level or the user level (email, SPAM, anti-virus, etc.). There are other options for security controls that focus on these areas. Every few years, the Open Web Application Security Project (OWASP), releases their Top 10 – which is a list of the most common web application security vulnerabilities facing sites today. NetGladiator helps protect against issues of this type, so any web application that has even a small amount of interactivity or backend to it will benefit from NetGladiator’s features.

We want to hear from you!

Have some questions about NetGladiator or web security in general? Visit our website, leave a comment, or shoot us an email at ips@apconnections.net.

Posted in Security. Tags: . Leave a Comment »

The Truth About Web Security (And How to Protect Your Data)

March 28, 2012 — netequalizer

By Zack Sanders – Security Expert at APconnections.

Security Theater

Internet security is an increasingly popular and fascinating subject that has pervaded our lives through multiple points of entry in recent years. Because of this infiltration, security expertise is no longer a niche discipline teetering on the fringe of computer science – it’s an integral part. Computer security concerns have ceased to be secondary thoughts and have made their way to the front lines of business decisions, political banter, and legislative reform. Hackers are common subjects in movies, books, and TV shows. It seems like every day we are reading about the latest security breach of a gigantic, international conglomerate. Customers who once were naive to how their data was used and stored are now outwardly concerned about their privacy and identity theft.

This explosion in awareness has, of course, yielded openings for the opportunistic. Companies now know there is a real business need for security, and there are thus hundreds of solutions available to you to improve your security footprint. But most of them are not telling you the truth about how to really secure your infrastructure. They just want to sell you their product – hyping its potential, touting its features, and telling you to install it and – *poof* – you no longer need to worry about security – something those in the industry call “Security Theater.” In many ways, these companies are actually making you less secure because of this sales point. Believing that you can plug in an “all-in-one device” and have it provide you with all of your security controls sounds good, but it’s unrealistic. When you stop being diligent on multiple levels, you start being vulnerable.

Real security is all about two things:

1) Being PROACTIVE.
2) Implementing LAYERED security controls.

Let’s briefly discuss each of these central tenants of best-practice security.

1) Being proactive is key for many reasons. When you are proactive with security, you are anticipating attacks before they start. This allows you to more calmly implement security controls, develop policies, and train staff before a breach occurs. You should be proactive about security for the same reasons you are proactive about your health. Eating well, exercising, and periodically seeing a doctor are all ways to improve your chances of remaining healthy. It doesn’t guarantee you won’t get sick, much in the same way security controls won’t guarantee you won’t get hacked, but it does greatly improve your odds. And if you are not proactive, just like with your personal health, if something does go wrong, it can often be too late to reverse the effects, as most of the damage has already been done.

2) Implementing a layered approach to security is paramount in reducing the odds of a successful attack. The goal is to take security controls that complement each other on different levels of your infrastructure and piece them together to form a solid line of defense. If one control is breached, another is there to back it up in a different, but equally effective way. It is actually possible to take products that are relatively ineffective on their own (say 75% effective), and layer them to lower the chances of a successful attack to less than 1%. If you implement just four 75%-effective tools, say, check out what your breach success rate becomes: (.25 * .25 * .25 *.25) = .0039 * 100 = 0.39%! That’s pretty impressive!

Here is an analogy

Think of your sensitive data as crown jewels that are stored in the center of a castle. If your only security control is a moat, it wouldn’t take much ingenuity for a thief to cross over the moat and subsequently steal your jewels. One thing we can do to improve security is better our moat. Let’s add some crocodiles – that will certainly help in thwarting would-be crossers. But, even though we’ve beefed up the security of the moat, it’s still passable. The problem is that we can never 100% secure the moat from thieves no matter what we do. We need to add in some complementary controls to back up the security of the moat in case the moat fails. So, we’ll place archers at the four corner towers and install a big door with multiple locks and guards at the front gate. We’ll move the jewels to the cellar and place them under lock and key with a designated guard. Knights will be trained to spot thieves, and there will be a checkpoint outside the castle for all incoming and outgoing guests. Now, instead ofhaving to just cross the moat, a thief would also have to get through the heavy door, through the locks, past the guards, past the archers, into the cellar, past another guard, and into the locked room. On exit, he’d have to get through all these again, including a manual search at the checkpoint. That seems tough to do compared to just crossing the moat.

Your web security infrastructure should work the same way. Multiple policies, devices, and configurations should all work in harmony to protect your sensitive data. When companies are trying to sell you an all-in-one security device, they are essentially trying to sell you a very robust moat. It’s not that their product won’t provide value, but it needs to be implemented as part of an overall security strategy, and it should not be solely relied upon.

How Real Attacks Occur

We have thought a lot lately about exactly how real attacks occur in the wild for organizations with interactive web applications. This is slightly simplistic, but it really seems to boil down to two key origins:

1) A hack results from an AUTOMATED scan or probe.

This is by far the most common type of attack, despite it not being as popular as the other. Many organizations don’t take this type of attack as seriously as they should. They think that just because they are a small, non-influential site with little customer data that they won’t be targeted. And they are probably right – a human attacker won’t be targeting them. But a robot has no discretion. The robot’s goal is to increase hosts in their botnet (for DOS attacks, sending SPAM, etc.), and to siphon off any available sensitive data from the server. The botnets are constantly scouring the Internet, rapidly attempting breaches with known, common patterns. They don’t get too sophisticated.

2) A hack results from a TARGETED attack.

The media has hyped this into the most popular type of attack, but it is much less common. Targeted attacks can begin from multiple motivations. Sometimes, a targeted attack will occur due to interesting results from an automated scan (as in #1, above). The other type of targeted attack is the most dangerous – an attacker, or group of attackers, specifically targeting your site for financial or political reasons. Despite what other products might profess, there is no one-stop solution for stopping this type of attack. A layered approach to security, as discussed above, is key.

Approaches to Dealing with Botnets/Malnets and other Automated Attacks

Botnets are large, distributed networks of private computers and servers that are infected with malicious software without the owner of the system being aware. The botnet computers can be used to scan targets for vulnerabilities or send out SPAM/malicious emails. Using systems registered to someone else provides a layer of anonymity to the attacker. He/she also has increased processing power and resources available at their disposal. Botnets rely heavily on attempting simple intrusions and speed. They often are brute forcing directory listings or credentials and once they’ve exhausted their lists, they move on.

There are a few things you can do to greatly lower the effectiveness of a botnet:

1) Think about if your website really needs to be open to the entire Internet. Are there countries/subnets that you will never receive business from? Why not just block these IP ranges right off the bat? It seems harsh at first, but if you think about it, there is a lot of added security value here for the small risk you turn away a legitimate customer.

2) Implement a tool that monitors the amount of requests received over a given time frame. A normal user won’t ever be requesting pages at the same rate as a botnet. If the request count reaches past a certain threshold, you can confidently block the offending IP.

3) Implement a tool that monitors logs for multiple 404 (Page Not Found) requests. Brute-force tools will generate plenty of 404 requests when they are hammering your servers. If you see multiple 404′s over a short period of time from the same IP, chances are good they are acting maliciously.

4) Look for common patterns in logs that suggest malicious intent. The information discovery process is very important for an attacker (or botnet). It is during this phase that they learn about possible vulnerabilities your sites might have. In order to find these holes, the attacker has to experiment with the site to see how it responds to malicious code. If you can isolate these probing attempts right off the bat, you stand a good chance at cutting off the information gathering process before they get results on potential attack vectors.

5) Implement a file integrity monitoring tool on your web server and have it actively alert to changes in files that are not supposed to change often. If an attacker finds an entry point, one of the first things they will try and do is upload a file to the server. Getting a file to the server is a huge accomplishment for an attacker. They can upload PHP or ASP files that act as shell interfaces to the server itself, and from there can wreak whatever havoc they’d like. With a file integrity monitoring tool, you can know if an file is added within minutes of upload and can deal with the threat before it is wide spread.

The NetGladiator

NetGladiator is a next-generation Intrusion Prevention System (IPS) made by APconnections that deals with some of the issues above and was built based on how attacks actually occur. It can be an effective layer in your security profile to help block unwanted web-based requests (either from a botnet or a targeting attacker) – you can think of it as a firewall for your web applications. In addition to handling web requests, it can detect time-based anomalies and block IP ranges by country and/or subnet.

NetGladiator has two primary goals:

1) Make your web infrastructure INVISIBLE and UNINTERESTING to probing botnets.
2) Provide value as a LAYERED appliance in case of a targeted attack.

NetGladiator also has some of the following aspects that set it apart from more expensive, overly robust IPS’s:

Customizable Configurations
Unlike other IPSs with insanely robust pattern sets, NetGladiator lets you pick and choose the patterns you’d like it to hit on. Other products inspect for every vulnerability known to man. While this sounds good, it isn’t very practical and often leads to broken functionality, false positives, and total reliance.

Support From a White Knight (a.k.a Professional Hacker)
As part of your support agreement when you purchase a NetGladiator, a real, white knight will help you set up and configure your machine to meet your needs. This includes identifying and patching any existing holes prior to your installation, deciding what issues you might face from a real attacker, and writing you a custom configuration for your box. That’s something that no one else provides – especially at this price point. And, if you want further security assessments performed, additional support hours can be purchased.

Plug and Play
If you’ve set up a NetEqualizer in the past, you’ll find NetGladiator’s installation process to be even easier. Just put it in front of your web servers, cable the box correctly, and turn it on. Traffic will be passing through it instantly. Now all that’s left is to configure your patterns. NetGladiator comes with default patterns in case no customization is necessary. NetGladiator also runs on its own system, and does not require any installs to your web server. This makes it platform independent and will create zero conflicts with your existing software and hardware.

But remember, protecting web applications is just one piece of the puzzle. In order to layer NetGladiator into your overall security strategy, you should complement its use with other controls. Some examples would be:

- Well-defined user and staff policies that deal with insider threats and social engineering

- Full or column-level database encryption

- Anti-virus

- File integrity monitoring

- Hardware firewalls

- A security assessment by an expert

etc…

Questions?

Need help instituting a layered security strategy? We have experience in all these levels of security controls and are happy to help with NetGladiator implementation or other security-related tasks. Just let us know how we can be of service!

Have some questions about NetGladiator or web security in general? Visit our website, leave a comment, or shoot us an email at ips@apconnections.net. In the next blog post, we’ll answer those questions and also discuss common ones we’ve received from customers so far.

Posted in Security, Topics. Tags: . 4 Comments »

APconnections Releases FREE Version of Intrusion Detection and Prevention Device

March 2, 2012 — netequalizer

APconnections quietly released a free version of their IPS device yesterday. Codenamed StopHack, you can install this full-featured IPS with a little elbow grease on your own hardware. This powerful technology is used to detect and block hacker intrusion attempts before they get into your network.

Although the price is free for this version, under the hood, the StopHack software can handle about 10,000 simultaneous streams (users) hitting your network and will check every query for malformed and invasive URL’s. These type of attacks are the most dangerous and are typically exploited by probing bots to knock holes in your servers. StopHack also has a nice log where you can see who has attempted to breach your network, and a white list to exempt users from being scrutinized at all.

It comes with 16 of the most common intrusion techniques blocked, (more can be purchased with a support contract), and uses behavior-based techniques to differentiate a friendly IP from a non-friendly IP.

Click here for the StopHack FAQ.

Click here to get the download and installation instructions.

NOTE: StopHack is free to use but support must be purchased if you need help for any reason, including installation.

Posted in Bandwidth Monitoring, Security. Leave a Comment »

Five Great Ideas to Protect Your Data with Minimal Investment

February 27, 2012 — netequalizer

We see quite a bit of investment when it comes to data security. Many solutions are selected on the quantity of threats deterred. Large feature sets, driven by FUD, are exponential in cost, and at some point the price of the security solution will outweigh the benefit. But where do you draw the line?

Note:

1) It is relatively easy to cover 95 percent of the real security threats that can damage a business’s bottom line or reputation.

2) It is totally impossible to completely secure data.

3) The cost for security starts to hockey stick as you push toward the mythical 100 percent secure solution.

For example, let’s assume you can stop 95 percent of potential security breaches with an investment of $10, but it would cost $10 million to achieve 99 percent coverage. What would you do? Obviously you’d stop someplace between 95 and 99 percent coverage. Hence, the point of this post. The tips below are intended to help with the 95 percent rule, what is reasonable and cost effective. You should never be spending more money securing an asset than that asset is worth.

Some real world examples of reducing practical physical risk would be putting life jackets in a watercraft, or an airbag in an automobile. If we took the approach to securing your water craft or automobile with the FUD of data security, everybody would be driving 5 million dollar Abrams tanks, and trout fishing in double hulled aircraft carriers.

Below are some security ideas to protect your data that should greatly reduce your risk at a minimal investment.

1) Use your firewall to block all uninitiated requests from outside the region where you do business.

For example, let’s assume you are a regional medical supply company in the US. What is the likelihood that you will be getting a legitimate inquiry from a customer in China, India, or Africa? Probably not likely at all. Many hackers come in from an IP addresses originating in foreign countries, for this reason you should use your firewall to block any request outside of your region. This type of block will still allow internal users to go out to any Internet address, but will prevent unsolicited requests from outside your area.  The cost to implement such a block is free to very little, yet the security value is huge. According to many of our customers, just doing this simple block can reduce 90 percent of potential intrusions.

2) Have a security expert check your customer facing services for standard weaknesses. For a few hundred dollars, an expert can examine your security holes in just a few hours. A typical security hole often exploited by a hacker is SQL Injection – this is where a hacker inserts an SQL command in your URL or web form to see if the backend code executes the command. If it does, further exploration and exploitation will occur which could result in total system compromise. A good security expert can find most of these holes and make recommendations on how to remedy it in a few hours.

3) Install an IDPS (Intrusion Detection and Prevention System) in between your Internet connection and your data servers. A good IDPS will detect and block suspicious inquiries to your web servers and enterprise. There are even some free systems you can install with a little elbow grease.

4) Lay low, and don’t talk about your security prowess. Hackers are motivated by challenge. There are millions of targets out there and only a very small number of businesses get intentionally targeted with a concerted effort by a human. Focused hacking by a human takes a huge amount of resources and time on the part of the intruder. Without a specific motive to target your enterprise, the automated scripts and robots that crawl the internet will only probe so far and move on. The simple intrusion steps outlined here are very effective against robots and crawlers, but would be much less effective against a targeted intrusion. This is because there are often numerous entry points outside the web application – physical breaches, social engineering, etc.

5) Have an expert monitor your logs and the integrity of your file system. Combining automatic tools with manual review is an excellent line of defense against attack. Many organizations think that installing an automated solution will get them the security they need, but this is not the case. Well known virus scan tools that “analyze your web site for 25,000 vulnerabilities” are really just selling you security theater. While their scanning technology does help in many ways, combining the results of the scans with manual review and analysis is the only way to go if you care about good security. Our security friends at Fiddler on the Root, mentioned above, say they have a 100% success rate in hacking sites scanned with tools like McAfee.

File integrity monitoring is also extremely beneficial. Knowing right away that a file changed on your web server when nothing should have changed is very powerful in preventing an attack. Many attacks develop over time and if you can catch an attack early your chances of preventing its success are much greater.

Posted in Commentary and Editorials, Security. 1 Comment »

Seven Things to Look for When Choosing an Intrusion Prevention System

January 23, 2012 — netequalizer

The following list was submitted by the APconnections technical staff.

APconnections is a company that specializes in turn-key bandwidth control and intrusion prevention system (IPS) products.

1) Don’t degrade your network speed. Make sure your IPS system is not going to slow down your network. If you have a T1 or smaller sized network, chances are just about any tool you choose will not slow down your connection; however with links approaching 10 megabits and higher,  it is worth investing in a tool whose throughput speeds can be quantified. Higher speeds generally will require a tool specifically designed and tested as an IPS device and rated for your link speed. Problems can arise if you buy a software add-on module for your web server. A stand-alone physical device specifically designed to prevent intrusion is likely your best option. A good IPS system is very CPU intensive, and lower-end routers, switches, and heavily utilized web servers generally do not have the extra CPU cycles to support an IPS system. For example, IT managers are aware that large web server sites must use multiple servers to handle large volumes of HTTPS pages, which are also CPU intensive.  The same metrics will apply to an IPS system on a smaller scale,  so make sure you are not underpowered.

2) Watch out for high license fees. Try to get a tool with a one-time cost and a small licensing fee. Many vendors sell their equipment below cost with the hopes of getting a monthly fee on per seat license. Yes, you should expect to pay a yearly support fee, but it should be a small fraction of the tool’s original cost.

3) More features is not necessarily better when it comes stopping intrusion from hackers.  You may not realize that large, robust “all-in-one” IPS solutions can be rendered useless by alerting you thousands of times a day, as you will ignore their alerts at that volume.  They can also block legitimate requests (“false positives”), and can break web
functionality. They can also block legitimate requests (“false positives”), and can break web functionality.

You should consider solutions that are not as fully-featured but are targeted to your security concerns, so that you receive meaningful alerts on real potential intrusion attempts.  More features can just introduce clutter, where you are not able to sift through your alerts to find what you really care about.  Also, doing everything can dilute the mission of the toolset, so instead of doing one thing well, it does everything poorly.

Remember, the biggest threat to your enterprise is a person that breaks into your internal systems and attains access to your customer data.  A typical PC virus or Denial of Service (DoS) attack does not pose this type of threat.  Although it may be counter-intuitive to your experience, it is a good idea to make sure you have a solid intrusion detection system before investing in things like virus prevention, web-filters and reporting.  Yes, viruses are a pain and can bring down systems, but the damage will likely not compare in real cost to a hacker that steals your customer records.

4) Block first ask questions later.  An intruder usually behaves oddly when compared to a normal visitor. Your intrusion detection device should block first and ask questions later. It is better to accidentally block a small number of friendlies than to let one hacker into your network. You will get feedback if legitimate visitors are locked out from your website, and it won’t take long to hear from them if your intrusion device is accidentally blocking a friendly visitor.

5) Don’t rely on manpower for detection. Let the device do the work. If you are relying on a reporting system and a human to make a final decision on what to block, you will get hacked. Your device must be automated and on the job 24/7. There is nothing wrong with an analyst doing the follow-up.

6) Use a white knight to expose your security risks. There was an article in the Wall Street Journal today on how anybody can hire a professional hacker. What they failed to mention is that you can also hire a white knight to test your armor and let you know if you have any weaknesses. Most weaknesses are common back doors in web servers that can easily be remedied once exposed by a white knight.

7) Use a combination of techniques. The only way to 100 percent secure your enterprise is to block all outside access, and with the silo mentality of a some security zealots you could end up with this TSA mentality solution if not careful. Given the reality that you must have a public portal for your customers, the next best thing to locking them out is a combination of white knight testing, plugging holes in web servers and entry points and a permanent watch dog intrusion prevention system – this should keep you safe from a hacker.

Some good intrusion prevention links:

Lanner

Checkpoint

NetGladiator  (our product)

Solera Networks

SourceFIRE

Posted in Security. Tags: , , . 1 Comment »

Developing Technology to Detect a Network Hacker

January 21, 2012 — netequalizer

Editors note:  Updated on Feb 1st, 2012.  Our new product, NetGladiator, has been released.  You can learn more about it on the NetGladiator website at www.netgladiator.net or calling us at 303.997.1300 x123.

In a few weeks we will be releasing a product to automatically detect and prevent a web application hacker from breaking into a private enterprise. What follows are the details of how this product was born.  If you are currently seeking or researching intrusion detection & prevention technology, you will find the following quite useful.

Like many technology innovations, our solution resulted from the timely intersection of two technologies.

Technology 1: About one year ago we starting working with a consultant in our local tech community to do some programming work on a minor feature in our NetEqualizer product line. Fiddlerontheroot is the name of their company, and they specialize in ethical hacking. Ethical hacking is the process of deliberately hacking into a high-profile client company with the intention of exposing their weaknesses. The key expertise that they provided was a detailed knowledge of how to hack into a network or website.

Technology 2: Our NetEqualizer technology is well known for providing state-of-the-art bandwidth control. While working with Fiddler on the Root, we realized our toolset could be reconfigured to spot, and thwart, unwanted entry into a network. A key piece to the puzzle would be our long-forgotten Deep Packet Inspection technology. DPI is the frowned upon practice of looking inside data packets traversing the Internet.

An ironic twist to this new product journey was that, due to the privacy controversy, as well as finding a better way to shape bandwidth, we removed all of our DPI methodology from our core bandwidth shaping product four years ago.  Just like with any weapon, there are appropriate uses for DPI. Over a lunch conversation one day, we realized that using DPI to prevent a hacker intrusion was a legitimate use of DPI technology. Preventing an attack is much different from a public ISP scanning and censoring customer data.

So how did we merge these technologies to create a unique heuristics-based IPS system?

Before I answer that question, perhaps you are thinking that revealing our techniques might provide a potential hacker or competitor with inside secrets? More on this later…

The key to using DPI to prevent an intrusion (hack) revolves around 3 key facts:

1) A hacker MUST try to enter your enterprise by exploiting weaknesses in your normal entry points.

2) One of the normal entry points is a web page, and everybody has them. After all, if you had no publicly available data there would be no reason to be attached to the Internet.

3) By using DPI technology to monitor incoming requests and looking for abnormalities, we can now reliably spot unwanted intrusion attempts.

When we met with Fiddler on the Root, we realized that a normal entry by a customer and a probing entry by a hacker are radically different. A hacker attempts things that no normal visitor could even possibly stumble into. In our new solution we have directed our DPI technology to watch for abnormal entry intrusion attempts. This involved months of observing a group of professional hackers and then developing a set of profiles which clearly distinguish them from a friendly user.

What other innovations are involved in a heuristics-based Intrusion Prevention System (IPS)?

Spotting the hacker pattern with DPI was only part of a complete system. We also had to make sure we did not get any false positives – this is the case where a normal activity might accidentally be flagged as an intruder, and this obviously would be unacceptable. In our test lab we have a series of computers that act like users searching the Internet, the only difference is we can ramp these robot users up to hyper-speed so that they access millions of pages over a short period of time. We then measure our “false positive” rate from our simulation and ensure that our false positive rate on intrusion detection is below 0.001 percent.

Our solution, NetGladiator, is different than other IPS appliances.  We are not an “all-in-one solution”, which can be rendered useless by alerting you thousands of times a day, can block legitimate requests, and break web functionality.  We do one thing very well – we catch & stop hackers during their information discovery process – keeping your web applications secure.  NetGladiator is custom-configured for your environment, alerting you on meaningful attempts without false positive alerts.

We also had to dig into our expertise in real-time optimization. Although that sounds like marketing propaganda to impress somebody, we can break that statement down to mean something.

When doing DPI, you must look at and analyze every data stream and packet coming into your enterprise, skipping something might lead to a security breach. Looking at data and analyzing it requires quite a bit more CPU power than just moving it along a network. Many intrusion detection systems are afterthoughts to standard routers and switches. These devices were originally not designed to do computing-intensive heuristics on data. Doing so may slow your network down to a crawl, a common complaint with lower-end affordable security updates. We did not want to force our customers to make that trade-off. Our technology uses a series of processors embedded in our equipment all working in unison to analyze each packet of Internet data without causing any latency. Although we did not invent the idea of using parallel processing for analysis of data, we are the only product in our price range able to do this.

How did we validate and test our IPS solution?

1) We have been putting our systems in front of beta test sites and asking white knights to try to hack into them.

2) We have been running our technology in front of some of our own massive web crawlers. Our crawlers do not attempt anything abnormal but can push through millions of sites and web pages. This is how we test for false positives blocking a web crawler that is NOT attempting anything abnormal.

Back to the question, does divulging our methodology render it easier to breach?

The holes that hackers exploit are relatively consistent – in other words there really is only a finite number of exploitations that hackers use. They can either choose to exploit these holes or not, and if they attempt to exploit the hole they will be spotted by our DPI. Hence announcing that we are protecting these holes is more likely to discourage a hacker, who will then look for another target.

Posted in Security. Tags: , , , . Leave a Comment »

Hacking is Obvious, Why Can’t We Stop Them?

January 12, 2012 — netequalizer

Your website is just like any other business, whether it be a bank or a restaurant or a hardware store, a large majority of visitors are honest and enter with an intent to browse your information or perform a transaction. All legitimate customers follow a similar pattern. They browse your public HTML pages and perhaps interact with public fields and forms displayed on your site. Just like in a brick and mortar store, a normal cyber customer will observe basic rules of etiquette and stay within the boundaries of your web presence.

A hacker, on the other hand, is not likely to behave in any way close to a normal customer. If they did, they would not be very successful. A hacker will pound your website with force looking for a weaknesses. They will probe every nook and cranny of your web server until they find something to exploit. Their entry point could be one of those old orphaned web pages that you do not advertise, or they might create their own hole by inserting an SQL command within a URL. These kind of probes are way out of the ordinary and glaringly out-of-place.

Hacker intrusion is analogous to someone entering a brick and mortar store and proceeding to tip over shelves while scrounging on the floor for spilled documents. Imagine a customer asking rude questions to the sales clerk, and rattling doors off their hinges. At the very least, this behavior in the physical world would prompt a call to the police and a disorderly conduct charge.

So why is hacking so prevalent? Why isn’t the hacker immediately spotted and removed?

In many cases, hackers are detected and blocked, but all it takes is one. Just like my bank that is constantly turning off my credit cards every time I travel, a good business practice would be to err on the side of caution. Even accidentally locking out 1 in 1000 customers from your website is a much better proposition than letting one hacker in. The economic damage from a hacker is typically far worse than a short-term potential 0.1 percent drop in web visits.

In our opinion, there are several reasons why this solvable problem is so prevalent:

1) Broadbase security tools that try to do everything.

Businesses are sold an expensive set of tools that do many things unrelated to intrusion prevention. A tool that removes viruses from e-mails, prevents DOS attacks, or runs the generic firewall, is useful but the investment in a heuristics-based intrusion detection system is often on the light side of the all-in-one. Money spent on the broad-based tool is usually out of proportion with the potential economic damage of a real attack.

For example, you might lose a day of business if a virus gets loose in your enterprise and brings down a few workstations; however, the potential loss of stolen property and the damage to brand reputation that can be wreaked by a hacker is a magnitude above a nuisance virus infecting your laptops.

2) Businesses may not have the resources for an expensive tool, so they use what is at hand as best they can. We can certainly understand cash flow issues and where to spend resources. Look for some breakthroughs in cost with commercial hacker prevention tools in the near-term. A focused tool can be put in place at a reasonable cost, and does not require an IT staff to maintain.

3) Businesses cultures can get hung up on analysis of data, and don’t realize they must trust their security to a computer that makes decisions now. A hacker must be detected and blocked immediately. Many businesses may hesitate to use an automated tool, as it certainly may make a mistake and block a friendly user. However as we have mentioned above, blocking an occasional friendly user can be mitigated. Explaining the loss of 10,000 credit card numbers is hard to recover from.

So how does a good intrusion tool stop a hacker without an army of IT people?

It simply needs to quickly quantify abnormal behavior and block the IP immediately, with no questions asked or any hesitation. There really is no need to wait. The signs of intrusion are so different from a normal customer that you can with 99.99 percent accuracy toss them out before damage is done. In the coming few months we will be introducing a new turn-key product that will work like this.

Won’t the hacker try to subvert a heuristic tool once they suspect it is guarding your site?

Even if the hacker is trying to break through a heuristic based tool, the problem for the hacker is in order to get access to something they are not supposed to have, they will have to do something odd at some point, acting normal won’t cut it, and acting abnormal will get flagged. The tool will alert administrators to suspicious behavior and block the IP address of the malicious user. Now, with their increased alertness, administrators can lock down interfaces, manually review logs, and focus their diligence on the attack at hand.

—————————————————————————————————————————————————-
Editor’s note: update 01/23/2012

A wall street journal article came out today exposing how easy it is to hire  a hacker. If you think about it, the media likes to portray a hacker as some kind of amazing brilliant savant with super human powers. The truth is, tools to hack are readily available, and anybody with a background in computers and suspect moral character can do it. It also supports our premise that stopping a hacker is just a matter of plugging the common holes and entry points.

Editor’s note: update on 02/01/2012
Today APconnections, maker of the NetEqualizer, released a new intrusion prevention system (IPS) product, the NetGladiator, which is designed to detect & prevent network intrusions. You can learn more about NetGladiator at www.netgladiator.net or by calling us at 303.997.1300 x123.

Posted in Security, Topics. Leave a Comment »

Cloud Computing – Do You Have Enough Bandwidth? And a Few Other Things to Consider

December 10, 2011 — netequalizer

The following is a list of things to consider when using a cloud-computing model.

Bandwidth: Is your link fast enough to support cloud computing?

We get asked this question all the time: What is the best-practice standard for bandwidth allocation?

Well, the answer depends on what you are computing.

- First, there is the application itself.  Is your application dynamically loading up modules every time you click on a new screen? If the application is designed correctly, it will be lightweight and come up quickly in your browser. Flash video screens certainly spruce up the experience, but I hate waiting for them. Make sure when you go to a cloud model that your application is adapted for limited bandwidth.

- Second, what type of transactions are you running? Are you running videos and large graphics or just data? Are you doing photo processing from Kodak? If so, you are not typical, and moving images up and down your link will be your constraining factor.

- Third, are you sharing general Internet access with your cloud link? In other words, is that guy on his lunch break watching a replay of royal wedding bloopers on YouTube interfering with your salesforce.com access?

The good news is (assuming you will be running a transactional cloud computing environment – e.g. accounting, sales database, basic email, attendance, medical records – without video clips or large data files), you most likely will not need additional Internet bandwidth. Obviously, we assume your business has reasonable Internet response times prior to transitioning to a cloud application.

Factoid: Typically, for a business in an urban area, we would expect about 10 megabits of bandwidth for every 100 employees. If you fall below this ratio, 10/100, you can still take advantage of cloud computing but you may need  some form of QoS device to prevent the recreational or non-essential Internet access from interfering with your cloud applications.  See our article on contention ratio for more information.

Security: Can you trust your data in the cloud?

For the most part, chances are your cloud partner will have much better resources to deal with security than your enterprise, as this should be a primary function of their business. They should have an economy of scale – whereas most companies view security as a cost and are always juggling those costs against profits, cloud-computing providers will view security as an asset and invest more heavily.

We addressed security in detail in our article how secure is the cloud, but here are some of the main points to consider:

1) Transit security: moving data to and from your cloud provider. How are you going to make sure this is secure?
2) Storage: handling of your data at your cloud provider, is it secure once it gets there from an outside hacker?
3) Inside job: this is often overlooked, but can be a huge security risk. Who has access to your data within the provider network?

Evaluating security when choosing your provider.

You would assume the cloud company, whether it be Apple or Google (Gmail, Google Calendar), uses some best practices to ensure security. My fear is that ultimately some major cloud provider will fail miserably just like banks and brokerage firms. Over time, one or more of them will become complacent. Here is my check list on what I would want in my trusted cloud computing partner:

1) Do they have redundancy in their facilities and their access?
2) Do they screen their employees for criminal records and drug usage?
3) Are they willing to let you, or a truly independent auditor, into their facility?
4) How often do they back-up data and how do they test recovery?

Big Brother is watching.

This is not so much a traditional security threat, but if you are using a free service you are likely going to agree, somewhere in their fine print, to expose some of your information for marketing purposes. Ever wonder how those targeted ads appear that are relevant to the content of the mail you are reading?

Link reliability.

What happens if your link goes down or your provider link goes down, how dependent are you? Make sure your business or application can handle unexpected downtime.

Editors note: unless otherwise stated, these tips assume you are using a third-party provider for resources applications and are not a large enterprise with a centralized service on your Internet. For example, using QuickBooks over the Internet would be considered a cloud application (and one that I use extensively in our business), however, centralizing Microsoft excel on a corporate server with thin terminal clients would not be cloud computing.

Posted in Business Advice, Commentary and Editorials, Security. Tags: , . 1 Comment »

How Safe is The Cloud?

December 7, 2011 — netequalizer

By Zack Sanders, NetEqualizer Guest Columnist

There is no question that cloud-computing infrastructures are the future for businesses of every size. The advantages they offer are plentiful:

  • Scalability – IT personnel used to have to scramble for hardware when business decisions dictated the need for more servers or storage. With cloud computing, an organization can quickly add and subtract capacity at will. New server instances are available within minutes of provisioning them.
  • Cost – For a lot of companies (especially new ones), the prospect of purchasing multiple $5,000 servers (and to pay to have someone maintain them) is not very attractive. Cloud servers are very cheap – and you only pay for what you use. If you don’t require a lot of storage space, you can pay around 1 cent per hour per instance. That’s roughly $8/month. If you can’t incur that cost, you should probably reevaluate your business model.
  • Availability – In-house data centers experience routine outages. When you outsource your data center to the cloud, everything server related is in the hands of industry experts. This greatly increases quality of service and availability. That’s not to say outages don’t occur – they do – just not nearly as often or as unpredictably.

While it’s easy to see the benefits of cloud computing, it does have its potential pitfalls. The major questions that always accompany cloud computing discussions are:

  • “How does the security landscape change in the cloud?” – and -
  • “What do I need to do to protect my data?”

Businesses and users are concerned about sending their sensitive data to a server that is not totally under their control – and they are correct to be wary. However, when taking proper precautions, cloud infrastructures can be just as safe – if not safer – than physical, in-house data centers. Here’s why:

  • They’re the best at what they do – Cloud computing vendors invest tons of money securing their physical servers that are hosting your virtual servers. They’ll be compliant with all major physical security guidelines, have up-to-date firewalls and patches, and have proper disaster recovery policies and redundant environments in place. From this standpoint, they’ll rank above almost any private company’s in-house data center.
  • They protect your data internally – Cloud providers have systems in place to prevent data leaks or access by third parties. Proper separation of duties should ensure that root users at the cloud provider couldn’t even penetrate your data.
  • They manage authentication and authorization effectively – Because logging and unique identification are central components to many compliance standards, cloud providers have strong identity management and logging solutions in place.

The above factors provide a lot of piece of mind, but with security it’s always important to layer approaches and be diligent. By layering, I mean that the most secure infrastructures have layers of security components that, if one were to fail, the next one would thwart an attack. This diligence is just as important for securing your external cloud infrastructure. No environment is ever immune to compromise. A key security aspect of the cloud is that your server is outside of your internal network, and thus your data must travel public connections to and from your external virtual machine. Companies with sensitive data are very worried about this. However, when taking the following security measures, your data can be just as safe in the cloud:

  • Secure the transmission of data – Setup SSL connections for sensitive data, especially logins and database connections.
  • Use keys for remote login – Utilize public/private keys, two-factor authentication, or other strong authentication technologies. Do not allow remote root login to your servers. Brute force bots hound remote root logins incessantly in cloud provider address spaces.
  • Encrypt sensitive data sent to the cloud – SSL will take care of the data’s integrity during transmission, but it should also be stored encrypted on the cloud server.
  • Review logs diligently – use log analysis software ALONG WITH manual review. Automated technology combined with a manual review policy is a good example of layering.

So, when taking proper precautions (precautions that you should already be taking for your in-house data center), the cloud is a great way to manage your infrastructure needs. Just be sure to select a provider that is reputable and make sure to read the SLA. If the hosting price is too good to be true, it probably is. You can’t take chances with your sensitive data.

About the author:

Zack Sanders is a Web Application Security Specialist with Fiddler on the Root (FOTR). FOTR provides web application security expertise to any business with an online presence. They specialize in ethical hacking and penetration testing as a service to expose potential vulnerabilities in web applications. The primary difference between the services FOTR offers and those of other firms is that they treat your website like an ACTUAL attacker would. They use a combination of hacking tools and savvy know-how to try and exploit your environment. Most security companies  just run automated scans and deliver the results. FOTR is for executives that care about REAL security.

Posted in Commentary and Editorials, Security. Tags: , . 2 Comments »
Follow

Get every new post delivered to your Inbox.