James Jardine – Page 3

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.

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.

July 20, 2016 by James Jardine

You don’t need to play Pokemon Go to get a reward

Pokemon Go is taking over the world. An “augmented reality” platform where you hunt pokemon characters using your phone and GPS coordinates. Many voice concern over privacy and safety.

I recently talked about those concerns on Channel 4 News:

Watch the Full Interview

The attention focused on security and privacy distracts from three other areas worthy of discussion. In some cases, the solutions might be more challenging and less obvious. That’s precisely why we can use the Pokemon Go craze to advance the dialogue in our organizations. Here are some of the areas to tackle:

Fake Applications

Due to the overwhelming success of the app so far, there have been a high number of fake, or malicious, applications being released. These applications are billed as being the real Pokemon Go application, but instead are malware used to gain access to the user’s device. These fake apps are found on 3rd party sites, not typically in the official app stores.

My questions to the organizations out there:

Have you thought about how these rogue applications could be created in response to your applications?
What effect does that have on your organization and your users?
Are there any controls you can implement that would help stop that type of behavior?

I’m fascinated with exploring if/how this could be stopped. I am not sure there is a way for an organization to completely block fake apps disguised as their own. It may be possible to issue takedown orders, but that could get out of hand pretty quickly. It also requires you to be tracking all of these apps that pop up. Maybe the best we can do is reinforce with our users where to get the official application and not to download it from 3rd party sites.

One of the factors that made fake apps so popular with Pokemon Go is the fact that the app was not released to everyone at one time. This leads to users looking for a way to get access before it is available to them.

Scams

Popularity brings scams. Whether it is phishing, vishing, smishing or any other type of scam, we may want to start thinking about the possibilities before the release. While we cannot stop scammers from taking advantage of our popularity, there may be some ways to reduce some of the risk.

Take this example from Pokemon Go. Not long after the release, there were reports of phishing emails going around indicating that due to the popularity of the game it would no longer be free. The user’s account would be locked if they didn’t go to a website and start paying $12.99/mo for access. This could lead to stealing of credit card information or user credentials.

Three questions to guide the conversation:

How do you communicate to your customers/users?
How does your business model affect the types of scams available?
How do customers contact the organization for concerns, and are you ready for it?

This isn’t a new technique. Rumors of Facebook going to a pay service have spread for a long time. None have been true from what I can tell. However, this gives us an example of the types of scams that may be used. It allows us to consider how we can handle this type of communication if it were to happen. I wonder how the communication would happen if an app did decide to switch to a monthly service. Would the notice come from within the application? Would the company release information on their official site? How would the user’s know?

Legal

Inevitably, organizations that provide products and services are under heavy legal scrutiny. Of course there are the obvious issues that come up all the time. With Pokemon Go, we are going to see some interesting cases attempting to make the game and its creators liable for a myriad of incidents. We have already seen in the news incidents where players were caught trespassing in a zoo, shot at in their car, and even automobile accidents.

Three questions to consider:

How involved is the legal group during the creation of an application?
What do your terms of service cover regarding liability concerns?
Is your legal group ready to respond to raised concerns?

While none of these events have brought legal suit against the game or its creators, these are things that should be considered with such an interactive offering. Reducing liability through a terms of service may be the first step, it may not be a complete solution. I am no lawyer, but do believe that this is another area that should be fully understood when analyzing the risk of an application. What are you doing to be prepared if legal action is taken?

Next Steps

There are a lot of things to consider when we create new applications and services. Some of these things can be solved, while others cannot. It is impossible to think of all the different things that could go wrong. However, if we look at the things that occur for other applications, we can see new ways to view our own applications and procedures. Maybe no changes will be made, but at least we will have considered some of these topics, rather than being blind to them.

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

July 12, 2016 by James Jardine

Application Security and Responsibility

Who is responsible for application security within your organization? While this is something I don’t hear asked very often, when I look around the implied answer is the security team. This isn’t just limited to application security either. Look at network security. Who, in your organization, is responsible for network security? From my experience, the answer is still the security group. But is that how it should be? Is there a better way?

Security has spent a lot of effort to take and accept all of this responsibility. How often have you heard that security is the gate keeper to any production releases? Security has to test your application first. Security has to approve any vulnerabilities that may get accepted. Security has to ….

I won’t argue that the security group has a lot of responsibility when it comes to application security. However, they shouldn’t have all of it, or even a majority of it. If we take a step back for a moment, lets think about how applications are created. Applications are created by application teams which consist of app owners, business analysts, developers, testers, project managers, and business units. Yet, when there is a security risk with the application it is typically the security group under fire. The security group typically doesn’t have any ability to write or fix the application, and they shouldn’t. There is a separation, but are you sure you know where it is?

I have done a few presentations recently where I focus on getting application teams involved in security. I think it is important for organizations to think about this topic because for too long we have tried to separate the duties at the wrong spot.

