centurylink draft business support systems (bss ... · supporting ordering, billing, inventory...

Enterprise Infrastructure Solutions

Volume 2—Management Volume—Draft BSS Verification Test Plan

SFA# 52021671/NSP# 80162 RFP No.: QTA0015THA3003

i November 4, 2016

Data contained on this page is subject to the restrictions on the title page of this proposal.

CENTURYLINK

DRAFT BUSINESS SUPPORT SYSTEMS (BSS) VERIFICATION TEST PLAN

DRAFT

CDRL 34

November 4, 2016

Qwest Government Services, Inc. dba CenturyLink QGS

4250 N Fairfax Drive, Suite 300

Arlington, VA 22203




ii November 4, 2016


REVISION HISTORY Revision Number Revision Date Revision Description Revised by




iii November 4, 2016


TABLE OF CONTENTS 1.0 Document Scope .................................................................................................. 1

1.1 BSS Verification Testing Approach (E.2.2.1) ............................................. 2

2.0 Assumptions ......................................................................................................... 3 3.0 BSS Test Scenarios (E.2.1.2.1, E.2.1.2.2) ........................................................... 3 4.0 Test Approach Overview ...................................................................................... 9

4.1 Environment ............................................................................................. 10 4.2 Test Scenario Coverage .......................................................................... 13

4.2.1 Test Scenario Coverage Overview ................................................ 13 4.2.2 Test Scenario to Test Case Mapping ............................................ 14

4.3 Test Case Process Flows ........................................................................ 17 4.3.1 Test Case 1: Account Set-up and RBAC ...................................... 19 4.3.2 Test Case 2: Service Ordering Lifecycle ....................................... 21

4.3.2.1 Inventory and Billing ...................................................... 22

4.3.3 Test Case 3: In-progress Order Changes Lifecycle ...................... 23 4.3.4 Test Case 4: Provisioned Order Administrative Changes Lifecycle24

4.3.5 Test Case 5: Self-Service/Rapid Provisioned Order Lifecycle ...... 25 4.3.6 Test Case 6: Disputes ................................................................... 26 4.3.7 Test Case 7: Security .................................................................... 27

4.3.7.1 Security Features .......................................................... 27 4.3.7.2 Customer Access and Authentication ........................... 28

4.3.7.3 EIS BSS Gateway and EBAB architecture .................... 29 4.3.8 Test Case 8: Regression ............................................................... 31

4.4 Test Acceptance, Results, Reporting (E.2.1.3, E.2.1.4, E.2.1.5.2, E.2.2.4) ................................................................................................... 31

4.5 Draft Test Project Schedule ..................................................................... 35

LIST OF FIGURES Figure 4.3-1. Overarching Test Case to Test Scenario Relationships ........................... 18

Figure 4.3.1-1. Test Case 1: Account Set-up and RBAC .............................................. 20

Figure 4.3.2-1. Service Ordering Lifecycle .................................................................... 22

Figure 4.3.3-1. In Process Order Change Flow ............................................................. 24

Figure 4.3.4-1. Administrative Change Flow ................................................................. 25

Figure 4.3.5-1. Self-Service/Rapid Provisioned Flow .................................................... 26

Figure 4.3.6-1. Disputes Test Flow................................................................................ 27

Figure 4.3.7-1. EIS Customer Access to the BSS - Overview ....................................... 28

LIST OF TABLES Table 3.0-1. BSS Test Scenarios .................................................................................... 4

Table 4.2.2-1. BSS Test Cases. .................................................................................... 15

Table 4.2.2.-2. Test Case Mapping to Test Scenarios .................................................. 15

Table 4.4-1. Test Case Elements .................................................................................. 34

Table 4.5-1. 8-Week Test Schedule .............................................................................. 35




1 November 4, 2016


1.0 DOCUMENT SCOPE

CenturyLink’s draft BSS Verification Test Plan (BSS Test Plan) describes our

approach to verifying compliance of the EIS BSS with the BSS RFP requirements. This

plan defines and documents the overall methodology and timeline that CenturyLink will

use to validate each test scenario and test case defined in RFP Section E.2.1. Implicit in

this methodology is the sequencing of each test scenario as defined by test case flows

and the relationship of all test scenarios across these flows.

CenturyLink’s draft BSS Test Plan is developed as required and in accordance with

the EIS requirements. A final BSS Test Plan will be provided to the government 30 days

after notice to proceed (NTP) consistent with RFP Section F.2.1. The final BSS Test

Plan will contain the contents of the approved draft BSS Test Plan as well as each

detailed test case that will be executed during BSS verification testing.

This final plan will be accepted or rejected by the government within 21 days of

receiving it. If it is rejected, CenturyLink will send an updated plan back to the

government within 14 days of receipt of the government’s comments. At this point, the

government will have 14 days to accept or reject the revised plan. If it is rejected again,

this cycle will be repeated until acceptance is achieved.

During our BSS development, CenturyLink will perform Section 508 compliance

testing for our government-facing web interfaces and identify and prioritize all

accessibility errors, define the method for addressing issues, and document overall

compliance with Section 508. Automated accessibility compliance tools will be used to

define a baseline list of areas to be addressed. As required, our BSS testing will take

into account aspects of the Section 508 regulations that cannot be tested without

human interaction and input.




2 November 4, 2016


1.1 BSS VERIFICATION TESTING APPROACH (E.2.2.1)

CenturyLink will complete the BSS verification testing process within 12 calendar

months following government acceptance of the BSS Test Plan, as required in RFP

Section G.2.3 and in accordance with RFP Section E.2.1. CenturyLink recognizes that

the BSS test cases provided by the government will cover the following elements:

BSS testing will verify all BSS functional, regression and security requirements

have been met

BSS testing will be performed for all management and operation functions

supporting ordering, billing, inventory management, disputes, SLA management

and trouble ticketing processes described in RFP Sections G and J.2

Security testing will be based on the requirements described in RFP Section

G.5.6 (See BSS-TS13). The security requirements acceptance will be based on:

– Assessment and Authorization (A&A)

– FedRAMP certification (if applicable)

BSS testing will include multiple test cases as defined in RFP Section Error!

Reference source not found. Test Cases

BSS testing will include use test cases for quality, utility, and customer access

features

CenturyLink will allow government representative(s) to observe all or any part of the

verification testing

Upon request, CenturyLink will perform tests to ensure continued compliance

each time a new service is offered or when a features/functionality of the BSS is

modified affecting the functional requirements described in RFP Sections G and

J.2.

CenturyLink will provide a BSS verification test results report with analysis for

any retest within seven days after performance of the tests. The government

reserves 14 days to accept or reject the test results, in part or in whole. If the

government rejects the test results CenturyLink shall retest until such time the

results are acceptable to the government.




3 November 4, 2016


CenturyLink will perform BSS verification testing according to the accepted BSS test

plan at a mutually acceptable date with the government. BSS testing will be performed

during normal business hours, 8:00am-5:00pm Monday-Friday, Eastern Time.

2.0 ASSUMPTIONS

CenturyLink has no assumptions in planning the test activities, estimating the test

effort, and deriving the test schedule(s) associated with the requirements in RFP

Section E.2.1:

3.0 BSS TEST SCENARIOS (E.2.1.2.1, E.2.1.2.2)

Prior to initiating BSS testing, CenturyLink will:

Provide written notice to the government that the BSS has passed internal testing

and is ready to begin BSS interface testing with GSA Conexus.

Provide a finalized BSS Test Plan that is accepted by GSA

Support BSS security and functional testing as defined in RFP Section G.5.6

CenturyLink will use GSA-provided test data for all BSS verification testing unless

specified otherwise:

This data will be used for testing purposes only.

No customer “live” data will be used for testing.

This data will be a realistic simulation of actual customer data.

The test data will include, in some tests, intentional errors intended to test

CenturyLink‘s BSS error handling.

The purpose of the verification and acceptance testing is to ensure that the BSS

meets requirements in RFP Sections G and J.2. Table 3.0-1 contains a high-level list of

BSS test scenarios that will be addressed by the test cases identified in this document.




4 November 4, 2016


Table 3.0-1. BSS Test Scenarios

Test

Scenario #

RFP

References

Description Test Case Comment

BSS-TS01 G.5.3.2

J.2.9

Exchange structured data using the

defined direct data exchange methods:

XML via secure web services

Pipe, “|”, delimited table via SFTP

CenturyLink will demonstrate bidirectional

exchange of defined data structure that

meets the interface specifications as

defined in RFP Sections G.5.3.2 and

J.2.9.

BSS-TS02 G.3

J.2.3

CenturyLink’s BSS manages the

following as specified in RFP Section

J.2.3:

Accept system reference data

Provide direct billed agency setup

CenturyLink will demonstrate successful

task order (TO) data management initial

setup and updates.

BSS-TS03 J.2.3.1.2 CenturyLink’s BSS manages role-based

access to all BSS functions (e.g.,

ordering, billing, inventory management,

trouble management, SLA management).

CenturyLink will demonstrate that its BSS

provides the ability to define role based

users with privileged access to the BSS

to meet the requirements as defined in

RFP Section J.2.3.1.2.

BSS-TS04 G.3

J.2.4

CenturyLink’s BSS manages the

processing of orders and generation of

required acknowledgments and

notifications. Order types include:

New service for each of the services

specified in RFP Section C.2, Technical

Requirements, that are included in the

awardee’s contract

Service moves

Service disconnects

Service feature changes

Telecommunications Service Priority

(TSP)

Auto-sold CLINs

Bulk orders

CenturyLink will demonstrate that an

authorized government user can place an

order using the methods specified in RFP

Section J.2.4, and the order populates

the fields in CenturyLink’s BSS in a way

that meets the requirements in RFP

Sections G.3, G.5 andJ.2.2-J.2.10.

Using the direct data exchange method

defined in RFP Section J.2.4,


can provide all required CDRLs, including

the following:

1) Service Order Acknowledgement

