Web App Security Step by Step :Part II

Web / Application Security how to Step by Step :Part II

As we have discussed in the last Blog about web security identification & importance now we are taking a step further on implantation. First we need to understand the vulnerabilities from the network / networks & build a scanning process to review these vulnerabilities on periodic basis depending upon the criticality of the application , domain, system etc.

Step 1: identify, priorities and categorize web applications

With enterprise applications, you need to itemize all systems and categorize them before conducting security audits. Web application threats are no different – you must identify all web applications for testing and decide on their relative priority of importance for assessing remediation. Tools include automated scanners that do most of the work for you. The undeniable fact is that a machine can do some things efficiently than us humans in repetitive jobs.

Step 2: Scan everything for threats & vulnerabilities Scanning is an automated process that tests items for security as measured by a dynamic database of known vulnerabilities and likely exploits. A web application scanner includes simulated attacks against each web application. The object is to see if it breaks.

Step 3: Verify vulnerabilities against a register which also maintains a scenario log to check the impact factor like risk registers in project management This step helps to reduce false positives and false negatives, which can lead to inefficiencies in the VM process. False positives inhibit some scanning by drowning the scan results with vulnerabilities that don’t match what’s in your inventory of network and IT assets and web applications. Chasing down false positives is a waste of IT staff time and an inefficient way to do the management. Likewise, a false negative may occur when the scanner fails to detect a vulnerability that actually exists or we might miss an impending threat in the device or application. This failure to detect actual vulnerabilities may place your applications at serious risk of exploitation by hackers.

Step 4: Classify and rank risks: Fixing everything at once is practically impossible. In fact, in large organizations, the amount of vulnerability data can be huge & increasing as good proportion so if it’s not properly categorized, segmented, and prioritized in a meaningful fashion. This defines the most critical issues that could impact the most critical applications – all the way to items of lesser importance. In a nutshell, you need to decide what to fix first.

Step 5: Test all bug-fixing , updates and workarounds before integrating to the web site / application. Patches and workarounds are usually meant for insecure networks and systems, but they apply equally to web applications. If an application is vulnerable, it must be fixed. Updates, patches, fixes, and workarounds are usually administered by security and IT team members. Fixing actual code requires the work of programmers as guided by the in-house development team. Once a fix is devised, the team must thoroughly test it before re-deployment.

Step 6: Apply patches, fixes, and workarounds Here’s where the repairs are applied to vulnerable web applications and other assets.

Step 7: Rescan to verify patching After conducting steps for remediation, it’s useful to re-scan the web application to ensure it was fixed. This step verifies that the fix worked and that it doesn’t cause other applications, network devices, services, or other applications to be exposed to additional vulnerabilities.

Step 8: plan a audit cycle to understand the changed scenarios & priorities to be incorporated in these vulnerabilities management cycles. Simply using IT policy compliance products for continuous control monitoring of web applications, for example, doesn’t automatically make audit issues go away. But use the right tools under the right policy framework, stay consistent, and keep your reports, and you can greatly reduce the amount of money you spend every year in audit!

It goes without saying that specifications for a web application security scanner vary depending on the needs of each organization. Traditional considerations include whether you should go for an Open Source (‘free’) solution, or purchase a commercial scanner from an established software company. Another consideration is whether to run a software solution on your own infrastructure, or to rent its functionality with

Software-as-a-Service. Let's have more to say in next Part about the advantages of SaaS. Meanwhile, what else should you look for in a scanner? We answer this question in greater detail in Part III, where we also describe the practical ins and outs of using a web application scanner.

Web application scanners automate the manual techniques that hackers and security researchers alike employ against websites. They range from simple scripts that may simply search HTML content for useful information, to more complex tools that spider (that is, discover and crawl through) a

website and catalog its content for further manual analysis. The scanner acts like a hacker, albeit one less antagonistic towards the web application. As with any technology, it’s useful to consider what to look for in choosing the right web application security scanner.

Let’s ponder more what a web application security scanner should do for us. As per my thought process a minimum standard suggests that a web application security scanner should:

Must have :

1. Identify specified types of vulnerabilities in a web application.
2. Generate a text report indicating an attack for each identified vulnerability.
3. Identify false positive results at an acceptably low rate.

Good to have

1. Produce a report compatible with other tools.
2. Allow particular types of weaknesses to be suppressed by the user.
3. Use standard names for weakness classes.

The top priority for a scanner is helping you keep on top of the constantly changing universe of web application vulnerabilities. In particular, your scanner must be capable of identifying the top vulnerabilities such as cross-site scripting and SQL injection. Our scanner will provide more value if it incorporates standard industry resources for this information.

I am still compiling this day by day also got help from various comments by mail to understand specific pain areas in detail, please share your concerns or any threat I missed in this. You can write to me at ravindrapande@gmail.com