Search the Community

AWS Mainframe Modernization is now Payment Card Industry Data Security Standard (PCI DSS) compliant, enabling customers to use AWS Mainframe Modernization for applications that store, process, and transmit information for use cases such as payment processing that are subject to PCI DSS. View the full article

System hardening means locking down a system and reducing its attack surface: removing unnecessary software packages, securing default values to the tightest possible settings and configuring the system to only run what you explicitly require. Let’s take an example from daily life. A jewellery store and a grocery shop are located next to each other, but of course, you would expect that the jewellery store has much beefier bars and stronger locks that are shut when the shop is closed for the night as the contents are more valuable. In this case, the jewellery shop building has been hardened to protect precious products and deter thieves. We can take a very similar approach to computer systems too. When software such as an operating system is published, anyone can download it and use it for playing games, running an online bank, and everything in between. But for running the bank, we need to take some additional precautions to harden the system above and beyond the default configuration. Hardening a system aims to decrease its exposure in order to make it more difficult to hack, and to lessen the potential collateral damage in the event of a compromise. Why is system hardening important? Anyone who runs computer infrastructure they rely upon should be concerned about hardening their systems. This is especially important where user data such as Personally Identifiable Information or financial records are involved, as there are significant fines facing organisations who suffer a data breach in these cases, not to mention the reputational damage caused by the damning headlines. What are the types of system hardening? Server hardening Each layer and component of an IT system needs to be hardened to ensure that they provide a secure base for the next layer. This all starts with the hardware, the foundation of the application stack, so the first place we will look is at server hardening. The idea is to make the server as robust as possible against local attacks, i.e. people with physical access to the machine, and prevent them from snooping on the data on the server or introducing malicious code. These are the main server hardening steps to take: Update the BIOS. Manufacturers frequently release new BIOS versions to address security issues, and it’s important to keep on top of these by updating to the latest version as soon as is reasonable. Enable SecureBoot. This uses digital signatures to ensure that the system boots genuine signed code, and means that it is harder for an attacker with physical access to the server to subvert the boot process. Set BIOS and remote management passwords. Features such as SecureBoot can be disabled in the BIOS, so it’s important to set a BIOS password to prevent that. Remote management interfaces also offer a wealth of low-level system access, and these should be password protected, and only be accessible via a trusted management subnet. Disable unused USB ports. If the server doesn’t need to use certain hardware features, these can often be disabled in the BIOS, to further prevent physical attacks against the system. Configure the disks with full disk encryption. Disk encryption means that someone can’t take the disks out of the machine and access or modify the contents offline. In cloud environments and virtual machines, disk encryption also prevents a malicious actor at the hypervisor level from accessing your virtual disks. Operating system hardening Once the server hardware has been locked down, the next step is to configure the operating system. This is where the majority of the hardening procedures can be applied, as the operating system is a generic canvas that needs to be customised to each individual use case; for instance, a development environment has a very different security posture to a production server. There are a number of avenues to follow when hardening the operating system, which can be broken down into the following categories: Remove unnecessary and unused components. A Linux OS such as Ubuntu contains packages to cover a very wide range of use cases, but it’s likely that a production system will only have a small number of critical workloads. Any package not supporting these workloads should be removed. Tighten default settings and enforce encryption. Ensure directories are configured to allow only the minimum privileges required to run the production workloads, and encrypt file systems. Configure logging and integrity checks. All system and application logs should be stored on a remote server to ensure that in the event of a hack the attacker can’t delete the logs to cover their tracks. File integrity monitoring software should be deployed to provide warnings if any unexpected changes occur which might be indicative of an attack. Keep software patched and up-to-date. The majority of system compromises occur because attackers exploit known vulnerabilities that have not been patched. It is essential that all security patches are applied quickly and automatically. Regularly scan for vulnerabilities using third-party scanning software, to identify any weaknesses in the overall system integrity. Implement operational best practices, particularly when it comes to user account management. In any organisation, users will come and go and change roles; user accounts need to be kept in sync, and access revoked when users no longer need the same levels of access. Application security and hardening When it comes to application security, it is more difficult to be prescriptive about hardening as each application has its own security requirements. However, there are general security and hardening principles that can be applied to most applications: Enforce strong encryption, and use a trusted PKI to ensure authenticity. For example, web-based applications use TLS, for which certificates can be provisioned through Let’s Encrypt. Reduce privilege levels to the minimum required. Ensure that regular users don’t have full administrative access. Configure logging, and monitor logs for anomalies. Application logs should be aggregated remotely to ensure that they can’t be altered or destroyed by an attacker, and the logs should be analysed to detect anomalous behaviour which could reveal the start of an active attack. Check dependencies for vulnerabilities. Most applications have a large number of software libraries and dependencies, any of which might have security vulnerabilities – all components need to be kept patched and up to date. For any application it is important to build on solid foundations, which means that the operating system is secured and hardened properly first. The next step is to look at the software supply chain that the application builds upon, and an excellent place to begin here is to consume software components from a trusted source. Ubuntu gives everybody access to the widest range of open source software libraries and applications within the industry, backed by a ten year security maintenance guarantee with a Pro subscription, which gives your application security and hardening the strongest foundations possible. CIS benchmarks Because system hardening is so important to so many organisations, industry standards have been developed to gather the best practices from across the world and formulate a common approach to hardening. The Center for Internet Security (CIS) publishes hardening benchmarks for many common software applications and operating systems, including Ubuntu, and if you implement the suggestions in these hardening profiles then you can be assured of a comprehensive level of security. CIS benchmarks have broad applicability across a wide range of industries, and are useful for any organisation deploying services on the internet. Some industry sectors carry specific regulatory requirements which mandate system hardening, such as PCI-DSS, the Payment Card Industry Data Security Standard. PCI-DSS version 4 requires that “System components are configured and managed securely” and “are consistent with industry-accepted system hardening standards or vendor hardening recommendations”, with specific reference to the CIS benchmarks. Automated cyber security tools with Ubuntu Security Guide (USG) At Canonical, we recognise the need for hardening, whilst also acknowledging that implementing the hundreds of rules within the CIS benchmarks is an arduous task, therefore we provide the Ubuntu Security Guide, an automated cyber security tool for system hardening, remediation and auditing. USG is available as part of Ubuntu Pro, which is free for personal use on up to 5 machines. With USG installed, hardening your Ubuntu system to the CIS standards is as straightforward as running a command: usg fix cis_level1_server For a quick start with Ubuntu Security Guide for CIS or DISA-STIG consider using this tutorial. A comprehensive guide We published a detailed guide to Infrastructure Hardening covering all the steps and procedures outlined here, plus more. Download Canonical has published a detailed guide to Infrastructure Hardening covering all the steps and procedures outlined here, plus more. Conclusion Hardening your infrastructure and systems is a vital step in creating a production environment, but can be a daunting prospect to tackle from scratch. Taking advantage of industry standards, such as the CIS benchmarks, and using the automated cyber security tools available with Ubuntu Pro, can make this a much more manageable proposition. For more information contact us here. To learn more about Canonical and what we do around security and compliance: Visit our webpage Read more on this topic in our blog Download our comprehensive guide on infrastructure hardening View the full article