(SOA)

2) Service Order Rejection Notice

(SORN)

3) Service Order Confirmation (SOC)

4) Firm Order Commitment Notice

(FOCN)

5) Service Order Completion Notice

(SOCN)




5 November 4, 2016


Test

Scenario #

RFP

References


BSS-TS05 G.3

J.2.4

CenturyLink’s BSS handles order

updates that impact other, in-progress

orders, including the following:

Cancel orders


Location changes

Changes to customer want date

Changes to administrative data


authorized government user can make a

change to or cancel an order using the

methods specified in RFP Section J.2.4,

and the order populates the fields in

CenturyLink’s BSS in a way that meets

the requirements in RFP Sections G.3,

G.5 and J.2.2-J.2.10.




will provide all required CDRLs, including

the following:

1) SOA

2) SORN

3) SOC

4) FOCN

5) SOCN

BSS-TS06 G.3

J.2.4

CenturyLink’s BSS handles orders for

administrative changes to the records for

previously provisioned services, as

described in RFP Section G.3.


authorized government user can place an

administrative change order using the

methods specified in RFP Section J.2.4,

and the order populates the fields in

CenturyLink’s BSS in a way that meets

the requirements in RFP Sections G.3,

G.5 and J.2.2-J.2.10.





the following:

1) SOA

