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 26, 2018 by James Jardine

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.jardinesoftware.com/jamesjardine-public.txt

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

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

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

# Signature - To help secure your file, create a signature file and reference it here.
Signature: https://www.jardinesoftware.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?

Filed Under: Uncategorized Tagged With: application security, developer, researcher, secure development, secure software, secure testing, security research, security training, security.txt, white hat

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 10, 2018 by James Jardine

New Training Course – Fundamentals of Application Security

We are excited to announce the availability of our Fundamentals of Application Security course for application development teams. If you are a business analyst, developer, QA tester, or any other role involved with creating applications, this course is for you. Understanding why application security is important and how it can be built into our everyday processes will help create more secure applications going forward.

The goal of this course is to introduce the basic concepts of some of the more common application vulnerabilities. Through the use of lecture and live demonstrations, attendees will understand what vulnerabilities are, how they create risk, and how they can start to build applications that are better protected from common security weaknesses.

To facilitate a better learning environment, the course is taught in 1.5 hour sessions across a 6 week period one day a week. We are offering 2 different schedules, both on Tuesdays. One is at noon EST and the other is at 7:30PM EST. The sessions are taught live, through the GoToTraining platform allowing for real time conversations. In addition, each session is recorded and will be available to enrolled students in the event they have to miss a session or just want to re-watch it later.

The course starts May 1, 2018, so don’t wait to sign up.

For more information about course details and pricing go to https://www.jardinesoftware.com/fundamentals-of-application-security/

Filed Under: Uncategorized

January 3, 2018 by James Jardine

New Year’s Resolutions

Here we are, the start of another year. As we reflect on 2017, this is where we really start to focus on what lies ahead in 2018. The new year is always interesting because it usually doesn’t affect our build cycles or releases. With the exception of accounting for vacations. Yet, this is the time of year where many people get re-focused and motivated to change old habits or try something new.

As I look back on 2017, there were a lot of news headlines that focused around security. So many of them highlighting breaches, many termed “mega” breaches. The trend of hyped up headlines glorifying monster breaches will likely continue through 2018 and beyond. We know that breaches can, or will, happen. We have seen examples of different techniques used to gain unauthorized access to data. This won’t change, and will most likely become more prevalent going forward. The amount of information available to potential attackers is enormous, making our job of application security that much more important.

One of the biggest lessons to take away from 2017 is that privacy is important. In addition, private data is not limited to PCI or HIPAA. All sorts of data can be considered private and require the custodian to take proper steps to protect it. It doesn’t matter if the data is held by a Fortune 500 company or a one-person shop. To someone, that data is worth something. As we look into 2018, this reminds us that we must understand what data we have. We must know what type of regulations it may fall under, what applications contain it, and how we are protecting it. Just because data may not fall under a regulation doesn’t mean it should be overlooked. In the end, it is the expectation of our customers and clients that we will handle their data responsibly.

Protecting this data is not about how much money you spend or what tools you buy. Every organization is different. Every application development team is different. I encourage everyone to take the time to research and understand what your team needs to be successful. As in the past, throughout the year I will be posting thoughts on different application security topics. If you have any questions or topics, feel free to share them with me. Looking for someone to talk to about application security? Reach out. I have services available to help organizations and individuals reach new heights and solve problems.

What are your New Year’s Resolutions when it comes to application security?

Filed Under: Uncategorized Tagged With: application, application security, appsec, data, development, pen testing, penetration testing, privacy, qa, qc, quality, secure development, security, testing

March 7, 2017 by James Jardine

Vulnerability disclosure doesn’t require a bug bounty

Software is moving at a rapid pace. Even with secure coding training, a secure SDLC, and third party penetration testing, vulnerabilities still exist. Fortunately, there are many people that are happy and willing to notify you of these issues if they find them.

When we talk about external resources finding vulnerabilities on their own, we often think of bug bounties. Companies offer a bug bounty to compensate people who have identified a bug, submitted it, and followed other rules defined around the program.

A bug bounty is not the only option to provide a means for these users to provide vulnerability information. The process of disclosing these vulnerabilities is known as vulnerability disclosure. I spoke about this on the DevelopSec podcast linked below:

People often get confused between bug bounties and vulnerability disclosure. They often consider the two to be one in the same. But they are actually different. A vulnerability disclosure process should be implemented by every organization. It is the process someone would use to report a vulnerability to the organization, ensuring it makes it to the right people. There are too many instances where a vulnerability may be reported, but it gets lost in the help desk system. This happens because the identifier doesn’t have any clear path to submit the flaw. Left to their own choice, they may attempt emailing, tweeting, Facebook, or the contact us page on the website. Unfortunately, many of these methods are not monitored by the security group and the people that are monitoring them don’t have a defined process to pass the information along.

A bug bounty program is not meant for every organization, nor is every organization ready to implement one. The bug bounty program builds upon vulnerability disclosure by adding a form of compensation. The compensation can range from kudos (or a thank you) to monetary rewards. Bug bounties provide an incentive for people to proactively look for vulnerabilities within your application. Bug bounties come with their own special considerations, which are covered in other posts. If you would like to discuss more about them, contact us.

Creating a clear path of communication and clear set of expectations helps reduce the chance of a vulnerability falling through the cracks. It does mean that each vulnerability will go through an analysis process to determine the risk it exposes to the organization and its clients and the priority level. Make sure that your organization has a clear vulnerability disclosure policy and it the method to report is easy to identify.

Remember, creating a vulnerability disclosure policy doesn’t require a bug bounty. It doesn’t need to promote the testing of your applications for security vulnerabilities. It does provide a means for someone that does identify something to share that with you to help resolve it.

Jardine Software helps companies get more value from their application security programs. Let’s talk about how we can help you.

Contact us to discuss more

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: application security, application security program, disclosure, secure development, security testing, vulnerability, vulnerability disclosure

  • 1
  • 2
  • 3
  • …
  • 5
  • Next Page »

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