application security

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.

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 10, 2017 by James Jardine

When it comes to security, read the instructions

Many of us are fairly technical and have gotten along just fine just clicking through wizards to install new software or devices. For many, it is like building your favorite furniture from IKEA. Who needs instructions? You fight your way through it, making assumptions on what pieces go where and with which hardware. With your furniture, a missed step may lead to some left over parts and the item collapsing at an unfortunate time. With software and devices, a missed step could lead to the loss of sensitive data, loss of money, or even possibly physical harm.

In a perfect world, software and devices would force secure defaults and then require explicit actions to remove that security. We don’t live in that perfect world. This was seen with the recent news about MongoDB databases being exposed on the internet and infected with ransomeware.

In the case of MongoDB, misconfigurations may bind the database port to the public interface, while also allowing anonymous access. This combination can be devastating. Doing a quick search on Shodan you may find there are thousands of misconfigured MondoDB servers exposed on the internet.

Like many other software packages, MongoDB has a security checklist available to help minimize this exposure. The checklist covers important steps, such as enforcing authentication and limiting network exposure. I am seeing more packages that are including security checklists, or security guides that are available. If you are installing something new, take a moment to see if there is a guide availble to properly secure the item.

In addition to the security checklist, the creators of MongoDB have created a post addressing the ransomware attacks that are happening. This link points out a few other items to help secure your MongoDB instance. It also points out that the most popular installer for MongoDB (RPM) limits network access to localhost. This default configuration is critical in helping reduce the exposure of these databases.

As time goes on, I expect we will see more improvements made to these types of products that make them more secure by default. As an organization developing this type of software, or devices, think about how the item is installed and how that reflects security. Starting off more secure and requiring explicit configuration to open make the item available will provide much better protection than it being open by default.

If you are running MongoDB, go back and check the security checklist. Make sure you are not exposing the instance publicly and authentication is enabled. If you are running other software or devices, make sure to know where they are and determine if they are deployed securely. Check to see if a security checklist exists.

We are often in a hurry and just click through the prompts of an installer. However, to provide the proper risk management, we must take the next steps to understand the configurations to protect our assets.

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.

November 22, 2016 by James Jardine

5 mistakes to avoid to hire qualified application security talent

Hiring for application security positions is often seen as almost impossible. With many claims of talent shortages and so many open positions, finding the right candidate can be a daunting task. Here are 5 common mistakes to avoid and how to get past them.

Not understanding your current needs

If you are thinking about bringing on an additional resource focused on application security, you must understand what the duties will be. Unfortunately, due to the constant pressure to be secure, many companies focus on having the resources and then trying to determine what they will be expected to do. While this may be the case for the initial hire of a brand new application security program, it shouldn’t be the norm.

Understanding your needs requires work. It requires understanding what your immediate priorities are vs. the long term goals. While both of these may play into the candidates skill sets, focusing on the immediate may result in a quicker hire. There are many different tasks that an application security professional may perform. For example, working with static or dynamic analysis tools, or helping with threat modeling. They may also be creating automation around identifying security issues within the organization’s environment. You have to ask yourself, which of these are the current priority. Your organization may implement static analysis this year, but have dynamic analysis scheduled out a year. Maybe manual testing (red teaming) is a nice to have, but you know you won’t have time to build up that program for a few months.

Ignoring existing resources

Once you have a good understanding of what your needs are, it is time to look at existing resources. The common mistake is to just look at the security team. Instead, look at the application teams as well. What type of resources and skill sets exist within the organization. Business analysts are great at digging into understanding problems and gathering requirements. Developers know development and are typically great problem solvers. QA testers know how to test applications. Project managers know how to efficiently schedule tasks to get the project to its expected milestones.

All of theses resources, none of which are dedicated to security, provide a wealth of experience that can be applied to security. Let’s be honest, application security should be a part of each of these roles if we expect it to be successful.

Not sharing the workload

Just because it says application security doesn’t mean everything has to be handled or executed by the application security team. Many of the application security programs can be spread across multiple teams. For example, dynamic analysis could be integrated into the QA team’s responsibilities. The team already performs testing against the application, it makes sense to put dynamic testing within this context. Shifting the ownership to the correct location adds many benefits. First, it allows the application security team to focus on more specialized tasks. If using on-premise static analysis, this may include writing custom rulesets vs. just executing the tool and reformatting the results. It also helps embed security into the SDLC. The verification phase will now not only test for the common bugs, but also for the security bugs. In addition, the bugs will all be tracked using the same process, requiring less implementation effort.

There are many application security tasks that can be integrated into the existing SDLC processes. This will typically require engagement from the application security team to help guide the creation of these processes. That may be, however, what defines the role you are trying to fill.

Not defining the role

Once you have a good understanding of your needs and what still falls within the application security team’s responsibility, you can start to define the role you see. This process still relies heavily on understanding your needs, filtering out what is covered by current resources. Depending on the size of your organization and your application security team, the role may be very broad or very specific. It is this definition, however, that will drive the job requirements that get shared to human resources.

Overly broad job requirements

Getting candidates interested in the open position is critical to getting their attention. Being specific about what you are really looking for helps reduce noise and attract more relevant candidates. Often times job requirements are very broad and cover every possible task that may be performed. How often do those tasks actually get performed once someone is brought in? Some of them may never get executed.

Having too broad of requirements may cause great people to pass on by, thinking they don’t have all the skill sets needed. On the other hand, people may apply because they have one of those skill sets and it never gets used once they are hired.

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

November 21, 2016 by James Jardine

SSL Labs Grading Changes and HSTS

Qualys recently posted about some grading changes coming to SSL Labs in 2017. If you are not aware of SSL Labs, it is a service to check your SSL/TLS implementation for your web applications to determine how secure they are. While there were more changes listed, you can read about them in the link above, I wanted to focus on the one regarding HTTP Strict Transport Security (HSTS).

If you haven’t heard of HSTS, or want a quick refresher, you can check out this post: HTTP Strict Transport Security (HSTS): Overview.

According to Qualys, the changes regarding HSTS will not be implemented until later in 2017, not with the initial set of changes. However, this early notification may help some companies make preparations for the change. Here is what they say about HSTS grading changes:

HSTS Preloading required for A+
HSTS required for A

Some organizations have specific requirements to the grade they expect to receive on the SSL Labs report. If an A is your target, HSTS is going to be a critical component for that. Even if it is not, this change is a clear indication that HSTS does not look like it is going away.

HSTS is a great way to help increase the security of your transmission from browser to server. However, it may not be something that can just be turned on. We have seen many sites have difficulty going to 100% HTTPS, and HSTS doesn’t play well with mixed content. It also doesn’t play well with self-signed certificates. While these are important for the increased security it provides, this is where the difficulty may come in.

If you are not using HSTS currently, now may be the time to start thinking about it. Creating the header is typically not very difficult. Testing to make sure nothing breaks because of it can be a bit more tedious. Want to know more about HSTS or application security?

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.

New browser security notifications highlight insecure connections

When it comes to security, read the instructions

5 mistakes to avoid to hire qualified application security talent

SSL Labs Grading Changes and HSTS

Scoping your application security assessment (Applications)

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us