How Serious is Username Enumeration

Looking through Twitter recently, I caught a very interesting stream that started with the following message:

There were quite a few replies, and a good discussion on the topic of the seriousness of username enumeration flaws. 140 characters is difficult to share a lot of thoughts, so I thought this would actually be a great post.

What is Username Enumeration?

Username Enumeration refers to the ability to determine not only if a username is valid within a specific application, but also to automate the process of identifying a multiple valid usernames. The most common example of username harvesting is on the application logon form. The culprit, the unsuccessful login error message. This happens because the application creators want to be helpful and let the user know what went wrong. When the message is not generic, for example “unsuccessful login”, it may indicate if the user exists or not. An example message would be “Username does not exist”. This is bad. A better response would be “Username or password are incorrect”. This is a much more generic answer and doesn’t give away whether or not the username is valid.

Where do we find Username Enumeration?

As I mentioned above, the login screen is one of the most common locations we find username harvesting. However, it is not the only place. Probably the two next biggest offenders are the Forgot Password screen and the User Registration screen. With all three of these screens, it is critical to realize that the display message is not the only way to detect username harvesting. In reality, it is any difference that comes back between an invalid and a valid user. This could be the error message, a status code that is different, timing attacks, or a myriad of other techniques. Don’t just think about the error message. That one is typically the easiest, but not the only method for identification. API calls may also be a source for username harvesting.

The Login Form

The login form is typically vulnerable through the error message. To help protect the login form, make sure that the application returns a generic error message for any error situation. A good example of this is “Your login attempt was unsuccessful. If you continue to have trouble, contact support.” This message is good for invalid username, invalid password, and even account lockout.

The Forgot Password Form

The forgot password screen is usually vulnerable due to poor forget password design. Most systems ask for the username/email address and if correct, do one of the following: 1) Ask for secret security questions, 2) Display a message that an email has been sent to the email address on record. Unfortunately, for an incorrect username, the system returns an error message that the username was not found. To correct this problem, it is possible to either ask for more than just the username (something that is private to the account), or just always display the “email has been sent” message. In this configuration, no matter what, the email is sent form is displayed.

The Registration Form

The registration screen is a bit more tricky because, in most situations, you need to be able to alert the user that their username is already in use. Unlike the other two scenarios, the error message can’t really be fixed. One option on a registration screen is to enable the use of a CAPTCHA to attempt preventing automation attacks. If implemented properly the attacker would be slowed down in their enumeration making things more difficult. It may not make it impossible, but the goal is to reduce the risk.

How is Username Enumeration Used?

There are a few ways that username enumeration becomes important to an attacker. First, it is a good technique to limit down the list of possible usernames to attempt password attacks on. One example on twitter gave the example of taking a list of 100 million usernames and reducing it to 100 thousand to perform actual password guessing on. In this scenario, the attackers are also attempting to take advantage of weak password complexity, or just bad password hygiene. Often times, they may take the top 3 or 4 common passwords and try those against all of the valid usernames to see if anyone is using them.

The second way that username enumeration is used is for social engineering attacks. Or, at least, more targeted social engineering attacks. If the attacker knows that the user has an account on a specific application, it can make phone calls and emails much more convincing and ultimately more successful. Limiting emails to 100,000 users rather than 100 million helps reduce the overhead and reduces the chances of getting detected.

Somewhat related to social engineering attacks, this information could also be used to target individuals based on moral values. Remember the Ashley Madison breach that happened a while back. Depending on what the username is in use, it may be possible to identify people that use a particular site and sort of out them, or blackmail them. Think of other sites people may not want to be public about visiting.

How Serious is it?

I bet you didn’t think we would ever get here. It is important to understand how the attackers may be using a vulnerability to start to determine how serious it really is. Unfortunately, there isn’t an easy answer that fits every application. As I mentioned above, with poor password hygiene, the risk would be raised if someone is using one of those top 4 passwords. It also depends on the type of system, the type of data collected, the functionality the application performs, etc. No systems are created or rated equally.

In the scenario above for the login screen guessing the top 4 passwords, let’s not forget that it is possible to try all 100 million usernames from our list. Sure, it is helpful to reduce it down to only valid usernames, but the attack is still possible without the username enumeration flaw. In the ideal setup, the application would have some form of detection system in place that might detect all of the unsuccessful login attempts, but that is the ideal. It is not common enough to see that type of detection implemented in many applications. Without that detection, and a little crafty rate limiting by an attacker, the difference between 100 million attempts and 100,000 attempts is really just time.

