A risk assessment has been completed for the current version of the application and appropriate measures have been taken to secure the application. Application supports SSL v3 and/or TLS v1.2, with 256-bit minimum encryption, for all communications interfaces. The application validates all user input and does not provide trust of submitted or presented data.
The application provides for extensive and configurable assessment and logging functionality. Sensitive information and transactions are not logged in clear text. The application is able to manage normal and abnormal termination. The application ensures the integrity of data both stored and transmitted. Standard cryptographic APIs are used for cryptographic processing, and industry standard encryption algorithms are used.
Encryption keys are of appropriate length to meet security requirements: Symmetric keys are at least 256-bits. Asymmetric public/private key pairs are 2048-bits. The application provides a mechanism to detect and lock unauthorized access to cryptographic keys. All access from the application to the database is restricted as appropriate and allows for only the least amount of functionality required to accomplish tasks. The application provides a mechanism to disable user accounts after three (3) login failures. The application provides a mechanism to log all access by users to confidential information. The application provides for modularity and the ability to be segmented into three logical layers (Presentation Layer, Business Logic, and Data Layer). There is a strong segregation between individuals involved in development, testing, and production. Processes and procedures are in place to ensure software changes are controlled and assessed. A software revision control system is used to ensure only authorized individuals are allowed to modify the code base. Processes and procedures are defined to assure for standardized testing procedures. Testing includes cases for malicious data input, abnormal session termination, modified cookies, incomplete data input, malformed requests, missing data fields, malicious URL modification, and other types of unexpected or potentially malicious activity. Applications utilize prepared SQL statements to minimize the risk of SQL injection.
Movere is based on the entity framework which consists of a data model and a set of design and run-time services that isolate the website from the underlying logical database schema. Outside parties cannot see the Movere data structure and there is no ability to query SQL directly from the outside.
What development languages is Movere implemented in?
What are the physical and logical tiers of Movere?
The physical tier is managed by Azure.
The virtual tier has 6 logical tiers including:
- Web: This involves our Web services (https://go.movere.io), load balanced n+1 architecture. Traffic allowed only via HTTPS. Initial HTTP request is redirected to HTTPS.
- APIs: Authentication API responsible for token validation; FileTransfer API responsible for allowing customers to download the Movere Console, rescan files and upload resulting inventory/ARC data from the console; Web API that allows customers to submit data overrides via website. All 3 APIs allow only secure traffic in/out via HTTPS. Load balanced n+1 architecture.
- Data brokerage. Internal facing. Custom code.
- Data processing. Internal facing. Custom code + SQL Server.
- Data Storage. Internal facing. Custom code + SQL Server + Azure DocumentDB.
- External facing. Custom code + Qlik Sense Server. HTTPS + WebSockets.
Are any state and session tracking mechanisms used by Movere?
Movere uses four (4) cookies for session maintenance on the website. All sessions are kept alive for 24 hours after which the user is automatically logged-off. If the user chooses to log-off manually, the session cookies are immediately deleted. 1 cookie is issued by the Web API for session state, 1 cookie is issued by the Authentication API and serves as a bearer token, and 2 cookies are issued by Qlik and provide authentication to the Qlik service.
What input validation functions are performed Movere?
All customer forms are validated using input masks (i.e. phone number by country codes), and fields cannot be left blank.
What specific application vulnerability tests are performed on Movere and when the last assessment was performed (e.g. for OWASP vulnerabilities, patching status, SSL status, etc.)?
Movere is tested monthly using a Web Application Vulnerability Scan. Latest report is available upon request.