appsec – Page 2

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.

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 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.

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.

5 mistakes to avoid to hire qualified application security talent

SSL Labs Grading Changes and HSTS

Scoping your application security assessment (Applications)

Application Security and Responsibility

Understanding the “Why”

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us