secure development

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?

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?

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.

James Jardine is the CEO and Principal Consultant at Jardine Software Inc. He has over 15 years of combined development and security experience. If you are interested in learning more about Jardine Software, you can reach him at james@jardinesoftware.com or @jardinesoftware on twitter.

November 22, 2016 by James Jardine

5 mistakes to avoid to hire qualified application security talent

Hiring for application security positions is often seen as almost impossible. With many claims of talent shortages and so many open positions, finding the right candidate can be a daunting task. Here are 5 common mistakes to avoid and how to get past them.

Not understanding your current needs

If you are thinking about bringing on an additional resource focused on application security, you must understand what the duties will be. Unfortunately, due to the constant pressure to be secure, many companies focus on having the resources and then trying to determine what they will be expected to do. While this may be the case for the initial hire of a brand new application security program, it shouldn’t be the norm.

Understanding your needs requires work. It requires understanding what your immediate priorities are vs. the long term goals. While both of these may play into the candidates skill sets, focusing on the immediate may result in a quicker hire. There are many different tasks that an application security professional may perform. For example, working with static or dynamic analysis tools, or helping with threat modeling. They may also be creating automation around identifying security issues within the organization’s environment. You have to ask yourself, which of these are the current priority. Your organization may implement static analysis this year, but have dynamic analysis scheduled out a year. Maybe manual testing (red teaming) is a nice to have, but you know you won’t have time to build up that program for a few months.

Ignoring existing resources

Once you have a good understanding of what your needs are, it is time to look at existing resources. The common mistake is to just look at the security team. Instead, look at the application teams as well. What type of resources and skill sets exist within the organization. Business analysts are great at digging into understanding problems and gathering requirements. Developers know development and are typically great problem solvers. QA testers know how to test applications. Project managers know how to efficiently schedule tasks to get the project to its expected milestones.

All of theses resources, none of which are dedicated to security, provide a wealth of experience that can be applied to security. Let’s be honest, application security should be a part of each of these roles if we expect it to be successful.

Not sharing the workload

Just because it says application security doesn’t mean everything has to be handled or executed by the application security team. Many of the application security programs can be spread across multiple teams. For example, dynamic analysis could be integrated into the QA team’s responsibilities. The team already performs testing against the application, it makes sense to put dynamic testing within this context. Shifting the ownership to the correct location adds many benefits. First, it allows the application security team to focus on more specialized tasks. If using on-premise static analysis, this may include writing custom rulesets vs. just executing the tool and reformatting the results. It also helps embed security into the SDLC. The verification phase will now not only test for the common bugs, but also for the security bugs. In addition, the bugs will all be tracked using the same process, requiring less implementation effort.

There are many application security tasks that can be integrated into the existing SDLC processes. This will typically require engagement from the application security team to help guide the creation of these processes. That may be, however, what defines the role you are trying to fill.

Not defining the role

Once you have a good understanding of your needs and what still falls within the application security team’s responsibility, you can start to define the role you see. This process still relies heavily on understanding your needs, filtering out what is covered by current resources. Depending on the size of your organization and your application security team, the role may be very broad or very specific. It is this definition, however, that will drive the job requirements that get shared to human resources.

Overly broad job requirements

Getting candidates interested in the open position is critical to getting their attention. Being specific about what you are really looking for helps reduce noise and attract more relevant candidates. Often times job requirements are very broad and cover every possible task that may be performed. How often do those tasks actually get performed once someone is brought in? Some of them may never get executed.

Having too broad of requirements may cause great people to pass on by, thinking they don’t have all the skill sets needed. On the other hand, people may apply because they have one of those skill sets and it never gets used once they are hired.

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

November 21, 2016 by James Jardine

SSL Labs Grading Changes and HSTS

Qualys recently posted about some grading changes coming to SSL Labs in 2017. If you are not aware of SSL Labs, it is a service to check your SSL/TLS implementation for your web applications to determine how secure they are. While there were more changes listed, you can read about them in the link above, I wanted to focus on the one regarding HTTP Strict Transport Security (HSTS).

If you haven’t heard of HSTS, or want a quick refresher, you can check out this post: HTTP Strict Transport Security (HSTS): Overview.

According to Qualys, the changes regarding HSTS will not be implemented until later in 2017, not with the initial set of changes. However, this early notification may help some companies make preparations for the change. Here is what they say about HSTS grading changes:

HSTS Preloading required for A+
HSTS required for A

Some organizations have specific requirements to the grade they expect to receive on the SSL Labs report. If an A is your target, HSTS is going to be a critical component for that. Even if it is not, this change is a clear indication that HSTS does not look like it is going away.

HSTS is a great way to help increase the security of your transmission from browser to server. However, it may not be something that can just be turned on. We have seen many sites have difficulty going to 100% HTTPS, and HSTS doesn’t play well with mixed content. It also doesn’t play well with self-signed certificates. While these are important for the increased security it provides, this is where the difficulty may come in.

If you are not using HSTS currently, now may be the time to start thinking about it. Creating the header is typically not very difficult. Testing to make sure nothing breaks because of it can be a bit more tedious. Want to know more about HSTS or application security?

Overview of Web Security Policies

New Year’s Resolutions

Vulnerability disclosure doesn’t require a bug bounty

5 mistakes to avoid to hire qualified application security talent

SSL Labs Grading Changes and HSTS

Company Profile

Resources

Contact Us

Company Profile

Resources

Engage With Us

Contact Us