Security Monitoring with CloudTrail

Build a pipeline that emails you when suspicious AWS activity is detected.

Introduction

30 Second Summary

Imagine someone sneaks into your house while you are away. You would want an alarm system that detects the intrusion and calls you immediately. Your AWS account deserves the same protection.

In this project, you will build a security monitoring pipeline that watches your AWS account for suspicious activity and sends you email alerts when something happens.

What You'll Build

A security monitoring pipeline using CloudTrail, CloudWatch, and Amazon SNS that detects root user activity and failed console sign-ins, then emails you an alert.

By the end of this project, you'll have:

A multi-region CloudTrail trail logging all management events across your AWS account.
Two metric filters and CloudWatch alarms that detect root user activity and failed console sign-ins.
An SNS topic that sends you real email notifications whenever a security event triggers an alarm.
Secret Mission: Add a third detection rule for security group configuration changes.

Are there any prerequisites?

You need an active AWS account with admin-level permissions. If you do not have one yet, create a free-tier AWS account before starting.

Set Up and Verify Your AWS Environment

Before you can detect suspicious activity in your AWS account, you need a properly configured environment. Every security tool you build in this project depends on being in the right region with the right permissions.

In this step, you will sign in to the AWS Management Console, set your region to us-east-1, and confirm there are no existing trails that might interfere with your new security monitoring setup.

In this step, get ready to:

Sign in to the AWS Management Console with admin permissions.
Set your region to US East (N. Virginia).
Verify no conflicting CloudTrail trails exist.

Sign in to the AWS Management Console

You need admin-level permissions to create trails, alarms, and SNS topics throughout this project. Signing in with an IAM admin user (instead of the root user) follows AWS security best practices.

Open your browser and navigate to https://console.aws.amazon.com/.
Sign in using an IAM user with admin permissions.

You should see the AWS Management Console home page with the search bar at the top and a list of recently visited services.

What if I'm signed in as the root user?

That is okay for this project. Everything will still work. However, best practice is to use an IAM admin user for daily work and reserve the root user for account-level tasks only.

Set your region to US East (N. Virginia)

AWS resources are region-specific. You need to create your security monitoring resources in us-east-1 because CloudTrail console sign-in events are always logged there regardless of which region you are working in.

Click the region selector in the top-right corner of the console (it displays your current region name).
Select US East (N. Virginia) from the dropdown.

The region selector should now display N. Virginia in the top-right corner.

Why us-east-1?

When you sign in using the root user, CloudTrail records the ConsoleLogin event in us-east-1. Creating your trail and alarms in the same region simplifies testing later when you verify the pipeline end-to-end.

Verify no existing multi-region trails conflict

If your account already has a multi-region trail, creating another one could result in duplicate log delivery. A quick check now saves confusion later.

Click the search bar at the top of the console and type CloudTrail.
Select CloudTrail from the search results.
In the left navigation panel, click Trails.
Note any existing trails listed on this page. If the page is empty, that is perfectly fine.

You should see the Trails page. It may be empty or show one or more existing trails.

Don't see the Trails page?

Make sure you clicked Trails in the left navigation, not Event history or Dashboard. If the left panel is not visible, click the hamburger menu icon (three horizontal lines) in the top-left of the CloudTrail page to expand it.

If you see an access denied error, your IAM user may not have admin permissions. Confirm your user has the AdministratorAccess policy attached.

help me troubleshoot why I can't see the CloudTrail Trails page

Your environment is ready. Next up, you will create a CloudTrail trail that streams management events to CloudWatch Logs in near real-time.

Create a CloudTrail Trail with CloudWatch Logs

Your AWS environment is verified and you know what trails already exist in your account. Now it's time to build the backbone of your security monitoring pipeline.

In this step, you'll create a CloudTrail trail that captures management events across all AWS regions and streams them into CloudWatch Logs. This integration is what makes real-time alerting possible.

In this step, get ready to:

Create a multi-region CloudTrail trail with CloudWatch Logs integration.
Configure the trail to log all management events (both Read and Write).
Verify the trail is actively logging.

Create a new trail

A trail is a configuration that tells CloudTrail where to deliver your account activity logs. You'll create one that covers all regions and sends events to both S3 (for storage) and CloudWatch Logs (for real-time monitoring).

