SGS MA_Final_Part6.pdf

Commonwealth of Massachusetts

Vehicle Inspection and Maintenance Program

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-161 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-162 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-163 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-164 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-165 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-166 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-167 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-168 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-169 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-170 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-171 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-172 April 7, 2016

This page is intentionally left blank.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-173 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-174 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-175 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-176 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-177 April 7, 2016

IPCM VPAT 10.3.10

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-178 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-179 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-180 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-181 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-182 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-183 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-184 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-185 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-186 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-187 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-188 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-189 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-190 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-191 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-192 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-193 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-194 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-195 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-196 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-197 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-198 April 7, 2016

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-199 April 7, 2016

10.4 SECURITY PLAN

As successful bidder and partner with the Agencies, SGS affirms our responsibility for administration of the infrastructure, implementing or maintaining security and the protection of the confidentiality, integrity, and availability of information systems or processes. SGS will provide more details as requested and will work with the Agencies as necessary to implement further security mechanisms as part of the refinement of our proposed Security Plan for final approval by the Agencies (beyond the requirements set forth in the RFR Attachment), that will ensure the ongoing security of the Database throughout the Contract term, including, if applicable, all Contract extensions.

Part I 10.4.1

General Requirements 10.4.1.1

10.4.1.1.1 Administrative, Physical, Technical and Systems Controls to be used by the System, including the Database

SGS meets the Agencies’ stringent security requirements for administrative, physical, technical, and systems controls used in the Program, as described in this Security Plan overview.

10.4.1.1.2 Contact Information of SGS Security Manager

The SGS IT Operations Manager, Chris Marlow, also serves as the Security Manager on the

Program. His contact information is:

Office Phone: 518-245-8084

Mobile Phone: 518-275-1003

Fax: 518-580-2320

E-mail: christopher.marlow@sgs.com

10.4.1.1.3 Identity, Contact Information, and All Pertinent Details Subcontractors involved in

Implementation of the Security Plan

No SGS subcontractors are involved in the implementation of the Security Plan

Physical Security 10.4.1.2

10.4.1.2.1 Equipment and Software Inventory Process

The SGS Corporate Security Policy for Infrastructure Components states the following:

Installation of new, changes to existing or removal of hosted hardware infrastructure components or facilities, into or from Computer Rooms, are tracked, then tested or qualified, according to appropriate SOPs.

mailto:christopher.marlow@sgs.com

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-200 April 7, 2016

The inventory is maintained by the IT Infrastructure & Services department, and contains at least following information:

Reference/Name

Building

Logical content

Responsibilities (through the IT Matrix)

SGS adheres to the Corporate Policy by executing Change Management process as illustrated below.

Figure 10.4-1: Change Management Process

SGS leverages its Configuration Management Plan in concert with change management to administer and monitor configuration revisions.

A complete inventory of all the systems and components for the Program is maintained in the

SGS Configuration Management Library (CM Library). The CM Library contains each system component, its redundancy, and specific details (model number, circuit ID, configuration information, etc.).

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-201 April 7, 2016

In the event of a major change to the system or application, the Program project manager is notified along with initiating steps to obtain security reauthorization approval.

The following excerpt from our Configuration Management Plan describes further details.

1. Configuration Item (CI) Identification

SGS identifies CIs for which they are responsible and logs all CIs identified within the

Configuration Management Databases (CMDB).

CIs are anything whose exact status must be known during the product lifecycle, e.g., hardware configuration, software versions, system requirements, design specifications, project management plans, controlled data, source code, executable code, test plans, test cases, etc.

Each CI has a unique identifier by which the item is controlled. Each software or document CI also has version markings to uniquely identify revisions of the CI, approved change requests, etc.

Each CI is placed in a secure electronic library, physical library or both depending on contractual or organizational requirements. Current libraries include:

Subversion (SVN) and Mercurial repositories (code, scripts, etc…)

Atlassian documentation repository (documentation)

Web accessible portal using a SQL database (COTS, hardware CIs)

As CIs are created, they are recorded into one of the CMDBs depending on the CI type. Once a

CI is placed in a CMDB, ownership of the CI transfers from the CI author to the SGS

