Filed in Cloud Industry Insights by David Lister | March 25, 2013 2:00 pm
There are many options when trying to assess the security posture of your application and its hosting environment. Some choose to start from the top of the stack down and look at the application directly, while others might look at the supporting infrastructure first, including the network itself, the firewall rules, running services, and web server configurations. Regardless of the approach, enterprises must protect the integrity of their application and data by proactively identifying potential attack vectors or vulnerabilities. Certain regulation and standards even require periodic vulnerability assessments.
There are two ways in which these vulnerabilities can be identified: vulnerability assessments and penetration testing.
A vulnerability assessment is an automated scan to determine basic flaws in a system. This can be either network or application vulnerability scanning, or a combination of both. The common factor here is that the scan is automated and generates a report of vulnerabilities or issues that may need to be addressed.
In a network vulnerability scan, software looks at a set list of IP addresses to determine what services are listening across the network, and also what software (including versions of the software) are running. Limited tests are run against the listening services, including attempts to login with default account credentials, or comparing the versions of software against known vulnerable versions. If a match is found, it is recommended that the listening port be closed off and/or the software be upgraded if possible.
Application vulnerability scanning can take either or both of two approaches:
Penetration testing represents another way to uncover flaws in an application or computer system. It is a manual process which usually starts with a vulnerability scan or reconnaissance to determine what is running on the network or application. In network penetration testing, a qualified ethical hacker tries to determine what services are running on each accessible host in the network and attempts to exploit vulnerable services to gain access to a system. Once access is gained, and depending on the scope of the penetration test, other steps can be performed post-exploitation. One simple example of this is to attempt to retrieve the password hash database to crack the passwords. In this case, administrators would be recommended to choose stronger passwords if necessary.
The main point of this discussion is that one needs to think like an attacker and attempt to perform the actions that attackers would perform to gain further access. In an application penetration test, the ethical hacker could check first for flaws in the business logic, something that is difficult for an automated scanner to determine. For example, if it is possible to inject something into an application (which is something that should not be possible), then that would be noted as a flaw that should be corrected in the application.
Some flaws are difficult to detect by a scanner. For example, if what was injected could be seen later by another user and caused their browser’s memory to overflow and allowed an attacker to install software and gain access to their desktop, or redirect them and steal passwords, that would only be preventable if these flaws were specifically tested for and fixed before an attacker found them. Asynchronous flows, where the responses are not tied to the input, are difficult to detect by a scanner. Other examples of difficult flaws to scan for are those created by applications that release too much information in error messages or error handling. An attacker could, for example, increment a known account number to see data of another account.
It goes without saying that the ethical hacker must secure permission before performing these tests. Otherwise, the tests would not be ethical hacking: they would just be hacking. Penetration testing would regularly not include actions such as installing a back door, performing DDoS attacks, or stealing and using credit card numbers. Sometimes, proving that a flow exists involves retrieving some data. If this is the case, a “flag” could be used in place of “real” data, and could be sufficient to prove that an ethical attack was successful. Generally, it is best to try to perform these tests against a test or pre-production environment, and always with the help of an experienced professional. Doing something is better than doing nothing, as it is better to find the flaws yourself than have someone report them to you.
Source URL: http://www.rackspace.com/blog/vulnerability-assessment-and-penetration-testing-identify-and-fix-flaws/
Copyright ©2014 The Official Rackspace Blog unless otherwise noted.