Return to the CloudTrail Trails page (search CloudTrail in the console search bar, then click Trails in the left navigation).
Click Create trail.
For Trail name, enter security-monitoring-trail.
Under Storage location, select Create new S3 bucket.
Accept the auto-generated bucket name that AWS provides.
Under Log file SSE-KMS encryption, uncheck Enabled.

Why disable SSE-KMS encryption?

SSE-S3 encryption remains active by default, so your log files are still encrypted at rest. Disabling SSE-KMS simply avoids the extra complexity of creating and managing a KMS key for this project.

Now enable CloudWatch Logs integration on the same page.

Under CloudWatch Logs, check Enabled.
For Log group, select New and enter CloudTrail/SecurityMonitoring as the log group name.
For IAM Role, select New and accept the default role name CloudTrail_CloudWatchLogs_Role.
Click Next.

What does the IAM role do?

The IAM role CloudTrail_CloudWatchLogs_Role grants CloudTrail permission to deliver log events into your CloudWatch Logs log group. Without it, CloudTrail would only write to S3 and you wouldn't get near real-time event streaming.

Configure log events

Management events cover actions like creating resources, modifying permissions, and signing into the console. These are the events your security filters will inspect later.

On the Choose log events page, confirm that Management events is selected.
Under Management events, ensure both Read and Write are selected.
Leave Exclude AWS KMS events and Exclude Amazon RDS Data API events unchecked.
Leave Data events and Insights events at their defaults (not enabled).
Click Next.

Why both Read and Write events?

Read events capture things like listing resources or describing configurations. Write events capture changes like creating or deleting resources. Security monitoring needs both because an attacker might start with reconnaissance (Read) before making changes (Write).

Review and create the trail

On the Review and create page, verify that Multi-region trail is shown (this is the default for console-created trails).
Click Create trail.

You should see your new trail listed on the Trails page with its Status showing as Logging.

What is a multi-region trail?

A multi-region trail captures management events from every AWS region in your account, not just the region you created it in. This is critical for security because an attacker could operate in any region.

All trails created through the AWS Console are multi-region by default. You get full account-wide visibility without extra configuration.

Why CloudTrail + CloudWatch instead of GuardDuty?

GuardDuty is a managed threat detection service, but it works as a black box. CloudTrail + CloudWatch teaches you the underlying pattern that powers every AWS security architecture: log events, filter them, create metrics, and trigger alarms.

This pattern is also free within the free tier limits, while GuardDuty charges per event volume.

Log delivery takes about 15 minutes

CloudTrail begins delivering events to your CloudWatch Logs log group within approximately 15 minutes of trail creation. You don't need to wait now. The next step sets up SNS notifications, which gives CloudTrail time to start populating your log group.

Trail status not showing Logging?

Make sure you confirmed all settings and clicked Create trail on the review page. If the trail shows an error, check that the S3 bucket name is unique (AWS enforces global uniqueness for S3 bucket names).

Also confirm your region is set to US East (N. Virginia) in the top-right corner of the console.

Still stuck? Help me troubleshoot my CloudTrail trail creation issue.

Your trail is live and logging management events from every region in your account. Next up, you'll create an SNS topic so you have a notification channel ready for your security alarms.

Set Up SNS Email Notifications

Your CloudTrail trail is now logging management events across your entire AWS account. The next question is: how do you find out when something suspicious happens?

In this step, you'll set up Amazon SNS (Simple Notification Service) to send you email alerts. This notification channel is what your CloudWatch alarms will use later to reach you when they detect a security event.

In this step, get ready to:

Create a Standard SNS topic for security alerts.
Subscribe your email address and confirm the subscription.
Verify that CloudTrail logs are flowing into CloudWatch Logs.

Create an SNS topic

An SNS topic is a communication channel that can broadcast messages to multiple subscribers at once. You'll create one topic and later point your CloudWatch alarms at it.

In the search bar at the top of the AWS Console, type SNS and select Simple Notification Service from the results.
In the left navigation, choose Topics.
Choose Create topic.
For Type, select Standard.
For Name, enter SecurityAlerts.
Leave all other settings at their defaults and choose Create topic.

You should now see the topic detail page with the ARN (Amazon Resource Name) displayed near the top.

What is an ARN?

An ARN is a unique identifier for any resource in AWS. Think of it like a full mailing address that other AWS services use to find and communicate with your SNS topic.