Amazon Managed Workflows for Apache Airflow (MWAA) is now Payment Card Industry Data Security Standard (PCI DSS) compliant. Amazon MWAA is a managed orchestration service for Apache Airflow that makes it easier to set up and operate end-to-end data pipelines in the cloud. Customers can now use Amazon MWAA to manage workflows that store, process, and transmit information for use cases such as payment processing that are subject to PCI DSS. View the full article

This is a warning about AWS Security Hub. Organizations that use AWS Security Hub to monitor and mitigate risks pay too much attention to the visible part of the AWS security iceberg, namely the findings. These organizations tend to overlook or underestimate the invisible part of the iceberg where critical risks are hidden. /images/2022/05/iceberg.jpg Below, I go into the details of my observations and outline possible countermeasures to ensure you are using AWS Security Hub in the right way. Overwhelming amount of findingsThe AWS Security Hub comes with controls for the following standards: CIS AWS Foundations: 48 controls Payment Card Industry Data Security Standard (PCI DSS): 49 controls AWS Foundational Security Best Practices: 162 controls It is not uncommon that you will end up with hundreds or even thousands of findings after enabling one or multiple standards for multiple AWS accounts with running workloads. Working through a huge list of findings to evaluate, suppress, or fix the issue is demotivating and uses up a lot of energy and attention. /images/2022/05/securityhub-findings.png I’ve seen teams spend weeks or months fixing all the findings generated by AWS Security Hub. Don’t get me wrong, fixing the findings will improve overall security. My point is that you may be overlooking important areas where security can be significantly enhanced by spending the same time and money. A few ideas to avoid getting overwhelmed by the number of findings generated by the AWS Security Hub. Do not enable all security standards at once. For example, start with the CIS AWS Foundations standard. Enable and monitor the AWS Security Hub at the beginning of a project before creating resources in the AWS account. Disable irrelevant or outdated controls. Also, disable controls generating a lot of minor findings. Superficial security controlsBefore the AWS Security Hub was a thing, I worked on a similar tool many years ago. The challenge when designing and implementing controls is abstraction and generalization. To evaluate the risk of a configuration, context is needed. Let me illustrate this with an example. A Lambda function assumes an IAM role with the following policy attached. { "Version": "2012-10-17", "Statement": [ { "Action": [ "s3:CreateBucket", "s3:DeleteBucket", "s3:DeleteObject", "s3:GetObject", "s3:PutObject" ], "Effect": "Allow", "Resource": "*" } ] } A generic control cannot tell whether the IAM policy follows the least privilege principle because it does not know the Lambda function. The IAM policy could either be fine or add an unnecessary risk of accidental or malicious data deletion. That’s why the controls focus on generic risks that are easy to detect. So it is crucial that you ask the question: Which parts of the iceberg are not covered by AWS Security Hub? Let me give you a few examples: Do resource- and identity-based policies follow the least privilege principle. Are the security group rules as strict as possible? Is the ALB publicly accessible by intention? Should objects be protected from being manipulated or deleted by enabling S3 Object Lock? What’s the data classification of the data stored in a database cluster? Is encryption with a customer-managed KMS key required? Does that Lambda function (Node.js) contain a package with a critical vulnerability? Be aware that the AWS Security Hub does not check all relevant aspects of cloud security. Also, it is impossible to evaluate rules based on context information like the data classification, for example. That does not mean the service is terrible; it is just not possible to go into the details with generic controls. Some might argue, that other AWS services or 3rd parties could jump in and provide advanced controls. For example, the IAM Access Analyzer compares CloudTrail logs with IAM polices to make suggestions on how to improve the policy. However, the IAM Access Analyzer comes with the same limitation, it does not know about your scenario. Instead, it makes guesses based on incomplete/expensive CloudTrail logs. In my opinion, all those tools try to solve a problem, that cannot be solved without any context information about the scenario. Some ideas on avoiding blind spots when using the AWS Security Hub. Be aware that the AWS Security Hub does not cover all relevant aspects of cloud security. Ask AWS security specialists to review AWS accounts regularly. Validate whether IAM and network configuration follows the least privilege principle. False-positivesWe use the AWS Security Hub to evaluate the security risks within our AWS accounts. Every day, marbot -our chatbot- forwards a Security Hub finding to one of our Slacks channels. The finding tells us that there is an EC2 instance with a public IP address running. /images/2022/05/securityhub-finding-marbot.png Running an EC2 instance with a public IP address should raise a red flag. However, we have a good reason to start an EC2 instance with public IP once a day for 5 minutes. Thus, the finding is a false positive. The problem with false positives is that we get used to them. I close the warning every day, and it has happened to me that I have overlooked an important warning. So, watch out for false positives and mark them as SUPPRESSED, which means you reviewed the finding and do not think any action is needed. In our case, a new finding gets generated every day because we are launching a new instance. That’s why automatically suppressing the finding is on our TODO list. A few ideas to ensure you do not get bothered by false positives and avoid alert fatigue. Mark false-postives as SUPPRESSED (see Setting the workflow status for findings) manually. Use a Lambda function to mark false positives as SUPPRESSED in case new resources result in findings regularly. SummaryThink of AWS security as an iceberg. The easy-to-find risks look out of the water, and AWS Security Hub will easily detect them. But under the water, the iceberg continues; critical vulnerabilities are hiding there. Therefore, here are a few tips for dealing with the AWS Security Hub. Avoid generating an overwhelming amount of findings. For example, do not enable all standards and controls at once. Be aware that the AWS Security Hub does not cover all relevant aspects of cloud security. The generic controls do not guarantee that you are following the least-privilege principle, for example. Reduce the noise generated by false positives to avoid alert fatigue. Mark findings as SUPPRESSED manually or automatically. View the full article

