Secure by Design is increasingly becoming a mainstream development approach that ensures the security and privacy of software systems.
The core premise is that software has been designed from the foundation to be secure. Security best practices are enforced by the architecture design and then used as guiding principles for developers.
Secure by Design
Secure by design, in software engineering, means that the software has been designed from the foundation to be secure.
Secure by Design is increasingly becoming a mainstream development approach that ensures the security and privacy of software systems. The core premise is that software has been designed from the foundation to be secure. Security best practices are enforced by the architecture design and then used as guiding principles for developers.
With the Secure by Design approach, security is built into systems from the ground up and starts with robust architecture design. Security architectural design decisions are often based on well-known security tactics, and patterns defined as reusable techniques for achieving specific quality concerns. Security tactics/patterns provide solutions for enforcing the necessary authentication, authorization, confidentiality, data integrity, privacy, accountability, availability, safety, and non-repudiation requirements, even when the system is under attack.
Omniscien products are built around and designed the following 3 core pillars of information security in mind:
- Confidentiality – only allow access to data for which the user is permitted
- Integrity – ensure data is not tampered or altered by unauthorized users
- Availability – ensure systems and data are available to authorized users when they need it
Secure Architecture and Design Principles
Omniscien products are built upon an application security and information architecture that is designed to cover all kinds of risks, ranging from typical usage risks (accidental data erasure) through to extreme attacks (brute force attacks, injection attacks etc.).
To significantly reduce risks of successful attacks, the Omniscien team follows specific security by design principles created by the Open Web Application Security Project (OWASP). These principles ensure that their application is secure down to its foundation. Learn more about the OWASP Security by Design Principles in the Threatpress Blog.
Many of the features and principles that are part of the Secure by Design philosophy also align with government regulations such as GDPR. All Omniscien products are designed with compliance to standards and regulations in mind.
While there are different security requirements depending on your deployment model for each Omniscien product the core principles of the Secure by Design philosophy have been applied throughout in an appropriate manner for each deployment model.
Beyond software, many of the techniques, technologies and processes that are utilized by the Omniscien team and in our products are based around industry recognized best practices.
Security Best Practices , Techniques, Technologies and Processes
Omniscien products use a variety of techniques and technologies to ensure that systems are deployed and remain secure. The below list provides examples of just some of those the techniques and technologies used.
Secure and Private
- Install in your office/data-center or Cloud infrastructure providers such as AWS, Google, Azure, SAP, Oracle, IBM, etc.
- Data never leaves your organizational control
GDPR Compliant
- Designed to support and help organizations enforce GDPR within the organization.
- Data is processed an immediately deleted.
- Only minimal information necessary for system use is retained.
Encryption
- All communciations are via SSL.
- On premises and private cloud deployments can apply their own SSL certificates.
- All data is stored on disk using 256-bit AES encryption.
- All sensitive data stored in databases is stored using 256-bit AES encryption
CIS Hardened Docker Containers
- On-premises or private cloud software shipped as Docker Containers
- All Docker Containers are hardened to Center for Internet Security (CIS) standards
- Docker containers are updated frequently with the latest security patches and software updates.
Data Shredding
- Data deleted using the United States Department of Defense (DoD) 5220.22-M Data Wiping Standard
- Even if an attacker gained physical access to the hardware data can never be recovered.
- The digital equivalent to a paper shredder.
Authentication
- On-premises and private cloud deployments can be configured to authenticate via LDAP, OAuth-2, or SAML 2.
- REST API access is authenticated by user-managed security keys.
Security Principles of the Secure by Design Philosophy
The principles of Secure by Design are followed during the development, testing, and deployment of Omniscien products. The 10 principles listed below cover many of the most important concepts and explain them in simple terms. Examples are provided from within the context of Omniscien products and how these principles are applied. These examples are not exhaustive and are intended to illustrate how they are applied within every part of our product development lifecycle.
Establish Secure Defaults
Applications should limit access to resources by default. For a user to gain more access, they must obtain privileges that give them access to the resource or features. Applications using this principle prevent unauthorized users from having access to certain resources — making the application secure by default.
Omniscien Product Example
All Omniscien products have all features disabled for users by default. A user must be explicitly granted a role or a permission prior to being able to access functionality and features.
Minimize Attack Surface Area
Every application has features that serve as possible entry points for security breaches. For every feature added to an application, the attack surface area is expanded, making it more vulnerable to security attacks. Minimizing the attack surface area reduces the entry points to the system for unauthorized users.
Omniscien Product Example
Omniscien products have a single public REST API, irrespective of the functionality of the REST call. The type of functionality is determined in the REST API header. By having a single REST API, only a single URL part need be exposed to the outside world which can be more easily secured. A single REST API minimizes the attack surface area to just 1 URL.
Fail Securely
Applications fail for a variety of reasons ranging from hardware and network to software bugs and many other issues. Whatever the reason for failure, sensitive user information, and system errors should not be exposed to users or attackers when something fails. Limited information should be shown to users when an error occurs.
Omniscien Product Example
If a password is incorrect when a user is logging in, the system states that the login credentials are incorrect without specifying whether the username or the password is the incorrect parameter. Confirming that the username is correct makes it easier for an attacker to hack into an account.
When a technical error occurs, sufficient detail for audits and debugging are written to secure log files, with only a minimal amount of non-specific information being exposed to the user describing the issue that was encountered. For example, “An error occurred writing the transaction to the database.”
Establish In-Depth Defense
Applications should not rely on just a single security control. The in-depth defense principle states that multiple security controls make attacks less successful due to layers of authorization verifications. A single layer of defense is not enough to protect your data from attackers. Multiple layers are required to secure vulnerabilities and make it difficult to exploit sensitive information.
Omniscien Product Example
After authentication, each organization’s data is stored and structured so that it is segmented by organization. Code is designed so that it cannot cross organizational boundaries.
Simply logging in successfully as a user does not provide access to data or account information. Each activity requires independent permissions and authentication.
Network architecture is layered so that even if a hacker was able to break into a front-line web server they would not have access to other servers or databases where sensitive user data is stored.
Should an attacker somehow obtain physical access to the hardware, they are not able to access the data as it is stored in an encrypted format using 256-bit AES encryption.
Separate Privileges
Separation of privileges means that individuals must have distinct roles within an application. High ranking roles are not able to perform lower ranking tasks. A system administrator cannot perform the actions of a standard user and cannot be demoted to a standard user. Likewise, a standard user cannot have additional permissions and roles that are relevant to a system administrator and cannot be promoted from a standard user to a system administrator. This is to prevent fraudulent activities from happening on the application.
Omniscien Product Example
When a user is created it is assigned a role. That role is permanent and cannot be changed. This limits the tasks that a user can perform to only those associated with a specific role.
For example, a user with the system administrator role is only to configure the system. They cannot access features that would add a purchase to a customer’s account.
Lessen Privileges
Users should start with a minimum number of privileges granted to them. These privileges can only allow them to perform their tasks within an application and a role assigned to them. More often than not, users don’t need additional privileges to perform their tasks. If they need more access, it has to be granted to them by administrators.
Omniscien Product Example
When a user is created, they are assigned the appropriate role and are provided with the minimum privileges and permissions needed for their role. A series of permission granting steps are performed in order to assign new privileges.
Minimize Third-Party Access
Applications often utilize services of third-parties for additional functionality. External parties will have their own security measures that may or may not be more secure than your own.
Giving these external parties access within the application makes it vulnerable to cybercriminals who might gain access through their end. If third-party services return or provide data, it’s a wise option to first check the validity of the data before utilizing it.
Omniscien Product Example
Omniscien products can integrate many third-party services that are out of our control. Our systems are architected to call out to these systems as the primary method of data exchange.
For example, we use voice recognition technology from AWS, Google, Microsoft, and others (in addition our own voice technologies) . None of these third-parties have access to the internals or any features of Omniscien products. Omniscien products call these products APIs as and when needed. When the response data is received, it is validated and then normalized into Omniscien’s own internal formats for further processing.
Many third-parties also access Omniscien products in both the cloud and on-premises deployments. All access to features and data is provided via standard interfaces such as REST APIs and job queue submissions. No direct access to file systems and storage is provided.
Keep Security Simple
Contrary to popular belief, simple application security is better than complex security design approaches. Complex systems are hard to debug and correct. When an error occurs Complexity can cause time-consuming delays that cybercriminals can take advantage of.
Omniscien Product Example
Omniscien software follows best practices for network architecture, firewalls, and applications. Each part of the system is layered based on functionality and purpose. By design, the internal storage systems are not directly connected to the public internet. Access to data is achieved via authenticated processes in software at other layers of the network and application. This simple architecture ensures that access is restricted by default and only permitted by secondary application authentication and protocols which in turn are also simple and easy to trace and debug.
Within each user role is a set of clearly defined permissions. No other functions are available to a user. They either have the permission as permitted in their restricted role or do not have the permission. This ensures that controlling access is simple from an administrative perspective and also from a technical perspective in the event of an issue that needs to be traced.
Avoid Security by Obscurity
Security by obscurity should never be relied upon. Secret and hidden URLs for administration and other functions are not secure at all. There should be sufficient security controls in place in every part of the application to ensure security without the need to hide access points.
Omniscien Product Example
All interfaces into Omnscien products are fully documented. There are no back doors or secret URLs. When administration features are required the administrator is authenticated using appropriate security and authentication with full logging and activity tracking.
Fix Security Issues Correctly
If a security issue has been identified in an application, server, or product, engineers should determine the root cause of the problem and the total impact. All impacted systems must be identified and the issue addressed on the entire platform. They should then repair it and test the repairs thoroughly.
Omniscien Product Example
The Omniscien team uses a comprehensive project management and issue tracking system. In the event of a security or technical issue, incident reports are created that track every aspect of the issue through to its complete resolution. In some cases there may be a quick fix to reduce the risk or impact. A complete fix is always applied as quickly as possible.