diff options
Diffstat (limited to 'docs/Chapter4')
-rw-r--r-- | docs/Chapter4/Design.rst | 82 | ||||
-rw-r--r-- | docs/Chapter4/Develop-Steps.rst | 29 | ||||
-rw-r--r-- | docs/Chapter4/Devops.rst | 74 | ||||
-rw-r--r-- | docs/Chapter4/Modularity.rst | 352 | ||||
-rw-r--r-- | docs/Chapter4/Resiliency.rst | 301 | ||||
-rw-r--r-- | docs/Chapter4/Security.rst | 563 | ||||
-rw-r--r-- | docs/Chapter4/index.rst | 17 |
7 files changed, 1418 insertions, 0 deletions
diff --git a/docs/Chapter4/Design.rst b/docs/Chapter4/Design.rst new file mode 100644 index 0000000..e9003e6 --- /dev/null +++ b/docs/Chapter4/Design.rst @@ -0,0 +1,82 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +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 5.a VNF Design in *VNF Guidelines* describes +the overall guidelines for designing VNFs from VNF Components (VNFCs). +Below are more detailed requirements for composing VNFs. + +VNF Design Requirements + +* R-58421 The VNF **SHOULD** be decomposed into granular re-usable VNFCs. +* R-82223 The VNF **MUST** be decomposed if the functions have + significantly different scaling characteristics (e.g., signaling + versus media functions, control versus data plane functions). +* R-16496 The VNF **MUST** enable instantiating only the functionality that + is needed for the decomposed VNF (e.g., if transcoding is not needed it + should not be instantiated). +* R-02360 The VNFC **MUST** be designed as a standalone, executable process. +* R-34484 The VNF **SHOULD** create a single component VNF for VNFCs + that can be used by other VNFs. +* R-23035 The VNF **MUST** be designed 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. +* R-30650 The VNF **MUST** 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. +* R-12709 The VNFC **SHOULD** be independently deployed, configured, + upgraded, scaled, monitored, and administered by ONAP. +* R-37692 The VNFC **MUST** provide API versioning to allow for + independent upgrades of VNFC. +* R-86585 The VNFC **SHOULD** minimize the use of state within + a VNFC to facilitate the movement of traffic from one instance + to another. +* R-65134 The VNF **SHOULD** maintain state in a geographically + redundant datastore that may, in fact, be its own VNFC. +* R-75850 The VNF **SHOULD** 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. +* R-88199 The VNF **MUST** utilize a persistent datastore service that + can meet the data performance/latency requirements. (For example: + Datastore service could be a VNFC in VNF or a DBaaS in the Cloud + execution environment) +* R-99656 The VNF **MUST** NOT terminate stable sessions if a VNFC + instance fails. +* R-84473 The VNF **MUST** 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. +* R-54430 The VNF **MUST** use the NCSP’s supported library and compute + flavor that supports DPDK to optimize network efficiency if using DPDK. [1]_ +* R-18864 The VNF **MUST** 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). +* R-64768 The VNF **MUST** limit the size of application data packets + to no larger than 9000 bytes for SDN network-based tunneling when + guest data packets are transported between tunnel endpoints that + support guest logical networks. +* R-74481 The VNF **MUST** NOT require the use of a dynamic routing + protocol unless necessary to meet functional requirements. + + +.. [1] + Refer to NCSP’s Network Cloud specification diff --git a/docs/Chapter4/Develop-Steps.rst b/docs/Chapter4/Develop-Steps.rst new file mode 100644 index 0000000..30fe07e --- /dev/null +++ b/docs/Chapter4/Develop-Steps.rst @@ -0,0 +1,29 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + + +VNF Develop Steps +----------------- + +Aid to help the VNF provider to fasten the integration with the GVNFM, the +ONAP provides the VNF SDK tools, and the documents. In this charter, +the develop steps for VNF providers will be introduced. + +First, using the VNF SDK tools to design the VNF with TOSCA model and +output the VNF TOSCA package. The VNF package can be validated, and +tested. + +Second, the VNF provider should provide the VNF Rest API to integrate with +the GVNFM if needed. The VNF Rest API is aligned to the ETSI IFA +document. + +Third, the TOSCA model supports the HPA feature. + +Note: + +1. The scripts to extend capacity to satisfy some special requirements. + In the R2, the scripts is not implemented fully, and will be provided + in the next release. + +2. The monitoring and scale policy also be provide the next release. diff --git a/docs/Chapter4/Devops.rst b/docs/Chapter4/Devops.rst new file mode 100644 index 0000000..702db95 --- /dev/null +++ b/docs/Chapter4/Devops.rst @@ -0,0 +1,74 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +VNF Devops +--------------------- + +This section includes guidelines for VNF providers 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 5.a DevOps in *VNF Guidelines* describes +the DevOps guidelines for VNFs. + +DevOps Requirements + +* R-46960 NCSPs **MAY** operate a limited set of Guest OS and CPU + architectures and families, virtual machines, etc. +* R-23475 VNFCs **SHOULD** be agnostic to the details of the Network Cloud + (such as hardware, host OS, Hypervisor or container technology) and must run + on the Network Cloud with acknowledgement to the paradigm that the Network + Cloud will continue to rapidly evolve and the underlying components of + the platform will change regularly. +* R-33846 The VNF **MUST** install the NCSP required software on Guest OS + images when not using the NCSP provided Guest OS images. [1]_ +* R-09467 The VNF **MUST** utilize only NCSP standard compute flavors. [1]_ +* R-02997 The VNF **MUST** preserve their persistent data. Running VMs + will not be backed up in the Network Cloud infrastructure. +* R-29760 The VNFC **MUST** be installed on non-root file systems, + unless software is specifically included with the operating system + distribution of the guest image. +* R-20860 The VNF **MUST** be agnostic to the underlying infrastructure + (such as hardware, host OS, Hypervisor), any requirements should be + provided as specification to be fulfilled by any hardware. +* R-89800 The VNF **MUST NOT** require Hypervisor-level customization + from the cloud provider. +* R-86758 The VNF **SHOULD** provide an automated test suite to validate + every new version of the software on the target environment(s). The tests + should be of sufficient granularity to independently test various + representative VNF use cases throughout its lifecycle. Operations might + choose to invoke these tests either on a scheduled basis or on demand to + support various operations functions including test, turn-up and + troubleshooting. +* R-39650 The VNF **SHOULD** provide the ability to test incremental + growth of the VNF. +* R-14853 The VNF **MUST** respond to a "move traffic" [2]_ command + against a specific VNFC, moving all existing session elsewhere with + minimal disruption if a VNF provides a load balancing function across + multiple instances of its VNFCs. Note: Individual VNF performance + aspects (e.g., move duration or disruption scope) may require further + constraints. +* R-06327 The VNF **MUST** respond to a "drain VNFC" [2]_ command against + a specific VNFC, preventing new session from reaching the targeted VNFC, + with no disruption to active sessions on the impacted VNFC, if a VNF + provides a load balancing function across multiple instances of its VNFCs. + This is used to support scenarios such as proactive maintenance with no + user impact. +* R-64713 The VNF **SHOULD** support a software promotion methodology + from dev/test -> pre-prod -> production in software, development & + testing and operations. + + +.. [1] + Refer to NCSP’s Network Cloud specification + +.. [2] + Not currently supported in ONAP release 1 + diff --git a/docs/Chapter4/Modularity.rst b/docs/Chapter4/Modularity.rst new file mode 100644 index 0000000..12024bd --- /dev/null +++ b/docs/Chapter4/Modularity.rst @@ -0,0 +1,352 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + + +VNF Modularity +-------------- + +ONAP Heat Orchestration Templates: Overview +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +ONAP supports a modular Heat Orchestration Template design pattern, +referred to as *VNF Modularity.* + +ONAP VNF Modularity Overview +^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +With VNF Modularity, a single VNF may be composed from one or more Heat +Orchestration Templates, each of which represents a subset of the +overall VNF. These component parts are referred to as “\ *VNF +Modules*\ ”. During orchestration, these modules are deployed +incrementally to create the complete VNF. + +A modular Heat Orchestration Template can be either one of the following +types: + +1. Base Module + +2. Incremental Module + +3. Cinder Volume Module + +* R-37028 The VNF **MUST** be composed of one “base” module. +* R-41215 The VNF **MAY** have zero to many “incremental” modules. +* R-20974 The VNF **MUST** deploy the base module first, prior to + the incremental modules. + +ONAP also supports the concept of an optional, independently deployed +Cinder volume via a separate Heat Orchestration Templates, referred to +as a Cinder Volume Module. This allows the volume to persist after a +Virtual Machine (VM) (i.e., OS::Nova::Server) is deleted, allowing the +volume to be reused on another instance (e.g., during a failover +activity). + +* R-11200 The VNF **MUST** keep the scope of a Cinder volume module, + when it exists, to be 1:1 with the VNF Base Module or Incremental Module. + +* R-38474 The VNF **MUST** have a corresponding environment file for + a Base Module. +* R-81725 The VNF **MUST** have a corresponding environment file for + an Incremental Module. +* R-53433 The VNF **MUST** have a corresponding environment file for + a Cinder Volume Module. + +These concepts will be described in more detail throughout the document. +This overview is provided to set the stage and help clarify the concepts +that will be introduced. + + +ONAP VNF Modularity +^^^^^^^^^^^^^^^^^^^^^^ + +ONAP supports a modular Heat Orchestration Template design pattern, +referred to as *VNF Modularity.* With this approach, a single VNF may be +composed from one or more Heat Orchestration Templates, each of which +represents a subset of the overall VNF. These component parts are +referred to as “\ *VNF Modules*\ ”. During orchestration, these modules +are deployed incrementally to create the complete VNF. + +A modular Heat Orchestration Template can be either one of the following +types: + +1. Base Module + +2. Incremental Module + +3. Cinder Volume Module + +A VNF must be composed of one “base” module and may be composed of zero +to many “incremental” modules. The base module must be deployed first, +prior to the incremental modules. + +ONAP also supports the concept of an optional, independently deployed +Cinder volume via a separate Heat Orchestration Templates, referred to +as a Cinder Volume Module. This allows the volume to persist after a VM +(i.e., OS::Nova::Server) is deleted, allowing the volume to be reused on +another instance (e.g., during a failover activity). + +The scope of a Cinder volume module, when it exists, must be 1:1 with a +Base module or Incremental Module. + +A Base Module must have a corresponding environment file. + +An Incremental Module must have a corresponding environment file. + +A Cinder Volume Module must have a corresponding environment file. + +A VNF module (base, incremental, cinder) may support nested templates. + +A shared Heat Orchestration Template resource must be defined in the +base module. A shared resource is a resource that that will be +referenced by another resource that is defined in the Base Module and/or +one or more incremental modules. + +When the shared resource needs to be referenced by a resource in an +incremental module, the UUID of the shared resource must be exposed by +declaring an ONAP Base Module Output Parameter. + +Note that a Cinder volume is *not* a shared resource. A volume template +must correspond 1:1 with a base module or incremental module. + +An example of a shared resource is the resource +OS::Neutron::SecurityGroup. Security groups are sets of IP filter rules +that are applied to a VNF’s networking. The resource OS::Neutron::Port +has a property security\_groups which provides the security groups +associated with port. The value of parameter(s) associated with this +property must be the UUIDs of the resource(s) +OS::Neutron::SecurityGroup. + +*Note:* A Cinder volume is *not* considered a shared resource. A volume +template must correspond 1:1 with a base template or add-on module +template. + +Suggested Patterns for Modular VNFs +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +There are numerous variations of VNF modularity. Below are two suggested +usage patterns. + +**Option 1: Modules per VNFC type** + +a. Base module contains only the shared resources. + +b. Group all VMs (e.g., VNFCs) of a given type (i.e. {vm-type}) into its + own incremental module. That is, the VNF has an incremental module + for each {vm-type}. + +c. For a given {vm-type} incremental module, the VNF may have + + i. One incremental module used for both initial turn up and re-used + for scaling. This approach is used when the number of VMs + instantiated will be the same for initial deployment and scaling. + + ii. Two incremental modules, where one is used for initial turn up + and one is used for scaling. This approach is used when the + number of VMs instantiated will be different for initial + deployment and scaling. + +**Option 2: Base VNF with Incremental Growth Modules** + +a. Base module contains a complete initial VNF instance + +b. Incremental modules for incremental scaling units + + i. May contain VMs of multiple types in logical scaling combinations + + ii. May be separated by VM type for multi-dimensional scaling + +With no growth units, Option 2 is equivalent to the “One Heat Template +per VNF” model. + +Note that modularization of VNFs is not required. A single Heat +Orchestration Template (a base module) may still define a complete VNF, +which might be appropriate for smaller VNFs that do not have any scaling +options. + +Modularity Rules +^^^^^^^^^^^^^^^^^^^ + +There are some rules to follow when building modular VNF templates: + +1. All VNFs must have one Base VNF Module (template) that must be the + first one deployed. The base template: + + a. Must include all shared resources (e.g., private networks, server + groups, security groups) + + b. Must expose all shared resources (by UUID) as “outputs” in its + associated Heat template (i.e., ONAP Base Module Output + Parameters) + + c. May include initial set of VMs + + d. May be operational as a stand-alone “minimum” configuration of the + VNF + +2. VNFs may have one or more incremental modules which: + + a. Defines additional resources that can be added to an existing VNF + + b. Must be complete Heat templates + + i. i.e. not snippets to be incorporated into some larger template + + c. Should define logical growth-units or sub-components of an overall + VNF + + d. On creation, receives appropriate Base Module outputs as + parameters + + i. Provides access to all shared resources (by UUID) + + ii. must not be dependent on other Add-On VNF Modules + + e. Multiple instances of an incremental Module may be added to the + same VNF (e.g., incrementally grow a VNF by a fixed “add-on” + growth units) + +3. Each VNF Module (base or incremental) may have (optional) an + associated Cinder Volume Module (see Cinder Volume Templates) + + a. Volume modules must correspond 1:1 with a base module or + incremental module + + b. A Cinder volume may be embedded within the base module or + incremental module if persistence is not required + +4. Shared resource UUIDs are passed between the base module and + incremental modules via Heat Outputs Parameters (i.e., Base Module + Output Parameters) + + a. The output parameter name in the base must match the parameter + name in the add-on module + +VNF Modularity Examples +^^^^^^^^^^^^^^^^^^^^^^^ + +*Example: Base Module creates SecurityGroup* + +A VNF has a base module, named base.yaml, that defines a +OS::Neutron::SecurityGroup. The security group will be referenced by an +OS::Neutron::Port resource in an incremental module, named +INCREMENTAL\_MODULE.yaml. The base module defines a parameter in the out +section named dns\_sec\_grp\_id. dns\_sec\_grp\_id is defined as a +parameter in the incremental module. ONAP captures the UUID value of +dns\_sec\_grp\_id from the base module output statement and provides the +value to the incremental module. + +Note that the example below is not a complete Heat Orchestration +Template. The {network-role} has been defined as oam to represent an oam +network and the {vm-type} has been defined as dns. + +base\_MODULE.yaml + +.. code-block:: yaml + + parameters: + . . . + + resources: + DNS_SECURITY_GROUP: + type: OS::Neutron::SecurityGroup + properties: + description: vDNS security group + name: + str_replace: + template: VNF_NAME_sec_grp_DNS + params: + VMF_NAME: {get_param: vnf_name} + rules: [. . . . . + + . . . + + outputs: + dns_sec_grp_id: + description: UUID of DNS Resource SecurityGroup + value: { get_resource: DNS_SECURITY_GROUP } + + +INCREMENTAL\_MODULE.yaml + +.. code-block:: yaml + + parameters: + dns_sec_grp_id: + type: string + description: security group UUID + . . . + + resources: + dns_oam_0_port: + type: OS::Neutron::Port + properties: + name: + str_replace: + template: VNF_NAME_dns_oam_port + params: + VNF_NAME: {get_param: vnf_name} + network: { get_param: oam_net_name } + fixed_ips: [{ "ip_address": { get_param: dns_oam_ip_0 }}] + security_groups: [{ get_param: dns_sec_grp_id }] + + +*Examples: Base Module creates an internal network* + +A VNF has a base module, named base\_module.yaml, that creates an +internal network. An incremental module, named incremental\_module.yaml, +will create a VM that will connect to the internal network. The base +module defines a parameter in the out section named int\_oam\_net\_id. +int\_oam\_net\_id is defined as a parameter in the incremental module. +ONAP captures the UUID value of int\_oam\_net\_id from the base module +output statement and provides the value to the incremental module. + +Note that the example below is not a complete Heat Orchestration +Template. The {network-role} has been defined as oam to represent an oam +network and the {vm-type} has been defined as lb for load balancer. + +base.yaml + +.. code-block:: yaml + + heat_template_version: 2013-05-23 + + resources: + int_oam_network: + type: OS::Neutron::Network + properties: + name: {… } + . . . + outputs: + int_oam_net_id: + value: {get_resource: int_oam_network } + + +incremental.yaml + +.. code-block:: yaml + + heat_template_version: 2013-05-23 + + parameters: + int_oam_net_id: + type: string + description: ID of shared private network from Base template + lb_name_0: + type: string + description: name for the add-on VM instance + + Resources: + lb_server: + type: OS::Nova::Server + properties: + name: {get_param: lb_name_0} + networks: + - port: { get_resource: lb_port } + . . . + + lb_port: + type: OS::Neutron::Port + properties: + network_id: { get_param: int_oam_net_id } + ... diff --git a/docs/Chapter4/Resiliency.rst b/docs/Chapter4/Resiliency.rst new file mode 100644 index 0000000..bf3e2e8 --- /dev/null +++ b/docs/Chapter4/Resiliency.rst @@ -0,0 +1,301 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +VNF 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 5.a Resiliency in *VNF Guidelines* describes +the overall guidelines for designing VNFs to meet resiliency goals. +Below are more detailed resiliency requirements for VNFs. + +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 + +* R-52499 The VNF **MUST** meet their own resiliency goals and not rely + on the Network Cloud. +* R-42207 The VNF **MUST** design resiliency into a VNF such that the + resiliency deployment model (e.g., active-active) can be chosen at + run-time. +* R-03954 The VNF **MUST** survive any single points of failure within + the Network Cloud (e.g., virtual NIC, VM, disk failure). +* R-89010 The VNF **MUST** survive any single points of software failure + internal to the VNF (e.g., in memory structures, JMS message queues). +* R-67709 The VNF **MUST** be designed, built and packaged to enable + deployment across multiple fault zones (e.g., VNFCs deployed in + different servers, racks, OpenStack regions, geographies) so that + in the event of a planned/unplanned downtime of a fault zone, the + overall operation/throughput of the VNF is maintained. +* R-35291 The VNF **MUST** 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. +* R-36843 The VNF **MUST** 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. +* R-00098 The VNF **MUST NOT** impact the ability of the VNF to provide + service/function due to a single container restart. +* R-79952 The VNF **SHOULD** support container snapshots if not for rebuild + and evacuate for rollback or back out mechanism. + +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). + +Minimize Cross Data-Center Traffic Requirements + +* R-92935 The VNF **SHOULD** minimize the propagation of state information + across multiple data centers to avoid cross data center traffic. + +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 + +* R-26371 The VNF **MUST** detect communication failure for inter VNFC + instance and intra/inter VNF and re-establish communication + automatically to maintain the VNF without manual intervention to + provide service continuity. +* R-18725 The VNF **MUST** handle the restart of a single VNFC instance + without requiring all VNFC instances to be restarted. +* R-06668 The VNF **MUST** 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. +* R-80070 The VNF **MUST** handle errors and exceptions so that they do + not interrupt processing of incoming VNF requests to maintain service + continuity (where the error is not directly impacting the software + handling the incoming request). +* R-32695 The VNF **MUST** 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 + NCSP to control that behavior, where the interface and/or functional + specification allows for altering behaviour. +* R-48356 The VNF **MUST** fully exploit exception handling to the extent + that resources (e.g., threads and memory) are released when no longer + needed regardless of programming language. +* R-67918 The VNF **MUST** handle replication race conditions both locally + and geo-located in the event of a data base instance failure to maintain + service continuity. +* R-36792 The VNF **MUST** automatically retry/resubmit failed requests + made by the software to its downstream system to increase the success rate. +* R-70013 The VNF **MUST NOT** require any manual steps to get it ready for + service after a container rebuild. +* R-65515 The VNF **MUST** provide a mechanism and tool to start VNF + containers (VMs) without impacting service or service quality assuming + another VNF in same or other geographical location is processing service + requests. +* R-94978 The VNF **MUST** provide a mechanism and tool to perform a graceful + shutdown of all the containers (VMs) in the VNF without impacting service + or service quality assuming another VNF in same or other geographical + location can take over traffic and process service requests. + + +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 + +* R-22059 The VNF **MUST 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. +* R-63473 The VNF **MUST** automatically advertise newly scaled + components so there is no manual intervention required. +* R-74712 The VNF **MUST** utilize FQDNs (and not IP address) for + both Service Chaining and scaling. +* R-41159 The VNF **MUST** deliver any and all functionality from any + VNFC in the pool (where pooling is the most suitable solution). 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. +* R-85959 The VNF **SHOULD** automatically enable/disable added/removed + sub-components or component so there is no manual intervention required. +* R-06885 The VNF **SHOULD** 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. +* R-12538 The VNF **SHOULD** support load balancing and discovery + mechanisms in resource pools containing VNFC instances. +* R-98989 The VNF **SHOULD** utilize resource pooling (threads, + connections, etc.) within the VNF application so that resources + are not being created and destroyed resulting in resource management + overhead. +* R-55345 The VNF **SHOULD** 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. +* R-35532 The VNF **SHOULD** 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. + + +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 + +* R-77334 The VNF **MUST** allow configurations and configuration parameters + to be managed under version control to ensure consistent configuration + deployment, traceability and rollback. +* R-99766 The VNF **MUST** allow configurations and configuration parameters + to be managed under version control to ensure the ability to rollback to + a known valid configuration. +* R-73583 The VNF **MUST** 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. + + +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 + +* R-21558 The VNF **SHOULD** 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. +* R-08315 The VNF **SHOULD** 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. +* R-27995 The VNF **SHOULD** 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. + +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). + +Deployment Optimization Requirements + +* R-73364 The VNF **MUST** 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. +* R-02454 The VNF **MUST** 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. +* R-57855 The VNF **MUST** support hitless 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. +* R-64445 The VNF **MUST** 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. +* R-56793 The VNF **MUST** 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. +* R-77667 The VNF **MUST** 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. +* R-49308 The VNF **SHOULD** 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. +* R-16039 The VNF **SHOULD** 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. + +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 +post-incident diagnostics. + +Monitoring & Dashboard Requirements + +* R-34957 The VNF **MUST** provide a method of metrics gathering for each + layer's performance to identify/document variances in the allocations so + they can be addressed. +* R-49224 The VNF **MUST** provide unique traceability of a transaction + through its life cycle to ensure quick and efficient troubleshooting. +* R-52870 The VNF **MUST** 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. +* R-92571 The VNF **MUST** provide operational instrumentation such as + logging, so as to facilitate quick resolution of issues with the VNF to + provide service continuity. +* R-48917 The VNF **MUST** 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. +* R-28168 The VNF **SHOULD** 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. +* R-87352 The VNF **SHOULD** 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. +* R-16560 The VNF **SHOULD** 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. diff --git a/docs/Chapter4/Security.rst b/docs/Chapter4/Security.rst new file mode 100644 index 0000000..a0691ae --- /dev/null +++ b/docs/Chapter4/Security.rst @@ -0,0 +1,563 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + +VNF 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 5.a Security in *VNF Guidelines* outlines +the five broad security areas for VNFs that are detailed in the +following sections: + +- **VNF General Security**: This section addresses general security + requirements for the VNFs that the VNF provider 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 + +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. + +* R-23740 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. +* R-61354 The VNF **MUST** implement access control list for OA&M + services (e.g., restricting access to certain ports or applications). +* R-85633 The VNF **MUST** 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. +* R-92207 The VNF **SHOULD** implement a mechanism for automated and + frequent "system configuration (automated provisioning / closed loop)" + auditing. +* R-23882 The VNF **SHOULD** be scanned using 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. +* R-46986 The VNF **SHOULD** have source code scanned using scanning + tools (e.g., Fortify) and provide reports. +* R-55830 The VNF **MUST** distribute all production code from NCSP + internal sources only. No production code, libraries, OS images, etc. + shall be distributed from publically accessible depots. +* R-99771 The VNF **MUST** 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. VNF provider + default credentials, community strings and other such artifacts will be + removed or disclosed so that they can be modified or removed during + provisioning. +* R-19768 The VNF **SHOULD** 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). +* R-33981 The VNF **SHOULD** interoperate with various access control + mechanisms for the Network Cloud execution environment (e.g., + Hypervisors, containers). +* R-40813 The VNF **SHOULD** support the use of virtual trusted platform + module, hypervisor security testing and standards scanning tools. +* R-56904 The VNF **MUST** interoperate with the ONAP (SDN) Controller so that + it can dynamically modify the firewall rules, ACL rules, QoS rules, virtual + routing and forwarding rules. +* R-26586 The VNF **SHOULD** support the ability to work with aliases + (e.g., gateways, proxies) to protect and encapsulate resources. +* R-49956 The VNF **MUST** pass all access to applications (Bearer, + signaling and OA&M) 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. +* R-69649 The VNF **MUST** have all vulnerabilities patched as soon + as possible. Patching shall be controlled via change control process + with vulnerabilities disclosed along with mitigation recommendations. +* R-78010 The VNF **MUST** use the NCSP’s IDAM API for Identification, + authentication and access control of customer or VNF application users. +* R-42681 The VNF **MUST** use the NCSP’s IDAM API or comply with + the requirements if not using the NCSP’s IDAM API, for identification, + authentication and access control of OA&M and other system level + functions. +* R-68589 The VNF **MUST**, if not using the NCSP’s IDAM API, 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. +* R-52085 The VNF **MUST**, if not using the NCSP’s IDAM API, 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. +* R-98391 The VNF **MUST**, if not using the NCSP’s IDAM API, support + Role-Based Access Control to permit/limit the user/application to + performing specific activities. +* R-63217 The VNF **MUST**, if not using the NCSP’s IDAM API, support + logging via ONAP for a historical view of “who did what and when”. +* R-62498 The VNF **MUST**, if not using the NCSP’s IDAM API, encrypt + OA&M access (e.g., SSH, SFTP). +* R-79107 The VNF **MUST**, if not using the NCSP’s IDAM API, enforce + a configurable maximum number of Login attempts policy for the users. + VNF provider 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. +* R-35144 The VNF **MUST**, if not using the NCSP’s IDAM API, comply + with the NCSP’s credential management policy. +* R-75041 The VNF **MUST**, if not using the NCSP’s IDAM API, expire + passwords at regular configurable intervals. +* R-46908 The VNF **MUST**, if not using the NCSP’s IDAM API, comply + with "password complexity" policy. When passwords are used, they shall + be complex and shall at least meet the following password construction + requirements: (1) be a minimum configurable number of characters in + length, (2) include 3 of the 4 following types of characters: + upper-case alphabetic, lower-case alphabetic, numeric, and special, + (3) not be the same as the UserID with which they are associated or + other common strings as specified by the environment, (4) not contain + repeating or sequential characters or numbers, (5) not to use special + characters that may have command functions, and (6) new passwords must + not contain sequences of three or more characters from the previous + password. +* R-39342 The VNF **MUST**, if not using the NCSP’s IDAM API, comply + with "password changes (includes default passwords)" policy. Products + will support password aging, syntax and other credential management + practices on a configurable basis. +* R-40521 The VNF **MUST**, if not using the NCSP’s IDAM API, support + use of common third party authentication and authorization tools such + as TACACS+, RADIUS. +* R-41994 The VNF **MUST**, if not using the NCSP’s IDAM API, comply + with "No Self-Signed Certificates" policy. Self-signed certificates + must be used for encryption only, using specified and approved + encryption protocols such as TLS 1.2 or higher or equivalent security + protocols such as IPSec, AES. +* R-23135 The VNF **MUST**, if not using the NCSP’s IDAM API, + authenticate system to system communications where one system + accesses the resources of another system, and must never conceal + individual accountability. + +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 + +* R-95105 The VNF **MUST** host connectors for access to the application + layer. +* R-45496 The VNF **MUST** host connectors for access to the OS + (Operating System) layer. +* R-05470 The VNF **MUST** host connectors for access to the database layer. +* R-99174 The VNF **MUST** comply with Individual Accountability + (each person must be assigned a unique ID) when persons or non-person + entities access VNFs. +* R-42874 The VNF **MUST** comply with Least Privilege (no more + privilege than required to perform job functions) when persons + or non-person entities access VNFs. +* R-71787 The VNF **MUST** comply with Segregation of Duties (access to a + single layer and no developer may access production without special + oversight) when persons or non-person entities access VNFs. +* R-86261 The VNF **MUST NOT** allow VNF provider access to VNFs remotely. +* R-49945 The VNF **MUST** authorize VNF provider access through a + client application API 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. +* R-31751 The VNF **MUST** subject VNF provider access to privilege + reconciliation tools to prevent access creep and ensure correct + enforcement of access policies. +* R-34552 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for OWASP Top 10. +* R-29301 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Password Attacks. +* R-72243 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Phishing / SMishing. +* R-58998 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Malware (Key Logger). +* R-14025 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Session Hijacking. +* R-31412 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for XSS / CSRF. +* R-51883 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Replay. +* R-44032 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Man in the Middle (MITM). +* R-58977 The VNF **MUST** provide or support the Identity and Access + Management (IDAM) based threat detection data for Eavesdropping. +* R-24825 The VNF **MUST** provide Context awareness data (device, + location, time, etc.) and be able to integrate with threat detection system. +* R-59391 The VNF provider **MUST**, where a VNF provider requires + the assumption of permissions, such as root or administrator, 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. +* R-85028 The VNF **MUST** authenticate system to system access and + do not conceal a VNF provider user’s individual accountability for + transactions. +* R-80335 The VNF **MUST** make visible a Warning Notice: A formal + statement of resource intent, i.e., a warning notice, upon initial + access to a VNF provider 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. +* R-73541 The VNF **MUST** 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. +* R-64503 The VNF **MUST** provide minimum privileges for initial + and default settings for new user accounts. +* R-86835 The VNF **MUST** set the default settings for user access + to sensitive commands and data to deny authorization. +* R-77157 The VNF **MUST** conform to approved request, workflow + authorization, and authorization provisioning requirements when + creating privileged users. +* R-81147 The VNF **MUST** have greater restrictions for access and + execution, such as up to 3 factors of authentication and restricted + authorization, for commands affecting network services, such as + commands relating to VNFs. +* R-49109 The VNF **MUST** encrypt TCP/IP--HTTPS (e.g., TLS v1.2) + transmission of data on internal and external networks. +* R-39562 The VNF **MUST** disable unnecessary or vulnerable cgi-bin programs. +* R-15671 The VNF **MUST NOT** provide public or unrestricted access + to any data without the permission of the data owner. All data + classification and access controls must be followed. +* R-89753 The VNF **MUST NOT** install or use systems, tools or + utilities capable of capturing or logging data that was not created + by them or sent specifically to them in production, without + authorization of the VNF system owner. +* R-19082 The VNF **MUST NOT** run security testing tools and + programs, e.g., password cracker, port scanners, hacking tools + in production, without authorization of the VNF system owner. +* R-19790 The VNF **MUST NOT** include authentication credentials + in security audit logs, even if encrypted. +* R-85419 The VNF **SHOULD** use REST APIs exposed to Client + Applications for the implementation of OAuth 2.0 Authorization + Code Grant and Client Credentials Grant, as the standard interface + for a VNF. +* R-48080 The VNF **SHOULD** support SCEP (Simple Certificate + Enrollment Protocol). + + +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, Lawful Intercept, 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 + +* R-37608 The VNF **MUST** provide a mechanism to restrict access based + on the attributes of the VNF and the attributes of the subject. +* R-43884 The VNF **MUST** integrate with external authentication + and authorization services (e.g., IDAM). +* R-25878 The VNF **MUST** use certificates issued from publicly + recognized Certificate Authorities (CA) for the authentication process + where PKI-based authentication is used. +* R-19804 The VNF **MUST** 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. +* R-47204 The VNF **MUST** protect the confidentiality and integrity of + data at rest and in transit from unauthorized access and modification. +* R-33488 The VNF **MUST** protect against all denial of service + attacks, both volumetric and non-volumetric, or integrate with external + denial of service protection tools. +* R-21652 The VNF **MUST** implement the following input validation + control: 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. +* R-54930 The VNF **MUST** implement the following input validation + control: 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. +* R-21210 The VNF **MUST** implement the following input validation + control: 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. +* R-23772 The VNF **MUST** validate input at all layers implementing VNF APIs. +* R-87135 The VNF **MUST** comply with NIST standards and industry + best practices for all implementations of cryptography. +* R-02137 The VNF **MUST** implement all monitoring and logging as + described in the Security Analytics section. +* R-15659 The VNF **MUST** restrict changing the criticality level of + a system security alarm to administrator(s). +* R-19367 The VNF **MUST** 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. +* R-78066 The VNF **MUST** support requests for information from law + enforcement and government agencies. + + +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 + +- Connection attempts to inactive ports (malicious port scanning) + +The following requirements of security monitoring need to be met by the +solution in a virtual environment. + +Security Analytics Requirements + +* R-48470 The VNF **MUST** support Real-time detection and + notification of security events. +* R-22286 The VNF **MUST** support 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 +* R-32636 The VNF **MUST** support API-based monitoring to take care of + the scenarios where the control interfaces are not exposed, or are + optimized and proprietary in nature. +* R-61648 The VNF **MUST** support event logging, formats, and delivery + tools to provide the required degree of event data to ONAP +* R-22367 The VNF **MUST** support detection of malformed packets due to + software misconfiguration or software vulnerability. +* R-31961 The VNF **MUST** support integrated DPI/monitoring functionality + as part of VNFs (e.g., PGW, MME). +* R-20912 The VNF **MUST** support alternative monitoring capabilities + when VNFs do not expose data or control traffic or use proprietary and + optimized protocols for inter VNF communication. +* R-73223 The VNF **MUST** support 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. +* R-58370 The VNF **MUST** coexist and operate normally with commercial + anti-virus software which shall produce alarms every time when there is a + security incident. +* R-56920 The VNF **MUST** 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. +* R-54520 The VNF **MUST** log successful and unsuccessful login attempts. +* R-55478 The VNF **MUST** log logoffs. +* R-08598 The VNF **MUST** log successful and unsuccessful changes to + a privilege level. +* R-13344 The VNF **MUST** log starting and stopping of security + logging. +* R-07617 The VNF **MUST** log creating, removing, or changing the + inherent privilege level of users. +* R-94525 The VNF **MUST** log connections to a network listener of the + resource. +* R-31614 The VNF **MUST** log the field “event type” in the security + audit logs. +* R-97445 The VNF **MUST** log the field “date/time” in the security + audit logs. +* R-25547 The VNF **MUST** log the field “protocol” in the security audit logs. +* R-06413 The VNF **MUST** log the field “service or program used for + access” in the security audit logs. +* R-15325 The VNF **MUST** log the field “success/failure” in the + security audit logs. +* R-89474 The VNF **MUST** log the field “Login ID” in the security audit logs. +* R-04982 The VNF **MUST NOT** include an authentication credential, + e.g., password, in the security audit logs, even if encrypted. +* R-63330 The VNF **MUST** 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. +* R-41252 The VNF **MUST** support the capability of online storage of + security audit logs. +* R-41825 The VNF **MUST** activate security alarms automatically when + the following event is detected: configurable number of consecutive + unsuccessful login attempts +* R-43332 The VNF **MUST** activate security alarms automatically when + the following event is detected: successful modification of critical + system or application files +* R-74958 The VNF **MUST** activate security alarms automatically when + the following event is detected: unsuccessful attempts to gain permissions + or assume the identity of another user +* R-15884 The VNF **MUST** include the field “date” in the Security alarms + (where applicable and technically feasible). +* R-23957 The VNF **MUST** include the field “time” in the Security alarms + (where applicable and technically feasible). +* R-71842 The VNF **MUST** include the field “service or program used for + access” in the Security alarms (where applicable and technically feasible). +* R-57617 The VNF **MUST** include the field “success/failure” in the + Security alarms (where applicable and technically feasible). +* R-99730 The VNF **MUST** include the field “Login ID” in the Security + alarms (where applicable and technically feasible). +* R-29705 The VNF **MUST** restrict changing the criticality level of a + system security alarm to administrator(s). +* R-13627 The VNF **MUST** 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. +* R-21819 The VNF **MUST** support requests for information from law + enforcement and government agencies. +* R-56786 The VNF **MUST** implement “Closed Loop” automatic implementation + (without human intervention) for Known Threats with detection rate in low + false positives. +* R-25094 The VNF **MUST** perform data capture for security functions. +* R-04492 The VNF **MUST** generate security audit logs that must be sent + to Security Analytics Tools for analysis. +* R-19219 The VNF **MUST** provide audit logs that include user ID, dates, + times for log-on and log-off, and terminal location at minimum. +* R-30932 The VNF **MUST** provide security audit logs including records + of successful and rejected system access data and other resource access + attempts. +* R-54816 The VNF **MUST** support the storage of security audit logs + for agreed period of time for forensic analysis. +* R-57271 The VNF **MUST** provide the capability of generating security + audit logs by interacting with the operating system (OS) as appropriate. +* R-84160 The VNF **MUST** have security logging for VNFs and their + OSs 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. + +VNF Data Protection Requirements +^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ + +This section covers VNF data protection requirements that are mostly +applicable to security monitoring. + + +Data Protection Requirements + +* R-58964 The VNF **MUST** provide the capability to restrict read + and write access to data. +* R-99112 The VNF **MUST** provide the capability to restrict access + to data to specific users. +* R-83227 The VNF **MUST** Provide the capability to encrypt data in + transit on a physical or virtual network. +* R-32641 The VNF **MUST** provide the capability to encrypt data on + non-volatile memory. +* R-13151 The VNF **SHOULD** disable the paging of the data requiring + encryption, if possible, where the encryption of non-transient data is + required on a device for which the operating system performs paging to + virtual memory. If not possible to disable the paging of the data + requiring encryption, the virtual memory should be encrypted. +* R-93860 The VNF **MUST** provide the capability to integrate with an + external encryption service. +* R-73067 The VNF **MUST** use industry standard cryptographic algorithms + and standard modes of operations when implementing cryptography. +* R-22645 The VNF **SHOULD** use commercial algorithms only when there + are no applicable governmental standards for specific cryptographic + functions, e.g., public key cryptography, message digests. +* R-12467 The VNF **MUST NOT** use the SHA, DSS, MD5, SHA-1 and + Skipjack algorithms or other compromised encryption. +* R-02170 The VNF **MUST** 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. +* R-70933 The VNF **MUST** provide the ability to migrate to newer + versions of cryptographic algorithms and protocols with no impact. +* R-44723 The VNF **MUST** use symmetric keys of at least 112 bits in length. +* R-25401 The VNF **MUST** use asymmetric keys of at least 2048 bits in length. +* R-95864 The VNF **MUST** use commercial tools that comply with X.509 + standards and produce x.509 compliant keys for public/private key generation. +* R-12110 The VNF **MUST NOT** use keys generated or derived from + predictable functions or values, e.g., values considered predictable + include user identity information, time of day, stored/transmitted data. +* R-52060 The VNF **MUST** provide the capability to configure encryption + algorithms or devices so that they comply with the laws of the jurisdiction + in which there are plans to use data encryption. +* R-69610 The VNF **MUST** provide the capability of using certificates + issued from a Certificate Authority not provided by the VNF provider. +* R-83500 The VNF **MUST** provide the capability of allowing certificate + renewal and revocation. +* R-29977 The VNF **MUST** provide the capability of testing the validity + of a digital certificate by validating the CA signature on the certificate. +* R-24359 The VNF **MUST** provide the capability of testing the validity + of a digital certificate by validating the date the certificate is being + used is within the validity period for the certificate. +* R-39604 The VNF **MUST** provide the capability of testing the + validity of a digital certificate by checking the Certificate Revocation + List (CRL) for the certificates of that type to ensure that the + certificate has not been revoked. +* R-75343 The VNF **MUST** provide the capability of testing the + validity of a digital certificate by recognizing the identity represented + by the certificate — the "distinguished name". diff --git a/docs/Chapter4/index.rst b/docs/Chapter4/index.rst new file mode 100644 index 0000000..15fd8df --- /dev/null +++ b/docs/Chapter4/index.rst @@ -0,0 +1,17 @@ +.. This work is licensed under a Creative Commons Attribution 4.0 International License. +.. http://creativecommons.org/licenses/by/4.0 +.. Copyright 2017 AT&T Intellectual Property. All rights reserved. + + +VNF Development Requirements +============================ + +.. toctree:: + :maxdepth: 2 + + Design + Resiliency + Security + Modularity + Devops + Develop-Steps |