Configuration Management Team that tracks and control changes to the CI. If CIs are modified, a copy of the CI is taken out of the CMDB, modified and checked back into the CMDB where version control is applied to uniquely identify the new version.

2. Configuration Control

The control activities for CIs are coordinated as defined in the Change Management Plan The primary source for changes to SGS controlled CIs is through the Change Management process though changes may also occur due to contractual requirements, such as an annual update of specific documentation.

a. Change CI

When a CI needs to be changed, such as due to an approval through the Change Management process, the CI is retrieved from the library where the item is stored. The CI is then modified to incorporate the approved change and when the change is complete, the CI is returned to the

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-202 April 7, 2016 appropriate CMDB. The CI modification is complete when the CI is returned to the CMDB, where it is version controlled, and is available for testing or review by other SGS or Program staff. When any change to a CI is required, the reason for the change must be recorded with the

CI being modified. If a CI is modified due to an approved CMR, then the CMR should be identified in the text of the CI. Similarly, if the CI is modified due to a documented incident, the

CI should identify the incident number.

The above defined process is applicable for all SGS developed software, with the exception of system software. For system software, which includes software such as Unix/Linux scripts, cron files, configuration files, etc., these CIs are modified directly on the platform where they execute.

Then, every 2-weeks, an application is executed that scans all of the production and test servers and captures any changes to these files and places the results in SVN. For the CIs managed in the asset management CMDB, these CIs are updated whenever a change is made to the assets.

Over its lifetime, a CI is likely to be updated a number of times. A history of changes (with dates) is maintained to provide the Problem Management service management function and other service management functions with a view of changes made over time. This history contributes to trend analysis as well as to process improvement. If a change needs to be rolled back or an IT component restored to its previous state, this information is invaluable.

b. Version Control

Version control is the method of managing changes to information. Version control allows the tracking of all changes as well as a rollback to a previous state, if necessary.

Configuration Management is performed using a version control system and an observation tracking system.

Version control for items stored in either the source control or incident tracking tool are automatically managed by the respective repositories. Whenever items are checked in to the repository to replace a previous version, the source control or incident tracking tool automatically provides version control information.

Previous versions are not deleted but only archived within the repository and are always accessible. Hardware nomenclature and configuration data are stored in Oracle.

The database has a front-end written in PHP to display data and can be accessed via a command line. The purpose of the front-end is to provide an all-inclusive report of the current individual asset.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-203 April 7, 2016

3. Configuration Status Accounting

All CIs contained within a CMDB are tracked and reported to designated Agency personnel and SGS Managers as requested. Items stored in either of SVN and Mercurial can report CI versioning information. Asset management tracking contained in the third CMDB does not capture versioning or historical information of the assets. However, it does capture current hardware, COTS software, firmware and other information not contained in the other CMDBs.

Reports can be generated and compared to determine configuration changes.

A separate tracking tool, from Atlassian (JIRA), is used to identify documentation being changed and that data is maintained by the SGS Contract Administrator. The SVN and Mercurial

CMDBs allow reporting of software configuration builds for the Core Application and the BI applications. Using SVN and Mercurial, a complete list of all software CIs that comprises any production or test release is available and reportable. Additionally, software configuration changes between any two major releases can be reported by identifying the separate minor releases. These reports are primarily used to support Configuration Reviews.

Reports are generated periodically for internal SGS Configuration Management use and as requested by Agency personnel or SGS Managers. Status accounting reports identify:

Tracked CI attributes

Current version of each CI

CIs in each release (identified in the incident tracking tool)

Difference in CIs between releases (release notes)

Scripts and cron jobs

Version of all off-the-shelf and developed software in use

Hardware components that comprise the System

Firmware version

4. Configuration Audits and Reviews

Configuration audits and reviews for the Program are limited to two areas, reviews of configuration items that make up new releases or implement a CMR and audits of environments to verify that the environments are reflective of the data maintained in the CMDBs; i.e.

validating that configuration control has been maintained. Each of these is defined below.

