DevelopSec

security training

by

Investing in People for Better Application Security

Application security, like any facet of security, is a complex challenge with a mountain of solutions. Of course, no one solution is complete. Even throwing multiple solutions will never get 100% coverage.

The push today is around devsecops, or pushing left in the SDLC. I am seeing more solutions recommending also pushing right in the SDLC. I feel like we are stuck at this crossroad where the arrow points both ways.

The good news is that none of these recommendations are wrong. We do need to push left in the SDLC. The sooner we address issues, the better off we are. The idea that if we don’t introduce a vulnerability in the first place is the best case scenario. Unfortunately, we also know that is an unrealistic assumption. So this brings us to pushing right. Here, we are looking to quickly identify issues after they are introduced and, in some cases, actively block attacks. Of course, let’s not leave out that automation is our key to scalable solutions as we build and deploy our applications.

Much of what we focus on is bringing in some form of tool. Tools are great. They take they mundane, repetitive work off of our plate. Unfortunately, they can’t do it all. In fact, many tools need someone that has at least some knowledge of the subject. This is where the people come in.

Over the years, I have worked with many companies as both a developer and an application security expert. I have seen many organizations that put a lot of effort into building an application security team, focused on managing everything application security. Often times, this team is separate from the application development teams. This can create a lot of friction. With the main focus on the application security team, many organizations don’t put as much effort into the actual application development teams.

How does your organization prepare developers, business analysts, project managers and software testers to create secure applications?

In my experience, the following are some common responses. Please feel free to share with me your answers.

  • The organization provides computer based training (CBT) modules for the development teams to watch.
  • The organization sends a few developers to a conference or specialized training course and expects them to brief everyone when they return.
  • The organization brings in an instructor to give an in-house 2-3 day trading class on secure development (once a year).
  • The organization uses its security personnel to provide secure development training to the developers.
  • The organization provides SAST or DAST tools, but the results are reviewed by the security team.
  • The organization has updated the SDLC to included security checkpoints, but no training is provided to the development teams.
  • The organization doesn’t provide any training on security for the development teams.

By no means is this an exhaustive list, but just some of the more common scenarios I have seen. To be fair, many of these responses have a varying range of success across organizations. We will look at some of the pitfalls too many of these approaches in future articles.

The most important point I want to make is that the development teams are the closest you can get to the actual building of the application. The business analysts are helping flush out requirements and design. The developers are writing the actual code, dealing with different languages and frameworks. The QA team, or software testers, are on the front line of testing the application to ensure that it works as expected. These groups know the application inside and out. To help them understand the types of risk they face and techniques to avoid them is crucial to any secure application development program.

My goal is not, let me repeat, NOT, to turn your application development teams into “security” people. I see this concept floating around on social media and I am not a fan. Why? First and foremost, each of you have your own identity, your own role. If you are a developer, you are a developer, not a security person. If you are a software tester, don’t try to be a security person. In these roles, you have a primary role and security is a part of that. It is not the defining attribute of your tasks.

Instead, the goal is to make you aware of how security fits into your role. As a software tester, the historical goals focused on ensuring that the application functions as expected. Looking at validating use cases. When we start to think about security within our role, we start to look at abuse cases. There becomes a desire to ensure that the application doesn’t act in certain ways. Sometimes this is very easy and others it may be beyond our capabilities.

Take the software tester again. The goal is not to turn you into a penetration tester. That role requires much more in-depth knowledge, and honestly, should be reserved for looking for the most complex vulnerabilities. This doesn’t mean that you can’t do simple tests for Direct Object Reference by changing a simple ID in the URL. It doesn’t mean that you don’t understand how to do some simple checks for SQL Injection or Cross-site Scripting. It does mean you should be able to understand what the common vulnerabilities are and how to do some simple tests for them.

If you invest in your people correctly, you will start to realize how quickly application security becomes more manageable. It becomes more scalable. The challenge becomes how to efficiently train your people to provide the right information at the right time. What type of support are you looking for? Is it the simple CBT program, or do you desire something more fluid and ongoing that provides continuing support for your most valuable assets?

Different programs work for different organizations. In all cases, it is important to work with your teams to identify what solution works best for them. Providing the right type of training, mentorship, or support at the right time can make a huge impact.

