We’ve recently been asked to look at the way that the Cloud is increasingly being used to provide external security testing services (such as AVS, Application Vulnerability Scanning). The argument of the proponents of such services is that security threats come from the cloud, and thus it makes most sense to embed the AVS in the cloud. However after very detailed examination of the options we have come to the conclusion that the Cloud it isn’t necessarily the right answer for many enterprises, and that the AVS service may best be delivered inside the datacenter.
Application Vulnerability Scanning is the process of exercising the external interfaces to applications (typically public-facing web applications) so as to make sure that there are no exploitable or potentially-exploitable security weaknesses. So, for example, you might want to log on to a system and check that the credentials aren’t just sent back to you in plain text in a cookie.
Don’t laugh it does happen sometimes, but there are also several hundred more sophisticated checks you might also want to apply. Underlying this there are application weaknesses (i.e. pieces of code in which, for example, some naive developer has written the credentials into the cookie). In fact there is whole emerging area of analyzing and classifying these weaknesses, driven by National Security (Mitre CWE) and Payment Card Industry (OWASP), and Application Vulnerability Scanning is becoming mandated as part of the diligence around running public-facing systems.
And so we come to the Cloud. The argument is that you can use a cloud-based service such as IBM Rational AppScan OnDemand to run AVS against your externally-visible systems, and that the Cloud is the right place to do this because the AVS is getting the same level of access that a hacker would. Furthermore a cloud-based AVS can be used to test applications whether or not they are hosted in the Cloud, so it is a natural first step into the Cloud for those organizations which do not really want to go there with their applications just yet.
However, there is a problem with this approach when you put it in the context of the overall process of vulnerability risk management and remediation. First there is the outside-in process that occurs when an application vulnerability is detected by external scan. At this point you have to initiate the process of triaging the problem and deciding whether or not to fix it. The people who understand the vulnerability are those who scanned for it, and are sitting in the cloud, but the codebase they need to fix is sitting inside the datacenter amongst people who haven’t been involved in the scanning process. If you are going to include the scanning team into the remediation process, you need to bring them inside the datacenter. Which kind-of begs the question as to why they aren’t there in the first place.
Then there is the internal process that occurs when weaknesses are detected by processes running inside the datacenter. These processes are additional to the AVS scans and referred to as either Static or Dynamic Analysis, and performed against pre-production or otherwise non-live systems or codebases. In the case of Static Analysis you typically need source code.
The reason why you do this is that the AVS is against live systems and thus by its very nature cannot be intrusive. In a Static or Dynamic Analysis scan you can do way more things and thus detect way more vulnerabilities than in an AVS scan. However, these scans can only be done with access into the datacenter because the non-live systems are not often exposed to the world.
This matters because Dynamic Analysis and AVS are actually variations of the same thing. AVS is just a Dynamic Analysis scan with a restricted profile (restricted to things that are suitably non-intrusive), so if you have half of the combined AVS and Dynamic Analysis process internal to the datacenter and half external in the cloud you end up with a discontinuity in your process.
So, in reality the reason why many organizations are turning to the cloud for AVS is that they have an urgent requirement under PCI-DSS to get AVS in place and they don’t have the skills in house to set the thing up. Once set up, they may have the skills to run it in house, and they may have some of the remediation skills in the teams that actually built the applications.
So the conclusion to all of this is that if you are thinking about doing Application Vulnerability Scanning for PCI-DSS, it’s best to think of the solutions as being tightly coupled to the systems to be scanned. If the systems are in the cloud, then by all means put the AVS in the same cloud. Otherwise, you really are best putting AVS in the datacenter, and if you need help, look to a specialist service provider to solve the problem, and then you can even transition back to internal operation once the AVS is operational.
Application Vulnerability Scanning comes in from the Cloud
We’ve recently been asked to look at the way that the Cloud is increasingly being used to provide external security testing services (such as AVS, Application Vulnerability Scanning). The argument of the proponents of such services is that security threats come from the cloud, and thus it makes most sense to embed the AVS in the cloud. However after very detailed examination of the options we have come to the conclusion that the Cloud it isn’t necessarily the right answer for many enterprises, and that the AVS service may best be delivered as a hybrid managed service – i.e. by third parties internal to the enterprise.
Application Vulnerability Scanning is the process of exercising the external interfaces to applications (typically public-facing web applications) so as to make sure that there are no exploitable or potentially-exploitable security weaknesses. So, for example, you might want to log on to a system and check that the credentials aren’t just sent back to you in plain text in a cookie.
Don’t laugh it does happen sometimes, but there are also several hundred more sophisticated checks you might also want to apply. Underlying this there are application weaknesses (i.e. pieces of code in which, for example, some naïve developer has written the credentials into the cookie). In fact there is whole emerging area of analysing and classifying these weaknesses, driven by National Security (Mitre CWE) and Payment Card Industry (OWASP), and Application Vulnerability Scanning is becoming mandated as part of the diligence around running public-facing systems.
And so we come to the Cloud. The argument is that you can use a cloud-based service such as IBM Rational AppScan OnDemand to run AVS against your externally-visible systems, and that the Cloud is the right place to do this because the AVS is getting the same level of access that a hacker would. Furthermore a cloud-based AVS can be used to test applications whether or not they are hosted in the Cloud, so it is a natural first step into the Cloud for those organizations which do not really want to go there with their applications just yet.
However, there is a problem with this approach when you put it in the context of the overall process of vulnerability risk management and remediation. First there is the outside-in process that occurs when an application vulnerability is detected by external scan. At this point you have to initiate the process of triaging the problem and deciding whether or not to fix it. The people who understand the vulnerability are those who scanned for it, and are sitting in the cloud, but the codebase they need to fix is sitting inside the datacenter amongst people who haven’t been involved in the scanning process. If you are going to include the scanning team into the remediation process, you need to bring them inside the datacenter. Which kind-of begs the question as to why they aren’t there in the first place.
Then there is the internal process that occurs when weaknesses are detected by processes running inside the datacenter. These processes are additional to the AVS scans and referred to as Either Static or Dynamic Analysis, and performed against pre-production or otherwise non-live systems. In the case of Static Analysis you typically need source code. The reason why you do this is that the AVS is against live systems and thus by its very nature cannot be intrusive. In a Static or Dynamic Analysis scan you can do way more things and thus detect way more vulnerabilities than in an AVS scan.
However, these scans can only be done with access into the datacenter because the non-live systems are not exposed to the world. The reason why this matters is that Dynamic Analysis and AVS are actually variations of the same thing. AVS is just a Dynamic Analysis scan with a restricted profile (I.e restricted to things that are suitably non-intrusive), so if you have half of the combined AVS and Dynamic Analysis process internal to the datacenter and half external in the cloud you end up with a discontinuity in your process.
So, in reality the reason why many organizations are turning to the cloud for AVS is that they have an urgent requirement under PCI-DSS to get AVS in place and they don’t have the skills in house to set the thing up. Once set up, they may have the skills to run it in house, and they may have some of the remediation skills in the teams that actually built the applications.
So the conclusion to all of this is that if you are thinking about doing Application Vulnerability Scanning for PCI-DSS, it’s best to think of the solutions as being tightly coupled to the systems to be scanned. If the systems are in the cloud, then by all means put the AVS in the same cloud. Otherwise, you really are best putting AVS in the datacenter, and if you need help, look to a specialist service providers to solve the problem, and then you can transition back to internal operation once the AVS is operational.