As we all know, social engineering attacks are the latest and greatest. Any help we provide attackers in that arena is a step backwards for us. This could lead to a bigger problem and that is why we need to understand the issues we are trying to solve.

Should we fix it?

If we had all the time and resources in the world, the answer would be an easy “yes”. Unfortunately, we don’t have that. This really comes down to your organization’s risk assessments and priorities. I always like to provide the recommendation to resolve the issue, as it makes for a better application overall. Depending on your situation, the fix may not be straight forward or easy. You may have other higher priority items that need to be worked on. Remember, for the password attack, it is really a combination of a weak password issue as well. It is not just username harvesting on its own.

Take the opportunity to review how you are auditing and logging these types of events within your application. In some cases we may see logging occurring, but then there is no auditing of those logs. Detection and response is critical in helping reduce the risk of these types of flaws.

Continuing Forward

Username enumeration is a risk to any application. It is up to the organization to understand their business to determine how big or small that risk is. This isn’t something that should just be ignored, but it also doesn’t mean it is something that is a critical finding. Don’t just write the finding off. Use that as an opportunity to discuss the functionality, understand how it works, and determine the best course of action for the organization and the users.

Username enumeration is typically fairly simple to test for and should be worked into the QA testing cycle. Take the time to discuss with the architects, developers, business analysts, and the testers how the organization can test for this and reduce the risk.

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.

Should Password Change Invalidate All Access Tokens?

Passwords are a part of our every day life. It is no wonder they are under such scrutiny, with many breaches focusing on them. We all know how to manage our passwords, or at least we should by now. We know that we should change our passwords every once in a while, especially if we believe they may have been a part of a recent breach. What about those access tokens?

Access tokens are typically used by your mobile devices to access your account without the need for you to enter in your username and password every time. In some situations, you may have to create an app password for your mobile device if you are using 2-factor authentication. This is because most applications still don’t support the 2-factor model. Instead, you create an application password and use that with your application.

Depending on your system, the management of these app passwords or tokens can vary quite a bit. In this post, I want to focus on how the ideal solution may work. First, the access tokens and the user’s password should not be related in any way. The closest they come to any relation is that they both provide authentication to the same application. This purpose here is that the compromise of one, does not compromise the other. While getting access to an access token may give me access to the account, it should not give me access to the password. If you are thinking that the access to the account means I could change the password, let me stop you right there. A good system would require the current password to be able to change the password. So this should be prohibited.

In the same vein, getting access to the account password should not lead to the compromise of the account’s access tokens. In a good system, there should be a way to manage these tokens, but that management should not include the ability to view existing tokens. Instead, that functionality is used to revoke an access token. In the instance of an application password (2-factor), you may also have the ability to create a new application password. This would still not give access to the existing password or token values.

So the question posed, or implied: If you change your account password, should that invalidate your devices?

If there is truly no relationship between the two items, and one doesn’t effect the other, then there may not be a reason to invalidate everything for every password change. As a good friend likes to always say, “what is the problem we are trying to solve?” So what is the problem? Let’s look at a few scenarios:

User just wanted to change their password

It is not unusual for a user to want to change their password. They may have even forgotten it. In this case, if the password and access tokens are unrelated, I don’t see a big risk around the access tokens that may have been created for other devices. The password should be completely separate from the access tokens and the change should have no impact to the mobile devices.

User’s password was leaked in a recent breach

This scenario is very similar to the one above. However, if an account has been compromised, it makes sense to review the devices that have been granted access and remove any that should not be there. The account compromise should not lead to the compromise of the access tokens already generated, but may enable the creation, or addition, of access tokens for new devices.

User’s device was lost or stolen

Something no one wants to think about, their device getting lost or stolen. In this case, the specific device’s access token has probably been compromised. This shouldn’t lead to a compromise of the user’s actual password. Like the above example, there should be a way for the user to log into their account and revoke access to that specific device, or worst case, all devices.

Should we, or shouldn’t we?

I don’t think there is an exact answer here. I think if done right, the two pieces are separate and stand alone. What happens to one, shouldn’t have an effect on the other. Unfortunately, that is not how things work in the real world. If you are a developer or architect designing these systems, take the time to consider these questions. Understand how your applications work, how the authentication pieces fit together, and how that will all tie together for the user experience. It may make sense to reset everything every time. On the flip side, it shouldn’t have to if designed properly. Remember the question: “What are we trying to solve?”