Audits or reviews occur prior to the beginning of new system development lifecycle phases or after major releases of changed CIs are implemented. This data is compared with the release

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-204 April 7, 2016 notes to verify consistency. Audit and review activities are identified in the work plan. The audits and reviews documentation includes the following:

The objective

The CIs under audit or review

The schedule of audit or review tasks

The procedure for conducting the audit or review

The documentation required

The procedure for recording deficiencies and reporting corrective actions

The acceptance criteria

10.4.1.2.2 Limiting Access to Equipment and Preventing Unauthorized Access

Data Center Security. Implementation of systems and procedures to prevent unauthorized personnel from accessing the systems:

1. Within each data center, the equipment is housed in dedicated, locked cabinets. On-site security personnel monitor each center and manage the locking cabinets and cages.

Building and environmental alarms are monitored locally in each of the centers by a 24x7 staff and remotely by the Sungard Availability Services.

2. High night illumination levels are provided throughout all exterior areas within limits set by local authorities. The entire facility is monitored 24x7 by closed-circuit television, including site and roof, by on-site security staff.

3. Access into Equipment Areas:

Data center access is controlled via a mantrap.

Mechanical equipment areas and AC or DC power areas are hard key controlled.

Customer access into Sungard managed space is by escort only.

Access into SGS cages and storage is by conventional keys.

Employee access to all back-of-house areas requires card keys.

Biometric hand scanners, closed circuit TV with tape library for image retention, access card readers, and data center mantrap are all integral parts of the data center security model.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-205 April 7, 2016

4. Access List Verification:

SGS controls a list of authorized personnel with access to the server cabinets.

Personnel or visitors to the center not on the list or without adequate ID are prevented from entering the building or accessing the cabinets.

Server Site Security. All servers are securely housed and unauthorized access prevented.

The development servers and other program servers are maintained in locked computer facilities at SGS’ Malta, NY headquarters. Access to the Malta rooms is by key-card.

Access to all buildings is controlled by key or key-card. All visitors are logged in and out and escorted. The building alarm is armed for motion, glass break, door trip, and fire detection, and the intrusion system automatically arms each evening.

Fire suppression in the computer room is accomplished via automatic fire suppression equipment, along with manually operating extinguishers.

10.4.1.2.3 Monitoring and Logging Physical Access

Access to the room and all alarms and warnings is logged and monitored by SGS security personnel and also by the local alarm company.

Workforce Security 10.4.1.3

10.4.1.3.1 Control Process for Hiring and Terminating Personnel (Including Subcontractors), Including Audit Controls Implemented when Employment Terminates

Upon new or rehire of an employee, the hiring manager notifies SGS Transportation Human

Resources delegate to initiate establishment and configuration of the new employee’s user account. The new account is established per our change request procedure.

In circumstances applicable to terminations and separations where an account needs to be temporarily disabled, or access made available, HR management approval is required prior to any changes.

When a user leaves SGS or terminates his/her contract his/her manager, with Human

Resources, ensure that all access rights and associated user identification-account(s) are immediately revoked from all relevant systems before the person leaves

Accounts that are removed in response to an SGS employee leaving the company are retained as inactive for a period set in accordance with SGS' integrity policy.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-206 April 7, 2016

Confidentiality and Non-Disclosure Agreements

SGS affirms that Confidentiality and Non-Disclosure Agreements, when requested, all project staff including its subcontractor(s) complete and sign confidentiality and non-disclosure agreements provided by the Commonwealth.

Where required we affirm our responsibility to ensure that any new staff sign the confidentiality agreement and complete the security awareness and confidentiality training modules as part of our on-boarding process within one month of the employees’ start date.

10.4.1.3.2 Granting and Denying Access to the System and the Database

Initial passwords issued to a new user by a Security Administrator are valid only for the new user's first on-line session. During the first session the user is forced to choose another password.

Passwords and user logins grant access to users for the systems and programs that are applicable to them. We implement Role Based Access Control (RBAC) in all aspects of the authentication model to determine authorization to resources.

Account and Password Management 10.4.1.4

10.4.1.4.1 Management of all Administrator, End User, and Server or Service Accounts on

System Software, Hardware, and the Database

