And Now For Something Completely Different

It’s the last Thursday of the month, which means it’s the day I post something completely different. Included below are a few topics and articles that I found interesting this month.

DEF CON

This story from a Delta flight from Las Vegas to Atlanta following DEF CON doesn’t necessarily bring up a new concept in hacking, though the timing definitely leaves a lot to be desired. It would seem doing something illegal while on a plane with no exit strategy isn’t the smartest idea, unless their name is DB Cooper.

Still, the story allowed me to reminisce about attending DEF CON in 2017 with some coworkers, which was an experience both during and after-hours. Most of the conference was over my head, but I did learn how to pick locks and still have a lock picking set stored somewhere.

https://arstechnica.com/information-technology/2026/08/def-con-crowd-suspected-in-fake-hotspot-attack-on-delta-flight/

Apple

Apple will send a push notification to your phone if it detects “mercenary spyware attacks” based on who you are or what you do. This is a feature Apple has had in place since 2001, but popped into the mainstream once again this past month.

Security awareness training (including phishing, vishing, and smishing) usually recommend being cautious when an email, text, or phone call comes with a sense of urgency or pressure, so this would require some thought before taking next steps if it popped on my screen.

https://techcrunch.com/2026/08/13/if-apple-sends-you-a-push-notification-alerting-you-to-a-spyware-attack-take-it-seriously/

Infrastructure

Bear with me as I go in a little circle here regarding the cyber attacks on water infrastructure in various states.

Chesterton’s Fence is “the principle that you should not remove or change a rule, system, or object until you understand why it was put there in the first place”. I learned about this principle recently, mostly because it applies to so many things happening around us.

With my prior employer, an aspect of my job responsibilities was to complete IT risk and general controls assessments for local (small) municipal and public sector entities. Something I always had to keep in mind while performing these assessment was their resource limitations, which directly affected what types of recommendations could be made.

The Cybersecurity and Infrastructure Security Agency (CISA) is a federal agency under the Department of Homeland Security (DHS) responsible for protecting the nation’s critical infrastructure and cyber defenses. CISA provides additional support for local entities, including infrastructure, that don’t have the resources to do everything on their own.

CISA’s staff dropped from roughly 3,300 to about 2,389 employees last year (2025), which is a loss of about a third of the agency. Proposed budget plans for 2027 target the elimination of ~900 additional positions.

Job cuts at CISA, limited resources at the local level, and constantly increasing cyber threats is a recipe for disaster and could make cyberattacks on our infrastructure more common and potentially successful.

This is a long winded way of noting the job cuts at CISA are not a good idea.

https://www.securityweek.com/us-water-cyberattacks-extend-beyond-minnesota-to-at-least-6-other-states/

SOC Planning – Control Design

System and Organization Controls (SOC) control design involves documenting policies, procedures, and technical safeguards to align with the specific framework (e.g., SOC 1 control objectives, SOC 2 Trust Service Criteria). Last week I posted an example SOC 1 control objective with 4 supporting controls (below) with a caption indicating it’s not a fully fleshed out control objective and is just being used for illustrative purposes. With that in mind, let’s take a look at some topics to enhance the controls supporting the objective with some example controls.

Example SOC 1 control matrices for an access control objective. This is not a fully fleshed out objective and is just being used for illustrative purposes.

Topic #1: Hiring Process

The hiring process typically includes various controls that need to be completed prior to an employee being granted access. These controls can be included to provide a beginning-to-end employee lifecycle, but would most likely be assessed moderate or low control significance during the controls risk assessment.

Employees are required to pass a general background check prior to their first day of employment.
Employees are required to complete security awareness training on their first day of employment and annually thereafter.
Employees are provided the employee handbook upon hire, which documents the company code of conduct and authorized use of computer resources, that they are required to sign as an acknowledgment they read the handbook.

Topic 2: Split Access Controls

The process for granting an employee general network access at hire is different than the access required for specific job functions. For example, a payroll analyst would require role-based access to the ERP (Enterprise Resource Planning) system while a system administrator would require privileged access to 1 or more systems. These controls would be assessed high control significance during the controls risk assessment.

Application-level permissions are approved by the application/data owner and assigned based on custom configured user groups based on employee role to ensure permissions promote appropriate separation of duties.
Administrator-level permissions for network infrastructure (e.g, servers, firewalls, etc.) is approved by the CISO and is restricted to personnel who require elevated access to perform administrative job functions.
Access for administrative roles requires multi-factor authentication (MFA).

Topic 3: Authentication Controls

Authentication controls include minimum password length, password complexity, and account lock-out mechanisms for when unsuccessful attempts to access an account reach certain thresholds. The account lockout would include maximum attempts before getting locked out and a lockout duration, which lowers the risk of attackers guessing passwords to access the system. Authentication controls would be assessed a moderate or high control significance during the controls risk assessment depending on how the control objective is phrased.

Operating system, application, and database passwords are configured for strong user authentication parameters, including password length, password complexity, user account lockout on invalid attempts, and password change intervals.
User sessions are automatically logged out after 30 minutes of inactivity.

