Micro Focus is now part of OpenText. Learn more >

You are here

You are here

Put OWASP Top 10 Proactive Controls to work

public://pictures/brent.jpeg
Brent Jenkins Evangelist, Micro Focus Fortify
 

It has always been important for developers to write secure code, but with the wider adoption of DevOps, agile, continuous integration, and continuous delivery, it's more important than ever.

Organizations are realizing they can save time and money by finding and fixing flaws fast. And developers are discovering that great coding isn't just about speed and functionality, but also minimizing security risk.

As developers prepare to write more secure code, though, they're finding that few tools are designed with software writers in mind. For example, the OWASP Top 10, a cornerstone of web application security, identifies the risks of the most common vulnerabilities in applications.

These include things such as injection, broken authentication and access control, security misconfigurations, and components with known vulnerabilities. But the list doesn't offer the kind of defensive techniques and controls useful to developers trying to write secure code.

OWASP Top 10 Proactive Controls contains security techniques that should be included in every software development project. What's more, each item is mapped back to the OWASP Top 10 risk it addresses.

Here's a walk-through of the newest Top 10, and how to put it into action (hint: motivate your developers).

1. Define security requirements

According to OWASP, a security requirement is a statement of needed functionality that satisfies many different security properties of software. Requirements can be drawn from industry standards, applicable laws, and a history of past vulnerabilities. A good place to start a search for requirements is the OWASP Application Security Verification Standard (ASVS), a catalog of security requirements and verification criteria.

Security requirements are usually implemented in four steps. First, you need to find and choose the requirements for your software. Next, you review how the application stacks up against the security requirements and document the results of that review. Then you modify the app, where necessary, to meet the requirements. Finally, create test cases to confirm the requirements have been implemented.

By defining the security requirements for an application, you can define its security functionality, build in security earlier in the development process, and avert the appearance of vulnerabilities later in the process.

[ Special Coverage: SecureGuild Conference 2019 ]

2. Leverage security frameworks and libraries

Developers writing an app from scratch often don't have the time, knowledge, or budget to implement security properly. Using secure coding libraries and software frameworks can help address the security goals of a project.

When using third-party libraries or frameworks, it's best to follow these guidelines:

  • Use only those from trusted sources.
  • Maintain a catalog of any libraries that you're using.
  • Keep your libraries and components up to date so any newly discovered vulnerabilities can be addressed immediately.
  • Reduce the attack surface of your software by encapsulating libraries so only required behavior is introduced into the program.

Secure frameworks and libraries can provide protection against a wide range of web application vulnerabilities, but they must be kept current so known vulnerabilities are patched.

3. Secure database access

Access to all data stores, including relational and NoSQL, should be secure. Take care to prevent untrusted input from being recognized as part of an SQL command. Turn on security settings of database management systems if those aren't on by default. All access to the database should be properly authenticated.

Secure access to databases can help thwart injection attacks, which are on the OWASP Top 10 list, and weak server-side control flaws, which are on the OWASP Mobile Top 10 list of vulnerabilities.

4. Encode and escape data

Encoding and escaping are defensive techniques used to foil injection attacks. Encoding translates a character into an equivalent that's not dangerous to an interpreter. For example, an angle bracket < could be converted to &lt. Encoding should be applied just before content is passed to an interpreter, so the encoding doesn't interfere with program execution.

Escaping adds a character before a string to prevent it from being misinterpreted. For instance, the backslash character \ could be placed in front of a double quotation mark to make sure the string is interpreted as text and not as a closing string.

Use these techniques to prevent injection and cross-site scripting vulnerabilities as well as client-side injection vulnerabilities.

5. Validate all inputs

Before an application accepts any data, it should determine whether that data is syntactically and semantically valid in order to ensure that only properly formatted data enters any software system component.

Syntax validity means data sent to a component should meet expectations. For example, if a PIN is supposed to consist of four numbers, then something calling itself a PIN that consists of letters and numbers should be rejected.

There are two general methods for doing input syntax validation. One is blacklisting, where you compare the input against a list of malicious content. If it's on the list, it gets rejected. The other is whitelisting, which uses rules to define what is "good." If input satisfies the rules, then it's accepted.

Although useful in foiling obvious attacks, blacklisting alone isn't recommended because it's prone to error and attackers can bypass it by using a variety of evasion techniques.

Semantic validity means input data must be within a legitimate range for an application's functionality and context. For example, a start date needs to be input before an end date when choosing date ranges.

Always perform input validation server-side for security reasons. Client-side validation can be useful, but can be bypassed.

