-
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 open to internet.
-
AWS Guard Duty 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 Mongo DB instances should be protected with access control mechanism.
-
AWS service limits should be upgraded to match growing needs.
-
Elastic search 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 open to the internet.
-
Non-White listed SQS resources should not be publicly accessible.
-
Non White listed IAM users should not have core networking privileges.
-
Non white listed IAM Roles should not have core networking privileges.
-
Non White listed 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 mentioned days from 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
- An EC2 instance should not have an S3, S4 or S5 vulnerability.
- EC2 Public Access Port With S5 Vulnerability
- Every EC2 instance should be scanned by the Qualys vulnerability assessment tool at least once a month.
- Install monitoring agent on your machines
- Apply a Just-In-Time network access control
- Remediate vulnerabilities by a Vulnerability Assessment solution
- Enable Adaptive Application Controls
- Resolve monitoring agent health issues on your machines
- Close management ports on your Virtual Machines
- Enable Network Security Groups on Virtual Machines
- Install a vulnerability assessment solution on your virtual machines
- Harden Network Security Group rules of internet facing Virtual Machines
- Blob Container should be tagged with mandatory tags
- Disk should be tagged with mandatory tags
- Storage Account should be tagged with mandatory tags
- Resource Group should be tagged with mandatory tags
- Security Center should be tagged with mandatory tags
- Network Interface should be tagged with mandatory tags
- NSG should be tagged with mandatory tags
- VNet should be tagged with mandatory tags
- Virtual Machine should be tagged with mandatory tags
- SQL Database should be tagged with mandatory tags
- Databricks should be tagged with mandatory tags
- Sql Server should be tagged with mandatory tags
- Load Balancer should be tagged with mandatory tags
- MySQL Server should be tagged with mandatory tags
- Access through Internet facing endpoint should be restricted
- Adaptive Application Controls should be enabled on virtual machines
- Advanced Data Security SQL Server should have auditing enabled
- Audit unrestricted network access to storage accounts
- Audit Storage VNet Integration
- Secure transfer to storage accounts should be enabled
- Metric alert rules should be configured on Batch accounts
- Diagnostic logs in Batch accounts should be enabled
- Diagnostic logs in Service Bus should be enabled
- SQL Auditing settings should have Action Groups configured to capture critical activities
- An Active Directory administrator should be provisioned for SQL Servers
- Configure Email In Data Security Settings
- Container Security Configuration
- VMs wo enabled disk encryption will be monitored by Security Center as recommendations
- Just In Time network access control should be applied on Virtual Machines
- Transparent Data Encryption on SQL databases should be enabled
- IP Forwarding on Virtual Machines should be disabled
- Monitor missing Endpoint Protection in Security Center
- Diagnostic logs in namespaces should be enabled
- SQL Auditing for configured number of retention days
- SQL TDE protector encryption check
- Vulnerability assessment should be enabled on SQL servers
- Sensitive data in SQL databases should be classified
- Subnets should be associated with a Network Security Group
- System updates should be installed on Virtual Machines
- Diagnostic logs in Key Vault should be enabled
- Diagnostic logs in Logic Apps should be enabled
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.
A 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 exemption 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 exemption process.
To remediate this issue:
- Make the snapshot private.
A 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 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 downsizeg 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 bruteforce login attempts and subsequent data leak /loss. Unauthorised 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 guard duty 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 upto 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, elastic IP 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 privilleges 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 Mongo DBs 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:
- Reach out to xxxxxx@t-mobile.com for exceptions
All AWS service limits should be extended from time to time based on the growing needs. Cloudformation execution, Auotscalling or A,B deplymnet 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 Elastic Search 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 if you need to put anything internet facing 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 Elastic Search endpoint is not publicly accessible PacBot will auotmatically 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 internet facing ELB's will be marked as a policy violation. You would need to request for an exception by providing Cloud Application Name What component of the application is made public? Why it has to be public? What data will be exposed via the internet facing 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 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 outside CCOE admins not 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.
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 donot 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 open to internet.
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.
To remediate this issue: 1)
This policy can be applied for all AWS resources types which has regions. example(EC2/S3/Lambda/RDS.....).
This rule checks for s3 bucket containing web-site configuration.If its true then its an issue.
To remediate this issue: 1)
This policy checks for unauthorized CloudFront distribution.
To remediate this issue: 1)
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)
Global permission to access the well known services like TCP on port 5432 (POSTGRESQL) 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 multi region, if not its an issue
To remediate this issue:
- Enable the cloudtrail in multi region
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 S5, S4 and S3 vulnerability report it as an issue with severity high, medium and low respectively
To remediate this issue:
An EC2 instance with remotely exploitable vulnerability (S5) should not be open to internet, 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 atleast once a month. It would be ideal to have the Qulays 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 Qualys vulnerability assessment tool atleast once a month. It would be ideal to have the Qulays 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 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 Azure Secuirty Rule
To remediate this issue: 1)
This is Azure Secuirty Rule
To remediate this issue: 1)
This is Azure Secuirty Rule
To remediate this issue: 1)
The vulnerability assessment in Azure Security Center is part of the Security Center virtual machine (VM) recommendations. If Security Center doesnt 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.
To remediate this issue: 1)
This is Azure Secuirty Rule
To remediate this issue: 1)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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 Naming guide)
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.
Inbound rules should not allow access from Any or Internet ranges
To remediate this issue:
- Access through Internet-facing endpoint should be restricted.
Adaptive Application Controls should be enabled on virtual machines
To remediate this issue: 1)
Auditing should be enabled on advanced data security settings on SQL Server
To remediate this issue:
- Auditing should be enabled on advanced data security settings on SQL Server
Audit unrestricted network access in your storage account firewall settings. Instead, configure network rules so only applications from allowed networks can access the storage account. To allow connections from specific internet or on-premise clients, access can be granted to traffic from specific Azure virtual networks or to public internet IP address ranges
To remediate this issue: 1)
Audit Storage Vnet Integration
To remediate this issue: 1)
Audit requirement of Secure transfer in your storage account. Secure transfer is an option that forces your storage account to accept requests only from secure connections (HTTPS). Use of HTTPS ensures authentication between the server and the service and protects data in transit from network layer attacks such as man-in-the-middle, eavesdropping, and session-hijacking
To remediate this issue: 1)
Audit configuration of metric alert rules on Batch account to enable the required metric
To remediate this issue: 1)
Audit enabling of diagnostic logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised
To remediate this issue: 1)
Audit enabling of diagnostic logs. This enables you to recreate activity trails to use for investigation purposes; when a security incident occurs or when your network is compromised
To remediate this issue: 1)
The AuditActionsAndGroups property should contain at least SUCCESSFUL_DATABASE_AUTHENTICATION_GROUP, FAILED_DATABASE_AUTHENTICATION_GROUP, BATCH_COMPLETED_GROUP to ensure a thorough audit logging
To remediate this issue: 1)
Audit provisioning of an Azure Active Directory administrator for SQL Server to enable Azure AD authentication. Azure AD authentication enables simplified permission management and centralized identity management of database users and other Microsoft services
To remediate this issue: 1)
Ensure that an email address is provided for the 'Send alerts to' field in the Advanced Data Security server settings. This email address receives alert notifications when anomalous activities are detected on SQL servers.
To remediate this issue: 1)
Vulnerabilities in container security configurations should be remediated
To remediate this issue: 1)
Disk encryption should be applied on virtual machines
To remediate this issue: 1)
Possible network Just In Time (JIT) access will be monitored by Azure Security Center as recommendations
To remediate this issue: 1)
Transparent Data Encryption on SQL databases should be enabled
To remediate this issue:
- Audit transparent data encryption status for SQL databases
Enabling IP forwarding on a virtual machine should be reviewed by the network security team
To remediate this issue:
- Enabling IP forwarding on a virtual machine should be reviewed by the network security team
Enabling IP forwarding on a virtual machine should be reviewed by the network security teamServers without an installed Endpoint Protection agent will be monitored by Azure Security Center as recommendations
To remediate this issue:
- Servers should be installed with Endpoint Protection agent
Diagnostic logs in Namespaces should be enabled
To remediate this issue:
- This enables you to recreate activity trails to use for investigation purposes,when a security incident occurs or when your network is compromised
SQL servers should be configured with auditing retention days greater than 90 days
To remediate this issue:
- Audit SQL servers configured with an auditing retention period of less than 90 days
SQL server TDE protector should be encrypted with your own key
To remediate this issue:
- Transparent Data Encryption (TDE) with your own key support provides increased transparency and control over the TDE Protector, increased security with an HSM-backed external service, and promotion of separation of duties
Vulnerability assessment should be enabled on your SQL servers
To remediate this issue:
- Audit Azure SQL servers which do not have recurring vulnerability assessment scans enabled. Vulnerability assessment can discover, track, and help you remediate potential database vulnerabilities
Sensitive data in your SQL databases should be classified
To remediate this issue:
- Sensitive data in your SQL databases should be classified
Subnets should be associated with a Network Security Group
To remediate this issue:
- Protect your subnet from potential threats by restricting access to it with a Network Security Group (NSG)
Missing security system updates on your servers will be monitored by Azure Security Center as recommendations
To remediate this issue:
- System updates should be up to date
Diagnostic logs in Key Vault should be enabled
To remediate this issue:
- Diagnostic logs in Key Vault should be enabled
Diagnostic logs in Logic Apps should be enabled
To remediate this issue:
- This enables you to recreate activity trails to use for investigation purposes,when a security incident occurs or when your network is compromised
We are working to make all of the policies available in the open source version.
This is not the exhaustive list.