2) SOCN




6 November 4, 2016


Test

Scenario #

RFP

References


BSS-TS07 G.3.5.6

J.2.4.2.4

CenturyLink’s BSS manages self-service

provisioning and other rapid provisioning

orders and provides the correct notices.

CenturyLink will successfully demonstrate

the completion of these orders. Non-self-

service orders will be tested using both

correctly placed orders and orders with

related errors. Self-service orders will be

tested with correctly placed orders and to

ensure that CenturyLink’s BSS does not

permit the placement of incorrect orders.




can provide all required CDRLs including:

1) SOA

2) SOCN

BSS-TS08 G.4

J.2.5

J.2.6

J.2.7

J.2.10

CenturyLink’s BSS properly manages

inventory and billing in the following

ways:

Generates the inventory of services

delivered by CenturyLink

Produces output that is consistent with

order and billing details

Generates the detailed billing in

accordance with the billing invoice (BI)

CDRL

Properly handles usage-based billing

Correctly calculates the AGF due to GSA

and produces the required AGF CDRLs

Provides accurate calculation of rounding

and proration related to billing, taxes, fees,

and surcharges

CenturyLink will demonstrate that its

service inventory management system

maintains a complete and accurate

inventory of EIS service orders in a way

that meets the requirements in RFP

Sections G.5, G.7 and J.2 (CDIP).

CenturyLink will demonstrate that the

output of its billing data elements is

consistent with the orders entered into its

BSS and that the billing data elements

meet the requirements in RFP Sections

G.4, G.5 and J.2 (CDIP).


defined in RFP Sections J.2.5-J.2.7,


can provide all required CDRLs including:

1) Billing invoice

2) Billing adjustment

3) Tax detail

4) AGF detail

5) AGF electronic funds transfer report

6) Inventory reconciliation




7 November 4, 2016


Test

Scenario #

RFP

References


BSS-TS09 G.4.4

J.2.6

CenturyLink’s BSS properly manages all

dispute types with appropriate handling

for the following:

Government-initiated disputes

Contractor-initiated disputes

Billing disputes

Inventory disputes

SLA disputes

Dispute tracking and reporting


can accept and issue disputes and track

them to resolution.





the following:

1) Dispute

2) Dispute report

BSS-TS10 G.8

J.2.8

CenturyLink’s BSS properly manages

SLA management through the following:

SLA reporting

SLA credit request handling and response


successfully tracks SLAs with associated

KPIs and reports SLA performance and

provides sufficient information in

response to SLA credit requests.




can provide all required CDRLs including

the following:

1) SLA report

2) SLA credit request response

BSS-TS11 F

J.2

CenturyLink’s BSS produces the

following acceptable open-format reports

defined in the CDIP:

Monthly billing information memorandum

Trouble management incident

performance report

Trouble management performance

summary report

CenturyLink will demonstrate, via sample

reports, that the open-format reports

specified are sufficiently detailed and

clear so as to meet the government’s

requirements.

BSS-TS12 J.2 CenturyLink’s BSS testing includes

regression testing of all key features,

including ordering, service assurance,

and billing.

NOTE: Applies only to testing

conducted as part of system changes,

not initial BSS development.


meets regression testing. The BSS Test

Plan will include regression testing;

however, actual regression testing will not

be part of initial test and acceptance.




8 November 4, 2016


Test

Scenario #

RFP

References


BSS-TS13 G.5.6 CenturyLink’s BSS has been provided an

Authority to Operate (ATO) as defined by

the following NIST.gov publications:

SP.800-53 REV 4

(http://nvlpubs.nist.gov/nistpubs/SpecialPu

blications/NIST.SP.800-53r4.pdf)

FIPS Publication 200

(http://csrc.nist.gov/publications/fips/fips20

0/FIPS-200-final-march.pdf)


meets FISMA moderate requirements.

Test Data

CenturyLink will use GSA-provided test data for all BSS verification testing unless

specified otherwise:

This data will be used for testing purposes only.

No customer “live” data will be used for testing.

This data will be a realistic simulation of actual customer data.

The test data will include, in some tests, intentional errors intended to test

CenturyLink‘s BSS error handling.

Tiered Approach

BSS testing follows a tiered approach:

CenturyLink will accept multiple test cases for the test scenarios defined in RFP

Section E.2.1.2.

CenturyLink will accept, incorporate into the BSS Test Plan, and successfully

execute each test case with one or more test data sets.

GSA will group test data sets into Test Subcases:

– Each test subcase will contain data sets to test a specific “real world” test

case

– Each test subcase will include at least two complete test data sets




9 November 4, 2016


4.0 TEST APPROACH OVERVIEW

The CenturyLink testing process is managed by dedicated testing personnel and is

clearly delineated in the test cases described in this plan. CenturyLink test cases have

been configured to ensure each applicable government defined test scenario is

covered. CenturyLink will demonstrate, through these test cases, the compliance and