Amazon Keyspaces (for Apache Cassandra), a scalable, highly available, and fully managed Cassandra-compatible database service, now supports Payment Card Industry Data Security Standard (PCI DSS) compliance to help you run payment processing workloads more easily. View the full article

Today, Amazon Web Services (AWS) announced Amazon Timestream can now be used for workloads that are subject to Health Insurance Portability and Accountability Act (HIPAA), International Organization for Standardization (ISO), and Payment Card Industry – Data Security Standard (PCI DSS). View the full article

PCI Eligible AWS services deployed in AWS Wavelength can now store, process, or transmit cardholder data (CHD) or sensitive authentication data (SAD), including merchants, processors, acquirers, issuers, and service providers. PCI DSS (Payment Card Industry Data Security Standard) is a proprietary information security standard administered by the PCI Security Standard Council. Many Wavelength use cases like interactive live video streams, AR/VR, and real-time gaming require in-app purchases. Starting today, you can use AWS Wavelength to build, deploy, and run applications that store and use sensitive payment card data in compliance with PCI DSS. View the full article

AWS App Mesh is now certified as a Payment Card Industry Data Security Standard (PCI DSS) service. AWS App Mesh is a service mesh that provides application-level networking to standardize how your services communicate, giving you end-to-end visibility and enables options to tune for high-availability of your applications. View the full article