SGS applies our security model for management of software, hardware, and Database access for all administrators, end users, and server or service accounts, described below:

Authentication to verify a user’s identity. Depending on the level of trust required, this could entail user/password combinations, PINs, x.509 certificates, biometrics, device fingerprinting, or one-time passwords.

Authorization determines applications or data the user is allowed to access. In order to keep privilege separation and maintenance as simple as possible, SGS utilizes role-based authorization. This method divides privileges into discrete buckets, or roles, and assigns users to those roles depending on their function and business need. We conduct periodic authorization reviews to ensure users still have a business need for their granted roles.

10.4.1.4.2 Maintenance of an Auditable Change Log of Database and File Server User Account

Additions, Changes, and Inactivations

Within the System, any activity that can add, change, or delete any file or table entry is logged within the Database. Each entry includes the date, time, the originating system or workstation, and the action performed. Should there ever be a question as to who modified a specific

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-207 April 7, 2016 parameter, or which Inspector performed a test, the session data is captured and recorded and can be reviewed at any time. SGS employs a centralized system which stores and correlates data across different applications to facilitate quick access to the accounting data and enable efficient pattern detection and reporting.

Any reporting or investigation activity can be done through the SMART management console or via direct Database connection to view the tables. In addition, the logs will be archived in the

Inspection Database for the life of the program to facilitate any historical research or investigation necessary

Auditing is a review of the full process, ensuring the authentication, authorization, and accounting methodologies are appropriately designed and implemented. This is a critical step in the security process as systems, technologies, and business needs are constantly evolving.

Controls and processes put into place today may become insufficient or obsolete over time. SGS performs periodic top-down reviews of the entire process to monitor industry trends and techniques and to utilize current methods.

Identity and Access Management 10.4.1.5

The Inspection Database utilizes Role Based Access Control (RBAC) in all aspects of the authentication model to determine authorization to resources. These roles, or user security groups, restrict access and functionality into the system by table, screen, menu, and field.

RBAC is a method for allowing users to access various resources within a system according to pre-defined roles and responsibilities. As illustrated below, each resource is broken down into an individual set of permissions. Example permissions include

The ability to access an application or module within the SMART portal

Whether a particular screen, menu, or table is displayed

Which fields on that page are displayed

Which fields are read-only, and which fields are updatable

Which commands or functions are available to be run

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-208 April 7, 2016

Figure 10.4-2: Role Based Access Control (RBAC)

These individual roles are then mapped to task-based permissions. Each task-based permission is comprised of all the individual permissions required to accomplish a single task. For example, allowing a help desk agent to update an inspection station’s mailing address could require the following individual permissions:

Access to the SMART portal

Access to the management console module

Access to the station tab

View permissions to locate correct station in search tab

Access to station mailing address section

Update permissions on station mailing address

Each of these task-based permissions is bound by role assignment to one or more roles.

Following the example above, a role called “Help Desk Agent” is bound to the “Update Station

Mailing Address” task. It is important to note that each task can be assigned to multiple roles

(Update Station Mailing Address is bound to both Help Desk Agent and Agencies’

Administrator), and each role can be bound to multiple tasks (Help Desk Agent is bound to both

Update Station Mailing Address and Create New Ticket).

Within the system, each User is assigned to one or more roles. The roles a user is assigned to therefore determine the resources they have access to, what information is viewable, and what information is alterable. When new employees come on board it is a simple matter of assigning

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-209 April 7, 2016 that employee a User ID, mapping it to the roles they perform, and they have immediate access to every resource needed to perform their job, and nothing more. Similarly, as roles change or as employees leave, the assigned job roles are easily modified for the new position, or revoked altogether.

Single Sign On

The Database, SGS Management and Reporting Tool (SMART) Portal, and related components have single sign-on capability integrated into the application, including:

One user ID and password for the end-user to remember

Time savings by logging in once and accessing multiple applications

Centralized user ID management for creating, revoking, and modifying users and roles

