vulnerability

June 3, 2018 by James Jardine

Thinking about starting a bug bounty? Do this first.

Application security has become an important topic within our organizations. We have come to understand that the data that we deem sensitive and critical to our business is made available through these applications. With breaches happening all the time, it is critical to take reasonable steps to help protect that data by ensuring that our applications are implementing strong controls.

Over the years, testing has been the main avenue for “implementing” security into applications. We have seen a shift to the left more recently, leading to doing more throughout the entire development cycle, but we still have a ways to go. I am still a firm believer in embedding security into each of the phases as our main means of securing applications. Testing, however, is still a major component of any security program.

Typically, organizations rely on penetration testing to find the flaws in their applications. This is the de facto standard for understanding your risk. Unfortunately, penetration testing for applications has been watered down from what we think about with network testing. Many of the assessments we call penetration tests these days are just automated scans transposed into a custom report. These types of testing overlook one of the components a penetration test provides, which is the manual testing. Of course, there is much more to a penetration test, but that is not the focus of this post.

Internally, organizations may implement automated tools to help identify security flaws within their applications. These tools are good at finding certain types of flaws, and usually quite quickly. Like many current penetration tests, they lack the manual assessment side.

Not only does manual testing have the ability to find different types of flaws, such as authentication, authorization, CSRF, business logic, etc., it also has the ability to identify flaws that an automation tool overlooks. For example, a tool may not find every instance of cross-site scripting, depending on how that tool analyzes the system. Granted, manual testing is not guaranteed to find every instance either. With each type of testing, there is always a number of issues that will not be identified. The goal is to start reducing these numbers down over time.

Handling the results of all these res ports from the different assessments is critical to how well you start creating more resilient applications. In many organizations, vulnerabilities identified are handled as individual items and patched. In my opinion, the return on investment is when you can analyze these results to review your development process and see what improvements can be made to reduce the chance these types of flaws will be included in the future. Having an expert available to help review the issues and provide insight into how to use that information to improve your process is valuable.

Having a solid application development process in place is important before thinking about implementing a bug bounty program within your organization. If you are not already doing things consistently, there is a better chance the bounty program will fail.

Bug bounty programs have been becoming more prevalent over the last few years. This is especially true for newer technical startups. We have seen much slower adoption with most of the major corporations. There are many reasons for this, which are outside the scope of this post. There have been questions on whether bug bounties can replace penetration testing. The answer is no, because the goal of each of these is different. There are plenty of articles discussing the subject. A bug bounty program has also been seen by many as the evidence to show they are doing application security. Unfortunately, we can’t test ourselves secure. As I stated previously, testing is just a part of our solution for application security.

A key difference between our traditional testing and a bug bounty program is that bug bounties pay by the bug. Our traditional testing is provided at flat fees. For example, that automated tool is a set price for a month or year subscription. A penetration test is a set price per test. A bug bounty is priced per bug, which makes the cost very unpredictable. In addition, if you are not already doing many of the things previously discussed, there could be a lot of bugs to be found, leading to potentially high payouts.

As I have stated before, penetration testing has a different purpose and it can be very expensive. At Jardine Software we offer more budget friendly manual application security testing at a fixed cost. The goal is not necessarily to find every instance of every vulnerability or to exploit vulnerabilities in the way a penetration test would. The focus is on augmenting the automated testing you may already have in place and to provide that missing manual piece. The testing is performed manually by using the application in combination with Burp Suite, to look for weaknesses and provide those in a way that helps prioritize and then remediate them according to your organization’s needs.

The manual application security testing is typically performed over a week to two weeks and includes a broader scope than a typical bug bounty program. The reason for this is that we want to help identify risks that we see based on our years of experience to make you aware. This assessment can then help identify where you may have issues within your application before opening it up for a crowd sourced bounty program where each bug is priced individually.

If you are thinking about implementing a bug bounty program, reach out and lets chat first. Even if you are not considering a bug bounty program, do you have any manual application security testing implemented? We have the expertise to help provide the necessary testing or provide training for your internal teams to start applying manual testing techniques as part of your life cycle.

March 7, 2017 by James Jardine

Vulnerability disclosure doesn’t require a bug bounty

Software is moving at a rapid pace. Even with secure coding training, a secure SDLC, and third party penetration testing, vulnerabilities still exist. Fortunately, there are many people that are happy and willing to notify you of these issues if they find them.

