Emergence of Shadow AI

Shadow IT was a term created to describe the use of technology outside the purview of IT security and compliance teams (security compliance). An example of Shadow IT would be tools like flash drives or cloud storage to share documents with internal/external personnel, which can lead to the loss of sensitive/confidential information. This is why data loss prevention (DLP) measures are an important aspect of security compliance. An example DLP measure would be disabling USB drives on computers to prevent the use of flash drives.

AI is often not being introduced through structured programs with clear ownership and governance.

This brings me to an interesting article I read yesterday related to Shadow AI, which has emerged as a new term during the past few years. I find the concept interesting since, at least from the outside looking in, it appears AI is being pushed from the top down, bypassing attempts by security compliance to introduce controls into processes. This approach often leads to data loss similar to what happened to Meta last month while implementing their Model Compatibility Initiative (MCI) tool, even if the data loss was limited to internal personnel.

This is why security leadership must evolve from the “Department of No” to the “Department of How.”

The writer of the article is of the opinion the security function needs to evolve from “No” to “How”. This brought flashbacks from when companies reimagined internal and external audit teams as advisers. I’m not going to refute the writer here so much as I think this should already exist. Security should already be included in the “how” through project management and software development life cycle processes.

The issue is still that the security compliance teams are being bypassed. Organizations are asking staff to find ways to use AI outside the typical project management and SDLC processes. There’s no reimagining of security compliance if organizations aren’t willing to use a structured approach to implementing AI… and this introduces a massive risk that I don’t think executives and board members are aware of or are just willing to accept to beat the competition.

The CISO vs. Shadow AI Cold War

Just my two cents.

And Now For Something Completely Different

I’m going to take a stab at doing something different on the GRC blog so it doesn’t get too stale by posting links to articles I found interesting during the past month or so and adding some thoughts about the articles. Where the focal point of the blog will mostly revolve around Governance, Risk, and Compliance (GRC), these will likely stray from that focus and into the wider IT industry / environment.

FIFA

This post popped into my feed on the infosec.exchange Mastodon instance and, though it can be a little technical to read at times (read: boring), it might be the most interesting read from the last month. Bob the Hacker was able to find a weakness in FIFA’s Agent Platform that allowed him to not only see the backend of the FIFA feeds, but change them if he wanted. Things got worse as he attempted to contact FIFA to report the security flaw. The headline for the post makes it even better, thinking about how funny it would have been if he changed a match feed to Rick Astley’s Never Gonna Give You Up at the most inopportune time.

I Could’ve Rickrolled the Entire FIFA World Cup. All I Needed Was My ID

On that note, why not give the song a watch/listen.

Apple

It didn’t happen overnight, but the devices I use in my personal life are almost entirely in the Apple ecosystem, so articles about them tend to peak my interest. However, the reality of this article headline about an exploit doesn’t really hold up from a risk perspective. Yes, there’s an exploit on millions of iPhones that can’t be patched. However, assuming the information included in the article is accurate, it only affects older iPhones, requires directly connecting to the iPhone via a special USB device, and doesn’t grant access to user data. It’s not something to dismiss, but maybe don’t let someone connect a USB device to your iPhone without your knowledge.

New Exploit Bypasses Apple’s Boot Defenses

Sticking with the Apple ecosystem, Apple is planning to move from @icloud.com to @private.icloud.com for their hide my email address feature. I’ve used this feature a few times when signing up for an online web site/service. I’m not a fan of the change as it would seem to make it easier for web sites to blacklist @private.icloud.com email addresses, nullifying its usefulness.

Apple Plans to Change its Hide My Email Privacy Feature

META

I don’t actively use Meta platforms much anymore, mostly just using Facebook for the community page to keep up with things happening in my neighborhood, but that’s not really the point of the article. The article is about an employee tracking program called MCI.

