Cloud Security

September 1, 2018 By PC Portal

AWS Cloud: Proactive Security and Forensic Readiness – part 4

Part 4: Detective Controls in AWS

Security controls can be either technical or administrative. A layered security approach to protecting an organisation’s information assets and infrastructure should include preventative controls, detective controls and corrective controls.

Preventative controls exist to prevent the threat from coming in contact with the weakness. Detective controls exist to identify that the threat has landed in our systems. Corrective controls exist to mitigate or lessen the effects of the threat being manifested.

This post relates to detective controls within AWS Cloud. It’s the fourth in a five-part series that provides a checklist for proactive security and forensic readiness in the AWS Cloud environment.

Detective controls in AWS Cloud

AWS detective controls include processing of logs and monitoring of events that allow for auditing, automated analysis, and alarming.

These controls can be implemented using AWS CloudTrail logs to record AWS API calls, Service-specific logs (for Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc) and AWS Config to maintain a detailed inventory of AWS resources and configuration. Amazon CloudWatch is a monitoring service for AWS resources and can be used to trigger CloudWatch events to automate security responses. Another useful tool is Amazon GuardDuty which is a managed threat detection service in AWS and continuously monitors for malicious or unauthorised.

Event Logging

Security event logging is crucial for detecting security threats or incidents. Security teams should produce, keep and regularly review event logs that record user activities, exceptions, faults and information security events. They should collect logs centrally and automatically analysed to detect suspicious behaviour. Automated alerts can monitor key metrics and events related to security. It is critical to analyse logs in a timely manner to identify and respond to potential security incidents. In addition, logs are indispensable for forensic investigations.

The challenge of managing logs

However, managing logs can be a challenge. AWS makes log management easier to implement by providing the ability to deﬁne a data-retention lifecycle or deﬁne where data will be preserved, archived, or eventually deleted. This makes predictable and reliable data handling simpler and more cost-eﬀective.

The following list recommends use of AWS Trusted Advisor for detecting security threats within the AWS environment. It covers collection, aggregation, analysis, monitoring and retention of logs, and, monitoring security events and billing to detect unusual activity.

The checklist provides best practice for the following:

Best-practice checklist

1. Are you using Trusted Advisor?	Use AWS Trusted Advisor to check for security compliance.
2. How are you capturing and storing logs?	Activate AWS Cloud Trail. Collect logs from various locations/services including AWS APIs and user-related logs (e.g. AWS CloudTrail), AWS service-specific logs (e.g. Amazon S3, Amazon CloudFront, CloudWatch logs, VPC flow logs, ELB logs, etc.), operating system-generated logs, IDS/IPS logs and third-party application-specific logs Use services and features such as AWS CloudFormation, AWS OpsWorks, or Amazon Elastic Compute Cloud (EC2) user data, to ensure that instances have agents installed for log collection Move logs periodically from the source either directly into a log processing system (e.g., CloudWatch Logs) or stored in an Amazon S3 bucket for later processing based on business needs.
3. How are you analysing logs?	Parse and analyse security data using solutions such as AWS Config, AWS CloudWatch, Amazon EMR, Amazon Elasticsearch Service, etc. Perform analysis and visualisation with Kibana.
4. How are you retaining logs?	Store data centrally using Amazon S3, and, for long-term archiving if required, using Amazon Glacier Define data-retention lifecycle for logs. By default, CloudWatch logs are kept indefinitely and never expire. You can adjust the retention policy for each log group, keeping the indefinite retention, or choosing a retention period between 10 years and one day Manage log retention automatically using AWS Lambda.
5. How are you receiving notification and alerts?	Use Amazon CloudWatch Events for routing events of interest and information reflecting potentially unwanted changes into a proper workflow Use Amazon GuardDuty to continuously monitor for malicious or unauthorised behaviour Send events to targets like an AWS Lambda function, Amazon SNS, or other targets for alerts and notifications.
6. How are you monitoring billing in your AWS account(s)?	Use detailed billing to monitor your monthly usage regularly Use consolidated billing for multiple accounts.