As seen in Figure 10.4-3, single sign-on works by redirecting all authentication requests by applications and modules to a singular domain. This single authentication domain maintains the session token (browser cookie) and informs the applications and modules as to the status of that session. If there is no existing session, the authentication domain prompts the user for their login and password. Once the session is created, future authentication requests are handled without needing to prompt the user a second time. When the session becomes invalid, either through a session timeout or by specific action by the user, any new request to access a screen or module within SMART portal requires the user to re-enter their credentials.

Figure 10.4-3: Single Sign-On

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-210 April 7, 2016

Data Security 10.4.1.6

10.4.1.6.1 Ensuring Data Integrity

Integrity constraints are a set of business rules that verify or validate data at multiple levels when applied. Various types of integrity constraints exist throughout the Inspection Database environment, from the SMART portal, to the Workstation, to the Data Warehouse. Based on the result of these business rules, the application either disallows the entry or warns the user if any violations exist. Examples of different types of integrity constraints include:

Screen level constraints. Data filters applied at the screen level to perform high-level data validation. This includes items such as creating a mask for entering dates (xx/xx/xxxx), verifying all required fields are completed, or checking password complexity.

Table level constraints. Ensuring the data within a table is properly stored by checking items such as the requirement of a primary key, existence of a foreign key, or if a value needs to be unique within a table.

Field level constraints. Verifying that individual data elements conform to the expected information, such as whether NULL is allowed, comparing the datatype, or ensuring proper formatting.

By combining the different integrity constraints at multiple levels within the application, the data is more complete, consistent, and precise. This enables greater confidence in data integrity and accuracy as a whole.

Within the System, any activity that can add, change, or delete any file or table entry is logged within the database. Each entry includes the date, time, the originating system or workstation, and the action performed.

Any reporting or investigation activity can be done through the SMART management console or via direct database connection to view the tables. In addition, the logs will be archived in the

Inspection Database for the life of the program to facilitate any historical research or investigation necessary.

Figure 10.4-4 shows two examples of the journaling. The first example is the log generated by the SMART management console, indicating which users performed which actions. The second is a log generated by workstations in the field. These entries include users, station IDs, station numbers, actions, as well as Inspection Database communication times and failures.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-211 April 7, 2016

SMART Generated Log

Workstation Generated Log

Figure 10.4-4: Journal Example

10.4.1.6.2 Encryption and Protection of Data

SGS utilizes a three-pronged methodology for IT Security which is based off our larger

Corporate IT Security Policies.

Prevent. Reduce the risk of vulnerability, misuse, or compromise from occurring

Detect. Identify attempted attacks or misuse when it occurs

Respond. Take corrective action, document findings, and recover systems

Within the System, multiple techniques are used to prevent security issues from occurring in the first place. This includes the use of encryption for all communications channels; the implementation of segregated networks delineated by firewalls with Deep Packet Inspection

(DPI); operating-system level firewalls; and periodic security audits and penetration testing by third party vendors. By identifying potential threat vectors prior to attack, SGS is able to mitigate risks before they become a problem.

During an attempted attack or misuse event, the Security Information and Event Management system (SIEM) correlates multiple data points to determine the threat value, attack vector, and potential for compromise. Depending on the issue identified, the SIEM system executes various actions including, but not limited to: logging information for later retrieval; alerting IT

Operations staff of an event; and actively terminating connections. For example, network probes and port scans of our externally-facing services are quite common and benign, so the SIEM system merely logs the attempt but does not take any further action. Conversely, an internal system exhibiting behaviors indicating a malware infection generates immediate text alerts to the

IT Operations Team and blocks all network traffic originating from that host to prevent the spread of infection.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-212 April 7, 2016

In conjunction with the actions above, SGS follows a fully defined protocol for responding to threats. This methodology includes the following high-level pieces:

Neutralizing the threat and (if necessary) notifying the external customer

Preserving evidence for later forensic analysis

Determining scope and impact of the event

Recovering systems to known good states

Documenting all findings and actions

Given the ever-evolving landscape for information compromise, fraud, and abuse, the processes defined above are not static in nature. The entire security framework is subject to the same Continual Service Improvement standards implemented throughout the System. SGS works closely with the Agencies to determine benefits, risks, and opportunities of changes and new technologies as they become available to ensure the integrity of the System as a whole.

