It is a common misconception that the overhead introduced by security controls will render an application too slow...
for customer acceptance. So when application developers pit security against performance, performance wins -- every time. The result can be an application riddled with vulnerabilities.
“We need to take a step back and re-evaluate the assertion that security is going to impact performance,” says Dan Cornell, CTO of consulting firm Denim Group. “It’s a big mistake to be premature in optimizing for performance. A better approach is to build security in a sensible way, then if you have a performance problem, optimize for performance.”
Sooner or later an application built for performance will succumb to its own vulnerabilities, making performance a moot point. On the other hand, building too much security into an application impairs usability. Because no two applications are alike, it is impossible to create a list of specific security controls that should be built into every application. “Security needs are completely dependent on the application or system in question,” says David Lindsay, senior security consultant with consulting firm Cigital.
To strike a balance between security and usability, security controls should be considered from a risk management perspective. These efforts begin during the architectural process and continue through to development. “The [security] decisions that need to be made are done at the architectural level. Once they’re baked into the architecture, you need to have the controls in various parts of the code, and that’s the responsibility of the developer -- to ensure that the correct architectural components are being inserted within the code. It’s up to both to do the detailed implementation right,” says Lindsay.
Here are three best practices for ensuring that security is built into your applications:
Conduct upfront threat modeling
Threat modeling occurs during the architectural process. It is a structured way of looking at how an application is built, how data flows through the application and where it is stored. “It is a way of trying to understand the business risks of an application,” says Lindsay.
By looking at how data moves through an application, you can identify vulnerabilities. Once you have a giant list of things that can go wrong, you can begin to identify appropriate controls based on the likelihood of them occurring. The idea is to determine where the most effort should be applied to protect the application -- before coding begins.
Brainstorm abuse cases
Brainstorming abuse cases also takes place during the architectural process. However, while threat modeling is a very structured process, brainstorming tends to be unstructured. It involves considering use case scenarios and brainstorming all the possible ways that the application can be misused. Consider, for example, an online banking application. “What are some situations where this can be misused,” asks Cornell. “We don’t want a nonsystem user to be able to transfer money into an external account. We don’t want someone inside the system to be able to transfer money from someone else’s account into theirs.” Once these abuse cases are identified, developers can put checks in place to help prevent them from occurring in production.
“If this is done upfront, it doesn’t have to be expensive. It can proactively identify design flaws that tend to be the most expensive to fix,” says Cornell.
Include input validation
From a code-level standpoint, input validation is the best security measure you can implement, according to Cornell. However, it brings us back to the security versus performance debate. “There’s conventional wisdom that says if you do input validation, it will kill performance. In actuality, it’s an assertion that’s not backed up by data. Poorly implemented validation can impact performance,” says Cornell.
Input validation essentially puts a “screen in front of the application, making it impossible to exploit a vulnerability that might exist,” says Cornell. A path still exists to the code, but weaknesses within the code are not exploitable. For example, proper input validation can prevent a number of attacks including cross-site scripting, SQL injection, command injection and buffer overflows.
“Input validation is one thing that provides a tremendous boost to application security, and the extra effort to do it is not that great,” says Cornell.
There is a temptation amongst software architects and developers to write off security controls due to the performance impact they will have on an application. However, when done right, security controls introduce little to no latency, and their absence can cause more harm than good. Instead of dismissing security, software architects and developers should work together to make risk-based decisions that balance usability and the need for security.