Refer to the following AWS resources for more details:

AWS Well-Architected Framework

What is Amazon CloudWatch Logs?

Definition of Preventative controls, Detective controls and Corrective controls – Fundamentals of Information Systems Security (David Kim, Michael G. Solomon)

Next up in the blog series, is Part 5 – Incident Response in AWS – best practice checklist. Stay tuned.

Let us know in the comments below if we have missed anything in our checklist!

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written ;). Please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

Author: Neha Thethi

Editor: Gordon Smith

The post AWS Cloud: Proactive Security and Forensic Readiness – part 4 appeared first on BH Consulting.

May 10, 2018 By PC Portal

Security newsround: May 2018

We round up reporting and research from across the web about the latest security news and developments. This month: police success against cyber villains, the value of personal data, IoT security, a new ransomware strain, a new security framework and Gmail goes for 2FA.

Law’s long arm collars cyber crooks

Police forces scored three big wins against various cybercrime operations recently. In late April, authorities took down WebStresser.org, one of the world’s most popular marketplaces for launching DDoS attacks. Reuters reported that WebStresser was behind attacks on seven of Britain’s largest banks last November. The service is also alleged to have been responsible for four million attacks since 2015 against governments, police services, and businesses.

The Dutch Politie and the UK’s National Crime Agency led ‘Operation Power Off’, supported by Europol and a dozen other law enforcement agencies. They arrested alleged WebStresser administrators in four countries, seized infrastructure, and took unspecified “further measures” against some of its top users.

Before police pulled the plug, WebStresser had amassed 136,000 registered users. Threatpost aptly described WebStresser as a “criminal fantasy dream site”. It reported that there are 6.5 million DDoS attacks per year on average, earning attackers $13 million in revenue.

In separate operations, a coalition of eight countries led by Belgium took down propaganda broadcasting infrastructure of the Islamic State. Authorities targeted web assets of Amaq News Agency, an online media outlet which authorities called “the main mouthpiece of IS”. The same action also took down other IS-branded media outlets.

Completing the hat-trick, cybercrime teams from Dutch police seized the Anon-IB forum in an investigation relating to criminal offences. Vice Motherboard described Anon-IB as “possibly the most infamous site focused on revenge porn – explicit or intimate images of people shared without their consent”.

We’re always pleased to see law enforcement prevail in the fight against cybercrime. BH Consulting has been a partner of Europol for years. In 2013, our CEO Brian Honan was appointed as a special advisor on internet security to Europol’s CyberCrime Centre (EC3).

What’s your data worth?

If data is the new oil, there’s no shortage of ways that criminals can refine it for profit. As this post from Dark Reading makes clear, stolen data has many purposes that security teams need to know about. Crimes range from stolen IP to filing fraudulent tax rebates to schemes for stealing money, Steve Zurier wrote. Once hackers hold an inventory of stolen data , they package up and sell personal information such as names, addresses, phone numbers, and email addresses. They usually sell this data in bulk to maximise their profits. The more recent the records, the more value they fetch on the black market, Zurier said.

The question of what our data is worth in the digital economy is especially resonant and relevant in light of the recent Facebook/Cambridge Analytica scandal. Not to mention a certain four-letter privacy regulation. In Medium, Rik Ferguson of Trend Micro wrote a thoughtful post that considers the value of our personal information in the online economy. Data, he wrote, “unlike oil … is not burned up when used, but can be sold and resold, mined and reused”.

There’s plenty to chew on for privacy and security professionals. Rik wrote: “Our data is cataloged and combined with the traces we leave behind in the physical world, correlated and mined to reach conclusions far beyond those we might perhaps be comfortable with publicising, and then sold as a commodity or a subscription-based service to any interested party. It is an industry based our ignorance and our nonchalance.”

Securing all the things