Don’t just buy a training solution, look for a partner in your development teams training efforts. A partner that gets to know your situation, that is available at the right times, and builds an on-going relationship with the team.

by Leave a Comment

Apple Mail: Highlighting External Email Addresses

A simple error to make when sending an email with sensitive data is to send it to the wrong email address. Imagine you are sending some information to Dave down in accounting. When you fill out the email you start typing Dave and the auto-complete pops up and you select the first one (out of habit). You think you have selected the right Dave, but what if you didn’t? How would you know that you were about to send potentially sensitive information outside of the organization?

Apple Mail and iOS mail has a built in feature to highlight any email address outside of a specified domain. The steps to enable this are a little different based on the desktop vs. an iPad/iPhone. Let’s look at each one.

Desktop

By default, email addresses all appear the same when composing a new message. The image below shows me composing an email with two addresses:

  • To: james@jardinesoftware.com
  • CC: james@developsec.com

Mail 1

To change this, in the Mail program, go to Preferences…Composing. Under the Addressing: section there is a checkbox for “Mark addresses not ending with“. Check the box and enter your organization’s domain name in the text box. In the image below, I have entered my domain of @jardinesoftware.com.

Mail 2

Now, go back and compose a new message entering in an email address that is in the org and one that is out of it. The email address that is outside of your domain should be highlighted in red. The below image shows my configuration with the same 2 email addresses. Notice that the james@developsec.com address is now listed in red indicating it is external to my organization.

Mail 3

iPhone/iPad

The mail application with the iPhone/iPad also has this capability. To enable this, go into Settings->Mail. Scroll down to the Composing section and click the “Mark Addresses” button (shown below).

Mail 4

On the next screen, enter the email address you don’t want to highlight. In my case, I entered my domain of @jardinesoftware.com. (shown below)

Mail 5

Once the change is stored, go to mail and compose a new message. In my example, I used the same emails as above. Notice that the james@developsec.com email address is now highlighted in red:

Mail 6

Although this is not a fool proof way to stop this type of mistake, it does add in a visual clue that just might catch your attention. Simple changes like this can help reduce your risk of accidentally leaking sensitive information out of your organization.

by Leave a Comment

Thinking about starting a bug bounty? Do this first.

Application security has become an important topic within our organizations. We have come to understand that the data that we deem sensitive and critical to our business is made available through these applications. With breaches happening all the time, it is critical to take reasonable steps to help protect that data by ensuring that our applications are implementing strong controls.

Over the years, testing has been the main avenue for “implementing” security into applications. We have seen a shift to the left more recently, leading to doing more throughout the entire development cycle, but we still have a ways to go. I am still a firm believer in embedding security into each of the phases as our main means of securing applications. Testing, however, is still a major component of any security program.

Typically, organizations rely on penetration testing to find the flaws in their applications. This is the de facto standard for understanding your risk. Unfortunately, penetration testing for applications has been watered down from what we think about with network testing. Many of the assessments we call penetration tests these days are just automated scans transposed into a custom report. These types of testing overlook one of the components a penetration test provides, which is the manual testing. Of course, there is much more to a penetration test, but that is not the focus of this post.

Internally, organizations may implement automated tools to help identify security flaws within their applications. These tools are good at finding certain types of flaws, and usually quite quickly. Like many current penetration tests, they lack the manual assessment side.

Not only does manual testing have the ability to find different types of flaws, such as authentication, authorization, CSRF, business logic, etc., it also has the ability to identify flaws that an automation tool overlooks. For example, a tool may not find every instance of cross-site scripting, depending on how that tool analyzes the system. Granted, manual testing is not guaranteed to find every instance either. With each type of testing, there is always a number of issues that will not be identified. The goal is to start reducing these numbers down over time.

Handling the results of all these res ports from the different assessments is critical to how well you start creating more resilient applications. In many organizations, vulnerabilities identified are handled as individual items and patched. In my opinion, the return on investment is when you can analyze these results to review your development process and see what improvements can be made to reduce the chance these types of flaws will be included in the future. Having an expert available to help review the issues and provide insight into how to use that information to improve your process is valuable.

Having a solid application development process in place is important before thinking about implementing a bug bounty program within your organization. If you are not already doing things consistently, there is a better chance the bounty program will fail.

