DevelopSec

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

Does SAST and DAST Really Require Security Experts To Run Them?

There is no argument that automated tools help quickly identify many of the vulnerabilities found in applications today. Tools are typically categorized into one of the following three categories:

  • Dynamic Application Security Testing (DAST) – analyzes the running application.
  • Static Application Security Testing (SAST) – analyzes the source or byte code of the application.
  • Interactive Application Security Testing (IAST) – uses agents installed on the web server to instrument the application and analyze it at runtime. This gives access to both dynamic and static details.

These tools are becoming more popular within organizations as part of their application security programs. While there is still a large gap that can only be filled by manual testing, the automated tools are a good first step.

Are these security tools or development tools?

This depends on what your goal is. Ultimately, they are focused on finding security flaws which make them a “security” tool, however that doesn’t mean it is meant for the security team. I have been presenting for a long time on the idea that many of these tools should be considered development tools and placed in the hands of development and QA. To understand where they fit in your organization, you have to understand how you want to use them.

The application team should be using these tools to help quickly identify security bugs earlier on in the SDLC. To make this work efficiently, this should be considered a development tool. Let’s look at how SAST is used by developers. Developers have the ability to scan their source code using their chosen SAST tool. In many cases, these tools may provide an IDE plugin to make the process easier. As the developer writes their code, they can perform regular scans in smaller increments to quickly identify potential security threats. Once identified, the code can be corrected before it even leaves the development queue. In other instances, SAST is embedded into the continuous integration pipeline and scans can be run on check-in or other predefined activities. The results are immediately available to the development teams to review and make corrections.

The security team should be using these tools differently than the development teams. Security is typically more interested in the risk an application presents to the application. In the use of these tools, they provide valuable information that can be reported on to help analyze that risk. The security team should also be involved in the creation of policies and procedures around the implementation and use of the tools provided.

I thought only security experts can run these tools?

I believe this is a myth that only security experts can run these types of tools. Developers have long had static analysis tools built right into their IDEs, they just didn’t have a focus for security flaws. QA groups use all sorts of automated tools to assist in application testing. Lets take a look at each of the tool categories again.

DAST

Dynamic scanners usually require at minimum three pieces of information to get started: URL, Username, Password. Most of these scanners are either a windows or web application with a GUI. Setting up a scan is usually not to complex and fairly straightforward. I will admit that some applications, depending on how the login works or how routing is configured, can require a more complex setup. Depending on the scanner, you may be able to perform other advanced settings, but these are not difficult to learn.

Once the scan has completed, the results are provided in a GUI as well. The GUI typically provides a simple way to then view each of the findings identified, including the request and response the scanner sent and received. In dynamic scanning, the request and response are helpful in identifying where the issue is in the application. The tool will also usually provide a description of the vulnerability and references to more information. Based on my experience, reviewing findings in the provided GUI is much more efficient than trying to review an exported PDF of the results. A GUI that provides easy navigation is much better received than a 100-200 page PDF report that can’t really be consumed.

Dynamic scanning fits right into the QA process of scanners and can be easily executed by the QA or development team. This is good, because it can be executed against the QA or other pre-prod instances which are owned by the QA and development groups.

SAST

Static scanners analyze your binaries or source code. As expected, they need either the source code itself, or a compiled version of the code. Depending on the tool, you may have to submit the binaries to a service or select them using a local interface. The most difficult part in the process is usually getting the code to compile correctly with debug symbols and components. This compilation is usually done by the development team or DevOps if that has been implemented.

Once the scan is complete, the results are provided either in a web interface or in a local GUI. These results can then be inspected to view details about the issue, just like in the DAST solutions. The big difference being that in SAST you won’t see a request/response, rather you see the file and line of code indicated as well as the source and sink of the vulnerability. The source and sink help trace the data as it passes through the application to the vulnerable line of code. This is useful in helping understand the vulnerability to resolve it. There is a lot of efficiency gained in being able to view these details in a simple manner. The other option is exporting the results to a PDF file which is very inefficient.

Due to the results referencing source code, developers are put into an environment they understand. With some understanding of how security flaws work and are addressed, developers can review the results and take appropriate actions to address them.

IAST