ENISA has developed a free interactive tool based on its baseline security recommendations for the Internet of Things. This lets anyone working on IoT projects search and identify good practices. The tool is available to download here, and this page also includes a help guide. It’s based on the agency’s original study on IoT security which it published last year. The new tool is timely, as criminals have apparently begun exploiting IoT as another way to profit from cryptocurrency mining. Trend Micro researchers identified malware that hijacks the processing power of IoT devices and smartphones to mine for cryptocurrency. As Lesley Carhart of Dragos jokingly tweeted: “Your router and your IOT thermostat should really beep like your smoke detector when it’s missing a critical security patch.”

Prepare for a summer of SamSam?

Researchers are warning of criminals taking a new approach to ransomware infections. Sophos analysed the SamSam variant and found criminals carefully choose target organisations. They then launch thousands of copies of SamSam onto that organisation’s computers all at once. Once the infection has hit, the criminals offer victims a volume discount to clean all machines. This differs from the usual spam-like scattergun approach to ransomware of sending one malware copy to multiple possible targets. “The cybercriminals behind SamSam use vulnerabilities to gain access to the victims’ network or use brute-force tactics against the weak passwords of the Remote Desktop Protocol (RDP)”, the researchers wrote. Here’s ThreatPost’s writeup of the research. Sophos’ own blog describes the findings, and here’s a link to the technical paper.

Guidelines in the NIST

The US National Institute of Standards and Technology (NIST) has released version 1.1 of its Framework for Improving Critical Infrastructure Cybersecurity. This updates the original version 1.0 which proved popular on its release in February 2014. Version 1.1’s updated guidelines cover authentication and identity, cybersecurity risk self assessment, supply chain security management, and vulnerability disclosure. NIST programme manager Matt Barrett said the framework is flexible enough to meet an individual organisation’s business or mission needs. It applies to a wide range of technology environments such as information technology, industrial control systems and the Internet of Things. Later this year, NIST will release an updated companion document, the Roadmap for Improving Critical Infrastructure Cybersecurity. NIST’s press release is here and the framework is available free in PDF at this link.

Google beefs up Gmail security

Two-factor authentication got a shot in the arm after Google added this security feature for its Gmail app last month. Also called two-step verification, this sends a prompt to a user’s phone when they access their Gmail account on another computer. Naked Security said this is more secure than sending an SMS code to the phone, which can be vulnerable to fraud. It also pointed out that ease of use will encourage more people to use it, as takeup of 2FA to date has been low. Why does this matter? Here’s how many Gmail users there are in the world: 1.2 billion, to be exact. Google has more details on its blog. If you or your users still prefer passwords, here’s our advice from last year on how to choose better ones.

The post Security newsround: May 2018 appeared first on BH Consulting.

March 15, 2018 By PC Portal

AWS Cloud: Proactive Security and Forensic Readiness – part 3

Part 3: Data protection in AWS

This is the third in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to protecting data within AWS.

Data protection has become all the rage for organisations that are processing personal data of individuals in the EU, because the EU General Data Protection Regulation (GDPR) deadline is fast approaching.

AWS is no exception. The company is providing customers with services and resources to help them comply with GDPR requirements that may apply to their operations. These include granular data access controls, monitoring and logging tools, encryption, key management, audit capability and, adherence to IT security standards (for more information, see the AWS General Data Protection Regulation (GDPR) Center, and Navigating GDPR Compliance on AWS Whitepaper). In addition, AWS has published several privacy related whitepapers, including country specific ones. The whitepaper Using AWS in the Context of Common Privacy & Data Protection Considerations, focuses on typical questions asked by AWS customers when considering privacy and data protection requirements relevant to their use of AWS services to store or process content containing personal data.

This blog, however, is not just about protecting personal data. The following list provides guidance on protecting any information stored in AWS that is valuable to your organisation. The checklist mainly focuses on protection of data (at rest and in transit), protection of encryption keys, removal of sensitive data from AMIs, and, understanding access data requests in AWS.

