1. What are the components in a typical eBusiness security solution?
2. What is a web application?
3. How can I know if my site is vulnerable today?
4. What is a Web application firewall?
5. How is an application firewall different from a network firewall?
6. How does an application firewall differ from intrusion detection?
7. What is a Positive security model? And how does AppShield enforce this?
8. What are the differences between Positive and Negative security?
9. What are the advantages of a Secure Proxy?
10. We have skilled programmers and services to write our Web pages. Do we still have security exposures?
    
11. We have security policies and practices and have a firewall in place. Are we still exposed to application level hacking?
    
12. Why do I need to offer application level audits?
13. Do I need an application firewall if my developers follow good coding practices?
14. How does an application scanner compare to some of the popular network scanners?
15. What is SQL injection and does AppScan test for it?
16. What is Cross-Site Scripting and does AppScan test for it?

We recognize 4 layers of Internet security in a typical eBusiness environment:

1. Desktop Security
2. Data protection mechanisms like SSL and PKI.
3. Network protection measures like firewalls, intrusion detection.
4. Application level defense such as access control and application shielding.

Also, today's site audits, which focus on the network level, will be augmented by application level audits.

Back to Questions

Web Applications are the business logic that enables user�s interaction with the web site, and the transacting and interfacing with all the back-end data systems.

Examples include applications that allow users to look up their account information at their bank and move funds; applications that allow users to buy things online, such as shopping carts and transaction software; supply-chain automation applications that link suppliers to a manufacturer, and many, many others.

What these applications have in common is that they are composed of code that was written explicitly for the Web interface and code from many other sources that accesses internal data and performs transactions. Additionally, the databases that are accessed and the data the database contain are all crucial elements of the Web Application.

The components of a Web Application are shown schematically in the diagram below.

Back to Questions

Vulnerabilities in a site are discovered in a way similar to looking for bugs in software - through a QA or auditing process. As a matter of fact, these two are one and the same. Sanctum can help you identify potential vulnerabilities in your site through AppAudit - an auditing service in which Sanctum's experts perform ethical hacking of your Web application in order assess its general security level.

Sanctum has performed over 90 application-level audits during the last year, over 97% of which yielded severe vulnerabilities and only 3% was non critical. This is very similar to results produced by normal software testing processes, but in the case of Web applications, most bugs are translated to vulnerabilities.

Back to Questions

An application firewall listens on TCP ports 80 and 443, and accepts incoming (from the client) HTTP/HTTPS requests, parses them, associates them with a session (creates a session if required) and then matches them to the policy in effect for the session. If this request is permitted (i.e. the link is allowed), it is forwarded to the web server, and if it is not permitted, it is rejected. The web server's response arrives at the application firewall, is associated with a session (the same one the request belongs to), parsed and policy update (e.g. new links which are allowed) is extracted and associated to the session. If this is the response of the first request, a cryptographic session cookie is also attached to the response to identify the client session in further communications. The application firewall finally forwards the response to the client.

Back to Questions

Network firewalls operate mostly on the network level, limiting the allowed access into the sites to designated protocols and services. They can be viewed as the fence that forces people to access the site through the main gate. AppShield complements this by focusing on the application level and maintaining the correctness of the requests reaching the Web site. In other words, once entering through the main gate, AppShield ensures the user will behave properly once inside the premises.

Second, firewalls rely on a statically defined set of rules, and therefore are not able to provide tight security around a dynamic application. AppShield, on the other hand, adjusts itself on the fly to tightly fit the application logic. This is an essential component in providing a high level of security for Web applications, since, unlike network protocols, these are highly non-standardized.

Back to Questions

Intrusion detection can be host or network based. Enforcing a negative security model, it relies on a database of known patterns in order to identify and alert about attacks. See next question for more information on Host based Intrusion Detection.

• It differs from an application firewall like AppShield in a number of aspects: It can only detect network level attacks. It is not application aware since application logic is too diverse to be effectively handled by pattern recognition.
• It's reactive, meaning it will alert only after the attack has taken place.
• It's capable of identifying only what's in its database and requires updates as new techniques emerge.

AppShield, on the other hand:

• Works at the application level, adapting to it on the fly.
• Is proactive, meaning it blocks the attempts without them ever reaching the Web server.
• Uses generic enforcement technology (DPRE) to prevent attacks without knowing their structure and without the need to identify them. It therefore does not require knowledge base updates, and can deal with both present and future techniques.

Back to Questions

A positive security model enforces intended behavior vs. watching for unintended behavior. In other words, positive security only permits good behavior vs. preventing bad behavior. Positive security assumes an administrator and/or developer can define the ways in which you want a user to interact with your site, compared to the virtual impossibility of defining all the ways in which you think someone may try to manipulate/hack/misuse your site.

The benefits of a positive security model are:

1. Positive security policies do not require patches, signatures, or continual updates. And they protect against unknown vulnerabilities.
2. A positive security model contains a complete set of valid requests. There are no unknowns. Thus, the number of false negative and positives is significantly reduced.
3. Positive policies have a better ROI. They require little main memory and no disk space making them very efficient at processing requests.
4. Positive Security helps to significantly lower Operating Costs due to less administrative overhead since no continual updating is required, and the elimination of unplanned maintenance downtime

Back to Questions

The Positive Security Model is based on a complete set of valid request/responses. Any request that is not part of the positive model is an invalid request. There are no unknown requests. A positive policy can accurately and efficiently identify invalid requests.