accuracy of our BSS. Test cases will demonstrate compliance with different scenarios

and sub-scenarios detailed in the testing guidelines provided by the government. Each

service type will have all sub-scenarios tested through an individual test case or in some

instances several test cases.

CenturyLink will hold daily meetings internally to review the testing for that day. A

status will be provided to the government on a mutually agreed upon frequency and

method. A review will be made of all test cases executed, failed, and passed. Testing

output and test case results will be discussed by the CenturyLink BSS verification

testing team during daily morning briefings. The results are used to identify defects

and/or required enhancements to be addressed in the CenturyLink BSS environment. If

the test results show a defect, the continuation of that test will be held for CenturyLink IT

development and the test will be marked pending. After corrective changes have been

completed, CenturyLink will conduct internal system testing before the CenturyLink BSS

verification testing team continues with the test case.

Documentation on the test cases will be provided to the government for review with

results attached. After each test case step is completed that culminates in the testing of

each case per service, the report will reflect that the service has passed testing for that

scenario and a cumulative completion testing percentage will be updated. CenturyLink

will sign off on all tests once they are complete and submit this to the government. Once

the government certifies the test case has been passed (by service), the certified results

and the status of any outstanding tests will be documented in the BSS verification test

results report and provided to the government on a weekly basis with the final report

provided to the government within seven days after performance of the tests.




10 November 4, 2016


CenturyLink will use the BSS production environment for all management and

operation functions supporting ordering, billing, inventory management, disputes, SLA

management, and trouble ticketing processes.

As required in the RFP, our test plan includes thirteen functional discrete BSS

verification testing scenarios. Each scenario is broken down into sub-scenarios to

exercise specific functionality related to that test scenario. As described in Section 5.3,

these scenarios and sub-scenarios have been restructured into eight test cases to test

the specific end-to-end operational flow they represent.

4.1 ENVIRONMENT

CenturyLink has leveraged its commercial architecture and enhanced it to meet all

EIS RFP requirements. This includes establishing a secure environment that is

firewalled off from our commercial systems to provide the EIS BSS Assessment

Boundary (EBAB) inside which will be housed the authentication, authorization and role

based access controls (RBAC) securing access to government specific data. Building

on this existing infrastructure provides substantial advantages to the government, as

corporate enhancements and support are provided concurrently for both commercially

supported contracts and the EIS contract.

CenturyLink protects this environment against anticipated threats or hazards,

including unauthorized access, malicious code attacks, and inappropriate use or

disclosure of information. EIS-dedicated web application firewall (WAF) functionality

monitors traffic for a wide array of potential cyber attacks and other nefarious traffic. The

WAF blocks such traffic and terminates sessions that initiate it, to protect systems within

the EBAB and back-office systems from Internet cyber attacks.

Automated continuous monitoring of EIS systems is centralized in corporate security

information and event management (SIEM) systems for access monitoring, file integrity

monitoring, and configuration monitoring. Network intrusion detection systems (IDS) are

deployed at inside and outside locations across the CenturyLink network boundary, as

well as at strategic locations within the corporate network and in our national networks.




11 November 4, 2016


The IDS sensors report to SIEM systems managed and monitored by CenturyLink’s

cyber defense team.

As a provider of Department of Homeland Security (DHS)-approved enhanced

cybersecurity services to the sixteen critical infrastructure sectors, CenturyLink makes

use of these same services within our own infrastructure. As a consequence, GSA may

be assured that the CenturyLink infrastructure has been filtered on the most pernicious

classified threats identified by DHS and its partners. This filtering is achieved through:

Network-based inbound email filtering and neutralization

Domain Name System (DNS) protection and notifications

Advanced attack detection, prevention and mitigation

Real time blocking and notifications

Weekly reporting

Multiple interface options to meet a variety of corporate email implementations

Evolving security services provide state-of-the-art protections not available in

commercial offerings. Support is provided 24/7/365 by CenturyLink’s Security

Operations Center (SOC).

Redundancy is incorporated for all critical components, at both the processor and

data levels, ensuring a stateful failover without service disruption. Redundancy is

achieved through mirrored and load-balanced configurations. All software is backed up

and stored offsite to protect the integrity of all data restorations.

CenturyLink has deployed a comprehensive set of protective security measures in

its national networks, including software configuration and patch management systems,

which ensure system applications are protected, and a robust monitoring system for

managing the infrastructure:

User and protocol access: Restrict access to management plans of the

network elements, including use of encryption and two-factor authentication

IP spoofing prevention measures: Include implementation of anti-spoofing

technologies in our edge and border routers to prevent spoofed network attacks




12 November 4, 2016


from entering the CenturyLink network, along with routing protocol message

integrity checks using MD5 hashing

Denial of service and distributed denial of service (DoS/DDoS): Monitoring

and mitigation measures include flow monitoring across our border routers to

provide immediate attack identification and mitigation

Virus protection: Anti-malware/anti-spyware systems are incorporated at

multiple layers of the CenturyLink infrastructure

Standardized identity management: Access systems ensure that all those who

access CenturyLink systems are granted unique identifiers and given access

only to those systems for which they have a specific business need to access. In

addition to this least-privilege model of security, CenturyLink employs two-factor

authentication methods such as SecurID tokens and digital certificates for access

to critical elements and remote access to our networks

Managed firewalls: Used to manage access to networks and systems, and to

deter outside threats against systems