Meta rolled out the Model Compatibility Initiative (MCI) tool in April to US employees. The tool “collects computer inputs such as mouse movements, click locations and keystrokes, as well as screen content,” according to workers who have been petitioning against it over privacy, security, and personal liberty concerns.

There are obviously a lot of decisions that go into obtaining employment and deciding to stay with that employer over time, but I’m not sure I’d be willing to give up all my privacy to allow an employer to go into this level of monitoring. To make matters worse, Meta failed to protect the data it was gathering in the program… TWICE. Not good.

Meta Pauses Employee-Tracking Program Following Internal Data Leak

That’s it for this month.

SOC 2 and the Trust Services Principles/Criteria

In my first post, way back on June 1ˢᵗ, I provided a brief overview of the System and Organization Controls (SOC) 1, 2, and 3 reports. Since then the posts have mostly been from the SOC 1 perspective, although the concepts still mostly apply to SOC 2 reports. Either way, I figured it would be beneficial to go into a little more detail about SOC 2 reports.

Example cover page for an SOC 2 Type 2 report.

Trust Services Principles/Criteria:

SOC 2 examinations were born out of the Trust Services Principles (TSP) and were later renamed as Trust Services Criteria (TSC). There are 5 TSCs that can be included in an SOC 2 report. Service organizations have the option to include 1 or more of these in their report depending on the needs of their clients.

Security / Common Criteria: The Security criteria ensures systems and information are protected against unauthorized access and disclosure. Initially, there were some security criteria that spanned all 5 TSCs. As a result, those criteria were consolidated into what is now known as the Common Criteria (CC), which also include aspects of the organizations overall control environment, risk assessment processes, and monitoring activities. There are 9 overall Common Criteria (CC1 – CC9).

The Security / Common Criteria is the baseline for inclusion in all SOC 2 reports. In other words, a service organization can choose to include just the Security / Common Criteria in their examination / report or include 1 or more of the remaining TSCs at their discretion.

Availability: The Availability criteria ensures systems are accessible and operational based on internal and/or contractual requirements. The criteria in this principle include performance monitoring, data backup, and testing of disaster recovery plans. There is 1 overall Availability criteria (A1).

Example availability criteria (A1) as noted in the TSC.

Included in the image above are the A1: Additional Availability criteria. The service organization would document 1 or more of their controls for each of the 3 sub-criteria noted. Those controls are what the service auditor would assess.

Processing Integrity: The Processing Integrity criteria ensures system processing is complete, valid, accurate, timely, and authorized. In essence, the controls supporting this criteria ensure the systems do what they were intended to do, without errors. There is 1 overall Processing Integrity criteria (PI1).

Confidentiality: The Confidentiality criteria ensures the organization is able to identify, maintain, and protect sensitive data thought the use of encryption, access controls, and data disposal procedures. There is 1 overall Confidential criteria (C1).

Privacy: The Privacy criteria ensures Personal Identifiable Information (PII) is collected, used, retained, and disclosed in accordance with the organizations own privacy policy and generally accepted privacy principles.

The Privacy criteria is expansive and requires a lot of time to assess. As a result, including the Privacy criteria in an SOC 2 examination / report substantially increases the overall cost to complete the engagement, compared to just including the 1ˢᵗ 4 TSCs, making it the least likely to be included in an SOC 2 examination / report. There are 8 overall Privacy criteria (P1 – P8).

SOC2+:

Service organizations also have the option to complete an SOC 2+ examination / report. This report would include an assessment of 1 or more TSCs along with other criteria specified by the service organization. The other criteria can be objectives typically included in an SOC 1 report for clients that are also interested in the financial statement impact of the services provided by the service organization. Or, for example, the service organization could include requirements under the Health Insurance Portability and Accountability Act Security Rule (e.g., HIPAA) in the SOC 2+ report. I haven’t seen organizations used this option often, rather deciding to have separate SOC 1 and SOC 2 examinations completed, with either/both provided to clients based on their specific needs.