Vendor and Client Security Requirements
NOTE: The term “Vendor” or “Vendors” refers to any outside entity providing information or technology to the State of South Dakota.
IMPORTANT: In conjunction with the below information, vendors who are actively pursuing IT business opportunities with the State of South Dakota must also comply with the Information Technology Security Policy. For security purposes, this content is not for public consumption and must be requested prior to signing an IT contractual agreement with the State of South Dakota. To obtain a copy of this policy, please call 605.773.4357 or email the BIT Help Desk.
All actions deemed necessary by the state, to protect state information from exploits, inappropriate alterations, access or release, and malicious actor attacks must be taken. During all phases of a project, assistance will be provided by the vendor or entity providing or supporting the project and its associated technology components to the State of South Dakota in performing an investigation to determine the nature of any security issues discovered or reasonably suspected. State access to source code will be allowed to ensure BIT security standards, policies, and best practices are followed. Vendors will make a reasonable effort to ensure third party software is as secure as custom developed code developed by the vendor or entity.
When a vendor signs a contract that includes hosting any state data that may be confidential, private, financially sensitive, or contain personally identifiable information, the vendor will be agreeing to either:
1. Allowing the state, at the vendor’s expense, twice annually, to require a security audit and vulnerability assessment to provide third party verification of the vendor’s IT security safeguards for the system and its data. At its request the state may review any and all independent audit reports that document the system’s security posture and/or that of the company and its policies and procedures. This security audit and vulnerability assessment must come from an industry recognized third party source agreed to in advance by the state.
2. Allowing the state, at the state’s expense, to perform up to two security audit and vulnerability assessments per year to provide verification of the vendor’s IT security safeguards for the system and its data. The state will work with the vendor to arrange the audits and assessments at a time least likely to create work load issues for the vendor and will accept scanning a test or UAT environment on which the code and systems are a mirror image of the production one rather than requiring a direct scan of the production environment.
In either case the vendor agrees to work with the state to rectify any serious security issues the security audit or vulnerability assessments reveal. This includes additional security audits and vulnerability assessments that may be performed after any remediation efforts to confirm the serious security issues have been resolved and no further serious security issues exist. It is required that any scans must meet the requirements of the Payment Card Industry Data Security Standard (PCI DSS) irrespective of there being any PCI DSS data involved.
This is a state standard and is part of any contract signed by a vendor were state data that may be confidential, private, financially sensitive, or contain personally identifiable information or is to be hosted by the vendor, this standard applies whether or not it is so stated in the contract.
For all web applications, the state will perform security scanning using industry standard practices. The state may perform such scanning any time the state deems there is reasonable cause based on the changing threat landscape and/or when changes have been made that may affect the system’s security or performance; regardless of the nature of the changes.
The vendor will fully support and maintain the vendor’s application on platforms and code bases still being supported, maintained, and patched by the applicable third parties owning them. The vendor may not withhold support from the state for their product nor charge the state additional fees as a result of the state moving the vendor’s product to a new release of third party technology if:
- The previous version of the third party code base or platform is no longer being maintained, patched, and supported; and
- The new version to which the state moved the product is actively maintained, patched, and supported.
If a code base or platform on which the vendor’s application depends is no longer supported, maintained, or patched by a qualified third party, the vendor will move its application from that code base and/or platform to one that is supported, maintained, and patched after the state has performed a risk assessment using industry standard tools and methods.
The vendor shall use the highest applicable industry standards for sound secure software development practices to resolve critical security issues as quickly as possible. These standards include, but are not limited to the South Dakota Application Security Vulnerabilities document.
The "highest applicable industry standards" shall also be defined as the degree of care, skill, efficiency, and diligence that a prudent person possessing technical expertise in the subject area and acting in a like capacity would exercise in similar circumstances.
The state applies security patches and security updates as needed to maintain compliance with industry best practices as well as state and federal audit requirements. Vendors who do business with the state must also keep up with industry security practices and requirements. Vendors must include costs and time needs in their proposals and project plans to assure they can keep up with all security needs throughout the life-cycle of a project. The state will work in good faith with vendors to help them understand and support state security requirements during all phases of a project’s lifecycle, but will not assume the costs to mitigate applications or processes that fail to meet then-current security requirements.
At the state’s discretion, security scanning will be performed and or security settings put in place or altered during the software development phase and during pre-production review. It is required that any scans must meet the requirements of the PCI DSS irrespective of there being any PCI DSS data involved. These scans and tests, initially applied to development and test environments, can be time consuming and should be allowed for in project planning documents and schedules. Products not meeting BIT’s security and performance requirements will not be allowed into production and will be barred from User Acceptance Testing (UAT) until all issues are addressed to the state’s satisfaction. The discovery of security issues during UAT are automatically grounds for non-acceptance of a product even if a product meets all other acceptance criteria. Any security issues discovered during UAT that require product changes will not be considered a project change chargeable to the state. The state urges the use of industry scanning/testing tools and secure development methods be employed to avoid unexpected costs and project delays. Costs to produce and deliver secure and reliable applications are the responsibility of the software entity producing or delivering an application to the state. Unless expressly indicated in writing, the state assumes all price estimates and bids are for the delivery and support of applications and systems that will pass security and performance testing.
An application can be denied access to or removed from the production system at the state’s discretion.
Reasons for denial of access or removal of the application from production system may include, but is not limited to:
- unsupported third party technologies, or
- excessive resource consumption.
If this application is currently part of a contract process, at the discretion of the state, any contractual payments may be suspended while the application is denied access to or removed from the production system if the problem is caused by the vendor’s actions or inactions. Access to the production system and any updates to the production system will be made only with state’s prior approval. It is expected that any fixes will be tested on the test system provided by the vendor and not on the production system. It is expected that the vendor shall provide the state with proof of the fix proposed before the state provides access to the production system. The certification by the state of the fix on the test system does not guarantee the vendor access to the production system. The state shall sign a non-disclosure agreement with the vendor if revealing its fix will put the vendor’s intellectual property at risk. If the vendor is unable to produce the project deliverables due to actions or inactions within thirty days of the application’s denial of access or removal from the production system and the change management process is not used to alter the project schedule or deliverables then at the state’s discretion the contract may be terminated and a refund made by the vendor to the state of any contractual payments made to the vendor by the state.
Vendors are required to state their hourly rates for any additional work in any RFP bids and contracts for Commercial off the Shelf (COTS) products purchased by the State of South Dakota. These hourly rates can be used to require additional work by the vendor to bring an application in line with the state’s security requirements, meet the functional requirements established for the application, unsupported third party technologies or excessive resource consumption. This work can be made a requirement by the state for allowing the application to go into production. This additional work will not be considered a project change chargeable to the state if it is for these reasons. This work can be required by any of the state’s signatories to a contract.
Vendors and state agencies should be aware that they are required to have annual maintenance agreements for any COTS product purchased for the State of South Dakota. If a maintenance agreement is not present, then the state agency must have an active plan to:
- Upgrade the product.
- Migrate the functions to a product that does have a maintenance agreement or an active plan to upgrade the product.
- Retire the product with in the year.
In any case the state agency is required to have the product included in the Technology Roadmap. If you have questions, please contact your POC.
The State of South Dakota requires an acknowledgement from all service providers who possess or interact with credit card holder data that the service provider is committed to maintaining proper security of the credit card holder data in their possession annually. This acknowledgment shall include written proof from an authorized Payment Card Industry (PCI) compliant organization of an ongoing contract for PCI compliance testing and authorization services as well as a PCI scan provided by that PCI compliance testing and authorization service demonstrating current PCI compliance.
Movement of Product
The State of South Dakota operates a virtualized computing environment and retains the right to use industry standard hypervisor high availability, fail-over, and disaster recovery systems to move instances of any product(s) between the install sites defined in agreement with the vendor provided resource and usage restrictions are maintained. This movement of product can be done by the State of South Dakota without any additional fees or charges by the vendor. As part of normal operations the State of South Dakota may also install the product on different computers or servers if the product(s) is also removed from the previous computer or server provided resource and usage restrictions as agreed to by the State of South Dakota and the vendor are maintained. This movement of product(s) can be done by the State of South Dakota without any additional fees or charges by the vendor.
The State of South Dakota requires all contractors who write or modify State of South Dakota-owned software, alter hardware, configure software of state-owned technology resources, access to source code and/or protected-personally identifiable information or have access to secure areas to have background checks. These background checks must be fingerprint-based and performed by the State of South Dakota with support from our law enforcement resources. The state will supply the finger print cards and the procedure that is to be used to process the finger print cards. Individuals should plan on the background check taking two – four weeks.
The vendor will provide documentation and, at the discretion of the state, allow for on site inspections as needed to demonstrate all facilities supporting an application have adequate physical security.
The vendor will use industry standard and up-to-date security tools and technologies such as anti-virus protections and intrusion detection methods in providing services.
The vendor will, at their expense, either conduct or have conducted at least one of the following on an annual basis:
- A vulnerability scan (conducted by an industry standard scanner) of the vendor’s systems and facilities, used in any way to deliver services, with the results provided to the state at the state's request.
- A formal penetration test (conducted by an industry standard process) of the vendor’s systems and facilities, used in any way to deliver services, with the results provided to the state at the state's request.
Immediately upon becoming aware of a data compromise, or of circumstances that could have resulted in unauthorized access to, disclosure of, or any other inappropriate use of state or end user data, the vendor will notify the State of South Dakota, fully investigate the incident, and cooperate fully with the state’s investigation of, analysis of, and response to the incident. At the state’s option, the vendor will reimburse the State of South Dakota in full for all costs incurred by the state in investigation and remediation of such data compromise.
All access attempts, whether failed or successful, to any system connected to the hosted system which can impact the hosted system or its data or data integrity shall be logged by the vendor. Logs must be maintained not less than 7 years or as stipulated by the BIT client agency in a searchable, electronic format that is incapable of being modified. Access must be granted to the state to search those logs as needed to demonstrate compliance with state standards, and any and all audit requirements related to the hosted system.
Password policies for all vendor employees will be documented annually and provided to the state to assure adequate password protections are in place.
All state and end user data hosted by the vendor will be stored in facilities located in the United States of America at all times. This restriction also applies to disaster recovery; any disaster recovery plan must provide for data storage entirely within the United States of America.
Websites or applications developed for state agencies and hosted on the State of South Dakota infrastructure must meet the following minimum guidelines. The State of South Dakota reserves the right to perform security, load, vulnerability, PCI compliance, performance, and other scans and tests against any application supported by state funds at any time. Based on the results of these scans and tests, the state reserves the right to require fixes or adjustments be made either as part of ongoing maintenance contracts or before final payment is made for the application in question.
This content shall be part of (or referenced by) any contract or agreement that includes a web component
(websites or web application) made between a state agency and an outside vendor.
Vendor Contracted Websites and Web Applications
Many vendor developed websites and applications are hosted on the State of South Dakota’s infrastructure as soon as the website is complete or turned over to the state to host according to the contract agreement. It is important that all websites and applications be supported by the State of South Dakota using standard software and infrastructure adopted by the state.
All vendor contracted websites and applications must be evaluated to meet the basic set of web standards and must also function or operate properly on the state’s infrastructure. Once a site is submitted by the outside vendor, it will be uploaded to a testing area on the state’s infrastructure where it will be tested and reviewed. Testing contact names will be provided by BIT at the appropriate time. BIT staff will perform load testing, security and vulnerability testing and PCI compliance along with performance analysis testing as appropriate.
If the website or application meets these minimum web guidelines and all relevant project deliverables, it will be accepted by the State of South Dakota and moved into a UAT environment.
If it does not meet these minimum guidelines, the vendor will be notified of the deficiency. The vendor will make appropriate changes and will notify the state when the application can be re-tested to verify it meets the minimum guidelines as outlined above.
Mobile Applications Developed for the State
Any mobile application developed by a vendor or contractor for the State of South Dakota must meet certain minimum standards. Due to the rapidly changing mobile application operating system environment these standards may also change rapidly. If the vendor or contractor has a mobile application with a web component hosted by the vevndor or contractor BIT may for security reasons have to take the application down with little or no notice. If it is determined that the vendor or contractor was at fault a suspension of contract payments by the State of South Dakota may be made at the State’s discretion. If in the State of South Dakota’s opinion this was an egregious security failure on the vendor’s or contractor’s part then the State of South Dakota may at its option be reimbursed any payments made to the vendor or contractor by the State of South Dakota.
Any mobile application developed for the State of South Dakota must meet these requirements:
- Code reuse is only allowed as it is within the boundaries and guidelines of State Standards or modified to meet those standards.
- Encryption of data in transport and at rest using a mutually agreed upon encryption format.
- Application will close all connections and close at the end of processing.
- The documentation will be in grammatically complete text for each call and defined variables (No abbreviations and using complete sentences, for example)sufficient for a native speaker of English with average programming skills to determine the meaning and or intent of what is written without having prior knowledge of the application.
- No code not required for the functioning of the application