The initial step in implementing SSA as part of your application is to define the SSA requirements. These requirements help you determine the current state of your software, the issues that require resolution, and the severity of those issues.
After the issues are defined, you can determine the remediation process and any other requirements needed to ensure that the software remains secure. In fact, you can break SSA down into eight steps:
1.Evaluate the software and develop a plan to remediate it.
2.Define the risks that the security issues represent to the data and categorize these risks to remediate the worst risks first.
3.Perform a complete code review.
4.Implement the required changes.
5.Test the fixes you create and verify that they actually do work on the production system.
6.Define a defense for protecting application access and therefore the data that the application manages.
7.Measure the effectiveness of the changes you have made.
8.Educate management, users, and developers in the proper methods to ensure good application security.
Categorizing Data and Resources
This process involves identifying the various pieces of data that your application touches in some way, including its own code and configuration information. Once you identify every piece of data, you categorize it to identify the level of security required to protect that data.
Data can have many levels of categorization and the way in which you categorize the data depends on your organization’s needs and the orientation of the data.
For example, some data may simply inconvenience the organization, while other data could potentially cause harm to humans. The definition of how data security breaches affects the security environment as a whole is essential.
After the data categorization process is complete, it’s possible to begin using the information to perform a variety of tasks. For example, you can consider how to reduce vulnerabilities by:
•Creating coding standards
•Implementing mandatory developer training
•Hiring security leaders within development groups
•Using automated testing procedures that specifically locate security issues
All of these methods point to resources that the organization interacts with and relies upon to ensure the application manages data correctly. Categorizing resources means determining how much emphasis to place on a particular resource.
For example, denying developers training will have a bigger impact than denying individual application users training because the developers work with the application as a whole. Of course, training is essential for everyone. In this case, categorizing resources of all sorts helps you determine where and how to spend money in order to obtain the best Return on Investment (ROI), while still meeting application security goals.
Performing the Required Analysis
As part of SSA, you need to perform an analysis on your application. It’s important to know precisely what sorts of weaknesses your code could contain. The operative word here is “could.” Until you perform analysis in depth, you have no way of knowing the actual security problems in your code.
Web applications are especially adept at hiding issues because, unlike desktop applications, the code can appear in numerous places and scripts tend to hide problems that compiled applications don’t have because the code is interpreted at runtime, rather than compile time.
It’s important to understand that security isn’t just about the code—it’s also about the tools required to create the code and the skill of the developers employing those tools. When an organization chooses the wrong tools for the job, the risk of a security breach becomes much higher because the tools may not create code that performs precisely as expected.
Likewise, when developers using the tool don’t have the required skills, it’s hardly surprising that the software has security holes that a more skilled developer would avoid.
Some experts claim that there are companies that actually allow substandard work. In most cases, the excuse for allowing such work is that the application development process is behind schedule or that the organization lacks required tools or expertise. The fact that an organization may employ software designed to help address security issues (such as a firewall), doesn’t alieve the developer of the responsibility to create secure code. Organizations need to maintain coding standards to ensure a good result.
Logic
Interacting with an application and the data it manages is a process. Even though users might perform tasks in a seemingly random fashion, specific tasks follow patterns that occur because the user must follow a procedure in order to obtain a good result.
By documenting and understanding these procedures, you can analyze application logic from a practical perspective. Users rely on a particular procedure because of the way in which developers design the application. Changing the design will necessarily change the procedure.
The point of the analysis is to look for security holes in the procedure. For example, the application may allow the user to remain logged in, even if it doesn’t detect activity for an extended period. The problem is that the user might not even be present—someone else could access the application using the users credentials and no one would be the wiser because everyone would think that the user is logged in using the same system as always.
However, data holes can take other forms. A part number might consist of various quantifiable elements. In order to obtain a good part number, the application could ask for the elements, rather than the part number as a whole, and build the part number from those elements. The idea is to make the procedure cleaner, clearer, and less error prone so that the database doesn’t end up containing a lot of bad information.
Data
It may not seem like you can perform much analysis on data from a security perspective, but there really are a lot of issues to consider. In fact, data analysis is one of the areas where organizations fall down most because the emphasis is on how to manage and use the data, rather than on how to secure the data (it’s reasonable to assume you need to address all three issues). When analyzing the data, you must consider these issues:
•Who can access the data
•What format is used to store the data
•When the data is accessible
•Where the data is stored
•Why each data item is made available as part of the application
•How the data is broken into components and the result of combining the data for application use
For example, some applications fail to practice data hiding, which is an essential feature of any good application. Data hiding means giving the user only the amount of information actually needed to perform any given task.
Applications also format some data incorrectly. For example, storing passwords as text will almost certainly cause problems should someone break in. A better route is to store the password hash. The hash isn’t at all valuable to someone who has broken in because the application needs the password on which the hash is based.
Making all data accessible all the time is also a bad idea. Sensitive data should only appear on screen when someone is available to monitor its use and react immediately should the user do something unexpected.
Storing sensitive data in the cloud is a particularly bad idea. Yes, using cloud storage makes the data more readily available and faster to access as well, but it also makes the data vulnerable. Store sensitive data on local servers when you have direct access to all the security features used to keep the data safe.
Application developers also have a propensity for making too much information available. You use data hiding to keep manager-specific data hidden from other kinds of users. However, some data has no place in the application at all. If no one actually needs a piece of data to perform a task, then don’t add the data to the application.
Many data items today are an aggregation of other data elements. It’s possible for a hacker to learn a lot about your organization by detecting the form of aggregation used and taking the data item apart to discover the constituent parts. It’s important to consider how the data is put together and to add safeguards that make it harder to discover the
source of that data.
Interface
A big problem with software today is the inclusion of gratuitous features. An application is supposed to meet a specific set of goals, perform a specific set of tasks. Invariably, someone gets the idea that the software might be somehow better if it had certain features that have nothing to do with the core goals the software is supposed to meet.
The term feature bloat has been around for a long time. You normally see it discussed in a monetary sense—as the source of application speed problems, the elevator of user training costs, and the wrecker of development schedules. However, application interface issues, those that are often most affected by feature bloat, have a significant impact on security in the form of increased attack surface.
Every time you increase the attack surface, you provide more opportunities for a hacker to obtain access to your organization. Getting rid of gratuitous features or moving them to an entirely different application, will reduce the attack surface—making your application a lot more secure. Of course, you’ll save money too.
Another potential problem is the hint interface—one that actually gives the security features of the application away by providing a potential hacker with too much information or too many features. Even though the password used to help a user retrieve a lost password is necessary, some implementations actually make it possible for a hacker to retrieve the user’s password and become that user.
The hacker might even lock the real user out of the account by changing the password (although, this action would be counterproductive because an administrator could restore the user’s access quite easily).
A better system is to ensure that the user actually made the request before doing anything and then ensuring that the administrator sends the login information in a secure manner.
Constraint
A constraint is simply a method of ensuring that actions meet specific criteria before the action is allowed. For example, disallowing access to data elements unless the user has a right to access them is a kind of constraint. However, constraints have other forms that are more important.
The most important constraint is determining how any given user can manage data. Most users only require read access to data, yet applications commonly provide read/write access, which opens a huge security hole.
Data has constraints to consider as well. When working with data, you must define precisely what makes the data unique and ensure the application doesn’t break any rules regarding that uniqueness. With this in mind, you generally need to consider these kinds of constraints:
•Ensure the data is the right type
•Define the range of values the data can accept
•Specify the maximum and minimum data lengths
•List any unacceptable data values