Application security is moving at a rapid pace, and it is great to see these types of topics coming up. As we start to raise more questions, we start to have more discussions. Share your feedback with us about this topic. Are there concerns that should be raised? Are there risks that should be considered? Share your thoughts with out on Twitter (@developsec).

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.

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?

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.

Originally posted at https://www.jardinesoftware.com

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.

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.

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.

Originally posted at https://www.jardinesoftware.com

ImageMagick – Take-aways

Do your applications accept file uploads? More specifically, image uploads? Do you use a site that allows you to upload images? If you haven’t been following the news lately, there was recently a few vulnerabilities found in the ImageMagick image library. This library is very common in websites to perform image processing. The vulnerability allows remote code execution (RCE) on the web server, which is very dangerous. For more specific details on the vulnerability itself, check out this post on the Sucuri Blog.

There are a few things I wanted to focus on that are less about ImageMagick and more focused on better security solutions.

Application Inventory

I know, enough already. I get it, I mention application inventory all the time. It is with good reason. We rely heavily on 3rd part components just like ImageMagick and there are bound to be security flaws identified in them. Some may be less critical, while others demanding the highest priority. The issue at hand is that we cannot defend against the unknown. In this case, even if we are aware of a vulnerability, it doesn’t help us if we are not aware we use the vulnerable component. Time is important, especially when it comes to critical type issues. You need to be able to quickly determine if your company uses the vulnerable component, which apps are effected, and what types of data resides in those systems. Performing fire drills for every vulnerability announced is very inefficient. Being able to quickly identify the effected areas allows for a better understanding of any risk changes.

Permissions

When you are configuring your applications, think about the type of permissions the application has on the server. Does it have the ability to write to specific folders, execute specific files, read data, etc.? Does the application run as an administrator with full rights? To help reduce the attack surface we must understand what the app needs to do, and then make sure the permissions are aligned with those needs. In this case, the files may be stored on the file system to be used later so write permissions may be required. It is still possible to limit those write permissions to specific folders and even limiting execution permissions.

Application Configuration

How you design and configure your application plays a significant role in how security is handled. In regards to allowing file uploads, how do you handle storing the files? Are they on the file system or in the database? How are features configured? In the case of ImageMagick, there are configuration settings that can be set to limit the vulnerabilities. Make sure that you are only accepting file types that are needed and discarding others. These configurations can take many forms, but will help provide security when they are truly understood.

Importance of Input Validation

The vulnerability in ImageMagick highlights the importance of sanitizing input and performing solid validation. In this case, the file name is not properly handled which allows an attacker to run unintended commands. We have to check to make sure that the data passed to our applications is what we are expecting. If it is not, then it must be discarded.

This is not the last time we will see a vulnerable component that is used by lots of applications. It is part of the risk of using external components. We can do more on our side to make sure that we know what we are using and preparing for the event that something goes wrong. Take the time to understand your applications and think about the different ways security may be effected.

Reliance on 3rd Party Components

It was just recently announced that Apple will no longer be supporting QuickTime for Windows. Just like any other software, when support has ended, the software becomes a security risk. As a matter of fact, there are current known vulnerabilities in QuickTime that will never get patched. The Department of Homeland Security has an alert recommending removal of QuickTime for Windows.

For users, it may seem simple: Uninstall QuickTime from your Windows system. But wait.. what about software they rely on that may require quicktime? There are times when our users are locked into some technologies because of the software we create. How does our decision to use a specific technology have an effect on our end users when it comes to security?

If you have created an application that relies on the installation of QuickTime for Windows this creates somewhat of an issue. It can be very difficult to justify your position to end users to continue using a component that is not only known vulnerable, but is also past the end of life. This brings up a few things to consider when using third party components in our solutions.

Why use the component/technology?

The first question to ask is why do we need this component or technology. Is this a small feature within our application or does our entire business model rely on this. What benefit are we getting by using this component. Are there multiple components by different sources? What process was used to pick the used component? Did you look at the history of the creator, the reviews from other users, how active development is, etc.? When picking a component, more is required than just picking the one with the prettiest marketing page.

How do we handle Updates?

