IT Requirements for 3rd Party Vendor Packages



Updated: 10/25/2019Any deviation from the IT recommendations listed in this document must be approved by the Division of Information Technology.Technical RequirementsTechnical DocumentsThe vendor shall provide a document of the complete system architecture.This shall include all plugins, batch processes, worker processes, and so on.The vendor shall provide a diagram of the database schema:This shall include the core product database schema and interfaces with various external and ODOT systems and databases, API’s, and standard integration methods.The vendor will provide accurate installation and configuration document for the system software and database schema.The vendor will provide a complete network diagram.Server RequirementsWindows 2016 or newer – IIS 10Must use currently supported products and tools (i.e., 3rd Party components and dependencies).System shall support server virtualization.System must be capable of functioning with F5 Big IP Load Balancers. 1.3 Document StorageDocuments will not be stored directly on webservers or application servers.1.4 Authentication & Authorization Active Directory and LDAPS (Secure LDAP) is the preferred authentication protocol. The system shall be able to access multiple Active Directory domains and forests.The system must support role-based authorization, (e.g., groups of users with unique access and privileges). 1.5 System SecurityThe system must pass an ODOT security scan which reports potential security threats and vulnerabilities within web software. Vendor shall follow OWASP secure code practices.DatabaseThe system shall use Oracle 12c or SQL Server 2016 or newer.Client-Side SoftwareThe system will be compatible with Microsoft’s Internet Explorer 11.Plug-ins are discouraged but will be subject to ODOT’s approval.Any page which passes or grants access to confidential or secure data should use SSL encryption. No Java installs will be supported at the client level.Client-side software shall not require administrative rights.Coding RequirementsGeneralAll URLs/ Links/ Paths/ Database Connection Strings the system uses should not be hard coded and must be configurable.Sensitive information like usernames, passwords etc if being stored must be encrypted.Database constraints should be employed to ensure data integrity.SQL statements must be parameterized.All efforts must be made to build a performant solution. Not limited to using database indexes, normalized tables, avoid unnecessary joins etc.Must be willing to try and implement / provide alternate solutions if the performance is not reasonable to ODOT.Any additional software libraries / components that require licensing will be subject to ODOT approval.Application will need to pass regular ZAP scans to be acceptedAll attempts must be made to avoid the use of database cursors. Use of database cursors is discouraged and will be subject to ODOT approval.? Coding changes necessary to make the solution work in ODOT’s environment will be the vendor’s responsibility.Logging GuidelinesThe solution should generate application logs using logging frameworks that allow logging level configuration (DEBUG/INFO/WARN/ERROR/FATAL). System should carry logging to the extent that it will facilitate troubleshooting. For example, exceptions must be logged with full stack trace.Things to consider while logging, but not limited toFailure to connect to resources that are essential for the app to function must be logged as FATALConnectivity issuesFile system errorsAny exception throughout the application must be logged?as ERROR Authorization failuresSession management failuresApplication errors / runtime errorsAnything that warrants the attention of support personnel must be logged as WARNAuthentication failures (access denial, cross site scripting attack etc)Application configuration changesInput / business validation failuresAnything that will be helpful in the troubleshooting an issue – must be logged as DEBUG/INFOApplication and related services start-ups and shut-downsLogging initializationClient request parameters if not sensitive information.Things Not To log Access tokensSensitive data (Password, Credit Card, SSN, etc)ODOT Assuming OwnershipThe solution should align with ODOT’s technology stack - .NET Core 2.1 or newer / .NET Framework 4.7 or newer / C# / Angular / ExtJS / jQuery / Bootstrap / Log4NetMust provide all source code.Source code will be subject to code review. While ODOT will try to be reasonable, must be willing to make necessary changes if ODOT finds the code to be unacceptable.There should be a separation of layers. Coding conventions and best practices should be followed. Code should be reasonably commented.Functioning unit tests and test cases should be provided.Source code should follow OWASP best practices related to security and vulnerabilities (i.e. ). Excessive business logic in stored procedures is discouraged and will be subject to ODOT approval.Use of database triggers is discouraged and will be subject to ODOT approval.MobileHardwareWirelessMust be capable of supporting WIFI/WWAN(cellular) natively or by interface with third-party deviceGPSMust be capable of supporting GPS, natively or by interface with third-party deviceUpdatesCannot be required to sync for updates/upgrades via physical workstationSecurityBIOSBIOS must be persistentBIOS must be able to be password protected TPM chip must be integratedTPM must be capable of being controlled by the device OSIntel vProMust be Intel vPro compliantComputraceHardware must be Computrace compatibleEncryptionHard Drive(s) must be capable of encryptionOperating SystemsWindows Operating SystemMust support Windows 10 EnterpriseMobile OSAndroid, Apple iOS, MAC OSXMust be compatible with a MDM Solution i.e. VMWare AirwatchSecurityAny operating system cannot synchronize data to any cloud service which stores data outside the United StatesMust have support for the State of Ohio approved Antivirus solution and be enabledUpdatesAny OS should be fully capable of consuming latest OS available updates at any time without disruption to the application.? Mobile ApplicationApplication must employ a centralized method for deployment and updatesMethod can be provided via app vendor or ODOT approved third-party applicationIf the application requires login the following requirements must be metMicrosoft Active Directory authentication must be supportedCredentials must be encrypted in transmission, and never stored in clear-text on deviceApplication must be capable of functioning in tandem with Mobile Device Management (MDM) clientApplication must be capable of functioning in tandem with antivirus clientCannot synchronize data to any cloud service which stores data outside of the United StatesGeneral Device RequirementsWireless encryption must support at minimum WPA2 PSK with 256 bit AES encryptionMust support secure device access method (password, PIN, or biometric authentication)Device must support remote wipe capabilities ................
................

In order to avoid copyright disputes, this page is only a partial summary.

Google Online Preview   Download