The checklist provides best practice for the following:

IMPORTANT NOTE: Identity and access management is an integral part of protecting data, however, you’ll notice that the following checklist does not focus on AWS IAM. I have created a separate checklist on IAM best practices here.

Best-practice checklist

1. How are you protecting data at rest?	Define polices for data classification, access control, retention and deletion Tag information assets stored in AWS based on adopted classification scheme Determine where your data will be located by selecting a suitable AWS region Use geo restriction (or geoblocking), to prevent users in specific geographic locations from accessing content that you are distributing through a CloudFront web distribution Control the format, structure and security of your data by masking, making it anonymised or encrypted in accordance with the classification Encrypt data at rest using server-side or client-side encryption Manage other access controls, such as identity, access management, permissions and security credentials Restrict access to data using IAM policies, resource policies and capability policies
2. How are you protecting data at rest on Amazon S3?	Use bucket-level or object-level permissions alongside IAM policies Don’t create any publicly accessible S3 buckets. Instead, create pre-signed URLs to grant time-limited permission to download the objects Protect sensitive data by encrypting data at rest in S3. Amazon S3 supports server-side encryption and client-side encryption of user data, using which you create and manage your own encryption keys Encrypt inbound and outbound S3 data traffic Amazon S3 supports data replication and versioning instead of automatic backups. Implement S3 Versioning and S3 Lifecycle Policies Automate the lifecycle of your S3 objects with rule-based actions Enable MFA Delete on S3 bucket Be familiar with the durability and availability options for different S3 storage types – S3, S3-IA and S3-RR.
3. How are you protecting data at rest on Amazon EBS?	AWS creates two copies of your EBS volume for redundancy. However, since both copies are in the same Availability Zone, replicate data at the application level, and/or create backups using EBS snapshots On Windows Server 2008 and later, use BitLocker encryption to protect sensitive data stored on system or data partitions (this needs to be configured with a password as Amazon EC2 does not support Trusted Platform Module (TPM) to store keys) On Windows Server, implement Encrypted File System (EFS) to further protect sensitive data stored on system or data partitions On Linux instances running kernel versions 2.6 and later, you can use dmcrypt and Linux Unified Key Setup (LUKS), for key management Use third-party encryption tools
4. How are you protecting data at rest on Amazon RDS? (Note: Amazon RDS leverages the same secure infrastructure as Amazon EC2. You can use the Amazon RDS service without additional protection, but it is suggested to encrypt data at application layer)	Use built-in encryption function that encrypts all sensitive database fields, using an application key, before storing them in the database Use platform level encryption Use MySQL cryptographic functions – encryption, hashing, and compression Use Microsoft Transact-SQL cryptographic functions – encryption, signing, and hashing Use Oracle Transparent Data Encryption on Amazon RDS for Oracle Enterprise Edition under the Bring Your Own License (BYOL) model
5. How are you protecting data at rest on Amazon Glacier? (Note: Data stored on Amazon Glacier is protected using server-side encryption. AWS generates separate unique encryption keys for each Amazon Glacier archive, and encrypts it using AES-256)	Encrypt data prior to uploading it to Amazon Glacier for added protection
6. How are you protecting data at rest on Amazon DynamoDB? (Note: DynamoDB is a shared service from AWS and can be used without added protection, but you can implement a data encryption layer over the standard DynamoDB service)	Use raw binary fields or Base64-encoded string fields, when storing encrypted fields in DynamoDB
7. How are you protecting data at rest on Amazon EMR?	Store data permanently on Amazon S3 only, and do not copy to HDFS at all. Apply server-side or client-side encryption to data in Amazon S3 Protect the integrity of individual fields or entire file (for example, by using HMAC-SHA1) at the application level while you store data in Amazon S3 or DynamoDB Or, employ a combination of Amazon S3 server-side encryption and client-side encryption, as well as application-level encryption
8. How are you protecting data in transit?	Encrypt data in transit using IPSec ESP and/or SSL/TLS Encrypt all non-console administrative access using strong cryptographic mechanisms using SSH, user and site-to-site IPSec VPNs, or SSL/TLS to further secure remote system management Authenticate data integrity using IPSec ESP/AH, and/or SSL/TLS Authenticate remote end using IPSec with IKE with pre-shared keys or X.509 certificates Authenticate remote end using SSL/TLS with server certificate authentication based on the server common name(CN), or Alternative Name (AN/SAN) Offload HTTPS processing on Elastic Load Balancing to minimise impact on web servers Protect the backend connection to instances using an application protocol such as HTTPS On Windows servers use X.509 certificates for authentication On Linux servers, use SSH version 2 and use non-privileged user accounts for authentication Use HTTP over SSL/TLS (HTTPS) for connecting to RDS, DynamoDB over the internet Use SSH for access to Amazon EMR master node Use SSH for clients or applications to access Amazon EMR clusters across the internet using scripts Use SSL/TLS for Thrift, REST, or Avro
9. How are you managing and protecting your encryption keys?	Define key rotation policy Do not hard code keys in scripts and applications Securely manage keys at server side (SSE-S3, SSE-KMS) or at client side (SSE-C) Use tamper-proof storage, such as Hardware Security Modules (AWS CloudHSM) Use a key management solution from the AWS Marketplace or from an APN Partner. (e.g., SafeNet, TrendMicro, etc.)
10. How are you ensuring custom Amazon Machine Images (AMIs) are secure and free of sensitive data before publishing for internal (private) or external (public) use?	Securely delete all sensitive data including AWS credentials, third-party credentials and certificates or keys from disk and configuration files Delete log files containing sensitive information Delete all shell history on Linux
11. Do you understand who has the right to access your data stored in AWS?	Understand the applicable laws to your business and operations, consider whether laws in other jurisdictions may apply Understand that relevant government bodies may have rights to issue requests for content, each relevant law will contain criteria that must be satisfied for the relevant law enforcement body to make a valid request. Understand that AWS notifies customers where practicable before disclosing their data so they can seek protection from disclosure, unless AWS is legally prohibited from doing so or there is clear indication of illegal conduct regarding the use of AWS services. For additional information, visit Amazon Information Requests Portal.

