Gone are the days where testing your application code for security issues was something done last minute or not at all. If you have a stake in the applications you’re building or the security of the organization behind the software, from developers to IT operations, the security team and all the way to the CISOs and CSOs, ensuring the code is secure is a major part of your job.
ALL application stakeholders need to do their part in making sure secure coding practices are established and followed. To help, we’ve collected the practices, along with specific examples of each, that are essential for organizations, with an eye towards application security. With around 75% of vulnerabilities found within the application layer, that’s where organizations should be focusing.
With the implementation of a standard set of secure coding practices, your organization will have a much easier time understanding the most common risks you deal with and learn the best ways to fix and prevent similar issues in the future.
How have you implemented these practices in your own organization? Share your thoughts below!
1. Secure by Design
Today’s worst kinds of application vulnerabilities are realized when malicious actors exploit bugs that allow them to steal, change or delete data. These attacks use vulnerabilities like SQL injection and cross-site scripting, which, while fairly simple to fix, still somehow manage to run rampant and wreak havoc in our software.
The solution, which is never easy but will save time and damage later, is to design your applications with security at top of mind. Making your applications secure by design is the number one practice on this list because it’s a prerequisite for the security principles to follow.
2. Threat Modeling
Determining the greatest threats and risks posed by your applications is a fundamental part of secure code. You most likely won’t be able to fix all issues immediately, all the time, so identifying your most valuable assets and the most severe vulnerabilities will tell you what needs to get fixed and how quickly.
Microsoft’s Guide to Threat Modeling
3. Keep Security Simple
Complexity makes security easy to ignore and fail. If there are too many separate tools and processes included in properly securing a function, they won’t all be followed. Making the process as simple as possible for all involved will go far in getting the organization as a whole to adopt these principles.
Read more about how CxSAST enforces security policies throughout the SDLC.
4. Defense in Depth
At the same time that we’re making security as simple as possible, we need to practice ‘defense in depth.’ It’s a balance that needs to be weighed by the various risks posed. The principle of defense in depth is all about layering our defense tools in order to minimize the number of holes in our application that would allow different attacks to take place.
The idea behind defense in depth, of course, is that if one security layer fails, the next will be there to catch whatever attacks fall through the cracks of the first layer. How many layers and which tools are required are different for each organization.
InfoSec Institute:Defense-in-Depth: Layered Protection and Data Security
5. Least Privilege
Access within applications needs to be carefully designed so that each account has the appropriate – in this case, the least – amount of privilege necessary for their needs or responsibilities.
Consider any applications that offer first-time users default passwords for the initial login session. To make it harder for malicious actors to get their hands on them, make sure each default password is different, complex, and only usable for a limited time.
6. Positive Security
Define what is allowed and reject everything else. This model, also called whitelisting, is the only true method of preventing unwanted attacks that weren’t thought of during development. New malware pops up on a regular basis, so it’s already impossible to keep your applications up to date in that sense. With application whitelisting, the attack surface is limited only to the number of risks it has accepted through the earlier discussed practice of threat modeling.
7. Fail Securely
Bruce Schneier wrote it perfectly: “ When an ATM fails, it shuts down; it doesn’t spew money out its slot.”
Realize that failure is unavoidable and your applications will fail – make sure you (and they) are prepared. Instead, we need to ensure our software is prepared to fail without offering up sensitive data in the process.
8. Avoid Security by Obscurity
Security by Obscurity does NOT work. We’ve seen it fail time and time again, yet some organizations still don’t seem to get it. For example, while demanding your users and employees use strong passwords offers one layer of security by obscurity, you can’t just rely on that. You still need to sanitize inputs, secure your database, and log inconsistencies for later analysis.
Perhaps one of the best ways to avoid security by obscurity is to assume your source code has already been taken. That would be a worst-case scenario, but we can’t keep holding our fingers crossed hoping a vulnerability won’t be discovered before you can fix it.
9 .Complete Remediation
Last, yet certainly not least, is the principle of fully understanding and remediating risky vulnerabilities. Only through proper testing and training can an organization truly cut down on their security risks by learning from past mistakes and planning for the future. Completely remediating those vulnerabilities that hold your code back is the only way you can truly move forward in your security program.
This is where source code analysis works especially well, both in regards to testing for security issues and tracking the issue fixes. As the OWASP Testing Guide – a highly valuable resource for all application stakeholders – states:
Source code analysis and unit tests can validate that the code change mitigates the vulnerability exposed by the previously identified coding defect.
The results of automated secure code analysis can also be used as automatic check-in gates for version control, for example software artifacts cannot be checked into the build with high or medium severity coding issues.
Writing Secure Code by Michael Howard and David LeBlanc
Sign up today & never miss an update from the Checkmarx blog
Interested in trying CxSAST on your own code? You can now use Checkmarx's solution to scan uncompiled / unbuilt source code in 18 coding and scripting languages and identify the vulnerable lines of code. CxSAST will even find the best-fix locations for you and suggest the best remediation techniques. Sign up for your FREE trial now.
Checkmarx is now offering you the opportunity to see how CxSAST identifies application-layer vulnerabilities in real-time. Our in-house security experts will run the scan and demonstrate how the solution's queries can be tweaked as per your specific needs and requirements. Fill in your details and we'll schedule a FREE live demo with you.