-
Notifications
You must be signed in to change notification settings - Fork 277
Policies
-
Security Groups should not have an inbound rule allowing 0.0.0.0/0 for non DMZ resources.
-
EC2 instances should not have any publicly accessible ports.
-
Security Groups with RDP port 3389 should not be publicly accessible.
-
AWS GuardDuty service should be enabled on all regions of all AWS accounts.
-
EC2 instances should not be in stopped state for more than 60 days.
-
Deprecated EC2 instances types should not be used to launch instances.
-
CORP ADFS integrated AWS accounts should not have IAM account for individuals.
-
Lambda function invocations count should not exceed the threshold.
-
All MongoDB instances should be protected with access control mechanism.
-
AWS service limits should be upgraded to match growing needs.
-
Cloud formation stacks should be tagged with mandatory tags.
-
Elasticsearch resources should be tagged with mandatory tags.
-
Redshift-attached Security Group should not be publicly accessible.
-
Non-whitelisted S3 buckets should not be publicly accessible.
-
Unapproved Security Groups should not have inbound rule allowing 0.0.0.0/0 for any port.
-
Security Group with SSH port 22 should not be publicly accessible.
-
Non-Whitelisted SQS resources should not be publicly accessible.
-
Non-Whitelisted IAM users should not have core networking privileges.
-
Non-whitelisted IAM Roles should not have core networking privileges.
-
Non-Whitelisted IAM Role should not have EC2 RunInstance privilege.
-
EC2 instances should not be publicly accessible on port 8080.
-
EC2 instances should not be publicly accessible on port 138.
-
EC2 instances should not be publicly accessible on default MySQL port 3306.
-
S3 bucket should not have hosting website or redirecting requests.
-
EC2 instances should not be publicly accessible on default SQL Browser port 1434.
-
EC2 instances should not be publicly accessible on default POSTGRESQL port 5432.
-
EC2 instances should not be publicly accessible on port 3389.
-
ACM Certificate should not expire in a configurable number of days from the current date.
-
IAM certificate should not expire in mentioned days from current date.
-
Access log should be enabled to ELB and attached to mentioned bucket.
-
Access log should be enabled to CloudFront and attached to mentioned bucket.
-
Remediate vulnerabilities by a vulnerability Assessment solution.
-
Install a vulnerability assessment solution on your Virtual Machines.
-
Harden Network Security Group rules of publicly accessible Virtual Machines.
Unprotected S3 buckets are one of the major causes of data theft and intrusions. With the exception of S3 buckets used for hosting public websites, no S3 buckets should be publicly accessible for unauthenticated users or for 'Any AWS Authenticated Users'.
AWS S3 buckets cannot be publicly accessible for READ/WRITE actions in order to protect S3 data from unauthorized users. An S3 bucket that allows WRITE (UPLOAD/DELETE) access to everyone (i.e. anonymous users) can provide attackers the capability to add, delete and replace objects within the bucket, which can lead to data loss, unintended changes to applications using the S3 bucket, a big bill or all three.
To remediate this issue:
- S3 buckets should be protected by using the bucket ACL and bucket policies.
- If you want to share data via S3 buckets to other users.
- you could create pre-signed URLs which will be valid only for short duration.
- For example, the following command will generate a pre-signed URL for the file 'samplefile.zip': aws s3 presign --expires-in 36000 s3://sharedfolder/samplefile.zip
- This command will generate pre-signed URLS for every object in a S3 bucket.
aws s3 ls --recursive s3://sharedfolder | awk '{print $4}' | while read line; do aws s3 presign --expires-in 36000 s3://sharedfolder/$line; done
- For all automation-related work, use the bucket policy and grant access to the required roles.
It is best practice to allow required IP ranges and specific port in the security groups that will be used for securing EC2 instances in private subnets.
To remediate this issue:
- Edit the Security Groups and allow only specific IP ranges and ports.
An RDS snapshot may contain sensitive or customer information. No RDS snapshot should be made public, although there may be some rare cases where this is required. Such cases have to go through the exception process.
To remediate this issue:
- Make the snapshot private.
EC2 instances should not be publicly accessible from internet (Except for the servers in DMZ zone). Ideally these instances should be behind a firewall (AWS WAF or any other firewall).
To remediate this issue:
- Do not allow public access to well known ports of an EC2 instance directly.
Amazon GuardDuty is a managed threat detection service that continuously monitors your VPC flow logs, CloudTrail event logs and DNS logs for malicious or unauthorized behavior. When GuardDuty detects a suspicious or unexpected behavior in your AWS account, it generates a finding. A finding is a notification that contains information about a potential security threat identified by the GuardDuty service. The finding details includes data about the finding actor, the AWS resource(s) involved in the suspicious activity, the time when the activity occurred and so on.
To remediate this issue:
- Follow the step by step guide line provided for each finding from the GuardDuty console.
Global permission to access the well known services like RDP on port 3389 (Windows RDP) should not be allowed.
To remediate this issue:
- Do not allow public access to well known ports of an EC2 instance directly (except for 80 and 443).
Charges begin when a volume is created. If a volume remains unattached or has very low write activity (excluding boot volumes) for a period of time, the volume is probably not being used.
To remediate this issue:
- Consider creating a snapshot and deleting the volume to reduce costs.
Yellow: A volume is unattached or had less than 1 IOPS per day for the past 7 days.
Depending on the purpose for which the EBS was used, the snapshot might carry sensitive information about its cloud ecosystem, customer PII, customer CPNI or other sensitive data. The cases where a publicly accessible snapshot is very rare; such cases have to go through an exception process.
To remediate this issue:
- Make the snapshot private.
An RDS snapshot may contain sensitive or customer information. No RDS snapshot should be made public from our accounts. There are very rare cases where this might be required. Those cases have to go through an exception process.
To remediate this issue:
- Make the snapshot private.
If an Amazon Redshift cluster has not had a connection for a prolonged period of time or is using a low amount of CPU, we can use lower-cost options such as downsizing the cluster or shutting down the cluster and taking a final snapshot.
Yellow: A running cluster has not had a connection in the last 7 days. Yellow: A running cluster had less than 5% cluster-wide average CPU utilization for 99% of the last 7 days.
To remediate this issue:
- Consider shutting down the cluster and taking a final snapshot, or
- Downsize the cluster.
EIPs are static IP addresses designed for dynamic cloud computing. Unlike traditional static IP addresses, EIPs can mask the failure of an instance or Availability Zone by remapping a public IP address to another instance in your account. A nominal charge is imposed for an EIP that is not associated with a running instance.
To remediate this issue:
- Associate the EIP with a running active instance, or
- Release the unassociated EIP.
If a DB instance has not had a connection for a prolonged period of time, you can delete the instance to reduce costs. If persistent storage is needed for data on the instance, you can use lower-cost options such as taking and retaining a DB snapshot. Manually created DB snapshots are retained until you delete them.
To remediate this issue:
- Consider taking a snapshot of the idle DB instance and then deleting it.
Un-used assets should be terminated promptly for obvious cost saving reasons
To remediate this issue:
- Terminate the ELB if it is no longer required
A publicly accessible database end-point would be vulnerable to brute force login attempts and subsequent data leak /loss. Unauthorized access attempts should be restricted to minimize security risks.
To remediate this issue:
- To restrict access to any publicly accessible RDS database instance, you must disable the database Publicly Accessible flag and update the VPC Security Group associated with the instance.
Enforce a strong password policy on IAM console authentications. By default AWS does not configure the maximal strength password complexity policy on your behalf.
To remediate this issue:
- Log into your AWS console.
- Go to the IAM service.
- On the left menu select Password Policy which should be the bottom option.
- Set the Minimum Password Length form field to XX (or higher) and Select each of the checkboxes so that all four required complexity options are selected.
All the AWS accounts should have GuardDuty enabled. Amazon GuardDuty is a managed threat detection service that continuously monitors for malicious or unauthorized behavior to help you protect your AWS accounts and workloads. It monitors for activity such as unusual API calls or potentially unauthorized deployments that indicate a possible account compromise. GuardDuty also detects potentially compromised instances or reconnaissance by attackers
To remediate this issue:
- Enable GuardDuty for all regions.
Cleaning up un-used Security Groups is best practice to keep the Security Groups up to date and relevant.
To remediate this issue:
- Delete the unused Security Groups.
Un-used assets should be terminated promptly for obvious cost saving reasons
To remediate this issue:
- Delete the volume if it is no longer required
Checks your Elastic Load Balancing configuration for load balancers that are not actively used. Any load balancer that is configured accrues charges. If a load balancer has no associated back-end instances or if network traffic is severely limited, the load balancer is not being used effectively.
To remediate this issue:
- If your load balancer has no active back-end instance then consider registering instances or deleting your load balancer
Un-used assets should be terminated promptly for obvious cost saving reasons
To remediate this issue:
- Terminate the ELB if it is no longer required
Stopped EC2 instances still incur cost for the volumes, ElasticIP associated with it, potential AWS marketplace license costs as well.
To remediate this issue:
- Terminate the EC2 instance if it is no longer required.
VPC flow logs provide vital information for debugging and forensic exercise in case of any incidents. These should be always enabled
To remediate this issue:
- Enable VPC flow logs
Deprecated EC2 instance types (Old generation instance types) should not be used. Using old generation instance types have cost implication, they are not covered in our RI purchase as well
To remediate this issue:
- Stop the instance and change the instance type to a newer generation one and start it
Checks the Amazon Elastic Compute Cloud (Amazon EC2) instances that were running at any time during the last 14 days and alerts yu if the daily CPU utilization was 10% or less and network I/O was 5 MB or less on 4 or more days.
To remediate this issue:
- Consider stopping or terminating instances that have low utilization.
Every AWS account should be configured with corp AD as IAM Identity provider. This identity provider is required for logging into AWS with our corp AD account
To remediate this issue:
- Add the corp AD identity provider configuration back to the AWS account.
Only the role named 'Admin' should have full access to IAM. No other AWS role is supposed have IAM full access.
To remediate this issue:
- Remove the IAM privileges from that role.
AWS Lambda is cheap but is pay per use. An errant lambda function calling itself, cyclic lambda function calls between functions can result is huge bills. Any lambda functions that is going to exceed 1 million executions a day should be reviewed.
To remediate this issue:
- Review the code and design and inspect if there is any problem with the logic. If it known and expected behavior please request for an exception.
To prevent data theft and data loss all, MongoDB servers should be protected with access control mechanism.
To remediate this issue:
- Disable anonymous access to MongoDB
Access keys of IAM accounts should be rotated every 90 days in order to decrease the likelihood of accidental exposures and protect AWS resources against unauthorized access
To remediate this issue:
- Rotate the access keys every 90 days
All publicly accessible API behind API gateway should be protected with at least one custom authorizer.
AWS API gateway resources are by default publicly accessible, all of the API resources should be protected by a Authorizer or a API key. Unprotected API's can lead to data leaks and security breaches.
To remediate this issue:
- Protect the API gateway with an API key OR Use a custom authorizers at the gateway level
IAM users who have not logged into AWS and have no API activity for 90 days will be considered inactive IAM users and their accounts will be terminated.
To remediate this issue:
- Resolution may depend on specific IAM policies.
All AWS service limits should be extended from time to time based on the growing needs. CloudFormation execution, Autoscaling or A/B deployment for production workloads may fail if the service limit is reached causing downtime. Proactively service limits should be extended when limit thresholds reach 75% or above
To remediate this issue:
- Open a case with AWS and increase the service limits
All AWS assets should be tagged with following mandatory tags. Application, XXX, YYY and ZZZ. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
This policy can applied for all AWS resources types which can be taggable. example(EC2/S3/Lambda/RDS.....).
All AWS assets in T-Mobile using some standard region (us-est/west). As part of this rule if the resource finds non-standard region it should report as violation.
To remediate this issue:
Global permission to access the well known services like HTTP on port 80 should not be allowed.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
AWS Elasticsearch should not be publicly accessible from internet to protect data from unauthorized user access, data loss and possible leakage of sensitive data. As a general rule, if you need to make anything publicly accessible it has to go through security review and approval from DSO.
To remediate this issue:
- Make necessary changes to the access control policy and Security Groups to make the ES endpoint private.
- Allow only a specific list of IP addresses
- Once the Elasticsearch endpoint is not publicly accessible PacBot will automatically close the issue.
- You can also request exception from the policy violation details page.
- SecOps will review and involve DSO if required and grant exception and PacBot will automatically ignore this resource till the expiry of exception.
All publicly accessible ELB's will be marked as a policy violation. You would need to request an exception by providing a cloud application name. What component of the application is made public? Why it has to be public? What data will be exposed via the publicly accessible system?
The reason why all internet-facing are marked as violation is, the number of cases where we need to have internet-facing load balancers is small and these legitimate cases will be reviewed and granted exception. Developer often associate internet-facing load balancers for internal applications and end up exposing sensitive data.
To remediate this issue:
- Request for an exception legitimate internet-facing ELB.
A Redshift snapshot may contain sensitive or customer information. No RDS snapshot should be made public from our accounts. There are very rare cases where this might be required. Those cases have to go through an exception process.
To remediate this issue:
- Make the snapshot private
It is a best practice to allow only required ip ranges and specific port in the Security Groups. There are cases where security group should allow access to everyone, for those cases request for an exception.
To remediate this issue:
- Edit the security groups and allow only specific IP ranges and ports
To remediate this issue:
AWS Volume resource should not be untagged or unused to avoid the cost.
To remediate this issue:
Anyone other than administrators should not have these permissions. List of privileges it’s checking right now are
"ec2:AssociateDhcpOptions","ec2:AssociateRouteTable","ec2:AssociateSubnetCidrBlock","ec2:AssociateVpcCidrBlock","ec2:AttachInternetGateway","ec2:AttachVpnGateway","ec2:CreateCustomerGateway","ec2:CreateDefaultSubnet","ec2:CreateDefaultVpc","ec2:CreateEgressOnlyInternetGateway","ec2:CreateInternetGateway","ec2:CreateNatGateway","ec2:CreateNetworkAcl","ec2:CreateNetworkAclEntry","ec2:CreateRoute","ec2:CreateRouteTable","ec2:CreateSubnet","ec2:CreateVpc","ec2:CreateVpcPeeringConnection","ec2:CreateVpnConnection","ec2:CreateVpnConnectionRoute","ec2:CreateVpnGateway","ec2:DeleteCustomerGateway","ec2:DeleteDhcpOptions","ec2:DeleteNatGateway","ec2:DeleteNetworkAcl","ec2:DeleteNetworkAclEntry","ec2:DeleteRouteTable","ec2:DeleteSubnet","ec2:DeleteVpc","ec2:DeleteVpcEndpointServiceConfigurations","ec2:DeleteVpcPeeringConnection","ec2:DeleteVpnConnection","ec2:DeleteVpnConnectionRoute","ec2:DeleteVpnGateway","ec2:DetachInternetGateway","ec2:DetachVpnGateway","ec2:DisableVgwRoutePropagation","ec2:DisassociateRouteTable","ec2:DisassociateSubnetCidrBlock","ec2:DisassociateVpcCidrBlock","ec2:ModifyVpcAttribute","ec2:ModifyVpcTenancy","ec2:ReplaceNetworkAclAssociation","ec2:ReplaceNetworkAclEntry","ec2:ReplaceRoute","ec2:ReplaceRouteTableAssociation","iam:AddUserToGroup","iam:AttachGroupPolicy","iam:AttachRolePolicy","iam:AttachUserPolicy","iam:CreateAccessKey","iam:CreatePolicy","iam:CreatePolicyVersion","iam:CreateRole","iam:CreateSAMLProvider","iam:CreateUser","iam:DeleteAccessKey","iam:DeleteAccountPasswordPolicy","iam:DeleteGroup","iam:DeleteGroupPolicy","iam:DeletePolicy","iam:DeletePolicyVersion","iam:DeleteSAMLProvider""ec2:CreateDhcpOptions","iam:DeleteServerCertificate","iam:DetachGroupPolicy","iam:DetachUserPolicy","iam:PutGroupPolicy","iam:PutRolePolicy""iam:PutUserPolicy","iam:RemoveUserFromGroup","iam:UpdateGroup","iam:UpdateSAMLProvider","iam:UpdateServerCertificate"
To remediate this issue:
- Attach deny policy / remove elevated permissions
- If you want exception you may please request exception for this rule through PacBot.
None of the roles supposed to have these permissions List of privileges it’s checking right now are
"ec2:AssociateDhcpOptions","ec2:AssociateRouteTable","ec2:AssociateSubnetCidrBlock","ec2:AssociateVpcCidrBlock","ec2:AttachInternetGateway","ec2:AttachVpnGateway","ec2:CreateCustomerGateway","ec2:CreateDefaultSubnet","ec2:CreateDefaultVpc","ec2:CreateEgressOnlyInternetGateway","ec2:CreateInternetGateway","ec2:CreateNatGateway","ec2:CreateNetworkAcl","ec2:CreateNetworkAclEntry","ec2:CreateRoute","ec2:CreateRouteTable","ec2:CreateSubnet","ec2:CreateVpc","ec2:CreateVpcPeeringConnection","ec2:CreateVpnConnection","ec2:CreateVpnConnectionRoute","ec2:CreateVpnGateway","ec2:DeleteCustomerGateway","ec2:DeleteDhcpOptions","ec2:DeleteNatGateway","ec2:DeleteNetworkAcl","ec2:DeleteNetworkAclEntry","ec2:DeleteRouteTable","ec2:DeleteSubnet","ec2:DeleteVpc","ec2:DeleteVpcEndpointServiceConfigurations","ec2:DeleteVpcPeeringConnection","ec2:DeleteVpnConnection","ec2:DeleteVpnConnectionRoute","ec2:DeleteVpnGateway","ec2:DetachInternetGateway","ec2:DetachVpnGateway","ec2:DisableVgwRoutePropagation","ec2:DisassociateRouteTable","ec2:DisassociateSubnetCidrBlock","ec2:DisassociateVpcCidrBlock","ec2:ModifyVpcAttribute","ec2:ModifyVpcTenancy","ec2:ReplaceNetworkAclAssociation","ec2:ReplaceNetworkAclEntry","ec2:ReplaceRoute","ec2:ReplaceRouteTableAssociation","iam:AddUserToGroup","iam:AttachGroupPolicy","iam:AttachRolePolicy","iam:AttachUserPolicy","iam:CreateAccessKey","iam:CreatePolicy","iam:CreatePolicyVersion","iam:CreateRole","iam:CreateSAMLProvider","iam:CreateUser","iam:DeleteAccessKey","iam:DeleteAccountPasswordPolicy","iam:DeleteGroup","iam:DeleteGroupPolicy","iam:DeletePolicy","iam:DeletePolicyVersion","iam:DeleteSAMLProvider""ec2:CreateDhcpOptions","iam:DeleteServerCertificate","iam:DetachGroupPolicy","iam:DetachUserPolicy","iam:PutGroupPolicy","iam:PutRolePolicy""iam:PutUserPolicy","iam:RemoveUserFromGroup","iam:UpdateGroup","iam:UpdateSAMLProvider","iam:UpdateServerCertificate"
To remediate this issue:
- Attach deny policy / remove elevated permissions
- If you want exception you may please request exception for this rule through PacBot.
IAM roles do not have the permission to launch instances List of privileges it’s checking right now
ec2:*,*,ec2:RunInstances
To remediate this issue:
- Remove run instance permission from the role or if you want exception you may please request exception for this rule through PacBot.
IAM roles not supposed to have lambda function creation permissions. List of privileges it’s checking right now are
lambda:CreateFunction,lambda:Create*,*,lambda:*
To remediate this issue:
- Remove lambda create permission from role or if you want exception you may please request exception for this rule through PacBot.
Service account should only has the read permission List of privileges it’s checking right now
ec2:TerminateInstances,ec2:RunInstances,s3:DeleteBucket,s3:PutBucketPolicy,ec2:ModifyInstanceAttribute,s3:DeleteObject,ec2:*,*,s3:*,s3:Put*,cloudtrail:*,cloudtrail:DeleteTrail,config:*,config:DeleteConfigRule
To remediate this issue:
- Remove write permissions from service accounts.
This rule creates an issue, if the port 8080 is publicly accessible.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
Global permission to access the well known services like TCP on port 138 should not be allowed.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
Global permission to access the well known services like TCP on port 3306 (MySQL) should not be allowed.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
This rule checks if the CloudFront has unauthorized HTML content, if so then it creates a violation.
This policy can be applied for all AWS resources types which has regions. example (EC2/S3/Lambda/RDS etc.)
This rule checks for S3 bucket containing website configuration.If its true then its an issue.
This policy checks for unauthorized CloudFront distribution.
Global permission to access the well known services like TCP on port 1434 (SQL Browser) should not be allowed.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
EC2 instances should not be publicly accessible on default This is an Azure security rule. port 5432.
Global permission to access the well known services like TCP on port 5432 (This is an Azure security rule.) should not be allowed.
To remediate this issue:
- Do not allow global access to well known ports of an EC2 instance directly (except for 80 and 443).
RDP port 3389 should not be accessible from internet. Port 3389 should be open only to the internal 10...* network. Further reducing the permitted IP addresses or ranges allowed to communicate to destination hosts on RDP port 3389 is recommended. An exposed RDP port 3389 pose a great security risk.
To remediate this issue:
- Remove the rule from the security groups that allows inbound access from 0.0.0.0/0.
MFA should be enabled for Root User, if not its an issue.
To remediate this issue:
- Enable the MFA for root user
CloudTrail should be enabled in multiple regions, if not its an issue.
To remediate this issue:
- Enable the CloudTrail in multiple regions.
ACM certificate should not expire in mentioned days from current date.
To remediate this issue:
- Rotate the keys before the expiry
IAM certificate should not expire in mentioned days from current date.
To remediate this issue:
- Rotate the keys before the expiry
Access log should be enabled to App ELB/Classic ELB and attached to mentioned bucket.
To remediate this issue:
- Access log should be enabled to ELB and attached to mentioned bucket.
Access log should be enabled to CloudFront and attached to mentioned bucket.
To remediate this issue:
- Access log should be enabled to CloudFront and attached to mentioned bucket.
Protected S3 buckets should be server access logs enabled.
To remediate this issue:
- Protected S3 buckets should be server access logs enabled.
Events from all AWS account should be routed to a central event bus so that the events and be processed and analyzed centrally.
To remediate this issue:
- Events from all AWS account should be routed to a central event.
Checks the Amazon Elastic Compute Cloud (Amazon EC2) instances that were running at any time during the last 14 days and alerts you if the daily CPU utilization was 10% or less and network I/O was 5 MB or less on 4 or more days. Running instances generate hourly usage charges. Although some scenarios can result in low utilization by design, you can often lower your costs by managing the number and size of your instances. An instance had 10% or less daily average CPU utilization and 5 MB or less network I/O on at least 4 of the previous 14 days.
To remediate this issue:
- Consider stopping or terminating instances that have low utilization, or scale the number of instances by using Auto Scaling.
If an EC2 Instance having an S5, S4 and S3 vulnerability report it as an issue with severity high, medium and low respectively.
An EC2 instance with remotely exploitable vulnerability (S5) should not be publicly accessible, this instance can be easily compromised from a remote location.
To remediate this issue:
- Immediately remove the internet access
- Apply the vulnerability fix.
All assets in Cloud should be scanned by Qualys vulnerability assessment tool at least once a month. It would be ideal to have the Qualys Cloud Agent installed on all the assets. This would eliminate the need to have manual external scans.
To remediate this issue:
- Install Qualys Cloud Agent on the server or get the asset scanned manually by VMAS team every month.
All assets in Cloud should be scanned by the Qualys vulnerability assessment tool at least once a month. It would be ideal to have the Qualys Cloud Agent installed on all the assets. This would eliminate the need to have manual external scansSecurity Center uses the Microsoft Monitoring Agent (MMA) to collect security events from your Azure virtual machines. To make sure your virtual machines are successfully monitored, you need to enable data collection in Security Center and make sure the MMA agent is both installed on the virtual machines and properly collects security events to the configured workspace. Enabling data collection in Security Center enables you to benefit from multiple agent-based features, including OS baselines rules assessments, monitoring for missing system updates, endpoint protection issues and advanced threat detection capabilities.
To remediate this issue:
- Installation of the monitoring agent and enabling data collection in Security Center can be done in several ways: Using Security Center’s automatic provisioning on your subscription(s). This will automatically provision the monitoring agent on current and future-created virtual machines on your subscription(s). You can enable automatic provisioning on multiple subscriptions by clicking on the Getting started menu item, and select 'Install agents'. You can also enable it for specific subscriptions and customize additional settings by clicking on the 'Security policy' menu item, select 'Edit settings' on a subscription and enable auto provisioning in the 'data collection' menu item. Install the Microsoft Monitoring agent on your Virtual machines as a VM extension or directly, by following these instructions. Provision the Microsoft Monitoring agent with Azure Policies.
Just-in-time (JIT) virtual machine (VM) access can be used to lock down inbound traffic to your Azure VMs, reducing exposure to attacks while providing easy access to connect to VMs when needed.
To remediate this issue:
- Open the Security Center dashboard.
- In the left pane, select Just-in-time VM access.
- The Just-in-time VM access window opens.
- Select the Recommended tab.
- Under VIRTUAL MACHINE, click the VMs that you want to enable. This puts a checkmark next to a VM.
This is an Azure security rule.
To remediate this issue: 1)
Application control helps you deal with malicious and/or unauthorized software, by allowing only specific applications to run on your VMs and Computers.
To remediate this issue:
- Open the Security Center dashboard.
- In the left pane select Adaptive application controls located under Advanced Cloud Defense and follow the guidelines.
This is an Azure security rule.
To remediate this issue: 1)
This is an Azure security rule.
To remediate this issue: 1)
This is an Azure security rule.
The vulnerability assessment in Azure Security Center is part of the Security Center virtual machine (VM) recommendations. If Security Center doesn't find a vulnerability assessment solution installed on your VM, it recommends that you install one. A partner agent, after being deployed, starts reporting vulnerability data to the partner’s management platform. In turn, the partners management platform provides vulnerability and health monitoring data back to Security Center. You can quickly identify vulnerable VMs on the Security Center dashboard. Switch to the partner management console directly from Security Center for additional reports and information.
This is an Azure security rule.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (Refer to naming conventions).
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
All cloud assets should be tagged with following mandatory tags. Application, Environment, Role and Stack. Assets without these mandatory tags will be marked as non-complaint. Below is an example for the tag value pairs.
Tag name: Application Example value: Rebellion
Notes This value for the application tag should be the approved application name give for the project during the cloud on-boarding process. Unknown applications will be marked for review and possible termination.
Tag name: Environment Example value: Production or Non Production or Non Production::qat1 or Non Production::dit1 (refer to your naming conventions)
Notes The value for environment should distinguish the asset as a Production or Non Production class. You can further qualify Non Production assets using the :: separator. Look at the examples 3 and 4.
Tag name: Stack Example Value: Apache Httpd
Tag name: Role Example value: Webserver
Each asset should at least have these 4 mandatory tags. You can have additional tags as well.
To remediate this issue:
- Add the mandatory tags to the assets
- Follow the Cloud Asset Tagging guidelines.
We are working to make all of the policies available in the open source version.
This is not the exhaustive list.