This model is similar to the same security model used by network firewalls. Specifically, a firewall is configured with the requests that it will allow, implicitly blocking any request that does not meet these criteria. By providing true "application aware" analysis, AppShield brings this very powerful security concept to the application layer.

The opposite of this is the negative security model. Where the administrator must configure their system with all the requests they wish to block or detect.

Security Model Comparison Table

Positive Security Model Negative Security Model Complete Incomplete Accurate Uncertain Efficient Wasteful Non-signature based Signature based Low Admin Ongoing Admin Small Footprint Large Footprint Low Resource Usage Heavy Resource Usage Non-disruptive Disruptive No unknown requests Unknown requests (good and bad)

Back to Questions

AppShield uses a secure proxy to provide the platform for AppShield's Dynamic Policy Recognition Engine. The benefits of proxies are well known and provide a true barrier between the outside world and your web applications. AppShield's secure proxy evaluates every request for RFC compliance, buffer overflow attacks, and invalid HTTP headers as well as translating all requests to a common format before passing the requests to the security engine. Because all requests must be understood and well formed during this process, all encoding type attacks will fail as the true request will be revealed for what it really is.

Back to Questions

Yes. Whether you are in B2B or B2C, to be competitive in today's market you have to do business on the Web. And as more and more of the worlds largest enterprises put their digital assets online, security for application development is becoming a very demanding task. While most companies understand the importance of encryption and advanced firewall software to guard access to online assets, the most vulnerable points in any Website - the Web applications themselves - remain mostly unguarded. Handling Web application security in-house requires developers to address security issues at each stage of the development cycle - design, implementation, testing and deployment - a costly and time-consuming process - especially in the competitive hiring environment today for good Web developers! With Sanctum and specifically AppShield, you can provide your environment with automated Web application control and security software that autonomously and intelligently controls and monitors you application behavior - whether your Web developers produced it or you acquired them from a 3rd party.

Back to Questions

Yes. Security policies, firewalls and encryption are not effective against application level hacking. A hacker using a regular Web browser will seamlessly go through the firewall and encryption and is virtually free to send requests to the application. Those requests can be of three types:

1. Legal requests, which the application recognizes and accepts
2. Illegal requests, which the application recognizes and rejects
3. Anything else

It's the latter of the three that is dangerous to the application. There are a large variety of techniques the hacker can use in order to reveal the requests from this 3rd type, and use them to force the application into unpredicted behavior. The results can be detrimental to the site and include defacement, total deletion, stealing customer accounts, credit cards and medical records, and much more.

Back to Questions

As the cost, likelihood, and frequency of hacks at the application level increase, demand for application security audits grows. AppScan targets the needs of the following key customer segments:

• Developers—Develop quality web applications.
• QA & Internal Auditors—Ensure that web applications are secure prior to going into production and ongoing
• Security Consultants and Auditors—Evaluate web site security and recommend (sell) methods to improve sites.

Across each segment, the business problem remains the same.

• Skilled security personnel are a scarce resource
• Speed to market of new web applications is critical

In every case, automating the manual task of auditing web applications helps your customers develop secure web applications by empowering them to perform more application level audits in less time.

Back to Questions

According to a study done by CSI and the FBI, over 90% of all large corporations were victimized by hackers. Combined with a report from the Gartner Group that found that 75% of all web attacks were performed at the application layer it is clear that good coding practices are not good enough. Unfortunately mistakes are made, and market pressures constantly require new applications to be released all the time, often with out a through security review. Even for organizations with the time and the need for zero failure such as NASA acknowledge that bug free code is impossible and that only by providing 3 layers of redundancy can a system be acceptable for use. While such a level of redundancy is not needed for most systems, AppShield can add the important first layer of protection that today does not exist. AppShield also protects against vulnerabilities that arise in 3rd party code such as web and application servers.

Back to Questions

Although an application scanner like AppScan and traditional security scanners perform some of the same tasks, AppScan is different from these tools because it analyzes the behavior of the actual web application and the vulnerabilities it finds. AppScan exposes security loopholes (such as parameter tampering, forceful browsing, cross-site scripting and hidden field manipulation) that occur in the application code and within widely used third-party products. Network scanners can identify buffer overflow vulnerabilities at the network level, but only AppScan will find these and others at the application level. Unlike traditional network scanners, AppScan dynamically scans the application by analyzing the outbound HTML pages on the fly as they will be seen by the legitimate user and the unscrupulous hacker. The result is a comprehensive evaluation of a web application's vulnerability to attack. Once the assessment is complete, AppScan provides customized reports that include actionable recommendations for how to address known and unknown vulnerabilities.

Back to Questions

Web applications commonly use SQL to add, edit, or retrieve data from a database. If an application is not sufficiently protected from this form of attack, a hacker can inject SQL commands into a form field and have the backend database execute them. The destructive potential for this attack is enormous. SQL injection can enable a hacker to:

1. Obtain any or all of the information stored in the database
2. Erase records
3. Bring down the database

AppScan runs a series of tests during a scan to determine if the application is vulnerable to SQL injection. It does this safely to ensure that the integrity of the database and its contents are not compromised.

Back to Questions

Many web applications contain forms and other interactive components that allow the end user to pass information to the application. Instead of passing benign information into the application through the form, hackers will pass scripts (written in JavaScript or VBScript typically) to the application. The scripts usually contain code for forms or other manners of collecting information from a web page. As a result of this process, hackers can insert their own scripts into web applications that enable them to do things like:

1. Steal username and passwords
2. Collect customer information

AppScan runs a complete series of tests against every application to determine if it is susceptible to this popular type of attack.

Back to Questions