When we talk about external resources finding vulnerabilities on their own, we often think of bug bounties. Companies offer a bug bounty to compensate people who have identified a bug, submitted it, and followed other rules defined around the program.

A bug bounty is not the only option to provide a means for these users to provide vulnerability information. The process of disclosing these vulnerabilities is known as vulnerability disclosure. I spoke about this on the DevelopSec podcast linked below:

People often get confused between bug bounties and vulnerability disclosure. They often consider the two to be one in the same. But they are actually different. A vulnerability disclosure process should be implemented by every organization. It is the process someone would use to report a vulnerability to the organization, ensuring it makes it to the right people. There are too many instances where a vulnerability may be reported, but it gets lost in the help desk system. This happens because the identifier doesn’t have any clear path to submit the flaw. Left to their own choice, they may attempt emailing, tweeting, Facebook, or the contact us page on the website. Unfortunately, many of these methods are not monitored by the security group and the people that are monitoring them don’t have a defined process to pass the information along.

A bug bounty program is not meant for every organization, nor is every organization ready to implement one. The bug bounty program builds upon vulnerability disclosure by adding a form of compensation. The compensation can range from kudos (or a thank you) to monetary rewards. Bug bounties provide an incentive for people to proactively look for vulnerabilities within your application. Bug bounties come with their own special considerations, which are covered in other posts. If you would like to discuss more about them, contact us.

Creating a clear path of communication and clear set of expectations helps reduce the chance of a vulnerability falling through the cracks. It does mean that each vulnerability will go through an analysis process to determine the risk it exposes to the organization and its clients and the priority level. Make sure that your organization has a clear vulnerability disclosure policy and it the method to report is easy to identify.

Remember, creating a vulnerability disclosure policy doesn’t require a bug bounty. It doesn’t need to promote the testing of your applications for security vulnerabilities. It does provide a means for someone that does identify something to share that with you to help resolve it.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

September 28, 2016 by James Jardine

Scoping your application security assessment (Applications)

Assessing our applications is important because it helps us understand what security controls are efficient, and which ones are not. Whether you call it a vulnerability assessment or a penetration test, often used interchangeably, the value is important. Vulnerability assessments and penetration tests are different. The goals are often different. Many times the techniques are different as well. its s important to understand what you are trying to accomplish.

Today, many applications are spread across multiple technologies and platforms. Unlike in the past, when most applications were just on the web, now many also reside on mobile devices and even other internet of things devices. We must understand how these pieces all fit together and verify that they do not open potential issues for each other. Have a look at the following image showing some of the different components that can be a part of the same application.

Scoping1

Unfortunately, when we see a security assessment performed, we typically focus on one component at a time. We know we need to test the web and mobile applications, but we do them at different times. There are many reasons for this to happen, for example different release schedules, but it is something we must consider.

Look back at the picture above and notice that there are shared APIs and data sources. Data from one application maybe be updated from another. When we perform an assessment on just one of the pieces, we lose the ability to see the effects the other pieces have. Lets look at an example:

Years ago, I worked on a system that had web, windows, and mobile components to it. The web team did an excellent job of limiting input into their application. They were fairly well protected against cross-site scripting payloads, often just by the built in frameworks they used. Unfortunately, the mobile application (which was not effected by XSS) didn’t do as good of a job with their input validation. It was very easy to put XSS payloads into the mobile application and sync them to the server. Then, switching back to the web client, viewing that data would execute the XSS.

This was a multi-part lesson. First, the web team learned that they can’t trust the data in the database. Even though they were fairly well protected against inputs in their application, there were other components updating that same data source. They had to start looking at output encoding their data when they sent it to the browser. Second, it highlighted the fact that these components don’t exist in a silo. They are working together to provide a complete solution. We couldn’t get away with just testing each one on its own. There was a whole class of issues that were left out during the testing phase.

I have seen this time and time again during application assessments and it will only get more common. Each component is different. They react different to different inputs. They store data differently. You never know when that one piece of data, hard-coded into the mobile application, will lead to a compromise on the web application.

During our development and QA stages we will have time to focus on a sole component to make sure that it is functioning as expected. However, we have to identify ways to verify that the components are working together as expected. This doesn’t start with testing, it actually starts with design and understanding the different components. Mapping out the data and how/where it is used. Understanding what that data means to different components can help us understand how it may be used against other components.