Don't see the topic detail page?

Make sure you selected Standard as the type. FIFO topics have additional naming requirements that can cause errors.

Check that your topic name is exactly SecurityAlerts with no spaces or special characters.

Help me troubleshoot creating an SNS topic.

Subscribe your email to the topic

A topic on its own does nothing until it has subscribers. You'll add your email address so that any message published to this topic arrives in your inbox.

On the SecurityAlerts topic detail page, choose Create subscription.
For Protocol, select Email.
For Endpoint, enter your email address.
Choose Create subscription.

AWS sends a confirmation email to the address you entered. You need to confirm it before the subscription becomes active.

Check your email inbox for a message from AWS Notifications with the subject AWS Notification - Subscription Confirmation.
Click the Confirm subscription link in the email.
Return to the SNS console and navigate to Subscriptions in the left navigation.

Your subscription should now show a status of Confirmed.

Don't see the confirmation email?

Check your spam or junk folder. The email comes from AWS Notifications and some email providers filter it automatically.

If you still don't see it after a minute, return to the SNS console, delete the subscription, and create a new one. Double-check the email address for typos.

Help me fix my SNS email subscription.

Verify that CloudTrail logs are arriving

In the next step, you'll create metric filters that scan your CloudTrail logs for suspicious patterns. Those filters need actual log data to work with.

CloudTrail takes approximately 15 minutes to begin delivering events to CloudWatch Logs after trail creation. Now is a good time to check whether log streams have started appearing.

In the console search bar, type CloudWatch and select CloudWatch from the results.
In the left navigation, expand Logs and choose Log groups.
Choose the log group named CloudTrail/SecurityMonitoring.
Look for log streams listed on the page.

✔️ I see log streams listed

CloudTrail is delivering events successfully. You're ready to move on to the next step.

ⓧ The log group is empty

This is normal if fewer than 15 minutes have passed since you created the trail in the previous step. CloudTrail needs time to start delivering events.

Wait a few more minutes and refresh the page.
While you wait, verify that your trail status still shows Logging by navigating back to CloudTrail > Trails.
You can proceed to the next step even if streams have not appeared yet. The metric filters will work once data starts flowing.

Why the wait?

CloudTrail batches and delivers log files approximately every 5 minutes, but the first delivery after trail creation can take up to 15 minutes. This is a one-time delay. Once delivery starts, new events appear continuously.

Your notification channel is ready. Next up, you'll create metric filters that scan every incoming CloudTrail event for suspicious patterns and trigger these alerts automatically.

Create Metric Filters for Security Events

Your SNS topic is ready and your email subscription is confirmed. Now it's time to teach CloudWatch what to look for in your logs.

A metric filter scans every log event that arrives in a log group and increments a custom metric whenever the event matches a pattern you define. In this step, you will create two metric filters aligned with the CIS AWS Foundations Benchmark. One detects root user activity. The other detects failed console sign-ins.

In this step, get ready to:

Create a metric filter that detects root user activity in your account.
Create a metric filter that detects failed console sign-in attempts.

Create a metric filter for root user activity

The first detection rule catches any activity performed by the root user. Root access should be rare in a well-managed account, so any root activity is worth alerting on.

In the AWS Console search bar at the top, type CloudWatch and select CloudWatch from the results.
In the left navigation pane, expand Logs and choose Log groups.
Choose the log group named CloudTrail/SecurityMonitoring.
Select the Metric filters tab.
Choose Create metric filter.

In the Filter pattern field, paste the following pattern exactly:

{$.userIdentity.type="Root" && $.userIdentity.invokedBy NOT EXISTS && $.eventType !="AwsServiceEvent"}

What does this filter pattern detect?

This pattern matches any log event where the root user performed an action directly. The three conditions work together to avoid false positives.

$.userIdentity.type="Root" matches events from the root account.
$.userIdentity.invokedBy NOT EXISTS excludes actions triggered by AWS services on behalf of root.
$.eventType !="AwsServiceEvent" excludes background service events that root did not initiate.

Choose Next.
For Filter name, enter RootAccountUsage.
For Metric namespace, enter CISBenchmarkMetrics.
For Metric name, enter RootAccountUsageCount.
For Metric value, enter 1.
Leave Default value blank.
Choose Next.
Choose Create metric filter.

