security testing

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.

January 23, 2017 by James Jardine

New browser security notifications highlight insecure connections

Creating an application and presenting it to others requires a lot of different security considerations. One of the most fundamental security controls is to provide a secure communication channel between the application and the server. For web applications, that focuses on the web browser to server communications. For mobile applications, it could be a built in web browser or the application making API calls directly. If you are developing IoT devices, it is the connection between the device and the back-end server.

Secure communication is most commonly conducted using HTTPS, or WSS for web sockets. HTTPS implements TLS (SSL is no longer recommended) to encrypt the data between the client and server. The encryption of the data reduces the risk of an attacker on the same network pathway from reading or manipulating the data. In addition, the use of a certificate provides authentication of who the client is communicating with. Let’s take a look at how each of these helps reduce risk.

Authentication

The first thing we want to understand is how authentication is provided by our secure communication. Certificates are issued by certificate authorities that are supposed to verify the identity of the organization requesting the certificate. Once the application is complete, and the certificate is installed on the server, the user will receive the valid certificate. When the user visits that application over HTTPS, a green lock will typically appear indicating that the connection is secure. It is possible to dig into that status icon to get the name of the organization that requested the certificate. For organizations that get an EV (Extended Verification) certificate, it may show the organization name in the address bar.

Certificates from root certificate authorities are already trusted by most browsers. This factor makes browsing most applications seamless. If a certificate is self-signed or not from a trusted authority, browsers will display a warning message to the user. This warning helps bring to attention the fact there is an issue, or higher risk, when visiting that application. Many organizations will use self-signed certificates internally. If the certificate is not properly deployed and trusted on all the user systems, it can lead to confusion when dealing with the browser alert. It could create a situation where user’s just click through any notifications without understanding them. This authentication and trust allows the user to know who they are communicating with.

Secure Communication

Protecting the communication from eavesdroppers is critical for applications that transmit sensitive data, such as PII, credit card numbers, account numbers, etc. When data is transmitted in clear text, it is possible for others on the same network segments (between the user and the server) to potentially view that data. This allows for stealing passwords and other sensitive information.

Don’t assume that a site/application that doesn’t contain sensitive information shouldn’t be concerned with secure communication. Just because there is a lack of sensitive information, there is still a risk to the end user. Just as an attacker may eavesdrop on communications, there is also the possibility they can manipulate the traffic from the server to the client. Using this technique, the attacker can modify the response to remove security controls, modify the content displayed, or even inject malicious content into the page to attack the user directly. By encrypting the transmission, it makes it much more difficult to manipulate any of the data, helping provide more protection to the end user.

How Browsers Help

Starting this year, well, this month actually, both FireFox and Chrome are releasing updates to help notify users when their connection is insecure. The browsers already have a mechanism to help alert users of issues with certificates (self-signed, expired) and they are now adding additional notifications.

FireFox will be adding a grey lock with a red line through it when an application is found to be using HTTP (non-secure) and transmits passwords.

Chrome will be adding a notification similar to FireFox when an application is found to be using HTTP and transmits passwords or credit card numbers.

In both cases, the goal is to help notify the user that some form of sensitive information is being passed over a non-secure channel, exposing them to more risk.

What Now?

Here are a few questions to consider regarding the use of secure communications:

Do you know what applications, in your organization, are not using a secure communication channel?
Have you analyzed the risk around not implementing HTTPS?
What is preventing the use of HTTPS on all of your applications?
Do you have a plan to provide a response to users that may have questions if they see these new notifications?
Do your QA engineers know how to identify and properly handle this scenario during testing?

There may be technical issues prohibiting the use of HTTPS. If so, are they documented and understood? The first step is having a grasp on your applications and the user base. the next step is understanding the technical details to support the appropriate implementation.

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

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.

August 17, 2016 by James Jardine

Should Your Application Have a Security Test?

The world is driven by technology and applications are at the forefront. You see them as corporate site, blogs, business critical applications and on the Internet of Things devices. Some are publicly available, others only available on the internal network. So which ones need to be tested for security?

The simple answer: All of them.

But is it really that simple? Of course, you have to prioritize your focus when performing security testing. There isn’t a strict formula that defines your specific priorities. Lets walk through a few scenarios and think about the potential impact.

Business Critical Applications Exposed to on the Internet

Due to the criticality of these applications, they should be higher on the priority list. Often times, these applications will contain sensitive information, of some sort. This data may be passwords (for login), credit card info, health info, financial info, or other information considered sensitive. Not only do you have a duty to protect your user’s information, you may also be under regulatory oversight.

These critical applications are an obvious target for hackers. These systems are typically public facing, however they require valid user accounts for full access. You shouldn’t assume that because the application requires a login, it isn’t public facing. Due to the availability and criticality of the functionality, these are the most commonly tested types of applications.

Business Critical Applications on the Intranet

Many organizations have applications that are only available on the local network. Like the internet exposed applications, these can still contain sensitive information and be a high priority for the organization. These applications often receive less attention from a security standpoint because they are not publicly available. While the exposure to potential hackers is reduced, these applications should not be completely overlooked due to the risk of an insider threat.

That Marketing Site Hosted by a Third Party

Almost all businesses have some form of marketing site. It is the corporate landing page to provide basic information to potential visitors. Often times these sites are even hosted externally, by a third party. This doesn’t mean they don’t present a risk. One example of this is a watering hole attack. In this scenario, an attacker may take advantage of a benign website that is frequented by a specific group of people. Once the potential victim loads the page, a malicious application may be planted and the user infected.

The risk here may be very different than the attack on business critical applications. Even a full compromise of the site would not be a direct link to business critical/sensitive information. It still must be realized that it does maintain a certain level of risk.

“Smart” Devices

The market is seeing a lot more devices that have internet capabilities. This goes from kids toys, televisions, all the way to automobiles. These types of devices present a different level of risk. You must understand what its availability is: Internal or External. What can the device do if it were to be remotely attacked? What type of data does it handle, and are you protecting that data in both transit and storage?

What Type of Testing Do I Need?

Depending on your risk level, the level of testing may vary. For example, those business critical applications should have an in-depth test performed. This includes both manual penetration testing as well as secure code reviews. For those sites that are at a much lower level, automated testing may be the right start. Application security is about understanding and managing the risks presented. Remember that all applications, no matter their size or functionality, could be a target.

No matter what type of application it is, or what type of testing may be required, a secure development process should be followed. Testing is great for finding flaws after the fact, but it is much better to not introduce them at all. This is done by having application teams that are aware of the types of security issues effecting their applications. This includes training for the teams, secure coding techniques, security testing and secure design. When these things are baked into the process, the external security testing becomes a formality and a last chance effort to find anything overlooked.

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

Thinking about starting a bug bounty? Do this first.

Vulnerability disclosure doesn’t require a bug bounty

New browser security notifications highlight insecure connections

Scoping your application security assessment (Applications)

Should Your Application Have a Security Test?

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us