In this blog post, I’ll elaborate on the statement “Don’t leave security to the end” and what that means in terms of best practices. Cybersecurity is a constantly changing field that requires critical thinking in a multitude of areas. We need specialists who know applications, databases, networks, and even physical security to name a few. The attack surface is growing as technology expands, and cybersecurity professionals need to be constantly learning. Even if a company hired security specialists for all these unique areas we would likely never be able to complete a project before the funding runs out. For this reason, we need to engage all members of a project or the staff of a company to participate in being a security specialist.

Don't Leave Security to the End visual

This seems great in theory as we’re able to cut back on payroll costs because we’re able to have developers, database specialists, and IT specialists working diligently to mitigate threats. It poses an important question, when do you combat these threats? The answer is constantly which could be intimidating to any one of these roles listed because it’s not necessarily what they signed up for, being a full-time security specialist. That’s where the security mindset becomes key to cultivating with your staff. A developer can still be a full-time developer, but instead of just running through a checklist at the end of their project for security purposes they take a more critical approach to their work.

Every piece of code a developer writes needs a moment to consider time complexity, space complexity, and even readability. What we’re cultivating is an additional layer of thinking that I’ll coin as “security complexity”. This means analyzing the threat surface of the code that was written, possible solutions to reduce that surface, and abstracting your role for a moment to think like a malicious actor who got their hand on the source code that they need to formulate an exploit for.

Some easy steps that a developer specifically can take to analyze their security complexity is to build unit tests that cover basic and well-determined exploits outlined by major organizations, such as OWASP. Ensure that these unit tests have ample code coverage because the test is useless if there are sections left unchecked. Use commonly used libraries that have major time invested in their development because recreating the wheel isn’t just tedious but leaves you vulnerable to attacks that someone has already had an unfortunate encounter with. Using dependency checkers that can identify vulnerabilities is critical for identifying your attack surface.

I touch on the validation of input as an example here. Input from all sources is typically expected to some degree and shouldn’t be trusted to conform to that expectation. As such, we can deny any form of data we’re expecting to use that doesn’t conform to our expectation. If complete denial of data isn’t an option for your application because of dynamic needs, it ultimately boils down to understanding your attack surface. If you understand that the given input for your web application is going to be passed into a MySQL database for instance, we can implement safe practices to sanitize the data from key SQL words to prevent attacks. Proactive solutions like this allow you to mitigate your attack surface.