Bug bounty programs have been becoming more prevalent over the last few years. This is especially true for newer technical startups. We have seen much slower adoption with most of the major corporations. There are many reasons for this, which are outside the scope of this post. There have been questions on whether bug bounties can replace penetration testing. The answer is no, because the goal of each of these is different. There are plenty of articles discussing the subject. A bug bounty program has also been seen by many as the evidence to show they are doing application security. Unfortunately, we can’t test ourselves secure. As I stated previously, testing is just a part of our solution for application security.

A key difference between our traditional testing and a bug bounty program is that bug bounties pay by the bug. Our traditional testing is provided at flat fees. For example, that automated tool is a set price for a month or year subscription. A penetration test is a set price per test. A bug bounty is priced per bug, which makes the cost very unpredictable. In addition, if you are not already doing many of the things previously discussed, there could be a lot of bugs to be found, leading to potentially high payouts.

As I have stated before, penetration testing has a different purpose and it can be very expensive. At Jardine Software we offer more budget friendly manual application security testing at a fixed cost. The goal is not necessarily to find every instance of every vulnerability or to exploit vulnerabilities in the way a penetration test would. The focus is on augmenting the automated testing you may already have in place and to provide that missing manual piece. The testing is performed manually by using the application in combination with Burp Suite, to look for weaknesses and provide those in a way that helps prioritize and then remediate them according to your organization’s needs.

The manual application security testing is typically performed over a week to two weeks and includes a broader scope than a typical bug bounty program. The reason for this is that we want to help identify risks that we see based on our years of experience to make you aware. This assessment can then help identify where you may have issues within your application before opening it up for a crowd sourced bounty program where each bug is priced individually.

If you are thinking about implementing a bug bounty program, reach out and lets chat first. Even if you are not considering a bug bounty program, do you have any manual application security testing implemented? We have the expertise to help provide the necessary testing or provide training for your internal teams to start applying manual testing techniques as part of your life cycle.

by Leave a Comment

Overview of Web Security Policies

A vulnerability was just identified in your website. How would you know?

The process of vulnerability disclosure to an organization is often very difficult to identify. Whether you are offering any type of bounty for security bugs or not, it is important that there is a clear path for someone to notify you of a potential concern.

Unfortunately, the process is different on every application and it can be very difficult to find it. For someone that is just trying to help out, it can be very frustrating as well. Some websites may have a separate security page with contact information. Other sites may just have a security email address on the contact us page. Many sites don’t have any clear indication of how to report such a finding. Maybe we could just use the security@ email address for the organization, but do they have it configured?

In an effort to help standardize how to find this information, there is a draft definition for a method for web security policies. You can read the draft at https://tools.ietf.org/html/draft-foudil-securitytxt-03. The goal of this is to specify a text file in a known path to provide contact information for users to submit potential security concerns.

How it works

The first step is to create a security.txt file to describe your web security policy. This file should be found in the .well-known directory (according to the specifications). This would make your text file found at /.well-known/security.txt. In some circumstances, it may also be found at just /security.txt.

The purpose of pinning down the name of the file and where it should be located is to limit the searching process. If someone finds an issue, they know where to go to find the right contact information or process.

The next step is to put the relevant information into the security.txt file. The draft documentation covers this in depth, but I want to give a quick example of what this may look like:

Security.txt

— Start of File —

# This is a sample security.txt file
contact: mailto:james@developsec.com
contact: tel:+1-904-638-5431

# Encryption - This links to my public PGP Key
Encryption: https://www.developsec.com/jamesjardine-public.txt

# Policy - Links to a policy page outlining what you are looking for
Policy: https://www.developsec.com/security-policy

# Acknowledgments - If you have a page that acknowledges users that have submitted a valid bug
Acknowledgments: https://www.developsec.com/acknowledgments

# Hiring - if you offer security related jobs, put the link to that page here
Hiring: https://www.developsec.com/jobs

# Signature - To help secure your file, create a signature file and reference it here.
Signature: https://www.developsec.com/.well-known/security.txt.sig

—- End of File —

I included some comments in that sample above to show what each item is for. A key point is that very little policy information is actually included in the file, rather it is linked as a reference. For example, the PGP key is not actually embedded in the file, but instead the link to the key is referenced.

The goal of the file is to be in a well defined location and provide references to your different security policies and procedures.

WHAT DO YOU THINK?