AWS Cloud Map is now certified as a Payment Card Industry Data Security Standard (PCI DSS) service. AWS Cloud Map is a cloud resource discovery service. With AWS Cloud Map, you can define custom names for your application resources, such as Amazon Elastic Container Services (Amazon ECS) tasks, Amazon Elastic Compute Cloud (Amazon EC2) instances, Amazon DynamoDB tables, or any other cloud resource. You can then use these custom names to discover the location and metadata of cloud resources from your applications using AWS SDK and authenticated API queries. AWS Cloud Map is a highly available, managed service with rapid change propagation. View the full article

Amazon Fraud Detector is a fully managed service that makes it easy to identify potentially fraudulent online activities, such as credit card transactions that are likely to result in costly chargebacks, using customized machine learning models. The service now supports Payment Card Industry Data Security Standard (PCI DSS), which applies to entities that store, process, or transmit cardholder data or sensitive authentication data. View the full article

Not a lot of things are certain in 2021, but one thing you can count on is Google Cloud’s commitment to our customers and to being a leader in open cloud. Supporting multiple workloads and meeting customers where they are is part of that open cloud commitment—and so is Bare Metal Solution, our solution to run Oracle database workloads on Google Cloud. As we continue developing Bare Metal Solution to meet your needs and meet you where you are, we’re announcing three Bare Metal Solution enhancements: Availability in Montreal, our 10th region; A new, smaller 8-core server; Support for PCI DSS and HIPAA. In 2021, we’ll continue to build on the momentum of Google Cloud’s Bare Metal Solution, which enables businesses to run Oracle databases close to Google Cloud with extremely low latency. See how StubHub is using Bare Metal Solution to reduce their dependency on Oracle, lower overall costs, and improve performance. Related Article Bare Metal Solution: Coming to a Google Cloud data center near you With Bare Metal Solution, now you can run specialized databases in five new Google Cloud regions. Read Article New regions, to meet you where you are Last year, we launched Bare Metal Solution in five regions and added four more throughout the year. With the launch of Bare Metal Solution in Montreal today, we’re kicking off this year by bringing Bare Metal Solution to Canada to provide our customers with local availability. We’ll launch Bare Metal Solution in a slew of other new regions in 2021 (and even some dual region availability). We recognize the need for local options for our customers, so please reach out to your sales rep if you’re interested in Bare Metal Solution, and we can work to get you on our roadmap. Below, in green, are our 10 GA regions: A smaller server, to help you save on licensing and hardware costs In order to help you right-size your workloads and reduce costs, we’ve added a new, smaller 8-core server to our lineup in all of our regions. This new 8-core server, which leverages our state-of-the-art compute, storage, and networking, means a migration to Bare Metal Solution can help shrink your hardware footprint and thus potentially reduce Oracle licensing costs, which are often dependent on core count. Here’s our full lineup of Bare Metal Servers, available in all of our regions: PCI DSS and HIPAA, to support your enterprise workload Last, but not least, Bare Metal Solution can now help support customer compliance with PCI DSS and HIPAA. Support for PCI DSS will allow our retail partners to bring their customers’ credit card data and run their workloads according to the Payment Card Industry Data Security Standards (PCI DSS). Support for HIPAA similarly means our healthcare partners can bring their customers’ healthcare data and run their workloads according to the requirements of the Health Insurance Portability and Accountability Act (HIPAA). As we expand to new regions and work to better enable specific industries, you can expect future announcements of both regional and industry-related certifications.