Interactive testing uses an agent on the web server to instrument the application. Basically, it injects code into the application to analyze it as it runs. Due to performance hits, this is a great tool for pre-production environments. It also relies on the code being executed.. basically, if your application is not being used, it won’t analyze the code. This also makes it great for a QA environment or regression testing environment. The setup just requires installing the agent onto the server. The results are displayed, as they are found, in a web interface. These results include the source code and the request/response values. Having direct access to the tool provides an efficient way to view the details to then provide remediations to them.

Review how you use these tools

It has been my experience that more than just security experts can run any of these tools. There may be some tweaking that can be done and requires learning how the tools works, but this is something anyone on the dev or QA teams can adapt to. Take a look at your current program. If you are using any of these tools, look at how you are using them and who has access. Is your current process efficient? Does it make it harder than it needs to be? If you are not using these tools and looking to implement any of them, look at the resources you have and get the development teams involved. Think about where you want these tools to sit and how you want to take advantage of them. They don’t have to be locked down to a security team. Use the resources you have and allow the application teams to take ownership of the tools that will help them create more secure applications.

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.

by Leave a Comment

Tips for Protecting Credit Card Information

Turn on the news and you will see a breach announced for some company. It is happening all the time. In most cases we, as consumers, accept the risk for the convenience of using a credit card for purchases. While there isn’t much you can do to protect your information once you have given it to a business, there are some things you can do to help reduce your risk while shopping online.

Scan for Malware

Most of our online purchases happen from our own computer indicating that this is where we should start our own protections. Over the years we have always told people to make sure you are running anti-virus software, but there are other types of malicious software (called malware) that these programs often don’t detect. Malware is software that is installed on your computer, usually without your knowledge, that has a malicious intent. It may be that it is trying to steal your passwords, credit card information, or other sensitive information. It might be software to spy on you using your computer’s built in microphone or video camera. In any case, it is software that you do not want installed.