10.4.1.6.3 Retention of Records

Inspection records are stored on the Inspection Database as read-only and can only be edited with written permission from the Agencies. All records are stored on the Inspection Database indefinitely.

10.4.1.6.4 Compliance with applicable Data Security and Privacy Laws

SGS understands and will comply with the Commonwealth’s data security and privacy laws, as stated in Section 10.4.2.3.

Disaster Recovery and Business Continuity 10.4.1.7

SGS maintains a disaster recovery and business continuity model that protects the Agencies’ data and keeps business going. As described in Section 5.5, we maintain both a primary and secondary Database site with ongoing data replication. Our fully redundant Data Centers are located in Marlborough MA and Malta, NY. All communications lines between the Agencies, ALARS, and the Primary and Secondary Database sites are redundant and load sharing with automatic switchover if a failure occurs.

Compliance and Audit 10.4.1.8

10.4.1.8.1 Third-Party Security Review and Intrusion Testing

SGS’s third party IT Security auditing includes internal / external penetration testing, vulnerability scanning, and policy review.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-213 April 7, 2016

10.4.1.8.2 Plan for Compliance with Legal Requirements

SGS understands that all data generated and/or received by the Agencies, the Inspection

Stations, or otherwise through the Program is the property of the Commonwealth and the

Agencies. All data will be stored, protected, retained, and transmitted in accordance with the applicable laws, regulations, rules, and policies, including without limitation the Enterprise IT standards referred to in RFR Section 3.1.1.4, and record retention schedules required by both

Federal and State statutes. Applicable laws include, without limitations:

1. Federal Driver Privacy Protection Act, 18 U.S.C. §§2721-2725;

2. Massachusetts Public Records Law, M.G.L. c. 66, §10;

3. Massachusetts Security Breach and Breach Notification Laws, M.G.L. c. 93H and 93I;

4. Massachusetts Fair Information Practices Act, M.G.L. c. 66A;

5. Massachusetts Executive Order 504 (Order Regarding the Security and Confidentiality of

Personal Information); and

6. Massachusetts Records Retention Law, M.G.L. chapter 30, section 42.

SGS will comply with these legal requirements when developing, installing, servicing, and maintaining the data system for the Program. Prior to handling any data, SGS will work with the

Agencies to classify the data and identify which laws apply. For each component of the Program involving data, SGS will create written documentation identifying the data fields, applicable law, and evidence of compliance, subject to approval by the Agencies.

Prior to the System going live, SGS will provide a Security Assessment Report from a qualified third party security assessor (who has been previously approved by the Agencies), certifying that our established policies, procedures, and controls are adequate to ensure a secure operating environment, using one of the following standards as an acceptable framework:

NIST – Specifically: Special Publication 800-53 Revision 4 with Moderate controls

ISO 27000 series – Specifically ISO 27002:2013 or ISO 27002:2005

FedRAMP (does not apply since SGS is not proposing cloud implementations)

The assessor will provide a letter of certification, including the assessor's name and industry qualifications. SGS will also provide an annual certification stating that it is continuing to comply with all security controls and with the standard used in the original assessor’s letter.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-214 April 7, 2016

System Security and Incident Management 10.4.1.9

10.4.1.9.1 Products and Methods for Firewall Control Process and Intrusion Detection

Methodology

The Database security tools are shown in Figure 10.4-5.

Figure 10.4-5: Database Security Tools

Tool Used for

Hardware

Network Firewalls Network security and segregation

Software

SIEM Security log management, correlation, real-time analysis, alerting, and reporting

OS-Level Firewalls Controlling network access at a per-host level

Other

Qualys Security Audits Third party IT Security auditing including internal / external penetration testing, vulnerability scanning, and policy review

Encryption Data encryption to ensure security of PII, inspection results, and information stored within offline workstations

RBAC Controlling access to view / add / change information on a per-user or per-job basis.

Integrity Constraints Ensuring data is valid, accurate, and complete

10.4.1.9.2 Products and Methods for "Hardening" of Operating Systems or the Database

Hardening a network typically implies utilizing layered protection to offset malicious threats.

