Jardine Software

  • Home
  • Solutions
    • Vulnerability Assessments / Penetration Tests
    • Security Review
    • Code Review
    • Training
      • Fundamentals of Application Security
  • Testimonials
  • Resources
  • Blog
    • .Net Blog
  • About
    • Events
  • DevelopSec

June 3, 2018 by James Jardine

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.

Filed Under: Uncategorized Tagged With: app sec, application program, application security, application security program, appsec, consulting, developer, developer awareness, development, hacking, hiring, pen test, pen testing, penetration testing, qa, quality, quality assurance, ransomware, secure code, secure program, security testing, security training, testing, vulnerability, vulnerability assessment, vulnerability disclosure

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.

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.

Filed Under: Uncategorized Tagged With: app sec, application security, appsec, awareness, developer, developer awareness, developer training, inventory, security, security training, testing

March 22, 2016 by James Jardine

Webcast: Introduction to Penetration Testing for Application Teams

In most organizations it is the security team that initiates and manages the penetration tests. The application teams are called upon to ensure that an environment is available, credentials are created, and to remedy any findings in the report. Many application teams don’t even get the full report, rather just a listing of the findings. This listing often doesn’t include the needed details.

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

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.

Filed Under: Uncategorized Tagged With: app sec, application security, appsec, developer, developer awareness, pen testing, penetration testing, secure development, security, security testing, vulnerability, vulnerability assessment

Newsletter

Sign up to receive email updates regarding current application security topics.

Privacy Policy

Contact Us

Contact us today to see how we can help.
Contact Us

Search

Company Profile

Jardine Software Inc. was founded in 2002. Originally focused on software development, we now focus on helping development teams and … Read More...

Resources

Podcasts
DevelopSec
Down the Security Rabbithole (#DTSR)

Blogs
DevelopSec
Jardine Software

Engage With Us

  • Email
  • Facebook
  • GitHub
  • LinkedIn
  • RSS
  • Twitter
  • YouTube

Contact Us

Jardine Software Inc.
Email: james@jardinesoftware.com



Privacy Policy

© Copyright 2018 Jardine Software Inc. · All Rights Reserved