Intrusion detection and prevention: Effective systems and processes are used

to monitor for attacks, misuse, and anomalies, to detect and record such

intrusions and implement immediate corrective responses

Vulnerability scanning: Conduct effective and proactive assessments of critical

networking environments, enabling the rapid elimination of vulnerabilities before

they can be exploited

Anti-virus management: Detects and removes malware before it can do critical

damage to business operations




13 November 4, 2016


4.2 TEST SCENARIO COVERAGE

4.2.1 Test Scenario Coverage Overview

CenturyLink will conduct its BSS testing using eight major test case flow cycles that

span multiple government-defined BSS test scenarios (BSS TSS-XX) and sub-

scenarios to demonstrate the business support processes lifecycle including all CDRLs

produced during that lifecycle. These test case flow cycles are:

1. Account set-up and RBAC: Establish basic account information for use by the

rest of the BSS functions, including login

2. Order processing lifecycle: Ensure traceability, accountability, and systems

integrity is in place from the placement of a service order through billing and

inventory

3. In-progress order changes lifecycle: Allow changes to an in-progress service

order before it is provisioned

4. Provisioned administrative change order lifecycle: Ensure traceability,

accountability, and systems integrity is in place from the submission of changes

to the administrative data (such as the agency service request number (ASRN)

and agency hierarchy code (AHC)) to the generation of the SOAC and reports

where these fields occur

5. Self-service/rapid provisioned order lifecycle: Ensure traceability,

accountability, and systems integrity is in place from the service order through

billing and inventory for those services that can be self-service/rapid provisioned

6. Disputes: Ensure entry, tracking, and management of billing, inventory, and SLA

disputes to ensure traceability through closure and the capture of any impacts to

billing and inventory

7. Security testing: Ensure that the EIS BSS meets Federal Information Security

Management Act (FISMA) moderate requirements

8. Regression testing: Regression testing will not apply to initial BSS development

and will be detailed in the final BSS Test Plan submitted after NTP. Regression

testing will follow the BSS change control practices described in the PMP,

Section 9.4.2




14 November 4, 2016


Through application of the eight relevant test cases, traceability from an initial

service order to the invoice/inventory can be clearly demonstrated, and the

invoice/inventory impacts of subsequent changes to that service will be readily apparent

when comparing the original invoice inventory to one generated in the next simulated

reporting cycle.

Since each test case spans the lifecycle of an order, certain error handling rules

must apply. If an order is stopped because of a failed step, inventory and billing cases

cannot continue for that case. These errors will either be ones that would stop

processing or ones that may be detected later. The critical errors (those that stop

processing) will necessitate retesting once the error has been corrected, and regression

testing will then occur. Errors that do not stop processing will be revealed with the

mitigation plan showing how these errors will be handled. CenturyLink will show where

test process interruptions occur and provide the plan to start testing again.

4.2.2 Test Scenario to Test Case Mapping

Table 4.2.2-1 describes the test cases that will be used for BSS testing and

dependencies that a specific test case may have on other test cases. Two examples of

the types of dependencies/predecessor activity that will occur are the test case involving

BSS TS-05, which may be defined as a change to an in-progress order that is part of

BSS TS-04, and the test case involving BSS TS-06, which may be defined as an

administrative change to an order provisioned as a result of BSS TS-04.




17 November 4, 2016


4.3 TEST CASE PROCESS FLOWS

Figures 4.3-1 through 4.3.7-1 detail the flows in diagram form for each test case. As

noted above, Figure 4.3-1 provides a high level overview of each test case and the

BSS test scenario exercised during that test case.




18 November 4, 2016


Figure 4.3-1. Overarching Test Case to Test Scenario Relationships




19 November 4, 2016


4.3.1 Test Case 1: Account Set-up and RBAC

Before executing any test cases that use the web interfaces, accounts must be

established. As shown in Figure 4.3.1-1, testing scenarios 2 and 3 are directly related

to establishing direct billed accounts and then enabling access to EIS web interfaces

based on a user’s role. Based on the set-up information received with each task order

(TO), agencies and their authorized users are configured within the internal system’s

user set-up, establishing secure access to the web interfaces. For testing, CenturyLink

will establish all user accounts required for BSS verification testing. Once entered, the

user accounts are immediately available for accessing the CenturyLink EIS web

interfaces by entering username and password.




20 November 4, 2016


Figure 4.3.1-1. Test Case 1: Account Set-up and RBAC

Authentication and authorization (A&A) are very important to the security and

ordering structure required to access CenturyLink’s BSS. Agency personnel use

credentials stored with FIPS 140-2-compliant encryption in an EIS BSS gateway

database. Privileged users (CenturyLink administrators) use centrally managed

credentials and individual digital certificates as two-factor authentication to access the

application.

Once agency users have been properly authenticated to the EIS BSS gateway, they

are able to conduct their business based upon their role and assigned security

parameters that have been approved by the agency’s Ordering Contracting Officer




21 November 4, 2016


(OCO). Users may have BSS credentials but have access limited by the Contracting

Officer’s Representative (COR); they may have the ability to see services and run

reports, but not to order or modify services provided to their agency.

The CenturyLink web interfaces are accessed from the public Internet through

encrypted HTTPS sessions that traverse the “demilitarized zone” (DMZ), set forth in

Figure 4.3.7-1, first through the Internet-facing firewalls, then through a redundant set