You should see your new RootAccountUsage filter listed under the Metric filters tab.

Don't see the metric filter?

Make sure you clicked Create metric filter on the final review page. If you only clicked Next, the filter was not saved.
Confirm you are viewing the correct log group (CloudTrail/SecurityMonitoring). If you navigated away, go back to Log groups and select it again.

Still stuck? Help me troubleshoot why my CloudWatch metric filter didn't save.

Create a metric filter for console sign-in failures

The second detection rule catches repeated failed login attempts. Multiple failures in a short window can indicate a brute-force attack or credential stuffing.

On the same log group page, stay on the Metric filters tab.
Choose Create metric filter.

In the Filter pattern field, paste the following pattern exactly:

{ ($.eventName = ConsoleLogin) && ($.errorMessage = "Failed authentication") }

What does this filter pattern detect?

This pattern matches ConsoleLogin events where the authentication failed. Every time someone enters an incorrect password on the AWS sign-in page, CloudTrail records the attempt with the error message Failed authentication.

Choose Next.
For Filter name, enter ConsoleSignInFailures.
For Metric namespace, enter CISBenchmarkMetrics.
For Metric name, enter ConsoleSignInFailureCount.
For Metric value, enter 1.
Leave Default value blank.
Choose Next.
Choose Create metric filter.

You should now see two metric filters listed under the Metric filters tab: RootAccountUsage and ConsoleSignInFailures.

Only seeing one filter?

Refresh the page. Sometimes the console needs a manual refresh to display newly created filters.
Check that you created both filters on the same log group (CloudTrail/SecurityMonitoring). If you accidentally navigated to a different log group, your second filter may be in the wrong place.

Need more help? Help me figure out why I only see one metric filter on my log group.

Why the CISBenchmarkMetrics namespace?

Both filters publish metrics to a custom namespace called CISBenchmarkMetrics. A namespace groups related metrics together in CloudWatch. This name signals that these detections align with the CIS AWS Foundations Benchmark controls (CloudWatch.1 for root usage, CloudWatch.6 for sign-in failures).

In the next step, you will create alarms on these metrics that send email alerts through your SecurityAlerts SNS topic.

Your detection rules are in place. Next up, you will wire these metrics to CloudWatch alarms that trigger email alerts through SNS whenever suspicious activity is detected.

Create CloudWatch Alarms and Test Your Pipeline

Your metric filters are now counting root user activity and failed sign-ins. But a counter that nobody watches is useless during a real security incident.

CloudWatch Alarms close that gap. They evaluate your metric counters on a schedule and fire a notification through SNS the moment a threshold is crossed. In this step, you'll wire up both alarms and test the full detection pipeline end-to-end.

In this step, get ready to:

Create a CloudWatch alarm for root user activity.
Create a CloudWatch alarm for console sign-in failures.
Test the pipeline by triggering a real alert and receiving an email notification.

Create an alarm for root user activity

The first alarm watches the RootAccountUsageCount metric. If the count hits 1 or higher in any 5-minute window, you want to know immediately.

Return to the CloudTrail/SecurityMonitoring log group in CloudWatch. In the left navigation under Logs, choose Log groups, then select CloudTrail/SecurityMonitoring.
Select the Metric filters tab.
Select the checkbox next to RootAccountUsage.
Choose Create alarm.

The Create alarm wizard opens with the metric pre-filled. Now configure the conditions:

Under Specify metric and conditions, confirm the Metric name shows RootAccountUsageCount.
Set Statistic to Sum.
Set Period to 5 minutes.
For Threshold type, select Static.
For Whenever RootAccountUsageCount is, select Greater/Equal.
Enter 1 as the threshold value.
Choose Next.

Now connect the alarm to your SNS topic so it sends you an email:

Under Configure actions, for Alarm state trigger, select In alarm.
For Select an SNS topic, choose Select an existing SNS topic.
For Send a notification to, select SecurityAlerts.
Choose Next.

Finally, give your alarm a descriptive name:

For Alarm name, enter CIS-RootAccountUsage.
For Alarm description, enter Alerts when the root user performs any activity in the account.
Choose Next, review the summary, then choose Create alarm.

Why a threshold of 1?

The root account should almost never be used for day-to-day work. Any root activity at all is suspicious, so even a single event in a 5-minute window warrants an alert. This aligns with the CIS AWS Foundations Benchmark control CloudWatch.1.

