application security

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.

April 13, 2016 by James Jardine

5 Things to Improve Your Application Security Program

Application security is on the top of everyone’s todo list, and it isn’t as easy as it seems. There are lots of moving parts supported by lots of solutions. We know it is not possible to do everything. James Jardine, our CEO, put together a webcast the other day with a few different things you can do to help improve your application security program.

Watch the Full Video

You might be surprised by the list, since it does not deal directly with the traditional recommendations of static or dynamic analyzers or threat modeling. Instead, he takes a higher level approach to look at how the program as a whole can be improved. Here is a quick rundown of the list (watch the free video for much more insight):

Getting the App Teams Involved

Neither the security teams or the applications can do it all alone. Although many may not want to admit it, we need each other. Traditionally, I have seen security teams trying to take on too much of the burden when it comes to tools and security aspects of an application. Unfortunately, they usually do not have the required skillets or the access to fix many of the issues that are identified. It is important to start getting the application teams, that includes the developers, business analysts, testers, and others all involved with the security of the application. Application security is everyone in the company’s responsibility. The app teams are capable of managing tools like static and dynamic analyzers and even doing some level of security testing. The critical first step in this process is having good solid communication and collaboration between the different teams.

Identify Skill-sets and Resources

Building on the process of getting the application teams involved, we need to understand what resources and skillets we currently have in our organization. Take the time to evaluate your resources to understand what is available. In addition, you need to understand what skillets you need for your tasks. There may be specific technical skill sets, like a specific programming language, or they may be management type skill sets you need. This is where the hard work comes in. It requires you to really understand what your goals are to help determine how you will get there. Once the lists are compiled, it is easier to identify which skill-sets or resources are in need. This leads us to the ability to then determine how we gain those skill-sets. It may be through hiring new resources, or it might just be that you need to provide some training to existing resources. Without having a solid understanding of what you want, you may find yourself hiring resources that don’t help move the program forward.

Training

Training is very important, in fact, it is a must have for the different teams. With the traditional separation of security and development, development doesn’t have as much security experience or training. As you move towards getting more application team involvement, training is the foundation to build upon. The team must have the resources to understand security at a high enough level to be efficient at the tasks they are responsible for. Don’t expect better application security if the teams are not getting the support they need.

Application Inventory

Do you have an application inventory where you track all of your applications? For most companies the answer is no, or we track some applications but they are not kept up to date. An application inventory helps quickly identify the applications, their data classifications, 3rd party library usage, and much more. With the reliance on so many 3rd party libraries, this can be useful when a library is found to be vulnerable. How do you know if it effects your applications or which ones? How do you know which apps have had penetration tests, or are even required too. The application inventory plays a key role in helping understand these decisions.

Policies and Procedures

Last, but not least, do you have policies and procedures in place regarding application security. These policies are what guide the teams into performing better security. If there are no guidelines in place, you can be sure that it will be much more difficult to get good compliance. Take the time to create the policies you need to help define how application security should be handled. Extend those policies and guidelines out to different pieces, such as static or dynamic scanning. How should those tools be used, who is responsible, when should they be executed. Defining the program helps guide the roadmap to an improved application security program.

Watch the Full Video

Jardine Software focuses on helping companies retrieve more value out of their programs. Contact us to discuss your concerns and understand how we can help improve your application security program.

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”

5 Things to Improve Your Application Security Program

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us