Encanvas aPaaS security blends industry-standard and proprietary mechanisms to keep your data secure
How we protect your data
Supports ISO 27001/2
We’ve walked through ISO 20071/2 requirements with a number of agencies and shaped Encanvas aPaaS to meet their applied policy governance frameworks. Tooling in the platform caters for the implementation of ISO 27002.
Discourages creation of shadow data
‘Shadow data’ is so called because it becomes invisible to the functions charged with managing data in the enterprise (normally the IT department). Shadow systems are small scale databases or spreadsheets developed and used by end users outside the direct control of an organization’s IT department.
Typically, these systems are developed on an as-needed basis, responding to new situations that demand new information. They are usually not tested, documented, or secured with the same diligence as formally engineered software solutions. Consequently, shadow systems have become the single biggest source of data security breaches.
Organizations can’t ignore the need to improve the robustness of data security in the office environment. Neither is it right to assume that employees will encrypt files on their memory sticks or hard drives.
Encanvas aPaaS encourages the use of database-powered digital document solutions, where data remains on secure web servers; displacing self-authored applications and the risk of shadow data emerging.
Reduces risk of external breach
The risk of external attack through websites is front of mind with security professionals, but this threat is surprisingly uncommon as a cause of data breaches. It is more likely for data seepage to occur through unknowing or unscrupulous employees or known contacts, due to their ease of access to data and assumed bond of trust.
The quality of web security has improved immensely in recent years, and whilst there is no 100% safeguard against hackers, the probability of risk from external web attack is reduced dramatically through the adoption of a modern Web Server platform, like Microsoft® Windows/IIS, that SSL encryption security protocol.
Encanvas aPaaS is architected on Microsoft® ASP.NET™ based technologies and fully leverages the security features built into Microsoft® IIS as a Web server deployment platform. Encanvas Web Server does not hold resources on the Microsoft® IIS Server.
Pages are created as they are requested and served directly to the requester, ensuring that no data relating to the delivered web page can be accessed by hackers.
Encanvas aPaaS includes modules for secure file transfer and storage. Encanvas Web Server inherits security mechanisms such as SSL and code access security from the Microsoft® .NET Framework.
- Secure Sockets Layer (SSL) is an industry standard security technology for creating an encrypted link between a web server and a browser. This link ensures that all data passed through remains private and integral. SSL is an industry standard and is used by millions of websites for protecting online transactions with their customers. In order to be able to generate an SSL link, a web server requires an SSL Certificate.
- Code access security helps protect computer systems from malicious code, allows code from an unknown source to run safely, and protects trusted code from intentionally or unintentionally compromising security. Encanvas Web Server inherits this mechanism from ASP.NET™ and uses it to control access to protected resources and operations.
Reduces cross-site scripting threats
This is the potential risk of Input forms being used to run malicious script. The solution is to validate user input, making safe the use of special characters and sequences.
Prevents canonicalization attacks
This refers to the use of malformed URLs to gain access to restricted files. The solution is to not make security decisions based on the filename and to validate all URLs accessed.
Encanvas aPaaS is programmed to produce ‘point and click’ building blocks that prevent false URLs being used in deployed apps. For this reason we discourage use of self-authoring scripting or coding but do not prohibit this functionality in the event that customers and partners install their own protocols to safeguard against the associated risk.
Impersonation presents a far-reaching threat for fraud and theft of company data assets, particularly in instances where the identity of an individual is determined only by a username and password. Encanvas can recommend various identity authentication methods at the request of customers.
Protects from SQL injection attacks
This is the use of Input forms to execute SQL queries on the database. The solution is to validate all user inputs and avoid dynamic SQL as much as possible.
Encanvas aPaaS offers point and click building blocks that prevent malicious scripts being used in deployed digital solutions.
Protects from Session-Based Impersonation
Sessions can cause problems as it’s possible to impersonate another user. Encanvas minimizes this risk by carefully marshaling the client-server relationship and interactions. It includes a strong built-in permissions architecture made possible by the inclusion of canvas technology.
How many times have users and systems accessed sensitive customer data this month? Which data sources are applications farming for data? How much of this data has been risk assessed? If IT and data security professionals can’t answer these questions, their corporate information assets probably aren’t safe. The web services revolution energizes growth and harnesses talent pools across and beyond the physical boundaries of the enterprise – but there’s always the risk that small-scale innovation can ultimately lead to large-scale risks.
We have a comprehensive set of administrative tools to govern data across all Encanvas authored applications serving data to users. It gives data security managers control over user and data consumption behaviors. Better still, Encanvas enables organizations to devolve responsibility for operational data to departmental managers who are made more accountable for their data usage behaviors (and are best placed to see potential security threats). This is made possible by giving department heads tools to specify security levels on specific data assets and to understand user behavior through rich data visualization.
A service’s endpoint identity is a value generated from the service Web Services Description Language (WSDL). This value, propagated to any client, is used to authenticate the service. After the client initiates a communication to an endpoint and the service authenticates itself to the client, the client compares the endpoint identity value with the actual value the endpoint authentication process returned. If they match, the client is assured it has contacted the expected service endpoint. This functions as a protection against phishing by preventing a client from being redirected to an endpoint hosted by a malicious service. The endpoint address for a service can be specified either imperatively using code or declaratively through configuration. Defining endpoints in code is usually not practical because the bindings and addresses for a deployed service are typically different from those used while the service is being developed. Generally, it is more practical to define service endpoints using configuration rather than code. Keeping the binding and addressing information out of the code allows them to change without having to recompile or redeploy the application.
Protects Data In Transit (Encryption)
Encanvas makes extensive use of encryption to protect data in transport from being intercepted. Unless specific preferences are requested by the customer we leverage the standard encryption technologies installed in Microsoft® ASP.NET™. Using ASP.NET™ it is possible to configure keys to use for encryption and decryption of forms authentication cookie data and view-state data, and for verification of out-of-process session state identification.
It is possible to specify the key used to validate encrypted data. Validation Key is used when enable View State MAC is true in order to create a message authentication code (MAC) to ensure that view state has not been tampered with. Validation Key is also used to generate out-of-process, application-specific session IDs to ensure that session state variables are isolated between sessions. The Isolate Apps modifier of the validation Key value indicates that ASP.NET™ generates a unique encrypted key for each application, using the application’s ID. Isolate Apps is included within the default value.
As Encanvas DX is deployed on the Microsoft Web Platform (particularly the .NET Framework), it adopts use of Kerberos. All the authentication protocols are exposed via SSPI.
Microsoft has adopted Kerberos 5 as the default protocol for its network authentication. Active Directory is merely the directory that holds the information. Kerberos protocol implementation is used to protect it and make it function.
The .NET Framework has a model for managing user or automated agent based on the notion of an Identity. The identity object encapsulates information about the user or entity being validated. Basic identity objects contain a name and an authentication type. The name can either be a user’s name or the name of a Windows account, while the authentication type can be either a supported logo protocol, Such as Kerberos VS, or a custom value. The .NET Framework defines a Generic Identity object that can be used for most custom logon scenarios and a more specialized Windows Identity object that can be used when application relies on Windows authentication. Additionally, own identity class can be defined that encapsulates customer user information.
ASP.NET™ implements authentication via authentication providers. Providers are basically Classes that contact Public Static Methods to help in authenticating requests from Clients. An ASP.NET™ Application can be configured to use one of the following Authentication Providers (these are exposed to Encanvas systems administrators either within the IIS management application or via the Web Server Manager administrative cockpit).
1. Windows Authentication
The Windows Authentication Module provider relies on IIS to provide authenticated users. The provider module constructs a Windows Identity object. The default implementation constructs a Windows Principal object and attaches it to the application context. One of the major advantages of Windows Authentication is to allow implementation of an impersonation scheme.
2. Forms Authentication
This is recommended if the application needs to collect its own user credentials at logon time through HTML forms. All other unauthorized requests are redirected to the logon page using HTTP client-side redirection. Forms authentication provider may implement custom logic for validating username and password against identity store. If the application authenticates the request, the system issues a ticket that contains a key for reestablishing the identity for subsequent requests.
Encanvas makes use of the versatility of these options to provide organizations with the ability to produce federated identity management structures that may consume standard services such as Active Directory, merge them with other directory services, or create completely new identity management structures using the tooling provided by Encanvas DX that leverages optimal value from the authentication methods the .NET Framework provides.
Encanvas deployed applications will normally adopt the Forms authentication approach as outlined above to create personalizable logon forms. However, given that the platform resides on the Microsoft Web Platform, it has the option to use Windows Authentication when required.
Federated Security and SSO
Our Approach to SSO
Encanvas DX can be configured to provide Single Sign-On (SSO), implemented in one of two ways:
1. The Intranet Solution
A unique, one-time-use token is generated when a user clicks on the application they want to run. This token and the user’s identity get stored in another database table. The token is then passed to a special page (via the query line) in the web app the user wants to run. This page will read this token from the query line and verify its existence in the database table. If the token exists, it retrieves the login ID from the database and deletes the record where this token was stored. This prohibits anyone else from reusing the token and sends the login ID back to the web app. Now that you have the user’s identity within this app, you need to generate an ASP.NET™ forms authentication ticket since all web app in your intranet will use forms-based authentication. This ticket will then be used by the user who is navigating through all of the secure pages on this site.
2. The Extranet Solution
External users (people not in your domain) who want to visit your web application are directed to a different start page than internal users. The Web application that both internal and external users are directed to is secured with forms-based authentication. When an external user attempts to navigate to any page within it, they are automatically redirected to a login page. This login page is different from the one the internal users are authenticated by. Once the user enters their credentials, a call to the same database is made to determine if the user is valid for this application. Once approved, the normal forms-based authentication cookie is generated for their session.
As organizations extend their collaborations and processes beyond the boundaries of their enterprise, an identity management approach that’s able to flex and take into account differing needs becomes essential. Encanvas DX works with and protects existing technology investments. It allows enterprises to manage the end-to-end lifecycle of user identities across all enterprise resources consumed by Encanvas users, both within and beyond the firewall. The system does not attempt to ‘lock out’ or take privileges away from users. Instead, it enables security managers to specify security for each and every workspace, workgroup, role, and user without creating a burden on managers.
A role defines a set of permissions (Read, Write, Delete, Admin). The role defines their level of access and authority to use Encanvas software modules. There are 4 main privilege levels of user role:
Level 1. Administrator – Describes the role responsible for installing and administering Encanvas Administrators (normally an individual responsible for ICT or network infrastructure) determine user privileges and the level of access to Encanvas modules appropriate for users. Administrators can configure the operation of Encanvas modules to harmonize the operation of Encanvas to suit organizational procedures (e.g. the ability to pre-determine levels of access to organizational databases etc.).
Level 2. Author – Describes the role of users that are able to author, read and edit Canvases. Authors have access to Encanvas Create, unlike Contributors who do not.
Level 3. Contributor – Describes the role of users that are able to read and use canvases. A Contributor is responsible for contributing information for processes using canvases on web-browser, personal desktop, laptop, tablet, or smartphone device platforms.
Level 4. Viewer – Viewer have the authority to read canvases but not edit them. Each user is assigned a set of permissions that identify portal access, views and the actions they can perform. User permissions may be inherited from Microsoft Active Directory and controlled by Encanvas. Users are added and assigned to a role at one web page or web page group within the portal for all sub-pages. Therefore, a user will have the same permissions on all the sub-pages. Administrators can modify the web page creation process so that each web page uses unique permissions. Unique permissions enable the management of users and groups separately from the top-level portal.
A table of groups is created in SQL
A table of users is created in SQL or can be inherited from Active Directory (or other data sources).
As canvases are created, they are assigned to a Group. This data is also held in SQL.
Authorization determines if an identity should be granted access to a specific resource. In ASP.NET™, there are two ways to authorize access to a given resource:
File authorization – File authorization is performed by the File Authorization Module. It checks the access control list (ACL) of the .aspx or .asmx handler file to determine whether a user should have access to the file. ACL permissions are verified for the user’s Windows identity (if Windows authentication is enabled) or for the Windows identity of the ASP.NET™ process. For more information, see ASP.NET™ Impersonation.
URL authorization – URL authorization is performed by the URL Authorization Module, which maps users and roles to URLs in ASP.NET™ applications. This module can be used to selectively allow or deny access to arbitrary parts of an application (typically directories) for specific users or roles.
Encanvas has been designed to deliver human-readable log files covering all aspects of systems operations including the recording of:
- Web Server uptime and availability
- Web Service events
- Microsoft Web Platform service continuity (ASP.NET™, IIS, SQL Server)
- User login and behaviors
- Deployed Remote[Space] site events
- Data read/write errors
- Data source errors
- Click tracking and site visitor behaviors
Customers can create reports and log files for their own applications using the self-service report design tools provided. From a systems admin perspective, logs are captured on the Web Server and reported via an encrypted TCP/IP service; presented through the Remote(Spaces) Client module.
Using the fine-grained recording and reporting possibilities of Encanvas, organizations are able to develop full user behavior traceability. This functionality is being used in various industries to formalize process and policy, manage productivity, prevent errors, monitor compliance, and expose corruption.
Is your aPaaS safe for data?
Read our article on aPaaS security to consider whether your present system is up to the task of protecting business-critical processes from attack.
Take cybersecurity safeguarding to the next level.