When delving into security, an organization tends to focus first on its own data security. After all, if the organization’s data becomes lost, corrupted, modified, or otherwise unusable, the organization could go out of business.
The next level of scrutiny usually resides with third parties, such as partners. Often, the security of user data comes last and many organizations don’t think too much about customer data security at all.
The problem is that many users and customers see the safety of their data as paramount. The whole issue of privacy comes down to the protection of user data such that no one misuses or exposes the information without the user’s knowledge and consent.
In short, when building an application, you must also consider the privacy of user data as a security issue and an important one at that.
A recent article points out that users and customers view the tech industry as poor trustees of their data. In fact, the tech industry has actually fallen behind the government—people trust the government to safeguard their information more often. Many tech companies publicly support enhanced security policies for other entities (such as the government) and privately build more ways to thwart any notion of privacy that the user or customer might have.
This duality makes the situation even worse than it might otherwise be if the tech industry were open about the encroachment on user and customer data.
In order to create a truly secure application, you must be willing to secure every aspect of it, including user and customer data. This act requires that the application only obtain and manage the data necessary to perform its task and that it discard that data when no longer needed.
Trust is something that your application can gain only when it adheres to the same set of rules for working with all data, no matter its source.
What is Software Security Assurance (SSA) ?
The purpose of software is to interact with data. However, software itself is a kind of data. In fact, data comes in many forms that you might not otherwise consider and the effect of data is wider ranging that you might normally think.
With the Internet of Things (IoT), it’s now possible for data to have both abstract and physical effects in ways that no one could imagine even a few years ago. A hacker gaining access to the right application can do things like damage the electrical grid or poison the water system.
On a more personal level, the same hacker could potentially raise the temperature of your home to some terrifying level, turn off all the lights, spy on you through your webcam, or do any of a number of other things. The point of SSA is that software needs some type of regulation to ensure it doesn’t cause the loss, inaccuracy, alteration, unavailability, or misuse of the data and resources that it uses, controls, and protects. This requirement appears as part of SSA. The following sections discuss SSA in more detail.
SSA isn’t an actual standard at this time. It’s a concept that many organizations quantify and put into writing based on that organization’s needs. The same basic patterns appear in many of these documents and the term SSA refers to the practice of ensuring software remains secure.
Considering the OSSAP
One of the main sites you need to know about in order to make SSA a reality in web applications is the Open Web Application Security Project (OWASP) .
The site breaks down the process required to make the OWASP Security Software Assurance Process (OSSAP) part of the Software Development Lifecycle (SDLC). Yes, that’s a whole bunch of alphabet soup, but you need to know about this group in order to create a process for your application that matches the work done by other organizations.
In addition, the information on this site helps you develop a security process for your application that actually works, is part of the development process, and won’t cost you a lot of time in creating your own process.
Even though OSSAP does provide a great framework for ensuring your application meets SSA requirements, there is no requirement that you interact with this group in any way. The group does license its approach to SSA.
However, at this time, the group is just getting underway and you’ll find a lot of TBDs on the site will the group plans to fill in as time passes. Of course, you need a plan for today, so OWASP and its OSSAP present a place for you to research solutions for now and possibly get additional help later.
The whole reason to apply SSA to your application as part of the SDLC is to ensure that the software is as reliable and error free as you can make it. When talking with some people, the implication is that SSA will fix every potential security problem that you might encounter, but this simply isn’t the case.
SSA will improve your software, but you can’t find any pieces of software anywhere that are error free. Assuming that you did manage to create a piece of error free software, you still have user, environment, network,and all software of other security issues to consider.
Consequently, SSA is simply one piece of a much larger security picture and implementing SSA will only fix so many security issues. The best thing to do is to continue seeing security as an ongoing process.