For more details, refer to the following AWS resources:

Next up in the blog series, is Part 4 – Detective Controls in AWS – best practice checklist. Stay tuned.

Let us know in the comments below if we have missed anything in our checklist.

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written . Also, please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

Author: Neha Thethi

Editor: Gordon Smith

The post AWS Cloud: Proactive Security and Forensic Readiness – part 3 appeared first on BH Consulting.

February 27, 2018 By PC Portal

AWS Cloud: Proactive Security and Forensic Readiness – part 2

Part 2: Infrastructure-level protection in AWS

This is the second in a five-part blog series that provides a checklist for proactive security and forensic readiness in the AWS cloud environment. This post relates to protecting your virtual infrastructure within AWS.

Protecting any computing infrastructure requires a layered or defence-in-depth approach. The layers are typically divided into physical, network (perimeter and internal), system (or host), application, and data. In an Infrastructure as a Service (IaaS) environment, AWS is responsible for security ‘of’ the cloud including the physical perimeter, hardware, compute, storage and networking, while customers are responsible for security ‘in’ the cloud, or on layers above the hypervisor. This includes the operating system, perimeter and internal network, application and data.

Figure 1: AWS Defense in Depth

Infrastructure protection requires defining trust boundaries (e.g., network boundaries and packet filtering), system security configuration and maintenance (e.g., hardening and patching), operating system authentication and authorisations (e.g., users, keys, and access levels), and other appropriate policy enforcement points (e.g., web application firewalls and/or API gateways).

