General design principles and
controls
This section discusses the security design principles and controls that CSPs should consider when designing and running telco network workloads on AWS. It explains high-level security concepts, and what AWS services and service features can be used to support them. It also describes AWS infrastructures and how they help to secure telco workloads by design.
Security governance
Security governance is one of the foundational building blocks for defining and implementing a security strategy. Security governance involves defining how people, processes, and technology work together to support business objectives by defining policies and control objectives to help manage risks. This is a layered approach based on the AWS Shared Responsibility Model, and a typical starting point includes the separation of workloads across multiple environments (such as development, pre-production, production and so on) using AWS accounts as a logical boundary.
Landing zones are a mechanism to support the technical definition of security governance. A landing zone is a well-architected construct that uses multiple AWS accounts for workload isolation, billing, and to limit allocation. This is a starting point from which a CSP organization can quickly launch and deploy network workloads on AWS with confidence. Building a landing zone requires both technical and business decisions regarding account structure, networking, security, and access management, in line with business objectives.
A landing zone can be set up using AWS Control Tower
Telco customers should consider the following when designing and implementing their governance model:
-
Roles and responsibilities boundaries — For roles that have access to one or more accounts, attach role- and policy-based boundaries that limit the permission to the absolute minimum in line with the principle of least privilege.
-
Workload separation and/or isolation through accounts — An AWS account is an isolated environment for a workload. Use account-level separation to isolate different network workloads or isolate account environments. This separation helps to limit the scope of impact should an event occur. Furthermore, separating workloads into different accounts prevents consuming resource quotas or potentially overprovisioning resources that can prevent other applications from working as intended. As an example, network workloads such as 5G and IP Multimedia Core Subsystem (IMS) should have their own separate accounts for each type of environment.

Example of a multi-account structure
-
Compliance control identification — Different network workloads might have different risk profiles, requiring different control policies and mechanisms around them. Conformance packs, which are sets of AWS Config
rules, and remediation actions can be used by customers to deploy in an account or across an organization in AWS Organizations. An AWS Config rule represents the desired configuration settings for specific AWS resources, or for an entire AWS account. Conformance packs provide customers with a general-purpose governance and compliance framework. They enable you to create security, operations, and cost-optimization governance. -
AWS Config
— Monitors and records your AWS resource configurations and allows you to automate the evaluation and remediation against desired configurations.
-
-
Central management — Even though a landing zone contains multiple accounts, consistent management is key to maintain and administer a global policy framework to control account creation and management, including the available services and resources for each account as well as pre-defined and implemented security guardrails. CSPs should consider establishing a central function, which can act as both a management point and enablement function for the business and development teams. This could be in the form of, for example, a Cloud Center of Excellence (CCoE).
-
Data classification — Classify data the workload will interact with. For example, control plane data, user plane data, and call data records are some data classifications that customers can use to determine if a chosen AWS service that processes or stores that data has the features to meet the security and compliance requirements specific to those data types.
-
Data isolation and anonymization — Isolating data stores with the correct policies limits the number of people or applications that can access the data, and controls the exposure of traffic data or subscriber data. Call data records (CDRs) are one example where access should be limited only to people who need to access them. In the event that data is accessed, applying anonymization on sensitive details of CDR data adds another layer of exposure protection.
-
Limit allocation — There are limits and quotas on AWS services per account. Separating workloads into different accounts prevents a single workload from consuming limits or potentially over-provisioning resources that may interrupt other workloads or incur unnecessary costs. For production workloads, make sure to check the limits so network functions are not prevented from scaling out the needed resources in case of sudden traffic peaks or disaster recovery (DR).
-
Security guardrails — A security guardrail is a control that prevents deviations from expected or allowed behavior. Use security guardrails to implement preventive and detective controls across your AWS environment. You can implement these guardrails through the use of Service Control Policies (SCPs) enforced through AWS Organizations. SCPs are a type of organization policy that you can use to manage permissions in an organization.
-
Preventive – A preventive guardrail verifies that AWS accounts align with the policies you’ve set, because it disallows actions that lead to policy violations. AWS Control Tower comes with a default set of preventive guardrails based on best practices available to customers. Customers also have the option to set their own guardrails. For example, disallowing the creation of AWS resources that can compromise your network functions, such as the creation of a Network Address Translation Gateway (NATGW) inside your VPC that would provide a route from your Amazon Elastic Compute Cloud
(Amazon EC2) instance running network functions to connect to the internet. -
Detective – A detective guardrail detects noncompliance of resources within your accounts, such as policy violations, and can provide alerts through various mechanisms. For example, detecting a change in the security group of a network function compute instance to allow traffic from anywhere.
-
Threat detection and incident
response
Detection of threat events is underpinned by appropriate logging and monitoring of events and understanding the different threats to the workload. Threat modeling provides a systematic approach to identifying risks and threats specific to your workload, and informs what logging mechanisms need to be in place to support the detection and alerting of those threats.
Configure logging throughout the workload, including application logs, resource logs, and AWS service logs. For example, verify that AWS CloudTrail, Amazon CloudWatch Logs, Amazon GuardDuty, and AWS Security Hub are enabled for the accounts within your organization.
A foundational practice is to establish a set of detection mechanisms at the account level. This base set of mechanisms is aimed at recording and detecting a wide range of actions on the resources in your account. They allow you to build out a comprehensive detective capability with options that include automated remediation and partner integrations to add functionality.
In AWS, services that can implement this base set include:
-
AWS CloudTrail
— Provides event history of your AWS account activity, including actions taken through the AWS Management Console, AWS SDKs, command line tools, and other AWS services. -
AWS Config
— Monitors and records your AWS resource configurations and allows you to automate the evaluation and remediation against desired configurations. -
Amazon GuardDuty
— A threat detection service that nearly continuously monitors for malicious activity and unauthorized behaviour to help protect your AWS accounts and workloads. GuardDuty also provides threat detection for EKS clusters. We are seeing more Telco network workloads move to containerize their workloads for improved resilience, scaling, and operational management. Getting appropriate visibility and alerting from clusters is an important aspect of the overall security strategy. -
AWS Security Hub
— Provides a single place that aggregates, organizes, and prioritizes your security alerts, or findings, from multiple AWS services and optional third-party products to give you a comprehensive view of security alerts and helps you understand your overall security posture across all of your AWS accounts
Many core AWS services provide service-level logging features such as Amazon VPC. Amazon VPC Flow Logs enable you to capture information about the IP traffic going to and from network interfaces, subnet, or VPC. This information can provide valuable insight on connectivity history, and cue automated actions based on anomalous behaviour. This may be particularly important for network workloads which have a heavy traffic flow of subscriber data, and so on.
Visualizing high-volume data such as VPC Flow Logs is important to provide analytics and
trend analysis. There are example solutions
Responding to security events helps to reduce the impact should any occur. Therefore, it’s imperative that, as a CSP, the organization is educated and well-prepared for different types of events. Levels of preparation strongly affect the ability of teams to cooperate effectively during an incident. Using automation to investigate and remediate events also reduces human effort and error, and enables CSPs to scale investigation capabilities. Regular reviews will help tune automation tools, and nearly continuously iterate.
CSPs should define incident response objectives and performance indicators, and define
response playbooks or plans which help guide the responders on the correct series of steps for
specific types of incidents. Overall, the CSP should maintain an appropriate strategy that
covers education, preparation, simulation, and iteration for response activities. More details
on these can be found on the Incident Response
section of the Security Pillar or the NIST SP 800-61 Guide
on Computer Security Incident Handling