If you are getting ready to perform an application penetration test or other security assessments against your applications, consider putting them all into scope. You may be surprised at what may be found.

March 22, 2016 by James Jardine

Webcast: Introduction to Penetration Testing for Application Teams

In most organizations it is the security team that initiates and manages the penetration tests. The application teams are called upon to ensure that an environment is available, credentials are created, and to remedy any findings in the report. Many application teams don’t even get the full report, rather just a listing of the findings. This listing often doesn’t include the needed details.

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0

March 9, 2016 by James Jardine

Getting More Value from a Penetration Test

Penetration testing is one of the most common ways for companies to measure their current state of security. Even companies or applications that do not require a penetration test for regulatory reasons rely on them to measure their success or failure. The intent is to hire someone to hack your network or application like “the bad guys” would, and then receive a report indicating weaknesses in the system.

There are multiple ways to measure the value one receives from a penetration test.

The results, or at least a summary of the assessment, can be provided to clients, vendors, or other 3rd party entities. This is typically done to attest that the company is meeting industry standards when it comes to security. Of course, this view is only from an attack perspective, and doesn’t identify actual security operations within the organization. It is a primal indicator to determine if you are susceptible to security weaknesses that could lead to a breach. This type of testing is often required by these outside entities.
The results are used internally to help measure the security stance of the organization or application. It is a chance to get verification whether or not the controls put in place are actually effective. It allows the testing of auditing and monitoring controls in real time. It creates a way to determine if patches are applied to the right resources. It helps validate what we should already know. It also helps identify possible items that are not known.
The results are actionable. The findings can be handed to a developer or administrator to be remediated. This creates the ability to reduce the known risk.

Organizations put a lot of focus on remediating the exact penetration test results. Unfortunately, this leads to a false sense of security. To understand why, you must understand how penetration test reports are consumed. The most important thing to keep in mind is that a penetration test is typically not focused on finding every vulnerability. It isn’t even focused on finding all instances of a specific vulnerability. The focus is identifying weaknesses and risks that are available and determining how much access those items may lead to.

Listen to the podcast of this topic

There are two pieces to a penetration test finding.

The finding – This is the high level identification of a classification of vulnerability. Cross Site Scripting or SQL injection are common examples of a finding.
The instance – This is an example of the finding. There can be multiple instances per finding in the report. Cross Site Scripting on the search results page is an example of an instance of the Cross Site Scripting finding.

Due to the nature of a penetration test, remediating the instances provided falls short from a security perspective. Organizations spend so much effort focusing on the wrong information. Rather than focus on the finding, the focus is typically on each instance of a finding. Let’s look at an example.

A penetration test identifies cross-site scripting in the final report. That finding has 2 instances drawn out. The first instance is on the profile page and the second instance is on the documents page.

When the report is provided it is common to see the organization focus on the instances. In the example above, a developer would be assigned to resolve those two instances of cross-site scripting and the finding would be considered closed. By remediating those two items are you sure the issue is really closed? Remember, the goal of the penetration test is not to identify every instance, but to identify the different risks.

Rather than focusing on the instances, it is important to start focusing on the actual finding. Using the same example from above, the organization should create a task to identify why they have cross-site scripting issues within the application and then how they want to proceed to remediate them.

This involves:

Identifying and understanding the flaw (May indicate needed training)
Understanding how the application is developed
Identifying how it should be coded securely
Going through the application identifying these items to resolve it application wide

By actually analyzing the flaw itself, a much larger impact can be made to the application. Working just the instances identified in the report is like trying to plug randomly identified holes in a sinking ship. Sure, it resolves that one issue, but what is happening with those holes you don’t see letting water in.

If a quick inspection of a ship identified a crack or issue in one location, wouldn’t you want to inspect the rest of the ship making sure that issue isn’t somewhere else?

Penetration tests provide different values, but it is time that the true potential is realized. Don’t stop at just trying to remediate the instances in the penetration test, start looking to enhance your overall security by analyzing the findings.

Thinking about starting a bug bounty? Do this first.

Vulnerability disclosure doesn’t require a bug bounty

Scoping your application security assessment (Applications)

Webcast: Introduction to Penetration Testing for Application Teams

Getting More Value from a Penetration Test

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us