SGS utilizes a layered DMZ structure that protects at the host level, the application level, the operating system level, the user level, the physical level and all the sublevels in between. Each level is configured with a unique method of security.

We also monitor port activity by shutting down ports not in use for certain duration.

To better protect database information and to limit exposure to possible data breaches, SGS uses additional proactive tools and processes such as the following:

Intrusion detection and prevention systems

Encryption of all data sent for offsite backups

Physical access controls at all data centers

Role-based access to control data access

Sensitive data is stored in separate tables with more strict access

Full Authentication, Authorization, Accounting, and Auditing for data access and manipulation

SGS uses the following network support and security tools to monitor and safeguard databases:

AlienVault, a distributed Intrusion Detection System / Intrusion Prevention System

(IDS/IPS) used to constantly monitor security at the network, host, and application layers.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-215 April 7, 2016

This system combines application logs, network traffic, and system events to create real-time event correlation and comparison against accepted use patterns. Anomalous conditions are raised to the IT Operations Team for immediate review and remediation.

Centreon, an open source enterprise monitoring tool ensures uptime and availability of networks, servers, applications, and databases. In addition to identifying current problems, Centreon constantly collects and reports on performance metrics so that historical trends can be analyzed and remediation completed to enable problem avoidance.

Qualys, an external company used for external / internal penetration testing, vulnerability scanning, and remediation.

10.4.1.9.3 Methods for Agencies to Access and Review Log Information

The Agencies can perform reporting or investigation activity through the SMART management console or via direct database connection. In addition, the logs will be archived in the Inspection Database for the life of the program to facilitate any historical research or investigation necessary.

10.4.1.9.4 Communications and Transmissions Protected and Validated

As mentioned above, we use AlienVault to constantly monitor security at the network, host, and application layers. Communications and transmission security includes the use of encryption for all communications channels; the implementation of segregated networks delineated by firewalls with Deep Packet Inspection (DPI); operating-system level firewalls; and periodic security audits and penetration testing by third party vendors. By identifying potential threat vectors prior to attack, SGS is able to mitigate risks before they become a problem. Some of the measures we take to protect communications and transmissions are:

All wireless Access Points / Base Stations connected to the corporate network must be registered and approved by SGS. These Access Points / Base Stations are subject to periodic penetration tests and audits. All wireless Network Interface Cards (i.e., PC cards) used in corporate laptop or desktop computers must be registered with SGS.

All wireless LAN access must use corporate-approved vendor products and security configurations.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-216 April 7, 2016

All computers with wireless LAN devices must utilize a corporate-approved Virtual

Private Network (VPN) configured to drop all unauthenticated and unencrypted traffic.

To comply with this policy, wireless implementations must maintain point to point hardware encryption of at least 128 bits using WPA2. All implementations must support a hardware address that can be registered and tracked, i.e., a MAC address. All implementations must support and employ strong user authentication which checks against an external database such as TACACS+, RADIUS or something similar.

10.4.1.9.5 Products and Methods for Anti-Virus and Malware Controls

Network-based Intrusion Detection Services (NIDS) and HDS monitor security at the network, host, and application layers. This system is designed to detect and trap the following:

Spyware attacks

Denial of Service attacks

Network port probing/strobing

Worms / Network Virus

We configure and incorporate schema validation to validate and protect network resources from malicious formed messages.

All computers connected to SGS and the System must have current virus protection software in place. Anti-virus software must not be disabled or deactivated.

Recommended processes to prevent virus problems:

Always run the corporate standard, supported anti-virus software is available from the corporate download site. Download and run the current version; download and install anti-virus software updates as they become available.

NEVER open any files or macros attached to an email from an unknown, suspicious or untrustworthy source. Delete these attachments immediately, then "double delete" them by emptying your Trash.

Delete spam, chain, and other junk email without forwarding, in with the SGS Acceptable

Use Policy.

Never download files from unknown or suspicious sources.

Avoid direct disk sharing with read/write access unless there is absolutely a business requirement to do so.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-217 April 7, 2016

Always scan a CD/DVD from an unknown source for viruses before using it.

