Friday, January 20, 2012

Layer 7 Security

With every passing second the cyber attacks are getting more and more complex, making it hard to detect. Most of the attacks are executed in a stealth mode, where most of the radars fail to detect these attacks. Surprisingly, the focus of hackers have changed from cracking down a website to cracking down of applications.

This calls for changing the vocabolary of Security and make them point to the root level of the infections. I understand, what ever it takes ,mit cannot go beyond OSI layers, then why not we start repersenting the security with OSI Model.

So now what we are talking about, is to secure the application layers and we call it as LAYER 7 Security. While we say it as Layer 7 Seurity, it is actually securing the appkication layers starting from SESSION to APPLICATION layers. Sounds interesting...right

On a fundamental ground, we are putting some security measures to prevent our applications to fall into the traps of application service worms. For an example, we use OUTLOOK as a mail client and also use the same application through internet. Logically this application simultaenously works on SMTP/25 and HTTP/80 ports and gives the same output. Now if we have to infect this application, we know that there is an open channel on which this application is working. This clears our first level of information gathering on creating a point of infection.

Funniest part is, we usually neglect the possibilities of application infection. We feel the application created is secured and will work smoothly in any conditions and what ever the problems would arise will be only from infrastructure hosting the application. That is the reason, we put all our efforts in securing our infrastructure leaving the application as it is.

OWASP talks heavily on securing the application against TOP 10 most affected vulnerailities. It gives us a fundamental guidelines to asses our application on all layers of security breaches, which might turn up to a threat in near future.

So what i am saying is , it is an application there cannot be any assumptions on the security posture of the application. One has to asses the application only to be sure it is not comprisable. Applications depend on infrastructure only for processing the data but how they do is entirely on the business or application logic embeded in them.

Wednesday, January 4, 2012

Performance Test

Performance Testing is an art to evaluate a resouce or an application to react in a sudden burst in the request coming to them. This test is not an intrusion test but the challenge is to determine if it relates with Denial Of Service (DoS) attack. To be very precise, it is very difficult to justify the difference.

Performance Test is more identical to a Stress Testing, Only thing is, we generally relate Stress Testing with applications or a server and Performance Testing with the network.

Generally these type of testing is done by simulating a trusted traffic and out bursting it to target a server or an application, but generally donot have any concern with the security angle. One must be vey smart, when conducting these type of tests, that wheather this is not creating or increasing the network latency there by jamming other communication channels. With the increase in the Request per Second parameter to an broadcast level will tryto bring down the resource or the application because the server will not able to respond or acknowledge these type of burst because of the service window set in them. More over on the physical level the NIC cards cannot pump up to these type of spikes because of their transaction limits.

Few things which needs to be understood before executing these type of tests:

1. The network design of the organization: Since the packets has to pass through all the network levels, it is very important to understand the network structure.

2. The Device functionality: The devices like routere, firwalls, switches, who are already busy in inspecting, routing and forwarding the normal packets, will react with this outburst. One has to query about their acceptability limit and then plan the outburst otherwise they will jam the internal line. One also has to make sure that devices like firewalls, IDS/IPS etc. understand these outbursts not as a attack and permit the same to enter into the network.

3. Current Internal Throughput: All components communicate with themselves using the throughput in the internal network. Optimal use of the throughput ensures effective communication between the devices. In a sceanario, where the packets per second is increased from the normal rate, there is always a chance that the exixting components might collapse because they might not be able to cope up with this burst.

4. Target Scalability: To look this in a easy way, normal NIC cards can boost up their transmission and reception limit to 100 mbps from 10 mbps, but if there is something higher than that, then the jamming happens. On a broader angle, this might be a smaller problem but actually the intensity of this problem is very deep. If the NIC card jams up then the entire traffic would be permanantly blocked ot allowed to the application and if the application is not tuned to address these type of outburst then it will crash down, creating a DoS attack.

So what i want to say is? these type of tests needs to be planned in an effective manner thinking on the security angle rather on the test. One mis-planning will create huge damage in the network and the target asset.