So I am curious, what do you think about this technique? While it is still in draft status, it is an interesting concept. It allows providing a known path for organizations to follow to provide this type of information.

I don’t believe it is a requirement to create bug bounty programs, or even promote the security testing of your site without permission. However, it does at least provide a means to share your requests and provide information to someone that does find a flaw and wants to share that information with you.

Will we see this move forward, or do you think it will not catch on? If it is a good idea, what is the best way to raise the awareness of it?

by Leave a Comment

Choosing Application Security Tools

There are lots of security tools available, so how do you know which one to pick?

If your security team is not including the application teams in the decision, you run a big risk of failure. The security team does get the ability to form relationships with vendors. We see them at conferences. We know people that work there. Because our focus is on security, we know the tools that exist in our space and we have an idea of which ones may be better than others. Of course, this is often due to what we hear from others, rather than our own experience with those tools.

Picking a tool in a vacuum is less than ideal. Sure, the tool may have five stars and has great detection rates. However, if the tool doesn’t fit into the development process and causes more overhead and friction, it will end up failing. A tool with 100% accuracy is still useless if it is not actually being used.

I have seen over and over where a security group acquires a tool, especially static analysis, and a few months later they realize it is just sitting on the shelf. Like all of us, we are excited when we get a new toy. We use it, learn it. Then, the newness wears off. Without the proper processes in place, this can happen with security tools as well. We don’t want this to happen to you.

The first step in determining which tools make sense is to understand the development process now and where it is going. Lets talk about static analysis for a moment. If your development process doesn’t make use of continuous integration and doesn’t plan to then that is not a high priority feature of the tool you receive. Have you considered what IDE the developers use?

I once had a situation where static analysis was about to be rolled out. The security team worked to pick a vendor and get the ball rolling. It was later in the process that the development team was brought on board with the conversation. They asked questions that were less of a priority to the security team, but more of a priority to them. For example, The tool provided a plugin for their IDE. However, when digging deeper, the plugin ran a few versions behind. So what had appeared to be a good setup, now looked a little less efficient since the plugin may not work. This isn’t a deal breaker, but depending on how you were planning on this solution working, it adds friction to the process. The more friction, the more pain.

The next step is understanding who will ultimately be using this tool? For those that listen to the podcast on a regular basis and follow my blogs, you know I am a huge fan of the application teams having direct access to these tools. In my opinion, static analysis is a developers tool. It is there to evaluate the source code and identify policy violations that only the developer can resolve. Giving them access and control over that function and embedding it into their process reduces that friction. Don’t confuse this with the idea that security is not getting the results. Security still needs to have insight into what is going on with security flaws within the application. But to be efficient, the results of these tools need to fit into the flow of how development works. Not be one-off reports under different processes.

This is no different, in my opinion, than dynamic analysis or interactive analysis. These are tools that should be used by the QA group. The group that is responsible for testing and most likely already has automated testing capabilities. They are trained in identifying bugs, reporting, and tracking them. Building these types of tools into their process just makes sense. How many listeners have their own stories of the security team exporting a thousand page report out of that dynamic scanner and sending it to the application team as a pdf? I have been there. Even I won’t read through that report.

The moral of the story here is that if we don’t understand how development works, what type of tools they already use, and what they can handle, we will probably pick a solution that will be ineffective, or at the very least, cause us a lot more work. The goal is not to just shove tools onto the development teams and say do this. As application security representatives, our goal is to help build better applications. That doesn’t mean that our job is to run all the tools and hound the application teams to fix items. By understanding the environments and processes we can pick tools that will fit much better, allowing us to focus our time on building out other solutions or processes for the organization. We are still relied upon to provide the expert advice and guidance to the issues that are identified.

If you are considering implementing these types of tools, take a moment to sit down with all involved parties to get everyone on board. A well laid out plan will go much further than a shotgun approach.

by Leave a Comment

OWASP 2017 Changes

When I talk to people about application security, the most recognized topics is the OWASP Top 10. If you haven’t heard of the top 10, or need a refresher, you can get the full list at:

https://www.owasp.org/images/7/72/OWASP_Top_10-2017_%28en%29.pdf.pdf

The OWASP Top 10 is on a three year update cycle. We had the list in 2010, 2013 and now the latest is 2017. You may be wondering why it is 2017 rather than 2016. I think that is a question a lot of people had. In any case, the list made it out to final release after the initial draft was rejected. Now that it is here, we can analyze it and see how it affects us and our organizations.