Create an alarm for console sign-in failures

The second alarm watches for repeated failed sign-in attempts. Three or more failures in 5 minutes could indicate a brute-force attack.

Return to CloudWatch > Log groups > CloudTrail/SecurityMonitoring > Metric filters tab.
Select the checkbox next to ConsoleSignInFailures.
Choose Create alarm.

Configure the metric and conditions:

Confirm the Metric name shows ConsoleSignInFailureCount.
Set Statistic to Sum.
Set Period to 5 minutes.
For Threshold type, select Static.
For Whenever ConsoleSignInFailureCount is, select Greater/Equal.
Enter 3 as the threshold value.
Choose Next.

Configure the notification action:

For Alarm state trigger, select In alarm.
For Select an SNS topic, choose Select an existing SNS topic.
For Send a notification to, select SecurityAlerts.
Choose Next.

Name the alarm:

For Alarm name, enter CIS-ConsoleSignInFailures.
For Alarm description, enter Alerts when 3 or more console sign-in failures occur in 5 minutes.
Choose Next, review the summary, then choose Create alarm.

Navigate to CloudWatch > Alarms > All alarms in the left navigation. You should see both CIS-RootAccountUsage and CIS-ConsoleSignInFailures listed with their state showing Insufficient data.

Why does it say Insufficient data?

When you create a new CloudWatch alarm, its state is immediately set to Insufficient data. This means CloudWatch has not yet received enough metric data points to evaluate the threshold. The alarm transitions to OK or ALARM once the first data arrives.

For your alarms, this is completely normal. The metric filters only publish data when a matching event occurs, so until someone triggers a root login or a failed sign-in, there is nothing to evaluate.

Don't see both alarms?

Make sure you are viewing All alarms in the left navigation, not a filtered view. If an alarm is missing, return to the metric filters tab on the CloudTrail/SecurityMonitoring log group and repeat the creation steps for the missing alarm.

Help me troubleshoot my missing CloudWatch alarm.

Test the pipeline end-to-end

Your monitoring pipeline is fully wired: CloudTrail captures events, CloudWatch Logs receives them, metric filters count them, and alarms fire notifications. Time to prove it works with a real root login event.

Open a private or incognito browser window.
Navigate to https://console.aws.amazon.com/.
Sign in using your root user credentials (the email address you used to create your AWS account).
Perform any action, such as visiting the IAM dashboard.
Sign out of the root account and close the incognito window.

What happens next?

CloudTrail records the root user's ConsoleLogin event and delivers it to your CloudWatch Logs log group. This takes approximately 5 to 15 minutes. Once the log arrives, the metric filter increments RootAccountUsageCount and the alarm evaluates the new data point against its threshold.

When the threshold is breached, the alarm transitions to ALARM state and publishes a notification to your SecurityAlerts SNS topic. SNS then sends you an email.

Wait 5 to 15 minutes for CloudTrail to deliver the event.
Check your email inbox for a message from AWS Notifications about the CIS-RootAccountUsage alarm entering ALARM state.

You can also verify in the console by returning to CloudWatch > Alarms. The CIS-RootAccountUsage alarm should now show a red In alarm state.

No email after 15 minutes?

Confirm your SNS subscription is still in Confirmed status by navigating to SNS > Subscriptions. If it shows PendingConfirmation, check your spam folder for the original confirmation email.

Also verify that you signed in with the root user (the account owner email), not your IAM admin user. The metric filter specifically matches root identity events.

Help me figure out why my CloudWatch alarm did not send an email.

Secret mission

Detect Security Group Changes

Your pipeline catches root logins and failed sign-ins, but what about changes to your network perimeter? Security groups control which traffic can reach your resources. In this mission, add a third detection rule that alerts you whenever someone modifies a security group.

Clean Up Your Resources

This project runs almost entirely within AWS Free Tier. The first CloudTrail trail, up to 10 CloudWatch alarm metrics, and the first 1,000 SNS email notifications per month are all free. S3 storage for CloudTrail logs costs only pennies per month on a personal account.

Decide whether to keep your resources running, pause them to come back later, or delete them entirely.

Resources you used:

CloudTrail trail (security-monitoring-trail).
S3 bucket storing CloudTrail log files.
CloudWatch Logs log group (CloudTrail/SecurityMonitoring).
Metric filters (RootAccountUsage, ConsoleSignInFailures, SecurityGroupChanges).
CloudWatch alarms (CIS-RootAccountUsage, CIS-ConsoleSignInFailures, CIS-SecurityGroupChanges).
SNS topic (SecurityAlerts) and email subscription.
IAM role (CloudTrail_CloudWatchLogs_Role).
Security group created during testing (if completed the Secret Mission).

Keep everything running

No action needed. Choose this if you want production-useful security monitoring at near-zero cost. This pipeline is genuinely useful on a personal AWS account because it alerts you to unauthorized root activity and failed sign-in attempts.

The trail, alarms, and SNS topic will continue running. Expect minimal costs (pennies per month for S3 log storage on a low-activity account).

Pause - I'll come back to this later

CloudTrail trails do not have a pause mechanism. The trail either logs events or it does not. If you want to stop log delivery temporarily, you can stop logging on the trail without deleting it.

Navigate to CloudTrail in the console.
Choose Trails, then select security-monitoring-trail.
Choose Stop logging and confirm.
This stops new events from being delivered to S3 and CloudWatch Logs. Your alarms, metric filters, and SNS topic remain in place, ready to resume when you restart logging.

Delete - I don't want to use this again

Remove all project resources and start fresh. Follow these steps in order.

Delete the CloudWatch alarms

Open the CloudWatch console.
In the left navigation, choose Alarms.
Select the checkboxes next to CIS-RootAccountUsage, CIS-ConsoleSignInFailures, and CIS-SecurityGroupChanges.
Choose Actions, then Delete.
Confirm by choosing Delete.

Delete the metric filters

In the CloudWatch console, choose Log groups under Logs in the left navigation.
Choose the log group CloudTrail/SecurityMonitoring.
Select the Metric filters tab.
Select the checkbox next to RootAccountUsage, then choose Delete and confirm.
Repeat for ConsoleSignInFailures and SecurityGroupChanges.

Delete the SNS topic

Navigate to the Amazon SNS console.
In the left navigation, choose Topics.
Select the SecurityAlerts topic, then choose Delete.
In the confirmation dialog, enter delete me and choose Delete.
Deleting the topic also removes all its subscriptions, so you do not need to delete the email subscription separately.

Delete the CloudTrail trail

Navigate to the CloudTrail console.
In the left navigation, choose Trails.
Choose the trail name security-monitoring-trail.
At the top of the trail details page, choose Delete.
Confirm the deletion. Deleting the trail stops event logging but does not delete existing log files in S3.

Empty and delete the S3 bucket

Navigate to the Amazon S3 console.
Find the bucket that stores your CloudTrail logs (its name starts with aws-cloudtrail-logs-).
Select the bucket, then choose Empty.
Type permanently delete to confirm, then choose Empty.
After emptying, select the bucket again and choose Delete.
Enter the bucket name to confirm, then choose Delete bucket.

Delete the CloudWatch Logs log group

Return to the CloudWatch console.
Under Logs, choose Log groups.
Select the radio button next to CloudTrail/SecurityMonitoring.
Choose Actions, then Delete log group(s).
Confirm the deletion.

Delete the IAM role

Navigate to the IAM console.
In the left navigation, choose Roles.
Search for CloudTrail_CloudWatchLogs_Role.
Select the role, then choose Delete.
Enter the role name to confirm, then choose Delete.

Delete the test security group (Secret Mission)

If you created a security group to test the Secret Mission alarm, navigate to the EC2 console.
In the left navigation under Network & Security, choose Security Groups.
Select the test security group you created, choose Actions, then Delete security groups.
Confirm the deletion.

Nice Work!

You just built a production-ready security monitoring pipeline on AWS. Your account is now actively watching for suspicious activity and alerting you the moment something happens.

You learned how to:

Built a multi-region CloudTrail trail that streams all management events across your entire AWS account into CloudWatch Logs in near real-time.
Implemented CIS Benchmark-aligned metric filters that detect root user activity and failed console sign-ins, turning raw log data into actionable security metrics.
Configured CloudWatch alarms that trigger email notifications through SNS when suspicious events occur, and tested the full detection pipeline end-to-end.
Secret Mission: Added security group change detection, extending your pipeline to cover network perimeter modifications.

Ready to quiz yourself?