The number of breaches and security vulnerabilities documented is at an all time high. You need to be prepared for the event that there are updates, most likely critical, to the component. How will you handle these updates. What type of process will be in place to make sure that the application is compatible with all of these updates so the user is not forced to use an out-dated version? What would you do if the update removed a critical feature your application relies upon?

What if the component is discontinued?

Handling the updates and patches is one thing, but what happens if the component becomes end of life? When the component is no longer supported there is a greater possibility of security risks around it that will not get fixed. In most situations this will probably lead to the decision to stop using that component. I know, this seems like something we don’t want to think about, but it is critical that all of these possibilities are understood.

We use components in almost any software that we create. We rely on these components. Taking the time to create a process around how these components are selected and how they are maintained will help reduce headache later on. We often focus on the now, forgetting about what may happen tomorrow. Take the time to think about how the component is maintained going forward and how it would effect your business if it went away one day. Will you ask your users to continue using a known vulnerable component, or will you have a plan to make the necessary changes to no longer rely on that component?

Security in Testing Environments

When it comes to creating applications, there is a need for multiple environments to support the development process. It typically starts on the developers own computer, then on to an integration environment, a QA testing environment, possibly a UAT (User Acceptance Testing) environment, and then finally production. Depending on your organization, you may have some, none, or all of these different environments.

When it comes to security, the focus is typically on the production environment. This is where the instances that all of the users use are on a daily basis. This has all the “real” data. It is where real credit card numbers or social security numbers may reside. There is a lot of effort put on securing the production environment.

What about the test environments?

If your testing environments are externally exposed, the security of those environments are just as important. Anything exposed externally is a target and needs to be considered. Just recently there was an article about a test database being exposed that resulted in leaked data. This is an opportunity for us to look at our own systems to understand what we are doing with our test environments.

Some things to think about within your test environments:

  • What do we actually have exposed externally – Keep an inventory of the software, services and devices that are exposed. This includes any databases, web servers, ports, etc.
  • Ensure the endpoints are properly locked down – Make sure that your systems are not left wide-open. Don’t leave default passwords in place, make sure they are changed to be unique. If you are running some form of database server, make sure it is not exposed and that it has authentication enabled on it.
  • Check the validity of data – What type of data do you use in your test environment? Are you using a straight copy of production (shame on you)? What type of data scrubbing are you performing? Are you performing data scrubbing? What types of sensitive information may be stored in the environment.
  • Who has access to the environment – Is the environment limited to specific IP addresses or clients? Is it open to anyone that has a valid username and password? Who should it be open to?
  • Where are the servers – Consider where these servers are located. Are they in the same environment as the production servers? What about the corporate network?

These lower-level environments produce risk and should be tracked accordingly. Don’t discount them just because they are “test”.

The Hidden Reason for Switching to HTTPS

If you run a website, you have probably debated on whether or not you need to make the switch to HTTPS instead of using HTTP. For those that still don’t know, HTTPS is the encrypted version of HTTP. This is typically seen on banking sites, touted to protect your sensitive information when transmitted between you (your browser) and the application.

I wrote on this topic about a year ago in the post: Is HTTP being left behind for HTTPS? Back then there was a big push for making the switch and since we have seen even government mandates for government operated sites to make the switch to HTTPS.

There are typically two reasons you will hear someone recommend using HTTPS:

  • SEO (search engine optimization) – To learn more about these benefits, check out this great article Should you switch your site to HTTPS? Here’s Why you should or shouldn’t by Neil Patel. Neil does a great job of explaining HTTPS and the pros and cons.
  • Protecting sensitive information – We all should know by now that we need to protect sensitive information as it is transmitted to the application. So if your application transmits any sensitive information (Passwords, Social Security Number, Credit Card Info, Account information, etc) it is a must to use SSL.

But Wait…What about…

There is another big reason that HTTPS is important, even if you do not have sensitive information on your site. Let’s step into our favorite scenario of using your computer in the local coffee shop. You connect to the free wifi and start surfing to your favorite sites. You feel comfortable logging into your bank account because it uses HTTPS and you see the green lock in your browser (although maybe you shouldn’t feel so comfortable). Ideally, that session with your bank is protected from the guy sitting one table over trying to intercept the traffic.

Then you point your browser to a local news site to check out the latest happenings. That site is over HTTP and is not protected while traversing the wifi network. What happens when the attacker is able to intercept that news traffic and he changes the response, that you expect to contain today’s news, to contain malicious content. This would be no different than you clicking on a malicious site to begin with. Except here, you feel safe on that familiar news site.

