Cloud misconfiguration — incorrect control settings applied to both hardware and software elements in the cloud — are threat vectors that amplify the risk of data breaches. A new report from cloud security vendor Qualys, authored by Travis Smith, vice president of the company’s Threat Research Unit lifts the lid on risk factors for three major cloud service providers.

About the report

Smith wrote that Qualys researchers, analyzing misconfiguration issues at Amazon Web Services, Microsoft Azure and Google Cloud Platform, found that within Azure, 99% of the disks are either not encrypted or aren’t using customer-managed keys that give users control of encryption keys that protect data in software as a service applications.

The study, which reviewed encryption, identity and access management and failures to monitor external-facing assets examined risks to unauthorized access due to:

• The complexity of cloud environments
• Lack of expertise in keeping up with evolving technologies
• Insecure settings and permissions caused by human errors
• Rapid deployment compromising security implementation measures
• Lack of control and visibility of cloud-resident unencrypted or sensitive data due to the dynamic nature of cloud environments

Smith wrote that the company’s reachers found that 85% of the keys aren’t rotated, meaning automatic key rotation isn’t enabled. Amazon offers automatic key rotation — generating new cryptographic material — on a 365 day cycle for keys.

Qualys also reported that in GCP environments, 97.5% of virtual machine disks for critical virtual machines lack encryption using customer-supplied encryption keys.

Jump to:

• About the report
• Identity and Access Management
• Exposure of external-facing assets from leaky S3 buckets
• Center for Internet Security work offers insights to remediation

Identity and Access Management

Qualys found poor implementation levels of IAM in all three major providers:

• Multifactor authentication: AWS isn’t enabled for 44% of IAM users with console passwords. IAM Access Analyzer isn’t enabled in 96% of the accounts scanned by Qualys.
• In Azure, scans for enabling authentication and configuring client certificates within Azure App Service fail 97% of the time.

Exposure of external-facing assets from leaky S3 buckets

Qualys noted that a common mistake by users across the three platforms is public exposure of data:

• Qualys reported 31% of S3 buckets are publicly accessible.
• The misconfiguration of leaving public network access enabled was seen in 75% of the Azure databases.

SEE: What is cloud security?

Center for Internet Security work offers insights to remediation

Recommendations by the firm included reviewing research by the Center for Internet Security including work Qualys participated in: mapping of individual controls to the MITRE ATT&CK tactics and techniques.

Qualys contributed to developing these CIS benchmarks for AWS, Azure and GCP. The benchmarks will help offer some valuable insight and context for defenders to better prioritize the hundreds of hardening controls available in cloud environments.

Qualys also looked at how firms are deploying controls to harden their cloud postures across the three major platforms, noting that privilege escalation (96.03%), initial access (84.97%) and discovery (84.97%) are passing at the highest rates.

Efforts to control attacks early are helping to ameliorate more harmful consequences further along the the kill chain:

• Impact passed at only 13.67%
• Exfiltration at only 3.70%.
• Exploitation of public facing apps passed at only 28.54%.
• Exploitation of remote services, at only 17.92%, are failing at high rates.
• Resource hijacking is passing at just 22.83%.

Smith wrote that since crypto mining malware is a threat to cloud environments, organizations should consider mitigating such controls to reduce their organizational risk in the cloud.

“The lesson from these data points is that almost every organization needs to better monitor cloud configurations,” said Smith, adding that scans for CIS controls failed 34% of the time for AWS, 57% for Microsoft Azure and 60% for GCP (Figure A).

“Even if you believe your cloud configurations are in order, the data tells us that not regularly confirming status is a risky bet. Scan the configurations often and make sure the settings are correct. It takes just one slip-up to accidentally open your organization’s cloud to attackers,” wrote Smith.

CISSP training course

InfoSec tools | InfoSec services | InfoSec books

Article by Dejan Kosutic

The General Data Protection Regulation (GDPR) has already raised many controversies, and one of the biggest ones is certainly which documents are required. For example, often you see companies who think having a privacy policy and a consent form on their website is enough; however, this is only a small part of the documents that are required to be fully compliant with this new privacy regulation.

Therefore, we created a list of GDPR documentation requirements to help you find all mandatory documents at one place . Please note that the names of the documents are not prescribed by the GDPR, so you may use some other titles; you also have a possibility to merge some of these documents.

Mandatory documents and records required by EU GDPR

Here are the documents that you must have if you want to be fully GDPR compliant:

