Our Thinking

Making Your Applications More Secure – Doing Your Part

Posted by Maartje Kasdorp on Aug 11, 2014 9:42:13 AM

Have you ever had that sinking feeling when you found out that your credit card had been compromised – or your identity had been stolen? Count yourself lucky if you have not experienced this as data breaches and malicious attacks to the applications that we use are no longer an exception as we see in the news almost every day.

If you need a bit more convincing about how much the security threats have become a reality in our world, check out http://www.privacyrights.org/data-breach, which lists a vast number of reported data breaches in the US. I just about fell out of my chair when I browsed through the pages and pages of reports there – and you can only imagine how many more cases go unreported (where companies are trying to keep quiet to protect their reputation). Some highly publicized cases are:

  • Aaron Brothers, a division of Michaels Stores Inc., was part of a data breach of 23 Michaels Stores Inc. The company confirmed that the payment system breach also affected its Aaron Brothers chain. Approximately 400,000 cards were potentially breached from June 26, 2013 through February 27, 2014.
  • In January 2014, representatives of Neiman Marcus reported that a customer information database was hacked. Payment information of 1.1 million individuals had been compromised.
  • In July, it was reported that in March 2014, Chinese hackers broke into the computer networks of the United States government, specifically The Office of Personnel Management, which houses personal information of all federal employees. The hackers appeared to be targeting the files on "tens of thousands of employees who have applied for top-secret security clearance." "The hackers gained access to some of the databases of the Office of Personnel Management before the federal authorities detected the threat and blocked them from the network, according to the officials. It is not yet clear how far the hackers penetrated the agency’s systems, in which applicants for security clearances list their foreign contacts, previous jobs and personal information like past drug use."

As a QA manager who has been involved with dozens of projects, my experience shows that more attention is normally spent on the functional features that needed to be built, as opposed to the non-functional requirements that would make the application usable for our clients. I’ve come to realize that it is becoming just as (if not more so) important to make sure that our systems are secure, given all the malicious attacks that are taking place.

Not every application contains sensitive information, but almost every application is a potential entry point to a system that does. Clearly, personally identifiable information (PII), including credit card payment information, driver’s licenses, and personal health information are some of the crown jewels that attackers seek. Each application has to be considered with its unique features, data, users, architecture, and entry and exit points to determine the vulnerabilities or inherent ecosystem weaknesses. For example, just because you adhere to the PCI Data Security Standard, there is no guarantee that your systems are secure as hackers continuously change their approaches. The consultants in our Security Practice are highly-skilled at performing security assessments and penetration tests. We can’t all be experts at security – it would be nearly impossible for any of us to continuously stay up-to-date with the changes – but we can collectively take responsibility for making secure practices a larger focus of our System Development Life Cycle, and we can all take individual responsibility for applying a security lens to everything we do – analyzing requirements and processes; managing projects; writing and testing code; and configuring, testing, and implementing software packages.

As consultants, we need to make sure that our clients are aware of the potential security risks pertaining to their applications and their data; and as with ensuring application quality during development, we need to make sure applications are developed securely to begin with, instead of letting security experts find issues after the application has been built, or worse, waiting until data is breached when the system is in production.

What can you do to ensure that the applications you build are more secure?

  • Perform a threat analysis at the initiation phase of the project. Identify threats and weaknesses of the application and rank each threat. Microsoft uses a useful threat risk ranking model called DREAD, where some basic questions need to be answered for each identified threat:
    • Damage potential – how big would the damage be if the attack succeeded?
    • Reproducibility – How easy would it be to reproduce an attack?
    • Exploitability – How much time, effort and expertise is needed to exploit the threat?
    • Affected Users – If a threat were exploited, how many users would be affected?
    • Discoverability – How easy is it for an attacker to discover the threat / opportunity?

The answer to each of the questions is scored with a rating 1-10: 1 being a very minor issue and 10 a severe threat. The scores are added up and divided by 5, which provides the DREAD score for the identified threat, allowing the risk reviewer to compare the different threats and take appropriate counter measures, giving priority to the most severe threats.

  • Just like functional requirements are formulated for a system development project, non-functional requirements need to be formulated as well. It is not always easy to formulate such requirements before an application is built as the non-functional requirements are a bit more abstract. If you don’t take the time to define them though, you miss out on a big opportunity to make sure that the application meets your client’s needs regarding aspects like security, performance, maintainability, etc.
    • All developers on the project need to be aware of the techniques they need to apply to avoid the identified security threats. Some factors to consider are:
      • Protect against Cross-site scripting.
      • Protect against Injection flaws, particularly SQL injection.
      • Identify and authenticate access to system components.
      • Use strong cryptography and security protocols to protect sensitive data during transmission over networks.
  • On Agile projects, make sure security aspects are part of the “done” criteria. A story is not done unless the security precautions have been implemented and then reviewed by peers.
  • Set up automated security tests to be performed as part of the continuous integration (check out tools like Quotium).
  • As a Quality Assurance analyst, there are lots of security tests you can perform without being a Security Specialist. Work with the developers on your team to come up with a list of security tests to perform, including:
    • Bookmarking should be disabled on secure pages.
    • There should be a timeout after user inactivity.
    • Secure pages should not be accessible after the timeout.
    • Error messages should never contain code or sensitive information.
    • User should get locked out after multiple failed login attempts.
    • There should be strict minimum password requirements and validations around required password changes.
    • After an unsuccessful login attempt, it should not be specified whether it was the user name or password that is incorrect – otherwise you would give away useful information for a hacker.
    • Sensitive information should be encrypted when displayed on the screen.
    • The user is not able to enter XML in edit fields / save XML to fields in the database.

Each project / application will be unique. Get creative and identify the unique security tests that are required.

  • As a project manager, plan for time in the project schedule for security-related activities by the team members. Plan to bring in a security specialist to advise the team early in the project and to perform code reviews or penetration tests as applicable during the development cycle. Security improvement activities do not have to be on the critical path and they can be planned to be performed at a time that makes sense for your project.

Making sure that the applications we build and implement are secure does not require a major shift in our System Development Life Cycle – but it does require us to be a bit more security conscious in all that we do.

 

Topics: Application Development, Security

Our Thinking - The Online Blog is a source for insights, resources, best practices, and other useful content from our multi-disciplinary team of Onliners.

Subscribe to Blog Updates