Cloud Computing

Cloud Computing and Security

Cloud Computing

The National Institute of Standards and Technology (NIST) describes cloud computing as a model for enabling ubiquitous, convenient, on-demand network access to a shared pool of configurable computing resources (e.g., networks, servers, storage, applications, and services) that can be rapidly provisioned and released with minimal management effort or service provider interaction. 

Cloud Service Providers (CSP) offer three types of services:

  • Software-as-a-Service (SaaS)
    • This category provides applications and software solutions on demand over the internet, accessible to the user, usually via a web browser. The cloud provider is responsible for nearly all security since the cloud user can only access and manage their use of the application and can’t alter how the application works.
  • Platform-as-a-Service (PaaS)
    • This category of Cloud computing provides a platform and environment for developers to develop, test and deliver software applications. The cloud provider is responsible for the security of the platform, while the user is responsible for everything they implement on the platform, including how they configure any offered security features.
  • Infrastructure-as-a-Service (IaaS)
    • The most basic category of Cloud computing services is Infrastructure-as-a-Service. With IaaS, an organization is renting IT infrastructure; servers, virtual machines, storage, and networks.  The provider is responsible for foundational security, while the cloud user is responsible for everything they build on the infrastructure.  Unlike PaaS, this places far more responsibility on the user.

Organizations have taken advantage of the benefits of cloud computing which include reduced capital expenses, high availability, agility, resiliency, and redundancy.

Cloud Security

When moving services and data to the Cloud, an organization must understand its security and compliance requirements as there is a shared security responsibility model between the organization and the Cloud Service Provider as described above.  The user is responsible for security IN the cloud and the provider is responsible for security OF the cloud.  Depending on the Cloud service that is being utilized, the security responsibility of the user includes patching operating systems as well as the applications.  This is the case in the Infrastructure-as-a-Service offering.  If the user moves to a Platform-as-a-Service offering they are no longer responsible for the Operating System maintenance and the patching of the Operating System. 

Figure 1 graphically depicts the boundaries and ownership of security responsibilities.  Regardless of the services utilized, the user is always responsible for their data security.

Moving to the Cloud?

Is your organization looking to move to the Cloud?  Are you evaluating providers to find out what service will work best for your requirements?  If so, there are a few questions that should be clarified to make an informed decision before committing to a move.

  • What does the Cloud Service Provider offer for Identity and Access Management?
    • This includes identification, authentication, and authorizations (including access management).
    • This is how you determine who can do what within your cloud platform or provider.
  • What security standards are supported by the Cloud Service Provider?
    • Payment Card Industry Data Security Standard (PCI DSS)
    • General Data Protection Regulation (GDPR)
    • Health Insurance Portability and Accountability Act (HIPAA/HITECH)
    • National Institute for Standards and Technology (NIST) SP 800-171
  • Where will your data be located?
    • Some regulatory requirements may dictate where the data is stored and processed
  • What type of automation is offered by the Cloud Service Provider?
    • Automation aids in reducing human configuration errors
  • Do you always “own” your data?
    • Can you encrypt, move, or destroy data at your discretion?
  • How does the Cloud Service Provider handle these five parts of the cybersecurity lifecycle?
    • Identify
    • Protect
    • Detect
    • Respond
    • Recover

Your Data/Your Responsibility

Don’t fall into an “out of sight, out of mind” mode about your data when you move to Cloud services.  It’s your data and the security of that data is, and always will be your responsibility regardless of where it is stored or processed.

Cyber Liability insurance is on the rise and there is an expectation that there are measurable efforts devoted to keeping information secure.  Breaches can cause serious damage to your organization not only financially but from a reputation standpoint as well.

SecurIT360 is an independent, vendor-agnostic Cybersecurity consulting firm.  

If you are interested in a complimentary strategy session, contact us here.


Cloud Security Alliance – Security Guidance for Critical Areas of focus in Cloud Computing

Email Security

How to configure warning messages for Microsoft 365 emails from external senders

As a security precaution, it’s a good idea to remind your staff not to open attachments from unknown senders. One easy way to implement this in Microsoft 365 is by setting up a mail flow rule in the Exchange admin center. If you have ever set up a Disclaimer mail flow rule, the setup is almost identical. In this tutorial, we’ll cover how to setup your own warning message for all external email sent to users inside your organization.

Steps to Configure Attachment Security in Microsoft 365

1. Log in to your Microsoft 365 Admin account at:

2. On the lefthand side of the homepage, select the “Admin” app from your list of Apps:

3. On the resulting page, select “Exchange” under “Admin centers” located on the left-side menu

4. Again on the left menu, expand the dropdown menu for “Mail flow” and select “Rules”

5. On the resulting page, next hit the plus symbol under “Rules” and select “create a new rule…”


6. Fill out the “New Rule” popup window in the detailed steps 7-14:

7. Make the name, “Warning: Received from Scope Outside the Organization” or whatever best suits you or your organization’s naming convention

