DevelopSec

assessment

by Leave a Comment

Does the End of an Iteration Change Your View of Risk?

You have been working hard for the past few weeks or months on the latest round of features for your flagship product. You are excited. The team is excited. Then a security test identifies a vulnerability. Balloons deflate and everyone starts to scramble.

Take a breath.

Not all vulnerabilities are created equal and the risk that each presents is vastly different. The organization should already have a process for triaging security findings. That process should be assessing the risk of the finding to determine its impact on the application, organization, and your customers. Some of these flaws will need immediate attention. Some may require holding up the release. Some may pose a lower risk and can wait.

Take the time to analyze the situation.

If an item is severe and poses great risk, by all means, stop what you are doing and fix it. But, what happens when the risk is fairly low. When I say risk, I include in that the ability for it to be exploited. The difficulty to exploit can be a critical factor in what decision you make.

When does the risk of remediation override the risk of waiting until the next iteration?

There are some instances where the risk to remediate so late in the iteration may actually be higher than waiting until the next iteration to resolve the actual issue. But all security vulnerabilities need to be fixed, you say? This is not an attempt to get out of doing work or not resolve issues. However, I believe there are situations where the risk of the exploit is less than the risk of trying to fix it in a chaotic, last minute manner.

I can’t count the number of times I have seen issues arise that appeared to be simple fixes. The bug was not very serious and could only be exploited in a very limited way. For example, the bug required the user’s machine to be compromised to enable exploitation. The fix, however, ended up taking more than a week due to some complications. When the bug appeared 2 days before code freeze there were many discussions on performing a fix, and potentially holding up the release, and moving the remediation to the next iteration.

When we take the time to analyze the risk and exposure of the finding, it is possible to make an educated decision as to which risk is better for the organization and the customers. In this situation, the assumption is that the user’s system would need to be compromised for the exploit to happen. If that is true, the application is already vulnerable to password sniffing or other attacks that would make this specific exploit a waste of time.

Forcing a fix at this point in the game increases the chances of introducing another vulnerability, possibly more severe than the one that we are trying to fix. Was that risk worth it?

Timing can have an affect on our judgement when it comes to resolving security issues. It should not be used as an escape goat or reason not to fix things. When analyzing the risk of an item, make sure you are also considering how that may affect the environment as a whole. This risk may not be directly with the flaw, but indirectly due to how it is fixed. There is no hard and fast rule, exactly the reason why we use a risk based approach.

Engage your information security office or enterprise risk teams to help with the analysis. They may be able to provide a different point of view or insight you may have overlooked.

by Leave a Comment

What is a Penetration Test

You spend all day looking at requirements, creating functionality and doing some testing of the code you just created. You have been working for months on this application making sure it worked as expected. The testers have been diligently working to ensure that the requirements have been fulfilled and the application will work as expected and allow the end users the capability to solve a specific set of tasks. Then it happens… You find out that a penetration test is coming. Unfortunately for many, they really don’t understand what that means. Often times it is met with anger or resentment. How many people are actually excited to see the “pen testers” coming?

A penetration test, or pen test, is nothing that should be feared. While it is considered to be an adversarial act, the end goal is to assess the security of the environment or application to identify security risks before the “bad guys” do and help provide recommendations to reduce that risk.

That doesn’t sound that bad right, or does it? I may have left out the fact that a pen test may include exploiting your applications, retrieving your sensitive data, or even social engineering staff members to get what they want. But seriously, that is not as bad as it sounds and a pen test done right can be a very positive experience.

A big issue with a pen test is that in different companies and communities it has a different meaning. Sure the simple definition above should always fit that, but the scope that is defined and the results that are received can be very different. Here are some examples of some different types of pen tests (network and application specific).

Basic Pen Test (Scanner Only)
In my opinion this is not a pen test, but rather a vulnerability scan. In this situation, the “testers” will run a tool like Nessus or Qualys and then provide the results of that scan. The test is usually started by providing a set of IP addresses or URLs and then the scanner is configured and let loose. A few hours later, or maybe days, you get a report from the tool that is then passed on to the client. This type of assessment can make it difficult to identify the true risk of the vulnerabilities identified because they were not fully exploited. Maybe the scanner identified that there was SQL injection, but it didn’t follow through with the vulnerability to see how much access that provided.

Limited Scope Pen Test (Fairly Typical)
This type of test has scope limitations, meaning that it might just include a subset of IP addresses, specific functionality of an application, or how far you can take an exploit if one is found. This is fairly typical as it is rare to find a pen test that is fully open with everything on the table. The scope is defined in the rules of engagement as to what can and cannot be performed.

Full Pen Test (Not as Common)
Everything is game in this type of test. Be prepared to receive phishing emails or phone calls trying to get you to fall for a malicious attack. Your social profiles may also be a concern for you as when everything is game, a tester will use any avenue they can to try and gain access. All IP’s or the entire application is in scope. It can be very difficult to stop the testers from gaining access to systems when everything is in play.

Both the Limited and Full scope pen tests usually consist of both automated tools and lots of manual testing to identify the security risks.

In addition to the types of tests, we need to think about the different goals the client may have for requesting a pen test. Here is a quick rundown of some of the goals we see during a test.

Compliance Check Box
This is commonly seen by organizations that fall under some form of compliance, like PCI. “We are required to do this, so lets just get it done.” Often times the client is not really looking for security risks, but rather just trying to check the box. This doesn’t mean you should short change the testing efforts. The purpose of having a test performed is to help identify and reduce risk to the company.

Assess the Security of the Endpoint
This is seen in most tests where the client wants a vulnerability assessment of their endpoint, whether it is an IP or an application, so they can work to mitigate the risks identified. This type of test can be broken down into multiple levels, depending on how far the client wants to go. Some pen tests with this goal may not allow exploitation, making the goal just to identify vulnerabilities. Others, however, have higher goals of gaining access to internal networks, exploiting vulnerabilities, or gaining domain admin rights. This all depends on the goal of the organizer of the test.

High Stakes Goals
Some tests have very limited, yet high stakes goals. For example, many tests just want to see if the tester can gain domain administrator rights to the domain. In these types of tests, many of the other “vulnerability assessment” type findings may be overlooked. While they may be identified to help reach the ultimate goal, the goal is not to identify all, or as many as possible, of the risks to the endpoint.

In most tests, it is the assessing the security of the endpoint that we see the most. The goal is to identify the different risks, and while gaining internal access or domain administrator rights is great, the client is looking for more actionable results to it.

When testing occurs, often times the development teams have very little involvement. They may know it is going on, or have to provide some support if the applications are not configured properly, but that is usually the extent of it. It is important that we understand the goal and type of testing that is being performed. Also understand the purpose of the test should be to provide insight we didn’t have previously that could help us decrease the risk to our company.

Penetration tests, while “adversarial”, should be a collaborative effort with a positive feel. Don’t look at it as an “us” vs. “them”. The team was brought in for a specific task. The task should produce actionable results that are relevant to the environment. If they don’t, then it may be time to switch testing companies. Keep an open line of communication and a positive attitude.