ThreatPerspectiveApplication Vulnerability Assessment
Engage us to find vulnerabilities in your application(s).
What does an Application Vulnerability Assessment consist of?
ThreatPerspective's Application Vulnerability Assessment service provides our clients with the ability to identify weaknesses that exist in their IT infrastructure.
ThreatPerspective defines an Application Vulnerability Assessment as analyzing an an application for known vulnerabilities, configuration issues, role and permission issues, etc, however it is much more than that. During an application vulnerability assessement, ThreatPerspective will identify the root causes of security issues that are discovered which will enable an organization to change their practices and architecture to operate more securely moving forward. It will also be possible to identify if policies are effectively being enforced.
In today's world, some of the most valuable assets in a company's inventory are their public web servers. Web and application servers provide companies with advertising platforms, they allow companies and other entities to service a broader client base than ever before, and allow it to be done easily. But what is protecting these valuable assets? Often times, nothing is.
Firewalls are designed to keep hackers out. An organization's internet facing application servers are typically located within a DMZ or internal network, and a hole is punched right through the firewall to allow direct access to the application services. In other words, the application services themselves are not protected. This allows hackers to attack the application servers directly, as well as the applications that reside on the servers. An application assessment will find security issues within the application itself that may impact the overall security of your organization.
These assessments are typically quite involved depending on the size and complexity of the application. Along with a minimum list of common criteria using automated scanning and manual testing techniques (for vulnerability like SQL Injection (SQLi), Cross-Site-Scripting (XSS), Cross-Site Request Forgery (CSRF), XML External Entity (XXE), Deserialization, Remote Command Execution (RCE), etc), ThreatPerspective engineers take the time to see how your application works to see if there are any application logic flaws, privilege escalation, or data compartmentalization leaks that many automated tools are not able find.
An application vulnerability assessment can either be performed on site at a client's physical location to assess their internal network(s), remotely from the Internet to assess a client's external network(s), or both. Many organizations also have at least one DMZ on their internal networks. It is also possible to see what services and potential security issues are accessible inside those DMZs and how they may effect other networks, i.e. are there back channels from the DMZ to the Internal network(s), etc.
An application vulnerability assessment should ideally be conducted against a dev/qa/uat or other non-production environment to be the most thorough, however, ThreatPerspective can abolutely test an application in production and tread lightly so as not to disrupt business operations or cause regular users of the application to be adversely impacted or even alarmed. Testing in production is a lot slower and is not as thorough.
How we perform an Application Vulnerability Assessment
The first step is to determine the scope of the assessment. How many interactive pages, or API calls are accessed by the application? Then determine the complexity of the application by asking questions like: How many user roles are there? Is there a notion of data comparmentalization (i.e. organization "A" should not be able to see data associated with organization "B", etc). And also define reporting requirments.
The next step is negotiating the rules of engagement. Here we would decide if this is going to be a zero knowledge engagement where we perform open source intelligence gathering, provide the target lists to the you to approve, modify, etc, or is this a cooperative engagment where all necessary information is provided by the customer to save time and money? Is the engagement overt or unannounced. Is there any content that is out of scope? If we identify a serious vulnerability should we contact the customer prior immediately? How often will there be status updates? If we encounter issues who do we call? How much time will be spent? Are there any time constraints (nights and weekends only, or conversly, only during working hours)? What environment are we testing in? If not in production, would we validate vulnerabilities actually exist in production and not just the testing environment? Etc.
Once both parties have mutually agreed to commence, the Application Vulnerability Assessment begins and is conducted according to the rules of engagement.