Writing secure code is no longer an option.

With financially motivated crime at the top of the web app attack food chain, according to the latest Verizon Data Breach Investigation report, your organization will be hard-pressed to come out on top if you suffer a breach. In order to ensure our organizations and customers are secure, software developers must be able to create code that stands the test of time – only accomplished with proper techniques and a commitment to consistency throughout the organization.

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.

In Practice:

During the design stage, make sure that security policies are implemented within the architecture.

Ensure source code analysis is implemented throughout your SDLC, so that vulnerabilities are detected and can be fixed as soon as they’re written.

For more in-depth practices, SANS offers a great Security Checklist for Web Application Design

Related: Game of Hacks: Promoting Secure Coding Practices

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.

In Practice:

Perform source code analysis both on applications in their design stage as well as legacy applications or software with legacy code to find all vulnerabilities, before analyzing their risk level.

Use a threat modeling tool to automate the process of evaluating and analyzing risk, saving time for the remediation work.

Further reading:

Using Source Code Understanding as a Risk Barometer

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.

In Practice:

Reuse components that you know to be trusted.

Avoid complex architecture and coding with double negatives (more at OWASP).

Centralize your approaches by making the fundamentals part of your design.

Integrate your security tools within the developers already-familiar environments, including their IDE, build management, source repository, bug tracking system, etc.

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.

In Practice:

Find the best mix of SAST, DAST, Pen-testing, RASP and IAST for your organization, and make sure they’re baked directly into the SDLC.

Ensure that your applications Administrative Interface does not allow unauthorized access by non-admins.

Use secure development techniques within secure runtime environments.

Further reading:

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.

In Practice:

Create a data classification system to help easily designates appropriate, role-based privileges for all data.

Perform access control validations to ensure users are authorized to perform any given task, as well as terminating sessions that don’t pass an authorization check.

Centralize the above routines so that any errors or vulnerabilities will be fixed throughout the application.

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.

In Practice:

Never trust user input (a common theme in these practices and one not to be ignored)!

To keep in line with the earlier practice of keeping security simple, be sure to use a whitelisting solution that will be easy for admins.

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.

In Practice:

Ensuring that least privilege is followed will help you in failing securely by denying unauthenticated access.

If there is an error processing the login information, make sure your application doesn’t disclose any more information than a generic error

Always log the failure for further analysis later on to understand the error strategy and see what improvements can be made.

Further Reading:

https://buildsecurityin.us-cert.gov/articles/knowledge/principles/failing-securely

http://resources.infosecinstitute.com/fail-open-authentication/

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.

In Practice:

Assume your source code has been compromised and always ensure proper security testing.

Threat modeling and defense in depth are two principles that will help in knowing where you’re most vulnerable so you can decide how to move forward.

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.

In Practice:

Using a visualized graph such as the one CxSAST offers adds value by saving time and later issues by providing an in-depth analysis of the issues found in your code – and the best locations to fix them for maximum remediation in minimal effort and tampering.

Further Reading & Resources:

Writing Secure Code by Michael Howard and David LeBlanc

The OWASP Secure Coding Practices Checklist