8. For *Apply this rule if…  Select “The sender is located…”, from the drop-down menu then choose “Outside the organization” from the resulting “select sender location” window:

9. For *Do the following… , select “Apply a disclaimer to the message…” , “append the disclaimer”.

10. Select “*Enter text…” and enter the below HTML into the “specify disclaimer text” pop-out window

[CAUTION:  This email originated from outside of the organization.  Do not click links or open attachments unless you recognize the sender and know the content is safe]

The warning will look like the following if entered correctly:

11. After entering the Text, you’ll need to specify the fallback action. (by clicking “*Select one…”). Choose Wrap, then “OK”.

12. For the “Priority level of this rule” set according to any other rules you have configured. If this is the only rule, you can set “Audit this rule with severity level to “High”.

13. For “Choose a mode for this rule” leave at the selected default “Enforce” in place.

14. Click Save.

That’s it! You should start seeing the warning on external emails within a few minutes.

If you would like to learn more about how you can protect your corporate data, please click here to contact us. Keep up with the latest cybersecurity news here. SecurIT360 provides audits, scans, and analysis of various systems and businesses across multiple industries including legal, financial, utilities, and healthcare. Let us help you determine where you should spend your time and money protecting your information.

Cybersecurity Advisories

Log4j Zero-Day Advisory

We would like to make you aware of a critical and widespread unauthenticated Remote Code Execution (RCE) vulnerability involving Apache’s Log4j Java logging library.

Update – December 28th, 2021 (CVE-2021-44832)
On December 28th, Apache confirmed yet another vulnerability (CVE-2021-44832) that affects Log4j 2.0-beta7 to 2.17.0 (excluding 2.3.2 and 2.12.4). This is a new remote code execution vulnerability that requires an attacker to have permissions to modify the logging configuration file in order to be exploited. Apache has released Log4j 2.17.1 to fix this and previous vulnerabilities (CVE-2021-44228, CVE-2021-45046, CVE-2021-45105).

December 16th, 2021 (CVE-2021-45105)
On December 16th, Apache confirmed another vulnerability (CVE-2021-45105) that affects Log4j 2.0-alpha1 to 2.16.0 (excluding 2.12.3). It has been discovered that certain non-default configurations could allow attackers to perform a denial-of-service attack. Apache has released Log4j 2.17.0 to fix this and previous vulnerabilities associated with CVE-2021-44228 and CVE-2021-45046

SecurIT360 Managed Services ImpactAccording to FortiNET, FortiSIEM is listed as one of their applications that is impacted by Log4j.  We have followed the recommended mitigation steps across our FortiSIEM infrastructure.  Access to our FortiSIEM product externally is controlled by IP whitelisting, therefore only approved IP addresses can communicate with our environment by design. Their advisory page for this exploit is here for reference.
For Carbon Black, we use their cloud product and do not utilize any on-prem servers; therefore, it is not vulnerable to Log4j.  Their advisory page for this exploit is here for reference.
Detection of Vulnerable Log4j Versions

  • You can still utilize these detection methods that have been published to GitHub by security researchers
  • Nessus has released another updated plugin to help detect vulnerabilities associated with Log4j.  Our SOC analysts continue to run Nessus external vulnerability scans for all SecurIT360 MDR managed service clients as new plugins are released and will alert on successful findings.
    • So far, we have not detected any vulnerable versions via the external Nessus scans.  All scheduled routine external scans will continue to utilize this new plugin going forward.
    • An external scan is not enough, we do recommend utilizing the open-source tools mentioned above to detect all instances of Log4j in your environment.  Nessus plugins are also available for internal credentialed scans which can provide more thorough detection.
    • If you would like us to assist with Log4j detection utilizing Nessus Internal/External scanning please let us know and we can notify your account representative.
    • If you are a MDR managed client and would like us to update the external targets and rerun the scan or rerun the scan following a successful upgrade, please reach out via email to
  • A community-maintained list of known IPs associated with this exploit can be found here
    • All SecurIT360 MDR managed service clients are receiving alerts on permitted web traffic involving these known IP addresses
  • Hashes of vulnerable versions can also be found here for internal detection. Routine searches for these hashes are being conducted in Carbon Black across all SecurIT360 EDR managed service clients, we will alert on successful findings
    • All EDR managed service clients will be alerted to potential exploit activity if detected.

Recommended Mitigation Steps

  • Identify all applications in your environment that use Log4j and follow vendor guidance
  • Utilize open-source detection tools, Nessus, etc.
  • Upgrade to version Log4j 2.17.1 or later as soon as possible.
  • If upgrading is not feasible, we recommend following Apache’s mitigation guidance for Log4j 2.10 and later which can be found here
  • Restrict egress traffic to approved destinations at your firewall
    • IP Whitelisting
    • Restrict the types of traffic going out such as LDAP
  • Consider preemptively blocking known IPs associated with this exploit at your firewall
  • CSV format
  • TXT Format