Back-up critical data and system configurations on a regular basis and store the data in a safe place.

If lab testing conflicts with anti-virus software, run the anti-virus utility to ensure a clean machine, disable the software, and then run the lab test. After the lab test, enable the anti-virus software. When the anti-virus software is disabled, do not run any applications that could transfer a virus, e.g., email or file sharing.

New viruses are discovered almost every day. Periodically check the Lab (Development

Environment) Anti-Virus Policy and this Recommended Processes list for updates.

10.4.1.9.6 Products and Methods for Scanning the Database Infrastructure for Vulnerabilities and

Remediation of Vulnerabilities

The Database security is incorporated into a larger Security Information and Event

Management (SIEM) system which provides a holistic view of the security landscape. A combination of Security Information Management (SIM), and Security Event Management

(SEM), SIEM allows for long term log storage and management, real-time monitoring, event correlation, alert generation, and reporting.

The SIEM system has multiple filters and automatic correlation engines that are constantly looking for known attack vectors, anomalous traffic, pre-configured events, and a host of other conditions or logging points. Once an event is found it is logged, classified, and cross-checked to other existing activity. If the problem is within certain severity conditions, an alert is generated for immediate investigation.

A sample of an alert is show below in Figure 10.4-6.

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-218 April 7, 2016

Figure 10.4-6: Suspect Report Example

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-219 April 7, 2016

10.4.1.9.7 Methods used for Initiating and Completing Security Assessments

SGS forms a security review team, led by the Information Technology Operations Manager, to conduct a thorough security assessment for the Program. The review team serves as a security resource that bridges responsibilities between IT Operations and Quality Assurance to ensure audits and gap analysis are in alignment with program policies and best practices.

As part of the final design, the SGS Review Team conducts a formal vulnerabilities analysis.

This is a documented process. The review team includes:

The SGS IT Operations manager, who leads the team

A consultant approved by the Agencies performs the security review

Principle Technical Architect from the design team

Director, Information Systems Development

Quality Assurance Manager

Program staff as delegated

The review process includes:

Review of availability of sensitive information

Review of architectural design and security procedures

Security testing

Notification when an intrusion (or anomalous activity) occurred- regardless of its ability to penetrate the system to designated Program personnel

Documentation SGS Corporate Security provides a detailed audit checklist. SGS annually performs a commensurate audit and logs results and remedial actions on an annual basis. Our detailed audit checklist includes drill down lists regarding the following topics:

Context of the Organization

- Understanding of the organization

- Understanding the needs and expectations of interested parties

- Determining the scope of the information security management system

- Information security management system

Leadership

- Leadership and commitment

- Policy

- Organizational roles, responsibilities and authorities

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-220 April 7, 2016

Actions to address risks and opportunities

- Information security risk assessment

- Information security risk treatment

Information security objectives and planning to achieve them

Support

- Resources

- Competence

- Awareness

- Communication

- Documentation change and control

Operation

- Operational planning and control

- Information security risk assessment

- Information security risk treatment

Performance Evaluation

- Monitoring, measurement, analysis and evaluation

- Internal audit

- Management review

Improvement

- Nonconformity and corrective action

- Continual improvement

Information security policies

Organization of information security

Human Resource Security

Asset management

Access control

Cryptography

Physical and environmental security

Operations security

Communications security

Use or disclosure of data contained on this sheet is subject to the restriction on the title page of this proposal.

Technical Response 10-221 April 7, 2016

System acquisition, development and maintenance

Supplier relationships

Information security incident management

Information security aspects of business continuity management

Compliance

Throughout this Plan we state our utilization of audits to ensure appropriate security are established and executed measures and to use audit results as opportunities to enhance the effectiveness of our system procedures.

SGS acknowledges and welcomes audits performed by the Agencies. We fully cooperate with

Agency assigned staff to grant full access to all operations for security inspections and audits which may include reviews of all issues addressed in description of the security approach and willingness to enter into good faith discussions to implement.

Part II 10.4.2

As Prime Contractor to the Agencies on the Vehicle Inspection and Maintenance Program, SGS affirms that we meet the requirements below.

Us…