This scenario shows how your site, the one running without HTTPS, could be used as a launching point to attack a user. While it didn’t effect your actual site, or your servers, it will lead to a break in trust from your visitors. If something happens while on your site, it doesn’t matter how it happened, the finger is pointing straight at you.

Conclusion

So while we put a lot of focus on sensitive information or SEO, there are other very important reasons why a site owner would want to make the switch to HTTPS. Gone are the days when performance is an excuse. Heck, with the Let’s Encrypt project, maybe gone are the days of the cost of purchasing a certificate to enable HTTPS. Sure there may be reasons, even some valid ones, why you don’t need to make the switch. Don’t just look at the constraints. Take the time to really understand your situation, how the change effects you, and make rational decisions. Don’t do it because some site said too. Do it because you understand the situation and know it is right for your situation.

When One Testing Solution Isn’t Enough

Go to any conference, attend some webinars, or just do a search for application security testing solutions and you can quickly see the sheer number of solutions out there. As in every situation, there are some that are great and some that are not so great. With such great marketing, it is often very difficult to determine what is the best solution. All too often people are looking for that silver bullet. That one testing tool or pen testing company that will find everything. Unfortunately, that solution doesn’t exist, or I just haven’t seen it.

Application testing usually falls into two categories: Automated scanning and manual assessments. To break that down further, automated scanning is broken down into two disciplines: Static and dynamic.

Static Analysis

Static scanning means that code is scanned without running it. Here is a quick post about static analyzers. Inputs are traced through the code to see what paths are taken and determine vulnerabilities. Static scans can be efficient at finding flaws such as cross-site scripting, injection flaws, configuration issues, etc. Static scans excel at finding code issues like hard coded passwords, cryptography issues, and other items not possible through a dynamic or manual test. They still do not do very well at finding business logic flaws which can be the most devastating.

Dynamic Analysis

Dynamic scanning means that the application is scanned as it is running. Unlike a static scan, it can be very difficult to identify hard coded passwords or cryptographic issues because they are not visible to the end user. Dynamic scans do a decent job of identifying other flaws such as cross-site scripting, injection flaws, insecure cookies, and some other configuration issues to name a few. Dynamic scanners do not do a good job identifying authentication, authorization, or business logic flaws in general. Properly tuned scanners may be able to do this, but that requires extra work.

Manual Assessments

Manual assessments are mostly a manual process of analyzing source code or using the application to find security flaws. Source code review, has many advantages of the static scanning mentioned above. Penetration testing is very similar to the dynamic scanning mentioned. In both cases, the testing is done manually vs. using just an automated tool. Manual assessments (pen tests) are much more efficient at finding authentication, authorization and business logic flaw types. Of course the quality of the assessment is heavily influenced by the skill of the person doing the assessment.

Some of the big vendors have started offering all three types of assessment for their customers. The big players (White Hat Security, VeraCode, HP, etc.) all offer static, dynamic and manual assessments for your applications. And with good reason. If you have worked in an enterprise where you are required to have multiple assessments by different groups you quickly realize how nothing provides a complete solution. Each assessment paints a portion of the security picture. Items found by one may not be found by the other. In some instances you may think that two should have found the same item, but that is the nature of security.. No one finds everything.

Multiple Solutions

While you may think that it is overkill to have multiple scanning solutions or testers looking at an application, they all bring a different viewpoint and help identify different types of vulnerabilities. Sort of like an enhanced second pair of eyes. Not only can they double check the work the other has done, but in may situations they can identify different types of vulnerabilities. Not only do different solutions find different vulnerabilities, they also find them at different phases of the development lifecycle. It is common to use the static scanners in the development phase. Dynamic scanners are more commonly seen in the verification phase. Manual assessments, especially 3rd party penetration testers, are also in the verification phase, but near the end of the cycle. The closer to development a flaw is found, the quicker it is to remediate it.

The right solution is the one that fits your environment. Take the time to analyze your setup to determine the best way to implement a solution. These solutions take time and should be carefully considered.

Introduction to Penetration Testing for Application Teams

In this presentation, James Jardine focuses on educating application teams on what a penetration test is and how to extract the most value from it. Application teams learn how to participate in the engagement and better understand the report.

You can watch the recorded session at any time at: https://youtu.be/I1PukF8Glh0