of web servers that act as proxies residing in the DMZ, and finally through a second set

of firewalls to the interface servers. All of the servers involved are clustered to meet

required availability SLAs and ensure continuity for the user experience.

4.3.2 Test Case 2: Service Ordering Lifecycle

Order type requests allow for new services, moves, disconnects, feature changes,

telecommunications service priority (TSP), auto-sold CLINs, and bulk orders. Orders for

new services will establish the initial billing and inventory information for the respective

services. Moves, changes, and disconnects to these newly established services will be

made through additional service order cycles, with relevant inventory and billing

changes reflected as discussed below.




22 November 4, 2016


Figure 4.3.2-1. Service Ordering Lifecycle

4.3.2.1 Inventory and Billing

Inventory scenario tasks will be conducted in every case except tests that involve

cancellation of an order prior to service order completion. Inventory tests will be

conducted to validate all data contained within the SOCN appears in the inventory,




23 November 4, 2016


including agency hierarchy code, task order ID, ASRNs, and UBI. Inventory validation

tasks will also include confirmation that all information appears on subsequent changes

in the service configuration.

4.3.3 Test Case 3: In-progress Order Changes Lifecycle

CenturyLink will process change order requests that are made prior to issuance of

the SOCN. In this test case, an order will be generated that duplicates an order initiated

in Test Case 2 and then order updates will be entered before the generation of the

SOCN. These in-progress orders will include:

Cancel orders


Location changes

Changes to customer want date

Changes to administrative data

Confirmation that these in-progress changes have been made correctly will be

obtained by comparing (as relevant) the SOAs, the SOCNs, inventory, and billing data

between the Test Case 2 order and the order(s) produced in Test Case 3.




24 November 4, 2016


Figure 4.3.3-1. In Process Order Change Flow

4.3.4 Test Case 4: Provisioned Order Administrative Changes Lifecycle

As described in RFP Section G.3.3.2.2.4, administrative change orders may only

modify inventory data points provided by the government that have no impact on service

delivery or pricing. Only the ASRN 1, ASRN 2, and AHC fall into this category by

default.




25 November 4, 2016


Figure 4.3.4-1. Administrative Change Flow

4.3.5 Test Case 5: Self-Service/Rapid Provisioned Order Lifecycle

Services such as IaaS and Ethernet Transport (ETS) that have been provisioned

through Test Cases 2, 3, and 4 can allow the user to initiate self-service/rapid

provisioning orders. These orders include: for IaaS - configuration management,

topology management, etc., and for Ethernet Transport - bandwidth-on-demand. Other

types of rapid provisioning orders may be defined at the time of the TO. The ability to

place self-service/rapid provisioned orders will be restricted by the RBAC and the type

of service. Testing for these orders will reflect both positive and negative conditions

using correct and incorrect orders allowed for that service.




26 November 4, 2016


Figure 4.3.5-1. Self-Service/Rapid Provisioned Flow

4.3.6 Test Case 6: Disputes

Disputes will be issued by the government over a billing invoice (BI), inventory

reconciliation (IR), or SLA credit request (SLACR). If accepted, adjustments will be

made to the inventory and the billing files. These adjustments will be reflected in the

billing adjustment (BA), BI, and IR reports that are generated after the adjustments are

made.




27 November 4, 2016


Figure 4.3.6-1. Disputes Test Flow

4.3.7 Test Case 7: Security

4.3.7.1 Security Features

CenturyLink will demonstrate that its BSS meets FISMA moderate requirements. As

reflected in Figure 4.3.7-1, CenturyLink’s EIS BSS Assessment Boundary (EBAB) and

scope includes the following features:

The design uses CenturyLink’s commercial systems portals to access back-office

systems

EIS web traffic will stay encrypted all the way through commercial reverse-proxy

servers in a network DMZ, leaving those proxies out of scope for testing.

Encrypted web access will terminate at the EIS presentation access servers

within the EBAB

Dedicated, EIS-specific WAF functionality will reside in the EBAB to block and

alert on attempts to gain unauthorized access via SQL injection, cross-site

scripting, or other means




29 November 4, 2016


operations personnel use SecurID-based two-factor authentication to access network

elements, which include the firewalls protecting the EIS BSS Gateway systems.

Once agency users have been properly authenticated to access systems within the

EBAB, they will be able to conduct their business based on their role and assigned

security parameters that have been approved by the agency’s OCO.

Systems within the EBAB will store customer authentication credentials and

authority information that define the access permissions of each individual. They will not

store information about orders, services, performance, or reporting. Databases are

configured according to the latest CenturyLink standards. Only EIS BSS Gateway

database administrators and the EIS BSS Gateway application itself will be able to

access an EIS BSS Gateway database. Agency users, CenturyLink EBAB application

administrators, non-EIS applications, and other databases will not have access to any

EIS BSS Gateway database. EIS BSS Gateway databases will share no access links

with other databases.

4.3.7.3 EIS BSS Gateway and EBAB architecture

Systems and software in the EBAB will log to security monitoring systems in real

time, monitoring access, file integrity, and configuration integrity. Cyber defense network

monitoring (intrusion detection & prevention systems) will continue to operate with

sensors on both sides of the network perimeter and inside the corporate network.

The EIS BSS Gateway and EBAB architecture is provided in Figure 4.3.7-1. As with

all Internet-facing systems, CenturyLink will place reverse-proxy servers in a network

DMZ to accept the packets from the Internet destined for systems in the EBAB. The

