New technologies, some new approaches and a plethora of products (wrapped up in fancy new terms) keep appearing on the market, but, what’s really changing in terms of bottom line protection and security?

www.computerworld.com.au/index.php/id;748050467;fp;4;fpid;16
www.computerworld.com.au/index.php/id;349496118;fp;16;fpid;1

From what we are seeing, a reliance on technology alone is still rife out there. Organisations are still buying IDS / IPS systems and see these systems as the silver bullet to their perimeter and in some cases, internal security needs.

I asked some of the Security-Assessment.com team recently their thoughts on IDS / IPS and firewalls and what impacts we have seen in our ability to perform web application / penetration testing. Here’s a summary of some of the comments. I hope you find this interesting:
———————————
The success of these things as we all know depends on the implementation and skill of the analyst deploying and managing the systems. Even then, to rely on these things as the solution is dicey. In the majority of cases, they just don’t end up doing what they were purchased for. An easy test that most fail is with basic port scans (that almost all are configured to pick up). We assume most are picking up “loud” scans (really fast and obvious scans with no attempt to be sneaky about what we are doing), but few people are pulling us up on this. (Keep in mind, with a majority of our tests, we recommend that clients don’t tell the operations team responsible for monitoring these devices that we are going to test – thereby, we also test the response effectiveness). Where such packets are being dropped, as we expect they would, by slowing down the scans, we generally get the desired result we’re looking for!”

Most of the IDS we come across is Snort. While it is a real-time IDS, people use it as a batch mode audit tool, to review data after the fact. This doesn’t effect our testing. Few non-government client’s perimeter defences actually impact upon our ability to perform our testing work. I can’t remember the last time this happened. We generally only get picked up (and even then, just on basic port scans – nothing clever) when the network team knows there is a test on at the time – otherwise, it’s free reign – standard at the application level.

An IPS only forces the attacker to know their exploits better, and take things slower. For instance, an IPS may drop all packets that have NOP sleds in them (0×909090 etc) which is used in a lot of (kind of sloppy) buffer overflows. It is however possible for an attacker to stop the IPS from seeing this. Eg:

1) remove the NOP sled and calculate the return address in the exploit properly.
2) play with encoding of the data and fragmentation of the packet
3) encrypt the packet.

Point 3 brings me to the major point about IDS / IPS. Network Encryption. Anything of value should be encrypted, and when you stop the bad guys from seeing your traffic, you also stop the good guys. There are ways around this, but the people who engineer the IDS/IPS implementations don’t always think it through. Sometime the mere existence of traffic is enough to cause alarm, without even needing to know what is in it. For instance, an SSH connection from the Internet to an internal host or an unauthorised VPN terminating on a workstation. But not always. HTTPS to web servers is often missed – which is a critical one.

As we know, the way around this (and many many other IDS/IPS bypasses) is proper design and administration. There are only a handful of people in Australia that know how to run an IDS properly….. and fewer companies that are willing to pay for their IPS to be administered to a useful level.. the whole system is just so expensive – with most implementations being a waste of time and good money. I could go on for hours.. but I guess that gives you the idea
————————————–

Personally, I just don’t see application inspection on web traffic. Of all the web jobs I have done in the last 3 years, not one carried a front end ‘box’ with the solution.
—————————–

In some cases, particularly with a certain FW’s application intelligence enabled (about 10% of jobs) our port scans get trapped in an endless loop and cannot properly complete. But even with this enabled, there is nothing to restrict what sort of packets reach web servers because all network firewalls pretty much allow anything through to 80, 443. Still haven’t come across an effective application layer firewall in our testing (or if I have I never noticed since it didn’t impact testing!)

IDS/IPS inside the network… rarely ever are effective because:
- they may remain un-updated with signatures
- no resources for log inspection/correlation/reporting/incident mgmt (unless you are military?)

Also, in many jobs, we find firewall rules are not secure enough. i.e. you can get past certain rules by flipping your source port or other parameters to certain values
—————————————-

In summary, we are seeing a growth in the deployment of perimeter defences but surprisingly, we’re not being impacted in our ability to crack system defences and discover major weaknesses in the network and application environments. So what are these systems doing in most organisations?

www.securityfocus.com/firewalls
www.securityfocus.com/ids

On the flipside, very few organisations are investing in vulnerability assessment and management solutions – go there first I would recommend and proactively fix your vulnerabilities so even if someone or something (eg; worms) get by the FW, IDS and IPS (and they will!), there shouldn’t in most cases (I say most), be anything to do on your hosts and other network devices. Applications are another beast – develop securely and test, test, test – throughout the SDLC and regularly in production!

The Jericho Forum approaches perimeter security from an entirely different vein. If you’re not up to speed with what’s happening here, it’s worth a read.

www.opengroup.org/jericho/