3:35 min read | Flaws in software can leave your information systems vulnerable to attacks. Information about bugs in popular commercial and open-source software is available to everyone. Attackers exploit them once they’re known, so keeping up with patch releases is essential to security. Applications that are developed in-house and commercially obscure applications aren’t subject to the same broad scrutiny, but they still may have potentially vulnerable coding flaws to be dealt with. CIS Control #18 addresses the methods of keeping applications secure, whether they’re acquired or internally developed.
Commercially-developed applications
When it comes to vulnerable applications, the source doesn’t matter. When dealing with applications from outside sources, whether commercial or free, the most important consideration is to stay with a supported version and apply all security patches in a timely manner. This doesn’t necessarily mean having the latest version! When available, using the long-term support (LTS) version of an application can be less disruptive than updating to each new version. However, regular bug fixes and security patches still need to be applied quickly, and you should have an upgrade plan ready when the newer version is released.
In many cases, by the time a security patch is released, the vulnerabilities that it addresses are publicly known. Publicly-available exploits for the code may already exist or be easily discovered by reverse-engineering the change. Criminals will figure out how to take advantage of it if they haven’t already. There’s no escaping the need or the urgency required to fix these vulnerabilities.
Internally-developed applications
Developers need to design security in from the start, not add it on after they have working code. Unfortunately, this remains a recommended practice and not a common one, so organizations that develop their own applications may have a lot more work to do.
There’s pressure to get the code working on time, which sometimes results in security considerations being pushed to the background. Yielding to the pressure will only cause trouble. It’s harder to go back and catch every vulnerability than it is to stick with security-oriented development practices that minimize the chances of exploitable bugs.
The practices which bake security in from the start include these:
- Sanitizing all inputs from outside sources against invalid syntax and characters.
- Documenting expected data for each function.
- Doing error checking on all inputs for length, indexing, bounds, etc.
- Handling exceptions and errors properly rather than dumping error messages to output that the user sees.
Considerations for all applications
Development and QA work should be done on development systems that don’t have access to production data. Developer accounts shouldn’t give access to production systems; that way no one can work on live data by mistake.
Developers can still miss bugs, and configuration errors can introduce vulnerabilities. To maintain the safety of your applications and data, organizations should always test new implementations of the applications they use with automated scanning software. Being the first to discover a bug is better than living with an undiscovered vulnerability.
Code should go to production only after being thoroughly tested. A full, automated test needs to be run before each release, not just on the changes. Bugs in earlier versions have a way of creeping back, and seemingly inconsequential changes can introduce problems.
If any new or previously undocumented vulnerabilities turn up, they should be carefully documented so that others can replicate them. A confidential report should then go to the software’s maintainer. Until it’s fixed, measures should go into place to prevent exploitation of the bug. These could include input filters or a configuration setting to avoid the dangerous use case.
Application firewalls are another important level of protection against unknown or unpatched bugs. They provide a level of protection against the exploits of known bugs and common attack patterns, such as syntactically incorrect requests.
OWASP has some excellent resources for developing secure applications.
A previously undiscovered bug can turn into an active threat without warning. Zero-day exploits take advantage of these to steal vast amounts of data or gain control of computers. Criminals or malicious attackers will have information about these vulnerabilities before you do.
Badly designed and out-of-date applications are especially at risk. Protective measures need to cover purchased, free, and in-house software. They need to guard not only against known issues but against ones that are still unknown. A multilayered approach consisting of good design, maintenance, and application-level protection against malicious traffic will provide the best protection.