proxies translate the outward-facing, publicly routable IP address to an internal address

and then forward the network traffic. As with all components within the EBAB, the

reverse-proxy servers will operate as a load-balanced, redundant set so that the loss of

one server will not impact the operation of the components within the EBAB. All of the

primary components will operate in this mode to essentially eliminate the potential of the

system within the EBAB going offline as a result of the loss of a system component. The

servers will be high-availability models that add another level of redundancy. IP blocking

protection will be provided by CenturyLink firewalls.




30 November 4, 2016


The firewalls fronting the EBAB will be tightly controlled and allow only the ports and

protocols necessary for EIS BSS access from federal customers. All other protocols,

ports, and services to the EBAB will be blocked. Firewalls then pass allowed Internet

traffic to servers inside the EBAB.

The firewall rules that control traffic between the public Internet and the EBAB

servers (through reverse-proxy servers) will be evaluated for security A&A. The firewalls

and firewall management systems surrounding the gateway will not inherit controls from

another FISMA assessment boundary. Unrelated, commercial firewall rules, systems,

and technical firewall management systems are not in the scope of A&A. Dedicated

WAF functionality within the EBAB monitors traffic for a wide array of potential cyber

attacks and other nefarious traffic. The WAF blocks such traffic, and terminates

sessions that initiate it, to protect EIS BSS Gateway systems and back-office systems

from Internet cyber attacks.

The EIS BSS Gateway servers will access the CenturyLink BSS back-office systems

and retrieve information for the users through the commercial business systems

interface servers shown in Figure 4.3.7-1. Those links will be controlled by the EIS BSS

Gateway application and remain active only on an as-needed basis to limit the potential

of data compromise.

Firewall rules limit connections from the Internet to the reverse-proxy servers to only

one SSL-encrypted web service port (443). Access control lists (IP addresses) will

permit only EIS BSS Gateway application servers to access EIS databases using

application credentials. The firewalls surrounding the EBAB will not inherit controls from

another FISMA assessment boundary.

The EIS BSS Gateway servers will be high-availability devices that are deployed in

redundant pairs. The servers provide authentication services to federal agency-

approved users. The users will have access to the EIS BSS Gateway application that

displays options and information based upon the user’s agency, role, and authorized

services. Users’ activities will be tightly controlled, and actions that result in data being

written or changed in databases will be auditable. The EIS BSS Gateway database

servers will share access to an EIS-dedicated storage system.




31 November 4, 2016


CenturyLink commercial back office systems cannot initiate data transfers with

systems inside the EBAB. The business systems interface servers will initiate requests

(as they are passed from the user through the EIS BSS Gateway) for data and services

from the CenturyLink commercial back office systems, on demand, as requested by

EBAB system users. Such information will be transferred outside of the EBAB only in

the sense that each user sees information appropriate to the user in the user's browser

display.

4.3.8 Test Case 8: Regression

As noted in Section 4.2.1, regression testing will not apply to initial BSS

development. It will be detailed in the final BSS Test Plan submitted 30 days after NTP.

Regression testing will follow the BSS change control practices described in the PMP,

Section 9.4.2.

4.4 TEST ACCEPTANCE, RESULTS, REPORTING (E.2.1.3, E.2.1.4, E.2.1.5.2,

E.2.2.4)

This section also explains how the results of CenturyLink’s tests are documented

and communicated to the government. For internal testing, CenturyLink uses an

interactive system called application lifecycle management (ALM). This system

has all test cases built into it. In ALM, steps are created, owners are assigned, and

other pertinent fields are set up for the test cases. As the steps are being run, they are

either passed or failed. If the test step fails, then a defect is opened in the system and

assigned to the appropriate CenturyLink IT resource who will assess the root cause of

the defect and its priority/severity. Once the status has changed to “fixed”, then retesting

occurs.

Test Acceptance

CenturyLink will demonstrate that it successfully meets the BSS acceptance criteria

for the test scenarios/test cases defined in RFP Sections E.2.1.2 and E.2.1.3.




32 November 4, 2016


CenturyLink will provide test results that provide details of testing the following:

Functional requirements for the Ordering, Billing, Inventory Management,

Disputes, SLA Management and trouble ticketing processes as described in RFP

Section G and J.2.

System to system data exchange mechanism requirements defined in Section

G.5 for each CDRLs defined in RFP Section J.2.

Correct CDRLs are used in the data exchange.

Mandatory data elements for each CDRL defined in RFP Section J.2.10 Data

Dictionary are populated and accurate.

Available optional data elements for each CDRL defined in RFP Section J.2.10

Data Dictionary are populated and accurate.

Timely and successful system to system data exchange to meet defined

performance SLAs and provisioning intervals.

The test results, at a minimum, shall detail test scenario # / test case # / test data set

# / test #; date of test, acceptance criteria, and test result (pass/fail).

Test Results

CenturyLink will provide test results that will provide details of testing the following:

Functional requirements for the Ordering, Billing, Inventory Management,

Disputes, SLA Management and trouble ticketing processes as described in RFP

Sections G and J.2.

System to system data exchange mechanism requirements defined in RFP

Section G.5 for each CDRLs defined in RFP Section J.2.

Correct CDRLs are used in the data exchange.

Mandatory data elements for each CDRL defined in RFP Section J.2.10 Data

Dictionary are populated and accurate.

Available optional data elements for each CDRL defined in RFP Section J.2.10

