Monthly Archives: July 2015

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 ( 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.


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.


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 That indicates that the site is using HTTPS and your data will be protected when sent to the business.


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


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 are valid results that go to the creators of FireFox. Under that are results that don’t go to 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.


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.

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.

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.