Based in Denver, CO, Agile Ideation collects the thoughts and experiences of Ed Schaefer. His posts explore agile and devops related topics as he works to maximize team effectiveness and minimize waste through continuous learning, coaching and empowering teams.

Developing Secure Applications and Programs


Malicious attacks have and will continue to be on the rise. As technology becomes more widespread, miniaturized and ubiquitous, the incentive for a cracker to find a vulnerability and exploit it becomes more and more appealing. Attackers who are able to gain illicit access to private information and customer accounts can cause a lot of damage. Physical assets may be stolen, but access to personal data is even more worrisome. Even if an attacker is not able to gain explicit access to an account or system via a flaw, they may be able to obtain information that can be used for social engineering and gain the benefits anyway. While it may be difficult to stop an attacker from manipulating an employee, software engineers can take significant steps to reduce the risk of an attacker gaining access through a vulnerability in an application.

The most important thing a software developer must do to develop a secure application is eliminate any preconceived notions about security. In computer security, being paranoid is a virtue. A developer who believes her software is bug free is setting herself up for failure. Frequently programmers want to put as much functionality into their application as possible, but this may cause the application to have unexpected functions that, when discovered by an attacker, can be utilized to gain illicit access. If a programmer believes their code is perfect and contains no bugs, they may continue adding functionality increasing the danger. It is important for the software developer to limit what access the program has. For example if a fillable web form is created that allows any type of data to be entered for "phone number" an attacker may be able to gain access via cross-site scripting or an SQL injection. The programmer who tells the web form that a field can only be a certain type of data and to bounce anything that does not meet the requirements will produce a substantially more secure application.

Software testing should be enhanced. Typical QA testing is looking for bugs and errors that occur during normal use. In normal use cases it is very unlikely a security flaw would be discovered, as the tester is not looking for security flaws. Testing should be enhanced to test for non-normal use scenarios. This may include using random or unusual data, using a penetration sniffing tool to look for vulnerabilities or even testing under extreme conditions in a fashion similar to browser fuzzing. By having an individual actually attempt to penetrate the application, vulnerabilities can be discovered and patched that would otherwise remain in released code.

A software developer should not rely on security tools already in place. The amount of time or work required to develop an application could be significantly reduced if the software developer believes technology in place will provide protection, but this increases the risk of an attacker exploiting a vulnerability. Encryption may not allow an attacker to view sensitive data, but internal proprietary encryption is often poorly implemented and easy to crack. It should be trivial for the programmer to implement a strong open-source encryption within the application, and by not doing so may expose the organization and all users to additional risk. The same can be said for a firewall; normally this should provide protection from unexpected incoming or outgoing traffic, but if the firewall is penetrated data sent to and from the application may be compromised and could continue unnoticed for a long time.

It is also important to understand the context around security for a particular application. This understanding includes all aspects of security that are of concern including the overall environment, potential threats and objectives. By knowing to what extent confidentiality, availability and integrity are required for the data the programmer can build in strong authentication and tools to help with audits. With this knowledge the programmer is also able to account for any vulnerability that already exist in the system architecture and build controls into the new application to reduce the risk of these vulnerabilities. Another aspect of this is examining and learning from past mistakes. While an attack can have serious consequences and should be avoided as best as possible, looking at successful attacks and what issues or errors allowed the attacker to gain access not only allows vulnerabilities to be closed but helps to ensure the vulnerability will not be exposed in the future.

There are many development models used with the intention of ensuring applications are secure. Each method may apply a different process for ensuring the resulting application is secure, though no code is perfect vulnerabilities may still persist. By applying some formal methodology to ensure all areas of concern are properly constructed, tested and implemented the risk of an attack can be substantially reduced. While the specific methodology used may not be of the utmost significance, it is always important for a software developer to keep security at the forefront of concern. The software developer who fails to take security into consideration will not only be less trusted, but has failed to protect the organization, its employees and clients.


Securing Data

Fencing, fence register, bounds and relocation