The option exists to be more specific regarding password controls. For example, the minimum password length can be listed (e.g., 10). However, by leaving it a little more generic, the service organization can point to the policy for the auditor to use as a baseline for testing. Also, depending on how systems are integrated, password controls might be different for all systems/applications or the same when integrated with single sign-on tools.

Topic 4: Monitoring Controls

Controls to monitor user access can be split between general network, applications (with role/permission review), and privileged access (administrative) permissions, with different frequencies that align with their risk. For example, a general review of access to the network to ensure no separated employees continue to have access might be completed annually while an administrator access review might be completed monthly. Monitoring controls would be assessed a moderate control significance during the controls risk assessment.

System administrators review network user access reports annually to verify access for separated employees was disabled and/or removed.
ERP module owners review user access reports monthly to verify access is current and appropriate based on the users role within the system.

As you can see, this can result in 10+ controls supporting a single control objective, which opens up the option of splitting the control objective so it’s more focused. For example, a control objective can be added that focuses on the hiring process or the control objective can be split to focus between general network access and administrative access to network infrastructure (e.g. servers, firewalls, IDS).

The decision to split the control objective or include more controls in a single objective can depend on the size and complexity of the environment, contractual requirements, or industry standards (e.g., NIST). And, as noted in the previous post, there’s a lot of grey area that goes into these decisions that requires professional judgement on the part of the service auditor when making recommendations during a readiness assessment or planning for the examination.

SOC Planning – Controls Risk Assessment

There are various planning steps that occur at the onset of a System and Organization Controls (SOC) 1 and/or 2 engagement, most of them the client isn’t aware is happening in the background. These steps are generally included in the audit program with templates available to complete some of the steps.

The controls risk assessment is a planning step that can begin once the control matrices are received from the client. This is when the fun begins. The SOC controls risk assessment is different from what would normally be included in a NIST-based risk assessment, which looks at risks from a confidentiality, integrity, and availability perspective, and assesses those risks based on impact and likelihood.

The SOC control risk assessment analyzes the design of controls to ensure they adequately meet the control objective or trust service criteria (TSC), the significance of the controls as they related to the objective/criteria, and the risk of non-compliance for each control.

Control Design

The primary goal when reviewing the controls is to determine whether the sum of the controls adequately support the control objective or TSC.

This is a wholesale review of the controls to ensure they meet the minimum requirements of the control objective. Although not ideal, there are situations in which a single control is enough to meet the controls objective. It’s also possible for there to be 10+ controls and still miss a key aspect of the control objective.

Using the example control matrices above, if this were a very large organization, I’d inquire about controls to update access for employees that transfer from one business unit (BU) or department to another BU or department. This is a potential area for there to be a design deficiency.

There’s a lot of grey area in this review that requires professional judgement that comes from working with clients both big and small, more and less complex. The audit firm should be cautious about starting the engagement before clearing up any potential design deficiencies.

Control Significance

The control significance assessment determines the significance of the control as it relates to the control objective. Each control is assessed a rating of high, moderate, or low based on its significance. A high control significance would indicate the control has a direct correlation to the control objective. A moderate control significance would indicate a supporting control. A low control significance would indicate limited or no correlation to the control.

At a minimum, there needs to be at least 1 control with high control significance per objective/criteria. Otherwise, there would be a design deficiency.

In my experience, policies and procedures would be assessed as low control significance, assuming the control objective doesn’t directly call out for policies and procedures. This isn’t to say policies and procedures aren’t an important aspect of the overall control environment, just that they’re not directly related to meeting the objective/criteria as stated. Monitoring controls (e.g. periodic review) would be assessed as moderate control significance. These controls are detective controls rather than preventive controls.

Risk of Non-Compliance

Each control is then assessed a rating of high or low based on the risk that testing would result in an exception or finding. This assessment is pretty straightforward. Controls are typically assessed as low risk of non-compliance unless one of the following criteria are met:

First Year Engagement: All controls are assessed a high risk of non-compliance.
Subsequent Year Engagement: Control assessed a high risk of non-compliance if exceptions or findings were noted in the prior year.
Other: Although less frequent, if exceptions were noted during other internal control assessments, the control could also be assessed as a high risk of non-compliance. These might be found on a corrective action plan (CAP) reports provided during planning.

Example completed risk assessment using the access control matrices in the image above.

Why

Now, you might ask, what’s the purpose of going through this process? There are 2 primary reasons:

Completeness: Ensure the controls are complete and there are no design deficiencies that would result a qualified opinion.
Sampling: Control significance and risk of non-compliance are used as a basis for determining testing sample sizes.

The completed risk assessment is documented in the audit workpapers and isn’t usually provided to the client. However, in some situations, the client might request the results of the risk assessment in what would be referred to as a test plan. The test plan would include the risk assessment along with a tentative plan for how each control will be tested. This request is more common with government clients.

Not all firms use the same audit methodology as noted above. However, it’s important for service organizations to understand what goes into each of the steps of an engagement prior to contracting with a service auditor. The best time to do this is during the request for services and proposal process, at which point the service auditor should provide a general audit methodology used to complete the engagement.