The key AWS service that supports service-level protection is AWS Identity and Access Management (IAM) while Virtual Private Cloud (VPC) is the fundamental service that contributes to securing infrastructure hosted on AWS. VPC is the virtual equivalent of a traditional network operating in a data centre, albeit with the scalability benefits of the AWS infrastructure. In addition, there are several other services or features provided by AWS that can be leveraged for infrastructure protection.

The following list mainly focuses on network and host-level boundary protection, protecting integrity of the operating system on EC2 instances and Amazon Machine Images (AMIs) and security of containers on AWS.

The checklist provides best practice for the following:

IMPORTANT NOTE: Identity and access management is an integral part of securing an infrastructure, however, you’ll notice that the following checklist does not focus on the AWS IAM service. I have covered this in a separate checklist on IAM best practices here.

Best-practice checklist

1. How are you enforcing network and host-level boundary protection?	Establish appropriate network design for your workload to ensure only desired network paths and routing are allowed For large-scale deployments, design network security in layers – external, DMZ, and internal When designing NACL rules, consider that it’s a stateless firewall, so ensure to define both outbound and inbound rules Create secure VPCs using network segmentation and security zoning Carefully plan routing and server placement in public and private subnets. Place instances (EC2 and RDS) within VPC subnets and restrict access using security groups and NACLs Use non-overlapping IP addresses with other VPCs or data centre in use Control network traffic by using security groups (stateful firewall, outside OS layer), NACLs (stateless firewall, at subnet level), bastion host, host based firewalls, etc. Use Virtual Gateway (VGW) where Amazon VPC-based resources require remote network connectivity Use IPSec or AWS Direct Connect for trusted connections to other sites Use VPC Flow Logs for information about the IP traffic going to and from network interfaces in your VPC Protect data in transit to ensure the confidentiality and integrity of data, as well as the identities of the communicating parties.
2. How are you protecting against distributed denial of service (DDoS) attacks at network and application level?	Use firewalls including Security groups, network access control lists, and host based firewalls Use rate limiting to protect scarce resources from overconsumption Use Elastic Load Balancing and Auto Scaling to configure web servers to scale out when under attack (based on load), and shrink back when the attack stops Use AWS Shield, a managed Distributed Denial of Service (DDoS) protection service, that safeguards web applications running on AWS Use Amazon CloudFront to absorb DoS/DDoS flooding attacks Use AWS WAF with AWS CloudFront to help protect your web applications from common web exploits that could affect application availability, compromise security, or consume excessive resources Use Amazon CloudWatch to detect DDoS attacks against your application Use VPC Flow Logs to gain visibility into traffic targeting your application.
3. How are you managing the threat of malware?	Give users the minimum privileges they need to carry out their tasks Patch external-facing and internal systems to the latest security level. Use a reputable and up-to-date antivirus and antispam solution on your system. Install host based IDS with file integrity checking and rootkit detection Use IDS/IPS systems for statistical/behavioural or signature-based algorithms to detect and contain network attacks and Trojans. Launch instances from trusted AMIs only Only install and run trusted software from a trusted software provider (note: MD5 or SHA-1 should not be trusted if software is downloaded from random source on the internet) Avoid SMTP open relay, which can be used to spread spam, and which might also represent a breach of the AWS Acceptable Use Policy.
4. How are you identifying vulnerabilities or misconfigurations in the operating system of your Amazon EC2 instances?	Define approach for securing your system, consider the level of access needed and take a least-privilege approach Open only the ports needed for communication, harden OS and disable permissive configurations Remove or disable unnecessary user accounts. Remove or disable all unnecessary functionality. Change vendor-supplied defaults prior to deploying new applications. Automate deployments and remove operator access to reduce attack surface area using tools such as EC2 Systems Manager Run Command Ensure operating system and application configurations, such as firewall settings and anti-malware definitions, are correct and up-to-date; Use EC2 Systems Manager State Manager to define and maintain consistent operating system configurations Ensure an inventory of instances and installed software is maintained; Use EC2 Systems Manager Inventory to collect and query configuration about your instances and installed software Perform routine vulnerability assessments when updates or deployments are pushed; Use Amazon Inspector to identify vulnerabilities or deviations from best practices in your guest operating systems and applications Leverage automated patching tools such as EC2 Systems Manager Patch Manager to help you deploy operating system and software patches automatically across large groups of instances Use AWS CloudTrail, AWS Config, and AWS Config Rules as they provide audit and change tracking features for auditing AWS resource changes. Use template definition and management tools, including AWS CloudFormation to create standard, preconfigured environments.
5. How are you protecting the integrity of the operating system on your Amazon EC2 instances?	Use file integrity controls for Amazon EC2 instances Use host-based intrusion detection controls for Amazon EC2 instances Use a custom Amazon Machine Image (AMI) or configuration management tools (such as Puppet or Chef) that provide secure settings by default.
6. How are you ensuring security of containers on AWS?	Run containers on top of virtual machines Run small images, remove unnecessary binaries Use many small instances to reduce attack surface Segregate containers based on criteria such as role or customer and risk Set containers to run as non-root user Set filesystems to be read-only Limit container networking; Use AWS ECS to manage containers and define communication between containers Leverage Linux kernel security features using tools like SELinux, Seccomp, AppArmor Perform vulnerability scans of container images Allow only approved images during build Use tools such as Docker Bench to automate security checks Avoid embedding secrets into images or environment variables, Use S3-based secrets storage instead.
7. How are you ensuring only trusted Amazon Machine Images (AMIs) are launched?	Treat shared AMIs as any foreign code that you might consider deploying in your own data centre and perform the appropriate due diligence Look for description of shared AMI, and the AMI ID, in the Amazon EC2 forum Check aliased owner in the account field to find public AMIs from Amazon.
8. How are you creating secure custom (private or public) AMIs?	Disable root API access keys and secret key Configure Public Key authentication for remote login Restrict access to instances from limited IP ranges using Security Groups Use bastion hosts to enforce control and visibility Protect the .pem file on user machines Delete keys from the authorized_keys file on your instances when someone leaves your organization or no longer requires access Rotate credentials (DB, Access Keys) Regularly run least privilege checks using IAM user Access Advisor and IAM user Last Used Access Keys Ensure that software installed does not use default internal accounts and passwords. Change vendor-supplied defaults before creating new AMIs Disable services and protocols that authenticate users in clear text over the network, or otherwise insecurely. Disable non-essential network services on startup. Only administrative services (SSH/RDP) and the services required for essential applications should be started. Ensure all software is up to date with relevant security patches For in instantiated AMIs, update security controls by running custom bootstrapping Bash or Microsoft Windows PowerShell scripts; or use bootstrapping applications such as Puppet, Chef, Capistrano, Cloud-Init and Cfn-Init Follow a formalised patch management procedure for AMIs Ensure that the published AMI does not violate the Amazon Web Services Acceptable Use Policy. Examples of violations include open SMTP relays or proxy servers. For more information, see the Amazon Web Services Acceptable Use Policy http://aws.amazon.com/aup/

Security at the infrastructure level, or any level for that matter, certainly requires more than just a checklist. For a comprehensive insight into infrastructure security within AWS, we suggest reading the following AWS whitepapers – AWS Security Pillar and AWS Security Best Practises.

For more details, refer to the following AWS resources:

Next up in the blog series, is Part 3 – Data Protection in AWS – best practice checklist. Stay tuned.

Let us know in the comments below if we have missed anything in our checklist!

DISCLAIMER: Please be mindful that this is not an exhaustive list. Given the pace of innovation and development within AWS, there may be features being rolled out as these blogs were being written . Also, please note that this checklist is for guidance purposes only. For more information, or to request an in-depth security review of your cloud environment, please contact us.

Author: Neha Thethi

Editor: Gordon Smith

The post AWS Cloud: Proactive Security and Forensic Readiness – part 2 appeared first on BH Consulting.