VNF Cloud Readiness Requirements for

VNF Cloud Readiness Requirements for
VNF
Cloud Readiness
Requirements
for
OpenECOMP
Revision
1.0
Revision Date
2/1/2017
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
You may obtain a copy of the License at https://creativecommons.org/licenses/by/4.0/
Unless required by applicable law or agreed to in writing, software distributed under the License is distributed on an "AS IS" BASIS,
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License for the specific language
governing permissions and limitations under the License.
ECOMP and OpenECOMP are trademarks and service marks of AT&T Intellectual Property
Document Revision History
Date
2/1/2017
Revision
1.0
Description
Initial public release of VNF Cloud Readiness Requirements for
OpenECOMP
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page i
Table of Contents
1.0
Introduction........................................................................................................................................ 1
2.0
VNF Design ....................................................................................................................................... 2
3.0
Resiliency .......................................................................................................................................... 3
3.1
All Layer Redundancy ................................................................................................................... 3
3.2
Minimize Cross Data-Center Traffic .............................................................................................. 3
3.3
Application Resilient Error Handling ............................................................................................. 4
3.4
System Resource Optimization ..................................................................................................... 4
3.5
Application Configuration Management ........................................................................................ 5
3.6
Intelligent Transaction Distribution & Management ...................................................................... 5
3.7
Deployment Optimization .............................................................................................................. 5
3.8
Monitoring & Dashboard ............................................................................................................... 6
4.0
Security ............................................................................................................................................. 7
4.1
VNF General Security Requirements ............................................................................................ 7
4.2
VNF Identity and Access Management Requirements ................................................................. 9
4.3
VNF API Security Requirements ................................................................................................. 11
4.4
VNF Security Analytics Requirements ........................................................................................ 12
4.5
VNF Data Protection Requirements ............................................................................................ 14
5.0
DevOps ........................................................................................................................................... 15
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page ii
Definitions
Throughout the document the terms have the following meaning:
MUST This word, or the terms "REQUIRED" or "SHALL", mean that the definition is an absolute
requirement of the specification.
MUST NOT This phrase, or the phrase "SHALL NOT", mean that the definition is an absolute prohibition
of the specification.
SHOULD This word, or the adjective "RECOMMENDED", mean that there may exist valid reasons in
particular circumstances to ignore a particular item, but the full implications must be understood and
carefully weighed before choosing a different course.
SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that there may exist valid
reasons in particular circumstances when the particular behavior is acceptable or even useful, but the full
implications should be understood and the case carefully weighed before implementing any behavior
described with this label.
MAY This word, or the adjective "OPTIONAL", mean that an item is truly optional. One vendor may
choose to include the item because a particular marketplace requires it or because the vendor feels that it
enhances the product while another vendor may omit the same item. An implementation which does not
include a particular option MUST be prepared to interoperate with another implementation which does
include the option, though perhaps with reduced functionality. In the same vein an implementation which
does include a particular option MUST be prepared to interoperate with another implementation which
does not include the option (except, of course, for the feature the option provides.)
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page iii
1. Introduction
This document is part of a hierarchy of documents that describes the overall Requirements and
Guidelines for OpenECOMP. The diagram below identifies where this document fits in the hierarchy.
OpenECOMP Requirements and Guidelines
VNF Guidelines for Network Cloud and OpenECOMP
VNF Cloud
Readiness
Requirements
for
OpenECOMP
VNF
Management
Requirements
for
OpenECOMP
VNF Heat
Template
Requirements
for
OpenECOMP
Future
VNF
Requirements
Documents
Future OpenECOMP
Subject Documents
Future Requirements
Documents
Document summary:
VNF Guidelines for Network Cloud and OpenECOMP
• Describes VNF environment and overview of requirements
VNF Cloud Readiness Requirements for OpenECOMP
• Cloud readiness requirements for VNFs (Design, Resiliency, Security, and DevOps)
VNF Management Requirements for OpenECOMP
• Requirements for how VNFs interact and utilize OpenECOMP
VNF Heat Template Requirements for OpenECOMP
• Provides recommendations and standards for building Heat templates compatible with
OpenECOMP– initial implementations of Network Cloud are assumed to be OpenStack
based.
This reference document lists the requirements that are the supporting details for the Virtual Network
Function (VNF) characteristics outlined in the VNF Guidelines for Network Cloud and OpenECOMP.
These requirements are grouped into the following categories: VNF Design, Resiliency, Security, and
DevOps. Specific requirements for OpenECOMP can be found in the VNF Management Requirements for
OpenECOMP reference document.
This section outlines the guidelines for VNFs to be compliant with running on a multi-tenant, Network
Cloud infrastructure. VNFs must be virtualized, software-based, execute in a multi-tenant cloud, and be
de-coupled from the cloud hardware. To achieve interoperability between VNFs, open and standard
interfaces and APIs must be used. The set of reusable VNFs forms the basis of a VNF catalog that is
made available to service designers to compose new (service chained) services that can include servicespecific custom parameters and QoS policies. Use of open source technologies to leverage industry
innovation is important in the design of virtualized services. Equally important is the re-use of common
technologies (e.g., virtualized load balancers, firewalls, etc.) that are provided by the platform.
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 1
2. VNF Design
Services are composed of VNFs and common components and are designed to be agnostic of the
location to leverage capacity where it exists in the Network Cloud. VNFs can be instantiated in any
location that meets the performance and latency requirements of the service.
A key design principle for virtualizing services is decomposition of network functions using NFV concepts
into granular VNFs. This enables instantiating and customizing only essential functions as needed for the
service, thereby making service delivery more nimble. It provides flexibility of sizing and scaling and also
provides flexibility with packaging and deploying VNFs as needed for the service. It enables grouping
functions in a common cloud data center to minimize inter-component latency. The VNFs should be
designed with a goal of being modular and reusable to enable using best-in-breed vendors
Section 4.1.1 in VNF Guidelines for Network Cloud and OpenECOMP describes the overall guidelines for
designing VNFs from VNF Components (VNFCs). Below are more detailed requirements for composing
VNFs.
1
VNF Design Requirements
Type
ID #
Decompose VNFs into granular re-usable VNFCs
Decompose if the functions have significantly different scaling characteristics (e.g.,
signaling versus media functions, control versus data plane functions).
Decomposition of the VNF must enable instantiating only the functionality that is
needed for the VNF (e.g., if transcoding is not needed it should not be instantiated).
Design VNFC as a standalone, executable process.
Create a single component VNF for VNFCs that can be used by other VNFs.
Design to scale horizontally (more instances of a VNF or VNFC) and not vertically
(moving the existing instances to larger VMs or increasing the resources within a
VM) to achieve effective utilization of cloud resources.
Utilize cloud provided infrastructure and VNFs (e.g., virtualized Local Load
Balancer) as part of the VNF so that the cloud can manage and provide a
consistent service resiliency and methods across all VNF's.
VNFCs should be independently deployed, configured, upgraded, scaled,
monitored, and administered by OpenECOMP.
Provide API versioning to allow for independent upgrades of VNFC.
Minimize the use of state within a VNFC to facilitate the movement of traffic from
one instance to another.
Maintain state in a geographically redundant datastore that may, in fact, be its own
VNFC.
Decouple persistent data from the VNFC and keep it in its own datastore that can
be reached by all instances of the VNFC requiring the data.
Utilize virtualized, scalable open source database software that can meet the
performance/latency requirements of the service for all datastores.
Failure of a VNFC instance must not terminate stable sessions.
Enable DPDK in the guest OS for VNF’s requiring high packets/sec performance.
High packet throughput is defined as greater than 500K packets/sec.
When using DPDK, use the NCSP’s supported library and compute flavor that
supports DPDK to optimize network efficiency. 1
Do not use technologies that bypass virtualization layers (such as SR-IOV) unless
approved by the NCSP (e.g., if necessary to meet functional or performance
requirements).
Should
Must
20010
20020
Must
20030
Must
Should
Must
20040
20050
20060
Must
20070
Should
20080
Must
Should
20090
20100
Should
20110
Should
20120
Must
20130
Must
Must
20140
20150
Must
20160
Must
20170
Refer to NCSP’s Network Cloud specification
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 2
VNF Design Requirements
Type
ID #
Limit the size of application data packets to no larger than 907400 bytes for SDN
network-based tunneling when guest data packets are transported between tunnel
endpoints that support guest logical networks.
Do not require the use of a dynamic routing protocol unless necessary to meet
functional requirements.
Must
20180
Must
20190
3. Resiliency
The VNF is responsible for meeting its resiliency goals and must factor in expected availability of the
targeted virtualization environment. This is likely to be much lower than found in a traditional data center.
Resiliency is defined as the ability of the VNF to respond to error conditions and continue to provide the
service intended. A number of software resiliency dimensions have been identified as areas that should
be addressed to increase resiliency. As VNFs are deployed into the Network Cloud, resiliency must be
designed into the VNF software to provide high availability versus relying on the Network Cloud to
achieve that end.
Section 4.1.2 in VNF Guidelines for Network Cloud and OpenECOMP describes the overall guidelines for
designing VNFs to meet resiliency goals. Below are more detailed resiliency requirements for VNFs.
3.1
All Layer Redundancy
Design the VNF to be resilient to the failures of the underlying virtualized infrastructure (Network Cloud).
VNF design considerations would include techniques such as multiple vLANs, multiple local and
geographic instances, multiple local and geographic data replication, and virtualized services such as
Load Balancers.
All Layer Redundancy Requirements
Type
ID #
VNFs are responsible to meet their own resiliency goals and not rely on the
Network Cloud.
Design resiliency into a VNF such that the resiliency deployment model (e.g.,
active-active) can be chosen at run-time.
VNFs must survive any single points of failure within the Network Cloud (e.g., virtual
NIC, VM, disk failure).
VNFs must survive any single points of software failure internal to the VNF (e.g., in
memory structures, JMS message queues).
Design, build and package VNFs to enable deployment across multiple fault zones
(e.g., VNFCs deployed in different servers, racks, OpenStack regions, geographies)
to increase the overall resiliency of the VNF.
Support the ability to failover a VNFC automatically to other geographically
redundant sites if not deployed active-active to increase the overall resiliency of the
VNF.
Support the ability of the VNFC to be deployable in multi-zoned cloud sites to allow
for site support in the event of cloud zone failure or upgrades.
Must
30010
Must
30020
Must
30030
Must
30040
Must
30050
Must
30060
Must
30070
3.2
Minimize Cross Data-Center Traffic
Avoid performance-sapping data center-to-data center replication delay by applying techniques such as
caching and persistent transaction paths - Eliminate replication delay impact between data centers by
using a concept of stickiness (i.e., once a client is routed to data center "A", the client will stay with Data
center “A” until the entire session is completed).
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 3
Minimize Cross Data-Center Traffic Requirements
Type
ID #
Minimize the propagation of state information across multiple data centers to avoid
cross data center traffic.
Should
31010
3.3
Application Resilient Error Handling
Ensure an application communicating with a downstream peer is equipped to intelligently handle all error
conditions. Make sure code can handle exceptions seamlessly - implement smart retry logic and
implement multi-point entry (multiple data centers) for back-end system applications.
Application Resilient Error Handling Requirements
Type
ID #
Detect connectivity failure for inter VNFC instance and intra/inter VNF and reestablish connectivity automatically to maintain the VNF without manual
intervention to provide service continuity.
Handle the restart of a single VNFC instance without requiring all VNFC instances
to be restarted.
Handle the start or restart of VNFC instances in any order with each VNFC instance
establishing or re-establishing required connections or relationships with other
VNFC instances and/or VNFs required to perform the VNF function/role without
requiring VNFC instance(s) to be started/restarted in a particular order.
Handle errors and exceptions so that they do not interrupt processing of incoming
VNF requests to maintain service continuity.
Provide the ability to modify the number of retries, the time between retries and the
behavior/action taken after the retries have been exhausted for exception handling
to allow the Network Cloud Service Provider to control that behavior.
Fully exploit exception handling to the extent that resources (e.g., threads and
memory) are released when no longer needed regardless of programming
language.
Handle replication race conditions both locally and geo-located in the event of a
data base instance failure to maintain service continuity.
Automatically retry/resubmit failed requests made by the software to its downstream
system to increase the success rate.
Must
32010
Must
32020
Must
32030
Must
32040
Must
32050
Must
32060
Must
32070
Must
32080
3.4
System Resource Optimization
Ensure an application is using appropriate system resources for the task at hand; for example, do not use
network or IO operations inside critical sections, which could end up blocking other threads or processes
or eating memory if they are unable to complete. Critical sections should only contain memory operation,
and should not contain any network or IO operation.
System Resource Optimization Requirements
Type
ID #
Do not execute long running tasks (e.g., IO, database, network operations, service
calls) in a critical section of code, so as to minimize blocking of other operations
and increase concurrent throughput.
Automatically advertise newly scaled components so there is no manual
intervention required.
Utilize FQDNs (and not IP address) for both Service Chaining and scaling.
Deliver any and all functionality from any VNFC in the pool. The VNFC pool
member should be transparent to the client. Upstream and downstream clients
should only recognize the function being performed, not the member performing it.
Automatically enable/disable added/removed sub-components or component so
there is no manual intervention required.
Support the ability to scale down a VNFC pool without jeopardizing active sessions.
Ideally, an active session should not be tied to any particular VNFC instance.
Must
33010
Must
33020
Must
Must
33030
33040
Should
33050
Should
33060
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 4
Support load balancing and discovery mechanisms in resource pools containing
VNFC instances.
Utilize resource pooling (threads, connections, etc.) within the VNF application so
that resources are not being created and destroyed resulting in resource
management overhead.
Use techniques such as “lazy loading” when initialization includes loading
catalogues and/or lists which can grow over time, so that the VNF startup time does
not grow at a rate proportional to that of the list.
Release and clear all shared assets (memory, database operations, connections,
locks, etc.) as soon as possible, especially before long running sync and
asynchronous operations, so as to not prevent use of these assets by other
entities.
3.5
Should
33070
Should
33080
Should
33090
Should
33100
Application Configuration Management
Leverage configuration management audit capability to drive conformity to develop gold configurations for
technologies like Java, Python, etc.
Application Configuration Management Requirements
Type
ID #
Allow configurations and configuration parameters to be managed under version
control to ensure consistent configuration deployment, traceability and rollback.
Allow configurations and configuration parameters to be managed under version
control to ensure the ability to rollback to a known valid configuration.
Allow changes of configuration parameters to be consumed by the VNF without
requiring the VNF or its sub-components to be bounced so that the VNF availability
is not effected.
Must
34010
Must
34020
Must
34030
3.6
Intelligent Transaction Distribution & Management
Leverage Intelligent Load Balancing and redundant components (hardware and modules) for all
transactions, such that at any point in the transaction: front end, middleware, back end -- a failure in any
one component does not result in a failure of the application or system; i.e., transactions will continue to
flow, albeit at a possibly reduced capacity until the failed component restores itself. Create redundancy in
all layers (software and hardware) at local and remote data centers; minimizing interdependencies of
components (i.e. data replication, deploying non-related elements in the same container).
Intelligent Transaction Distribution & Management Requirements
Type
ID #
Use intelligent routing by having knowledge of multiple downstream/upstream
endpoints that are exposed to it, to ensure there is no dependency on external
services (such as load balancers) to switch to alternate endpoints.
Use redundant connection pooling to connect to any backend data source that can
be switched between pools in an automated/scripted fashion to ensure high
availability of the connection to the data source.
Include control loop mechanisms to notify the consumer of the VNF of their
exceeding SLA thresholds so the consumer is able to control its load against the
VNF.
Should
35010
Should
35020
Should
35030
3.7
Deployment Optimization
Reduce opportunity for failure, by human or by machine, through smarter deployment practices and
automation. This can include rolling code deployments, additional testing strategies, and smarter
deployment automation (remove the human from the mix).
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 5
Deployment Optimization Requirements
Type
ID #
Support at least two major versions of the VNF software and/or sub-components to
co-exist within production environments at any time so that upgrades can be
applied across multiple systems in a staggered manner.
Support the existence of multiple major/minor versions of the VNF software and/or
sub-components and interfaces that support both forward and backward
compatibility to be transparent to the Service Provider usage.
Support staggered/rolling deployments between its redundant instances to allow
"soak-time/burn in/slow roll" which can enable the support of low traffic loads to
validate the deployment prior to supporting full traffic loads.
Support the ability of a requestor of the service to determine the version (and
therefore capabilities) of the service so that Network Cloud Service Provider can
understand the capabilities of the service.
Test for adherence to the defined performance budgets at each layer, during each
delivery cycle with delivered results, so that the performance budget is measured
and the code is adjusted to meet performance budget.
Test for adherence to the defined performance budget at each layer, during each
delivery cycle so that the performance budget is measured and feedback is
provided where the performance budget is not met.
Test for adherence to the defined resiliency rating recommendation at each layer,
during each delivery cycle with delivered results, so that the resiliency rating is
measured and the code is adjusted to meet software resiliency requirements.
Test for adherence to the defined resiliency rating recommendation at each layer,
during each delivery cycle so that the resiliency rating is measured and feedback is
provided where software resiliency requirements are not met.
Must
36010
Must
36020
Must
36030
Must
36040
Must
36050
Must
36060
Should
36070
Should
36080
3.8
Monitoring & Dashboard
Promote dashboarding as a tool to monitor and support the general operational health of a system. It is
critical to the support of the implementation of many resiliency patterns essential to the maintenance of
the system. It can help identify unusual conditions that might indicate failure or the potential for failure.
This would contribute to improve Mean Time to Identify (MTTI), Mean Time to Repair (MTTR), and postincident diagnostics.
Monitoring & Dashboard Requirements
Type
ID #
Provide a method of metrics gathering for each layer's performance to
identify/document variances in the allocations so they can be addressed.
Provide unique traceability of a transaction through its life cycle to ensure quick and
efficient troubleshooting.
Provide a method of metrics gathering and analysis to evaluate the resiliency of the
software from both a granular as well as a holistic standpoint. This includes, but is
not limited to thread utilization, errors, timeouts, and retries.
Provide operational instrumentation such as logging, so as to facilitate quick
resolution of issues with the VNF to provide service continuity.
Monitor for and alert on (both sender and receiver) errant, running longer than
expected and missing file transfers, so as to minimize the impact due to file transfer
errors.
Use an appropriately configured logging level that can be changed dynamically, so
as to not cause performance degradation of the VNF due to excessive logging.
Utilize Cloud health checks, when available from the Network Cloud, from inside the
application through APIs to check the network connectivity, dropped packets rate,
injection, and auto failover to alternate sites if needed.
Must
37010
Must
37020
Must
37030
Must
37040
Must
37050
Should
37060
Should
37070
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 6
Conduct a resiliency impact assessment for all inter/intra-connectivity points in the
VNF to provide an overall resiliency rating for the VNF to be incorporated into the
software design and development of the VNF.
Must
37080
4. Security
The objective of this section is to provide the key security requirements that need to be met by VNFs. The
security requirements are grouped into five areas as listed below. Other security areas will be addressed
in future updates. These security requirements are applicable to all VNFs. Additional security
requirements for specific types of VNFs will be applicable and are outside the scope of these general
requirements.
Section 4.1.3 in VNF Guidelines for Network Cloud and OpenECOMP outlines the five broad security
areas for VNFs that are detailed in the following sections:
•
•
•
•
•
4.1
VNF General Security: This section addresses general security requirements for the
VNFs that the vendors will need to address.
VNF Identity and Access Management: This section addresses security requirements
with respect to Identity and Access Management as these pertain to generic VNFs.
VNF API Security: This section addresses the generic security requirements associated
with APIs. These requirements are applicable to those VNFs that use standard APIs for
communication and data exchange.
VNF Security Analytics: This section addresses the security requirements associated
with analytics for VNFs that deal with monitoring, data collection and analysis.
VNF Data Protection: This section addresses the security requirements associated with
data protection.
VNF General Security Requirements
This section provides details on the VNF general security requirements on various security areas such as
user access control, network security, ACLs, infrastructure security, and vulnerability management. These
requirements cover topics associated with compliance, security patching, logging/accounting,
authentication, encryption, role-based access control, least privilege access/authorization. The following
security requirements need to be met by the solution in a virtual environment:
General Security Requirements
Type
Integration and operation within a robust security environment is necessary and
expected. The security architecture will include one or more of the following:
IDAM (Identity and Access Management) for all system and applications access,
Code scanning, network vulnerability scans, OS, Database and application
patching, malware detection and cleaning, DDOS prevention, network security
gateways (internal and external) operating at various layers, host and application
based tools for security compliance validation, aggressive security patch
application, tightly controlled software distribution and change control processes
and other state of the art security solutions. The VNF is expected to function
reliably within such an environment and the developer is expected to understand
and accommodate such controls and can expected to supply responsive
interoperability support and testing throughout the product’s lifecycle.
The VNF must accommodate the security principle of “least privilege” during
development, implementation and operation. The importance of “least privilege”
cannot be overstated and must be observed in all aspects of VNF development
and not limited to security. This is applicable to all sections of this document.
Implement access control list for OA&M services (e.g., restricting access to
certain ports or applications).
Informational 40010
Must
40020
Must
40030
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 7
ID #
General Security Requirements
Type
ID #
Implement Data Storage Encryption (database/disk encryption) for Sensitive
Personal Information (SPI) and other subscriber identifiable data. Note:
subscriber’s SPI/data must be encrypted at rest, and other subscriber identifiable
data should be encrypted at rest. Other data protection requirements exist and
should be well understood by the developer.
Implement a mechanism for automated and frequent "system configuration
(automated provisioning / closed loop)" auditing.
Use both network scanning and application scanning security tools on all code,
including underlying OS and related configuration. Scan reports shall be
provided. Remediation roadmaps shall be made available for any findings.
Perform source code to scanning tools (e.g., Fortify) and provide reports.
Production code shall be distributed from NCSP internal sources only. No
production code, libraries, OS images, etc. shall be distributed from publically
accessible depots.
Provide all code/configuration files in a “Locked down” or hardened state or with
documented recommendations for such hardening. All unnecessary services will
be disabled. Vendor default credentials, community strings and other such
artifacts will be removed or disclosed so that they can be modified or removed
during provisioning.
Support L3 VPNs that enable segregation of traffic by application (dropping
packets not belonging to the VPN) (i.e., AVPN, IPSec VPN for Internet routes).
Interoperate with various access control mechanisms for the Network Cloud
execution environment (e.g., Hypervisors, containers).
VNF should support the use of virtual trusted platform module, hypervisor security
testing and standards scanning tools.
Interoperate with the OpenECOMP (SDN) Controller so that it can dynamically
modify the firewall rules, ACL rules, QoS rules, virtual routing and forwarding
rules.
Support the ability to work with aliases (e.g., gateways, proxies) to protect and
encapsulate resources.
All access to applications (Bearer, signaling and OA&M) will pass through various
security tools and platforms from ACLs, stateful firewalls and application layer
gateways depending on manner of deployment. The application is expected to
function (and in some cases, interwork) with these security tools.
Patch vulnerabilities in VNFs as soon as possible. Patching shall be controlled via
change control process with vulnerabilities disclosed along with mitigation
recommendations.
Identification, authentication and access control of customer or VNF application
users must be performed by utilizing the NCSP’s IDAM API.
Identification, authentication and access control of OA&M and other system level
functions must use the NCSP’s IDAM API or comply with the following is
expected.
Support User-IDs and passwords to uniquely identify the user/application.
VNF needs to have appropriate connectors to the Identity, Authentication
and Authorization systems that enables access at OS, Database and
Application levels as appropriate.
Provide the ability to support Multi-Factor Authentication (e.g., 1st factor =
Software token on device (RSA SecureID); 2nd factor = User
Name+Password, etc.) for the users.
Support Role-Based Access Control to permit/limit the user/application to
performing specific activities.
Support logging via OpenECOMP for a historical view of “who did what and
when”.
Must
40040
Should
40050
Should
40060
Should
Must
40070
40080
Must
40090
Should
40100
Should
40110
Should
40120
Must
40130
Should
40140
Must
40150
Must
40160
Must
40170
Must
40180
Must
40190
Must
40200
Must
40210
Must
40220
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 8
General Security Requirements
Encrypt OA&M access (e.g., SSH, SFTP).
Enforce a configurable maximum number of Login attempts policy for the
users. VNF vendor must comply with "terminate idle sessions" policy.
Interactive sessions must be terminated, or a secure, locking screensaver
must be activated requiring authentication, after a configurable period of
inactivity. The system-based inactivity timeout for the enterprise identity and
access management system must also be configurable.
Comply with the NCSP’s credential management policy.
Password expiration must be required at regular configurable intervals.
Comply with "password complexity" policy. When passwords are used, they
shall be complex and shall at least meet the following password construction
requirements:
•
Be a minimum configurable number of characters in length.
•
Include 3 of the 4 following types of characters: upper-case
alphabetic, lower-case alphabetic, numeric, and special.
•
Not be the same as the UserID with which they are associated or
other common strings as specified by the environment.
•
Not contain repeating or sequential characters or numbers.
•
Not to use special characters that may have command functions.
•
New passwords must not contain sequences of three (3) or more
characters from the previous password.
Comply with "password changes (includes default passwords)" policy.
Products will support password aging, syntax and other credential
management practices on a configurable basis.
Support use of common third party authentication and authorization tools
such as TACACS+, RADIUS.
Comply with "No Self-Signed Certificates" policy. Self-signed certificates
must be used for encryption only, using specified and approved encryption
protocols such as LS 1.1 or higher or equivalent security protocols such as
IPSec, AES.
Authenticate system to system communications where one system accesses
the resources of another system, and must never conceal individual
accountability.
4.2
Type
ID #
Must
Must
40230
40240
Must
Must
Must
40250
40260
40270
Must
40280
Must
40290
Must
40300
Must
40310
VNF Identity and Access Management Requirements
The following security requirements for logging, identity, and access management need to be met by the
solution in a virtual environment:
Identity and Access Management Requirements
Access to VNFs will be required at several layers. Hence, VNF vendor needs to be
able to host connectors for access to the following layers:
a. Application
b. OS (Operating System)
c. Database
Manage access to VNF, its OS, or Database by an enterprise access request
process.
Comply with the following when persons or non-person entities access VNFs:
a. Individual Accountability (each person must be assigned a unique ID)
b. Least Privilege (no more privilege than required to perform job functions)
c. Segregation of Duties (access to a single layer and no developer may
access production without special oversight)
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 9
Type
ID #
Must
Must
Must
Must
41010
41020
41030
41040
Must
Must
Must
41050
41060
41070
Identity and Access Management Requirements
Type
ID #
Vendors will not be allowed to access VNFs remotely, e.g., VPN
Vendors accessing VNFs through a client application API must be authorized by the
client application owner and the resource owner of the VNF before provisioning
authorization through Role Based Access Control (RBAC), Attribute Based Access
Control (ABAC), or other policy based mechanism.
Vendor VNF access will be subject to privilege reconciliation tools to prevent access
creep and ensure correct enforcement of access policies.
Provide or Support the Identity and Access Management (IDAM) based threat
detection data for:
a. OWASP Top 10
b. Password Attacks
c. Phishing / SMishing
d. Malware (Key Logger)
e. Session Hijacking
f. XSS / CSRF
g. Replay
h. Man in the Middle (MITM)
i. Eavesdropping
Provide Context awareness data (device, location, time, etc.) and be able to
integrate with threat detection system.
Where a VNF vendor requires the assumption of permissions, such as root or
administrator, the vendor user must first log in under their individual user login ID
then switch to the other higher level account; or where the individual user login is
infeasible, must login with an account with admin privileges in a way that uniquely
identifies the individual performing the function.
Authenticate system to system access and do not conceal a VNF vendor user’s
individual accountability for transactions.
Warning Notices: A formal statement of resource intent, i.e., a warning notice, must
be made visible upon initial access to a VNF vendor user who accesses private
internal networks or Company computer resources, e.g., upon initial logon to an
internal web site, system or application which requires authentication.
Use access controls for VNFs and their supporting computing systems at all times to
restrict access to authorized personnel only, e.g., least privilege. These controls
could include the use of system configuration or access control software.
a. Initial and default settings for new user accounts must provide minimum
privileges only.
b. Default settings for user access to sensitive commands and data must be
denied authorization.
c. Privileged users may be created conforming to approved request, workflow
authorization, and authorization provisioning requirements.
d. Commands affecting network services, such as commands relating to VNFs,
must have greater restrictions for access and execution, such as up to 3
factors of authentication and restricted authorization.
Encrypt TCP/IP--HTTPS (e.g., TLS v1.2) transmission of data on internal and
external networks.
Unnecessary or vulnerable cgi-bin programs must be disabled.
No public or unrestricted access to any data should be provided without the
permission of the data owner. All data classification and access controls must be
followed.
When in production, vendors or developers must not do the following without
authorization of the VNF system owner including:
a. Install or use systems, tools or utilities capable of capturing or logging data
that was not created by them or sent specifically to them;
Must
Must
41080
41090
Must
41100
Must
Must
Must
Must
Must
Must
Must
Must
Must
Must
41110
41120
41130
41140
41150
41160
41170
41180
41190
41200
Must
41210
Must
41220
Must
41230
Must
41240
Must
41250
Must
41260
Must
41270
Must
41280
Must
41290
Must
Must
41300
41310
Must
41320
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 10
Identity and Access Management Requirements
Type
ID #
b. Run security testing tools and programs, e.g., password cracker, port
scanners, hacking tools.
Authentication credentials must not be included in security audit logs, even if
encrypted.
The standard interface for a VNF should be REST APIs exposed to Client
Applications for the implementation of OAuth 2.0 Authorization Code Grant and
Client Credentials Grant.
Support hosting connectors for OS Level and Application Access.
Support SCEP (Simple Certificate Enrollment Protocol).
Must
41330
Must
41340
Should
41350
Should
Should
41360
41370
4.3
VNF API Security Requirements
This section covers API security requirements when these are used by the VNFs. Key security areas
covered in API security are Access Control, Authentication, Passwords, PKI Authentication Alarming,
Anomaly Detection, CALEA, Monitoring and Logging, Input Validation, Cryptography, Business continuity,
Biometric Authentication, Identification, Confidentiality and Integrity, and Denial of Service.
The solution in a virtual environment needs to meet the following API security requirements:
API Requirements
Type
ID #
Provide a mechanism to restrict access based on the attributes of the VNF and the
attributes of the subject.
Integrate with external authentication and authorization services (e.g., IDAM).
Use certificates issued from publicly recognized Certificate Authorities (CA) for the
authentication process where PKI-based authentication is used
Validate the CA signature on the certificate, ensure that the date is within the validity
period of the certificate, check the Certificate Revocation List (CRL), and recognize
the identity represented by the certificate where PKI-based authentication is used.
Protect the confidentiality and integrity of data at rest and in transit from
unauthorized access and modification.
Protect against all denial of service attacks, both volumetric and non-volumetric, or
integrate with external denial of service protection tools
Implement at minimum the following input validation controls:
a. Check the size (length) of all input. Do not permit an amount of input so
great that it would cause the VNF to fail. Where the input may be a file, the
VNF API must enforce a size limit.
b. Do not permit input that contains content or characters inappropriate to the
input expected by the design. Inappropriate input, such as SQL insertions,
may cause the system to execute undesirable and unauthorized
transactions against the database or allow other inappropriate access to the
internal network.
c. Validate that any input file has a correct and valid Multipurpose Internet Mail
Extensions (MIME) type. Input files should be tested for spoofed MIME
types.
Validate input at all layers implementing VNF APIs.
Comply with NIST standards and industry best practices for all implementations of
cryptography
Implement all monitoring and logging as described in the Security Analytics section.
Restrict changing the criticality level of a system security alarm to administrator(s).
Monitor API invocation patterns to detect anomalous access patterns that may
represent fraudulent access or other types of attacks, or integrate with tools that
implement anomaly and abuse detection.
Support requests for information from law enforcement and government agencies.
Must
42010
Must
Must
42020
42030
Must
42040
Must
42050
Must
42060
Must
42070
Must
42080
Must
42090
Must
Must
42100
42110
Must
Must
Must
42120
42130
42140
Must
42150
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 11
4.4
VNF Security Analytics Requirements
This section covers VNF security analytics requirements that are mostly applicable to security monitoring.
The VNF Security Analytics cover the collection and analysis of data following key areas of security
monitoring:
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Anti-virus software
Logging
Data capture
Tasking
DPI
API based monitoring
Detection and notification
Resource exhaustion detection
Proactive and scalable monitoring
Mobility and guest VNF monitoring
Closed loop monitoring
Interfaces to management and orchestration
Malformed packet detections
Service chaining
Dynamic security control
Dynamic load balancing
The following requirements of security monitoring need to be met by the solution in a virtual environment.
Security Analytics Requirements
Support the following monitoring features by the VNF:
a. Real-time detection and notification of security events.
b. Integration functionality via API/Syslog/SNMP to other functional modules in
the network (e.g., PCRF, PCEF) that enable dynamic security control by
blocking the malicious traffic or malicious end users
c. API-based monitoring to take care of the scenarios where the control
interfaces are not exposed, or are optimized and proprietary in nature
d. Event logging, formats, and delivery tools to provide the required degree of
event data to OpenECOMP
e. Detection of malformed packets due to software misconfiguration or
software vulnerability
f. Integrated DPI/monitoring functionality as part of VNFs (e.g., PGW, MME)
g. Alternative monitoring capabilities when VNFs do not expose data or
control traffic or use proprietary and optimized protocols for inter VNF
communication
h. Proactive monitoring to detect and report the attacks on resources so that
the VNFs and associated VMs can be isolated, such as detection
techniques for resource exhaustion, namely OS resource attacks, CPU
attacks, consumption of kernel memory, local storage attacks.
Coexist and operate normally with commercial anti-virus software which shall
produce alarms every time when there is a security incident.
Protect all security audit logs (including API, OS and application-generated logs),
security audit software, data, and associated documentation from modification, or
unauthorized viewing, by standard OS access control mechanisms, by sending to a
remote system, or by encryption.
Log the following events:
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 12
Type
ID #
Must
Must
43010
43020
Must
43030
Must
43040
Must
43050
Must
Must
43060
43070
Must
43080
Must
43090
Must
43100
Security Analytics Requirements
Type
ID #
a. Successful and unsuccessful login attempts
b. Logoffs
c. Successful and unsuccessful changes to a privilege level
d. Starting and stopping of security logging
e. Creating, removing, or changing the inherent privilege level of users
f. Connections to a network listener of the resource
Log, at minimum, the following fields (where applicable and technically feasible) in
the security audit logs:
a. Event type
b. Date/time
c. Protocol
d. Service or program used for access
e. Success/failure
f. Login ID
Security audit logs must never contain an authentication credential, e.g., password,
even if encrypted.
Detect when the security audit log storage medium is approaching capacity
(configurable) and issue an alarm via SMS or equivalent as to allow time for proper
actions to be taken to pre-empt loss of audit data.
Support the capability of online storage of security audit logs.
Activate security alarms automatically when the following events, at a minimum, are
detected:
a. Configurable number of consecutive unsuccessful login attempts
b. Successful modification of critical system or application files
c. Unsuccessful attempts to gain permissions or assume the identity of
another user
Include, at a minimum, the following fields in the Security alarms (where applicable
and technically feasible):
a. Date
b. Time
c. Service or program used for access
d. Success/failure
e. Login ID
Restrict changing the criticality level of a system security alarm to administrator(s).
Monitor API invocation patterns to detect anomalous access patterns that may
represent fraudulent access or other types of attacks, or integrate with tools that
implement anomaly and abuse detection.
Support requests for information from law enforcement and government agencies.
Implement “Closed Loop” automatic implementation (without human intervention)
for Known Threats with detection rate in low false positives.
Perform data capture for security functions.
Generate security audit logs that must be sent to Security Analytics Tools for
analysis.
Provide audit logs that include user ID, dates, times for log-on and log-off, and
terminal location at minimum.
Provide security audit logs including records of successful and rejected system
access data and other resource access attempts.
Support the storage of security audit logs for agreed period of time for forensic
analysis.
Provide the capability of generating security audit logs by interacting with the
operating system (OS) as appropriate.
Must
Must
Must
Must
Must
Must
43110
43120
43130
43140
43150
43160
Must
Must
Must
Must
Must
Must
Must
43170
43180
43190
43200
43210
43220
43230
Must
43240
Must
43250
Must
Must
Must
43260
43270
43280
Must
Must
Must
Must
Must
Must
Must
43290
43300
43310
43320
43330
43340
43350
Must
Must
43360
43370
Must
Must
43380
43390
Must
43400
Must
43410
Must
43420
Must
43430
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 13
Security Analytics Requirements
Type
ID #
Security logging for VNFs and their OSs must be active from initialization. Audit
logging includes automatic routines to maintain activity records and cleanup
programs to ensure the integrity of the audit/logging systems.
Must
43440
4.5
VNF Data Protection Requirements
This section covers VNF data protection requirements that are mostly applicable to security monitoring.
Data Protection Requirements
Type
ID #
Provide the capability to restrict read and write access to data.
Provide the capability to restrict access to data to specific users.
Provide the capability to encrypt data in transit on a physical or virtual network.
Provide the capability to encrypt data on non-volatile memory.
Where the encryption of non-transient data is required on a device for which the
operating system performs paging to virtual memory, then if possible disable the
paging of the data requiring encryption, if not the virtual memory should be
encrypted.
Provide the capability to integrate with an external encryption service.
Use industry standard cryptographic algorithms and standard modes of operations
when implementing cryptography.
Use commercial algorithms only when there are no applicable US federal standards
for specific cryptographic functions, e.g., public key cryptography, message digests.
The SHA, DSS, MD5, SHA-1 and Skipjack algorithms or other compromised
encryption must not be used.
Use, whenever possible, standard implementations of security applications,
protocols, and format, e.g., S/MIME, TLS, SSH, IPSec, X.509 digital certificates for
cryptographic implementations. These implementations must be purchased from
reputable vendors and must not be developed in-house.
A VNF must provide the ability to migrate to newer versions of cryptographic
algorithms and protocols with no impact.
Use symmetric keys of at least 112 bits in length.
Use asymmetric keys of at least 2048 bits in length.
Use commercial tools that comply with X.509 standards and produce x.509
compliant keys for public/private key generation. Keys must not be generated or
derived from predictable functions or values, e.g., values considered predictable
include user identity information, time of day, stored/transmitted data.
Provide the capability to configure encryption algorithms or devices so that they
comply with the laws of the United States and those of any country in which there
are plans to use data encryption.
Provide the capability of using certificates issued from a Certificate Authority not
provided by the VNF vendor.
Provide the capability of allowing certificate renewal and revocation.
Provide the capability of testing the validity of a digital certificate by performing the
following:
a. The CA signature on the certificate must be validated
b. The date the certificate is being used must be within the validity period for
the certificate
c. The Certificate Revocation List (CRL) for the certificates of that type must
be checked to ensure that the certificate has not been revoked
d. The identity represented by the certificate — the "distinguished name" —
must be recognized
Provide the capability of encrypting selected data fields stored or bound for security
logs.
Must
Must
Must
Must
Should
44010
44020
44030
44040
44050
Must
Must
44060
44070
Should
44080
Must
44090
Must
44100
Must
44110
Must
Must
Must
44120
44130
44140
Must
44150
Must
44160
Must
44170
Must
Must
44180
44190
Must
44200
Must
44210
Must
44220
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 14
Data Protection Requirements
Type
ID #
Provide the capability of deleting data stored in the VNF.
Provide the capability to make data available in order to support requests from law
enforcement and government agencies as required by legal or regulatory
mandates. Capability must be configurable for MOW deployment.
Must
Must
44230
44240
5. DevOps
This section includes guidelines for vendors to ensure that a Network Cloud Service Provider’s operations
personnel have a common and consistent way to support VNFs and VNFCs.
NCSPs may elect to support standard images to enable compliance with security, audit, regulatory and
other needs. As part of the overall VNF software bundle, VNF suppliers using standard images would
typically provide the NCSP with an install package consistent with the default OS package manager (e.g.
aptitude for Ubuntu, yum for Redhat/CentOS).
Section 4.1.4 in VNF Guidelines for Network Cloud and OpenECOMP describes the DevOps guidelines
for VNFs.
Additional requirements will be included in the next release of the document.
2
DevOps Requirements
Type
ID #
Utilize only the Guest OS versions that are supported by the NCSP’s Network
Cloud. 2
Utilize only NCSP supported Guest OS images.2
Utilize only NCSP standard compute flavors.2
Running VMs will not be backed up in the Network Cloud infrastructure. Bringing a
VM back up with the configuration required must be accomplished by using
appropriate snapshot images or using persistent storage.
Install VNFC(s) on non-root file systems, unless software is specifically included with
the operating system distribution of the guest image.
Must
50010
Should
Must
Must
50020
50030
50040
Must
50050
Refer to NCSP’s Network Cloud specification
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 15
Copyright 2017 AT&T Intellectual Property. All Rights Reserved.
This paper is licensed to you under the Creative Commons License:
Creative Commons Attribution-ShareAlike 4.0 International Public License
You may obtain a copy of the License at:
https://creativecommons.org/licenses/by-sa/4.0/legalcode
You are free to:
•
•
•
Share — copy and redistribute the material in any medium or format
Adapt — remix, transform, and build upon the material for any purpose, even commercially.
The licensor cannot revoke these freedoms as long as you follow the license terms.
Under the following terms:
•
•
•
Attribution — You must give appropriate credit, provide a link to the license, and indicate if changes
were made. You may do so in any reasonable manner, but not in any way that suggests the licensor
endorses you or your use.
ShareAlike — If you remix, transform, or build upon the material, you must distribute your
contributions under the same license as the original.
No additional restrictions — You may not apply legal terms or technological measures that legally
restrict others from doing anything the license permits.
Notices:
•
•
You do not have to comply with the license for elements of the material in the public domain or where
your use is permitted by an applicable exception or limitation.
No warranties are given. The license may not give you all of the permissions necessary for your
intended use. For example, other rights such as publicity, privacy, or moral rights may limit how you
use the material.
Copyright © 2017 AT&T Intellectual Property. All rights reserved.
Licensed under the Creative Commons License, Attribution 4.0 Intl. (the "License");
you may not use this documentation except in compliance with the License.
Page 16
Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF

advertisement