https://www.youtube.com/watch?v=kfDuxwFScOE

What I think sticks out more to me this update over previous updates is the removal of some pretty common flaws based on my experience. In the past we have seen flaws move up or down on the risk level, or get combined, but not as much removed. In 2017, we saw two items get removed:

  • Cross-site Request Forgery
  • Unvalidated Redirects and Forwards

I find these items interesting because I see them on most of the assessments I do. Let’s take a quick look at them.

Cross-site Request Forgery

CSRF can be a pretty serious flaw based on its context. It is the ability to force the victim’s browser to make requests to another site they are authenticated too without their knowledge. An example of a higher-risk context is the ability to change the victim’s email address on their profile. If the system doesn’t have two factor authentication or other safe guards, changing the email address can lead to the ability to request a password reset. In many situations, this can lead to easily taking over the victim’s account.
This is just one example of how CSRF can be used. The good news is that many newer frameworks provide some level of CSRF protection built-in. So in many applications it is not as prevalent. However, based on my experience, not everyone is using the latest frameworks. Due to this, I still find this on a lot of the assessments I do.

Unvalidated Redirects and Forwards

Unvalidated Redirects is often viewed as a low risk issue. In many cases, it may represent a low risk. There are some situations that make unvalidated redirects fairly dangerous. A good example is the redirect often performed by login forms. A common feature of many applications is to redirect the user to a specific resource after logging in. To do this, a parameter in the URL specifies the path to be sent to. If the application allows redirecting to external sites, it is simple to set up a malicious site with the same look and feel as the expected site. If the victim uses your link with the reference to your malicious site they may be presented with your fake login page after successfully logging into the real site. The victim may believe they have mistyped their password and just login again without checking the URL, leading to account takeover.

We also saw to access control findings get merged into one. This change makes a lot of sense when you look at each item. They are both regarding access control issues.

With the removal and merging, the list has brought on three new vulnerabilities:

  • XML External Entities (XXE)
  • Insecure Deserialization
  • Insufficient Logging and Monitoring

XML External Entities (XXE)

XML External Entities is a vulnerability that takes advantage of how XML Parsers interpret the supplied XML. In this case, it is possible to reference other resources outside of the XML document. A common scenario is the ability to read other files on the web server, such as the /etc/passwd file. This vulnerability also may allow a denial of service attack to occur due to embedding specific entities. This vulnerability obviously relies on the application parsing XML data. If your application is parsing XML, it is recommended to make sure the parser is ignoring or blocking DTDs. If your parser doesn’t have that option, or you need to allow some DTDs, make sure your input validation is limiting those to only acceptable ones.

Insecure Deserialization

Insecure Deserialization occurs when you are deserializing data that has not been properly sanitized. This occurs because we assume that the data serialized has not been modified. When the data is modified, it could be executed during the deserialization process to perform commands. To help prevent this, make sure you are enforcing strict data checks on the objects that have been serialized. I do not see this very often in many of the assessments I do. Just depends on the application as many do not use much serialization.

Insufficient Logging and Monitoring

When I talk to people and ask them about logging, the first response, or usually the only response, is related to troubleshooting. There is no doubt that troubleshooting is critical for any application. If the application is not running as expected, users may leave, transactions may get lost, or a myriad of other issues may occur. Logging is for much more than just troubleshooting. Proper logging of security related events can help identify an attack while it is occurring as well as help identify what happened after the fact. It can be very difficult to identify what data was accessed or how if there are no logs indicating such information. It is good that we are seeing more attention called to this practice, although it can be a complex one to implement and verify. Don’t forget that once you start logging security events, they must be monitored to take action.

Wrap Up

Changes to the OWASP Top 10 isn’t something new. We know it will happen and it may require some adjustment to what we are doing internally. While we do see items drop or get added, it just highlights that the top 10 is a mere starting point of security. Every organization should have their list of top 10 risks. Don’t limit yourself to these short lists. They are to help identify the highest risks and implement them in a feasible way. Application security doesn’t happen overnight. There has to be a starting point and then a path to mature.

Listen to the podcast on this topic. http://podcast.developsec.com/developsec-podcast-91-owasp-top-10-2017-thoughts