# SALZ: Default settings
Your AWS Managed Services (AMS) network is configured in a standardized manner with defaults for most services.
This section describes the default settings that AMS uses for security, access, monitoring, logging, continuity, and patching, management.
For an example of infrastructure costs, see [Basic components](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-sd.html#basic-components).
Firewall rules are provided in [Set up your Firewall](setup-firewall.md)
# Endpoint Security (EPS)
Resources that you provision in your AMS Advanced environment automatically include the installation of an endpoint security (EPS) monitoring client. This process ensures that the AMS Advanced-managed resources are monitored and supported 24x7. In addition, AMS Advanced monitors all agent activity, and an incident is created if any security event is detected.
**Note**
Security incidents are handled as incidents; for more information, see [Incident response](https://docs.aws.amazon.com/managedservices/latest/userguide/sec-incident-response.html).
Endpoint security provides anti-malware protection, specifically, the following actions are supported:
+ EC2 instances register with EPS
+ EC2 instances deregister from EPS
+ EC2 instances real-time anti-malware protection
+ EPS agent-initiated heartbeat
+ EPS restore quarantined file
+ EPS event notification
+ EPS reporting
AMS Advanced uses Trend Micro for endpoint security (EPS). These are the default EPS settings. To learn more about Trend Micro, see the [Trend Micro Deep Security Help Center](https://help.deepsecurity.trendmicro.com/aws/welcome.html?redirected=true); note that non-Amazon links may change without notice to us.
AMS Advanced Multi-Account Landing Zone (MALZ) default settings are described in the following sections; for non-default AMS multi-account landing zone EPS settings, see [ AMS Advanced Multi-Account Landing Zone EPS non-default settings](https://docs.aws.amazon.com/managedservices/latest/userguide/security-mgmt.html#malz-eps-settings).
**Note**
You can bring your own EPS, see [AMS bring your own EPS](https://docs.aws.amazon.com/managedservices/latest/userguide/ams-byoeps.html).
## General EPS settings
Endpoint security general network settings.
**EPS defaults**
| Setting | Default |
| --- | --- |
| Firewall Ports (Instances’ Security Group) | EPS Deep Security Manager agents (DSMs) must have port 4120 open for the Agent/Relay to Manager communication, and port 4119 for the Manager Console. EPS Relays must have port 4122 open for the Manager/Agent to Relay communication. No specific ports should be open for customer instance inbound communication because agents initiate all requests. |
| Communication Direction | Agent/Appliance Initiated |
| Heartbeat Interval | Ten minutes |
| Number of missed heartbeats before an alert | Two |
| Maximum allowed drift (difference) between server times | Unlimited |
| Raise offline errors for inactive (registered, but not online) virtual machines | No |
| Default policy | Base policy (described next) |
| Activation of multiple computers with the same host name | Is allowed |
| Alerts for pending updates are raised | After seven days |
| Update schedule | AMS targets a monthly release cycle for Trend Micro Deep Security Manager (DSM) / Deep Security Agent (DSA) software updates. However, AMS doesn't maintain an SLA for updates. Updates are performed fleet-wide by AMS developer teams during a deployment. DSA/DSA updates are logged in Trend Micro DSM system events that AMS retains locally by default for 13 weeks. For vendor documentation, see [System events](https://help.deepsecurity.trendmicro.com/12_0/aws/Events-Alerts/ref-events-system.html) in the Trend Micro Deep Security Help Center. Logs are also exported to log group /aws/ams/eps/var/log/DSM.log in Amazon CloudWatch. |
| Update source | Trend Micro Update Server (https://ipv6-iaus.trendmicro.com/iau\$1server.dll/) |
| Event or log data deletion | Events and logs are deleted from the DSM database after seven days. |
| Agent software versions are held | Up to five |
| Most recent rule updates are held | Up to ten |
| Logs storage | By default, log files are stored securely in Amazon S3, but you can also archive them to Amazon Glacier to help meet audit and compliance requirements. |
## Base policy
Endpoint security base policy default settings.
**EPS base policy**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/eps-defaults.html)
## Anti-malware
Endpoint security anti-malware settings.
**EPS anti-malware defaults**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/eps-defaults.html)
# Security groups
In AWS VPCs, AWS Security Groups act as virtual firewalls, controlling the traffic for one or more stacks (an instance or a set of instances). When a stack is launched, it's associated with one or more security groups, which determine what traffic is allowed to reach it:
+ For stacks in your public subnets, the default security groups accept traffic from HTTP (80) and HTTPS (443) from all locations (the internet). The stacks also accept internal SSH and RDP traffic from your corporate network, and AWS bastions. Those stacks can then egress through any port to the Internet. They can also egress to your private subnets and other stacks in your public subnet.
+ Stacks in your private subnets can egress to any other stack in your private subnet, and instances within a stack can fully communicate over any protocol with each other.
**Important**
The default security group for stacks on private subnets allows all stacks in your private subnet to communicate with other stacks in that private subnet. If you want to restrict communications between stacks within a private subnet, you must create new security groups that describe the restriction. For example, if you want to restrict communications to a database server so that the stacks in that private subnet can only communicate from a specific application server over a specific port, request a special security group. How to do so is described in this section.
## Default Security Groups
------
#### [ MALZ ]
The following table describes the default inbound security group (SG) settings for your stacks. The SG is named "SentinelDefaultSecurityGroupPrivateOnly-vpc-ID" where *ID* is a VPC ID in your AMS multi-account landing zone account. All traffic is allowed outbound to "mc-initial-garden-SentinelDefaultSecurityGroupPrivateOnly" via this security group (all local traffic within stack subnets is allowed).
All traffic is allowed outbound to 0.0.0.0/0 by a second security group "SentinelDefaultSecurityGroupPrivateOnly".
**Tip**
If you're choosing a security group for an AMS change type, such as EC2 create, or OpenSearch create domain, you would use one of the default security groups described here, or a security group that you created. You can find the list of security groups, per VPC, in either the AWS EC2 console or VPC console.
There are additional default security groups that are used for internal AMS purposes.
**AMS default security groups (inbound traffic)**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/about-security-groups.html)
------
#### [ SALZ ]
The following table describes the default inbound security group (SG) settings for your stacks. The SG is named "mc-initial-garden-SentinelDefaultSecurityGroupPrivateOnly-*ID*" where *ID* is a unique identifier. All traffic is allowed outbound to "mc-initial-garden-SentinelDefaultSecurityGroupPrivateOnly" via this security group (all local traffic within stack subnets is allowed).
All traffic is allowed outbound to 0.0.0.0/0 by a second security group "mc-initial-garden-SentinelDefaultSecurityGroupPrivateOnlyEgressAll-*ID*".
**Tip**
If you're choosing a security group for an AMS change type, such as EC2 create, or OpenSearch create domain, you would use one of the default security groups described here, or a security group that you created. You can find the list of security groups, per VPC, in either the AWS EC2 console or VPC console.
There are additional default security groups that are used for internal AMS purposes.
**AMS default security groups (inbound traffic)**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/about-security-groups.html)
------
## Create, Change, or Delete Security Groups
You can request custom security groups. In cases where the default security groups do not meet the needs of your applications or your organization, you can modify or create new security groups. Such a request would be considered approval-required and would be reviewed by the AMS operations team.
To create a security group outside of stacks and VPCs, submit an RFC using the `Deployment | Advanced stack components | Security group | Create (managed automation)` change type (ct-1oxx2g2d7hc90).
For Active Directory (AD) security group modifications, use the following change types:
+ To add a user: Submit an RFC using Management \$1 Directory Service \$1 Users and groups \$1 Add user to group [ct-24pi85mjtza8k]
+ To remove a user: Submit an RFC using Management \$1 Directory Service \$1 Users and groups \$1 Remove user from group [ct-2019s9y3nfml4]
**Note**
When using manual CTs, AMS recommends that you use the ASAP **Scheduling** option (choose **ASAP** in the console, leave start and end time blank in the API/CLI) as these CTs require an AMS operator to examine the RFC, and possibly communicate with you before it can be approved and run. If you schedule these RFCs, be sure to allow at least 24 hours. If approval does not happen before the scheduled start time, the RFC is rejected automatically.
## Find Security Groups
To find the security groups attached to a stack or instance, use the EC2 console. After finding the stack or instance, you can see all security groups attached to it.
For ways to find security groups at the command line and filter the output, see [https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-groups.html](https://docs.aws.amazon.com/cli/latest/reference/ec2/describe-security-groups.html).
# EC2 IAM instance profile
An instance profile is a container for an IAM role that you can use to pass role information to an EC2 instance when the instance starts.
------
#### [ MALZ ]
There are two AMS default instance profiles, `customer-mc-ec2-instance-profile` and `customer-mc-ec2-instance-profile-s3`. These instance profiles provide the permissions described in the following table.
**Policy descriptions**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/defaults-instance-profile.html)
------
#### [ SALZ ]
There is one AMS default instance profile, `customer-mc-ec2-instance-profile`, that grants permissions from the IAM instance policy `customer_ec2_instance_profile_policy`. This instance profile provides the permissions described in the following table. The profile grants permissions to the applications running on the instance, not to users logging into the instance.
Policies often include multiple statements, where each statement grants permissions to a different set of resources or grants permissions under a specific condition.
CW = CloudWatch. ARN = Amazon Resource Name. \$1 = wildcard (any).
**EC2 default IAM instance profile permissions**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/defaults-instance-profile.html)
------
If you're unfamiliar with Amazon IAM policies, see [Overview of IAM Policies](https://docs.aws.amazon.com/IAM/latest/UserGuide/access_policies.html) for important information.
**Note**
Policies often include multiple statements, where each statement grants permissions to a different set of resources or grants permissions under a specific condition.
# Monitored metrics defaults
The following table shows what is monitored and the default alerting thresholds. You can change the defaults with a change management request for change (RFC).
**Note**
CloudWatch launched extended retention of metrics in November 1, 2016. For more information, see [CloudWatch Limits](https://docs.aws.amazon.com/AmazonCloudWatch/latest/monitoring/cloudwatch_limits.html).
**Alerts from baseline monitoring**
[\[See the AWS documentation website for more details\]](http://docs.aws.amazon.com/managedservices/latest/onboardingguide/monitoring-default-metrics.html)
# Log retention and rotation defaults
This section describes AMS log management defaults; for more information, see [Log Management](https://docs.aws.amazon.com/managedservices/latest/userguide/log-mgmt.html).
+ Rotation = Log turnover inside the instances
+ Retention = Period of time we keep the logs in Amazon CloudWatch Logs and Amazon Simple Storage Service (S3)
The logs are retained in CloudWatch Logs as needed (you can configure this), and in S3. They don't expire or get deleted and are subject to service durability. For detailed S3 durability information, see [Data protection in Amazon S3](https://docs.aws.amazon.com/AmazonS3/latest/userguide/DataDurability.html).
You can request a change to log retention for all logs, except AWS CloudTrail logs, which are kept for 10 years for audit and security reasons.
Log rotation is configured inside the instances. By default, operating system and security logs rotate hourly if they reach over 100MB, this is done to ensure that you don't run short on disk in the instances.
The log agent inside the instances uploads the log online to CloudWatch Logs, from there the logs are archived to S3.
The logs are stored in CloudWatch Logs and S3 in the raw format they are generated, there is no pre-processing.
# Continuity management defaults
This section describes AMS continuity management defaults; for more information on AMS backups, see the AMS User Guide Continuity Management chapter.
Backup configuration is done at the time of onboarding. These are the default (recommended) backup settings.
# VPC tag and defaults
For the most current information on AMS backup, see [Continuity management](https://docs.aws.amazon.com/managedservices/latest/userguide/continuity-mgmt.html).
**Important**
By default, EC2 stack backups are disabled (Backup = False). You can enable EC2 instance backups at the time of creation by adding a tag `Key: Backup, Value: True` when requesting an EC2 stack through an RFC (CT ct-14027q0sjyt1h). If you want to add the tag after the instance has been created, submit an RFC with the Management \$1 Advanced stack components \$1 EC2 instance stack \$1 Update CT (ct-38s4s4tm4ic4u).
# EC2 instance tag and defaults
The **EC2 stack backup tag** specifies whether the stack requires a snapshot of the attached EBS volumes or not.
Tag` Key: Backup`
Tag` Value: True, False`
By default, the value is `False` the backup tag is not present, and the stack does not have scheduled backups.
Change the tag `Key: Backup` to `Value: True` to enable backups, which are then done on the schedule set with the VPC backup tag.
**Note**
The casing for the tag value (Value only) is insensitive, so True/true or False/false are all acceptable.
# RDS instance backup and defaults
The Amazon Relational Database Service (RDS) default values are defined in the stack templates:
` Backup: Yes`
` Backup Window: 22:00-23:00 (RDS local time zone)`
` Retention Period: 7 (7 snapshots stored)`
# Patching defaults
This section describes AMS patching defaults; for more information on AMS patching, see the AMS User Guide Patch Management chapter.
AMS releases patched AMIs on a monthly basis; all new stack requests should be configured with the latest AMS AMI.
**Important**
AMS Patch Orchestrator, tag-based patching, uses AWS Systems Manager (SSM) functionality to allow you to tag, or have AMS tag for you, instances and have those instances patched using a baseline and a window that you configure. To learn more, see [Patch Orchestrator: a tag-based patching model](https://docs.aws.amazon.com/managedservices/latest/userguide/patch-orchestrator.html).
AMS-standard, account-based, patching: For each account with stacks that receive in-place patching, a notification of upcoming applicable patches is sent out shortly after “patch Tuesday”. The notification contains a list of all stacks and the applicable patches as well as the suggested patch window. For critical patches, the window is set no longer than 10 days in advance, and for standard patching no more than 14 days in advance. If you do not reply to the notification, patching does not occur. If you would like to exclude certain patches, reply to the notification, or submit a service request. If you reply with consent to patching, but don’t specifically request a different schedule, patches are applied as described in the notification that you receive.
**Note**
The patch service notification is an email sent to the account contacts and contains a link to the AWS Support console. You can reply through the AWS Support console or through the AMS service request page, where the notification appears as a service notification.
At the time of the AMS-standard patching process, AMS performs the following:
1. You are sent a patching service notification fourteen days before the proposed patch window. The patching service notification is sent via email to the contact email address that you have on file for your account.
1. Identifies all reachable EC2 instances in the stack based on the list of stacks provided in the patching notification. In this case, "Reachable" means instances that are in the "Running" EC2 state, and have the EC2 Run Command agent fully operational.
1. AMS performs patching in a manner that ensures that a sufficient number of EC2 instances are running concurrently (configured through the `healthy-host-threshold` setting) so that the stack remains healthy.
1. After the patching operation is complete for all EC2 instances, AMS updates the RFC with the patching status: Success, Partial Success or Failure. In the case of any status other than Success, a ticket is created for an operator to follow up on the patching results and take any corrective actions.