There are other programs that you can get to remove this type of malware, above and beyond the use of anti-virus software. A program that I found very useful, that I don’t have any affiliation with, is MalwareBytes (https://www.malwarebytes.org). The greatest benefit is how easy the program is to use (oh and they have a free version). It scans your system for malware and does a really good job of removing it for you. If you have ever tried to remove malware before, it can be pretty difficult. Not with some of these programs like MalwareBytes. If you notice your computer running slow or acting odd it may be a good idea to give it a scan to see if anything comes up.

Be Careful with Emailed Links

Phishing, the art of sending emails with the intent on tricking the user into visiting a malicious site or installing malicious software, is a common way for an attacker to infect your system. All too often we have been told to not open attachments included in an email from someone we don’t know, but this is also true for clicking on links. In many cases, those links do not go to where you are expecting them too. Lets look at a quick example. I have created a simple fake email with some made up business and web site addresses.

BadEmail1

The link in the image above looks normal, however when we take a moment to inspect it more it turns out not to be. To inspect the link, most email clients allow us to hover over it for a moment to see a preview. Hovering means to place your mouse over the link, but don’t click the button. After a few seconds, a balloon should appear to show you what the link actually points to. The following image shows this in action.

BadEmail2

If it is possible, it is recommended to type out the link that is presented or go to the site directly in the browser (if it is a familiar site) rather than clicking on the link. It is understandable that this is not always possible, as some links contain a special discount code or special offer. In these cases, take the time to make sure that the link is going to the site you are expecting. As with any security tip, trust your gut. If something doesn’t seem right, don’t enter any type of personal information with it.

Verify the Site is Using HTTPS

When you are about to use your credit card online, make sure that the web site you are using is using HTTPS. HTTPS means that the information you provide will be encrypted, or protected, as it is sent to the web site. Think of it like using a security envelope vs a regular envelope when sending snail mail. Of course, there are other protections that make it more secure than a security envelope, but that should be a good analogy for most people. There are a few ways to verify this. First, you can look at the address bar in the browser that displays the site name and make sure it starts with “HTTPS”. The next step is to verify that there is a padlock icon near that site address. The image below shows this site and in the top left you will see the padlock icon and https://www.developsec.com. That indicates that the site is using HTTPS and your data will be protected when sent to the business.

DevSec1

You can also verify even further, by clicking on the padlock (in FireFox) the site name matches up with the certificate name. In the below image you will see that the box that appears states I am connected to developsec.com.

devsec2

When Searching, Select the Right Site

If you are using Google or Yahoo, or some other favorite search engine, make sure that the search result you click on is the site you are expecting. With how technology is advancing and the way we have updated how search engines work, there are possibly thousands of results that may come back. Search engines also often put ads as the first few results. Take a moment and ensure that you are going where you think you are going. Don’t just click the first link that is returned.

The following image shows a search for FireFox for Mac. Notice how there is an Ad (which does point to the real FireFox download) and then multiple results. The ones that go to Mozilla.org are valid results that go to the creators of FireFox. Under that are results that don’t go to Mozilla.org. While these sites may be valid downloads of FireFox (I did not try them), you want to try and stay with the creators or the software if possible. Often times software is repackaged by other vendors and that repackaging adds in software you may not want.

ff

Trust Your Gut

Security often times comes down to trusting what your gut tells you. If something seems out of place, then it probably is. If you don’t feel comfortable, then don’t input your sensitive information. Researching the item more can also help make a decision. if you are downloading software, do other searches about it to see if people downloaded malicious versions. If it is from a different site than the vendor, do a search to see if anyone else has flagged that download as bad. Finally, if you notice fraudulent charges, make sure you notify your credit card company as soon as possible.

by Leave a Comment

What is a Penetration Test

You spend all day looking at requirements, creating functionality and doing some testing of the code you just created. You have been working for months on this application making sure it worked as expected. The testers have been diligently working to ensure that the requirements have been fulfilled and the application will work as expected and allow the end users the capability to solve a specific set of tasks. Then it happens… You find out that a penetration test is coming. Unfortunately for many, they really don’t understand what that means. Often times it is met with anger or resentment. How many people are actually excited to see the “pen testers” coming?

A penetration test, or pen test, is nothing that should be feared. While it is considered to be an adversarial act, the end goal is to assess the security of the environment or application to identify security risks before the “bad guys” do and help provide recommendations to reduce that risk.

That doesn’t sound that bad right, or does it? I may have left out the fact that a pen test may include exploiting your applications, retrieving your sensitive data, or even social engineering staff members to get what they want. But seriously, that is not as bad as it sounds and a pen test done right can be a very positive experience.

A big issue with a pen test is that in different companies and communities it has a different meaning. Sure the simple definition above should always fit that, but the scope that is defined and the results that are received can be very different. Here are some examples of some different types of pen tests (network and application specific).

Basic Pen Test (Scanner Only)
In my opinion this is not a pen test, but rather a vulnerability scan. In this situation, the “testers” will run a tool like Nessus or Qualys and then provide the results of that scan. The test is usually started by providing a set of IP addresses or URLs and then the scanner is configured and let loose. A few hours later, or maybe days, you get a report from the tool that is then passed on to the client. This type of assessment can make it difficult to identify the true risk of the vulnerabilities identified because they were not fully exploited. Maybe the scanner identified that there was SQL injection, but it didn’t follow through with the vulnerability to see how much access that provided.

Limited Scope Pen Test (Fairly Typical)
This type of test has scope limitations, meaning that it might just include a subset of IP addresses, specific functionality of an application, or how far you can take an exploit if one is found. This is fairly typical as it is rare to find a pen test that is fully open with everything on the table. The scope is defined in the rules of engagement as to what can and cannot be performed.

Full Pen Test (Not as Common)
Everything is game in this type of test. Be prepared to receive phishing emails or phone calls trying to get you to fall for a malicious attack. Your social profiles may also be a concern for you as when everything is game, a tester will use any avenue they can to try and gain access. All IP’s or the entire application is in scope. It can be very difficult to stop the testers from gaining access to systems when everything is in play.

Both the Limited and Full scope pen tests usually consist of both automated tools and lots of manual testing to identify the security risks.

In addition to the types of tests, we need to think about the different goals the client may have for requesting a pen test. Here is a quick rundown of some of the goals we see during a test.

Compliance Check Box
This is commonly seen by organizations that fall under some form of compliance, like PCI. “We are required to do this, so lets just get it done.” Often times the client is not really looking for security risks, but rather just trying to check the box. This doesn’t mean you should short change the testing efforts. The purpose of having a test performed is to help identify and reduce risk to the company.

Assess the Security of the Endpoint
This is seen in most tests where the client wants a vulnerability assessment of their endpoint, whether it is an IP or an application, so they can work to mitigate the risks identified. This type of test can be broken down into multiple levels, depending on how far the client wants to go. Some pen tests with this goal may not allow exploitation, making the goal just to identify vulnerabilities. Others, however, have higher goals of gaining access to internal networks, exploiting vulnerabilities, or gaining domain admin rights. This all depends on the goal of the organizer of the test.

High Stakes Goals
Some tests have very limited, yet high stakes goals. For example, many tests just want to see if the tester can gain domain administrator rights to the domain. In these types of tests, many of the other “vulnerability assessment” type findings may be overlooked. While they may be identified to help reach the ultimate goal, the goal is not to identify all, or as many as possible, of the risks to the endpoint.

In most tests, it is the assessing the security of the endpoint that we see the most. The goal is to identify the different risks, and while gaining internal access or domain administrator rights is great, the client is looking for more actionable results to it.

When testing occurs, often times the development teams have very little involvement. They may know it is going on, or have to provide some support if the applications are not configured properly, but that is usually the extent of it. It is important that we understand the goal and type of testing that is being performed. Also understand the purpose of the test should be to provide insight we didn’t have previously that could help us decrease the risk to our company.

Penetration tests, while “adversarial”, should be a collaborative effort with a positive feel. Don’t look at it as an “us” vs. “them”. The team was brought in for a specific task. The task should produce actionable results that are relevant to the environment. If they don’t, then it may be time to switch testing companies. Keep an open line of communication and a positive attitude.

by Leave a Comment

SDLC: Understanding your Roles

Application security should be on the mind of anyone that is part of the application design/build process. That means architects, developers, application owners, QA testers, business analysts and even end users. Everyone of these positions plays a role in the security of the applications. Depending on the organization, the roles can be quite different. You must understand the roles of these positions from a development perspective to really understand how they fit into the security aspect of the machine.

The first step in the process is to define and document each role in the SDLC. The goal is to understand each role’s relation to your SDLC. Usually the size of the development teams indicate the number of roles that may be implemented. Here are a few things to think about when you are defining your roles:

  • Who defines business requirements – Often times the requirements get spread across different teams. Ideally it is the application owner and business analysts working with end users to determine the requirements. However, often times many items are left up to the developers or database administrators to determine or define requirements. This is especially true around input validation or how data is stored.
  • Who directs the coding guidelines – In large enterprises it is common to see a centralized architecture group that defines coding guidelines across different teams. They may define if database access is limited to stored procedures or a specific ORM. In other situations it may be up to the individual developer. Is there a central input validation or output encoding framework?
  • Who determines database schema – When thinking about how data is stored, who defines the fields that are used, how they are protected (encrypted, hashed, plain text) and how the database is structured? Does the table layout make sense? Is it properly segmented?
  • Who tests the application – The quick response is the QA team, but developers are most likely responsible for testing as well. What about third parties, whether they be an internal security team, a client team or other 3rd party testing teams.

Understanding these roles and who is doing what is critical to maturing a secure SDLC program. Traditionally, the groups are often fairly separate, but as you start to look at the different questions you realize that many of these items are handled by multiple groups. It is that collaboration and communication that is also critical to maturing the SDLC.

The next step is to start identifying the people that are occupying these roles. What skillsets do they possess and do they line up with the role you just defined? This will ultimately lead to defining what training is required for each resource. Providing custom training that is specific to the groups needs is much more efficient and effective than just hosting a generic secure coding class. What if the group that needs training is QA or the business analysts? Developer training isn’t what is needed there. What if the group develops in .Net? A course written using Java will not be as effective.

Finally, we start to identify the processes for the SDLC from start to finish and look at what does and does not exist. From the processes that do exist, what role is responsible for that piece of the puzzle. There can be a lot of cogs in the development process, especially when we bring security into the picture. Think about things like static and dynamic analysis, which are part of most mature secure SDLCs. Do these exist, and if not, who will be the people involved with them when they are implemented?

Identifying the full process and what each role is doing is really the beginning of creating baselines for your program which we will cover in another post. This is critical because it provides a starting point so we can define where we are going. Like an asset inventory, you must understand the roles in the entire SDLC and what part they play. Once we start to truly understand our teams, we can start to make the adjustments needed to move forward in secure SDLC maturity.