The first thing I like to point out is that the application development teams are smart, really smart. They are creating complex business functions that drive most organizations. We need to harness this knowledge rather than trying to augment it with other people. You might find this surprising, but most application security tools have GUIs that anyone on your app dev teams can use with little experience. Yet, most organizations I have been into have the security group running the security tools (such as Veracode, Checkmarx, WhiteHat, Contrast, etc). This is an extra layer that just decreases the efficiency of the process.

By getting the right resources involved with some of these tools and tasks, it not only gets security closer to the source, but it also frees up the security team for other activities. Moving security into the development process increases efficiency. Rather than waiting on a scan by the security team, the app team can run the scans and get the results more quickly. Even better, they can build it into their integration process and most likely automate much of the work. This changes the security team to be reserved for the more complex security issues. It also makes the security team more scalable when they do not have to just manage tools.

I know what you are thinking.. But the application team doesn’t understand security. I will give it to you, in may organizations this is very true. But why? Here we have identified what the problem really is. Currently, security tries to throw tools at the issue and manage those tools. But the real problem is that we are not focusing on maturing the application teams. We attempt to separate security from the development lifecycle. I did a podcast on discussing current application security training for development teams.

Listen to the podcast on AppSec Training

Everyone has a responsibility for application security, but we need to put a bigger focus on the application teams and getting them involved. We cannot continue to just hurl statements about getting these teams involved over the fence. We say to implement security into the SDLC, but rarely are we defining these items. We say to educate the developers, but typically just provide offensive security testing training, 1-2 days a year. We are not taking the time to identify how they work, how their processes flow, etc. to determine how to address the problem.

Take a look at your program and really understand it. What are you currently doing? Who is performing what roles? What resources do you have and are you using them effectively? What type of training are you providing and is it effective regarding your goals?

We will be discussing more of these topics in the future. To get started in your own organization, start with the questions above. Want to talk more about these topics? Contact us

June 3, 2016 by James Jardine

Understanding the “Why”

If I told you to adjust your seat before adjusting your mirror in your car, would you just do it? Just because I said so, or do you understand why there is a specific order? Most of us retain concepts better when we can understand them logically.

Developing applications requires a lot of moving pieces. An important piece in that process is implementing security controls to help protect the application, the company, and the users. In many organizations, security is heavily guided by an outside group, i.e.. the security group or 3rd party testers.

Listen to the podcast of this topic

Looking at an external test, or even a test by an internal security team, often the result is a report containing findings. These findings typically include a recommendation to guide the application team in a direction to help reduce or mitigate the finding. In my experience, the recommendations tend to be pretty generic. For example, a username harvesting flaw may come with a recommendation to return the same message for both valid and invalid user names. In most cases, this is a valid recommendation as it is the reason for the flaw.

But Why? Why does it matter?

Working with application teams, it quickly becomes clear the level of understanding regarding security topics. The part that is often missing is the Why. Sure, the team can implement a generic message (using the username harvesting flaw above) and it may solve the finding. But does it solve the real issue? What are the chances that when you come back and test another app for this same development team that the flaw may exist somewhere else? When we take the time to really explain why this finding is a concern, how it can be abused, and start discussing ways to mitigate it, the team gets better. Push aside the “sky is falling” and take the time to understand the application and context.

As security professionals we focus too much on fixing a vulnerability. Don’t get me wrong, the vulnerability should be fixed, but we are too focused. Taking a step back allows us to see a better approach. It is much more than just identifying flaws. It is about getting the application teams to understand why they are flaws (not just because security said so) so they become a consideration in future development. This includes the entire application team, not just developers. Lets look at another example.

An Example

Let’s say that you have a change password form that doesn’t require the current password. As a security professional, your wheels are probably spinning. Thinking about issues like CSRF. From a development side, the typical response “Why do I need to input my password when I just did that to login to change my password?” While the change will most likely get made, because security said it had too, there is still a lack of understanding from the application team. If CSRF was your first reason, what if they have CSRF protections already in place? Do you have another reason? What about if the account is hijacked somehow, or a person sits at the user’s desk and they forgot to lock their PC? By explaining the reasoning behind the requirement, it starts to make sense and is better received. It dominos into a chance that the next project that is developed will take this into consideration.

When the business analysts sits down to write the next change password user story, it will be a part of it. Not because security said so, but because they understand the use case better and how to protect it.

If you are receiving test results, take the time to make sure you understand the findings and the WHY. It will help providing a learning objective as well as reduce the risk of not correcting the problem. Understand how the issue and remediation effects your application and users.

Scoping your application security assessment (Applications)

Should Your Application Have a Security Test?

You don’t need to play Pokemon Go to get a reward

Application Security and Responsibility

Understanding the “Why”

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us