In addition, use input validation in combination with other controls, since it doesn't always make data "safe." Some complex forms of data can appear to be "valid" but still contain malicious code for cross-site scripting or SQL injections attacks.

Nevertheless, input validation can reduce the attack surface of an application and can make attacks on an app more difficult.

[ Also see: OWASP Top 10 Proactive Controls 2018: How it makes your code more secure ]

6. Implement digital identity

A digital identity is the unique representation of a person or other subject as they engage in an online transaction, and you use authentication to determine whether you can  trust that person or subject and they are who they say they are. You do this through passwords, multi-factor authentication, or cryptography.

Although there's a movement to eliminate passwords, they remain, and probably will remain, an important component of authentication. You need to create policies for password length, composition, and shelf life, you must store them securely, and you must make provisions for resetting them when users forget them or if they're compromised.

Multi-factor authentication requires a combination of elements, such as something you know—a password or PIN, for example—something you own, such as a token or phone; or something you are—a fingerprint, eyeball, or face.

Cryptographic authentication is considered the highest form of authentication and requires a person or entity to have proof of possession of a key through a cryptographic protocol.

Strong authentication can prevent vulnerabilities such as broken authentication and session management, and poor authentication and authorization.

7. Enforce access controls

Access control, also known as authorization, is about granting or denying requests from a user, program, or process. Some good things to keep in mind when designing access controls include:

  • Design the controls up front
  • Force all requests to go through access-control checks
  • Make access denial a default control
  • Limit access to the minimum amount necessary to perform a task
  • Avoid hard-coding roles into access controls
  • Log all access control events

Strong access control can prevent the OWASP-flagged broken access-control vulnerabilities and authorization and authentication flaws.

Digital identity, authentication, and session management can be very challenging, so it's wise to have your best engineering talent working on your identity systems.

8. Protect data everywhere

Failure to properly protect sensitive data—passwords, credit card numbers, health records, business secrets, and such—can cost an organization dearly, especially in light of laws such as the EU's General Data Protection Regulation (GDPR) and rules such as the PCI Data Security Standard. That's why you need to protect data needs everywhere it's handled and stored.

The first step in protecting your data is to classify it so you can map out your strategy for protecting it based on the level of sensitivity. Such a strategy should include encrypting data in transit as well as at rest.

When encrypting data, it isn't necessary to reinvent the wheel. There are very good peer-reviewed and open-source tools out there, such as Google Tink and Libsodium, that will likely produce better results than anything you could create from scratch.

But do take special measures to protect the "secrets" in your application that it uses to implement security—things such as certificates, SQL connection passwords, third-party service account credentials, passwords, SSH keys, and encryption keys.

For example, secrets should not be stored in code, config files, or passed through environmental variables. Secrets should also be kept in a "vault," such as KeyWhiz, Hashicorp’s Vault project, or Amazon's Key Management Service (KMS). These vaults can provide secure storage and allow for access to the secrets at runtime.

When you've protected data properly, you're helping to prevent sensitive data exposure vulnerabilities and insecure data storage problems.

9. Implement security logging and monitoring

Most developers are familiar with logging. Security logging gathers security information from applications during runtime. You can use that data for feeding intrusion detection systems, aiding forensic analysis and investigations, and satisfying regulatory compliance requirements. It can also reveal when a user is behaving in a malicious manner.

Security monitoring uses automation to review log information in real time. In addition to their security functions, you can use monitoring tools for debugging and operations.

Build and manage your logging systems securely. For example, don't log sensitive information such as passwords, session IDs, credit cards, and Social Security numbers. And preserve the integrity of logs, just in case someone tries to tamper with them.

In addition, you should centralize logs from distributed systems. This preserves data from any node that may be compromised, and facilitates centralized monitoring.

10. Handle all errors and exceptions

When an application encounters an error, exception handling will determine how the app reacts to it. Proper handling of exceptions and errors is critical to making code reliable and secure. Exception handling can be important in intrusion detection, too, because sometimes attempts to compromise an app can trigger errors that raise a red flag that an app is under attack.

Best practices for handling exceptions and errors include managing them in a centralized manner to avoid duplicate try/catch blocks in your code, ensuring that error messages don't leak critical data, and carefullty testing and verifying error handling code.

The motivation challenge

OWASP's Proactive Controls can provide concrete practical guidance to help developers build secure software, but getting developers motivated to write secure code can be challenging. For more tips on how to address this challenge, drop in on Adhiran Thirmal's session, "How to Win Over that Elusive Developer," at the upcoming SecureGuild online conference

The SecureGuild online conference covers a wide variety of security testing topic, and runs from May 20 to 21.

 

Keep learning

Read more articles about: SecurityApplication Security