1 Security overview

• OWASP top ten security vulnerabilities for 2017
  
• Security awareness and education
  
• The risk associated with build-your-own
  
• Other aspects of security
  

OWASP top ten security vulnerabilities for 2017

To guide developers on what they need to protect against, the Open Web Application Security Project (OWASP) publishes a document that lists the ten most critical security vulnerabilities identified for the year. Addressing these ten security vulnerabilities does not provide for total security, but is a good start in raising awareness on the current major security threats.

This document explains how the Oracle Clinical One Platform API addresses security vulnerabilities, identifies the controls within the Oracle Clinical One Platform API that are used or may be used to address the associated risks, and describes how API developers should address security vulnerabilities and risks documented by OWASP for 2017.

In some cases, the controls are coded into the product and proper use of the controls by API developers is necessary to validate the integrity of the controls. Developers using the Oracle Clinical One Platform API should use this document along with the Oracle Cloud SaaS Security Practices (download link available for registered users in the Oracle Cloud Operations Center on My Oracle Support, Doc ID 1541346.2) to identify the necessary security controls to maintain the risk posture of the API interface while integrating with Oracle Clinical One Platform.

Security awareness and education

The best application security that money can buy is education. Developers and project leads must be mindful of potential security issues and have an understanding of secure coding practices. Training must include an in-depth explanation of the potential risks, as well as features of the development and deployment platforms that help mitigate exploits.

The most important design principle for application security is to implement security by design and default. Secure coding guidelines should be made available, adhered to, and enforced in all development organizations, irrespective of the tools and platforms being used.

A good example of security by default is the expectation that we all have for how elevators behave in case of a power outage. Instead of releasing the brakes, we expect elevators to apply the brakes for the safety of passengers in the cabin. But how would the elevator know that it should apply the brakes if no one defined this as the default behavior? So before thinking about how to prevent external attacks, it makes sense to identify secure defaults for an application to protect it from the inside. This, however, does not work well without training and awareness.

The risk associated with build-your-own

Developers don't always find the security they need for an application within the security toolset provided by a platform or built into a framework. As a result, build-your-own-security is not uncommon among development projects. This is especially true if the application is a replacement of an existing system that uses a specific non-standard security infrastructure. An example for this is database-table-based authentication and authorization in combination with user provisioning and resource granting at runtime.

The risk associated with building your own security is that you are also on your own when it comes to quality assurance of the security layer, application security propagation, and single sign-on; and you are responsible for bug fixing and maintenance of the security layer.

Not all developers are security experts, but experts are what it takes to build a custom security layer.

Time spent investigating existing, well-vetted security solutions is probably time well spent. Existing solutions can be applied to custom applications more easily and more cost-effectively than creating an error-prone, self-written mechanism.

Other aspects of security

Application security is useless if the application itself runs in an insecure environment. Perimeter security describes the levels of protection that are added on servers, the network, and other data access channels outside of the API domain. As can be seen in this document, not all of the OWASP top ten security vulnerabilities documented for 2017 are relevant for application developers for specific implementations.