Data Dictionary are populated and accurate.

Timely and successful system to system data exchange to meet defined

performance SLAs and provisioning intervals.




33 November 4, 2016


BSS Functional Testing Acceptance (E.2.1.3)

BSS functional testing is not complete until all BSS test scenarios (RFP Section

E.2.1.2) are passed. A test scenario is not passed until the BSS properly handles each

associated test case. A test case is not passed until the BSS properly handles each

associated subcase twice in succession using different data sets. A subcase is not

passed until the BSS properly handles the data sets following the prescribed actions

with no errors or warnings. Functionaly defined test cases for required BSS capabilities

are detailed in Section 4.3 and its subsections.

Test Results Report

CenturyLink will provide a BSS Verification Test Results Report that includes

analysis of the current testing and a summary table of all previously submitted test

results, within seven days after performance of the tests. The government reserves

fourteen days to accept or reject the test results, in part or in whole.

CenturyLink will perform re-test of test cases with test data sets that failed until they

are accepted by the government and will rerun tests, in part or in whole, as deemed

necessary by the government, to verify that the government’s comments on the test

results are satisfactorily addressed.

Due to the nature of the required communication and documentation, this system will

only be used internally and not for interaction with the government. CenturyLink will

provide test result data produced by the ALM, to the government. CenturyLink will use

Excel spreadsheets as the documentation for the tests. Each step requires an actual

result to be placed on the spreadsheet. Each step will be either passed or failed and will

be reviewed with CenturyLink business, IT, and other personnel. The government will

have access to all documentation about the test cases performed. The environment

section will define any difference between the production and testing environments.

The test cases and documentation will be configured as follows in Table 4.4-1.

These test cases will be populated and validated during CenturyLink’s agile

development lifecycle and submitted as part the final BSS Test Plan submitted within 30

days after NTP.




34 November 4, 2016


Table 4.4-1. Test Case Elements

Test Case Element Description

Test case name Literal name of the test case being conducted

Test case description Description of what will be covered in the test case

Precondition Any precondition that needs to be noted prior to the execution of the test case. Can

also identify previous test cases that this test case may be predicated on.

Test case start date Provides the date the test case begins

Test case end date Provides the date the test case concludes with full passing

Test case status Provides the current status of the test case

Test scenario status Provides the current status of test scenarios 1-13 in test cases

Test case number ID for the specific test case

Test scenario Identifies, in the individual steps, which test scenario is being covered:

1=Direct Data Exchange

2=TO & Acct Mgt Setup

3=RBAC

4=Service Ordering

5=Supps to In-progress orders

6=Admin Change Orders

7=Self Service/Rapid Provisioning Orders

8=Inventory and Billing

9=Dispute Handling

10=SLA Management

11=Open Format Reporting

12=Regression Testing

13=Security Testing

Step number Identifies the step number being performed.

Manual or system step Identifies the step as a M=Manual or A=Automated step.

Description Provides a full description of what is being run in the test step. Identifies either the

manual or system step being executed or required.

Field name Identifies specific fields on the BSS component being used in execution of test step.

Test data set Identifies the data set being used in the execution of the test case.

Additional information Identifies additional information required for the steps, such as pre-conditions, pre-

loaded data, etc.

Expected results Descr bes the expected result of the test case step. Identifies the threshold for a pass

on the step.

Actual results Descr bes the actual results after executing the test step.

Test case pass/fail indicator Flagged accordingly.

Notes/comments Free form field used to provide any useful commentary or notes on the test step,

execution, or results of the test step.




35 November 4, 2016


4.5 DRAFT TEST PROJECT SCHEDULE

CenturyLink’s current test and project schedule requires all BSS testing to be

completed eight weeks following government acceptance of the test plan. Upon GSA

approval of the plan, CenturyLink will accept test data in the form of XML- and PSV-

formatted usage data. The first step following receipt of testing data is to set up security

profiles in the CenturyLink EIS web interface and account structures. CenturyLink plans

to execute all test cases in the BSS Test Plan using government-provided data.

CenturyLink will communicate the results daily with the government as previously

stated. If an issue during a test should occur, defects will be written and subsequently

reviewed by CenturyLink IT for resolution. After the first round of testing is complete, if

any defects were created and repaired, a second round of testing will commence. The

second round of tests will begin at the order entry stage because security profiles and

accounts were previously created and this action would not need to be redone. The

proposed timeline, in Table 4.5-1, is contingent on receiving test data from the

government and a minimal number of defects discovered, and it could change due to

unforeseen circumstances.

Table 4.5-1. 8-Week Test Schedule

Time Period Item

Weeks 1 & 2 Receive government Test Data

Translate and incorporate government test data into test cases and systems

Conduct Test Case 1 to set up accounts and verify RBAC to all BSS functions

Hold daily meetings

Report test case results to the government

Weeks 3 & 4 Conduct Test Cases 2 and 3 using data with the account and RBAC set-ups based on government data

Hold daily meetings


Weeks 5 & 6 Conduct Test Cases 4 and 5 using data with the account and RBAC set-ups based on government data

Hold daily meetings


Week 7 Conduct Test Case 6 using data with the account and RBAC set-ups based on government data

Hold daily meetings


Week 8 Per Test Case 7, demonstrate that the BSS meets FISMA Moderate requirements

Complete Testing


centurylink draft business support systems (bss ... · supporting ordering, billing, inventory...

Documents