• Personal Data Protection Policy (Article 24) – this is a top-level document for managing privacy in your company, which defines what you want to achieve and how. See also: Contents of the Data Protection Policy according to GDPR.
• Privacy Notice (Articles 12, 13, and 14) – this document (which can also be published on your website) explains in simple words how you will process personal data of your customers, website visitors, and others.
• Employee Privacy Notice (Articles 12, 13 and 14) – explains how your company is going to process personal data of your employees (which could include health records, criminal records, etc.).
• Data Retention Policy (Articles 5, 13, 17, and 30) – describes the process of deciding how long a particular type of personal data will be kept, and how it will be securely destroyed.
• Data Retention Schedule (Article 30) – lists all of your personal data and describes how long each type of data will be kept.
• Data Subject Consent Form (Articles 6, 7, and 9) – this is the most common way to obtain consent from a data subject to process his/her personal data. Learn more here: Is consent needed? Six legal bases to process data according to GDPR.
• Parental Consent Form (Article 8) – if the data subject is below the age of 16 years, then a parent needs to provide the consent for processing personal data.
• DPIA Register (Article 35) – this is where you’ll record all the results from your Data Protection Impact Assessment. See this webinar: Seven steps of Data Protection Impact Assessment (DPIA) according to EU GDPR.
• Supplier Data Processing Agreement (Articles 28, 32, and 82) – you need this document to regulate data protection with a processor or any other supplier.
• Data Breach Response and Notification Procedure (Articles 4, 33, and 34) – it describes what to do before, during, and after a data breach. See also: 5 steps to handle a data breach according to GDPR.
• Data Breach Register (Article 33) – this is where you’ll record all of your data breaches. (Hopefully, it will be very short.)
• Data Breach Notification Form to the Supervisory Authority (Article 33) – in case you do have a data breach, you’ll need to notify the Supervisory Authority in a formal way.
• Data Breach Notification Form to Data Subjects (Article 34) – again, in case of a data breach, you’ll have the unpleasant duty to notify data subjects in a formal way.

In response to a recent vulnerability identified in Outlook, Microsoft recently published a proper guide for its customers to help them discover the associated IoCs.

That Outlook vulnerability in question has been tracked as “CVE-2023-23397” with a CVSS score of 9.8 and marked as Critical.

As a result of this flaw, NTLM hashes can be stolen, and without any user interaction, they can be reused to execute a relay attack.

The threat actors use specially crafted malicious emails to exploit the vulnerability and manipulate the victim’s connection. As a result, this allows them to get control of an untrusted location.

The attacker can authenticate as the victim with the Net-NTLMv2 hash leaked to the untrusted network.

Microsoft patched the flaw

In the Patch Tuesday updates for March 2023, Microsoft fixed the vulnerability in order to prevent the possibility of any further attacks.

The problem is that this approach was taken after it was weaponized by Russian threat actors and used as a weapon against the following sectors in Europe:

• Government
• Transportation
• Energy
• Military

It was reported in April 2022 that Microsoft’s incident response team had found evidence that the shortcoming could be exploited.

Attack chain & threat hunting Guidance

It has been identified that a Net-NTLMv2 Relay attack allowed a threat actor to gain unauthorized entry to an Exchange Server in one attack chain.

By exploiting this vulnerability, the attacker could modify mailbox folder permissions and maintain persistent access, posing a significant security risk.

The adversary used the compromised email account in the compromised environment to extend their access. It has been discovered that this is done by sending additional malicious messages through the same organization to other members.

CVE-2023-23397 can lead to credential compromise in organizations if they do not implement a comprehensive threat-hunting strategy. 

As a first step, running the Exchange scanning script provided by Microsoft is important to detect any malicious activity. However, it’s imperative to note that for all scenarios, this script is not capable of providing any visibility into messages that are malicious in nature.

Multiple mailboxes can be opened at the same time by Outlook users. Messages received through one of the other services will still trigger the vulnerability if a user configured Outlook to open mailboxes from multiple services. The scanned mailboxes do not contain that message.

If a user wishes to move a message to a local file, they can do so. Finding evidence of a prior compromise in Archived messages may be possible in some cases.

You can no longer access your Exchange messages if they have been deleted from Exchange. It is recommended that incident responders review the security telemetry collected from all available channels in order to confirm the presence of IP addresses and URIs obtained from the PidLidReminderFileParameter values. 

There are a number of data sources that can be used to gather data, including:-

• Firewall logs
• Proxy logs
• Azure Active Directory sign-in logs for users of Exchange Online
• IIS Logs for Exchange Server
• VPN logs
• RDP Gateway logs
• Endpoint telemetry from endpoint detection and response (EDR)
• Forensic endpoint data

Recommendations

Here below we have mentioned all the recommendations:-

• To mitigate the issue, make sure to update Microsoft Outlook immediately.
• Ensure that defense-in-depth mitigations are active in organizations leveraging Microsoft Exchange Server on-premises.
• The script should be used to remove either the messages or just the properties if suspicious or malicious reminder values are observed.
• In the event that a targeted or compromised user receives suspicious reminders or initiates incident response activities, they should be instructed to reset their passwords.
• To mitigate the impact of possible Net-NTLMv2 Relay attacks, it is recommended that you use multifactor authentication.
• On Exchange, you should disable unnecessary services that you don’t need.
• Block all IP addresses except those on an allowlist from requesting connections on ports 135 and 445.
• If your environment has NTLM enabled, you should disable it.

Source: