Tag Archives: security training

What Happens When All SSNs are Breached

Visit any news site or social media outlet and you are bound to see news of some new company getting breached. It is a lot of what we talk about these days. Whether it is passwords, credit card information, health information or social security numbers, if it is breached it is headline news. With the exception of those trying to scam the system and get a quick payday, it is getting to the point where most people outside of the information security industry just write it off and don’t give it much thought.

There is a difference between social security numbers or health information that distinguish them from passwords or credit card numbers. They are much harder to replace. Taking a quick look at passwords we can see that it is easy to change them. If my password gets breached, I create a new one. It is usually a simple process that takes very little time. This is especially true if using different passwords for different sites. Credit cards are also fairly simple to replace and come with zero liability. If my card gets breached and there are fraudulent charges I just report them and they are removed. The bank sends me a new credit card and if I am doing regular monitoring of my statements the biggest hassle is changing the credit card that is stored on the different sites.

With social security numbers it is much more difficult to replace them. While they were not meant to be used as identifiers in all of these systems, they unfortunately are. Countless numbers of sites store your social security number increasing the risk to it. Getting a new number can be very difficult, not just the process of getting the new number but also updating everyplace that has it.

What happens if all of the social security numbers get breached? With under 400 million people in the united states how long will it take with all of these breaches for all numbers to have been breached? I know, we could just create all of the numbers that fit the format of xxx-xx-xxxx, but I am talking number with other identifying information. If all of the numbers get breached, what do we do next? Is it still worth spending so much money trying to protect them in our systems? We can’t get people to encrypt them now, will they continue to do it when they are all in the public domain? Do we finally start moving to a new identifier, albeit probably too late? Maybe it is just a money ticket for identity monitoring and credit monitoring companies. Will the duty to protect this information be removed when it is public domain? As we have seen with other breaches, once something is in public domain, no matter how it got there, it is fair game. It raises an interesting situation when a finite set of data is at risk. Do you know what your company is doing to protect this type of information? Better yet, as a consumer, do you have any concern about your SSN being stolen? Chances are very good it is already out there somewhere.

QA and Security Pt. 2: Software Testers

Lets start by discussing the type of QA that tests software to ensure it is working as designed. These are the bug finders of the QA world. The process starts by a developer creating some functional code and then deploying it to an environment specific to the QA team. The QA team then uses its knowledge of how the application is supposed to function and determines if it is performing properly. Any bugs identified get filed and sent back for remediation (hopefully).

There are some pretty major differences between different companies, and maybe within some companies, in how technical a QA team actually is. Many companies I have worked at, the QA team was not as technically savvy as I would have expected. They would use Microsoft Excel spreadsheets to define their test scripts. In this case the word script is used as a set of processes to follow, not automation. Here is how the process would go.

  • Open Internet Explorer
  • Type http://www.oursite.com into the address bar and hit go
  • Enter Valid Username (james)
  • Enter Valid Password (password)
  • Submit Login Form
  • Verify the user is logged in and redirected to Default.html
  • Pass/Fail

The above example may be a little over the top, but this is how a lot of scripts are designed. There is not a lot of thinking outside of the box when it comes to testing the functionality. While that may sound bad, there are some pros to the approach. For example, it ensures that the app is tested the same way every time which can help reduce the chance of a previous test being missed later on. These scripts are actually very easy to automate as well. On the other hand, it opens up the opportunity for a lot of good testing to not be performed.

Many companies are even using automation tools to help out with scripts like the one above. LoadRunner and Selenium come to mind as frameworks to help with this. These tools can record your testing and then play them back repeatedly. This helps when it comes time to re-test an application you can re-run your previous scripts automatically, allowing the manual tester to free up some time to look at other stuff. Of course, as you test more things you would hope that those tests also become automated.

In other companies, the QA testers are very technical. They work much more with creating custom tools to help with testing the applications. They are more savvy regarding how the application works and different ways that users will use it. With the addition of the automated tools, it makes sense to have testers with these capabilities to really dig into testing the application.

In many cases, we are not seeing a lot of QA teams embracing security testing. There are many people that want to believe that many security flaws cannot be tested by your normal QA department. I am not one of those people. I think to help increase security, we need to increase our internal QA capabilities. We hear that there is a shortage of security professionals, but really, we just need to enlist the current professionals in the development process to help out and we will be better off.

You might wonder why I think QA can find many of these security flaws. To be blunt, most of these security issues are just bugs. Bugs are what QA people (in the current context) do. There is no need for so much segregation between QA and security testing. I understand that we don’t want to share our bowl of rice or think that someone else could actually do that, but they can. Lets look at a few examples that QA should be able to test for.

Injection Bugs are the first on the list. While I group these together, this refers to things like OS Injection, SQL Injection, LDAP Injection, Cross-Site Scripting, XML Injection, etc. These types of bugs are typically not that difficult to identify. Before you jump all over my back, I will agree that some of them can be very difficult to identify. I don’t see that as the norm though. The method: Input known control characters for the current context and look at the output.

For example, enter a single quote (‘) into a field and examine the response. Did you get a database error message? If yes, good chance you have SQL injection – investigate further. No error message? Were there other indicators of a flaw? How about the response time? Did it change drastically from a request without that malicious value? Obviously there are other tests involved in this, but this shows how simple some of the tests can be to help identify the easy vulnerabilities. Will it find all of them, probably not, but it is better than finding none. We should not be relying on outside parties to identify a SQL Injection flaw by entering a (‘) into a field. This should be found internally.

Cross-Site Scripting is another good example. Just like above, enter in known control characters for this bug and analyze the output. If you enter an HTML tag does it get sent back without being encoded? How does the application react? Does it validate input? Does it encode output?

Another set of bugs are related to authentication and authorization. Again, this is something simple that QA can test. Verifying if restricted resources are only available to those given permission is a simple process. Same goes for verifying that a user must be authenticated properly before accessing the system. Many times during a penetration test we are given different sets of credentials to help facilitate the testing of auth bugs. Create a map of what pages/functions each role should have access too. Then check to ensure the other roles cannot access those pages/functions. You might actually be surprised at how much more you know about your application after mapping it like this.

Much of this testing can be accomplished using simple tools such as your browser, plugins, and proxies like Burp or ZAP. There is no good reason for why software testers don’t have and understand how to use these tools during their testing. Lets stop the “We don’t allow hacking tools” non-sense. Many of these tools were started as just testing tools, not hacking tools. If you are not providing QA the tools they need, you will never get better at assuring the quality of your software.

If you fall into the category of the less technically savvy personnel work to get them some security training. Not only will it benefit you by better security testing, but it will also make that person much more knowledgable in general and most likely less prone to falling for phishing or social engineering attacks.